OWL Concepts. Last Modified Tuesday, July 21, 2009 at 01:41:30 PM Document Revision: 65

Transcription

1 OWL Concepts Much of the information contained in this document was pulled from, or at least strongly inspired from, the Protégé mailing list. You can be sure that the errors are my own, however. Given the source, this document likely contains numerous errors and oversights. You have been warned. Last Modified Tuesday, July 21, 2009 at 01:41:30 PM Document Revision: 65

2 Table of Contents Table of Contents...iii 1. Introduction RDF RDFS OWL Common schemas Other resources Ontology repositories Document an ontology URIs Modeling examples owl:disjointwith Use all items from a set Force a property to have a value Limit a property to a list of values Set membership on property value Equal to...12 Less than Class with prerequisite Another question Russ responds Inconsistent class from properties Using a meta-class When do you use subclass When do you use metaclass...21 How do you create a meta-class Problems to solve Misc Stuff ComplimentOf and open world reasoning Has parent property owl:complimentof Limit number of members Quantifier and cardinality restrictions Restrictions are for reasoners Express mandatory participation Equivalent OWL Concepts Reasoning capabilities RDF/RDFS reasoning capabilities OWL reasoning capabilities Reifying relationships Querying OWL SPARQL...39 iii

3 Question Answer Answer SPARQL Inferred types Literal relates to Resource Represent the same thing Using value Methods to implement Descriptive Logics Restrict OWL Full to obtain OWL DL iv

4 1. Introduction The Web Ontology Language (OWL) is built on the Resource Description Framework (RDF) and RDF Schema (RDFS) as shown in Figure 1. RDFS is built on top of RDF. Therefore, to understand OWL, you must understand RDF and RDFS RDF Figure 1: OWL 1 is built on RDF and RDFS. RDF is a general-purpose language or data model for objects ( resources ) and relations between them. 1. RDF is a framework for describing resources in the World Wide Web (WWW). 2. RDF provides a model for data, and a syntax so that independent parties can exchange and use it. 3. RDF was designed to be read and understood by computers. 4. RDF was not designed to be displayed to people. 5. RDF is primarily written in XML. 6. RDF describes resources with classes, properties, and values. 7. RDF is a W3C standard RDFS RDF does not provide a method to define application-specific classes and properties. Application-specific classes and properties are defined using extensions to RDF. RDFS is a vocabulary for describing properties and classes of RDF resources, with semantics for generalization-hierarchies of such properties and classes. 1

5 RDFS provides the framework to define application specific (domain specific) classes and properties, rather than providing the application specific classes and properties. Classes in RDFS allow resources to be defined as instances of, and subclasses of, classes. RDFS provides the ability to define your own properties and classes, specify subclass and subproperty relationships, and to define domain and range relationships. Specific items can be inferred from the relationships. Let O be an ontology. If a resource is used as a property, then it is a property; if (?s,?p,?o) O then (?p, rdf:type, rdf:property) O. The property subclassof is transitive; if (?x, rdfs:subclassof,?y) O and (?y, rdfs:subclassof,?z) O then (?x, rdfs:subclassof,?z) O. Type and subclass are similar; if (?x, rdf:type,?y) O and (?y, rdfs:subclassof,?z) O then (?x, rdf:type,?z) O. Range specifies type; if (?x,?p,?y) O and (?y, rdfs:range,?z) O then (?x, rdfs:type,?z) O OWL OWL adds vocabulary to RDF for describing properties and classes; for example, relations between classes, cardinality, equality, richer typing of properties, characteristics of properties, and enumerated classes. Properties link two individuals together. An OWL property is the same as a relation in UML. 1. OWL is built on RDF and RDFS. 2. OWL was designed for processing information on the web. 3. OWL was designed to be interpreted by computers. 4. OWL was not designed to be displayed to people. 5. OWL is primarily written in XML. 6. OWL has sub-languages (or variants). 7. OWL is a standard. OWL provides a language that describes entities and how they are related. The initial need for OWL was seen in the poorly mapped documents on the WWW, where our primary ability to search is based on keyword searches and document connectivity. Automated searching and mapping is, therefore, difficult at best. OWL provides a mechanism to represent the data that allows you to: 2

6 1. define classes and the properties of those classes, 2. define individuals and assert properties about the individuals, and 3. reason about these classes and individuals. The ability to represent related data, intelligently query the data, and draw conclusions about that data, has numerous applications. As such, interest in OWL has grown and is now in active use in numerous domains outside the confines of the WWW. There are different versions of OWL (see Table 1 and Table 2). Table 1. OWL 1.0 variants. Variant Lite DL Full Description Supports a classification hierarchy with simple constraints. DL corresponds to the term Description Logics. OWL DL is computationally complete (all entailments are guaranteed to be computed) and decidable (all computations will finish in finite time).. Maximum expressiveness and the syntactic freedom, but with no computational guarantees. It is unlikely that reasoning software will be able to support every feature of OWL Full. See olw vocabulary document for this section: OWL 2 introduces new variants. Table 2. OWL 2 variants. Variant Subset Description Lite EL++ OWL 2 DL Enables polynomial time algorithms for the reasoning tasks consistency, classification, and instance checking. Dedicated reasoning algorithms for this profile are available and have been demonstrated to be implementable in a highly scalable way. DL-Lite OWL 2 DL Conjunctive query answering can be implemented using conventional relational database systems (after rewriting the query). In particular, this requires that conjunctive query answering is in LogSpace regarding data complexity. As in EL++, there are polynomial time algorithms for consistency, classification, and instance checking. OWL 2 DL OWL-R DL OWL 2 Full The OWL-R profile enables the implementation of reasoning algorithms by forward chaining rules applied to triples of the RDF serialization. In particular, such rule approaches can be used to compute consistency, classification, and instance checking in polynomial time. Conjunctive query answering in OWL-R can be implemented by extending a standard relational database system with rules. OWL-R comes in two varieties, 3

