please see http://hilaltarakci.blogspot.com/2010/04/protege.html
link to a related paper: http://www.co-ode.org/resources/papers/ekaw2004.pdf
nice exercises: http://dig.csail.mit.edu/2010/LinkedData/Presentations/Session3-ontology.pdf
19 Nisan 2010 Pazartesi
12 Nisan 2010 Pazartesi
protege
For prior basic information see http://hilaltarakci.blogspot.com/2010/04/introduction-to-ontology-development.html...
Protege 4.1 can be downloaded from http://protege.stanford.edu/download/registered.html or http://www.co-ode.org/downloads/protege-x/ .
OWL plugins for protege 4.0 are at http://www.co-ode.org/downloads/protege-x/plugins/ .
And an extended tutorial to follow can be found at http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/resources/ProtegeOWLTutorialP4_v1_2.pdf .
Installing OWL plugins is just copying the plugin jar under
In this post, i aim to note down some basic issues from the tutorial i linked above.
The terminology mapping between protege frames and owl ontologies is as follows:
protege frame : instances, slots, classes
owl ontology : individuals, properties, classes
individuals: represents objects in domain, instances of classes.
properties: binary relations on individuals. They can have inverses (for example hasOwner and isOwnedBy are inverse properties to each other). There are two main types of properties: Object properties and Datatype properties. In owl, there is also Annotation properties. The following figure is taken from the tutorial linked above:
Properties also form a taxonomy. In other words, properties form a hierarchy, some properties are subproperties (or superproperties) of some other properties (hasMother is a subproperty of hasParent object property). However, it is not possible to create a hierarchy between different types of properties ( for example an object property can not be subproperty(or superproperty) of a datatype property.)
Properties can have various characteristics:
Functional Properties (Features):
In a functional property, there can be only one individual that can be related to the individual via the property. In the tutorial, there is a good example:
Inverse Functional Properties: The inverse property is functional.
Transitive Properties: If individual a is related to individual b and individual b is related to individual c via property P, then it can be inferred that individual a is related to individual c via property P.
Inverse property of a transitive property is also transitive.
Transitive property can not be functional.
Symmetric Properties: If individual a is related to individual b via property P, then it can be inferred that individual b is related to individual a via property P.
OWL-DL does not allow data type properties to be transitive, symmetric or has inverse properties.
Anti-Symmetric Properties: If individual a is related to individual b via property P, then it can be inferred that individual b can not be related to individual a via property P.
Reflexive Properties: Property P relates individual a to itself.
Irreflexive Properties: Property P can not relate individual a to itself.
Properties may have domains and ranges. They attach individuals from the domain to individuals from range.
In OWL, domains and ranges are not constraints. On the contrary, when an individual which is not explicitly stated to be in the range is linked via the property, then that individual is inferred to be a subclass of the range.
data type properties: link an individual to an XMLSchema Data type value or an rdf literal. In other words, they describe relationships between an individual and data values.
classes: interpreted as sets that contain individuals. Classes may be
organised into a superclass-subclass hierarchy forming a taxonomy (for example Animal is superclass of Cat). In order to relate two classes in a hierarchy, subclass must be a kind of (or is-a) superclass. In the Animal-Cat example, Cat is a kind of (or is-a) Animal, therefore the hierarchy is correct.
restrictions: The definition of restriction is:
.. and some restriction examples are:
Owl restrictions are:
Universal Restrictions (AllValuesFrom Restrictions- (protege keyword is only)):They constrain the relationships along a given property to individuals that are members of a specific class. For example the universal restriction ForAll hasTopping MozzarellaTopping describes the individuals all of whose hasTopping relationships are to members of the class MozzarellaTopping— the individuals do not have a hasTopping relationships to individuals that are not members of the class MozzarellaTopping.
Following the tutorial, i created a sample Pizza ontology by opening protege and selecting Create New OWL Ontology option.
Active Ontology Tab: In this tab, the metadata about the ontology itself is defined. For instance, i added a comment about the ontology under Annotations frame.
Classes Tab: In this tab, classes can be added to the ontology and the taxonomy is formed while adding classes via Add Subclass and Add Sibling buttons. Besides, some relationships between classes are also formed: for instance disjoint classes can be marked.
In the sample Pizza ontology, there exist three sibling classes: Pizza, PizzaTopping and PizzaBase which are all disjoint classes. In other words, an individual can only belong to one of these classes. It is enough to specify disjoint classes on one of the classes, the others will be automatically defined.
Also, using
After class definitions, the taxonomy seems as follows:
In this tab, it is also possible to define restrictions by selecting the class, adding a superclass by using class expression editor. This is just one possible way.. The editor luckily has auto-complete property. Edit/Duplicate selected classes is an efficient way to clone the selected class.
Object/Data Properties Tab: In this tab, the object/data properties, their domains and ranges and the relationship between them can be modeled.
Individuals Tab:
Reasoners (Classifiers): Ontologies described with OWL-DL can be processed by reasoners. A reasoner can generate an inferred ontology from an asserted ontology(the originally given ontology) and decides if the ontology is consistent. If any class in the ontology could not take any instances, this means inconsistency. There are a variety of reasoners: Hermit, Fact++, Pellet and so on..
Running reasoner on the asserted ontology is known as classifying the ontology. Prior to classifying the ontology a probe class is defined as subclasses of disjoint classes in order to check the inconsistency.
Necessary Conditions (Superclasses):If something is a member of the class then it is necessary to fulfil its necessary conditions. The reverse may not be correct (The members that fulfil the necessary conditions may not belong to that class).
Necessary and Suffucient Conditions(Equivalent Classes):If something is a member of this class then it is necessary and sufficient to fulfil these conditions. The reverse is also correct (All members that fulfil the necessary and sufficient conditions belong to that class).
Primitive Class: A class that only has necessary conditions.
Defined Class: A class that has at least one set of necessary and sufficient conditions.
In protege a primitive class can be converted to a defined class by Edit/Convert to defined class..
Defined classes are preferrable whereever you can, since reasoners can reason over them.
Open World Assumption (OWA):
Closure Axiom: A closure axiom on a property consists of a universal restriction that acts along the property to say that it can only be filled by the specified fillers. The restriction has a filler that is the union of the fillers that occur in the existential restrictions for the property.
Value Partition: This has nothing to do with OWL, it is a desig pattern. The steps are as follows:
Covering Axiom:
Cardinality Restrictions:
Complement Class: A complement class contains all of the individuals that are not contained in the class that it is the complement to. If NonVegetarianPizza is created as a subclass of Pizza and made the complement of VegetarianPizza, it should contain all of the Pizza s that are not membersof VegetarianPizza.
Enumerated Classes:
Note: Usage of OWLViz plugin requires installation of GraphViz.OWLViz plugin come bundled with Protege 4.. After installing GraphViz, the
Note: Everything in this post, every figure, definition and etc. is taken from the document at http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/resources/ProtegeOWLTutorialP4_v1_2.pdf .
I just aimed to give a compact summary of that tutorial.
Last update on 16/4/2010 10:57
Protege 4.1 can be downloaded from http://protege.stanford.edu/download/registered.html or http://www.co-ode.org/downloads/protege-x/ .
OWL plugins for protege 4.0 are at http://www.co-ode.org/downloads/protege-x/plugins/ .
And an extended tutorial to follow can be found at http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/resources/ProtegeOWLTutorialP4_v1_2.pdf .
Installing OWL plugins is just copying the plugin jar under
Protege4.1-Home/plugins folder.In this post, i aim to note down some basic issues from the tutorial i linked above.
The terminology mapping between protege frames and owl ontologies is as follows:
protege frame : instances, slots, classes
owl ontology : individuals, properties, classes
individuals: represents objects in domain, instances of classes.
properties: binary relations on individuals. They can have inverses (for example hasOwner and isOwnedBy are inverse properties to each other). There are two main types of properties: Object properties and Datatype properties. In owl, there is also Annotation properties. The following figure is taken from the tutorial linked above:
Properties also form a taxonomy. In other words, properties form a hierarchy, some properties are subproperties (or superproperties) of some other properties (hasMother is a subproperty of hasParent object property). However, it is not possible to create a hierarchy between different types of properties ( for example an object property can not be subproperty(or superproperty) of a datatype property.)
Properties can have various characteristics:
Functional Properties (Features):
In a functional property, there can be only one individual that can be related to the individual via the property. In the tutorial, there is a good example:
Inverse Functional Properties: The inverse property is functional.
Transitive Properties: If individual a is related to individual b and individual b is related to individual c via property P, then it can be inferred that individual a is related to individual c via property P.
Inverse property of a transitive property is also transitive.
Transitive property can not be functional.
Symmetric Properties: If individual a is related to individual b via property P, then it can be inferred that individual b is related to individual a via property P.
OWL-DL does not allow data type properties to be transitive, symmetric or has inverse properties.
Anti-Symmetric Properties: If individual a is related to individual b via property P, then it can be inferred that individual b can not be related to individual a via property P.
Reflexive Properties: Property P relates individual a to itself.
Irreflexive Properties: Property P can not relate individual a to itself.
Properties may have domains and ranges. They attach individuals from the domain to individuals from range.
In OWL, domains and ranges are not constraints. On the contrary, when an individual which is not explicitly stated to be in the range is linked via the property, then that individual is inferred to be a subclass of the range.
data type properties: link an individual to an XMLSchema Data type value or an rdf literal. In other words, they describe relationships between an individual and data values.
classes: interpreted as sets that contain individuals. Classes may be
organised into a superclass-subclass hierarchy forming a taxonomy (for example Animal is superclass of Cat). In order to relate two classes in a hierarchy, subclass must be a kind of (or is-a) superclass. In the Animal-Cat example, Cat is a kind of (or is-a) Animal, therefore the hierarchy is correct.
restrictions: The definition of restriction is:
.. and some restriction examples are:
Owl restrictions are:
- Quantifier Restrictions (existential, universal)
- Cardinality Restrictions
- hasValue Restrictions
Universal Restrictions (AllValuesFrom Restrictions- (protege keyword is only)):They constrain the relationships along a given property to individuals that are members of a specific class. For example the universal restriction ForAll hasTopping MozzarellaTopping describes the individuals all of whose hasTopping relationships are to members of the class MozzarellaTopping— the individuals do not have a hasTopping relationships to individuals that are not members of the class MozzarellaTopping.
Following the tutorial, i created a sample Pizza ontology by opening protege and selecting Create New OWL Ontology option.
Active Ontology Tab: In this tab, the metadata about the ontology itself is defined. For instance, i added a comment about the ontology under Annotations frame.
Classes Tab: In this tab, classes can be added to the ontology and the taxonomy is formed while adding classes via Add Subclass and Add Sibling buttons. Besides, some relationships between classes are also formed: for instance disjoint classes can be marked.
In the sample Pizza ontology, there exist three sibling classes: Pizza, PizzaTopping and PizzaBase which are all disjoint classes. In other words, an individual can only belong to one of these classes. It is enough to specify disjoint classes on one of the classes, the others will be automatically defined.
Also, using
Tools/Create class hierarchy is an easy way to create a class hierarchy and making them disjoint. It is also possible to define a common prefix or suffix for the classes entered via this tool. Hierarchy can be represented with a tab as follows:
After class definitions, the taxonomy seems as follows:
In this tab, it is also possible to define restrictions by selecting the class, adding a superclass by using class expression editor. This is just one possible way.. The editor luckily has auto-complete property. Edit/Duplicate selected classes is an efficient way to clone the selected class.
Object/Data Properties Tab: In this tab, the object/data properties, their domains and ranges and the relationship between them can be modeled.
Individuals Tab:
Reasoners (Classifiers): Ontologies described with OWL-DL can be processed by reasoners. A reasoner can generate an inferred ontology from an asserted ontology(the originally given ontology) and decides if the ontology is consistent. If any class in the ontology could not take any instances, this means inconsistency. There are a variety of reasoners: Hermit, Fact++, Pellet and so on..
Running reasoner on the asserted ontology is known as classifying the ontology. Prior to classifying the ontology a probe class is defined as subclasses of disjoint classes in order to check the inconsistency.
Necessary Conditions (Superclasses):If something is a member of the class then it is necessary to fulfil its necessary conditions. The reverse may not be correct (The members that fulfil the necessary conditions may not belong to that class).
Necessary and Suffucient Conditions(Equivalent Classes):If something is a member of this class then it is necessary and sufficient to fulfil these conditions. The reverse is also correct (All members that fulfil the necessary and sufficient conditions belong to that class).
Primitive Class: A class that only has necessary conditions.
Defined Class: A class that has at least one set of necessary and sufficient conditions.
In protege a primitive class can be converted to a defined class by Edit/Convert to defined class..
Defined classes are preferrable whereever you can, since reasoners can reason over them.
Open World Assumption (OWA):
Closure Axiom: A closure axiom on a property consists of a universal restriction that acts along the property to say that it can only be filled by the specified fillers. The restriction has a filler that is the union of the fillers that occur in the existential restrictions for the property.
Value Partition: This has nothing to do with OWL, it is a desig pattern. The steps are as follows:
Covering Axiom:
Cardinality Restrictions:
Complement Class: A complement class contains all of the individuals that are not contained in the class that it is the complement to. If NonVegetarianPizza is created as a subclass of Pizza and made the complement of VegetarianPizza, it should contain all of the Pizza s that are not membersof VegetarianPizza.
Enumerated Classes:
Note: Usage of OWLViz plugin requires installation of GraphViz.OWLViz plugin come bundled with Protege 4.. After installing GraphViz, the
dot file under GraphViz-home/bin/dot.exe should be set from File/Preferences/OWLViz tab in Protege. http://protegewiki.stanford.edu/wiki/OWLViz#InstallationNote: Everything in this post, every figure, definition and etc. is taken from the document at http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/resources/ProtegeOWLTutorialP4_v1_2.pdf .
I just aimed to give a compact summary of that tutorial.
Last update on 16/4/2010 10:57
9 Nisan 2010 Cuma
introduction to ontology development
At work, during preperation of a conference paper related to semantic web, i luckily had a chance to use protege for ontology development.. Protege (http://protege.stanford.edu/) is an ontology editor and knowledge acquisition system. In this series of posts, i write down my experience of using protege as an ontology editor..
The paper at http://protege.stanford.edu/publications/ontology_development/ontology101.html proposes a methodology for developing an ontology. According to that paper, the domain and scope of the ontology should be defined properly before the design phase. After that, ontologies that have been developed so far in that domain should be checked. Using previous ontologies provides compatibility with applications using that ontology. Then the next step is writing down all the terms you can think of related to the concerned domain. Those terms are than examined and determined if they are classes or not. The terms that are decided to be classes are organized in a hierarchy with one of top-down, bottom-up approaches or a combination of them. Then, the slots are determined by using the generated class hierarchy and previously written and marked as not-class terms. The slots have domains and ranges and facets(restriction) can be defined on them. Afterwards, instances are created and the knowledge base is so close to be complete. However, ontology development is an iterative work and some of these steps should be carried out over and over in order to catch the balance: the developed ontology should be neither too generic nor too specific.
I will continue with new posts focusing on more specific issues and usage of protege.
The paper at http://protege.stanford.edu/publications/ontology_development/ontology101.html proposes a methodology for developing an ontology. According to that paper, the domain and scope of the ontology should be defined properly before the design phase. After that, ontologies that have been developed so far in that domain should be checked. Using previous ontologies provides compatibility with applications using that ontology. Then the next step is writing down all the terms you can think of related to the concerned domain. Those terms are than examined and determined if they are classes or not. The terms that are decided to be classes are organized in a hierarchy with one of top-down, bottom-up approaches or a combination of them. Then, the slots are determined by using the generated class hierarchy and previously written and marked as not-class terms. The slots have domains and ranges and facets(restriction) can be defined on them. Afterwards, instances are created and the knowledge base is so close to be complete. However, ontology development is an iterative work and some of these steps should be carried out over and over in order to catch the balance: the developed ontology should be neither too generic nor too specific.
I will continue with new posts focusing on more specific issues and usage of protege.
Kaydol:
Kayıtlar (Atom)