Submissions:Normalization - Revision history

EvaBlomqvist at 12:38, 23 September 2010

2010-09-23T12:38:55Z

ValentinaPresutti: Review has been created. Annotation 'assigned' has been removed. Annotation 'waiting' has been removed.

2010-09-16T18:15:51Z

Review has been created. Annotation 'assigned' has been removed. Annotation 'waiting' has been removed.

BenedictoRodriguezCastro at 15:29, 6 September 2010

2010-09-06T15:29:36Z

BenedictoRodriguezCastro at 15:27, 6 September 2010

2010-09-06T15:27:17Z

BenedictoRodriguezCastro at 15:24, 6 September 2010

2010-09-06T15:24:52Z

EvaBlomqvist: Review has been assigned.

2010-09-06T10:01:58Z

Review has been assigned.

EvaBlomqvist: Review has been assigned.

2010-09-06T09:56:59Z

Review has been assigned.

EvaBlomqvist: Review has been assigned.

2010-09-06T09:31:14Z

Review has been assigned.

EvaBlomqvist: Review has been assigned.

2010-09-06T09:30:49Z

Review has been assigned.

EvaBlomqvist: Article is waiting for review.

2010-09-06T09:30:21Z

Article is waiting for review.

@@ Line 24: / Line 24: @@
 |Origin=See [[Community:References/Modularisation of domain ontologies implemented in description logics and related formalisms including owl 3|(Rector, 2003)]]
 |KnownUse=See [[Community:References/Modularisation of domain ontologies implemented in description logics and related formalisms including owl 3|(Rector, 2003)]]
 }}
 {{Additional information header}}
+[[Category:Review assigned]]
-−
-−
-−
-−
-−
 {{Scenarios about me}}
 {{Reviews about me}}
 {{Modeling issues about me}}
 {{My references}}

@@ Line 28: / Line 28: @@
 }}
 {{Additional information header}}
-[[Category:Review assigned]]
-[[Category:Waiting for review]]
-[[Category:Review assigned]]
-[[Category:Review assigned]]
-[[Category:Review assigned]]
-[[Category:Review assigned]]
 {{Scenarios about me}}
 {{Reviews about me}}
@@ Line 40: / Line 40: @@
 {{Submission to event
 |Event=WOP:2010
-}}
+}}[[Category:Review assigned]]

@@ Line 13: / Line 13: @@
 |Motivation=There are ontologies where a given class can have plenty of superclasses, building a polyhierarchy. If all those subsumption relationships are directly stated by the ontology maintainer, two main problems rise: (i) the ontology becomes very difficult to maintain: whenever a subsumption must be deleted (because a class has changed) or created (because a new class has been created) it has to be done by hand; in a polyhierarchy the process becomes very inefficient and error-prone. (ii) the semantics are implicitly stated, not explicitly: any other ontologist or reasoner only knows that a class is a subclass of its superclasses, without knowing why.
 |Aim=To untangle a polyhierarchy, coding the subsumption relationships using restrictions rather than class-subclass relationships. The application example for this ODP is adapted from the Cell Type Ontology. In the example, the subsumption relationships that already are in the Cell Type Ontology are inferred by the reasoner instead of hard-coded. The term Neutrophil is used as an example class to show how a class can relate to different modules.
 |Elements=The original classes of the ontology are divided in different axes. The conditions for each subsumption relationship are encoded as restrictions (e.g. [PerformsFunction some Defense]) that will relate the different modules.
 |Implementation=Identify the modules: group the classes. Create the modules, maintaining only one parent for any given primitive class and making primitive siblings disjoint. Redefine the classes (or define the newly added classes) according to the conditions for belonging to each module. Protege includes a wizard, the restrictions matrix, that helps in the process.
 }}
 {{Logical OP Example Template
 |SolutionExample=http://ontologydesignpatterns.org/wiki/Image:Normalisation_instance.png
 |Consequences=The ontology gets untangled and becomes a collection of neat modules. The rest of the semantics are given by restrictions pointing to the modules, and the reasoner maintains the structure, avoding error-prone human maintenance of the polyhierarchy.
@@ Line 23: / Line 23: @@
 {{Logical OP Reference Template
 |Origin=See [[Community:References/Modularisation of domain ontologies implemented in description logics and related formalisms including owl 3|(Rector, 2003)]]
 }}
 {{Additional information header}}

@@ Line 21: / Line 21: @@
 |Consequences=The ontology gets untangled and becomes a collection of neat modules. The rest of the semantics are given by restrictions pointing to the modules, and the reasoner maintains the structure, avoding error-prone human maintenance of the polyhierarchy.
 }}
-{{Logical OP Reference Template}}
+{{Logical OP Reference Template
 {{Additional information header}}
 [[Category:Review assigned]]
 [[Category:Waiting for review]]

@@ Line 13: / Line 13: @@
 |Motivation=There are ontologies where a given class can have plenty of superclasses, building a polyhierarchy. If all those subsumption relationships are directly stated by the ontology maintainer, two main problems rise: (i) the ontology becomes very difficult to maintain: whenever a subsumption must be deleted (because a class has changed) or created (because a new class has been created) it has to be done by hand; in a polyhierarchy the process becomes very inefficient and error-prone. (ii) the semantics are implicitly stated, not explicitly: any other ontologist or reasoner only knows that a class is a subclass of its superclasses, without knowing why.
 |Aim=To untangle a polyhierarchy, coding the subsumption relationships using restrictions rather than class-subclass relationships. The application example for this ODP is adapted from the Cell Type Ontology. In the example, the subsumption relationships that already are in the Cell Type Ontology are inferred by the reasoner instead of hard-coded. The term Neutrophil is used as an example class to show how a class can relate to different modules.
 |Elements=The original classes of the ontology are divided in different axes. The conditions for each subsumption relationship are encoded as restrictions (e.g. [PerformsFunction some Defense]) that will relate the different modules.
 |Implementation=Identify the modules: group the classes. Create the modules, maintaining only one parent for any given primitive class and making primitive siblings disjoint. Redefine the classes (or define the newly added classes) according to the conditions for belonging to each module. Protege includes a wizard, the restrictions matrix, that helps in the process.
@@ Line 22: / Line 23: @@
 {{Logical OP Reference Template}}
 {{Additional information header}}
-{{Include Image
-|ImageName=Normalisation instance.png
-}}
 {{Scenarios about me}}
 {{Reviews about me}}
@@ Line 32: / Line 41: @@
 |Event=WOP:2010
 }}

← Older revision		Revision as of 09:30, 6 September 2010
Line 34:		Line 34:
	[[Category:Review assigned]]		[[Category:Review assigned]]
	[[Category:Waiting for review]]		[[Category:Waiting for review]]
		+	[[Category:Review assigned]]

← Older revision		Revision as of 09:30, 6 September 2010
Line 33:		Line 33:
	}}		}}
	[[Category:Review assigned]]		[[Category:Review assigned]]
		+	[[Category:Waiting for review]]