7 Variant Subset Description OWL-R DL and OWL-R Full. OWL-R Full OWL 2 Full The OWL-R profile enables the implementation of reasoning algorithms by forward chaining rules applied to triples of the RDF serialization. In particular, such rule approaches can be used to compute consistency, classification, and instance checking in polynomial time. Conjunctive query answering in OWL-R can be implemented by extending a standard relational database system with rules. OWL-R comes in two varieties, OWL-R DL and OWL-R Full. Full The profiles EL++, DL-Lite, and OWL-R DL are defined by placing restrictions on the syntax of OWL 2 DL. In contrast, OWL-R Full is defined by placing restrictions on the semantics of OWL 2 Full. OWL DL and OWL Full use the same vocabulary Every legal OWL Lite ontology is a legal OWL DL ontology. Every legal OWL DL ontology is a legal OWL Full ontology. Every valid OWL Lite conclusion is a valid OWL DL conclusion. Every valid OWL DL conclusion is a valid OWL Full conclusion. Every OWL document is an RDF document. Every RDF document is an OWL Full document. Every URI used as a class name must be explicitly asserted to be of type owl:class Every individual must be asserted to belong to at least one class (even if only owl:thing), URI's used for classes, properties and individuals must be mutually disjoint Common schemas Elements in OWL are identified using a URI or IRI. Frequently used schemas are typically defined in namespace schema declarations or as entity elements. Common OWL schemas are shown in Table 3. Table 3. Common OWL schemas. Prefix Namespace Comment rdf rdfs 4

