This document is also available in these non-normative formats: PDF version.
Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The rewrite and editing of this Working Draft has undergone a complete rewritebeen completed
since the previous version of 11 April 2008, to improve21st April, 2009.
The Working Group believes it has completed its readability and utility. Examples are now mostly also available in Turtle syntax.design
work for the technologies specified this document will undergo further significant revision beforedocument, so this
is a final version"Last Call" draft. The design is not expected to
change significantly, going forward, and now is produced.the key
time for external review, before the implementation
phase.
The OWL Working Group seeks public feedback on this Working Draft. Please send your comments to public-owl-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document and see if the relevant text has already been updated.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The W3C OWL 2 Web Ontology Language (OWL) is a Semantic Web language designed to represent rich and complex knowledge about individuals,things, groups of individuals,things, and relations between individuals.things. OWL is a computational logic-based language such that knowledge expressed in OWL can be reasoned with by computer programs either to verify the consistency of that knowledge or to make implicit knowledge explicit.
OWL documents, known as ontologies, can be published in the World Wide Web and may refer to or be referred from other OWL ontologies. OWL is part of the W3C's Semantic Web technology stack, which includes RDF RDF/XML [RDF] and SPARQL .[RDF].
The key goal of the primer is to help develop insight into OWL, its strengths, and its weaknesses.
The core of the primer is an introduction to most of the language features of OWL by way of a running example. Most of the examples in the primer are taken from a sample ontology (which is presented entirely in an appendix). This sample ontology is designed to touch the key language features of OWL in an understandable way and not, in itself, to be a exemplaran example of a good ontology.
Editor's Note: Pointers to sections to be checked in final version.This document is intended to provide an initial understanding about OWL 2. In particular it is supposed to be accessible for people yet unfamiliar with the topic. Therefore, we start with giving some high-level introduction on the nature of OWL 2 in Section 2 by providingbefore Section 3 provides some very basic notions in knowledge representation and explainexplains how they relate to terms used in OWL 2. Readers familiar with knowledge representation and reasoning might only skim through this section to get acquainted with the OWL 2 terminology.
Sections 3 - 74-8 describe most of the language features that OWL provides, starting from very basic ones and proceeding to the more sophisticated.
Section 34 presents and discusses the elementary modeling features of OWL 2 before in Section 45 complex classes are introduced. Section 5 adresses6 addresses advanced modeling features for properties. Section 67 focuses on advanced modeling related to dadatypes.datatypes. Section 78 concludes with extra-logical features used mainly for ontology management purposes.
In Section 89 we address the differences between OWL 2 DL and OWL 2 Full, the two semantic views of OWL, while in Section 910 we describe the 3 Profilesthree tractable sublanguages of OWL 2.2, called profiles. Tool support for OWL 2 is addressed in Section 1011 and in Section 1112 we give pointers on where to continue reading after our informal introduction to OWL 2.
Finally, Section 12.2 explains how13 lists the complete example ontology used in this document.
For a comprehensive listing of the OWL 2 relates to other key technologies.language features, see the [OWL 2 Quick Guide] which provides links into the corresponding sections of the appropriate documents concerning syntax and examples.
For readers already familiar with OWL 1, [OWL 2 New Features and Rationale] provides a comprehensive overview of what has changed in OWL 2.
OWL is part ofa language to be used in the Semantic Web, so names in OWL are international resource identifiers (IRIs) [RFC-3987]. As IRIs are long, we will often make use a compact wayof abbreviation mechanisms for writing them in OWL, consisting of a prefixOWL. The way in which such abbreviations work is specific to each syntactic format that can be used to encode OWL ontologies, but the examples in this document can generally be understood without knowing these details. Appropriate declarations for namespaces and a local part separated by a colon, asrelated mechanisms are given further below in SPARQL [SPARQL] .Section 8.2.
There are various syntaxes available for OWL available,which serve various purposes:purposes. The Functional-Style syntax [OWL 2 Specification] is designed to be easier for specification purposes and to provide a foundation for reasoningthe implementation of OWL 2 tools to use.such as APIs and reasoners.
The RDF/XML syntax for OWL is just RDF/XML, with a particular translation for the OWL constructs [OWL 2 RDF Mapping]. This is the only syntax that is mandatory to be supported by all OWL 2 tools.
The Manchester syntax [OWL 2 Manchester Syntax] is an OWL syntax that is designed to be easier for non-logicians to read.
The OWL XML syntax is an XML syntax for OWL defined by an XML schema [OWL 2 SpecificationXML Serialization].
There are tools that can translate between the different syntaxes for OWL. In many syntactic forms, OWL language constructs are also represented by IRIs, and some declarations might be needed to use the abbreviated forms as in the examples. Again, necessary details are found in Section 8.2.
The examples and the sample ontology in the appendix can be viewed as any of the four different syntaxes - in fact for RDFsyntaxes, and we giveprovide both theRDF/XML [RDF/XML Syntax] and theTurtle [RDF Turtle Syntax] serializations for the RDF-based syntax. You can control which syntaxes are shown throughout the document by using the buttons below.
Editor's Note: Control Panel: owl.css should include, for each type of syntax, a heading line saying, e.g. "RDF/XML Syntax:"The buttons below can be used to show or hide the available syntaxes.
OWL 2 is a knowledge representation language, designed to formulate, exchangelanguage for expressing ontologies. The term ontology has a complex history both in and reason with knowledge aboutout of computer science, but we use it to mean a domaincertain kind of interest. Some fundamental notions should first be explainedcomputational artifact – i.e., something akin to understand how knowledge is represented in OWL 2. These basic notions are: Axioms: the basic statements thata program, an XML schema, or a web page – generally presented as a document. An OWLontology expresses Entities: elements used to refer to the real-world objects that are modelled Expressions: combinationsis a set of entities to form complex descriptions from basic ones While OWL 2 aimsprecise descriptive statements about some part of the world (usually referred to capture knowledge,as the kind of “knowledge” that can be represented by OWL does of course not reflect all aspectsdomain of human knowledge. OWL can rather be considered as a powerful general-purpose modelling language for certain partsinterest or the subject matter of human knowledge.the modelling artefacts createdontology). Precise descriptions satisfy several purposes: most notably, they prevent misunderstandings in OWL are called ontologies – a terminologyhuman communication and they ensure that also helps to avoid confusion since the term “model” is often usedsoftware behaves in a rather different sense in knowledge representation. Now,uniform, predictable way and works well with other software.
In order to formulate knowledge explicitly,precisely describe a domain of interest, it is usefulhelpful to assume that it consistscome up with a set of elementary pieces that arecentral terms – often referred to as statements or propositions . Statements like “it is raining” or “every man is mortal” are typical examples for such basic propositions. In OWL 2, these basic “pieces of knowledge” arecalled axioms . Indeed, every OWL 2 ontology isvocabulary – from an abstract viewpoint – essentially justand fix their meaning. Besides a collectionconcise natural language definition, the meaning of axioms. It is characteristic for axioms that theya term can be saidcharacterized by stating how this term is interrelated to be true or false giventhe other terms. A certain state of affairs. This distinguishes axioms from entities and expressions that are described further below. When humans think, they draw consequences from their knowledge.terminology, providing a vocabulary together with such interrelation information constitutes an important featureessential part of a typical OWL is that it captures2 document. Besides this aspect of human intelligence for the forms ofterminological knowledge, an ontology might also contain so called assertional knowledge that it can represent. But what does it mean, generally speaking, that a statement is a consequencedeals with concrete objects of other statements? Essentially it means that this statement is true wheneverthe other statements are. Inconsidered domain rather than general notions.
OWL terms: we say, a set of axioms2 is not a entails an axiomprogramming language: OWL 2 is declarative, i.e. it describes a if in anystate of affairs wherein all axioms from A are true, also a is true. Moreover,in a set of axioms maylogical way. Appropriate tools (so-called reasoners) can then be consistent (that is, there is a possibleused to infer further information about that state of affairs in which all the axioms in the setaffairs. How these inferences are jointly true) or inconsistent (thererealized algorithmically is no such statenot part of affairs).the OWL document but depends on the specific implementations. Still, the correct answer to any such question is predetermined by the formal semantics of OWL specifies,(which comes in essence, for which possible “states of affairs” – interpretations – a particulartwo versions: the direct semantics [OWL ontology is true. There are2 Direct Semantics] and the RDF-based semantics [OWL tools – reasoners –2 RDF-Based Semantics]). Only implementations that can automatically compute consequences.comply with these semantics will be regarded as OWL 2 conformant (see [OWL 2 Conformance]). Through its declarative nature, the way axioms interactactivity of creating OWL 2 documents is conceptually different from programming. Still, as in both cases complex formal documents are created, certain notions from software engineering can be very subtletransferred to ontology engineering, such as methodological and difficultcollaborative aspects, modularization, patterns, etc.
OWL 2 is not a schema language for peoplesyntax conformance. Unlike XML, OWL 2 does not provide elaborate means to understand without tool support. This is bothprescribe how a strength anddocument should be structured syntactically. In particular, there is no way to enforce that a weaknesscertain piece of information (like the social security number of a person) has to be syntactically present. This should be kept in mind as OWL 2. Ithas some features that a user might misinterpret this way.
OWL 2 is not a strength becausedatabase framework. Admittedly, OWL 2 can discoverdocuments store information thatand so do databases. Moreover a person would not have spotted. This allows knowledge engineers to model more directlycertain analogy between assertional information and the system to provide useful feedbackdatabase content as well as terminological information and critique ofdatabase schemata can be drawn. However, usually there are crucial differences in the modelling. Itunderlying assumptions (technically: the used semantics). If some fact is not present in a weakness becausedatabase, it is comparatively difficult for humans to immediately foreseeusually considered false (the so-called closed-world assumption) whereas in the actual effectcase of various constructs in various combinations. Tool support amelioratesan OWL 2 document it may simply be missing (but possibly true), following the situation but successful knowledge engineeringopen-world assumption. Moreover, database schemata often still requires some amount of training and experience. Havingcome with the prescriptive constraint semantics mentioned above. Still, technically, databases provide a closer look atviable backbone in many ontology-oriented systems.
OWL axioms, we see that they are rarely “monolithic” but more often have some internal structure that can be explicitly represented. They normally refer2 is a knowledge representation language, designed to objects of the worldformulate, exchange and describe them e.g. by putting them into categories (like “Mary is female”) or saying somethingreason with knowledge about their relation (“John and Mary are married”). All atomic constituentsa domain of axioms,interest. Some fundamental notions should first be they objects (John, Mary), categories (female) or relations (married) are called entities .explained to understand how knowledge is represented in OWL 2, we denote objects as individuals , categories as classes and relations as properties . Properties in2. These basic notions are:
While OWL 2 aims to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead ofcapture knowledge, the domainkind of interest. As a central feature“knowledge” that can be represented by OWL does of OWL, namescourse not reflect all aspects of entitieshuman knowledge. OWL can be combined into expressions using so called constructors .considered as a basic example, the atomic classes “female” and “professor” could be combined conjunctively to describepowerful general-purpose modeling language for certain parts of human knowledge. The classresults of female professors.the latter would be described by an OWL class expression,modeling processes are called ontologies – a terminology that could bealso helps to avoid confusion since the term “model” is often used in statements ora rather different sense in other expressions.knowledge representation.
Now, in this sense, expressions can be seenorder to formulate knowledge explicitly, it is useful to assume that it consists of elementary pieces that are often referred to as new entities whichstatements or propositions. Statements like “it is raining” or “every man is mortal” are defined by their structure. In OWL, the constructors for each sort of entity varies greatly. The expression languagetypical examples for classessuch basic propositions.
Indeed, every OWL 2 ontology is very richessentially just a collection of such basic “pieces of knowledge.” Statements that are made in an ontology are called axioms in OWL 2, and sophisticated, whereas the expression language for properties is much less so. These differences have historical as well as technical reasons. Editor's Note:the following could be marked (via smaller font size or indentation)ontology asserts that its axioms are true. In some way as additional explanation which cangeneral, OWL statements might be skipped. One can use basic algebra aseither true or false given a somewhat naive but possibly elucidating analogy for the introduced terminology. An axiom would relate tocertain state of affairs. This distinguishes them from entities and expressions as described further below.
When humans think, they draw consequences from their knowledge. An equation like x=y . Clearly,important feature of OWL is that it captures this axiom can be said true or false, depending on the stateaspect of affairs (i.e.human intelligence for the actual valuesforms of these variables). Moreover, the two axioms x=y and y=z entailknowledge that it can represent. But what does it mean, generally speaking, that a statement is a consequence of other statements? Essentially it means that this statement is true whenever the axiom x=z , asother statements are. In everyOWL terms: we say, a set of statements A entails a statement a if in any state of affairs where the formerwherein all statements from A are true, the latter isalso a is true. Likewise, we can haveMoreover, a set of statements may be consistent sets(that is, there is a possible state of axioms ( x=y , y=z )affairs in which all the statements in the set are jointly true) or inconsistent ones ( x=y , y=x+1 ). Obviously,(there is no such state of affairs). The axioms consistformal semantics of entities ( x , y , z )OWL specifies, in essence, for which possible “states of affairs” a particular set of OWL statements is true.
There are not themselves true or false andOWL tools – reasoners – that can be combined by constructors ( + , - , etc.) into expressions (like x+y or y-z ) which in aautomatically compute consequences. The way represent new entities andontological axioms interact can be used instead of simple entities in axioms ( x+y=y-z ). 3 Classes, Properties,very subtle and Individuals - And Basic Modelling With Them After these general considerations, we now engage in the details of modeling with OWL 2. In the subsequent sections, we will introduce the essential modeling features that OWL 2 offers, provide examples and give some general comments on how to use them. We will proceed from basic features, which are essentially available in any modeling language,difficult for people to more advanced constructs. 3.1 Classesunderstand. This is both a strength and Instances Suppose we want to representa weakness of OWL 2. It is a strength because OWL 2 tools can discover information aboutthat a particular family. (We doperson would not intendhave spotted. This exampleallows knowledge engineers to be representative of the sorts of domains OWL should be used for, or as a canonical example of good modeling with OWL, or a correct representation ofmodel more directly and the rather complex, shifting,system to provide useful feedback and politically explosive domaincritique of families. Instead, we intendthe modeling. It to beis a rather simple exhibitionweakness because it is comparatively difficult for humans to immediately foresee the actual effect of various features of OWL.) We first need to provideconstructs in various combinations. Tool support ameliorates the information what personssituation but successful knowledge engineering often still requires some amount of training and experience.
Having a closer look at statements in OWL, we see that they are talking about. Thisrarely “monolithic” but more often have some internal structure that can be done as follows: ClassAssertion( f:Person f:Mary ) <f:Person rdf:about="#Mary"/> f:Mary rdf:type f:Person . Individual: Mary Types: Person <owl:ClassAssertion> <owl:Class IRI="&f;Person"/> <owl:NamedIndividual IRI="&f;Mary"/> </owl:ClassAssertion> This statement talks about an individual named Maryexplicitly represented. They normally refer to objects of the world and states that this individual is a person. More technically, being a person is expresseddescribe them e.g. by stating thatputting them into categories (like “Mary is female”) or saying something about their relation (“John and Mary belongs to (or "is a member of" or, even more technically, "is an instance of") the class ofare married”). All persons.atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities. In generalOWL 2, we denote objects as individuals, categories as classes and relations as properties. Properties in OWL 2 are usedfurther subdivided. Object properties relate objects to group individuals that have something in common in orderobjects (like a person to refertheir spouse), while datatype properties assign data values to them. Consequently, we can use the same type of statementobjects (like an age to indicate that Mary isa woman by expressing that she isperson). Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an instanceaxiom) instead of the classdomain of women: ClassAssertion( f:Woman f:Mary ) <f:Woman rdf:about="#Mary"/> f:Mary rdf:type f:Womaninterest.
As a central feature of OWL, names of entities can be combined into expressions using so called constructors. Individual: Mary Types: Woman <owl:ClassAssertion> <owl:Class IRI="&f;Woman"/> <owl:NamedIndividual IRI="&f;Mary"/> </owl:ClassAssertion> Hereby it also becomes clear that class membership is not exclusive:As there maya basic example, the atomic classes “female” and “professor” could be diverse criteria to group individuals (like gender, age, shoe size, etc.), one individual may well belongcombined conjunctively to several classes simultaneously. 3.2 Class Hierarchies In the previous section, we were talking about two classes:describe the class of all persons and that of all women. Tofemale professors. The human reader it is clear that these two classes are in a special relationship: Person is more general than Woman, meaning that whenever we know some individual tolatter would be a woman, it mustdescribed by an OWL class expression, that could be a person. However,used in statements or in other expressions. In this correspondence cannotsense, expressions can be derived fromseen as new entities which are defined by their structure. In OWL, the labels "Person"constructors for each sort of entity vary greatly. The expression language for classes is very rich and "Woman" butsophisticated, whereas the expression language for properties is partmuch less so. These differences have historical as well as technical reasons.
After these general considerations, we now engage in the details of modeling with OWL 2. In the human background knowledge aboutsubsequent sections, we introduce the worldessential modeling features that OWL 2 offers, provide examples and our usage of those terms. Therefore,give some general comments on how to use them. We proceed from basic features, which are essentially available in orderany modeling language, to enablemore advanced constructs.
Thereby we will represent information about a system to draw the desired conclusions, it hasparticular family. Note that we do not
intend this example to be informed about this corresondency. Inrepresentative of the sorts of domains OWL 2, this is done byshould be used
for, or as a so-called subclass axiom: SubClassOf( f:Woman f:Person ) <owl:Class rdf:about="#Woman"> <rdfs:subClassOf rdf:resource="#Person"/> </owl:Class> f:Woman rdfs:subClassOf f:Person . Class: Woman SubClassOf: Person <owl:SubClassOf> <owl:Class IRI="&f;Woman"/> <owl:Class IRI="&f;Person"/> </owl:SubClassOf> The presencecanonical example of this axiom in an ontology enables reasoners to infer for every individual that is specified as an instancegood modeling with OWL, or a correct representation
of the class Woman, that is an instancerather complex, shifting, and culturally dependent domain of the class Person as well. Asfamilies. Instead,
we intend it to be a rulerather simple exhibition of thumb, a subclass relationship between twovarious features of OWL.
We start by introducing the persons we are talking about. This can be specified, if the phrase "every A is a B" makes sensedone as follows:
ClassAssertion( :Person :Mary )
<Person rdf:about="Mary"/>
:Mary rdf:type :Person .
Individual: Mary Types: Person
<ClassAssertion> <Class IRI="Person"/> <NamedIndividual IRI="Mary"/> </ClassAssertion>
This statement talks about an individual named Mary and states that this individual is correct. Ita person. More technically, being a person is common in ontological modelling to use subclass statements not only for sporadically declaring such interdependencies, but to model whole class hierarchiesexpressed by specifyingstating that Mary belongs to (or “is a member of” or, even more technically, “is an instance of”) the generalization relationshipsclass of all persons.
In general classes are used to group individuals that have something in common in order to refer to them. Hence, classes essentially represent sets of individuals. In modeling, classes are often used to denote the domainset of interest. Supposeobjects comprised by a concept of human thinking, like the concept person or the concept woman.
Consequently, we also wantcan use the same type of statement to stateindicate that all mothers areMary is a woman by expressing that she is an instance of the class of women:
ClassAssertion( :Woman :Mary )
<Woman rdf:about="Mary"/>
:Mary rdf:type :Woman .
Individual: Mary Types: Woman
<ClassAssertion> <Class IRI="Woman"/> <NamedIndividual IRI="Mary"/> </ClassAssertion>
Hereby it isalso reflexive , meaningbecomes clear that everyclass membership is its own subclass - this is intuitivenot exclusive: as well since clearly, every person is a person etc. Two classes can alsothere may be saiddiverse criteria to be equivalentgroup individuals
(like gender, age, shoe size, etc.), one individual may well belong to several classes simultaneously.
In the sense that they contain exactly the same individuals. The following example states thatprevious section, we were talking about two classes: the class Person is equivalentof all persons and that of all women. To the class Human. EquivalentClasses( f:Person f:Human ) <owl:Class rdf:about="#Person"> <owl:equivalentClass rdf:resource="#Human"/> </owl:Class> f:Person owl:equivalentClass f:Human . Class: Person EquivalentTo:human <owl:EquivalentClasses> <owl:Class IRI="&f;Person"/> <owl:Class IRI="&f;Human"/> </owl:EquivalentClasses> Statingreader it is clear that Person and Humanthese two classes are equivalent amounts exactly to the same as stating that both Person isin a subclass of Human and Humanspecial relationship: Person is a subclass of Person. 3.3 Class Disjointness In Section 4.3,more general than Woman, meaning that whenever we statedknow some individual to be a woman, that anindividual canmust be an instance of several classes. However consideringa person. However, this correspondence cannot be derived from the classes Manlabels “Person” and Woman, it can be excluded that there is an individual that is an instance of both classes (for the sake of the example, we disregard biological borderline cases). This "incompatibility relationship" between classes is referred to as (class) disjointness . Again, the information that two classes are disjoint“Woman” but is part of ourthe human background knowledge about the world and hasour usage of those terms. Therefore, in order to be explicitly stated forenable a reasoningsystem to make use of it.draw the desired conclusions, it has to be informed about this correspondence. In OWL 2, this is done as follows: DisjointClasses( f:Woman f:Manby a so-called subclass axiom:
SubClassOf( :Woman :Person )
<owl:Classrdf:about="#Man"/></owl:members></owl:AllDisjointClasses>_:xrdf:typeowl:AllDisjointClasses ;owl:members(f:Womanf:Man)rdf:about="Woman"> <rdfs:subClassOf rdf:resource="Person"/> </owl:Class>
:Woman rdfs:subClassOf :Person .
Class: WomanMan<owl:DisjointClasses><owl:ClassIRI="&f;Woman"/><owl:ClassIRI="&f;Man"/></owl:DisjointClasses>Inpractice,disjointnessstatementsareoftenforgottenorneglected.SubClassOf: Person
<SubClassOf> <Class IRI="Woman"/> <Class IRI="Person"/> </SubClassOf>
The arguable reason forpresence of this could be that intuitively, classes are considered disjoint unless there is other evidence. By omitting disjointness statements, many potentially useful consequences can get lost. Note that in our example, the disjointnessaxiom is neededin an ontology enables reasoners to deduceinfer for every individual which is specified as an instance of the class Woman, that Maryit is not a man. Moreover, givenan instance of the above axioms,class Person as well. As a reasoner can infer the disjointnessrule of thethumb, a subclass relationship between two classes MotherA and Man. 3.4 Object Properties InB can be specified, if the preceding sections we were concerned with describing single individuals, their class memberships,phrase “every A is a B” makes sense and how classes can relateis correct.
It is common in ontological modeling to each other based on their instances.use subclass statements not only for sporadically declaring such interdependencies, but more often than not, an ontology is also meantto specify howmodel whole class hierarchies by specifying the individuals relate to other individuals. Obviously thosegeneralization relationships are central when describing a family.of all classes
in the domain of interest. Suppose we start by indicatingalso want to state that Mary is John's wife. PropertyAssertion( f:hasWife f:John f:Maryall mothers are women:
SubClassOf( :Mother :Woman )
<owl:Class rdf:about="Mother"> <rdfs:subClassOf rdf:resource="Woman"/> </owl:Class>
:Mother rdfs:subClassOf :Woman .
Class: Mother SubClassOf: Woman
<SubClassOf> <Class IRI="Mother"/> <Class IRI="Woman"/> </SubClassOf>
Then a reasoner could not only derive for every single individual that is classified as mother, that it is also a woman (and consequently a person), but also that Mother must be a subclass of Person – coinciding with our case, are called properties. Noteintuition. Technically, this means that the order in which the individuals are written downsubclass relationship between classes is important. While "Marytransitive. Besides this, it is John's wife" might be true, "Johnalso reflexive, meaning that every class is Mary's wife" certainly isn't. Indeed,its own subclass – this is a common source of modeling errors. Likewise, itintuitive as well since clearly, every person is importanta person etc.
Classes in our vocabulary may effectively refer to use property namesthe same sets, and
OWL provides a mechanism by which allow only one unique intuitive reading. In case of nouns (like “wife”), such unambiguous names mightto they are considered to be
constructions with “of” or with “has” (wifeOf or hasWife).semantically equivalent. For verbs (like “to love”) an inflected form (loves) or a passive version with “by” (lovedBy) would prevent unintended readings.example, we can also stateuse the term Person and Human
interchangeably, meaning that every instance of the class Person is also
an instance of class Human, and vice versa. Two individualsclasses are not connected by a property.considered equivalent if they contain exactly the following, for example,same individuals. The following example states that Marythe class Person is not Jack's wife. NegativeObjectPropertyAssertion( f:hasWife f:Jack f:Maryequivalent to the class Human.
EquivalentClasses( :Person :Human )
<owl:Class rdf:about="Person"> <owl:equivalentClass rdf:resource="Human"/> </owl:Class>
:Person owl:equivalentClass :Human .
Class: Person EquivalentTo: Human
<EquivalentClasses> <Class IRI="Person"/> <Class IRI="Human"/> </EquivalentClasses>
Stating that Person and Human are equivalent amounts exactly to the same as stating that both Person is a subclass of Human and Human is a subclass of Person.
In Section 4.24.1, we argued that it is useful to specifystated that an individual can be an instance of several classes. However, in some cases membership in one class
specifically excludes membership implies another one. Essentiallyin another. For example, considering the same situationclasses Man and Woman, it can occur for properties: whenever B is known tobe A's wife, itexcluded that there is also known to be A's spouse (note,an individual that thisis not truean instance of both classes (for the other way round). OWL allows to specifysake of the example, we disregard biological borderline cases). This statement“incompatibility relationship” between classes is referred to as follows: SubPropertyOf( f:hasWife f:hasSpouse ) <owl:ObjectProperty rdf:about="#hasWife"> <rdfs:subPropertyOf rdf:resource="#hasSpouse"/> </owl:ObjectProperty> f:hasWife rdfs:subPropertyOf f:hasSpouse(class) disjointness. ObjectProperty: hasWife SubPropertyOf: hasSpouse <owl:SubObjectPropertyOf> <owl:ObjectProperty IRI="&f;hasWife"/> <owl:ObjectProperty IRI="&f;hasSpouse"/> </owl:SubObjectPropertyOf> Similarly, the subproperty relationship can also be stated for datatype properties (and for annotation properties). There is also a syntactic shortcut for property equivalence, which is similar to class equivalence. 3.6 Domain and Range Restrictions Frequently,Again, the information that two individualsclasses are interconnected by a certain property allows to draw further conclusions about the individuals themselves. In particular, one might infer class memberships. For instance, the statement that Bdisjoint is the wifepart of A obviously implies that B is a woman while A is a man. So in a way, the statement that two individuals are related via a certain property carries implicit additional information about those individuals. Inour example, this additional information canbackground knowledge and has to be expressed via class memberships. OWL providesexplicitly stated for a wayreasoning system to statemake use of it. This correspondence: PropertyDomain( f:hasWife f:Man ) PropertyRange( f:hasWife f:Womanis done as follows:
DisjointClasses( :Woman :Man )
<owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class&f;Man"/></owl:ObjectPropertyDomain><owl:ObjectPropertyRange><owl:ObjectPropertyIRI="&f;hasWife"/>rdf:about="Woman"/> <owl:ClassIRI="&f;Woman"/></owl:ObjectPropertyRange>Havingthesetwoaxiomsrdf:about="Man"/> </owl:members> </owl:AllDisjointClasses>
[] rdf:type owl:AllDisjointClasses ; owl:members ( :Woman :Man ) .
DisjointClasses: Woman Man
<DisjointClasses> <Class IRI="Woman"/> <Class IRI="Man"/> </DisjointClasses>
In place and given e.g.practice, disjointness statements are often forgotten or neglected. The informationarguable reason for this could be that Sashaintuitively, classes are considered disjoint unless there is related to Hillary viaother evidence. By omitting disjointness statements, many potentially useful consequences can get lost. Note that in our example, the property hasWife, a reasoner would be abledisjointness axiom is needed to inferdeduce that SashaMary is not a man and Hillaryman. Moreover, given the above axioms, a woman. 3.7 Equality and Inequality of Individuals Note that from the information given so far, itreasoner can be deduced that John and Mary are notinfer the same as they are known to be instancesdisjointness of the disjointclasses Man and Woman, respectively. However, if we add information about another family member, say Bill, and indicate that he is a man, there is nothing said so far that implies that JohnMother and Bill are not the same. OWL does not make the assumption that different names are names for different individuals. (This "unique names assumption" would be particularly dangerousMan.
In the Semantic Web, where names may be coined by different organizations at different times unknowingly referring to the same individual.) Hence, ifpreceding sections we want to exclude the option of Johnwere concerned with describing single individuals, their class memberships, and Bill being the same individual, this hashow classes can relate to be explicitly specified as follows: DifferentIndividuals( f:John f:Bill ) <rdf:Description rdf:about="#John"> <owl:differentFrom rdf:resource="#Bill"/> </rdf:Description> f:John owl:differentFrom f:Bill . Individual: John DifferentFrom: Bill <owl:DifferentIndividuals> <owl:NamedIndividual IRI="&f;John"/> <owl:NamedIndividual IRI="&f;Bill"/> </owl:DifferentIndividuals> Iteach other based on their instances. But more often than not, an ontology is also possible to state that two names refermeant to (denote)specify how the same individual. For example,individuals relate to other individuals. These relationships are central when describing a family. We can saystart by indicating that John and Jack are the same individual. SameIndividual( f:John f:JackMary is John's wife.
ObjectPropertyAssertion( :hasWife :John :Mary )
<rdf:Descriptionrdf:about="#John"><owl:sameAsrdf:resource="#Jack"/>rdf:about="John"> <hasWife rdf:resource="Mary"/> </rdf:Description>
:John :hasWife :Mary .
Individual: JohnSameAs:Jack<owl:SameIndividual><owl:NamedIndividualIRI="&f;John"/><owl:NamedIndividualIRI="&f;Jack"/></owl:SameIndividual>ThiswouldenableareasonertoinferanyinformationaboutFacts: hasWife Mary
<ObjectPropertyAssertion> <ObjectProperty IRI="hasWife"/> <NamedIndividual IRI="John"/> <NamedIndividual IRI="Mary"/> </ObjectPropertyAssertion>
Hereby, the individual Jack which is written down forentities describing in which way the individual John. 3.8 Datatypes So far, we have seen how we can describeindividuals via class memberships and via their relatedness to other individuals.are related – like hasWife in many cases, however,our case, are called properties.
Note that the order in which the individuals are towritten is important. While “Mary is John's wife” might be described by data values. Think of a person's birth date, his age, his email address etc. Fortrue, “John is Mary's wife” certainly isn't. Indeed, this purpose, OWL provides another kindis a common source of properties, so-called Datatype properties . These propertiesmodeling errors that can be avoided by using property names which allow to relate individuals to data values (insteadonly one unique intuitive reading.
In case of to other individuals). The following isnouns (like “wife”), such unambiguous names might be constructions with “of” or with “has” (wifeOf or hasWife). For verbs (like “to love”) an example usinginflected form (loves) or a datatype property. It states that John's age is 51. PropertyAssertion( f:hasAge f:John "51"^^xsd:integer ) <f:Person rdf:about="#John"> <f:hasAge rdf:datatype=" http://www.w3.org/2001/XMLSchema#integer ">51</hasAge> </f:Person> f:John f:hasAge "51"^^xsd:integer . Individual: John Facts: hasAge "51"^^xsd:integer <owl:DataPropertyAssertion> <owl:DataProperty IRI="&f;hasAge"/> <owl:NamedIndividual IRI="&f;John"/> <owl:Literal datatypeIRI=" http://www.w3.org/2001/XMLSchema#integer ">51</owl:Literal> </owl:ataPropertyAssertion> Likewise,passive version with “by” (lovedBy) would prevent unintended readings.
We can also state that Jack's agetwo individuals are not connected by a property. The following, for example, states that Mary is not 53. NegativeDataPropertyAssertion( f:hasAge f:Jack "53"^^xsd:integerBill's wife.
NegativeObjectPropertyAssertion( :hasWife :Bill :Mary )
<owl:NegativePropertyAssertion> <owl:sourceIndividualrdf:about="#Jack"/>rdf:about="Bill"/> <owl:assertionPropertyrdf:about="#hasAge"/><owl:targetValuerdf:datatype="http://www.w3.org/2001/XMLSchema#integer">53</owl:targetValue>rdf:about="hasWife"/> <owl:targetIndividual rdf:about="Mary"/> </owl:NegativePropertyAssertion>
[] rdf:type owl:NegativePropertyAssertion ; owl:sourceIndividualf:Jack ;:Bill ; owl:assertionPropertyf:hasAge ;owl:targetValue"53"^^xsd:integer:hasWife ; owl:targetIndividual :Mary .
Individual:JackBill Facts: nothasAge"53"^^xsd:integer<owl:NegativeDataPropertyAssertion><owl:DataPropertyIRI="&f;hasAge"/><owl:NamedIndividualIRI="&f;Jack"/><owl:LiteraldatatypeIRI="http://www.w3.org/2001/XMLSchema#integer">53</owl:Literal></owl:NegativeDataPropertyAssertion>Domainandrangecanalsobestatedfordatatypepropertiesasitisdoneforobjectproperties.Inthatcase,however,therangewillbehasWife Mary
<NegativeObjectPropertyAssertion> <ObjectProperty IRI="hasWife"/> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="Mary"/> </NegativeObjectPropertyAssertion>
Negative property assertions provide a datatype instead of a class. The following states that the hasAge property is only usedunique opportunity to relate persons with non-negative integers. PropertyDomain( f:hasAge f:Person ) PropertyRange( f:hasAge xsd:NonNegativeInteger ) <owl:DatatypeProperty rdf:about="#hasAge"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:datatpye="&xsd;NonNegativeInteger"/> </owl:DatatypeProperty> f:hasAge rdfs:domain f:Person ; rdfs:range xsd:NonNegativeInteger . DatatpyeProperty: hasAge Domain: Person Range: xsd:NonNegativeInteger <owl:DatatypePropertyDomain> <owl:DatatypeProperty IRI="&f;hasAge"/> <owl:Class IRI="&f;Person"/> </owl:DatatypePropertyDomain> <owl:DatatypePropertyRange> <owl:DatatypeProperty IRI="&f;hasAge"/> <owl:Datatype IRI="&xsd;NonNegativeInteger"/> </owl:DatatypePropertyRange>make
statements where we would like to point out atknow something that is not true. This stage a common mistake which easily occurs when using property domains and ranges.kind of
information is particularly important in OWL where the example just given, which statesdefault stance is
that the hasAgeanything is possible until you say otherwise.
In Section 4.2 we argued that it is only useduseful to relate persons with non-negative integers, assume that we alsospecify the informationthat Felix is in theone class Cat and that Felix hasAge 9. Frommembership implies another one. Essentially the combined information, it would then be possiblesame situation can occur for properties: whenever B is known to deduce that Felixbe A's wife, it is also in the class Person, whichknown to be A's spouse (note, that this is probablynot intended.true the other way round). OWL allows to specify this is a commonly modelling error: note that a domain (or range)statement as follows:
SubObjectPropertyOf( :hasWife :hasSpouse )
<owl:ObjectProperty rdf:about="hasWife"> <rdfs:subPropertyOf rdf:resource="hasSpouse"/> </owl:ObjectProperty>
:hasWife rdfs:subPropertyOf :hasSpouse .
ObjectProperty: hasWife SubPropertyOf: hasSpouse
<SubObjectPropertyOf> <ObjectProperty IRI="hasWife"/> <ObjectProperty IRI="hasSpouse"/> </SubObjectPropertyOf>
There is notalso a constraint onsyntactic shortcut for property equivalence, which is similar to class equivalence.
Frequently, the knowledge, butinformation that two individuals are interconnected by a certain property allows to inferdraw further knowledge. If we state - asconclusions about the individuals themselves. In our example -particular, one might infer class memberships. For instance, the statement that an ageB is only given for persons, then everything we give an age for automatically becomesthe wife of A person. 4 Advanced Class Relationshipsobviously implies that B is a woman while A is a man. So in a way, the previous sections we have dealt with classes as something "opaque" carryingstatement that two individuals are related via a name. We used themcertain property carries implicit additional information about these individuals. In our example, this additional information can be expressed via class memberships. OWL provides a way to characterize individuals,state this correspondence:
ObjectPropertyDomain( :hasWife :Man ) ObjectPropertyRange( :hasWife :Woman )
<owl:ObjectProperty rdf:about="hasWife"> <rdfs:domain rdf:resource="Man"/> <rdfs:range rdf:resource="Woman"/> </owl:ObjectProperty>
:hasWife rdfs:domain :Man ; rdfs:range :Woman .
ObjectProperty: hasWife Domain: Man Range: Woman
<ObjectPropertyDomain> <ObjectProperty IRI="hasWife"/> <Class IRI="Man"/> </ObjectPropertyDomain> <ObjectPropertyRange> <ObjectProperty IRI="hasWife"/> <Class IRI="Woman"/> </ObjectPropertyRange>
Having these two axioms in place and given e.g. the information that Sasha is related themto other classesHillary via subclass or disjointness statements. We will now demonstrate how named classes, properties,the property hasWife, a reasoner would be able to infer that Sasha is a man and Hillary a woman.
Note that from the information given so far, it can be useddeduced that John and Mary are not the same individual as building blocksthey are known to define new classes. 4.1 Complex Classesbe instances of the language elements describeddisjoint classes Man and Woman, respectively. However, if we add information about another family member, say Bill, and indicate that he is a man, then there is nothing said so far allow to model simple ontologies. But their expressivity hardly surpassesthat of RDFS. In order to express more complex knowledge, OWL provides logical class constructors. In particular, OWL provides language elements for logical and, or,implies that John and not.Bill are not the correspondingsame. OWL termsdoes not make the assumption that different names are borrowed from set theory: (class) intersection , union and complement . These constructors allow to combine atomic classes – i.e. classes withnames –for different individuals. (This lack of a required “unique names assumption” is particularly well-suited to complex classes. Those class expressions canSemantic Web applications where names may be used anywhere The intersection of two classes consists of exactly those individuals which are instances of both classes.coined by different organizations at different times unknowingly referring to the following example states thatsame individual.) Hence, if we want to exclude the class Mother consists of exactly those objects which are instancesoption of both WomanJohn and Parent: EquivalentClasses( f:Mother IntersectionOf( f:Woman f:Parent ) ) <owl:Class rdf:about="#Mother"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Woman"/> <owl:Class rdf:about="#Parent"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> f:Mother owl:equivalentClass _:x . _:x rdf:type owl:Class ; owl:intersectionOf ( f:Woman f:ParentBill being the same individual, this has to be explicitly specified as follows:
DifferentIndividuals( :John :Bill )
<rdf:Description rdf:about="John"> <owl:differentFrom rdf:resource="Bill"/> </rdf:Description>
:John owl:differentFrom :Bill .
Individual: John DifferentFrom: Bill
<DifferentIndividuals> <NamedIndividual IRI="John"/> <NamedIndividual IRI="Bill"/> </DifferentIndividuals>
It is also possible to state that all instances oftwo names refer to (denote) the class Mothersame individual. For example, we can say that John and Jack are also in the class Parent.the union of two classes contains every individual which is contained in one of these classes. Therefore we could characterize the class of all parents as the union of the classes Mother and Father: EquivalentClasses( f:Parent UnionOf( f:Mother f:Father ) ) <owl:Class rdf:about="#Parent"> <owl:equivalentClass> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Mother"/> <owl:Class rdf:about="#Father"/> </owl:unionOf> </owl:Class> </owl:equivalentClass> </owl:Class> f:Parent owl:equivalentClass _:x . _:x rdf:type owl:Class ; owl:unionOf ( f:Mother f:Fathersame individual.
SameIndividual( :James :Jim )
<rdf:Description rdf:about="James"> <owl:sameAs rdf:resource="Jim"/> </rdf:Description>
:James owl:sameAs :Jim.
Individual: James SameAs: Jim
<SameIndividual> <NamedIndividual IRI="James"/> <NamedIndividual IRI="Jim"/> </SameIndividual>
This would enable a class correspondsreasoner to logical negation: it consists of exactly those objects which are not members of the class itself. The following definition of childless persons uses the class complement and demonstratesinfer that class constructors can be nested: EquivalentClasses( f:ChildlessPerson IntersectionOf( f:Person ComplementOf( f:Parent ) ) ) <owl:Class rdf:about="#ChildlessPerson"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Person"/> <owl:Class> <owl:complementOf rdf:resource="#Parent"/> </owl:Class> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> f:ChildlessPerson owl:equivalentClass _:x . _:x rdf:type owl:Class ; owl:intersectionOf ( f:Person _:y ) . _:y owl:complementOf f:Parent . Class: ChildlessPerson EquivalentTo: Person and not Parent <owl:EquivalentClasses> <owl:Class IRI="&f;ChildlessPerson"/> <owl:ObjectIntersectionOf> <owl:Class IRI="&f;Person"/> <owl:ObjectComplementOf> <owl:Class IRI="&f;Parent"/> </owl:ObjectComplementOf> </owl:ObjectIntersectionOf> </owl:EquivalentClasses> Allany information given about the above examples demonstrateindividual James also holds for the usage ofindividual Jim.
So far, we have seen how we can describe individuals via class constructorsmemberships and via their relatedness to other individuals. In ordermany cases, however, individuals are to define new classes as combination as others. But,be described by data values. Think of course, it is also possible to use class constructors together witha subclass statement in order to indicate necessary, but not sufficient conditionsperson's birth date, his age, his email address etc.
For a class.this purpose, OWL provides another kind of properties, so-called Datatype properties. These properties relate individuals to data values (instead of to other individuals). The following statement indicates that every Fatheris both a man andan example using a parent (whereas the conversedatatype property. It states that John's age is not necessarily true): SubClassOf( f:Father IntersectionOf( f:Man f:Parent ) ) <owl:Class rdf:about="#Father"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Man"/> <owl:Class rdf:about="#Parent"/> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> f:Father rdfs:subClassOf _:x . _:x rdf:type owl:Class ; owl:intersectionOf ( f:Man f:Parent51.
DataPropertyAssertion( :hasAge :John "51"^^xsd:integer )
<Person rdf:about="John"> <hasAge rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">51</hasAge> </Person>
:John :hasAge 51 .
Individual: John Facts: hasAge "51"^^xsd:integer
<DataPropertyAssertion> <DataProperty IRI="hasAge"/> <NamedIndividual IRI="John"/> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">51</Literal> </DataPropertyAssertion>
Likewise, we can occur, hence also in class assertions: ClassAssertion( IntersectionOf( f:Person ComplementOf( f:Parent ) ) f:John ) <rdf:Description rdf:about="#John"> <rdf:type> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Person"/> <owl:Class> <owl:complementOf rdf:about="#Parent"/> </owl:Class> </owl:intersectionOf> </owl:Class> </rdf:type> </rdf:Description> f:John rdf:type _:x1 . _:x1 rdf:type owl:Class ; owl:intersectionOf ( f:Person _:x2state that Jack's age is not 53.
NegativeDataPropertyAssertion( :hasAge :Jack "53"^^xsd:integer )
<owl:NegativePropertyAssertion> <owl:sourceIndividual rdf:about="Jack"/> <owl:assertionProperty rdf:about="hasAge"/> <owl:targetValue rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"> 53 </owl:targetValue> </owl:NegativePropertyAssertion>
[] rdf:typeowl:Class ;owl:complementOff:Parentowl:NegativePropertyAssertion ; owl:sourceIndividual :Jack ; owl:assertionProperty :hasAge ; owl:targetValue 53 .
Individual:JohnTypes:PersonandJack Facts: notParent<owl:ClassAssertion><owl:ObjectIntersectionOf><owl:ClassIRI="&f;Person"/><owl:ObjectComplementOf><owl:ClassIRI="&f;Parent"/></owl:ObjectComplementOf></owl:ObjectIntersectionOf><owl:NamedIndividualIRI="&f;John"/></owl:ClassAssertion>4.2PropertyRestrictionsBypropertyrestrictionsweunderstandanothertypeoflogic-basedconstructorshasAge "53"^^xsd:integer
<NegativeDataPropertyAssertion> <DataProperty IRI="hasAge"/> <NamedIndividual IRI="Jack"/> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">53</Literal> </NegativeDataPropertyAssertion>
Domain and range can also be stated for complex classes.datatype properties as the name suggests, property restrictions are constructors involvingit is done for object properties. The first property restriction called existential quantification defines a class as the set of all individualsIn that are connected viacase, however, the range will be a particular property to another individual which is an instancedatatype instead of a certainclass. This is best explained by an example, likeThe following which defines the class of parents as the class of individualsstates that are linked to a person bythe hasChild property. EquivalentClasses( f:Parent SomeValuesFrom( f:hasChild f:PersonhasAge property is only used to relate persons with non-negative integers.
DataPropertyDomain( :hasAge :Person ) DataPropertyRange( :hasAge xsd:NonNegativeInteger )
<owl:DatatypeProperty rdf:about="hasAge"> <rdfs:domain rdf:resource="Person"/> <rdfs:range rdf:datatpye="http://www.w3.org/2001/XMLSchema#NonNegativeInteger"/> </owl:DatatypeProperty>
:hasAge rdfs:domain :Person ; rdfs:range xsd:NonNegativeInteger .
DatatpyeProperty: hasAge Domain: Person<owl:EquivalentClasses><owl:ClassIRI="&f;Parent"/><owl:ObjectSomeValuesFrom><owl:ObjectPropertyIRI="&f;hasChild"/><owl:ClassIRI="&f;Person"/></owl:ObjectSomeValuesFrom></owl:EquivalentClasses>AnotherRange: xsd:NonNegativeInteger
<DatatypePropertyDomain> <DatatypeProperty IRI="hasAge"/> <Class IRI="Person"/> </DatatypePropertyDomain> <DatatypePropertyRange> <DatatypeProperty IRI="hasAge"/> <Datatype IRI="http://www.w3.org/2001/XMLSchema#NonNegativeInteger"/> </DatatypePropertyRange>
We would like to point out at this stage a common mistake which easily occurs when using property domains and ranges. In the example just given, which states that the hasAge property restriction, called universal quantificationis only used to describe a class of individuals for which all "property-successors" are instances of a given class.relate persons with non-negative integers, assume that we can usealso specify the following statement to indicateinformation that a personFelix is happy exactly if all their children are happy. EquivalentClasses( Intersection( f:Person f:Happy ) AllValuesFrom( f:hasChild f:Happy ) ) <owl:Class> <owl:intersectionOf> <owl:Class rdf:about="#Person"/> <owl:Class rdf:about="#Happy"/> </owl:intersectionOf> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:about="#hasChild"/> <owl:allValuesFrom rdf:about="#Happy"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> _:x1 owl:equivalentClass _:x2 . _:x1 rdf:type owl:Class ; owl:intersectionOf f:Person , f:Happy . _:x2 rdf:type owl:Restriction ; owl:onProperty f:hasChild ; owl:allValuesFrom f:Happy . Class: X EquivalentTo: Personin the class Cat and Happy Class: X EquivalentTo: hasChild all Happy <owl:EquivalentClasses> <owl:ObjectIntersectionOf> <owl:Class IRI="&f;Person"/> <owl:Class IRI="&f;Happy"/> </owl:ObjectIntersectionOf> <owl:ObjectAllValuesFrom> <owl:ObjectProperty IRI="&f;hasChild"/> <owl:Class IRI="&f;Happy"/> </owl:ObjectAllValuesFrom> </owl:EquivalentClasses>that Felix hasAge 9. From the usage of property restrictions may cause some conceptual confusioncombined information, it would then be possible to “modeling beginners.” Asdeduce that Felix is also in the class Person, which is probably not intended. This is a rule of thumb, when translatingcommonly modeling error: note that a natural languagedomain (or range) statement intois not a logical axiom, existential quantification occurs far more frequently. Natural language indicators for the usage of universal quantification are words like “only,” “exclusively,” or “nothing but.” There is one particular misconception concerningconstraint on the universal role restriction.knowledge, but allows a reasoner to infer further knowledge. If we state – as an example, consider the above happiness axiom. The intuitive reading suggests thatin order to be happy, a person must have at least one happy child. Yet, this is not the case: any individualour example – that an age is not the "starting point" of the property hasChild is class member of anyonly given for persons, then everything we give an age for automatically becomes a person.
In order to formalize the aforementioned intended reading,the statement wouldprevious sections we have to read as follows: EquivalentClasses( Intersection( f:Person f:Happy ) Intersection( ObjectAllValuesFrom( f:hasChild f:Happy ) ObjectSomeValuesFrom( f:hasChild f:Happy ) ) ) <owl:Class> <owl:intersectionOf> <owl:Class rdf:about="#Person"/> <owl:Class rdf:about="#Happy"/> </owl:intersectionOf> <owl:equivalentClass> <owl:Class> <owl:intersectionOf> <owl:Restriction> <owl:onProperty rdf:about="#hasChild"/> <owl:allValuesFrom rdf:about="#Happy"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:about="#hasChild"/> <owl:someValuesFrom rdf:about="#Happy"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> _:x1 owl:equivalentClass _:x2 . _:x1 rdf:type owl:Class ; owl:intersectionOf f:Person , f:Happy . _:x2 rdf:type owl:Class ; owl:intersectionOf _:x3 , _:x4 . _:x3 rdf:type owl:Restriction ; owl:onProperty f:hasChild ; owl:allValuesFrom f:Happy . _:x4 rdf:type owl:Restriction ; owl:onProperty f:hasChild ; owl:someValuesFrom f:Happy . Class: X EquivalentTo: Person and Happy Class: X EquivalentTo: hasChild all Happy <owl:EquivalentClasses> <owl:ObjectIntersectionOf> <owl:Class IRI="&f;Person"/> <owl:Class IRI="&f;Happy"/> </owl:ObjectIntersectionOf> <owl:ObjectAllValuesFrom> <owl:ObjectProperty IRI="&f;hasChild"/> <owl:Class IRI="&f;Happy"/> </owl:ObjectAllValuesFrom> </owl:EquivalentClasses> This example also illustrates how property restrictions can be nesteddealt with complex classes. Moreover,classes as something “opaque” carrying a name. We might be interestedused them to describe a class of individuals that arecharacterize individuals, and related them to one particular individual. For instanceother classes via subclass or disjointness statements.
We could define the class of John's children: EquivalentClasses( f:JohnsChildren ObjectHasValue( f:hasParent f:John ) ) missing missing Class: JohnsChildren EquivalentTo: hasParent value John missing As a special case ofwill now demonstrate how named classes, properties, and individuals being interlinkedcan be used as building blocks to define new classes.
By properties, an individual mightmeans of the language elements described so far, simple ontologies can be linkedmodeled. In order to itself. Indeed,express more complex knowledge, OWL provides logical class constructors. In particular, OWL provides language elements for logical and, or, and not. The opportunitycorresponding OWL terms are borrowed from set theory: (class) intersection, union and complement. These constructors combine atomic classes – i.e. classes with names – to e.g. define the class NarcisticPerson ascomplex classes.
The classintersection of two classes consists of exactly those individuals which are instances of both classes. The following example states that the class Mother consists of exactly those objects which are linked to themselves by a loves-property. EquivalentClasses f:NarcisticPerson HasSelf( f:lovesinstances of both Woman and Parent:
EquivalentClasses( :Mother ObjectIntersectionOf( :Woman :Parent ) )
<owl:Classrdf:about="#NarcisticPerson">rdf:about="Mother"> <owl:equivalentClass><owl:Restriction><owl:onPropertyrdf:resource="#loves"/><owl:hasSelfrdf:datatype="&xsd;boolean">true</owl:hasSelf></owl:Restriction><owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Woman"/> <owl:Class rdf:about="Parent"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class>
:Mother owl:equivalentClass_:x._:x[ rdf:typeowl:Restriction ;owl:onPropertyf:loves ;owl:hasSelf"true"^^xsd:booleanowl:Class ; owl:intersectionOf ( :Woman :Parent ) ] .
Class:NarcisticPersonMother EquivalentTo:lovesSelf<owl:EquivalentClasses><owl:ClassIRI="&f;NarcisticPerson"/><owl:ObjectHasSelf><owl:ObjectPropertyIRI="&f;loves"/></owl:ObjectHasSelf></owl:EquivalentClasses>4.3PropertyCardinalityRestrictionsUsingexistentialWoman anduniversalquantification,weParent
<EquivalentClasses> <Class IRI="Mother"/> <ObjectIntersectionOf> <Class IRI="Woman"/> <Class IRI="Parent"/> </ObjectIntersectionOf> </EquivalentClasses>
An example for an inference which can say something aboutbe drawn from this is that all respectively at least oneinstances of somebody's childs.the class Mother are also in a similar way, we can construct classes depending onthe number of childs.class Parent.
The following example states that John has at most four children who are themselves parents: ClassAssertion( MaxCardinality( 4 f:hasChild f:Parentunion of two classes contains every individual which is contained in at least one of these classes. Therefore we could characterize the class of all parents as the union of the classes Mother and Father:
EquivalentClasses( :Parent ObjectUnionOf( :Mother :Father )John)
<owl:Class rdf:about="Parent"> <owl:equivalentClass> <owl:Class><owl:Restriction><owl:maxQualifiedCardinalityrdf:datatype="&xsd;nonNegativeInteger">4</owl:maxQualifiedCardinality><owl:onPropertyrdf:about="#hasChild"/><owl:onClassrdf:about="#Parent"/></owl:Restriction><owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="Mother"/> <owl:Class rdf:about="Father"/> </owl:unionOf> </owl:Class></rdf:type></rdf:Description>f:Johnrdf:type_:x._:x</owl:equivalentClass> </owl:Class>
:Parent owl:equivalentClass [ rdf:typeowl:Restriction ;owl:maxQualifiedCardinality"4"^^xsd:nonNegativeInteger ;owl:onPropertyf:hasChild ;owl:onClassf:Parentowl:Class ; owl:unionOf ( :Mother :Father ) ] .
Class: Parent<owl:ClassAssertion><owl:ObjectMaxCardinalitycardinality="4"><owl:ObjectPropertyIRI="&f;hasChild"/><owl:Class&f;Parent"/></owl:ObjectMaxCardinality><owl:NamedIndividualIRI="&f;John"/></owl:ClassAssertion>NotethatthisstatementallowsJohnEquivalentTo: Mother or Father
<EquivalentClasses> <Class IRI="Parent"/> <ObjectUnionOf> <Class IRI="Mother"/> <Class IRI="Father"/> </ObjectUnionOf> </EquivalentClasses>
The complement of a class corresponds to have arbitrarily many further childrenlogical negation: it consists of exactly those objects which are not parents. Likewise, it is also possible to declare a minimum number by saying that John is an instancemembers of the class itself. The following definition of individuals having at least two childrenchildless persons uses the class complement and also demonstrates that are parents: ClassAssertion( MinCardinality( 2 f:hasChild f:Parentclass constructors can be nested:
EquivalentClasses( :ChildlessPerson ObjectIntersectionOf( :Person ObjectComplementOf( :Parent )f:John)<rdf:Descriptionrdf:about="#John"><rdf:type>)
<owl:Class rdf:about="ChildlessPerson"> <owl:equivalentClass> <owl:Class><owl:Restriction><owl:minQualifiedCardinalityrdf:datatype="&xsd;nonNegativeInteger">2</owl:minQualifiedCardinality><owl:onPropertyrdf:about="#hasChild"/><owl:onClassrdf:about="#Parent"/></owl:Restriction><owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Person"/> <owl:Class> <owl:complementOf rdf:resource="Parent"/> </owl:Class></rdf:type></rdf:Description>f:Johnrdf:type_:x._:x</owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class>
:ChildlessPerson owl:equivalentClass [ rdf:typeowl:Restriction ;owl:minQualifiedCardinality"2"^^xsd:nonNegativeInteger ;owl:onPropertyf:hasChild ;owl:onClassf:Parentowl:Class ; owl:intersectionOf ( :Person [ owl:complementOf :Parent ] ) ] .
Class: ChildlessPerson EquivalentTo: Person and not Parent
<EquivalentClasses> <Class IRI="ChildlessPerson"/> <ObjectIntersectionOf> <Class IRI="Person"/> <ObjectComplementOf> <Class IRI="Parent"/> </ObjectComplementOf> </ObjectIntersectionOf> </EquivalentClasses>
All the above examples demonstrate the usage of class constructors in order to define new classes as follows: ClassAssertion( ExactCardinality( 3 f:hasChild f:Parentcombination of others. But, of course, it is also possible to use class constructors together with a subclass statement in order to indicate necessary, but not sufficient, conditions for a class. The following statement indicates that every Grandfather is both a man and a parent (whereas the converse is not necessarily true):
SubClassOf( :Grandfather ObjectIntersectionOf( :Man :Parent )f:John)
<owl:Class rdf:about="Grandfather"> <rdfs:subClassOf> <owl:Class><owl:Restriction><owl:qualifiedCardinalityrdf:datatype="&xsd;nonNegativeInteger">3</owl:qualifiedCardinality><owl:onPropertyrdf:about="#hasChild"/><owl:onClassrdf:about="#Parent"/></owl:Restriction><owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Man"/> <owl:Class rdf:about="Parent"/> </owl:intersectionOf> </owl:Class></rdf:type></rdf:Description>f:Johnrdf:type_:x._:x</rdfs:subClassOf> </owl:Class>
:Grandfather rdfs:subClassOf [ rdf:typeowl:Restriction ;owl:qualifiedCardinality"3"^^xsd:nonNegativeInteger ;owl:onPropertyf:hasChild ;owl:onClassf:Parentowl:Class ; owl:intersectionOf ( :Man :Parent ) ] .
Class: Grandfather SubClassOf: Man and Parent
<SubClassOf> <Class IRI="Grandfather"/> <ObjectIntersectionOf> <Class IRI="Man"/> <Class IRI="Parent"/> </ObjectIntersectionOf> </SubClassOf>
In a cardinality restriction, providing the class is optional; if we just want to talk about the number of all of John's children wegeneral, complex classes can be used in every place where named classes can occur, hence also writein class assertions. This is demonstrated by the following:following example which asserts that John is a person but not a parent.
ClassAssertion(ExactCardinality(5f:hasChildObjectIntersectionOf( :Person ObjectComplementOf( :Parent )f:John) :John )
<rdf:Descriptionrdf:about="#John">rdf:about="John"> <rdf:type> <owl:Class><owl:Restriction><owl:cardinalityrdf:datatype="&xsd;nonNegativeInteger">5</owl:cardinality><owl:onPropertyrdf:about="#hasChild"/></owl:Restriction><owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Person"/> <owl:Class> <owl:complementOf rdf:about="Parent"/> </owl:Class> </owl:intersectionOf> </owl:Class> </rdf:type> </rdf:Description>
:John rdf:type_:x._:x[ rdf:typeowl:Restriction ;owl:cardinality"5"^^xsd:nonNegativeInteger ;owl:onPropertyf:hasChildowl:Class ; owl:intersectionOf ( :Person [ rdf:type owl:Class ; owl:complementOf :Parent ] ) ] .
Individual: John Types:hasChildexactly5<owl:ClassAssertion><owl:ObjectExactCardinalitycardinality="5"><owl:ObjectPropertyIRI="&f;hasChild"/></owl:ObjectExactCardinality><owl:NamedIndividualIRI="&f;John"/></owl:ClassAssertion>4.4EnumerationofIndividualsAverystraightforwardwaytodescribeaclassisjusttoenumeratePerson and not Parent
<ClassAssertion> <ObjectIntersectionOf> <Class IRI="Person"/> <ObjectComplementOf> <Class IRI="Parent"/> </ObjectComplementOf> </ObjectIntersectionOf> <NamedIndividual IRI="John"/> </ClassAssertion>
Property restrictions provide another type of logic-based constructors for complex classes. As the name suggests, property restrictions use constructors involving properties.
One property restriction called existential quantification defines a class as the set of all its instances. OWL provides this possibility, e.g. we can createindividuals that are connected via a particular property to another individual which is an instance of a certain class. This is best explained by an example, like the following which defines the class of birthday guests:parents as the class of individuals that are linked to a person by the hasChild property.
EquivalentClasses(f:MyBirthdayGuestsOneOf(f:Billf:Johnf:Mary):Parent ObjectSomeValuesFrom( :hasChild :Person ) )
<owl:Classrdf:about="#MyBirthdayGuests">rdf:about="Parent"> <owl:equivalentClass><owl:Class><owl:oneOfrdf:parseType="Collection"><rdf:Descriptionrdf:about="#Bill"/><rdf:Descriptionrdf:about="#John"/><rdf:Descriptionrdf:about="#Mary"/></owl:oneOf></owl:Class<owl:Restriction> <owl:onProperty rdf:resource="hasChild"/> <owl:someValuesFrom rdf:resource="Person"/> </owl:Restriction> </owl:equivalentClass> </owl:Class>
:Parent owl:equivalentClass_:x._:x[ rdf:typeowl:Class ;owl:oneOf(f:Billf:Johnf:Mary).owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] .
Class:MyBirthdayGuestsParent EquivalentTo:{BillJohnMary}<owl:EquivalentClasses><owl:ClassIRI="&f;MyBirthdayGuests"/><owl:ObjectOneOf><owl:NamedIndividualIRI="&f;Bill"/><owl:NamedIndividualIRI="&f;John"/><owl:NamedIndividualIRI="&f;Mary"/></owl:ObjectOneOf></owl:EquivalentClasses>NotethathasChild some Person
<EquivalentClasses> <Class IRI="Parent"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Person"/> </ObjectSomeValuesFrom> </EquivalentClasses>
This axiom provides more information than simply asserting class membershipmeans that there is an expectation that for every instance of
Bill, John,Parent, there exists at least one child, and Mary as described in Section 4.1. In addition to that, it also stipulatesthat Bill, John, and Mary are the only memberschild is a member of
MyBirthdayGuest. Therefore, classes definedthe class Person. This way are sometimes referredis useful to as closed classescapture incomplete
knowledge. If we now assert Jeff as an instance of MyBirthdayGuest, the consequenceFor example, Sally tells us that Bob is a parent,
and therefore we can infer that Jeff must be equal tohe has at least one of the above three persons. 5 Advanced Use of Properties Until now we focussed on classes and properties that were merely used as building blocks for class expressions. In the following,child even if we will see what role-centric modeling capabilities OWL 2 offers. 5.1 Property Characteristics Sometimes one property can be obtained by takingdon't know
their name.
Another property and changing its direction, i.e. inverting it. For example, the property hasParent can be defined as the inverse property of hasChild: InverseProperties( f:hasParent f:hasChild ) <owl:ObjectProperty rdf:about="#hasParent"> <owl:inverseOf rdf:resource="#hasChild"/> </owl:ObjectProperty> f:hasParent owl:inverseOf f:hasChild . ObjectProperty: hasParent InverseOf: hasChild <owl:InverseObjectProperties> <owl:ObjectProperty IRI="&f;hasParent"/> <owl:ObjectProperty IRI="&f;hasChild"/> </owl:InverseObjectProperties> This would for example allow to deduce for arbitrary individuals A and B, where Arestriction, called universal quantification is linked to B by the hasChild property, that B and A are also interlinked by the hasParent property. However, we do not need to explicitly assign a name to the inverse of a property if we just wantused to use it, say, insidedescribe a class expression. Insteadof using the new hasParent propertyindividuals for the definitionwhich all related individuals must be instances of the class Orphan,a given class. We can directly refer to it asuse the hasChild-inverse:following statement to indicate that somebody is a happy person exactly if all their children are happy persons.
EquivalentClasses(f:OrphanAllValuesFrom(InverseOf(f:hasChild:HappyPerson ObjectAllValuesFrom( :hasChild :HappyPerson )f:Dead))
<owl:Class> <owl:Classrdf:about="#Orphan">rdf:about="HappyPerson"/> <owl:equivalentClass> <owl:Restriction><owl:onProperty><owl:ObjectProperty><owl:inverseOfrdf:about="#hasChild"/></owl:ObjectProperty></owl:onProperty><owl:Classrdf:about="#Dead"><owl:onProperty rdf:about="hasChild"/> <owl:allValuesFrom rdf:about="HappyPerson"/> </owl:Restriction> </owl:equivalentClass> </owl:Class>
[] rdf:type owl:Class ; :HappyPerson ; owl:equivalentClass_:x1._:x1[ rdf:type owl:Restriction ; owl:onProperty_:x2 ;:hasChild ; owl:allValuesFromf:Dead._:x2owl:inverseOff:hasChild:Happy ] .
Class:OrphanHappyPerson EquivalentTo:inversehasChildallDead<owl:EquivalentClasses><owl:ClassIRI="&f;Orphan"/><owl:ObjectAllValuesFrom><owl:InverseObjectProperty><owl:ObjectPropertyIRI="&f;hasChild"/></owl:InverseObjectProperty><owl:ClassIRI="&f;Dead"/></owl:ObjectAllValuesFrom></owl:EquivalentClasses>Insomecases,apropertyanditsinversecoincide,orinotherwords,thedirectionofapropertydoesn'tmatter.ForinstancethepropertyhasSpouserelatesAwithBexactlyifitrelatesBwithA.Forobviousreasons,apropertywithonly HappyPerson
<EquivalentClasses> <Class IRI="HappyPerson"/> <ObjectAllValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Happy"/> </ObjectAllValuesFrom> </EquivalentClasses>
This characteristicexample also shows that OWL statements are allowed to by kind of self-referential; the class HappyPerson is called symmetric , which can be specified as follows SymmetricProperty( f:hasSpouse ) <owl:SymmetricProperty rdf:about="#hasSpouse"/> f:hasSpouse rdf:type owl:SymmetricProperty . ObjectProperty: hasSpouse Characteristics: Symmetric <owl:SymmetricObjectProperty> <owl:ObjectProperty IRI="&f;hasSpouse"/> </owl:SymmetricObjectProperty>used on both sides of the other hand, aequivalence statement.
The usage of property can also be asymmetric meaningrestrictions may cause some conceptual confusion to “modeling beginners.” As a rule of thumb, when
translating a natural language statement into a logical axiom, existential quantification occurs far more frequently. Natural language indicators for the usage of universal quantification are words like “only,” “exclusively,” or “nothing but.”
There is one particular misconception concerning the universal role restriction. As an example, consider the above happiness axiom. The intuitive reading suggests that if it connectsin order to be happy, a with B it never connects B with A. Clearly (excluding paradoxical scenarios resulting from time travels),person must have at least one happy child. Yet, this is not the case forcase: any individual that is not a “starting point” of the property hasChild andis expressed like this: AsymmetricProperty( f:hasChild ) <owl:AsymmetricProperty rdf:about="#hasChild"/> f:hasChild rdf:type owl:AsymmetricProperty . ObjectProperty: hasChild Characteristics: Asymmetric <owl:AsymmetricObjectProperty> <owl:ObjectProperty IRI="&f;hasChild"/> </owl:AsymmetricObjectProperty> Previously, we considered subpropertiesclass member of any class defined by universal quantification over hasChild. Hence, by our above statement, every childless person would be qualified as happy. In analogy to subclasses. It turns out that it also make senseorder to transferformalize the notion of class disjointnessaforementioned intended reading, the statement would have to properties: two properties are disjoint if there are no two individuals that are interlinked by both properties. Following common law, we can thus state that parent-child marriages cannot occur: DisjointProperties( f:hasParent f:hasSpouseread as follows:
EquivalentClasses( :HappyPerson ObjectIntersectionOf( ObjectAllValuesFrom( :hasChild :HappyPerson )<rdf:Descriptionrdf:about="#hasParent"><owl:propertyDisjointWithrdf:resource="#hasSpouse"/></rdf:Description>f:hasParentowl:propertyDisjointWithf:hasSpouseObjectSomeValuesFrom( :hasChild :HappyPerson ) ) )
<owl:Class> <owl:Class rdf:about="HappyPerson"/> <owl:equivalentClass> <owl:Class> <owl:intersectionOf parseType="Collection"> <owl:Restriction> <owl:onProperty rdf:about="hasChild"/> <owl:allValuesFrom rdf:about="HappyPerson"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:about="hasChild"/> <owl:someValuesFrom rdf:about="HappyPerson"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class>
[] rdf:type owl:Class ; :HappyPerson ; owl:equivalentClass [ rdf:type owl:Class ; owl:intersectionOf ( [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:allValuesFrom :Happy ] [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Happy ] ) ] .
Class: HappyPerson EquivalentTo: hasChild only HappyPerson and hasChild some HappyPerson
<EquivalentClasses> <Class IRI="HappyPerson"/> <ObjectIntersectionOf> <ObjectAllValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="HappyPerson"/> </ObjectAllValuesFrom> <ObjectSomeValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="HappyPerson"/> </ObjectSomeValuesFrom> </ObjectIntersectionOf> </EquivalentClasses>
This example also illustrates how property restrictions can be reflexive : such anested with complex classes.
Property relates everythingrestrictins can also be used to itself.describe classes of individuals that are related to one particular individual. For instance we could define the following example, note that everybody has himself as a relative. ReflexiveProperty( f:hasRelativeclass of John's children:
EquivalentClasses( :JohnsChildren ObjectHasValue( :hasParent :John )<owl:ReflexivePropertyrdf:about="f:hasRelative"/>f:hasRelative)
<owl:Class rdf:about="JohnsChildren"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="hasParent"/> <owl:hasValue rdf:resource="John"/> </owl:Restriction> </owl:equivalentClass> </owl:Class>
:JohnsChildren owl:equivalentClass [ rdf:typeowl:ReflexivePropertyowl:Restriction ; owl:onProperty :hasParent ; owl:hasValue :John ] .
Class: JohnsChildren EquivalentTo: hasParent value John
<EquivalentClasses> <Class IRI="JohnsChildren"/> <ObjectHasValue> <ObjectProperty IRI="hasParent"/> <Class IRI="John"/> </ObjectHasValue> </EquivalentClasses>
As a special case of individuals which are relatedbeing interlinked by a reflexive property are identical. Properties can furthermore be irreflexive , meaning that noproperties, an individual canmight be relatedlinked to itself by such a role. A typical example isitself. The following which simply statesexample shows how to represent the idea that nobody can be his own parent. IrreflexiveProperty( f:parentOfall narcissists love themselves.
EquivalentClasses( :NarcisticPerson ObjectHasSelf( :loves )<owl:IrreflexivePropertyrdf:about="#parentOf"/>f:parentOf)
<owl:Class rdf:about="NarcisticPerson"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="loves"/> <owl:hasSelf rdf:datatype="&xsd;boolean"> true </owl:hasSelf> </owl:Restriction> </owl:equivalentClass> </owl:Class>
:NarcisticPerson owl:equivalentClass [ rdf:typeowl:IrreflexivePropertyowl:Restriction ; owl:onProperty :loves ; owl:hasSelf "true"^^xsd:boolean .Objectproperty:parentOfCharacteristics:Irreflexive<owl:IreflexiveObjectProperty><owl:ObjectPropertyIRI="&f;parentOf"/></owl:IreflexiveObjectProperty>Next,considerthehasHusbandproperty.Aseveryperson] .
Class: NarcisticPerson EquivalentTo: loves Self
<EquivalentClasses> <Class IRI="NarcisticPerson"/> <ObjectHasSelf> <ObjectProperty IRI="loves"/> </ObjectHasSelf> </EquivalentClasses>
Using universal and existential quantification, we can have onlysay something about all respectively at least one husband (whichof somebody's children. However, we take for granted formight want to specify the sakenumber of individuals involved in the example), every individualrestriction. Indeed, we can be linked byconstruct classes depending on the hasHusband property tonumber of children. The following example states that John has at most one other individual. This kind of propertiesfour children who are calledthemselves parents:
ClassAssertion( ObjectMaxCardinality( 4 :hasChild :Parent )<owl:FunctionalPropertyrdf:about="#hasHusband"/>f:hasHusband:John )
<rdf:Description rdf:about="John"> <rdf:type> <owl:Class> <owl:Restriction> <owl:maxQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger"> 4 </owl:maxQualifiedCardinality> <owl:onProperty rdf:about="hasChild"/> <owl:onClass rdf:about="Parent"/> </owl:Restriction> </owl:Class> </rdf:type> </rdf:Description>
:John rdf:typeowl:FunctionalProperty[ rdf:type owl:Restriction ; owl:maxQualifiedCardinality "4"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ; owl:onClass :Parent ] .
Individual: John Types: hasChild max 4 Parent
<ClassAssertion> <ObjectMaxCardinality cardinality="4"> <ObjectProperty IRI="hasChild"/> <Class IRI="Parent"/> </ObjectMaxCardinality> <NamedIndividual IRI="John"/> </ClassAssertion>
Note that this statement does not require every individualallows John to have a spouse, it just states that there can be no more than one.arbitrarily many further children who are not parents.
Likewise, it is also possible to indicate that the inverse ofdeclare a given property is functional: InverseFunctionalProperty( f:hasHusband ) <owl:InverseFunctionalProperty rdf:about="#hasHusband"/> f:hasHusband rdf:type owl:InverseFunctionalProperty . ObjectProperty: hasHusband Characteristics: InverseFunctional <owl:InverseFunctionalObjectProperty> <owl:ObjectProperty IRI="&f;hasHusband"/> </owl:InverseFunctionalObjectProperty> This indicatesminimum number by saying that John is an individual can be husbandinstance of the class of individuals having at most one other individual. This example also indicates the difference between functionality and inverse functionality, as in a polygynous situation the former axiom is valid whereas the latter isn't. Now have a look at a property hasAncestor which is meantleast two children who are parents:
ClassAssertion( ObjectMinCardinality( 2 :hasChild :Parent ) :John )
<rdf:Description rdf:about="John"> <rdf:type> <owl:Class> <owl:Restriction> <owl:minQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger"> 2 </owl:minQualifiedCardinality> <owl:onProperty rdf:about="hasChild"/> <owl:onClass rdf:about="Parent"/> </owl:Restriction> </owl:Class> </rdf:type> </rdf:Description>
:John rdf:type [ rdf:type owl:Restriction ; owl:minQualifiedCardinality "2"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ; owl:onClass :Parent ] .
Individual: John Types: hasChild min 2 Parent
<ClassAssertion> <ObjectMinCardinality cardinality="2"> <ObjectProperty IRI="hasChild"/> <Class IRI="Parent"/> </ObjectMinCardinality> <NamedIndividual IRI="John"/> </ClassAssertion>
If we happen to link individuals A and B whenever A is a direct descendant of B. Clearly,know the property hasParent is a "special case" of hasAncestor and can be defined as a subproperty thereof. Still, it would be nice to "automatically" include parents of parents (and parents of parentsexact number of parents).John's children who are parents, this can be done by defining hasAncestorspecified as transitive property. A transitive property interlinks two individuals A and C whenever it interlinks A with B and B with C for some individual B. TransitiveProperty( f:hasAncestorfollows:
ClassAssertion( ObjectExactCardinality( 3 :hasChild :Parent )<owl:TransitivePropertyrdf:about="#hasAncestor"/>f:hasAncestor:John )
<rdf:Description rdf:about="John"> <rdf:type> <owl:Class> <owl:Restriction> <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger"> 3 </owl:qualifiedCardinality> <owl:onProperty rdf:about="hasChild"/> <owl:onClass rdf:about="Parent"/> </owl:Restriction> </owl:Class> </rdf:type> </rdf:Description>
:John rdf:typeowl:TransitiveProperty[ rdf:type owl:Restriction ; owl:qualifiedCardinality "3"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ; owl:onClass :Parent ] .
Individual: John Types: hasChild exactly 3 Parent
<ClassAssertion> <ObjectExactCardinality cardinality="3"> <ObjectProperty IRI="hasChild"/> <Class IRI="Parent"/> </ObjectExactCardinality> <NamedIndividual IRI="John"/> </ClassAssertion>
In a cardinality restriction, providing the previous section allowed to infer an hasAncestor property whenever thereclass is a chain of hasParent properties, we might want to be a bit more specific and define, say, a hasGrandparent property instead. Technically, this means thatoptional; if we just want hasGrandparent to connect all individuals that linked by a chain of exactly two hasParent properties. In contrastto talk about the previous hasAncestor example, we do not want hasParent to be a special casenumber of hasGrandparent nor do we want hasGrandparents to refer to great-grandparents etc.all of John's children we can express that every such chain has to be spanned by a hasGrandparent property as follows: SubPropertyOf( PropertyChain( f:hasParent f:hasParentwrite the following:
ClassAssertion( ObjectExactCardinality( 5 :hasChild )f:hasGrandparent:John )
<rdf:Descriptionrdf:about="#hasGrandparent"><owl:propertyChainAxiomrdf:parseType="Collection"><owl:ObjectPropertyrdf:about="#hasParent"/><owl:ObjectPropertyrdf:about="#hasParent"/></owl:propertyChainAxiom>rdf:about="John"> <rdf:type> <owl:Class> <owl:Restriction> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger"> 5 </owl:cardinality> <owl:onProperty rdf:about="hasChild"/> </owl:Restriction> </owl:Class> </rdf:type> </rdf:Description>
:John rdf:type [ rdf:type owl:Restriction ; owl:cardinality "5"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ] .
Individual: John Types: hasChild exactly 5
<ClassAssertion> <ObjectExactCardinality cardinality="5"> <ObjectProperty IRI="hasChild"/> </ObjectExactCardinality> <NamedIndividual IRI="John"/> </ClassAssertion>
A keyvery straightforward way to describe a class expression. This means that each named instance of the class expressionis uniquely identified by the set of values which these properties attain in relationjust to the instance. A simple example ofenumerate all its instances. OWL provides this would be the identification ofpossibility, e.g. we can create a person by her social security number. HasKey( f:Person hasSSN ) <owl:Class rdf:about="#Person"> <owl:hasKey rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="#hasSSN"> </owl:hasKey>class of birthday guests:
EquivalentClasses( :MyBirthdayGuests ObjectOneOf( :Bill :John :Mary) )
<owl:Class rdf:about="MyBirthdayGuests"> <owl:equivalentClass> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:about="Bill"/> <rdf:Description rdf:about="John"/> <rdf:Description rdf:about="Mary"/> </owl:oneOf> </owl:Class>f:Personowl:hasKeyf:hasSSN</owl:equivalentClass> </owl:Class>
:MyBirthdayGuests owl:equivalentClass [ rdf:type owl:Class ; owl:oneOf ( :Bill :John :Mary ) ] .
Class: MyBirthdayGuests EquivalentTo: { Bill John Mary }
<EquivalentClasses> <Class IRI="MyBirthdayGuests"/> <ObjectOneOf> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="John"/> <NamedIndividual IRI="Mary"/> </ObjectOneOf> </EquivalentClasses>
Note that this axiom provides more information and Annotations In the following, we describe featuresthan simply asserting class membership of OWL 2 which do not actually contribute to the "logical" knowledge specified in the ontology. Rather these are used to provide additional information about the ontology itself, axioms or even single entities. 7.1 Annotating AxiomsBill, John, and EntitiesMary as described in many cases, we wantSection 4.1. In addition to furnish parts of our OWL ontology with informationthat, it also stipulates that actually does not describe the domain itself but talks aboutBill, John, and Mary are the descriptiononly members of the domain. OWL provides annotations forMyBirthdayGuest. Therefore, classes defined this purpose.way are sometimes referred to as closed classes or enumerated sets. If we now assert Jeff as an OWL annotation simply associates property-value pairs with partsinstance of an ontology, orMyBirthdayGuest, the entire ontology itself. Even annotations themselves can be annotated. Annotation informationconsequence is not really part of the logical meaning of an ontology. So, for example, we could add informationthat Jeff must be equal to one of the classes of our ontology, giving a natural language description of its meaning. AnnotationAssertion( rdfs:label f:Person "Represents the set of all people." ) <owl:Class rdf:about="#Person"> <rdfs:label>Represents the setabove three persons.
Until now we focussed on classes and properties that were merely used as building blocks for class expressions. In the set of all people." <owl:AnnotationAssertion> <owl:AnnotationProperty IRI="&rdfs;label"/> <owl:IRI>f:Person</owl:IRI> <owl:Literal>Representsfollowing, we will see what other modeling capabilities with properties OWL 2 offers.
Sometimes one property can be obtained by taking another property and changing its direction, i.e. inverting it. For example, the setproperty hasParent can be defined as the inverse property of all people.</owl:Literal> </owl:AnnotationAssertion> Editor's Note: addhasChild:
InverseObjectProperties( :hasParent :hasChild )
<owl:ObjectProperty rdf:about="hasParent"> <owl:inverseOf rdf:resource="hasChild"/> </owl:ObjectProperty>
:hasParent owl:inverseOf :hasChild .
ObjectProperty: hasParent InverseOf: hasChild
<InverseObjectProperties> <ObjectProperty IRI="hasParent"/> <ObjectProperty IRI="hasChild"/> </InverseObjectProperties>
This would for example of annotated axiom (suggestion by pfps) 7.2 Ontology Management In OWL, general information aboutallow to deduce for arbitrary individuals A and B, where A topicis almost always gathered into an ontologylinked to B by the hasChild property, that is then usedB and A are also interlinked by various applications.the hasParent property. However, we can also providedo not need to explicitly assign a name for OWL ontologies , which is generallyto the place whereinverse of a property if we just want to use it, say, inside a class expression. Instead of using the ontology document is located innew hasParent property for the web. Particular information about a topicdefinition of the class Orphan, we can also be placed in an ontology, ifdirectly refer to it is used by different applications. Ontology(<http://example.com/owl/families> ...as the hasChild-inverse:
EquivalentClasses( :Orphan ObjectAllValuesFrom( ObjectInverseOf( :hasChild )<rdf:RDF...><owl:Ontologyrdf:about="http://example.com/owl/families"/>...</rdf:RDF><http://example.com/owl/families>rdf:typeowl:Ontology ;Ontology:<http://example.com/owl/families><Ontology...URI="http://example.com/owl/families">...</Ontology>WeplaceOWLontologiesintoOWLdocuments,whicharethenplacedintolocalfilesystemsorontheWorldWideWeb.AsidefromcontaininganOWLontology,OWLdocumentsalsocontaininformationabouttransformingtheshortnamesnormallyusedinOWLontologies(e.g.,Person)intoIRIs,byprovidingtheexpansionforprefixes:Dead ) )
<owl:Class rdf:about="Orphan"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty> <owl:inverseOf rdf:about="hasChild"/> </owl:ObjectProperty> </owl:onProperty> <owl:Class rdf:about="Dead"/> </owl:Restriction> </owl:equivalentClass> </owl:Class>
:Orphan owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty [ owl:inverseOf :hasChild ] ; owl:allValuesFrom :Dead ] .
Class: Orphan EquivalentTo: inverse hasChild only Dead
<EquivalentClasses> <Class IRI="Orphan"/> <ObjectAllValuesFrom> <InverseObjectProperty> <ObjectProperty IRI="hasChild"/> </InverseObjectProperty> <Class IRI="Dead"/> </ObjectAllValuesFrom> </EquivalentClasses>
In our example we have so far used two prefixes, xsdsome cases, a property and the empty prefix. The former prefix has been usedits inverse coincide, or in compact names for XML Schema datatypes, whose IRIs are fixed byother words, the XML Schema recommendation. We thus must usedirection of a property doesn't matter. For instance the standard expansionproperty hasSpouse relates A with B exactly if it relates B with A. For xsd , whichobvious reasons, a property with this characteristic is http://www.w3.org/2001/XMLSchema#called symmetric, and it can be specified as follows
SymmetricObjectProperty( :hasSpouse )
<owl:SymmetricProperty rdf:about="hasSpouse"/>
:hasSpouse rdf:type owl:SymmetricProperty .
ObjectProperty: hasSpouse Characteristics: Symmetric
<SymmetricObjectProperty> <ObjectProperty IRI="hasSpouse"/> </SymmetricObjectProperty>
On the other prefix will affecthand, a property can also be asymmetric meaning that if it connects A with B it never connects B with A. Clearly (excluding paradoxical scenarios resulting from time travels), this is the names ofcase for the classes, properties,property hasChild and individualsis expressed like this:
AsymmetricObjectProperty( :hasChild )
<owl:AsymmetricProperty rdf:about="hasChild"/>
:hasChild rdf:type owl:AsymmetricProperty .
ObjectProperty: hasChild Characteristics: Asymmetric
<AsymmetricObjectProperty> <ObjectProperty IRI="hasChild"/> </AsymmetricObjectProperty>
Previously, we considered subproperties in our ontology, as well asanalogy to subclasses. It turns out that it also make sense to transfer the namenotion of the ontology itself.class disjointness to properties: two properties are disjoint if wethere are going to put the ontology on the web,no two individuals that are interlinked by both properties. Following common law, we should pick an expansioncan thus state that is in some part ofparent-child marriages cannot occur:
DisjointObjectProperties( :hasParent :hasSpouse )
<rdf:Description rdf:about="hasParent"> <owl:propertyDisjointWith rdf:resource="hasSpouse"/> </rdf:Description>
:hasParent owl:propertyDisjointWith :hasSpouse .
DisjointProperties: hasParent hasSpouse
<DisjointObjectProperties> <ObjectProperty IRI="hasParent"/> <ObjectProperty IRI="hasSpouse"/> </DisjointObjectProperties>
Properties can also be reflexive: such a property relates everything to itself. For the webfollowing example, note that we control, soeverybody has himself as a relative.
ReflexiveObjectProperty( :hasRelative )
<owl:ReflexiveProperty rdf:about="hasRelative"/>
:hasRelative rdf:type owl:ReflexiveProperty .
ObjectProperty: hasRelative Characteristics: Reflexive
<ReflexiveObjectProperty> <ObjectProperty IRI="hasRelative"/> </ReflexiveObjectProperty>
Note that we arethis does not using someone else's namesnecessarily mean that every two individuals which are related by accident. (Here we usea made-up placereflexive property are identical.
Properties can furthermore be irreflexive, meaning that no one controls.)individual can be related to itself by such a role. A typical example is the two XML-based syntaxes need namespaces for built-in names and alsofollowing which simply states that nobody can use XML entities for namespaces. Namespace(=<http://example.com/owl/families#>) Namespace(f=<http://example.com/owl/families#>) Namespace(g=<http://example.com/owl2/families#>) Namespace(xsd=< http://www.w3.org/2001/XMLSchema# >) Namespace(dc=<http:// http://purl.org/dc/elements/1.1/ >) <!DOCTYPE rdf:RDF [ <!ENTITY owl " http://www.w3.org/2002/07/owl# " > <!ENTITY owl2 " http://www.w3.org/2006/12/owl2# " > <!ENTITY rdf " http://www.w3.org/1999/02/22-rdf-syntax-ns# " > <!ENTITY rdfs " http://www.w3.org/2000/01/rdf-schema# " > <!ENTITY xsd " http://www.w3.org/2001/XMLSchema# " > <!ENTITY f "http://example.com/owl/families#" > <!ENTITY g "http://example.com/owl2/families#" > ]> <rdf:RDF xml:base="http://example.com/owl/families" xmlns="http://example.com/owl/families#" xmlns:owl=" http://www.w3.org/2002/07/owl# " xmlns:owl2=" http://www.w3.org/2006/12/owl2# " xmlns:rdfs=" http://www.w3.org/2000/01/rdf-schema# " xmlns:rdf=" http://www.w3.org/1999/02/22-rdf-syntax-ns# " xmlns:xsd=" http://www.w3.org/2001/XMLSchema# " xmlns:f="http://example.com/owl/families#" xmlns:g="http://example.com/owl2/families#" xmlns:dc="http:// http://purl.org/dc/elements/1.1/ "> <owl:Ontology rdf:about="http://example.com/owl/families"/> ... @prefix : <http://example.com/owl/families#> @prefix f: <http://example.com/owl/families#> @prefix g: <http://example.com/owl2/families#> @prefix dc: <http:// http://purl.org/dc/elements/1.1/ > Namespace: <http://example.com/owl/families#> Namespace: f <http://example.com/owl/families#> Namespace: g <http://example.com/owl2/families#> Namespace: dc <http:// http://purl.org/dc/elements/1.1/ > <!DOCTYPE Ontology [ <!ENTITY owl " http://www.w3.org/2002/07/owl# " > <!ENTITY owl2 " http://www.w3.org/2006/12/owl2# " > <!ENTITY xsd " http://www.w3.org/2001/XMLSchema# " > <!ENTITY f "http://example.com/owl/families#" > <!ENTITY g "http://example.com/owl2/families#" > <!ENTITY dc "http:// http://purl.org/dc/elements/1.1/ " > ]> <Ontology xml:base=" http://www.w3.org/2006/12/owl2-xml# " xmlns=" http://www.w3.org/2006/12/owl2-xml# " xmlns:owl=" http://www.w3.org/2002/07/owl# " xmlns:owl2=" http://www.w3.org/2006/12/owl2# " xmlns:xsd=" http://www.w3.org/2001/XMLSchema# " xmlns:f="http://example.com/owl/families#" xmlns:g="http://example.com/owl2/families#" xmlns:dc="http:// http://purl.org/dc/elements/1.1/ " URI="http://example.com/owl/families"> ... </Ontology> It is also common in OWL to reuse general information that is stored inbe his own parent.
IrreflexiveObjectProperty( :parentOf )
<owl:IrreflexiveProperty rdf:about="parentOf"/>
:parentOf rdf:type owl:IrreflexiveProperty .
Objectproperty: parentOf Characteristics: Irreflexive
<IreflexiveObjectProperty> <ObjectProperty IRI="parentOf"/> </IreflexiveObjectProperty>
Next, consider the hasHusband property. As every person can have only one ontology in other ontologies. Instead of requiringhusband (which we take for granted for the copyingsake of this information, OWL allowsthe importation ofexample), every individual can be linked by the contents of entire ontologies inhasHusband property to at most one other ontologies, using imports statements,individual. This kind of properties are called functional and are described as follows:
FunctionalObjectProperty( :hasHusband )
<owl:FunctionalProperty rdf:about="hasHusband"/>
:hasHusband rdf:type owl:FunctionalProperty .
ObjectProperty: hasHusband Characteristics: Functional
<FunctionalObjectProperty> <ObjectProperty IRI="hasHusband"/> </FunctionalObjectProperty>
Note that this statement does not require every individual to use different names for the same concept, property, or individual. As wehave seen, several constructs in OWLa husband, it just states that there can be used to state that different namesno more than one. Moreover, if we additionally had a statement that Mary's husband is James and another that Mary's husband is Jim, it could be inferred that Jim and James must refer to the same class , property , or individual , so, for example, we could - instead of tediously renaming entities - tie the names used in our ontologyindividual.
It is also possible to indicate that thenamesusedinanimportedontologyasfollows:SameIndividuals(f:Johng:JohnBrown)SameIndividuals(f:Maryg:MaryBrown)EquivalentClasses(f:Adultg:Grownup)EquivalentObjectProperties(f:hasChildg:child)EquivalentDataProperties(f:hasAgeg:ageinverse of a given property is functional:
InverseFunctionalObjectProperty( :hasHusband )
<owl:InverseFunctionalProperty rdf:about="hasHusband"/>
:hasHusband rdf:type owl:InverseFunctionalProperty .
ObjectProperty: hasHusband Characteristics: InverseFunctional
<InverseFunctionalObjectProperty> <ObjectPropertyIRI="&g;child"/></EquivalentObjectProperties><EquivalentDataProperties><DataPropertyIRI="&f;hasAge"/><DataPropertyIRI="&g;age"/></EquivalentDataProperties>7.3EntityDeclarationsTohelpwithmanagingontologies,OWLhasthenotionofdeclarations.ThebasicideaisIRI="hasHusband"/> </InverseFunctionalObjectProperty>
This indicates that each class, property, or individual is supposed to be declared inan ontology, and then itindividual can be used in that ontologyhusband of at most one other individual. The example also indicates the difference between functionality and ontologies that import that ontology.inverse functionality, as in the Manchester syntax, declarations are implicit. Constructs that provide information abouta class, property, or individual implicitly declare that class, property, or individual if needed.polygynous situation the other syntaxes have explicit declarations. MISSING. MISSING. MISSING. Declaration(Individual(John)) Declaration(Class(Person)) Declaration(ObjectProperty(hasWife)) Declaration(DataProperty(hasAge)) <Declaration> <Individual IRI="&f;John"/> </Declaration> <Declaration> <Class IRI="&f;Person"/> </Declaration> <Declaration> <ObjectProperty IRI="&f;hasWife"/> </Declaration> <Declaration> <DataProperty IRI="&f;hasAge"/> </Declaration> Editor's Note:former axiom is valid whereas the following might be shifted into the following section. However, an IRI may denote different entity-types (e.g. both an individual andlatter isn't.
Now have a class)look at the same time. This possibility, called "punning", has been introduced to allow fora certain amount of metamodeling. Still, OWL 2 does require some discipline in using and reusing names.property hasAncestor which is meant to allowlink individuals A more readable syntax,and for other technical reasons, OWL 2 DL requires thatB whenever A nameis not used for more than onea direct descendant of B. Clearly, the property type (object, datatype or annotation property) nor can an IRI denote bothhasParent is a class“special case” of hasAncestor and a datatype. Moreover, "built-in" names (suchcan be defined as those useda subproperty thereof. Still, it would be nice to "automatically" include parents of parents (and parents of parents of parents). This can be done by RDFdefining hasAncestor as transitive property. A transitive property interlinks two individuals A and RDFSC whenever it interlinks A with B and various syntaxesB with C for some individual B.
TransitiveObjectProperty( :hasAncestor )
<owl:TransitiveProperty rdf:about="hasAncestor"/>
:hasAncestor rdf:type owl:TransitiveProperty .
ObjectProperty: hasAncestor Characteristics: Transitive
<TransitiveObjectProperty> <ObjectProperty IRI="hasAncestor"/> </TransitiveObjectProperty>
While the last example from the previous section implied the presence of OWL) cannotan hasAncestor property whenever there is a chain of hasParent properties, we might want to be freely used in OWL. 8 OWL 2 DLa bit more specific and OWL 2 Full Theredefine, say, a hasGrandparent property instead. Technically, this means that we want hasGrandparent to connect all individuals that are two wayslinked by a chain of thinking about OWL 2. One way, called OWL 2 DL, concentrates on OWL 2 as an ontology language - the constructs of OWL 2 form the syntax neededexactly two hasParent properties. In contrast to write ontologies andthe previous hasAncestor example, we do not havewant hasParent to be a separate existence. The other way, called OWL 2 Full, concentrates on OWL 2 as an extension of the Resource Description Framework (RDF) [ RDF Primer ] - here the constructs of OWL 2 are groups of RDF triples and have the standard meaningspecial case of RDF tripleshasGrandparent nor do we want hasGrandparent to go along with their meaningrefer to great-grandparents etc. We can express that every such chain has to be spanned by a hasGrandparent property as construct of an ontology language. The meaning of ontologiesfollows:
SubObjectPropertyOf( ObjectPropertyChain( :hasParent :hasParent ) :hasGrandparent )
<rdf:Description rdf:about="hasGrandparent"> <owl:propertyChainAxiom rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasParent"/> <owl:ObjectProperty rdf:about="hasParent"/> </owl:propertyChainAxiom> </rdf:Description>
:hasGrandparent owl:propertyChainAxiom ( :hasParent :hasParent ) .
ObjectProperty: hasGrandparent SubPropertyChain: hasParent o hasParent
<SubObjectPropertyOf> <PropertyChain> <ObjectProperty IRI="hasParent"/> <ObjectProperty IRI="hasParent"/> </PropertyChain> <ObjectProperty IRI="hasGrandparent"/> </SubObjectPropertyOf>
In OWL 2 DL is given bya direct model-theoretic semantics [ OWL 2 Direct Semantics ]., which providescollection of (data or object) properties can be assigned as a meaning for OWL 2 inkey to a Description Logic style. Meaning for OWL 2 Fullclass expression. This means that each named instance of the class expression is provideduniquely identified by the RDF-based semantics [ OWL 2 RDF-Based Semantics ], which is an extensionset of values which these properties attain in relation to the semantics for RDFS [ RDF Semantics ]. When thinking about ontologiesinstance.
A simple example of this would be the differences between OWL 2 DL and OWL 2 Full are generally quite slight. Any OWL 2 DL ontologyidentification of a person by her social security number.
HasKey( :Person () ( :hasSSN ) )
<owl:Class rdf:about="Person"> <owl:hasKey rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasSSN"/> </owl:hasKey> </owl:Class>
:Person owl:hasKey :hasSSN .
HasKey: Person hasSSN
<HasKey> <Class IRI="Person"/> <ObjectProperty IRI="hasSSN"/> </HasKey>
In Section 4.8, we learned that individuals can be considered asendowed with numerical information, esentially by connecting them to a collection of RDF triples (an RDF graph).data value via a datatype property - just like object properties link to other domain individuals. In fact, these parallels extend to the OWL 2 DL meaningmore advanced features of the ontology and the OWL 2 Full meaningdatatype usage.
First of this RDF graph are very close. The two main differencesall, data values are that in OWL 2 DL annotations have no meaninggrouped into datatypes and we have seen in OWL 2 Full there are some extra inferences that arise fromSection 4.8 how a range restriction on a datatype property can be used to indicate the RDF viewkind of the universe. Conceptually, wevalues this property can think of the difference between OWL 2 DLlink to. Moreover, it is possible to express and OWL 2 Full in two ways: Onedefine new datatypes by constraining or combining existing ones.
Datatypes can see OWL 2 DL as a syntacticallybe restricted version of OWL 2 Full wherevia so-called facets. In the restrictions are designed to make life easierfollowing example, we define a new datatype for implementors. In fact, since OWL 2 Full is undecidable, OWL 2 DL makes writinga reasoner that, in principle, can return all yes and no answers (subjectperson's age by constraining the datatype integer to resource constraints) possible. Asvalues between (inclusively) 0 and 150.
DatatypeDefinition( :personAge DatatypeRestriction( xsd:integer xsd:minInclusive "0"^^xsd:integer xsd:maxInclusive "150"^^xsd:integer ) )
<rdf:Description rdf:about="personAge"> <owl:equivalentClass> <owl:Datatype> <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/> <owl:withRestrictions rdf:parseType="Collection"> <xsd:minInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">0</xsd:minInclusive> <xsd:maxInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">150</xsd:maxInclusive> </owl:withRestrictions> </owl:Datatype> </owl:equivalentClass> </rdf:Description>
:personAge owl:equivalentClass [ rdf:type rdfs:Datatype; owl:onDatatype xsd:Integer; owl:withRestrictions ( [ xsd:minInclusive "0"^^xsd:integer ] [ xsd:maxInclusive "150"^^xsd:integer ] ) ] .
Datatype: personAge EquivalentTo: integer[<= 0 , >= 150]
<EquivalentClasses> <Datatype IRI="personAge"/> <DatatypeRestriction> <Datatype IRI="&xsd;integer"/> <FacetRestriction facet="&xsd;minInclusive"> <Literal datatypeIRI="&xsd;integer">0</Literal> </FacetRestriction> <FacetRestriction facet="&xsd;maxInclusive"> <Literal datatypeIRI="&xsd;integer">150</Literal> </FacetRestriction> </DatatypeRestriction> </EquivalentClasses>
Likewise, datatypes can be combined just like classes by complement, intersection and union. Thereby, assuming we have already defined a consequence of its design, there are several production quality OWL 2 DL reasoners that cover the entire language. There are no such OWL 2 Full reasoners. Onedatatype MinorAge, we can see OWL 2 Full asdefine the most straightforward extensiondatatype MajorAge by excluding all data values of RDFS. As such, OWL 2 Full follows the RDFS semanticsMinorAge from PersonAge:
DatatypeDefinition( :majorAge DataIntersectionOf( :personAge DataComplementOf( :minorAge ) ) )
<rdf:Description rdf:about="majorAge"> <owl:equivalentClass> <owl:Datatype> <owl:intersectionOf rdf:parseType="Collection"> <rdf:Description rdf:about="personAge"/> <rdfs:Datatype> <owl:datatypeComplementOf about="minorAge"/> </rdfs:Datatype> </owl:intersectionOf> </owl:Datatype> </owl:equivalentClass> </rdf:Description>
:majorAge owl:equivalentClass [ rdf:type rdfs:Datatype; owl:intersectionOf ( :personAge [ rdf:type rdfs:Datatype; owl:datatypeComplementOf :minorAge ] ) ] .
Datatype: majorAge EquivalentTo: personAge andgeneralsyntacticphilosophy(i.e.,everythingisnot minorAge
<EquivalentClasses> <Datatype IRI="majorAge"/> <DataIntersectionOf> <Datatype IRI="personAge"/> <DataComplementOf> <Datatype IRI="minorAge"/> </DataComplementOf> </DataIntersectionOf> </EquivalentClasses>
Moreover, a triple andnew datatype can be generated by just enumerating the language is fully reflective). Of course, OWL 2 Full and OWLdata values it contains.
DatatypeDefinition( :toddlerAge DataOneOf( "1"^^xsd:integer "2"^^xsd:integer ) )
<rdf:Description rdf:about="toddlerAge"> <owl:equivalentClass> <owl:Datatype> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</rdf:Description> <rdf:Description rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">2</rdf:Description> </owl:oneOf> </owl:Datatype> </owl:equivalentClass> </rdf:Description>
:toddlerAge owl:equivalentClass [ rdf:type rdfs:Datatype; owl:oneOf ( "1"^^xsd:integer "2"^^xsd:integer ) ] .
Datatype: toddlerAge EquivalentTo: { 1 2DLhavebeendesignedtogetherandthushaveinfluencedeachother.}
<EquivalentClasses> <Datatype IRI="toddlerAge"/> <DataOneOf> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">1</Literal> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">2</Literal> </DataOneOf> </EquivalentClasses>
In Section 6.1, we saw ways of characterizing object properties. Some of those are also available for example,datatype properties. This way, we can e.g. express that every person has only one design goal of OWL 2 was to bring OWL 2 DL syntactically closer to OWL 2 Full (that is, to allow more RDF Graphs/OWL 2 Full ontologies toage by characterizing the hasAge datatype property as functional:
FunctionalDataProperty( :hasAge )
<owl:FunctionalProperty rdf:about="hasAge"/>
:hasAge rdf:type owl:FunctionalProperty .
DataProperty: hasHusband Characteristics: Functional
<FunctionalDataProperty> <DataProperty IRI="hasHusband"/> </FunctionalDataProperty>
New classes can be legal OWL 2 DL ontologies). This led todefined by restrictions on datatype properties. The incorporation of so-called punning into OWL 2, e.g., usingfollowing example defines the same IRI as a name for both aclass teenager as all individuals whose age is between 13 and an individual. 9 OWL 2 Profiles In addition to OWL 2 DL19 years.
SubClassOf( :Teenager ObjectSomeValuesFrom( :hasAge DatatypeRestriction( xsd:integer xsd:minInclusive "13"^^xsd:integer xsd:maxInclusive "19"^^xsd:integer ) ) )
<owl:Class rdf:about="Teenager"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="hasAge"/> <owl:someValuesFrom> <rdfs:Datatype> <owl:onDataType rdf:resource="&xsd;integer"/> <owl:withRestrictions rdf:parseType="Collection"> <xsd:minExclusive rdf:datatype="&xsd;integer"> 12 </xsd:minExclusive> <xsd:maxInclusive rdf:datatype="&xsd;integer"> 19 </xsd:maxInclusive> </owl:withRestrictions> </rdfs:Datatype> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
:Teenager rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty :hasAge ; owl:someValuesFrom [ rdf:type rdfs:Datatype ; owl:onDatatype xsd:integer ; owl:withRestrictions ( [ xsd:minInclusive "13"^^xsd:integer ] [ xsd:maxInclusive "19"^^xsd:integer ] ) ] ] .
Class: Teenager SubClassOf: hasAge some integer[<= 13 , >= 19]
<SubClassOf> <Class IRI="Teenager"/> <DataSomeValuesFrom> <DataProperty IRI="hasAge"/> <DatatypeRestriction> <Datatype IRI="&xsd;integer"/> <FacetRestriction facet="&xsd;minInclusive"> <Literal datatypeIRI="&xsd;integer">13</Literal> </FacetRestriction> <FacetRestriction facet="&xsd;maxInclusive"> <Literal datatypeIRI="&xsd;integer">19</Literal> </FacetRestriction> </DatatypeRestriction> </DataSomeValuesFrom> </SubClassOf>
In the following, we describe features of OWL 2 Full, OWL 2 specifies three profiles of OWL. OWL, in general, is a very expressive language (both computationally and for users) and thus can be difficult to implement well andwhich do not actually contribute to work with.the “logical” knowledge specified in the ontology. Rather these additional profilesare designedused to be approachable subsetsprovide additional information about the ontology itself, axioms, or even single entities.
In many cases, we want to furnish parts of our OWL sufficient for a variety of applications. Asontology with OWL 2 DL, computational considerations are a major requirement of these profiles (and they are all much easier to implement with robust scalability given existing technology),information that actually does not describe the domain itself but there are many subsetstalks about the description of OWL that have good computational properties.the selecteddomain. OWL 2 profiles were identified as having substantial user communities already, although there were several others not included and one should expect more to emerge. The profiles documentprovides a clear template for specifying additional profiles. In order to guarantee for scalable reasoning, the existing profiles share some limitations regarding their expressiveness. In general, they disallow negation and disjunction, as those constructs complicate reasoning and have shown to be only rarely needed for modelling.annotations for example, nonethis purpose. An OWL annotation simply associates property-value pairs with parts of the profiles would allow to specify that every person is malean ontology, or female. Further specific modelling restrictions of the profiles will be dealt inthe sections on the single profiles. We discuss each profile and their design rationale, and provide some guidance for users in selecting which profile to work with. Pleaseentire ontology itself. Even annotations themselves can be aware that this discussionannotated. Annotation information is not comprehensive, nor can it be.really part of any decision has to be based on available tooling and how that fits it withthe restlogical meaning of your system or workflow. For example, you may require that your tools are implemented in Java and that dominates any decision. By and large, different profiles can be distinguished syntactically with there being inclusion relations between various profiles.an ontology.
So, for example, OWL 2 DL can be seen as a syntactic fragmentwe could add information to one of OWL 2 Full and OWL QL isthe classes of our ontology, giving a syntactic fragmentnatural language description of OWL 2 DL (and thusits meaning.
AnnotationAssertion( rdfs:comment :Person "Represents the set ofOWL2Full).Ideally,onecanuseareasoner(orothertool)thatisconformingforasuperprofileonall people." )
<owl:Class rdf:about="Person"> <rdfs:comment>Represents thesubprofilewithnochangeinset of all people.</rdfs:comment> </owl:Class>
:Person rdfs:comment "Represents theresultsderived.ForprofilessuchasOWLELandOWLQLinrelationtoOWL2DLthisprincipledoeshold:EveryconformingOWL2DLreasonerisanOWLELandOWLQLreasoner(butmaydifferinperformancesinceset of all people."^^xsd:string .
Class: Person Annotations: rdfs:comment "Represents theOWL2DLreasoneristunedforamoregeneralset ofcases).9.1OWL2ELOWL2ELisaprofileall people."
<AnnotationAssertion> <AnnotationProperty IRI="&rdfs;comment"/> <IRI>Person</IRI> <Literal>Represents the set ofOWL2verycloselyrelatedtoall people.</Literal> </AnnotationAssertion>
The description logic EL++ and basic reasoning problems for it can be performed in time thatfollowing is polynomial with respect to the sizean example of the ontology. Workingan axiom with OWL 2 ELan annotation.
SubClassOf( Annotation( rdfs:comment "States that every man isfairlysimilartoworkingwithOWL2DL:onecanuseclassexpressionsonbothsidesofasubClassStatementandeveninfersuchrelations.Formanyclassexpressionorientedontologies,OWL2ELmakesperson." ) :Man :Person )
<owl:Class rdf:about="Man"> <rdfs:subClassOf rdf:resource="Person"/> </owl:Class> <owl:Axiom> <owl:annotatedSource rdf:resource="Man"/> <owl:annotatedProperty rdf:resource="&rdfs;subClassOf"/> <owl:annotatedTarget rdf:resource="Person"/> <rdfs:comment>States that every man is agoodapproximationtarget,person.</rdfs:comment> </owl:Axiom>
:Man rdfs:subClassOf :Person . [] rdf:type owl:Axiom ; owl:annotatedSource :Man ; owl:annotatedProperty rdfs:subClassOf ; owl:annotatedTarget :Person ; rdfs:comment "States thatis,byonlyevery man is alittlesimplificationonecangetanOWL2ELontologyandpreservemuchofthemeaningoftheoriginalontology.OWL2ELperson."^^xsd:string .
Class: Man SubClassOf: Annotations: rdfs:comment "States that every man isveryrobustcomputationallyandreasonablyeasytoimplement.Notonlydoesitscalewellforfactsandaxioms,butitscaleswellforcomplexexpressions.OWL2ELa person." Person
<SubClassOf> <Annotation> <AnnotationProperty IRI="&rdfs;comment"/> <Literal datatypeIRI="xsd:string">"States that every man isdesignedwithlargebiohealthontologiesinmind,suchasSNOMED-CT,theNCIthesaurus,andGalen.Commoncharacteristicsofa person."</Literal> </Annotation> <Class IRI="Man"/> <Class IRI="Person"/> </SubClassOf>
Often such ontologies include complex structural descriptions (e.g., defining certain body parts in terms of what parts they contain andannotations are containedused in or propagating diseases along part-subpart relations), huge numbers of classes, the heavy use of classificationtools to manage the terminology, and the application of the resulting terminologyprovide access to vast amounts of data. Thus, OWL 2 EL has a comparatively expressive class expressionnatural language and it has no restrictions on how they maytext to be useddisplayed in axioms. Ithelp interfaces.
In OWL, general information about a topic is almost always gathered into an ontology that is then used by various applications. We can also has fairly expressive property expressions, including property chains but excluding inverse. Sensible use ofprovide a name for OWL 2 ELontologies, which is obviously not restricted togenerally the biohealth domain: as withplace where the other profiles of OWL, OWL 2 ELontology document is domain independent. However, OWL 2 EL shines when your domain and your application require recognition of structurally complex objects. Such domains include system configuration, product inventories, and many scientific domains. Besides negation and disjunction, OWL 2 ELlocated in the web. Particular information about a topic can also disallows universal quantificationbe placed in an ontology, if it is used by different applications.
Ontology(<http://example.com/owl/families> ... )
<rdf:RDF ...> <owl:Ontology rdf:about="http://example.com/owl/families"/> ... </rdf:RDF>
<http://example.com/owl/families> rdf:type owl:Ontology .
Ontology: <http://example.com/owl/families>
<Ontology ... ontologyIRI="http://example.com/owl/families"> ... </Ontology>
We place OWL ontologies into OWL documents, which are then placed into local filesystems or on properties. Therefore propositions like "all childrenthe World Wide Web. Aside from containing an OWL ontology, OWL documents also contain information about transforming the short names normally used in OWL ontologies (e.g., Person) into IRIs,
by providing the expansion for prefixes. The IRI is then the concatention of the prefix expansion and the reference.
In our example we have so far used a rich person are rich" cannot be stated. Moreover, as all kindsnumber of role inversesprefixes, including xsd and the empty prefix. The former prefix has been used in compact names for
XML Schema datatypes, whose IRIs are not available, therefixed by the XML Schema recommendation. We thus must use the standard expansion for xsd, which is no wayhttp://www.w3.org/2001/XMLSchema#. The expansion we pick for the other prefix will affect the names of specifying that, say, parentOfthe classes, properties, and childOf are inversesindividuals in our ontology, as well as the name of each other.the following isontology itself. If we are going to put the ontology on the web, we should pick an example which usesexpansion that is in some part of the typical modelling features available in OWL 2 EL. SubClassOf( f:Father IntersectionOf( f:Man f:Parent ) ) EquivalentClass( f:Parent SomeValuesFrom( f:hasChild f:Person ) ) EquivalentClasses( f:NarcisticPerson HasSelf( f:loves ) ) DisjointClasses( f:Mother f:Father f:YoungChild ) SubPropertyOf( PropertyChain( f:hasFather f:hasBrother ) f:hasUncle ) NegativePropertyAssertion( f:hasDaughter f:Bill f:Susan ) <owl:Class rdf:about="#Father"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Man"/> <owl:Class rdf:about="#Parent"/> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Parent"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="#hasChild"/> <owl:someValuesFrom rdf:resource="#Person"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="#NarcisticPerson"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="#loves"/> <owl:hasSelf rdf:datatype="&xsd;boolean"> true </owl:hasSelf> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class rdf:about="#Mother"/> <owl:Class rdf:about="#Father"/> <owl:Class rdf:about="#YoungChild"/> </owl:members> </owl:AllDisjointClasses> <rdf:Description> <owl:propertyChain rdf:parseType="Collection"> <owl:ObjectProperty rdf:resource="#hasFather"/> <owl:ObjectProperty rdf:about="#hasBrother"/> </owl:propertyChain> <rdfs:subPropertyOf rdf:resource="#hasUncle"/> </rdf:Description> <owl:NegativePropertyAssertion> <owl:sourceIndividual rdf:about="#Bill"> <owl:assertionProperty rdf:about="#hasDaughter"> <owl:targetIndividual rdf:about="#Susan"> </owl:NegativePropertyAssertion> f:Father rdfs:subClassOf _:x1 . _:x1 rdf:type owl:Class ; owl:intersectionOf ( f:Man f:Parentweb that we control, so that we are not using someone else's names by accident. (Here we use a made-up place that no one controls.) The two XML-based syntaxes need namespaces for built-in names and also can use XML entities for namespaces.
Prefix(:=<http://example.com/owl/families/>) Prefix(otherOnt:=<http://example.org/otherOntologies/families/>) Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>) Prefix(owl:=<http://www.w3.org/2002/07/owl#>) Ontology(<http://example.com/owl/families> ... )
<!DOCTYPE rdf:RDF [ <!ENTITY owl "http://http://www.w3.org/2002/07/owl#" > <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" > <!ENTITY otherOnt "http://example.org/otherOntologies/families/" > ]> <rdf:RDF xml:base="http://example.com/owl/families/" xmlns="http://example.com/owl/families/" xmlns:otherOnt="http://example.org/otherOntologies/families/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xml="http://www.w3.org/2001/XMLSchema#"> <owl:Ontology rdf:about="http://example.com/owl/families"/> ...
@prefix : <http://example.com/owl/families/> .f:Parentowl:equivalentClass_:x2._:x2rdf:typeowl:Restriction ;owl:onPropertyf:hasChild ;owl:someValuesFromf:Person@prefix otherOnt: <http://example.org/otherOntologies/families/> .f:NarcisticPersonowl:equivalentClass_:x3@prefix owl: <http://www.w3.org/2002/07/owl#> ._:x3rdf:typeowl:Restriction ;owl:onPropertyf:loves ;owl:hasSelf"true"^^xsd:boolean@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> ._:x4rdf:typeowl:AllDisjointClasses ;owl:members(f:Motherf:Fatherf:YoungChild)._:x5rdfs:subPropertyOff:hasUncle ;owl:propertyChain(f:hasFatherf:hasBrother)@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> ._:x6rdf:typeowl:NegativePropertyAssertion ;owl:sourceIndividualf:Bill ;owl:assertionPropertyf:hasDaughter ;owl:targetIndividualf:Susan@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
Prefix: <http://example.com/owl/families/> Prefix: owl <http://www.w3.org/2002/07/owl#> Prefix: otherOnt <http://example.org/otherOntologies/families/>
<!DOCTYPE Ontology [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > ]> <Ontology xml:base="http://example.com/owl/families/" xmlns="http://www.w3.org/2002/07/owl#" xmlns:owl="http://http://www.w3.org/2002/07/owl#" xmlns:g="http://example.org/otherOntologies/families/" ontologyIRI="http://example.com/owl/families"> ... </Ontology>
It is also common in OWL 2 QLto reuse general information that is inspired bystored in one ontology in other ontologies. Instead of requiring the variantscopying of this information, OWL allows the description logic DL Lite, which emerged from research on database integration. Implementationally, it can be realized on topimport of standard relational database technology (e.g., SQL) simply by expanding queries inthe lightcontents of class axioms. This means it can be tightly integrated with RDBMSs and benefit from their robust implementations and multi-user features. Furthermore, it can be implemented without having to "touch the data", so reallyentire ontologies in other ontologies, using import statements, as a translational/preprocessing layer. Expressively, it can represent key features of Entity-relationship and UML diagrams (at least those withfollows:
Import( http://example.org/otherOntologies/families.owl )
<owl:Ontology rdf:about="http://example.com/owl/families"> <owl:imports rdf:resource="http://example.org/otherOntologies/families.owl" /> </owl:Ontology>
<http://example.com/owl/families> owl:imports <http://example.org/otherOntologies/families.owl> .
Import: <http://example.org/otherOntologies/families.owl>
<Prefix name="otherOnt" IRI="http://example.org/otherOntologies/families/"/> <Import>http://example.org/otherOntologies/families.owl</Import>
As the Semantic Web and ontology construction is distributed, it is suitable bothcommon for representing database schemas andontologies to use different names for integrating them via query rewriting.the same concept, property, or individual. As a result, itwe have seen, several constructs in OWL can alsobe used directly as a high level database schema language, though users may prefer a diagram based syntax. OWL 2 QL also captures many commonlyto state that different names refer to the same class, property, or individual, so, for example, we could – instead of tediously renaming entities – tie the names used featuresin RDFS and small extensions thereof, such as inverse properties and subproperty hierarchies. OWL 2 QL restricts class axioms asymmetrically, that is, you can use constructs asour ontology to the subclass that you cannot usenames used in an imported ontology as the superclass. Among other constructs,follows:
SameIndividual( :John otherOnt:JohnBrown ) SameIndividual( :Mary otherOnt:MaryBrown ) EquivalentClasses( :Adult otherOnt:Grownup ) EquivalentObjectProperties( :hasChild otherOnt:child ) EquivalentDataProperties( :hasAge otherOnt:age )
<rdf:Description rdf:about="John"> <owl:sameAs rdf:resource="&otherOnt;JohnBrown"/> </rdf:Description> <rdf:Description rdf:about="Mary"> <owl:sameAs rdf:resource="&otherOnt;MaryBrown"/> </rdf:Description> <owl:Class rdf:about="Adult"> <owl:equivalentClass rdf:resource="&otherOnt;Grownup"/> </owl:Class> <owl:DatatypeProperty rdf:about="hasAge"> <owl:equivalentProperty rdf:resource="&otherOnt;age"/> </owl:DatatypeProperty> <owl:Class rdf:about="Adult"> <owl:equivalentClass rdf:resource="&otherOnt;Grownup"/> </owl:Class>
:Mary owl:sameAs otherOnt:MaryBrown . :John owl:sameAs otherOnt:JohnBrown . :Adult owl:equivalentClass otherOnt:Grownup . :hasChild owl:equivalentProperty otherOnt:child . :hasAge owl:equivalentProperty otherOnt:age .
SameIndividual: John otherOnt:JohnBrown SameIndividual: Mary otherOnt:MaryBrown EquivalentClasses: Adult otherOnt:Grownup EquivalentProperties: hasChild otherOnt:child EquivalentProperties: hasAge otherOnt:age
<SameIndividuals> <Individual IRI="John"/> <Individual IRI="otherOnt:JohnBrown"/> </SameIndividuals> <SameIndividuals> <Individual IRI="Mary"/> <Individual IRI="otherOnt:MaryBrown"/> </SameIndividuals> <EquivalentClasses> <Class IRI="Adult"/> <Class IRI="otherOnt:Grownup"/> </EquivalentClasses> <EquivalentObjectProperties> <ObjectProperty IRI="hasChild"/> <ObjectProperty IRI="otherOnt:child"/> </EquivalentObjectProperties> <EquivalentDataProperties> <DataProperty IRI="hasAge"/> <DataProperty IRI="otherOnt:age"/> </EquivalentDataProperties>
To help with managing ontologies, OWL 2 QL disallows existential quantificationhas the notion of rolesdeclarations. The basic idea is that each class, property, or individual is supposed to a class expression, i.e.be declared in an ontology, and then it can be statedused in that every person has a parent but notontology and ontologies that every person has a female parent. Moreover property chain axioms are not supported. The following is an example which uses some of the typical modelling features availableimport that ontology.
In OWL 2 QL.the first axiom statesManchester syntax, declarations are implicit. Constructs that every childless person isprovide information about a person for which there does not exist another person which hasclass, property, or individual implicitly declare that class, property, or individual if needed. The first person as parent. SubClassOf( f:ChildlessPerson IntersectionOf( f:Person ComplementOf( SomeValuesFrom( InverseOf( f:hasParentother syntaxes have explicit declarations.
Declaration( NamedIndividual( :John )f:Person) Declaration( Class( :Person ) ) Declaration( ObjectProperty( :hasWife )DisjointClasses(f:Motherf:Fatherf:YoungChild)DisjointProperties(f:hasSonf:hasDaughter)SubObjectPropertyOf(f:hasFatherf:hasParentDeclaration( DataProperty( :hasAge ) )
<owl:NamedIndividual rdf:about="John"/> <owl:Classrdf:about="#ChildlessPerson"><rdfs:subClassOf><owl:Class><owl:intersectionOfrdf:parseType="Collection"><owl:Classrdf:about="#Person"/><owl:Class><owl:complementOf><owl:Restriction><owl:onProperty><owl:ObjectProperty><owl:inverseOfrdf:resource="#hasParent"/></owl:ObjectProperty></owl:onProperty><owl:someValuesFromrdf:resource="#Person"/></owl:Restriction></owl:complementOf></owl:Class></owl:intersectionOf></owl:Class></rdfs:subClassOf></owl:Class><owl:AllDisjointClasses><owl:membersrdf:parseType="Collection"><owl:Classrdf:about="#Mother"/><owl:Classrdf:about="#Father"/><owl:Classrdf:about="#YoungChild"/></owl:members></owl:AllDisjointClasses><owl:ObjectPropertyrdf:about="#hasSon"><owl:propertyDisjointWithrdf:resource="#hasDaughter"/></owl:ObjectProperty>rdf:about="Person"/> <owl:ObjectPropertyrdf:about="#hasFather"><rdfs:subPropertyOfrdf:resource="#hasParent"/></owl:ObjectProperty>f:ChildlessPersonowl:subClassOf_:x1rdf:about="hasWife"/> <owl:DatatypeProperty rdf:about="hasAge"/>
:John rdf:type owl:NamedIndividual ._:x1:Person rdf:typeowl:Class ;owl:intersectionOf(f:Person_:x2)owl:Class ._:x2owl:complementOf_:x3._:x3:hasWife rdf:typeowl:Restriction ;owl:onProperty_:x4 ;owl:someValuesFromf:Person._:x4owl:inverseOff:hasParentowl:ObjectProperty ._:x5:hasAge rdf:typeowl:AllDisjointClasses ;owl:members(f:Motherf:Fatherf:YoungChild)owl:DatatypeProperty .
Individual: John Class:ChildlessPersonSubClassOf:PersonandnotinversehasParentsomePersonDisjointClasses:MotherFatherYoungChildDisjointProperties:hasSonhasDaughterObjectProperty:hasFatherSubPropertyOf:hasParent<owl:SubClassOf><owl:ClassIRI="&f;ChildlessPerson"/><owl:ObjectIntersectionOf><owl:ClassIRI="&f;Person"/><owl:ObjectComplementOf><owl:ObjectSomeValuesFrom><owl:InverseObjectProperty><owl:ObjectPropertyIRI="&f;hasParent"/></owl:InverseObjectProperty><owl:ClassIRI="&f;Person"/></owl:ObjectSomeValuesFrom></owl:ObjectComplementOf></owl:ObjectIntersectionOf></owl:SubClassOf><owl:DisjointClasses><owl:ClassIRI="&f;Father"/><owl:ClassIRI="&f;Mother"/><owl:ClassIRI="&f;YoungChild"/></owl:DisjointClasses><owl:DisjointObjectProperties><owl:ObjectPropertyIRI="&f;hasSon"/><owl:ObjectPropertyIRI="&f;hasDaughter"/></owl:DisjointObjectProperties><owl:SubObjectPropertyOf><owl:ObjectPropertyIRI="&f;hasFather"/><owl:ObjectPropertyIRI="&f;hasParent"/></owl:SubObjectPropertyOf>9.3OWL2RLhasWife Dataproperty: hasAge
<Declaration> <NamedIndividual IRI="John"/> </Declaration> <Declaration> <Class IRI="Person"/> </Declaration> <Declaration> <ObjectProperty IRI="hasWife"/> </Declaration> <Declaration> <DataProperty IRI="hasAge"/> </Declaration>
However, an IRI may denote different entity-types (e.g. both an individual and a class) at the same time. This possibility, called “punning,” has been introduced to allow for a certain amount of metamodeling; we give an example of this in Section 9. Still, OWL 2 RL profile is aimed at applications thatdoes require scalable reasoning without sacrificing too much expressive power. It is designedsome discipline in using and reusing names. To accommodate bothallow a more readable syntax, and for other technical reasons, OWL 2 applicationsDL requires that can trade the full expressivity of the languagea name is not used for efficiency,more than one property type (object, datatype or annotation property) nor can an IRI denote both a class and RDF(S) applications that need some added expressivity from OWL 2. This is achieved by defininga syntactic subsetdatatype. Moreover, “built-in” names (such as those used by RDF and RDFS and various syntaxes of OWL) cannot be freely used in OWL.
There are two alternative ways of assigning meaning to ontologies in OWL 2 called the direct model-theoretic semantics [OWL 2 RDF-BasedDirect Semantics in] and the form of first-order implications that can be used as the basis for such an implementation. The design of OWL 2 RL has been inspired by Description Logic Programs [DLP] and pD* [pD*]. Suitable rule-based implementations ofRDF-based semantics [OWL 2 RL will have desirable computational properties; for example, they can return all and onlyRDF-Based Semantics]. Informally, the correct answers to certain kinds of queries. Such an implementation can also be used with arbitrary RDF graphs. (In this case, however, these properties no longer hold — in particular, itnotion "OWL 2 DL" is no longer possibleused to refer to guarantee that all correct answers can be returned.) As a consequence,OWL 2 RLontologies interpreted using the direct semantics, and the notion "OWL 2 Full" is ideal for enriching RDF data, especiallyused when considering the dataRDF-based semantics. The OWL 2 functional-style syntax document [OWL 2 Specification] additionally lists a few conditions which must be massagedmet by additional rules. From a modeling perspective, however, this pushes us farther away from working with class expressions:an OWL 2 RL ensures we cannot (easily) talk about unknown individuals in our superclass expressions (this restriction follows fromontology to qualify as OWL 2 DL.
The nature of rules). Compared withdirect model-theoretic semantics [OWL 2 QL,Direct Semantics] provides a meaning for OWL 2 RL works better when you have already massaged your data into RDF and are working with it as RDF. One downside ofin a [Description Logic] style. The RDF-based semantics [OWL 2 RLRDF-Based Semantics] is that it cannot express that the existence ofan individual enforces the existenceextension of another individual: for instance,the statement "every person has a parent"semantics for RDFS [RDF Semantics] and is not expressible in OWL RL.based on viewing OWL 2 RL restricts class axioms asymmetrically, that is, you can use constructsontologies as RDF graphs.
When thinking about ontologies the subclassdifferences between these two semantics are generally quite slight. Indeed, given an OWL 2 DL ontology, inferences drawn using the direct semantics remain valid inferences under the RDF-based semantics - see the correspondence theorem in Section 7.2 of the RDF-based semantics document [OWL 2 RDF-Based Semantics]. The two main differences are that you cannot use asunder the superclass.direct model-theoretic semantics annotations have no formal meaning and under the following is an example which usesRDF-based semantics there are some extra inferences that arise from the RDF view of the typical modelling features availableuniverse.
Conceptually, we can think of the difference between OWL 2 DL and OWL 2 Full in two ways:
Of OWL 2 can be found incourse, the OWL 2 Semantics document [ OWL 2two semantics ],have been designed together and the mapping betweenthus have influenced each other. For example, one design goal of OWL syntax and RDF triples can be found in the2 was to bring OWL 2 MappingDL syntactically closer to RDF Graphs document [OWL 2 Full (that is, to allow more RDF Mapping ]. 12 Appendices 12.1 How OWLGraphs/OWL 2 relatesFull ontologies to other technologies Editor's Note: This section willbe rewritten in similar spiritlegal OWL is a language for expressing ontologies .2 DL ontologies). This led to the term ontology has a complex history both in and outincorporation of computer science, but we use it to meanso-called punning into OWL 2, e.g., using the same IRI as a certain kind of computational artifact -- i.e., something akin toname for both a program,class and an XML schema, or a web page -- generally presented as a document.individual. An ontology is a set of descriptive statements about some part of the world (usually referred to as the domain or the subject matterexample of such usage would be the ontology). The descriptive nature of OWL is worth emphasizing: Unlike schema languages or object-oriented programming languages, OWL is not particularly prescriptive. For example, a primary task of an XML Schemafollowing, which states that John is prescribing what elements can occur as children of other elements. Typically,a schema is used to validatefather, and that father is a document conforms to the restrictions expressed in the schema. Similarly, an XML Schema is, to a first approximation, about XML documents.social role.
ClassAssertion( :Father :John ) ClassAssertion( :SocialRole :Father )
<Father rdf:about="John"/> <SocialRole rdf:about="Father"/>
:John rdf:type :Father . :Father rdf:type :SocialRole .
Individual: John Types: Father Individual: Father Types: SocialRole
<ClassAssertion> <Class URI="Father"/> <NamedIndividual IRI="John"/> </ClassAssertion> <ClassAssertion> <Class URI="SocialRole"/> <NamedIndividual IRI="Father"/> </ClassAssertion>
Note that is,in the basic XML Schema perspectivefirst statement, Father is that there are elements, attributes, namespaces, and other features of XML andused as a Schema describesclass, while in the permitted ways to use such featuressecond it is used as an individual. In this sense, SocialRole acts as a metaclass for the class Father.
In OWL 1, a document or data format.containing these two statements would be an OWL 1 Full document, but not an OWL 1 DL document. In contrast, the basicOWL perspective2 DL, however, this is allowed. It must be noted, though, that there are things (in a broad sensethe direct model-theoretic semantics of OWL 2 DL accommodates this by understanding the term) thatclass Father and the individual Father as two different views on the same IRI, i.e. they are relatedinterpreted semantically as if they were distinct.
In addition to other thingsOWL 2 DL and mayOWL 2 Full, OWL 2 specifies three profiles. OWL 2, in general, is a very expressive language (both computationally and for users) and thus can be grouped into sets of things accordingdifficult to their commonality. Whetherimplement well and to work with. These thingsadditional profiles are physical objects or data items depends on the intent of the modeler. Of course, it is perfectly possible to use XML Schema to describe the "Tree Mark Up" (TML) language and use TMLdesigned to record information about trees. But there is a level of indirection in this usebe approachable subsets of XML Schema. The XML SchemaOWL 2 sufficient for TML is (most directly)a modelvariety of applications. As with OWL 2 DL, computational considerations are a setmajor requirement of XML documents (which themselvesthese profiles (and they are intendedall much easier to represent trees). An OWL ontology about trees is most directly a model of a setimplement with robust scalability given existing technology), but there are many subsets of things (in this case trees), their relations,OWL 2 that have good computational properties. The selected OWL 2 profiles were identified as having substantial user communities already, although there were several others not included and their categorizations.one interesting feature of XML's separation of well-formedness and validity isshould expect more to weakenemerge. The general prescriptiveness of schema languages. Unlike SGML, XML does not require that an XML document is valid against at least one schema.[OWL is much less suitable2 Profiles] document provides a clear template for validation.specifying additional profiles.
In order to guarantee for example, suppose we definescalable reasoning, the class Citizenexisting profiles share some limitations regarding their expressiveness. In general, they disallow negation and disjunction, as these constructs complicate reasoning and have shown to be those things that have a parent which is also a Citizen (assuming we have some bootstrap conditiononly rarely needed for founding citizens; we ignore that part of the definitionmodeling. For example, in none of the moment). The definition might look something like: Show examples using: Manchester Functional OWL XML RDF XML Turtle Example not shown here. Select a check boxprofiles it is possible to showspecify that every person is male or female.
Further specific modeling restrictions of the exampleprofiles will be dealt with in the given language. --> Manchester Syntax: Class: Citizen EquivalentTo: hasParent some Citizen Read prescriptively, we would expect thatsections on the following assertionindividual profiles.
We discuss each profile and its design rationale, and provide some guidance for users in selecting which profile to work with. Please be invalid (incorrect, inconsistent) in light ofaware that this definition: Show examples using: Manchester Functional OWL XML RDF XML Turtle Example not shown here. Select a check box to show the example in the given language. --> Manchester Syntax: Individual: Sheevah Types: Citizen Since this says that Sheevahdiscussion is a Citizen but doesn't tell us anything about her parents. That is, the definition doesnot force us to include information about Sheevah's parents in ordercomprehensive, nor can it be. Part of any decision has to claimbe based on available tooling and how that she is a Citizen. Show examples using: Manchester Functional OWL XML RDF XML Turtle Example not shown here. Select a check box to show the examplefits in with the given language. --> Manchester Syntax: Individual: Sheevah Types: Citizen Facts: hasParent Suma While we have not said anything about Suma's citizenship, we have not ruled out that she is a Citizen. Everything we have said about Sheevah is consistentrest of your system or workflow.
By and large, different profiles can be distinguished syntactically with herthere being a Citizen, thus, from aninclusion relations between various profiles. For example, OWL perspective, there is no problem. In2 DL can be seen as a prescriptive system, missing information generallysyntactic fragment of OWL 2 Full and OWL 2 QL is a problem orsyntactic fragment of OWL 2 DL (and thus of OWL 2 Full). Ideally, one can use a relatively rare occurrence.reasoner (or other tool) that is conforming for example, in RDBMs systema superprofile on the most common way of dealingsubprofile with missing information is to have special values , i.e., null values. That is, we must explictly say what we do not know.no change in OWL, everything not explictly saidthe results derived. For profiles such as OWL 2 EL and not explicitly ruled out is considered possible.OWL 2 is,QL in many respects, similarrelation to many other technologies: in particular,OWL uses a class-object paradigm which aligns it (to some degree) with object oriented programming and entity-relationship diagrams. Furthermore, it2 DL this principle does hold: Every conforming OWL 2 DL reasoner is hasan XML based concrete syntax as well as an RDF one, making it easyOWL 2 EL and OWL 2 QL reasoner (but may differ in performance since the OWL 2 DL reasoner is tuned for people familiara more general set of cases).
Working with those technologiesOWL 2 EL is fairly similar to project features from them onto OWL. In general, people familiarworking with other technologies are sometimes misled by the similaritiesOWL 2 DL: one can use class expressions on both sides of a subClassStatement and thus very surprisedeven infer such relations. For many class expression oriented ontologies, OWL 2 EL makes a good approximation target, that is, by the differences. Inonly a little simplification one can get an appendix , we provide discussions ofOWL from the lens of related or contrasting technologies, including RDF , XML , object oriented programming , databases ,2 EL ontology and preserve much of the prior versionmeaning of OWL,the original ontology.
OWL 1 . If you are familiar2 EL is designed with anylarge biohealth ontologies in mind, such as SNOMED-CT, the NCI thesaurus, and Galen. Common characteristics of these technologies, we recommend readingsuch ontologies include complex structural descriptions (e.g., defining certain body parts in terms of what parts they contain and are contained in or propagating diseases along part-subpart relations), huge numbers of classes, the relevant sectionheavy use of classification to manage the appendix before proceeding withterminology, and the restapplication of the primer. Editor's Note: The Working Group is committedresulting terminology to making these technology-specific sections be accessible by usersvast amounts of those technology. We particularly solicit comments on whether this is the case and how to make them moreso. Editor's Note: There isdata. Thus, OWL 2 EL has a proposal for having technology and application tips, notes,comparatively expressive class expression language and tricks scattered throughout the document,it has no restrictions on how they may be used in axioms. It also has fairly expressive property expressions, including property chains but with optional display. Thus, as with the syntax, different users can configure the document to their tastes and needs. 12.1.1 RDF(S)excluding inverse.
Sensible use of the technologies discussed in this section, the Resource Description Framework (RDF) and the RDF Schema (RDFS) Language (collectively referred to as RDF(S))OWL 2 EL is the closestobviously not restricted to OWL. RDF(S) has roots in logic based knowledge representation; in many ways, RDF(S) can be seenthe biohealth domain: as a subset of OWL; and, perhaps most prominently,with the primary exchange syntax forother profiles, OWL has been RDF/XML.2 EL is domain independent. However, there are differencesOWL 2 EL shines when your domain and your application require recognition of style, emphasis,structurally complex objects. Such domains include system configurations, product inventories, and common practice that can make relying on RDF(S) intuitions misleading when working with OWL. For example, while OWL statementsmany scientific domains.
Besides negation and expressions can be encoded as RDF facts (triples), viewing mostdisjunction, OWL statements and expressions2 EL also disallows universal quantification on properties. Therefore propositions like “all children of a rich person are rich” cannot be stated. Moreover, as collectionsall kinds of facts isrole inverses are not typically a fruitfulavailable, there is no way of writing or understanding them. Similarly, it is fairly commonspecifying that, say, parentOf and effective to work with RDF as a graph data structure or database where the primary focus is on the explicit statements in the graph. Even when we consider partschildOf are inverses of RDFS which support implicit knowledge, such as determining subclass relationships, the relation betweeneach other.
The explicit and implicit statements is very direct. Thus, itfollowing is easy to conceptualize inference in terms of graph structure manipulation. In contrast, determining implicit knowledge in OWL, including determining subclass relationships and typing and checking consistency ofan ontology, requires techniques that are much more akin to theorem proving. 12.1.2 SPARQL 12.1.3 XML OWL and the XML family of technologies shareexample which uses some common parts: OWL can be expressedof the typical modeling features available in XML languages (such asOWL 2 EL.
SubClassOf( :Father ObjectIntersectionOf( :Man :Parent ) ) EquivalentClass( :Parent ObjectSomeValuesFrom( :hasChild :Person ) ) EquivalentClasses( :NarcisticPerson ObjectHasSelf( :loves ) ) DisjointClasses( :Mother :Father :YoungChild ) SubObjectPropertyOf( ObjectPropertyChain( :hasFather :hasBrother ) :hasUncle ) NegativeObjectPropertyAssertion( :hasDaughter :Bill :Susan )
forOWL<owl:Class rdf:about="Father"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Man"/> <owl:Class rdf:about="Parent"/> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="Parent"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="hasChild"/> <owl:someValuesFrom rdf:resource="Person"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="NarcisticPerson"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="loves"/> <owl:hasSelf rdf:datatype="&xsd;boolean"> true </owl:hasSelf> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class rdf:about="Mother"/> <owl:Class rdf:about="Father"/> <owl:Class rdf:about="YoungChild"/> </owl:members> </owl:AllDisjointClasses> <rdf:Description rdf:about="hasUncle"> <owl:propertyChainAxiom rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasFather"/> <owl:ObjectProperty rdf:about="hasBrother"/> </owl:propertyChainAxiom> </rdf:Description> <owl:NegativePropertyAssertion> <owl:sourceIndividual rdf:about="Bill"/> <owl:assertionProperty rdf:about="hasDaughter"/> <owl:targetIndividual rdf:about="Susan"/> </owl:NegativePropertyAssertion>
:Father rdfs:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Man :Parent ) ] . :Parent owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] . :NarcisticPerson owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :loves ; owl:hasSelf true ] . [] rdf:type owl:AllDisjointClasses ; owl:members ( :Mother :Father :YoungChild ) . :hasUncle owl:propertyChain ( :hasFather :hasBrother ) . [] rdf:type owl:NegativePropertyAssertion ; owl:sourceIndividual :Bill ; owl:assertionProperty :hasDaughter ; owl:targetIndividual :Susan .
Class: Father SubClassOf: Man andthusbemanipulatedbyXMLtools.OWLreusesdatatypesanddatatypederivationfacetsfromXMLSchema(andcanusecertainformsofXMLSchematypedefinitions).Finally,OWLandXMLcanbothbeusedforconceptualmodelingaswellasdatadefinition,thoughtheywaystheygoaboutitarefairlydistinctandParent Class: Parent EquivalentTo: hasChild some Person Class: NarcisticPerson EquivalentTo: loves Self DisjointClasses: Mother Father YoungChild ObjectProperty: hasUncle SubPropertyChain: hasFather o hasBrother Individual: Bill Facts: not hasDaughter Susan
<SubClassOf> <Class IRI="Father"/> <ObjectIntersectionOf> <Class IRI="Man"/> <Class IRI="Parent"/> </ObjectIntersectionOf> </SubClassOf> <EquivalentClasses> <Class IRI="Parent"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Person"/> </ObjectSomeValuesFrom> </EquivalentClasses> <EquivalentClasses> <Class IRI="NarcisticPerson"/> <ObjectHasSelf> <ObjectProperty IRI="loves"/> </ObjectHasSelf> </EquivalentClasses> <DisjointClasses> <Class IRI="Father"/> <Class IRI="Mother"/> <Class IRI="YoungChild"/> </DisjointClasses> <SubObjectPropertyOf> <PropertyChain> <ObjectProperty IRI="hasFather"/> <ObjectProperty IRI="hasBrother"/> </PropertyChain> <ObjectProperty IRI="hasUncle"/> </SubObjectPropertyOf> <NegativeObjectPropertyAssertion> <ObjectProperty IRI="hasDaughter"/> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="Susan"/> </NegativeObjectPropertyAssertion>
OWL is designed to support the discovery2 QL can be realized on top of relationships between classes through automated reasoning. OWL also buildsstandard relational database technology (e.g., SQL) simply by expanding queries in far fewer presumptions aboutthe entities it is describing both generally and in termslight of their physical realization in computational systems. Both OWL and XML Schema support strong abstraction facilities. However XML Schema, is much more concernedclass axioms. This means it can be tightly integrated with the data organization issues relating to its core mission of validating XML documents. 12.1.4 Databases Databases (either relational or object-oriented) also storeRDBMSs and organize information. However, databases are oriented to environments where all information that an application needs is available, where considerations of data integrity in situations of simultaneous accessbenefit from their robust implementations and update are important, or where very large amounts of data needs tomulti-user features. Furthermore, it can be worked with. OWL is more oriented towards flexible and expressive description of data (or information), and only considers informationimplemented without having to be complete if“touch the completenessdata,” so really as a translational/preprocessing layer. Expressively, it can be determined from other information. Ontologies in OWL are much more powerfulrepresent key features of Entity-relationship and flexible than database schemas.UML diagrams (at least those with functional restrictions). Thus, it is suitable both for representing database schemas generally only shape the kinds of information that is associated with objects (or tuples) that belong toand for integrating them via query rewriting. As a class (or table). Classes in OWL ontologiesresult, it can do this, butalso can provide recognition conditions so that explicit typing is not required in OWL. Of course this flexibility means that determining typing in OWL can require complex inferences. A final major difference between databases and OWL is that the information stored inbe used directly as a database is derived from thehigh level database schema language, though users may prefer a diagram based syntax.
OWL 2 QL also captures many commonly used features in RDFS and integrity constraints - if the schema doesn't sanction the storage of certain kinds of information, thensmall extensions thereof, such as inverse properties and subproperty hierarchies. OWL 2 QL restricts class axioms asymmetrically, that information cannot be stored, and, similarly, ifis, you can use constructs as the information violates an integrity constraint it alsosubclass that you cannot be stored. OWL, onuse as the superclass.
Among other hand, allows arbitrary informationconstructs, OWL 2 QL disallows existential quantification of roles to be associated with just about any object - if there is nothing in the ontology forbidding the associated thena class expression, i.e. it is allowable. OWL is thus much more flexible in its information storage. 12.1.5 Object-oriented Programming Object-oriented programming (OOP) alsocan be stated that every person has object-centered modeling characteristics, and thusa parent but not that every person has much in common with OWL. However, OOP generally is performed in complete-information contexts, and wherea female parent. Moreover property chain axioms are not supported.
The information that can possibly be known about an objectfollowing is circumscribed by the information in the typean example which uses some of the object. As with databases,typical modeling features available in OWL 2 QL. The differing stances on completeness and object informationfirst axiom states that every childless person is a major difference between OWLperson for which there does not exist anybody who has the first person as parent.
SubClassOf( :ChildlessPerson ObjectIntersectionOf( :Person ObjectComplementOf( ObjectSomeValuesFrom( ObjectInverseOf( :hasParent ) owl:Thing ) ) ) ) DisjointClasses( :Mother :Father :YoungChild ) DisjointObjectProperties( :hasSon :hasDaughter ) SubObjectPropertyOf( :hasFather :hasParent )
<owl:Class rdf:about="ChildlessPerson"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Person"/> <owl:Class> <owl:complementOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty> <owl:inverseOf rdf:resource="hasParent"/> </owl:ObjectProperty> </owl:onProperty> <owl:someValuesFrom rdf:resource="Person"/> </owl:Restriction> </owl:complementOf> </owl:Class> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class rdf:about="Mother"/> <owl:Class rdf:about="Father"/> <owl:Class rdf:about="YoungChild"/> </owl:members> </owl:AllDisjointClasses> <owl:ObjectProperty rdf:about="hasSon"> <owl:propertyDisjointWith rdf:resource="hasDaughter"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="hasFather"> <rdfs:subPropertyOf rdf:resource="hasParent"/> </owl:ObjectProperty>
:ChildlessPerson owl:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Person [ owl:complementOf [ rdf:type owl:Restriction ; owl:onProperty [ owl:inverseOf :hasParent ] ; owl:someValuesFrom owl:Thing ] ] ) ] . [] rdf:type owl:AllDisjointClasses ; owl:members ( :Mother :Father :YoungChild ) . :hasSon owl:propertyDisjointWith :hasDaughter. :hasFather rdfs:subPropertyOf :hasParent.
Class: ChildlessPerson SubClassOf: Person andOOP.SimilarlyOOPclassesaremuchlessexpressivethannot inverse hasParent some owl:Thing DisjointClasses: Mother Father YoungChild DisjointProperties: hasSon hasDaughter ObjectProperty: hasFather SubPropertyOf: hasParent
<SubClassOf> <Class IRI="ChildlessPerson"/> <ObjectIntersectionOf> <Class IRI="Person"/> <ObjectComplementOf> <ObjectSomeValuesFrom> <InverseObjectProperty> <ObjectProperty IRI="hasParent"/> </InverseObjectProperty> <Class abbreviatedIRI="owl:Thing"/> </ObjectSomeValuesFrom> </ObjectComplementOf> </ObjectIntersectionOf> </SubClassOf> <DisjointClasses> <Class IRI="Father"/> <Class IRI="Mother"/> <Class IRI="YoungChild"/> </DisjointClasses> <DisjointObjectProperties> <ObjectProperty IRI="hasSon"/> <ObjectProperty IRI="hasDaughter"/> </DisjointObjectProperties> <SubObjectPropertyOf> <ObjectProperty IRI="hasFather"/> <ObjectProperty IRI="hasParent"/> </SubObjectPropertyOf>
The OWL 2 RL profile is a strictly declarative and logical language.aimed at applications that require scalable reasoning without sacrificing too much expressive power. It is designed to accommodate both OWL therefore has none of2 applications that can trade the operational aspectsfull expressivity of OOP, like methods,the language for efficiency, and similarly reasoning in OWL is strictly logical, with nothing comparing to inheritance , particularly inheritance with exceptions or overriding.RDF(S) applications that need some added expressivity from OWL 2. This is used inachieved by defining a numbersyntactic subset of different waysOWL 2 which is amenable to implementation using rule-based technologies, and forpresenting a numberpartial axiomatization of different domains -- far too many to enumerate here. But it's worth examining a few examples to getthe OWL 2 RDF-Based Semantics in the form of first-order implications that can be used as the basis for such an implementation.
Suitable rule-based implementations of OWL 2 RL can be used with arbitrary RDF graphs. As a feelconsequence, OWL 2 RL is ideal for enriching RDF data, especially when the sortsdata must be massaged by additional rules. From a modeling perspective, however, this pushes us farther away from working with class expressions: OWL 2 RL ensures we cannot (easily) talk about unknown individuals in our superclass expressions (this restriction follows from the nature of rules). Compared with OWL 2 QL, OWL 2 RL works better when you have already massaged your data into RDF and are working with it as RDF.
One downside of problemOWL 2 RL is that it cannot express that the existence of an individual enforces the existence of another individual: for instance, the statement “every person has worked well for. Using alla parent” is not expressible in OWL RL.
OWL 2 RL restricts class axioms asymmetrically, that is, you can use constructs as the subclass that you cannot use as the superclass. The following is an example which uses some of the typical modeling features available in OWL 2 RL. The first – somewhat contrived – axiom states that for each of Mary, Bill, and Meg who is female, the following holds: she is a parent with at most one child, and all her children (if she has any) are female.
SubClassOf( ObjectIntersectionOf( ObjectOneOf( :Mary :Bill :Meg ) :Female ) ObjectIntersectionOf( :Parent ObjectMaxCardinality( 1 :hasChild ) ObjectAllValuesFrom( :hasChild :Female ) ) ) DisjointClasses( :Mother :Father :YoungChild ) SubObjectPropertyOf( ObjectPropertyChain( :hasFather :hasBrother ) :hasUncle )
<owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:about="Mary"/> <rdf:Description rdf:about="Bill"/> <rdf:Description rdf:about="Meg"/> </owl:oneOf> </owl:Class> <owl:Class rdf:about="Female"/> </owl:intersectionOf> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Parent"/> <owl:Restriction> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger"> 2 </owl:maxCardinality> <owl:onProperty rdf:resource="hasChild"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="hasChild"/> <owl:allValuesFrom rdf:resource="Female"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class rdf:about="Mother"/> <owl:Class rdf:about="Father"/> <owl:Class rdf:about="YoungChild"/> </owl:members> </owl:AllDisjointClasses> <rdf:Description rdf:about="hasUncle"> <owl:propertyChainAxiom rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasFather"/> <owl:ObjectProperty rdf:about="hasBrother"/> </owl:propertyChainAxiom> </rdf:Description>
[] rdf:type owl:Class ; owl:intersectionOf ( [ rdf:type owl:Class ; owl:oneOf ( :Mary :Bill :Meg ) ] :Female ) ; rdfs:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Parent [ rdf:type owl:Restriction ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ] [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:allValuesFrom :Female ] ) ] . [] rdf:type owl:AllDisjointClasses ; owl:members ( :Mother :Father :YoungChild ) . :hasUncle owl:propertyChain ( :hasFather :hasBrother ) .
Class: X SubClassOf: Parent and hasChild max 1 and hasChild only Female Class: X EquivalentTo: {Mary Bill Meg} and Female DisjointClasses: Mother Father YoungChild ObjectProperty: hasUncle SubPropertyChain: hasFather o hasBrother
<SubClassOf> <ObjectIntersectionOf> <ObjectOneOf> <NamedIndividual IRI="Mary"/> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="Meg"/> </ObjectOneOf> <Class IRI="Female"/> </ObjectIntersectionOf> <ObjectIntersectionOf> <Class IRI="Parent"/> <ObjectMaxCardinality cardinality="1"> <ObjectProperty IRI="hasChild"/> </ObjectMaxCardinality> <ObjectAllValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Female"/> </ObjectAllValuesFrom> </ObjectIntersectionOf> </SubClassOf> <DisjointClasses> <Class IRI="Father"/> <Class IRI="Mother"/> <Class IRI="YoungChild"/> </DisjointClasses> <SubObjectPropertyOf> <PropertyChain> <ObjectProperty IRI="hasFather"/> <ObjectProperty IRI="hasBrother"/> </PropertyChain> <ObjectProperty IRI="hasUncle"/> </SubObjectPropertyOf>
This short primer can only scratch the surface of OWL. There are many longer and more involved tutorials on OWL and how to use OWL tools that can be found by searching on the Web. Reading one of these documents and using a tool to build an OWL ontology is probably the best way to learn more about OWL.
This short primer is also not a normative definition of OWL. The normative definition of the OWL syntax as well as informative descriptions of the meaning of each OWL construct can be found in the OWL 2 Structural Specification and Functional Syntax document [OWL 2 Specification].
The OWL 2 Quick Reference Guide [OWL 2 Quick Guide] comes handy as a reference when looking for information about a specific language feature.
For those interested in more formal documents, the formal meaning of OWL 2 can be found in the OWL 2 Semantics documents: [OWL 2 Direct Semantics] and [OWL 2 RDF-Based Semantics].
The mapping between OWL syntax and RDF triples can be found in the OWL 2 Mapping to RDF Graphs document [OWL 2 RDF Mapping].
Here we include the complete sample OWL ontology. Ontological axioms are ordered by top-level expressive features they use. Moreover, we follow a commonly-used ordering, with ontology and declaration information first, followed by information about properties, then classes and datatypes, then individuals.
Prefix(:=<http://example.com/owl/families/>) Prefix(otherOnt:=<http://example.org/otherOntologies/families/>) Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>) Prefix(owl:=<http://www.w3.org/2002/07/owl#>) Ontology(<http://example.com/owl/families> Import( http://example.org/otherOntologies/families.owl ) Declaration( NamedIndividual( :John ) ) Declaration( NamedIndividual( :Mary ) ) Declaration( NamedIndividual( :Jim ) ) Declaration( NamedIndividual( :James ) ) Declaration( NamedIndividual( :Jack ) ) Declaration( NamedIndividual( :Bill ) ) Declaration( NamedIndividual( :Susan ) ) Declaration( Class( :Person ) ) AnnotationAssertion( rdfs:comment :Person "Represents the set of all people." ) Declaration( Class( :Woman ) ) Declaration( Class( :Parent ) ) Declaration( Class( :Father ) ) Declaration( Class( :Mother ) ) Declaration( Class( :SocialRole ) ) Declaration( Class( :Man ) ) Declaration( Class( :Teenager ) ) Declaration( Class( :ChildlessPerson ) ) Declaration( Class( :Human ) ) Declaration( Class( :Female ) ) Declaration( Class( :HappyPerson ) ) Declaration( Class( :JohnsChildren ) ) Declaration( Class( :NarcisticPerson ) ) Declaration( Class( :MyBirthdayGuests ) ) Declaration( Class( :Dead ) ) Declaration( Class( :Orphan ) ) Declaration( Class( :Adult ) ) Declaration( Class( :YoungChild ) ) Declaration( ObjectProperty( :hasWife ) ) Declaration( ObjectProperty( :hasChild ) ) Declaration( ObjectProperty( :hasDaughter ) ) Declaration( ObjectProperty( :loves ) ) Declaration( ObjectProperty( :hasSpouse ) ) Declaration( ObjectProperty( :hasGrandparent ) ) Declaration( ObjectProperty( :hasParent ) ) Declaration( ObjectProperty( :hasBrother ) ) Declaration( ObjectProperty( :hasUncle ) ) Declaration( ObjectProperty( :hasSon ) ) Declaration( ObjectProperty( :hasAncestor ) ) Declaration( ObjectProperty( :hasHusband ) ) Declaration( DataProperty( :hasAge ) ) Declaration( DataProperty( :hasSSN ) ) Declaration( Datatype( :personAge ) ) Declaration( Datatype( :majorAge ) ) Declaration( Datatype( :toddlerAge ) ) SubObjectPropertyOf( :hasWife :hasSpouse ) SubObjectPropertyOf( ObjectPropertyChain( :hasParent :hasParent ) :hasGrandparent ) SubObjectPropertyOf( ObjectPropertyChain( :hasFather :hasBrother ) :hasUncle ) SubObjectPropertyOf( :hasFather :hasParent ) EquivalentObjectProperties( :hasChild otherOnt:child ) InverseObjectProperties( :hasParent :hasChild ) EquivalentDataProperties( :hasAge otherOnt:age ) DisjointObjectProperties( :hasSon :hasDaughter ) ObjectPropertyDomain( :hasWife :Man ) ObjectPropertyRange( :hasWife :Woman ) DataPropertyDomain( :hasAge :Person ) DataPropertyRange( :hasAge xsd:NonNegativeInteger ) SymmetricObjectProperty( :hasSpouse ) AsymmetricObjectProperty( :hasChild ) DisjointObjectProperties( :hasParent :hasSpouse ) ReflexiveObjectProperty( :hasRelative ) IrreflexiveObjectProperty( :parentOf ) FunctionalObjectProperty( :hasHusband ) InverseFunctionalObjectProperty( :hasHusband ) TransitiveObjectProperty( :hasAncestor ) FunctionalDataProperty( :hasAge ) SubClassOf( :Woman :Person ) SubClassOf( :Mother :Woman ) SubClassOf( :Grandfather ObjectIntersectionOf( :Man :Parent ) ) SubClassOf( :Teenager ObjectSomeValuesFrom( :hasAge DatatypeRestriction( xsd:integer xsd:minInclusive "13"^^xsd:integer xsd:maxInclusive "19"^^xsd:integer ) ) ) SubClassOf( Annotation( rdfs:comment "States that every man is a person." ) :Man :Person ) SubClassOf( :Father ObjectIntersectionOf( :Man :Parent ) ) SubClassOf( :ChildlessPerson ObjectIntersectionOf( :Person ObjectComplementOf( ObjectSomeValuesFrom( ObjectInverseOf( :hasParent ) owl:Thing ) ) ) ) SubClassOf( ObjectIntersectionOf( ObjectOneOf( :Mary :Bill :Meg ) :Female ) ObjectIntersectionOf( :Parent ObjectMaxCardinality( 1 :hasChild ) ObjectAllValuesFrom( :hasChild :Female ) ) ) EquivalentClasses( :Person :Human ) EquivalentClasses( :Mother ObjectIntersectionOf( :Woman :Parent ) ) EquivalentClasses( :Parent ObjectUnionOf( :Mother :Father ) ) EquivalentClasses( :ChildlessPerson ObjectIntersectionOf( :Person ObjectComplementOf( :Parent ) ) ) EquivalentClasses( :Parent ObjectSomeValuesFrom( :hasChild :Person ) ) EquivalentClasses( :HappyPerson ObjectIntersectionOf( ObjectAllValuesFrom( :hasChild :HappyPerson ) ObjectSomeValuesFrom( :hasChild :HappyPerson ) ) ) EquivalentClasses( :JohnsChildren ObjectHasValue( :hasParent :John ) ) EquivalentClasses( :NarcisticPerson ObjectHasSelf( :loves ) ) EquivalentClasses( :MyBirthdayGuests ObjectOneOf( :Bill :John :Mary) ) EquivalentClasses( :Orphan ObjectAllValuesFrom( ObjectInverseOf( :hasChild ) :Dead ) ) EquivalentClasses( :Adult otherOnt:Grownup ) EquivalentClass( :Parent ObjectSomeValuesFrom( :hasChild :Person ) ) DisjointClasses( :Woman :Man ) DisjointClasses( :Mother :Father :YoungChild ) HasKey( :Person () ( :hasSSN ) ) DatatypeDefinition( :personAge DatatypeRestriction( xsd:integer xsd:minInclusive "0"^^xsd:integer xsd:maxInclusive "150"^^xsd:integer ) ) DatatypeDefinition( :majorAge DataIntersectionOf( :personAge DataComplementOf( :minorAge ) ) ) DatatypeDefinition( :toddlerAge DataOneOf( "1"^^xsd:integer "2"^^xsd:integer ) ) ClassAssertion( :Person :Mary ) ClassAssertion( :Woman :Mary ) ClassAssertion( ObjectIntersectionOf( :Person ObjectComplementOf( :Parent ) ) :John ) ClassAssertion( ObjectMaxCardinality( 4 :hasChild :Parent ) :John ) ClassAssertion( ObjectMinCardinality( 2 :hasChild :Parent ) :John ) ClassAssertion( ObjectExactCardinality( 3 :hasChild :Parent ) :John ) ClassAssertion( ObjectExactCardinality( 5 :hasChild ) :John ) ClassAssertion( :Father :John ) ClassAssertion( :SocialRole :Father ) ObjectPropertyAssertion( :hasWife :John :Mary ) NegativeObjectPropertyAssertion( :hasWife :Bill :Mary ) NegativeObjectPropertyAssertion( :hasDaughter :Bill :Susan ) DataPropertyAssertion( :hasAge :John "51"^^xsd:integer ) NegativeDataPropertyAssertion( :hasAge :Jack "53"^^xsd:integer ) SameIndividual( :John :Jack ) SameIndividual( :John otherOnt:JohnBrown ) SameIndividual( :Mary otherOnt:MaryBrown ) DifferentIndividuals( :John :Bill ) )
<!DOCTYPE rdf:RDF [ <!ENTITY owl "http://www.w3.org/2002/07/owl#" > <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" > <!ENTITY otherOnt "http://example.org/otherOntologies/families/" > ]> <rdf:RDF xml:base="http://example.com/owl/families/" xmlns="http://example.com/owl/families/" xmlns:otherOnt="http://example.org/otherOntologies/families/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#"> <owl:Ontology rdf:about="http://example.com/owl/families"> <owl:imports rdf:resource="http://example.org/otherOntologies/families.owl" /> </owl:Ontology> <owl:ObjectProperty rdf:about="hasWife"> <rdfs:subPropertyOf rdf:resource="hasSpouse"/> <rdfs:domain rdf:resource="Man"/> <rdfs:range rdf:resource="Woman"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="hasParent"> <owl:inverseOf rdf:resource="hasChild"/> <owl:propertyDisjointWith rdf:resource="hasSpouse"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="hasSon"> <owl:propertyDisjointWith rdf:resource="hasDaughter"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="hasFather"> <rdfs:subPropertyOf rdf:resource="hasParent"/> </owl:ObjectProperty> <owl:SymmetricProperty rdf:about="hasSpouse"/> <owl:AsymmetricProperty rdf:about="hasChild"/> <owl:ReflexiveProperty rdf:about="hasRelative"/> <owl:IrreflexiveProperty rdf:about="parentOf"/> <owl:FunctionalProperty rdf:about="hasHusband"/> <owl:InverseFunctionalProperty rdf:about="hasHusband"/> <owl:TransitiveProperty rdf:about="hasAncestor"/> <rdf:Description rdf:about="hasGrandparent"> <owl:propertyChainAxiom rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasParent"/> <owl:ObjectProperty rdf:about="hasParent"/> </owl:propertyChainAxiom> </rdf:Description> <rdf:Description rdf:about="hasUncle"> <owl:propertyChainAxiom rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasFather"/> <owl:ObjectProperty rdf:about="hasBrother"/> </owl:propertyChainAxiom> </rdf:Description> <owl:DatatypeProperty rdf:about="hasAge"> <rdfs:domain rdf:resource="Person"/> <rdfs:range rdf:datatpye="http://www.w3.org/2001/XMLSchema#NonNegativeInteger"/> <owl:equivalentProperty rdf:resource="&otherOnt;age"/> </owl:DatatypeProperty> <owl:FunctionalProperty rdf:about="hasAge"/> <owl:Class rdf:about="Woman"> <rdfs:subClassOf rdf:resource="Person"/> </owl:Class> <owl:Class rdf:about="Mother"> <rdfs:subClassOf rdf:resource="Woman"/> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Woman"/> <owl:Class rdf:about="Parent"/> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="Person"> <rdfs:comment>Represents the set of all people.</rdfs:comment> <owl:equivalentClass rdf:resource="Human"/> <owl:hasKey rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hasSSN"/> </owl:hasKey> </owl:Class> <owl:Class rdf:about="Parent"> <owl:equivalentClass> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="Mother"/> <owl:Class rdf:about="Father"/> </owl:unionOf> </owl:Class> </owl:equivalentClass> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="hasChild"/> <owl:someValuesFrom rdf:resource="Person"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="ChildlessPerson"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Person"/> <owl:Class> <owl:complementOf rdf:resource="Parent"/> </owl:Class> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="Grandfather"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Man"/> <owl:Class rdf:about="Parent"/> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="HappyPerson"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf parseType="Collection"> <owl:Restriction> <owl:onProperty rdf:about="hasChild"/> <owl:allValuesFrom rdf:about="HappyPerson"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:about="hasChild"/> <owl:someValuesFrom rdf:about="HappyPerson"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="JohnsChildren"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="hasParent"/> <owl:hasValue rdf:resource="John"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="NarcisticPerson"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="loves"/> <owl:hasSelf rdf:datatype="&xsd;boolean"> true </owl:hasSelf> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="MyBirthdayGuests"> <owl:equivalentClass> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:about="Bill"/> <rdf:Description rdf:about="John"/> <rdf:Description rdf:about="Mary"/> </owl:oneOf> </owl:Class> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="Orphan"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty> <owl:inverseOf rdf:about="hasChild"/> </owl:ObjectProperty> </owl:onProperty> <owl:Class rdf:about="Dead"/> </owl:Restriction> </owl:equivalentClass> </owl:Class> <owl:Class rdf:about="Teenager"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="hasAge"/> <owl:someValuesFrom> <rdfs:Datatype> <owl:onDataType rdf:resource="&xsd;integer"/> <owl:withRestrictions rdf:parseType="Collection"> <xsd:minExclusive rdf:datatype="&xsd;integer"> 12 </xsd:minExclusive> <xsd:maxInclusive rdf:datatype="&xsd;integer"> 19 </xsd:maxInclusive> </owl:withRestrictions> </rdfs:Datatype> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="Man"> <rdfs:subClassOf rdf:resource="Person"/> </owl:Class> <owl:Axiom> <owl:annotatedSource rdf:resource="Man"/> <owl:annotatedProperty rdf:resource="&rdfs;subClassOf"/> <owl:annotatedTarget rdf:resource="Person"/> <rdfs:comment>States that every man is a person.</rdfs:comment> </owl:Axiom> <owl:Class rdf:about="Adult"> <owl:equivalentClass rdf:resource="&otherOnt;Grownup"/> </owl:Class> <owl:Class rdf:about="Father"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Man"/> <owl:Class rdf:about="Parent"/> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="ChildlessPerson"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Person"/> <owl:Class> <owl:complementOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty> <owl:inverseOf rdf:resource="hasParent"/> </owl:ObjectProperty> </owl:onProperty> <owl:someValuesFrom rdf:resource="&owl;Thing"/> </owl:Restriction> </owl:complementOf> </owl:Class> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:about="Mary"/> <rdf:Description rdf:about="Bill"/> <rdf:Description rdf:about="Meg"/> </owl:oneOf> </owl:Class> <owl:Class rdf:about="Female"/> </owl:intersectionOf> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Parent"/> <owl:Restriction> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger"> 2 </owl:maxCardinality> <owl:onProperty rdf:resource="hasChild"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="hasChild"/> <owl:allValuesFrom rdf:resource="Female"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class> <owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class rdf:about="Woman"/> <owl:Class rdf:about="Man"/> </owl:members> </owl:AllDisjointClasses> <owl:AllDisjointClasses> <owl:members rdf:parseType="Collection"> <owl:Class rdf:about="Mother"/> <owl:Class rdf:about="Father"/> <owl:Class rdf:about="YoungChild"/> </owl:members> </owl:AllDisjointClasses> <rdf:Description rdf:about="personAge"> <owl:equivalentClass> <owl:Datatype> <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/> <owl:withRestrictions rdf:parseType="Collection"> <xsd:minInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">0</xsd:minInclusive> <xsd:maxInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">150</xsd:maxInclusive> </owl:withRestrictions> </owl:Datatype> </owl:equivalentClass> </rdf:Description> <rdf:Description rdf:about="majorAge"> <owl:equivalentClass> <owl:Datatype> <owl:intersectionOf rdf:parseType="Collection"> <rdf:Description rdf:about="personAge"/> <rdfs:Datatype> <owl:datatypeComplementOf about="minorAge"/> </rdfs:Datatype> </owl:intersectionOf> </owl:Datatype> </owl:equivalentClass> </rdf:Description> <rdf:Description rdf:about="toddlerAge"> <owl:equivalentClass> <owl:Datatype> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</rdf:Description> <rdf:Description rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">2</rdf:Description> </owl:oneOf> </owl:Datatype> </owl:equivalentClass> </rdf:Description> <Person rdf:about="Mary"> <rdf:type rdf:resource="Woman"/> <owl:sameAs rdf:resource="&otherOnt;MaryBrown"/> </Person> <owl:NamedIndividual rdf:about="James"> <owl:sameAs rdf:resource="Jim"/> </owl:NamedIndividual>
<owl:NamedIndividual rdf:about="John"> <hasWife rdf:resource="Mary"/> <hasAge rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">51</hasAge> <owl:differentFrom rdf:resource="Bill"/> <owl:sameAs rdf:resource="&otherOnt;JohnBrown"/> <rdf:type rdf:resource="Person"/> <rdf:type rdf:resource="Father"/> <rdf:type> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="Person"/> <owl:Class> <owl:complementOf rdf:about="Parent"/> </owl:Class> </owl:intersectionOf> </owl:Class> </rdf:type> <rdf:type> <owl:Class> <owl:Restriction> <owl:maxQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger"> 4 </owl:maxQualifiedCardinality> <owl:onProperty rdf:about="hasChild"/> <owl:onClass rdf:about="Parent"/> </owl:Restriction> </owl:Class> </rdf:type> <rdf:type> <owl:Class> <owl:Restriction> <owl:minQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger"> 2 </owl:minQualifiedCardinality> <owl:onProperty rdf:about="hasChild"/> <owl:onClass rdf:about="Parent"/> </owl:Restriction> </owl:Class> </rdf:type> <rdf:type> <owl:Class> <owl:Restriction> <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger"> 3 </owl:qualifiedCardinality> <owl:onProperty rdf:about="hasChild"/> <owl:onClass rdf:about="Parent"/> </owl:Restriction> </owl:Class> </rdf:type> <rdf:type> <owl:Class> <owl:Restriction> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger"> 5 </owl:cardinality> <owl:onProperty rdf:about="hasChild"/> </owl:Restriction> </owl:Class> </rdf:type> </owl:NamedIndividual> <SocialRole rdf:about="Father"/> <owl:NegativePropertyAssertion> <owl:sourceIndividual rdf:about="Bill"/> <owl:assertionProperty rdf:about="hasWife"/> <owl:targetIndividual rdf:about="Mary"/> </owl:NegativePropertyAssertion> <owl:NegativePropertyAssertion> <owl:sourceIndividual rdf:about="Jack"/> <owl:assertionProperty rdf:about="hasAge"/> <owl:targetValue rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">53</owl:targetValue> </owl:NegativePropertyAssertion> <owl:NegativePropertyAssertion> <owl:sourceIndividual rdf:about="Bill"/> <owl:assertionProperty rdf:about="hasDaughter"/> <owl:targetIndividual rdf:about="Susan"/> </owl:NegativePropertyAssertion> </rdf:RDF>
@prefix : <http://example.com/owl/families/> . @prefix otherOnt: <http://example.org/otherOntologies/families/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <http://example.com/owl/families> rdf:type owl:Ontology ; owl:imports <http://example.org/otherOntologies/families.owl> . :Mary rdf:type :Person . :Mary rdf:type :Woman . :Woman rdfs:subClassOf :Person . :Mother rdfs:subClassOf :Woman . :Person owl:equivalentClass :Human . [] rdf:type owl:AllDisjointClasses ; owl:members ( :Woman :Man ) . :John :hasWife :Mary . [] rdf:type owl:NegativePropertyAssertion ; owl:sourceIndividual :Bill ; owl:assertionProperty :hasWife ; owl:targetIndividual :Mary . :hasWife rdfs:subPropertyOf :hasSpouse . :hasWife rdfs:domain :Man ; rdfs:range :Woman . :John owl:differentFrom :Bill . :James owl:sameAs :Jim . :John :hasAge 51 . [] rdf:type owl:NegativePropertyAssertion ; owl:sourceIndividual :Jack ; owl:assertionProperty :hasAge ; owl:targetValue 53 . :hasAge rdfs:domain :Person ; rdfs:range xsd:NonNegativeInteger . :Mother owl:equivalentClass [ rdf:type owl:Class ; owl:intersectionOf ( :Woman :Parent ) ] . :Parent owl:equivalentClass [ rdf:type owl:Class ; owl:unionOf ( :Mother :Father ) ] . :ChildlessPerson owl:equivalentClass [ rdf:type owl:Class ; owl:intersectionOf ( :Person [ owl:complementOf :Parent ] ) ] . :Grandfather rdfs:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Man :Parent ) ] . :John rdf:type [ rdf:type owl:Class ; owl:intersectionOf ( :Person [ rdf:type owl:Class ; owl:complementOf :Parent ] ) ] . :Parent owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] . :HappyPerson owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:allValuesFrom :HappyPerson ] . :HappyPerson owl:equivalentClass [ rdf:type owl:Class ; owl:intersectionOf ( [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:allValuesFrom :HappyPerson ] [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :HappyPerson ] ) ] . :JohnsChildren owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :hasParent ; owl:hasValue :John ] . :NarcisticPerson owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :loves ; owl:hasSelf "true"^^xsd:boolean . ] . :John rdf:type [ rdf:type owl:Restriction ; owl:maxQualifiedCardinality "4"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ; owl:onClass :Parent ] . :John rdf:type [ rdf:type owl:Restriction ; owl:minQualifiedCardinality "2"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ; owl:onClass :Parent ] . :John rdf:type [ rdf:type owl:Restriction ; owl:qualifiedCardinality "3"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ; owl:onClass :Parent ] . :John rdf:type [ rdf:type owl:Restriction ; owl:cardinality "5"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ] . :MyBirthdayGuests owl:equivalentClass [ rdf:type owl:Class ; owl:oneOf ( :Bill :John :Mary ) ] . :hasParent owl:inverseOf :hasChild . :Orphan owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty [ owl:inverseOf :hasChild ] ; owl:allValuesFrom :Dead ] . :hasSpouse rdf:type owl:SymmetricProperty . :hasChild rdf:type owl:AsymmetricProperty . :hasParent owl:propertyDisjointWith :hasSpouse . :hasRelative rdf:type owl:ReflexiveProperty . :parentOf rdf:type owl:IrreflexiveProperty . :hasHusband rdf:type owl:FunctionalProperty . :hasHusband rdf:type owl:InverseFunctionalProperty . :hasAncestor rdf:type owl:TransitiveProperty . :hasGrandparent owl:propertyChainAxiom ( :hasParent :hasParent ) . :Person owl:hasKey :hasSSN . :personAge owl:equivalentClass [ rdf:type rdfs:Datatype; owl:onDatatype xsd:Integer; owl:withRestrictions ( [ xsd:minInclusive "0"^^xsd:integer ] [ xsd:maxInclusive "150"^^xsd:integer ] ) ] . :majorAge owl:equivalentClass [ rdf:type rdfs:Datatype; owl:intersectionOf ( :personAge [ rdf:type rdfs:Datatype; owl:datatypeComplementOf :minorAge ] ) ] . :toddlerAge owl:equivalentClass [ rdf:type rdfs:Datatype; owl:oneOf ( "1"^^xsd:integer "2"^^xsd:integer ) ] . :hasAge rdf:type owl:FunctionalProperty . :Teenager rdfs:subClassOf [ rdf:type owl:Restriction ; owl:onProperty :hasAge ; owl:someValuesFrom [ rdf:type rdfs:Datatype ; owl:onDatatype xsd:integer ; owl:withRestrictions ( [ xsd:minInclusive "13"^^xsd:integer ] [ xsd:maxInclusive "19"^^xsd:integer ] ) ] ] . :Person rdfs:comment "Represents the set of all people."^^xsd:string . :Man rdfs:subClassOf :Person . [] rdf:type owl:Axiom ; owl:annotatedSource :Man ; owl:annotatedProperty rdfs:subClassOf ; owl:annotatedTarget :Person ; rdfs:comment "States that every man is a person."^^xsd:string . :Mary owl:sameAs otherOnt:MaryBrown . :John owl:sameAs otherOnt:JohnBrown . :Adult owl:equivalentClass otherOnt:Grownup . :hasChild owl:equivalentProperty otherOnt:child . :hasAge owl:equivalentProperty otherOnt:age . :John rdf:type owl:NamedIndividual . :Person rdf:type owl:Class . :hasWife rdf:type owl:ObjectProperty . :hasAge rdf:type owl:DatatypeProperty . :John rdf:type :Father . :Father rdf:type :SocialRole . :Father rdfs:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Man :Parent ) ] . :Parent owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:someValuesFrom :Person ] . :NarcisticPerson owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty :loves ; owl:hasSelf true ] . [] rdf:type owl:AllDisjointClasses ; owl:members ( :Mother :Father :YoungChild ) . :hasUncle owl:propertyChain ( :hasFather :hasBrother ) . [] rdf:type owl:NegativePropertyAssertion ; owl:sourceIndividual :Bill ; owl:assertionProperty :hasDaughter ; owl:targetIndividual :Susan . :ChildlessPerson owl:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Person [ owl:complementOf [ rdf:type owl:Restriction ; owl:onProperty [ owl:inverseOf :hasParent ] ; owl:someValuesFrom owl:Thing ] ] ) ] . :hasSon owl:propertyDisjointWith :hasDaughter. :hasFather rdfs:subPropertyOf :hasParent. [] rdf:type owl:Class ; owl:intersectionOf ( [ rdf:type owl:Class ; owl:oneOf ( :Mary :Bill :Meg ) ] :Female ) ; rdfs:subClassOf [ rdf:type owl:Class ; owl:intersectionOf ( :Parent [ rdf:type owl:Restriction ; owl:maxCardinality "1"^^xsd:nonNegativeInteger ; owl:onProperty :hasChild ] [ rdf:type owl:Restriction ; owl:onProperty :hasChild ; owl:allValuesFrom :Female ] ) ] .
Prefix: <http://example.com/owl/families/> Prefix: owl <http://www.w3.org/2002/07/owl#> Prefix: otherOnt <http://example.org/otherOntologies/families/> Ontology: <http://example.com/owl/families> Import: <http://example.org/otherOntologies/families.owl> Individual: Mary Types: Person Individual: Mary Types: Woman Class: Woman SubClassOf: Person Class: Mother SubClassOf: Woman Class: Person EquivalentTo: Human DisjointClasses: Woman Man Individual: John Facts: hasWife Mary Individual: Bill Facts: not hasWife Mary ObjectProperty: hasWife SubPropertyOf: hasSpouse ObjectProperty: hasWife Domain: Man Range: Woman Individual: John DifferentFrom: Bill Individual: James SameAs: Jim Individual: John Facts: hasAge "51"^^xsd:integer Individual: Jack Facts: not hasAge "53"^^xsd:integer DatatpyeProperty: hasAge Domain: Person Range: xsd:NonNegativeInteger Class: Mother EquivalentTo: Woman and Parent Class: Parent EquivalentTo: Mother or Father Class: ChildlessPerson EquivalentTo: Person and not Parent Class: Grandfather SubClassOf: Man and Parent Individual: John Types: Person and not Parent Class: Parent EquivalentTo: hasChild some Person Class: HappyPerson EquivalentTo: hasChild only HappyPerson Class: HappyPerson EquivalentTo: hasChild only Happy and hasChild some Happy Class: JohnsChildren EquivalentTo: hasParent value John Class: NarcisticPerson EquivalentTo: loves Self Individual: John Types: hasChild max 4 Parent Individual: John Types: hasChild min 2 Parent Individual: John Types: hasChild exactly 3 Parent Individual: John Types: hasChild exactly 5 Class: MyBirthdayGuests EquivalentTo: { Bill John Mary } ObjectProperty: hasParent InverseOf: hasChild Class: Orphan EquivalentTo: inverse hasChild only Dead ObjectProperty: hasSpouse Characteristics: Symmetric ObjectProperty: hasChild Characteristics: Asymmetric DisjointProperties: hasParent hasSpouse ObjectProperty: hasRelative Characteristics: Reflexive Objectproperty: parentOf Characteristics: Irreflexive ObjectProperty: hasHusband Characteristics: Functional ObjectProperty: hasHusband Characteristics: InverseFunctional ObjectProperty: hasAncestor Characteristics: Transitive ObjectProperty: hasGrandparent SubPropertyChain: hasParent o hasParent HasKey: Person hasSSN Datatype: personAge EquivalentTo: integer[<= 0 , >= 150] Datatype: majorAge EquivalentTo: personAge and not minorAge Datatype: toddlerAge EquivalentTo: { 1 2 } DataProperty: hasHusband Characteristics: Functional Class: Teenager SubClassOf: hasAge some integer[<= 13 , >= 19] Class: Person Annotations: rdfs:comment "Represents the set of all people." Class: Man SubClassOf: Annotations: rdfs:comment "States that every man is a person." Person SameIndividual: John otherOnt:JohnBrown SameIndividual: Mary otherOnt:MaryBrown EquivalentClasses: Adult otherOnt:Grownup EquivalentProperties: hasChild otherOnt:child EquivalentProperties: hasAge otherOnt:age Individual: John Class: Person ObjectProperty: hasWife Dataproperty: hasAge Individual: John Types: Father Individual: Father Types: SocialRole Class: Father SubClassOf: Man and Parent Class: Parent EquivalentTo: hasChild some Person Class: NarcisticPerson EquivalentTo: loves Self DisjointClasses: Mother Father YoungChild ObjectProperty: hasUncle SubPropertyChain: hasFather o hasBrother Individual: Bill Facts: not hasDaughter Susan Class: ChildlessPerson SubClassOf: Person and not inverse hasParent some owl:Thing DisjointClasses: Mother Father YoungChild DisjointProperties: hasSon hasDaughter ObjectProperty: hasFather SubPropertyOf: hasParent Class: X SubClassOf: Parent and hasChild max 1 and hasChild only Female Class: X EquivalentTo: {Mary Bill Meg} and Female DisjointClasses: Mother Father YoungChild ObjectProperty: hasUncle SubPropertyChain: hasFather o hasBrother Class: Citizen EquivalentTo: hasParent some Citizen Individual: Sheevah Types: Citizen Individual: Sheevah Types: Citizen Facts: hasParent Suma
<!DOCTYPE Ontology [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" > ]> <Ontology xml:base="http://example.com/owl/families/" xmlns="http://www.w3.org/2002/07/owl#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:g="http://example.org/otherOntologies/families/" ontologyIRI="http://example.com/owl/families"> <Prefix name="otherOnt" IRI="http://example.org/otherOntologies/families/"/> <Import>http://example.org/otherOntologies/families.owl</Import> <ClassAssertion> <Class IRI="Person"/> <NamedIndividual IRI="Mary"/> </ClassAssertion> <ClassAssertion> <Class IRI="Woman"/> <NamedIndividual IRI="Mary"/> </ClassAssertion> <SubClassOf> <Class IRI="Woman"/> <Class IRI="Person"/> </SubClassOf> <SubClassOf> <Class IRI="Mother"/> <Class IRI="Woman"/> </SubClassOf> <EquivalentClasses> <Class IRI="Person"/> <Class IRI="Human"/> </EquivalentClasses> <DisjointClasses> <Class IRI="Woman"/> <Class IRI="Man"/> </DisjointClasses> <ObjectPropertyAssertion> <ObjectProperty IRI="hasWife"/> <NamedIndividual IRI="John"/> <NamedIndividual IRI="Mary"/> </ObjectPropertyAssertion> <NegativeObjectPropertyAssertion> <ObjectProperty IRI="hasWife"/> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="Mary"/> </NegativeObjectPropertyAssertion> <SubObjectPropertyOf> <ObjectProperty IRI="hasWife"/> <ObjectProperty IRI="hasSpouse"/> </SubObjectPropertyOf> <ObjectPropertyDomain> <ObjectProperty IRI="hasWife"/> <Class IRI="Man"/> </ObjectPropertyDomain> <ObjectPropertyRange> <ObjectProperty IRI="hasWife"/> <Class IRI="Woman"/> </ObjectPropertyRange> <DifferentIndividuals> <NamedIndividual IRI="John"/> <NamedIndividual IRI="Bill"/> </DifferentIndividuals> <SameIndividual> <NamedIndividual IRI="James"/> <NamedIndividual IRI="Jim"/> </SameIndividual> <DataPropertyAssertion> <DataProperty IRI="hasAge"/> <NamedIndividual IRI="John"/> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">51</Literal> </DataPropertyAssertion> <NegativeDataPropertyAssertion> <DataProperty IRI="hasAge"/> <NamedIndividual IRI="Jack"/> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">53</Literal> </NegativeDataPropertyAssertion> <DatatypePropertyDomain> <DatatypeProperty IRI="hasAge"/> <Class IRI="Person"/> </DatatypePropertyDomain> <DatatypePropertyRange> <DatatypeProperty IRI="hasAge"/> <Datatype IRI="http://www.w3.org/2001/XMLSchema#NonNegativeInteger"/> </DatatypePropertyRange> <EquivalentClasses> <Class IRI="Mother"/> <ObjectIntersectionOf> <Class IRI="Woman"/> <Class IRI="Parent"/> </ObjectIntersectionOf> </EquivalentClasses> <EquivalentClasses> <Class IRI="Parent"/> <ObjectUnionOf> <Class IRI="Mother"/> <Class IRI="Father"/> </ObjectUnionOf> </EquivalentClasses> <EquivalentClasses> <Class IRI="ChildlessPerson"/> <ObjectIntersectionOf> <Class IRI="Person"/> <ObjectComplementOf> <Class IRI="Parent"/> </ObjectComplementOf> </ObjectIntersectionOf> </EquivalentClasses> <SubClassOf> <Class IRI="Grandfather"/> <ObjectIntersectionOf> <Class IRI="Man"/> <Class IRI="Parent"/> </ObjectIntersectionOf> </SubClassOf> <ClassAssertion> <ObjectIntersectionOf> <Class IRI="Person"/> <ObjectComplementOf> <Class IRI="Parent"/> </ObjectComplementOf> </ObjectIntersectionOf> <NamedIndividual IRI="John"/> </ClassAssertion> <EquivalentClasses> <Class IRI="Parent"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Person"/> </ObjectSomeValuesFrom> </EquivalentClasses> <EquivalentClasses> <Class IRI="HappyPerson"/> <ObjectAllValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="HappyPerson"/> </ObjectAllValuesFrom> </EquivalentClasses> <EquivalentClasses> <Class IRI="HappyPerson"/> <ObjectIntersectionOf> <ObjectAllValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="HappyPerson"/> </ObjectAllValuesFrom> <ObjectSomeValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="HappyPerson"/> </ObjectSomeValuesFrom> </ObjectIntersectionOf> </EquivalentClasses> <EquivalentClasses> <Class IRI="JohnsChildren"/> <ObjectHasValue> <ObjectProperty IRI="hasParent"/> <Class IRI="John"/> </ObjectHasValue> </EquivalentClasses> <EquivalentClasses> <Class IRI="NarcisticPerson"/> <ObjectHasSelf> <ObjectProperty IRI="loves"/> </ObjectHasSelf> </EquivalentClasses> <ClassAssertion> <ObjectMaxCardinality cardinality="4"> <ObjectProperty IRI="hasChild"/> <Class IRI="Parent"/> </ObjectMaxCardinality> <NamedIndividual IRI="John"/> </ClassAssertion> <ClassAssertion> <ObjectMinCardinality cardinality="2"> <ObjectProperty IRI="hasChild"/> <Class IRI="Parent"/> </ObjectMinCardinality> <NamedIndividual IRI="John"/> </ClassAssertion> <ClassAssertion> <ObjectExactCardinality cardinality="3"> <ObjectProperty IRI="hasChild"/> <Class IRI="Parent"/> </ObjectExactCardinality> <NamedIndividual IRI="John"/> </ClassAssertion> <ClassAssertion> <ObjectExactCardinality cardinality="5"> <ObjectProperty IRI="hasChild"/> </ObjectExactCardinality> <NamedIndividual IRI="John"/> </ClassAssertion> <EquivalentClasses> <Class IRI="MyBirthdayGuests"/> <ObjectOneOf> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="John"/> <NamedIndividual IRI="Mary"/> </ObjectOneOf> </EquivalentClasses> <InverseObjectProperties> <ObjectProperty IRI="hasParent"/> <ObjectProperty IRI="hasChild"/> </InverseObjectProperties> <EquivalentClasses> <Class IRI="Orphan"/> <ObjectAllValuesFrom> <InverseObjectProperty> <ObjectProperty IRI="hasChild"/> </InverseObjectProperty> <Class IRI="Dead"/> </ObjectAllValuesFrom> </EquivalentClasses> <SymmetricObjectProperty> <ObjectProperty IRI="hasSpouse"/> </SymmetricObjectProperty> <AsymmetricObjectProperty> <ObjectProperty IRI="hasChild"/> </AsymmetricObjectProperty> <DisjointObjectProperties> <ObjectProperty IRI="hasParent"/> <ObjectProperty IRI="hasSpouse"/> </DisjointObjectProperties> <ReflexiveObjectProperty> <ObjectProperty IRI="hasRelative"/> </ReflexiveObjectProperty> <IreflexiveObjectProperty> <ObjectProperty IRI="parentOf"/> </IreflexiveObjectProperty> <FunctionalObjectProperty> <ObjectProperty IRI="hasHusband"/> </FunctionalObjectProperty> <InverseFunctionalObjectProperty> <ObjectProperty IRI="hasHusband"/> </InverseFunctionalObjectProperty> <TransitiveObjectProperty> <ObjectProperty IRI="hasAncestor"/> </TransitiveObjectProperty> <SubObjectPropertyOf> <PropertyChain> <ObjectProperty IRI="hasParent"/> <ObjectProperty IRI="hasParent"/> </PropertyChain> <ObjectProperty IRI="hasGrandparent"/> </SubObjectPropertyOf> <HasKey> <Class IRI="Person"/> <ObjectProperty IRI="hasSSN"/> </HasKey> <EquivalentClasses> <Datatype IRI="personAge"/> <DatatypeRestriction> <Datatype IRI="&xsd;integer"/> <FacetRestriction facet="&xsd;minInclusive"> <Literal datatypeIRI="&xsd;integer">0</Literal> </FacetRestriction> <FacetRestriction facet="&xsd;maxInclusive"> <Literal datatypeIRI="&xsd;integer">150</Literal> </FacetRestriction> </DatatypeRestriction> </EquivalentClasses> <EquivalentClasses> <Datatype IRI="majorAge"/> <DataIntersectionOf> <Datatype IRI="personAge"/> <DataComplementOf> <Datatype IRI="minorAge"/> </DataComplementOf> </DataIntersectionOf> </EquivalentClasses> <EquivalentClasses> <Datatype IRI="toddlerAge"/> <DataOneOf> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">1</Literal> <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">2</Literal> </DataOneOf> </EquivalentClasses> <FunctionalDataProperty> <DataProperty IRI="hasHusband"/> </FunctionalDataProperty> <SubClassOf> <Class IRI="Teenager"/> <DataSomeValuesFrom> <DataProperty IRI="hasAge"/> <DatatypeRestriction> <Datatype IRI="&xsd;integer"/> <FacetRestriction facet="&xsd;minInclusive"> <Literal datatypeIRI="&xsd;integer">13</Literal> </FacetRestriction> <FacetRestriction facet="&xsd;maxInclusive"> <Literal datatypeIRI="&xsd;integer">19</Literal> </FacetRestriction> </DatatypeRestriction> </DataSomeValuesFrom> </SubClassOf> <AnnotationAssertion> <AnnotationProperty IRI="&rdfs;comment"/> <IRI>Person</IRI> <Literal>Represents the set of all people.</Literal> </AnnotationAssertion> <SubClassOf> <Annotation> <AnnotationProperty IRI="&rdfs;comment"/> <Literal datatypeIRI="xsd:string">"States that every man is a person."</Literal> </Annotation> <Class IRI="Man"/> <Class IRI="Person"/> </SubClassOf> <SameIndividuals> <Individual IRI="John"/> <Individual IRI="otherOnt:JohnBrown"/> </SameIndividuals> <SameIndividuals> <Individual IRI="Mary"/> <Individual IRI="otherOnt:MaryBrown"/> </SameIndividuals> <EquivalentClasses> <Class IRI="Adult"/> <Class IRI="otherOnt:Grownup"/> </EquivalentClasses> <EquivalentObjectProperties> <ObjectProperty IRI="hasChild"/> <ObjectProperty IRI="otherOnt:child"/> </EquivalentObjectProperties> <EquivalentDataProperties> <DataProperty IRI="hasAge"/> <DataProperty IRI="otherOnt:age"/> </EquivalentDataProperties> <Declaration> <NamedIndividual IRI="John"/> </Declaration> <Declaration> <Class IRI="Person"/> </Declaration> <Declaration> <ObjectProperty IRI="hasWife"/> </Declaration> <Declaration> <DataProperty IRI="hasAge"/> </Declaration> <ClassAssertion> <Class URI="Father"/> <NamedIndividual IRI="John"/> </ClassAssertion> <ClassAssertion> <Class URI="SocialRole"/> <NamedIndividual IRI="Father"/> </ClassAssertion> <SubClassOf> <Class IRI="Father"/> <ObjectIntersectionOf> <Class IRI="Man"/> <Class IRI="Parent"/> </ObjectIntersectionOf> </SubClassOf> <EquivalentClasses> <Class IRI="Parent"/> <ObjectSomeValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Person"/> </ObjectSomeValuesFrom> </EquivalentClasses> <EquivalentClasses> <Class IRI="NarcisticPerson"/> <ObjectHasSelf> <ObjectProperty IRI="loves"/> </ObjectHasSelf> </EquivalentClasses> <DisjointClasses> <Class IRI="Father"/> <Class IRI="Mother"/> <Class IRI="YoungChild"/> </DisjointClasses> <SubObjectPropertyOf> <PropertyChain> <ObjectProperty IRI="hasFather"/> <ObjectProperty IRI="hasBrother"/> </PropertyChain> <ObjectProperty IRI="hasUncle"/> </SubObjectPropertyOf> <NegativeObjectPropertyAssertion> <ObjectProperty IRI="hasDaughter"/> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="Susan"/> </NegativeObjectPropertyAssertion> <SubClassOf> <Class IRI="ChildlessPerson"/> <ObjectIntersectionOf> <Class IRI="Person"/> <ObjectComplementOf> <ObjectSomeValuesFrom> <InverseObjectProperty> <ObjectProperty IRI="hasParent"/> </InverseObjectProperty> <Class abbreviatedIRI="owl:Thing"/> </ObjectSomeValuesFrom> </ObjectComplementOf> </ObjectIntersectionOf> </SubClassOf> <DisjointClasses> <Class IRI="Father"/> <Class IRI="Mother"/> <Class IRI="YoungChild"/> </DisjointClasses> <DisjointObjectProperties> <ObjectProperty IRI="hasSon"/> <ObjectProperty IRI="hasDaughter"/> </DisjointObjectProperties> <SubObjectPropertyOf> <ObjectProperty IRI="hasFather"/> <ObjectProperty IRI="hasParent"/> </SubObjectPropertyOf> <SubClassOf> <ObjectIntersectionOf> <ObjectOneOf> <NamedIndividual IRI="Mary"/> <NamedIndividual IRI="Bill"/> <NamedIndividual IRI="Meg"/> </ObjectOneOf> <Class IRI="Female"/> </ObjectIntersectionOf> <ObjectIntersectionOf> <Class IRI="Parent"/> <ObjectMaxCardinality cardinality="1"> <ObjectProperty IRI="hasChild"/> </ObjectMaxCardinality> <ObjectAllValuesFrom> <ObjectProperty IRI="hasChild"/> <Class IRI="Female"/> </ObjectAllValuesFrom> </ObjectIntersectionOf> </SubClassOf> <DisjointClasses> <Class IRI="Father"/> <Class IRI="Mother"/> <Class IRI="YoungChild"/> </DisjointClasses> <SubObjectPropertyOf> <PropertyChain> <ObjectProperty IRI="hasFather"/> <ObjectProperty IRI="hasBrother"/> </PropertyChain> <ObjectProperty IRI="hasUncle"/> </SubObjectPropertyOf> </Ontology>
The starting point for the expressive powerdevelopment of OWL, effectively, requiresOWL 2 was the OWL1.1 member submission, itself a fair bitresult of skill. 12.2 The Complete Sample Ontology Here we includeuser and developer feedback, and in particular of information gathered during the complete sampleOWL ontology.Experiences and Directions (OWLED) Workshop series. The ontology here is ordered in a commonly-used ordering, with ontology information first, followedworking group also considered postponed issues from the WebOnt Working Group.
This document has been produced by information about properties, then classes, then individuals. Editor's Note:the complete sampleOWL ontology will go here 13 Acknowledgments Editor's Note: There'll be a list of everyone whose comments resulted in a change toWorking Group (see below), and its contents reflect extensive discussions within the Working Group as a draft ofwhole.
The text.editors extend special thanks to
Jie Bao (RPI),
Michel Dumontier (Carleton University),
Christine Goldbreich (Université de Versailles St-Quentin and LIRMM),
Henson Graves (Lockheed Martin),
Ivan Herman (W3C/ERCIM),
Rinke Hoekstra (University of Amsterdam),
Doug Lenat (Cycorp),
Deborah L. McGuinness (RPI),
Alan Rector (University of Manchester),
Alan Ruttenberg (Science Commons)
Uli Sattler (University of Manchester),
Michael Schneider (FZI), and
Mike Smith (Clark & Parsia)
for their thorough reviews and helpful comments.
The regular attendees at meetings of the OWL Working Group at the time of publication of this document were:
Jie Bao (RPI),
Diego Calvanese (Free University of Bozen-Bolzano),
Bernardo Cuenca Grau (Oxford University),
Martin Dzbor (Open University),
Achille Fokoue (IBM Corporation),
Christine Golbreich (Université de Versailles St-Quentin and LIRMM),
Sandro Hawke (W3C/MIT),
Ivan Herman (W3C/ERCIM),
Rinke Hoekstra (University of Amsterdam),
Ian Horrocks (Oxford University),
Elisa Kendall (Sandpiper Software),
Markus Krötzsch (FZI),
Carsten Lutz (Universität Bremen),
Deborah L. McGuinness (RPI),
Boris Motik (Oxford University),
Jeff Pan (University of Aberdeen),
Bijan Parsia (University of Manchester),
Peter F. Patel-Schneider (Bell Labs Research, Alcatel-Lucent),
Alan Ruttenberg (Science Commons),
Uli Sattler (University of Manchester),
Michael Schneider 14(FZI),
Mike Smith (Clark & Parsia),
Evan Wallace (NIST), and
Zhe Wu (Oracle Corporation).
We would also like to thank past members of the working group:
Jeremy Carroll,
Jim Hendler,
Vipul Kashyap.