8 Prefix Namespace Comment xsd owl owl2xml owl11 Old owl11xml Old dc Other resources Mapping OWL 1.1 (now 2.0) to RDF Reasoning with OWL Ontology repositories You can register your ontologies if you desire: Protégé wiki TONES SWOOGLE There is a best practices published by W3C: You can link people to the OWL browser (see already loaded with your ontology by perma-linking (see for instructions) Document an ontology 5

9 2. URIs Every non-literal resource in an Ontology has a URI, including the Ontology. Every Ontology also has a base URI that is used as the base context for a URI that is not fully specified. 7

10 3. Modeling examples Consider the fundamental differences between an OO design approach and a logic design approach. 1. In logic and OWL, restrictions are inference rules, not constraints. Reasoning engines use the restrictions to infer new information, which is very different, and it can lead to surprises. 2. Properties in OWL have their own independent existence. Properties are not "part of" classes, but rather, separate from them (although they do interact). You must understand the meaning of the OWL constructs, because they have meaning (as interpreted by OWL reasoners like Pellet, Fact++, Racer, etc.) And a number of the difference between the logic/inference rule style and the object-oriented style will cause you some surprise, bewilderment or even consternation. So, instead of thinking in the Java style, you must think more OWL-like. Start with an idea of what sorts of objects you want to model. Next, consider what sorts of properties such objects would have. Properties can have domains and ranges, as well as additional features such as being functional, transitive, symmetric, etc. The domains indicate what sort of classes they apply to, but these are inferences, not type checks. The distinction is that OWL will infer that individuals belong to the domain of properties that are asserted about them. OWL won't complain about individuals not being (previously) known to be of that class. Note also that properties, unless known to be functional, can have more than one value. The values, however, will not be ordered. They are a SET of values. Perhaps there are additional restrictions on properties that are specific to particular classes. Those restrictions are added to the class description as either necessary or necessary&sufficient restrictions. The distinction has to do with the inferences that a reasoner is able to perform. Necessary restrictions permit inference in one direction only. Necessary and sufficient restrictions permit inferences in both directions. Making restrictions sufficient when they shouldn't be is one way to get some rather unwelcome inferences. Finally, you may not really want to use SPARQL on OWL knowledge bases because SPARQL doesn't really understand the OWL semantics. Instead, it operates on the underlying RDF serialization of the OWL structures. For querying, you may wish to consider either SQWRL or some programmatic constructs like the OWLAPI 2.0 or the Protégé-OWL API owl:disjointwith There are two usual methods of claiming that one class is disjoint with the another; they are equivalent. <owl:disjointwith> <owl:class rdf:about="#aname"/> </owl:disjointwith> </owl:disjointwith rdf:resource="#aname"/> 9

11 3.2. Use all items from a set The Protégé pizza Ontology defines named pizzas with specific toppings. For example, I can define a pizza that uses mozzarella, mushroom, and tomato. Each of the listed toppings must be used, and only the listed toppings may be used. To accomplish this, the techniques presented in sections 10 and 10 must both be used Force a property to have a value Each topping is given its own restriction, which creates an anonymous class of all individuals that use a specific toping (see Listing 1). The named pizza is listed as a subclass of the anonymous class, which implies that it must use the MozzarellaTopping. In other words, there exists a hastopping property with the value MozzarellaTopping. Listing 1. Anonymous class with hastopping set to MozzarellaTopping. <rdfs:subclassof> <owl:restriction> <owl:somevaluesfrom rdf:resource="#mozzarellatopping"/> <owl:onproperty> <owl:objectproperty rdf:about="#hastopping"/> </owl:onproperty> </owl:restriction> </rdfs:subclassof> The generated axioms are as follows: Axioms 1. Anonymous class with hastopping set to MozzarellaTopping. _:1 <owl:onproperty> <pizza:hastopping> _:1 <rdf:type> <owl:restriction> _:1 <owl:somevaluesfrom> <pizza:mozzarellatopping> <pizza:sloppygiuseppe> <rdfs:subclassof> _:1 Provide an entry for every value that you desire the property to have. This forces the property to have specific values, but it does not limit the property to have only these values Limit a property to a list of values The allvaluesfrom restriction limits the values that a property may have. For example, Listing 2 says that the hastopping property is limited to one of three values. Listing 2. Anonymous class where hastopping values are limited. <rdfs:subclassof> <owl:restriction> <owl:onproperty> <owl:objectproperty rdf:about="#hastopping"/> 10

12 </owl:onproperty> <owl:allvaluesfrom> <owl:class> <owl:unionof rdf:parsetype="collection"> <owl:class rdf:about="#mozzarellatopping"/> <owl:class rdf:about="#mushroomtopping"/> <owl:class rdf:about="#tomatotopping"/> </owl:unionof> </owl:class> </owl:allvaluesfrom> </owl:restriction> </rdfs:subclassof> The generated axioms are as follows: Axioms 2. Anonymous class where hastopping values are limited. _:2 <rdfs:type> <owl:restriction> _:2 <owl:allvaluesfrom> _:3 _:2 <owl:onproperty> <pizza:hastopping> _:3 <owl:unionof> _:4 _:3 <rdfs:type> <owl:class> _:4 <rdfs:rest> _:5 _:4 <rdfs:first> <pizza:mozzarellatopping> _:5 <rdfs:rest> _:6 _:5 <rdfs:first> <pizza:mushroomtopping> _:6 <rdfs:rest> <rdfs:nil> _:6 <rdfs:first> <pizza:tomatotopping> <pizza:sloppygiuseppe> <rdfs:subclassof> _:2 On its own, this construct limits the values that can be used, but does not force all values from the set to be used. If you model from select list as an individual in the ontology, then you could use any of several techniques: 1. Just have the select list be an individual and make direct property value assertions 2. Create a class for that type of select list and use hasvalue restrictions to provide property values for all individuals of that class. If instead you want to just model the individuals for a particular select list, but not the list itself, then you again have a couple of choices: 1. Create a class and just assert the individuals. Use a query to get the individuals of that class. 11

13 2. Create an enumerated class. This allows you to skip the assertion step, since you've already specified class members by enumeration. You still need to use a query to get the individuals of the class. The main benefit of option 2 is that you have a closed set of individuals that belong to the class, so certain reasoning steps like exclusion (complement) are made easier. But if you just query procedurally for known individuals, then this is unlikely to be an issue. Note that for exclusion to really work, you have to make sure that the individuals are known to be alldifferent from any other individuals in the ontology Set membership on property value Equal to Write a rule If inclination is equal to 90 deg, then it is a Polar orbit. <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" xmlns=" xmlns:owl=" xmlns:xsd=" xmlns:rdfs=" xml:base=" <owl:ontology rdf:about=""/> <owl:class rdf:id="satellite"/> <owl:class rdf:id="polarorbit"> <rdfs:subclassof> <owl:restriction> <owl:onproperty> <owl:datatypeproperty rdf:id="hasinclination"/> </owl:onproperty> <owl:hasvalue rdf:datatype=" >90.0</owl:hasValue> </owl:restriction> </rdfs:subclassof> </owl:class> <owl:class rdf:id="notpolarorbit"/> <owl:datatypeproperty rdf:about="#hasinclination"> <rdfs:range rdf:resource=" <rdfs:domain rdf:resource="#satellite"/> </owl:datatypeproperty> </rdf:rdf> 12

14 The system shall support owl:hasvalue. The value constraint owl:hasvalue is a built-in OWL property that links a restriction class to a value V, which can be either an individual or a data value. A restriction containing a owl:hasvalue constraint describes a class of all individuals for which the property concerned has at least one value semantically equal to V (it may have other values as well). The following example describes the class of individuals who have the individual referred to as Clinton as their parent: <owl:restriction> <owl:onproperty rdf:resource="#hasparent" /> <owl:hasvalue rdf:resource="#clinton" /> </owl:restriction> NOTE: for datatypes "semantically equal" means that the lexical representation of the literals maps to the same value. For individuals it means that they either have the same URI reference or are defined as being the same individual (see owl:sameas). NOTE: the value constraint owl:hasvalue is not included in OWL Lite. Less than Write a rule If inclination is less than 90 deg, then it is not a Polar orbit. Write a rule If inclination is equal to 90 deg, then it is a Polar orbit. How can I write a rule for this statement "If the inclination is equal to 90 deg, then it is a Polar orbit ". If I wrote the rule will it be able to restrict the Polar_Orbit class to take greater or less value in it's hasinclination property? hasinclination(?x,?i) ^ swrlb:lessthan(?i, 90) -> Polar_Orbit(?x) It would be good to define what?x is though. Full documentation for the SWRLTab can be found here: For an exact value, you can use the hasvalue restriction from OWL. You only need to use SWRL if you want a comparison. (Well, that or use OWL 2.0 when that becomes available). I presume the hasinclination property is Functional. 13

15 3.1. Class with prerequisite I am developing a university education ontology. I added every lecture as a class to the ontology. And I defined a property "HasPrerequisite" meaning some lectures can have 1 or more prerequisite(s). If someone wants to take a lecture he/she must have passed from all of the prerequisite lectures. I defined HasPrerequisite property from lecture to lecture. And by making restrictions I adapt the property for each lecture class. My question is: If a lecture has only 1 prerequisite lecture, I define a hasvalue restriction. Right? But if a lecture has many prerequisites I can't use hasvalue with anding(intersecting) them. A person can take a lecture if the person passed all of the prerequisite lectures. How can I define such a restriction? Like "LectureA HasPrerequisite (LectureX and LectureY and LectureZ)" By making hasvalue restrictions for all of the prerequisites one by one. Or and'ing them and using maybe allvaluesfrom restriction. Thomas Russ Well, this is a bit of a tricky modeling situation. But first, let's be clear about how some of the different restrictions work. hasvalue takes an Individual as its argument and means that the restricted property must have that individual as one of its fillers. somevaluefrom takes a Class as its argument and means that the restricted property must have at least one filler from that class. Generally, unless you want to create OWL-Full ontologies, you will not be using hasvalue with classes. You would generally be using somevaluesfrom instead. But some of that depends on what other choices you make in your modeling. In other words, it partly depends on what your domain of discourse is, and that is where some of the choices get a bit tricky. OPTION 1. Make each lecture an individual. In this case you will be treating each lecture as an individual rather than as a class of lectures. It will also mean that you can't distinguish between a lecture given in 2006 and one given in 2008, since there will only be one individual for each lecture. If you go this route, then you can use hasvalue to set the values of the pre-requisites. You would have a separate hasvalue restriction for each pre-requisite. You can have multiple such restrictions. Students can take these lectures, but you won't be able to distinguish among lectures taken in different years or semesters. You also would not be able to tell if two students took the lecture at the same time. In effect, you will have treated the lecture class as the concrete domain object that you are talking about. 14

16 But this is still problematic because pre-requisites are not restrictions on the lectures, but rather on the students who take the lectures. See discussion below. OPTION 2. Make each lecture a class. The individuals of these classes can be particular instances of the lectures happening, and thus have particular instructors, students, times, etc. Pre- requisites could perhaps then be modeled using somevaluesfrom type restrictions. But this approach is problematic because the pre-requisites are NOT actually restrictions on the lectures themselves, but rather restrictions on the students who are taking the lectures. So one would need to use a more complicated formulation to place the restriction on the student. I think this may be the most accurate model, but the formulation makes the pre-requisites be an implicit model, which would make it difficult to answer the question "What are the prerequisites of course X?". That is because one would otherwise require a higher order logic to represent the mapping rule. This relies on the presence of some additional properties: takescourse (Student -> Lecture) hasstudent (Lecture -> Student), inverse of takescourse To say that Lecture1 has Lecture2 as a pre-requisite, one could then write: Lecture1 <=> hasstudent allvaluesfrom (Student and takescourse somevaluesfrom Lecture2) In other words, students that are taking (an instance of) Lecture1 must belong to the class of students how have taken (an instance of) Lecture2. Now this can be extended to a requirement of having passed the class by just changing the "takescourse" property to "passescourse" in the restriction. This extends to multiple pre-requisites by just adding additional somevaluesfrom clauses: LectureA <=> hasstudent allvaluesfrom (Student and passescourse somevaluesfrom LectureX and passescourse somevaluesfrom LectureY and passescourse somevaluesfrom LectureZ) This gives a good structural model, although as noted above, it would not be easy to query the ontology to find the restrictions from the somevalues from clauses. OPTION 3. Make the pre-requisites annotations of the lecture classes rather than restrictions. In this case you would have to build your own inference procedure to check for consistency, because annotations don't get enforced by the classification reasoner the way restrictions do. Also, not all systems are happy having classes as values of annotation properties. Since you have your own interpretation of the annotation, you can assign the appropriate semantics to the interpretation and enforcement of the pre-requisites property. OPTION 4. Use classes as fillers of the pre-requisites property. 15

17 This puts you into OWL-Full and still doesn't solve the issue of the student being the one restricted. Kaarel Kaljurand adds: both the domain and the range of the property 'has-prerequisite' are the class 'lecture'? > My question is: > If a lecture has only 1 prerequisite lecture, I define a hasvalue restriction. Right? Well, the argument of 'hasvalue' must be an individual. You can say that: (1) Calculus-2 instanceof has-prerequisite value Calculus-1. but here both Calculus-1 and Calculus-2 are individual lectures. Note that (1) is equivalent to (2): (2) ObjectPropertyAssertion(has-prerequisite Calculus-2 Calculus-1) It is probably simpler to assert (2) in Protégé. > But if a lecture has many prerequisites I can't use hasvalue with anding(intersecting) them. Just assert several axioms of type (2) (or (1)). > A person can take a lecture if the person passed all of the > prerequisite lectures. How can I define such a restriction? Do you mean something like this (think of 'takes' as 'has taken'): (3) If a person takes a lecture X then the person takes every lecture that is a prerequisite of the lecture X. Now, if your instance data says that: (4) John takes Calculus-2. (5) It is false that John takes Calculus-1. (6) A prerequisite of Calculus-2 is Calculus-1. Then you would get an inconsistency which helps you to "discover" that John hasn't been playing by the rules set by the prerequisite-assertions. The SWRL equivalent of (3) is (7) person(?x1) and lecture(?x2) and lecture(?x3) and take(?x1?x2) and hasprerequisite(?x2?x3) -> take(?x1?x3) which you could also express as an OWL 2 property chain (assuming that you use Protégé 4): (8) (take o has-prerequisite) SubPropertyOf take 16

18 Another question I chose OPTION 2 and made every lecture a class, more precisely a subclass of Lecture. I really want to make restrictions on the lectures not the students (Really good point you made). Modelling lectures are more important for my model. I'm only modeling graduate students, so the prerequisites are for modeling lecture class model. And if a student took the course than he/she also passed it. I'm developing this ontology in OWL-DL. Yes I realized using hasvalue is irrelevant. Now I use allvaluesfrom : For "LectureA has prerequisite LectureB" I make a restriction on HasPrerequisite: "allvaluesfrom LectureB" And when I try to add prerequisite LectureB instance for the "HasPrerequisite property" for the instance of LectureA which has 1 prerequisite(lectureb), only the relevant prerequisite class's instances(lectureb instances) come to choose from. Restriction works. It seems okay. Right? But if a lecture has more than 1 prerequisite I "or" the prerequisites which is not an exactly right solution for the case. I tried and'ing them and then adding individuals to test(if i mixed up the and's and or's) but it is irrelevant because it doesn't restrict the range as I wanted. Neither of these approaches really do what you want. For ex: "LectureA HasPrerequisite LectureX and LectureY and LectureZ" This means that each prerequisite must be an instance that is an instance of all three classes. This is clearly not what you want. I use "allvaluesfrom LectureX or LectureY or LectureZ" restriction for HasPrerequisite property. This, by itself, is not what you want either, although it can be useful as a closure axiom. That is because a single instance of LectureY satisfies the restriction. In fact, having no fillers at all satisfy the restriction. But you could use this if you also combined it with somevaluesfrom LectureX and somevaluesfrom LectureY and somevaluesfrom LectureZ 17

19 And when I try to add prerequisites to the LectureA instance, only LectureX, LectureY and LectureZ instances come to choose from. But it isn't exactly right because it makes an union of LectureX, Y, Z classes, so someone can choose all of the prerequisites from LectureX instances for example. Can't I make a restriction for "1 LectureX and 1 LectureY and 1 LectureZ" with using only lecture classes? Yes. That is just about what somevaluesfrom does. It means "at least 1 LectureX", etc. By the way I have "takescourse" property. What I don't really understand is If a lecture has 1 prerequisite I can model it right. But if it has more than 1 I can't. Why restrictions using only lecture classes isn't sufficient? I think that this is really a tough problem to model, given the limitations of description logic's expressive power. That is because the restriction that you really want to formalize is a 2nd order logic constraint. I would think that ideally you would want to have something like the following logical sentences: 1.hasPrerequisite(LectureA, LectureX) 2.hasPrerequisite(LectureA, LectureY) 3.Lecture(?c) ^ hastype(?c,?t) ^ hasprerequisite(?t,?p) ^ Student(?s) ^ takescourse(?s,?c) => exists(?c2): hastype(?c2,?p) ^ takescourse(?s,?c2) And it is the rule in #3 that is a second-order logic rule, since we are reasoning over types. So you would need a more powerful reasoner that what description logic provides. Now, the effect of that would be to force the inference of fillers for the pre-requisites. It will not detect missing pre-requisites. To detect missing pre-requisites requires a slightly different rule and the ability to do closed-world reasoning, either by assuming closed world or by explicit closure axioms: 3'. Lecture(?c) ^ hastype(?c,?t) ^ hasprerequisite(?t,?p) ^ Student(?s) ^ takescourse(?s,?c) ^ not [exists(?c2): hastype(?c2,?p) ^ takescourse(?s,?c2)] => StudentNotMeetingPrerequisites(?s) But doing reasoning like this requires more than description logics. Blowing our own horn here, I would point out that the PowerLoom first order logic reasoner can do this, but you will give up certain inference guarantees that you have with OWL-DL. If you want more information about PowerLoom, you can contact me privately. Thanks for the advice Thomas Russ, I read and understood your points, you are saying I should extend this ontology and should include students in my restricitons. 18

20 Russ responds I don't think you want allvaluesfrom. I think you really want somevaluesfrom. allvaluesfrom doesn't require that there be any fillers at all. So, for example, if you were to define a class: Person <=> child allvaluesfrom Person this would be satisfied by someone with no children. Using somevaluesfrom says that there is at least one filler of the given type. That seems to be closer to what you really mean. But in fact, if you really are attaching the pre-requisites to the class, I think they should be annotation properties rather than restrictions. That is because restrictions apply to instances of the class rather than to the class object itself. And it seems just a bit odd to say that a particular instance of LectureA must have as a pre- requisite a particular instance of LectureB. And this doesn't really link into any restriction on the students themselves, so you would have to use some external reasoning process to detect failure to fulfill pre-requisites Inconsistent class from properties You must be aware of the inferential consequences of the Ontology. What you say in OWL has effects that depend on the reasoner. Consider the difference between necessary conditions (a one-way implication) and necessary and sufficient conditions (a two- way implication, also sometimes called the equivalent class). Consider some abstract examples. Assume : classes A, B, C properties p1, p2, p3 => to show necessary conditions <=> to show necessary and sufficient conditions Assume the ontology states: (9) B <=> exactly 1 p1 & exactly 1 p2 (10) C <=> exactly 1 p1 & exactly 1 p2 Item (9) states that ANYTHING with exactly one p1 and one p2 is a B. Item (10) says the same thing about C. In fact, these definitions imply that B and C are the same class. If you then add that B and C are disjoint, then you get an inconsistent ontology once you include individuals. An overly general set of necessary and sufficient conditions can result in an implication that you do not intend. There are two ways to avoid this. One method is to make the conditions necessary and not sufficient: 19

21 (11) B => exactly 1 p1 & exactly 1 p2 (12) C => exactly 1 p1 & exactly 1 p2 (13) B /= C This says that anything that both B and C have the properties, but says nothing about the class if an individual has the properties. Therefore, you can have B and C disjoint without problems. Another approach depends on other intermediate classes that are disjoint. (14) B <=> A1 & exactly 1 p1 & exactly 1 p2 (15) C <=> A2 & exactly 1 p1 & exactly 1 p2 (16) A1 /= A2 Here you can use a fully equivalent definition because you include the additional class A1 or A2 in the right hand side of the definition. So just having the properties alone is not sufficient for class membership. As a general rule, it is often incorrect to have necessary and sufficient conditions that consist solely of property restrictions. This tends to result in overly broad definitions that include many more individuals than you really intend. The reason individuals are needed for inconsistency is that it is perfectly valid for a model to have classes that are contradictory as long as there are no individuals. Such classes must have no extension in the model theoretic sense. So as long as no individuals exist for such classes, there is no inconsistency. In other words, one can define a class of childless parents, and the ontology is fully consistent as long as there aren't any individuals of that class Using a meta-class The members of a meta-class are classes themselves. Consider a standard biological taxonomy. Different levels of the hierarchy are given different names, such as species, genus, family, phylum, etc. Now consider a Wolf: 1. Kingdom: Animalia 2. Phylum: Chordata 3. Class: Mammalia 4. Order: Carnivora 5. Family: Canidae 6. Genus: Canis 20

22 7. Species: Canis lupus 8. Subspecies: familiaris When do you use subclass Should I use a subclass relationship for? Kingdom > Phylum > Class > Order > Family > Genus > Species > Subspecies If you are thinking of adding the assertion: B sub-class-of A Then you should be happy saying every B is an A The definition using predicate logic would be subclass-of(b, A) <=> forall.x: B(x) -> A(x) It is NOT true that every class is a phylum, so you do not want a sub-class-of relation. How about for Animalae > Chordata > Mammalia > Carnivora > Canidae > Canis > Canis Lupus... It is true that every Lupus is a Canis, and every Canis is a Canidae. It makes sense to use a subclass relationship here. The basic principle is that you do not want to use the class hierarchy to express relationships that are not true class/subclass (or set/subset) relations. This is because the subclass relation has a particular defined meaning that the reasoners use, and if you apply it in situations where that meaning does not hold, the reasoners produce undesirable inferences. If, for example, one were to say that Wolf was a subclass of Species, then when one asked what were all the species, then all individual wolves would be returned. But that is not what you would really want to get. So you must respect the semantics of the language constructs so as not to mislead the reasoner When do you use metaclass The class Wolf (Canis Lupus) has the meta-type species, but it is NOT a subclass of species; Canis Lupus is a subclass of the genus Canis. This is because any individual wolf is also an individual of type Canis, and so on including being an individual of type Mammal. If Wolf is a class, and Canis Lupus is a class, the two classes have the same class extension both class extensions contain exactly the same set of individuals. You can, therefore, link the two classes using owl:equivalentclass. This does not mean that they have the same concept, just that they have the same class extension. For true class equality in an OWL full ontology, you can use owl:sameas. 21

23 An individual wolf would not be an individual of type species. It is the class Wolf that is an individual of type species. So that makes Species, Genus, etc. meta-classes since they have classes and individuals. There is some disagreement as to what happens when you use a meta-class. It is my opinion that the ontology becomes full. The Protégé OWL sub-language identifier identifies any ontology with a meta-class in it as being in OWL Full. My reading of the vague mentions in the OWL ref ( seem to indicate full as well. I believe, however, that Thomas Russ stated that he was not able to find anything conclusive in the OWL standards that mandate that the use of meta-classes alone cause an ontology to be OWL Full rather than OWL DL. It certainly can't lie alone in the use of rdf:type on them, since that assertion is allowed in OWL- Lite constructs such as "A rdf:type owl:class". So if someone has a pointer to a reference and explanation, I would like it. It could easily be that I am just missing some implication of other language in the standard. One reason I don't think this should move ontologies into OWL Full is that (built-in) metaclasses are already used. OWL DL already makes internal use of meta-classes, at least among properties, since there are several different property classes that one can belong to, such as ObjectProperty, DatatypeProperty, FunctionalProperty, TransitiveProperty, etc. In fact, those features also appear in OWL Lite. So as long as you don't try to put property restrictions on your meta-classes, I didn't think you would change the OWL species into OWL Full. But it seems that the various OWL sublanguage validators disagree, so I must be missing something. How do you create a meta-class In Protégé 3.4, use the following steps: 1. Use Owl > Preferences to open the OWL Preferences dialog. 2. On the Visibility tab, enable owl:class, which will also enable rdfs:class. 3. Close the OWL Preferences dialog. 4. Use the OWL classes tab. 5. Create classes X and Y as a subclassof owl:class (or rdfs:class) 6. Use the Individuals tab. 7. In the Class Hierarchy tree, expand owl:class and select class rdfs:class. 8. In the Asserted Instances window, select class X. 9. In the Asserted Types section, click the add button and add class Y. What is the result from an XML perspective? 22

24 <rdfs:class rdf:id="y"> <rdfs:subclassof rdf:resource=":owl-class"/> </rdfs:class> <Y rdf:id="x"> <rdfs:subclassof rdf:resource=":owl-class"/> <rdf:type rdf:resource=" </Y> What if these are created as a subclassof rdfs:class rather than owl:class? I prefer this! <owl:class rdf:id="y"> <rdfs:subclassof rdf:resource=" </owl:class> <Y rdf:id="x"> <rdf:type rdf:resource=" <rdfs:subclassof rdf:resource=" </Y> Class Y type owl:class subclassof rdfs:class. Class X type Y type owl:class rdfs:subclassof rdfs:class See why I consider this OWL Full? I do not fully understand how to create a class of type rdfs:class in Protégé 4, but I tried something like this: 1. Use the Class tab. 2. Create class A and class B. 3. Switch to the Individuals tab. 4. Create an individual named B. You will receive a warning that B already exists. 5. Under the Types area, add a new type and select A. So, what is the result? <owl:class rdf:about="#a"/> <owl:class rdf:about="#b"/> 23

25 <owl:thing rdf:about="#b"> <rdf:type rdf:resource="#a"/> </owl:thing> So, what do I expect to see in the Ontology? Canis is of type Genus, and it is a class. Canis rdf:type Genus Canis rdf:type owl:class Canis rdfs:subclassof Canidae Canis is an individual of type Genus, so Genus is the meta-class, and it is also a Class with a hierarchy. 24

26 4. Problems to solve Many names for the same object. Classification based on a range. 25

27 5. Misc Stuff 5.1. ComplimentOf and open world reasoning With open world reasoning, there is no way to infer information based on negation (not) or on maximum cardinality constraints (including exactly N) by looking at the fillers of the properties. With open world assumptions, it is always possible that there are additional property values that are not (yet) revealed. The possibility of additional property values means that counting property values cannot be used for valid inferences. In practice, you can not recognize nodes based on this type of inference; you must directly assert the facts Has parent property I connect instances with relations such as parent and child. I define the RootNode class as the first class without a parent. I define the LeaveNode class as the first class without a child. I use restrictions such as not (hasfather some Node) and hasfather exactly 0. The reasoners (pellet and racer) are not able to infer root or leaf nodes. The same problem exists with the Pizza ontology, which does not infer an instance of vegetarian pizza from an instance of pizza with only vegetarians topping and without meat toppings owl:complimentof The problem was also seen with a country class with individuals such as China and Germany. The class HomemadeMedicine has necessary and sufficient conditions that the ObjectProperty producedin has value China. The ImportedMedicine has necessary and sufficient condition 'not (producedin China)', but the reasoner does not obtain the expected results: it said some individual was forced to belong to a class and its compliment.assert that ImportedMedicine is the intersection of the compliment of HomemadeMedicine and Medicine. Protégé changes the necessary condition 'Medicine' to necessary and sufficient. The reasoner did not report errors, but inferred no individual belong to ImportedMedicine while in fact I had some Medicine producedin Germany. The Reasoner didn't conclude any medicine as ImportedMedicine because, unless you explicitly disallow it, a medicine produced in Germany can also be produced in MainlandChina. It is an example of OWL's open world assumption. Also, the unique name assumption (UNA) does not hold, so without an alldifferent assertion, the reasoner does not know that China and Germany are different individuals. Both of these issues must be addressed. The UNA is, in general, the easier problem. If producedin is a FunctionalProperty, that would solve the open world problem, but it may not be justified by the domain to make it functional, since I could imagine a medicine being produced in more than one country. 27

28 5.4. Limit number of members I want to define a Class "SmallDepartment" that contains all individuals of the class Department that have a maximum of three individuals of Person working in the Department. Informally, something like this: Class SmallDeparment definedby: each?department with Number_of_individuals(?person) < 4 with?person as the set of individuals working in?department (via the hasrole/hasdepartment links) This is easy to do using a max cardinality restriction. Attach that restriction to the appropriate property. It turns out that this will generally not help you in inferring that a particular department is a small department because open world reasoning makes it hard to evaluate maximum cardinality restrictions. That is because unless you create additional assertions to close the set of potential fillers, an OWL reasoner cannot know that there aren't some other, not yet known fillers, and thus it can't compute maximum cardinality by counting fillers. Note also that counting fillers requires alldifferent assertions as well, since OWL doesn't use a unique name assumption either Quantifier and cardinality restrictions I want to enforce quantifier / cardinality restriction in a simple test ontology. 1. (Q) With the quantifiers an "existential" quantifier on the property requiring somevaluefrom both classes 'B' and 'C' is enforced here. However in the instance I attach A's individual to only B's individual. The resoner doesnt point this out as an inconsistency. Why is that? 1. (A) Because you are not thinking of the restrictions in the proper OWL way. They are not just constraints, but also INFERENCE RULES. So, unless you actually have some way of proving that B's individual CANNOT logically be of type C, then Pellet will in fact, infer that the individual belongs to class C as well as B. The information that you provide can be used for inference, and that is what the system does. 2. (Q)Also if I do not use this property to attach to any of the individuals, I only get a red box but still no reasoner inconsistency by doing "Check Consistency". 28

29 1. That is because of the open world reasoning assumption. Just because a value is not asserted in the ontology, it doesn't mean that the assertion is false. So OWL is quite happy knowing that there is a filler of the property (which is an inference from the existential restriction), even if it doesn't happen to know which particular instance is that filler. One of the expressive power benefits of OWL is that the reasoner can operate with such vague knowledge that there is a filler. It doesn't have to be grounded in a concrete individual. 3. Cardinality restriction of say at least one such relation are not detected by the reasoner as an inconsistency if there are no such relations. Again what I get is a red box surrounding the widget. I am sure there is something wrong in my approach. Please advise. 1. See above. This is the designed behavior of OWL. The red box is just a user interface aid and legacy of the Protégé frames language. Consider it a reminder that a filler is present, but unknown. It is NOT an error or inconsistency. 2. To get an inconsistency, an OWL reasoner has to be able to prove that no such individual filler CAN exist. That is much harder to do than just not knowing what the filler is. 4. I asserted in the ontology that 'A', 'B' and 'C' are disjoint classes. Does this mean that the individuals will be of a single type of those classes? (in which case they should be distinct) 1. That is correct. If the classes are defined to be disjoint, then an instance can only belong to one and still be consistent. 2. A's "necessary and sufficient" definition states that it should have "some" from 'B' and 'C' classes for the property named 'property'. 3. I didn't read the OWL ontology you included, even though it was short. I find the RDF syntax not particularly human-friendly. So I misinterpreted your initial question. I assumed you meant "property some (B and C)" when in fact you meant "(property some B) and (property some C)" 5. In the ontology given below I have only attached it to B's instance. Do I need to assert (due to open world assumption) that it does not have a property with 'C' explicitly to generate and inconsistency here? 1. Yes. 6. How do I do this at the instance level to generate some form of inconsistency. Explicitly assert the cardinality, but that is actually something that is a bit tricky to express in OWL 1.0, since the only qualified cardinality restriction comes with the SOME operator. In OWL 1.1/2.0 you would be able to have a qualified cardinality restriction, which would allow you to say what you mean directly. 29

30 INSTANCE type maxcardinality(0 property C) In other words, you have to say the instance belongs to a type which has a maximum cardinality of 0 for fillers of "property" of type C. In OWL 1.0, you don't have that syntax, but you can achieve the same effect by using the complement operator INSTANCE type complement(property some C) In other words you have to say that the instance belongs to the class that excludes the class where property has some filler of type C. 1.The reason I want to do this is because the "design" and "instance" ontologies are separate and I need some way of knowing that the "instance" ontology's individual did not follow its class's definition in the "design". Well, the problem with the approach you have to take is that you need to know what elements the instance does not conform to. And that limits the practical usefulness, since you can't really have inference detect the inconsistency. You have to know enough about the type's definition to be able to explicitly say what parts of the definition are not satisfied, and once you've figured that out, you don't really need the inference engine -- since you already found the answer. So, lack of any sort of closure mechanism or circumscriptive reasoner greatly reduces the effectiveness of the inconsistency detection for the case of missing information. Open world semantics just make that nearly impossible to achieve. Now, in the case of mutually disjoint classes, you may be able to use a slightly simpler and more reasonable procedure, namely generating some closure by asserting the cardinality of the property. So in your example, where you have an instance with 1 B filler and no others, you could say instance type (property cardinality 1) that says there is exactly one filler of "property". And if it needs to have two different fillers (because of the disjointness of B and C), this could lead to an inconsistency. This approach is appealing because you don't need to know all of the restrictions that you have to negate. It is therefore much easier to construct the assertions from looking at the instance itself. I can't recall, however, if the standard reasoners do this sort of counting and reasoning by cases necessary to detect this inconsistency. 2.Same as above if I state that a class has mincardinality 1 for a property, just because it has an instance which does not have the property asserted, does not mean that it doesn't exist. In order to generate an inconsistency here, do I need to explicitly assert this. How do I do this this (close the system where if I state that mincardinality is 1, every instance should have at least one of that property else there is some sort of error flagging?) 30

31 Again, you would have to explicitly say that the instance doesn't have any fillers, so you would have to assert that the instance belongs to the type maxcardinality 0. So then when you have an instance that belongs to types with mincardinality 1 maxcardinality 0 for a given property, you get a contradiction. Listing 3. Quantifier and cardinality restrictions. <?xml version="1.0"?> <rdf:rdf xmlns=" xmlns:rdf=" xmlns:xsd=" xmlns:rdfs=" xmlns:owl=" xmlns:p1=" xml:base=" <owl:ontology rdf:about=""/> <owl:class rdf:id="b"> <owl:disjointwith> <owl:class rdf:id="c"/> </owl:disjointwith> </owl:class> <owl:class rdf:id="a"> <owl:equivalentclass> <owl:class> <owl:intersectionof rdf:parsetype="collection"> <owl:restriction> <owl:somevaluesfrom rdf:resource="#b"/> <owl:onproperty> <owl:objectproperty rdf:id="property"/> </owl:onproperty> </owl:restriction> <owl:restriction> <owl:onproperty> <owl:objectproperty rdf:about="#property"/> </owl:onproperty> <owl:somevaluesfrom> <owl:class rdf:about="#c"/> </owl:somevaluesfrom> </owl:restriction> 31

32 </owl:intersectionof> </owl:class> </owl:equivalentclass> </owl:class> <owl:class rdf:about="#c"> <owl:disjointwith rdf:resource="#b"/> </owl:class> <owl:objectproperty rdf:about="#property"> <rdfs:domain rdf:resource="#a"/> <rdfs:range> <owl:class> <owl:unionof rdf:parsetype="collection"> <owl:class rdf:about="#b"/> <owl:class rdf:about="#c"/> </owl:unionof> </owl:class> </rdfs:range> </owl:objectproperty> <B rdf:id="b1"/> <C rdf:id="c1"/> <A rdf:id="a1"> <property rdf:resource="#b1"/> </A> </rdf:rdf> Restrictions are for reasoners Although you can use a DL-reasoner to check for a contradiction, the open world assumptions of OWL prevent a reasoner from warning about missing information. Missing information is not really missing, it is assumed to be present but unknown. The restrictions that you put in OWL class definitions are not type tests or constraints, but axioms that can be used to infer additional information that is not explicitly given. Given a mincardinality of 2 on a property, we know that there are two values for that property even if we do not know what they are. This is not an inconsistency, but merely an unknown value. The ability to represent such unknown values is one of the things that gives OWL more expressive power than, say, a relational database Express mandatory participation The objective is to be able to express mandatory participation of instances of a concept into a Datatype property. Assume that where U is a data type property (concept attribute, concrete domain role, etc). That is, we want to say: 32

33 A \isa \exists U in DL Use a minimum cardinality restriction with the minimum cardinality being 1: A \isa U >= 1 Up to now, we have been doing it in Protégé with the "asserted conditions" editor in the "class editor" in this way: (17) A \isa U some rdf:xmlliteral and would also like to be able to say: (18) A \isa U some xsd:string and similar (xsd:integer, etc) The problem with (17) is that the meaning of rdf:xmlliteral is not very clear in the OWL specification, can it be used as the domain that contains all concrete domain values? that is, does rdf:xmlliteral subsumes xsd:string, xsd:integer, etc? If this is the case, then we have no problem, this is the meaning we want, if not... are there any other options? The problem with (18) is that it seems Protégé doesnt allow you to say it, at least not in the "asserted conditions editor" in the "class editor". Is this a bug? is it intended for some reason? We are about to start working on fixing inside Protégé's code in case it is a bug... before doing so I wanted to consult to check that we are not going in the wrong direction. P.S. Note that what we want to say are not domain and range restrictions over U (which can be said with the domain and range editors in the "properties editor") Equivalent You cannot make a property that takes a literal (for example, STRING) and have it be equivalent to one that takes an object. In other words, a DatatypeProperty and an ObjectProperty cannot be equivalent, because they are disjoint classes. Think about what it would mean for the properties to be the same. It would mean they have to support the same values, and they clearly don't. 33

34 6. OWL Concepts 6.1. Reasoning capabilities RDF/RDFS reasoning capabilities OWL reasoning capabilities include the RDF/RDFS reasoning capabilities, so they are important to understand. 1.Inheritance is reflexive. A class is rdfs:subclassof of itself, and a property is a rdfs:subpropertyof of itself. 2.Inheritance sets the type. If A is rdfs:subclassof of B, then A is of type B. An implication of this, is that a class can have multiple types. 3.Inheritance is transitive. If A is rdfs:subclassof of B, and B is rdfs:subclassof of C, then A is rdfs:subclassof of C. The same is true for rdfs:subpropertyof. 4.Rdfs:domain and rdfs:range constraints imply type. Assume that the rdfs:domain for serves is Waiter and the rdfs:range is Patron. If A serves B, then A is of type Waiter and B is of type Patron OWL reasoning capabilities OWL reasoning is similar to the RDFS reasoning. 1.Inheritance is reflexive. A class is owl:subclassof of itself, and a property is a owl:subpropertyof of itself. 2.Inheritance sets the type. If A is owl:subclassof of B, then A is of type B. An implication of this, is that a class can have multiple types. 3.Inheritance is transitive. If A is owl:subclassof of B, and B is owl:subclassof of C, then A is owl:subclassof of C. The same is true for owl:subpropertyof. See Reifying relationships In our recent modeling exercises with real-world customers it became (once more) evident that reified relationships are a key requirement in many domains. Reified relationships are everywhere. A typical solution to this is to introduce a relationship class that connects a source/subject with a target/object, so that you could attach additional attributes to the relationship objects. For example if we want to be able to attach an index to each parent-child relationship (first child, second child etc), then we can introduce an object to link parent, child and the index. 35

35 However, in many such cases it becomes very complicating and inconvenient if you need to do reasoning with such reified relationships. In many cases you want to talk about a simple relationship such as isparentof instead of having to construct statements involving reified objects like ChildParentRelationship. As a small exercise I have created an ontology pattern to automatically synchronize a reified relationship with a plain (object) property. I have no idea if this is useful to someone (and whether this has been shown elsewhere already), but anyway I'd like to share this idea here. An example based on this pattern is demonstrated below: Figure 2. Reified Example. We have a generic base class reif:binaryrelationship with properties reif:subject and reif:object. A subclass of this is reif:synchronizedbinaryrelationship, and you can create subclasses of this, such as ChildParentRelationship. Then let's assume we have a class Person with instances, and a simple property pair hasparent and isparentof. Now, whenever we create a reified ChildParentRelationship between A and B, we want to automatically also get the triple A hasparent B. This is expressed by connecting our relationship class with the hasparent property (OWL Full Full). To drive this, automatic inferences can be expressed in a rule language and then used by engines such as the generic Jena rule engine. Here is the corresponding rule in Jena notation: [synchronize: (?r rdf:type?rt) (?rt rdfs:subclassof reif:synchronizedbinaryrelationship) (?r reif:subject?s) (?r reif:object?o) (?rt reif:synchronizedproperty?p) -> (?s?p?o) ] A worked-out example can be found here and the generic pattern can be imported from 36