Movatterモバイル変換
[0]ホーム
OWL Web Ontology Language
Reference
W3C Recommendation 10 February 2004
New Version Available: OWL 2 (Document Status Update, 12 November 2009)
The OWL Working Group has produceda W3C Recommendation for a new version of OWL which addsfeatures to this 2004 version, while remaining compatible.Please seeOWL 2Document Overview for an introduction to OWL 2 and a guideto the OWL 2 document set.
- This version:
- http://www.w3.org/TR/2004/REC-owl-ref-20040210/
- Latest version:
- http://www.w3.org/TR/owl-ref/
- Previous version:
- http://www.w3.org/TR/2003/PR-owl-ref-20031215/
- Editors:
- Mike Dean, BBN Technologies
Guus Schreiber,Free University Amsterdam
- Authors:
- Sean Bechhofer,University of Manchester
Frank van Harmelen,Free University Amsterdam
Jim Hendler,University of Maryland
Ian Horrocks,University of Manchester
Deborah L. McGuinness, Stanford University
Peter F. Patel-Schneider, Bell Labs Research, Lucent Technologies
Lynn Andrea Stein,Franklin W. Olin College of Engineering
Please refer to theerratafor this document, which may include some normative corrections.
See alsotranslations.
Copyright © 2004W3C® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark,document use andsoftware licensing rules apply.
The Web Ontology Language OWL is a semantic markup language for publishingand sharing ontologies on the World Wide Web. OWL is developed as a vocabulary extension of RDF (the Resource Description Framework) and is derived from the DAML+OIL WebOntology Language. This document contains a structured informal descriptionof the full set of OWL language constructs and is meant to serve asa reference for OWL users who want to construct OWL ontologies.
This document has been reviewed by W3C Members and other interestedparties, and it has been endorsed by the Director as aW3CRecommendation. W3C's role in making the Recommendation is todraw attention to the specification and to promote its widespreaddeployment. This enhances the functionality and interoperability ofthe Web.
This is one ofsixparts of the W3C Recommendation for OWL, the Web OntologyLanguage. It has been developed by theWeb Ontology WorkingGroup as part of theW3CSemantic Web Activity (Activity Statement,Group Charter) forpublication on 10 February 2004.
The design of OWL expressed in earlier versions of these documentshas been widely reviewed and satisfies the Working Group's technical requirements.The Working Group has addressedall comments received, making changes as necessary. Changes tothis document sincethe ProposedRecommendation version are detailed in thechange log.
Comments are welcome atpublic-webont-comments@w3.org(archive)and general discussion of related technology is welcome atwww-rdf-logic@w3.org (archive).
A list ofimplementations is available.
The W3C maintains a list ofanypatent disclosures related to this work.
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 theW3C technical reports index at http://www.w3.org/TR/.
Parts of this document are derived from the DAML+OIL (March 2001) ReferenceDescription [DAML+OIL] which wassubmitted as part of theDAML+OIL W3C Note. The sponsors of this document and its predecessor documents are gratefully acknowledged.
Jeremy Carroll, Jim Hendler, Brian McBride andPeter Patel-Schneider provided substantive reviews and contributed text to this document. Jeff Heflincontributed the section on deprecation. Jerome Euzenatcontributed the example for an enumerated datatype.
This document is the result of extensive discussions within theWeb Ontology Working Groupas a whole. The participants in this Working Group included: Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin,Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael Sintek,Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant,Raphael Volz, Evan Wallace, Christopher Welty, Charles White,and John Yanosy.
1. Introduction
1.1 Purpose of this document
This document gives a systematic, compact and informative descriptionof all the modelling primitives of OWL, using the RDF/XMLexchange syntax for OWL. We expect this document toserve as a reference guide for users of the OWL language.
This document is one component of the description of OWL, the Web OntologyLanguage, being produced by the W3C Web Ontology Working Group.TheDocument Roadmap section of the OWL Overview document describes each of the different partsand how they fit together.Readersunfamiliar with OWL may wish to first consult the OWL Overviewdocument [OWL Overview], and subsequently the OWL Guide [OWL Guide] for a more narrative description and examples of the use ofthe language.
This document assumes the reader is familiar with the basic concepts of RDF [RDF Concepts] and has aworking knowledge of the RDF/XML syntax [RDF/XML Syntax] and of RDFSchema [RDF Vocabulary].
The normative reference on the precise syntax of the OWL languageconstructs can be found in the OWLSemantics and Abstract Syntax document [OWL S&AS]. Thatdocument also contains a precise definition of the meaning of thelanguage constructs in the form of a model-theoreticsemantics. Notions such as consistency of OWL ontologiesare discussed in that document.
Use cases and requirements for the OWL language are described in the OWLrequirements document[OWL Requirements].Test cases for OWL tools (e.g., entailment tests, consistency tests)are specified in the Test document[OWL Test Cases] .
1.2 OWL Full/DL/Lite
As also discussed in the OWL Overview document [OWL Overview], and subsequently the OWL Guide [OWL Guide], the OWL language provides two specific subsets that we believe willbe of use to implementors and language users. OWL Lite wasdesigned for easy implementation and to provide users with afunctional subset that will get them started in the use of OWL.OWL DL (where DL stands for "Description Logic") was designed to support the existingDescription Logic business segment and to provide a language subsetthat has desirable computational properties for reasoning systems.The complete OWL language (called OWL Full to distinguish it from thesubsets) relaxes some of the constraints on OWL DL so as to make availablefeatures which may be of use to many database and knowledge representation systems, but which violate the constraints of Description Logic reasoners.
NOTE: RDF documents will generally be in OWL Full, unless they arespecifically constructed to be in OWL DL or Lite.
OWL Full and OWL DL support the same set of OWL language constructs. Their difference lies in restrictions on the use of some of those features and on the use of RDF features. OWL Full allows free mixing of OWL with RDF Schema and, like RDF Schema, does not enforce a strict separation of classes, properties, individuals and data values. OWL DL puts constraints on the mixing with RDF and requires disjointness of classes, properties, individuals and data values. The main reason for having the OWL DL sublanguage is that tool builders have developed powerful reasoning systems which support ontologies constrained by the restrictions required for OWL DL. For the formal definitions of the differences between OWL Full and OWL DL the reader is referred to the Semantics and Abstract Syntaxdocument [OWL S&AS].Sec. 8.2 "OWL DL"summarizes the differences between OWL Full and OWL DL.
OWL Lite is a sublanguage of OWL DL that supports only a subset of the OWL language constructs. OWL Lite is particularly targeted at tool builders, who want to support OWL, but want to start with a relatively simple basic set of language features. OWL Lite abides by the same semantic restrictions as OWL DL,allowing reasoning engines to guarantee certain desirable properties. A summary of the language constructs allowed in OWL Lite is given inSec. 8.3.For a more formal description of the subset of OWL language constructs supported by OWL Lite the reader is referred to the Semantics andAbstract Syntax document[OWL S&AS].
NOTE: RDF users upgrading to OWL should be aware that OWL Lite isnot simply an extension of RDF Schema. OWL Lite is a lightversion of OWL DL and puts constraints on the use of the RDFvocabulary (e.g., disjointness of classes, properties,etc.). OWL Full is designed for maximal RDF compatibility and istherefore the natural place to start for RDF users. When opting foreither OWL DL or OWL Lite one should consider whether the advantagesof OWL DL/Lite (e.g., reasoning support) outweigh the DL/Literestrictions on the use of OWL and RDF constructs.
NOTE: OWL Lite is defined in this document as a number of additional restrictions on OWL DL. Thismean that, OWL DL constructs are also part of OWL Lite, unlessexplicitly stated otherwise.Sec. 8.3.provides a summary of these additionalOWL Lite restrictions.
1.3 OWL syntax
An OWL ontology is an RDF graph [RDF Concepts], which is in turn a set of RDF triples.As with any RDF graph, an OWL ontology graph can bewritten in many different syntactic forms (as described in the RDF/XML Syntax Specification (Revised)[RDF/XML Syntax]).The current document uses some specific syntactic forms of RDF/XML for representing triples(as does the Guide document) .However, the meaning of an OWL ontology is solely determined by theRDF graph. Thus, it is allowable to use other syntactic RDF/XMLforms, as long as these result in the same underlying set of RDF triples. Such other syntactic forms would then carry exactly the samemeaning as the syntactic form used in thisdocument.
As a simple example of an alternative syntacticform resulting in the same RDF triples, consider the following RDF/XML syntax:
<owl:Class rdf:ID="Continent"/>
The following RDF/XML syntax:
<rdf:Description rdf:about="#Continent"> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/></rdf:Description>
encodes the same set of RDF triples, and thereforewould convey the same meaning.
1.4 OWL and RDF semantics
OWL is a vocabulary extension of RDF [RDF Semantics]. Thus any RDF graphforms an OWL Full ontology. Further, the meaning given to an RDFgraph by OWL includes the meaning given to the graph by RDF. OWL Fullontologies can thus include arbitrary RDF content, which is treated ina manner consistent with its treatment by RDF. OWL assigns anadditional meaning to certain RDF triples. The OWL Semantics andAbstract Syntax document [OWLS&AS] specifies exactly which triples are assigned aspecific meaning, and what this meaning is.
NOTE: As remarked before, OWL DL and OWL Lite extend the RDFvocabulary, but also put restrictions on the use of this vocabulary.Therefore, RDF documents will generally be in OWL Full, unless theyare specifically constructed to be in OWL DL or Lite.
For readability purposes the examples in this document assume the XML entities&rdf;,&rdfs;,&owl; and&xsd; (for XML Schema datatypes) are defined in the same wayas inAppendix B. The same assumption holds for thecorresponding namespacesrdf:,rdfs:,owl: andxsd:.
The examples in this document are meant to serve as illustrations of theuse of OWL language constructs. They do not form one consistent ontology. Foran extended example the reader is referred to the Guide document[OWL Guide].
OWL's ability to express ontological information about individualsappearing in multiple documents supports linking of data from diversesources in a principled way. The underlying semantics providessupport for inferences over this data that may yield unexpectedresults. In particular, the ability to express equivalences usingowl:sameAs can be used to state that seeminglydifferent individuals are actually the same.Similarly,owl:InverseFunctionalProperty can be used to linkindividuals together.For example, if a property such asSocialSecurityNumberis anowl:InverseFunctionalProperty, then two separate individualscould be inferred to be identical based on having the same value ofthat property. When individuals are determined to be the same by suchmeans, information about them from different sources can bemerged. Thisaggregation can be used to determine facts thatare notdirectly represented in any one source.
The ability of the Semantic Web to link information from multiplesources is a desirable and powerful feature that can be used in manyapplications.However, the capability to merge data from multiple sources, combined with theinferential power of OWL, does have potential for abuse. It may even be illegalto create or to process such linked information in countries with dataprotection laws, especially in the EU, without having a valid legal reason forsuch processing. Therefore, great care should be taken when using OWL with anykind of personal data that might be linked with other data sources orontologies. Detailed security solutions were considered out of scope for theWorking Group. Work currently underway elsewhere is expected to address theseissues with a variety of security and preference solutions -- see for exampleSAML andP3P
This document has a set of appendices containing additional information.
Links in this document that are attached to definitions of language constructs provide access to theOWL Semantics and Abstract Syntax [OWL S&AS].Appendix A contains asystematic set of links for each language construct to thecorresponding sections in the Guide and the S&AS documents.
Appendix Bcontains a RDF schema for the OWL language constructs. This schema provides information about the OWL vocabulary that couldbe a useful reference point for ontology builders and tooldevelopers. The restrictions provided by the schema on the OWL classesand properties are informative and not complete. Also, this schemadoes not make distinctions between OWL Full, OWL DL and OWL Lite.Conventionally, classeshave a leading uppercase character; properties a leadinglowercase character. Thus,owl:Ontology is a class, andowl:imports is a property.
NOTE: The RDF Schema file for OWL is not expected to be imported explicitly(i.e., withowl:imports) into an ontology. The schemahas an informative status and is meant to provide the classes and properties to be used in the RDF/XML syntax.People that do import this schema should expect the resulting ontology to be an OWL Full ontology.
Appendix C gives a tabular overview of theOWL vocabulary interms of the built-in OWL classes and properties (the latter with their domain and range).
For readers familiar with DAML+OIL,Appendix D listsmany of the changes between DAML+OIL and OWL.
Finally,Appendix E provides a set ofpractical guidelines for specifying OWL DL ontologies in RDF.
2. OWL document
Information in OWL is gathered into ontologies, which can then bestored as documents in the World Wide Web. One aspect of OWL, theimporting of ontologies, depends on this ability to store OWLontologies in the Web.An OWL document consists of optionalontology headers (generally at most one) plus any number ofclass axioms,property axioms,andfacts about individuals.Please note that "axiom" is the formal term used in the S&ASdocument. These axioms are somewhat more informally called"definitions" in the Guide and Overview documents.
NOTE: OWL does not impose any order on OWL components. Humans writing ontologies are likely to use some sort of ordering, for exampleputting the ontology header in the beginning, but this has no impact on themeaning. Tools should not assume any order.
As with most RDF documents, the OWL code should be subelements of ardf:RDF element. This enclosing element generally holds XML namespace and base declarations. Also, an OWL ontology document often starts with several entity declarations.For a typical example of this sort of information, see theexample wine and food ontologiesdiscussed in the Guide document[OWL Guide].
The built-in vocabulary for OWL all comes from the OWL namespace
http://www.w3.org/2002/07/owl#
conventionally associated with the namespace nameowl. It isrecommended that ontologies not use names from this namespace exceptfor the built-in vocabulary. OWL tool builders should feel free tosignal a warning if other names from this namespace are used, butshould otherwise continue as normal.
The Web Ontology Working Group has not requested a separate MIME type for OWLdocuments. Instead, we recommend to use the MIME type requested by the RDF CoreWorking Group, namelyapplication/rdf+xml[RDF Concepts], or alternatively theXML MIME typeapplication/xml.
As file extension, we recommend to use either.rdf or.owl.
Classes provide an abstraction mechanism for grouping resources withsimilar characteristics. Like RDF classes, every OWL class is associated with a set of individuals, called theclassextension. The individuals in the class extension are called theinstances of the class. A class has an intensional meaning(the underlying concept) which is related but not equal to its classextension. Thus, two classes may have the same class extension, but still bedifferent classes.
When in this document we use wording such as "a class of individuals..", this should be read as "a class with a class extension containingindividuals ...".
NOTE: In OWL Lite and OWL DL an individual can never be at the same time aclass: classes and individuals form disjoint domains (as do properties and datavalues). OWL Full allows the freedom of RDF Schema: a class may act as aninstance of another (meta)class.
OWL classes are described through "class descriptions", which can becombined into "class axioms". We first describe class descriptions andsubsequently turn to class axioms.
A class description is the term used in this document (and in the OWLSemantics and Abstract Syntax) for the basic building blocks of class axioms(informally called class definitions in the Overview and Guide documents). A class description describes an OWL class, either by a class name orby specifying the class extension of an unnamed anonymous class.
OWL distinguishes six types of class descriptions:
- a class identifier (a URI reference)
- an exhaustiveenumeration of individuals that together form the instances of a class
- aproperty restriction
- theintersection of two or more class descriptions
- theunion of two or more class descriptions
- thecomplement of a class description
The first type is special in the sense that it describes a class through aclass name (syntactically represented as a URIreference). The other five types of class descriptions describe an anonymous class byplacingconstraints on the class extension.
Class descriptions of type 2-6describe, respectively, a class that contains exactly the enumeratedindividuals (2nd type), a class of all individuals which satisfy aparticular property restriction (3rd type), or a class that satisfies boolean combinations ofclass descriptions (4th, 5th and 6th type).Intersection, union and complement can be respectively seen asthe logical AND, OR and NOT operators.The four latter types of class descriptions lead to nested classdescriptions and can thus in theory lead to arbitrarily complex classdescriptions. In practice, the level of nesting is usually limited.
A type 1 class description is syntactically represented as an named instance ofowl:Class, a subclass ofrdfs:Class:
<owl:Class rdf:ID="Human"/>
This will assert the triple"ex:Human rdf:type owl:Class.", whereex: is the namespace of the relevant ontology .
NOTE: In OWL Lite and OWL DL,owl:Class (orowl:Restriction, see further) must be used for all class descriptions.
NOTE:owl:Class is defined as a subclass ofrdfs:Class. The rationale for having a separate OWL class construct lies in the restrictions on OWLDL (and thus also on OWL Lite), which imply that not all RDFS classes are legalOWL DL classes. In OWL Full these restrictions do not exist and thereforeowl:Class andrdfs:Class are equivalent inOWL Full.
The other five forms of class descriptions consist of a set of RDF triples in which a blank node represents the class being described. That blank node has anrdf:type property whose value isowl:Class.
NOTE: If one provides an RDF identifier for class descriptions ofthe enumeration, intersection, union or complement type, this is not considered to be a class description, but aspecial kind of class axiom for complete classes.SeeSec. 3.2.3 for details.
NOTE: In this document we sometimes use for readability purposes the shorthand "class description" torefer to "the class being described by the classdescription". Strictly speaking, these are different in the case ofclass descriptions of type 2-6: the class is represented by thecorresponding blank node; the class description is represented by thetriples that have this blank node as their subject.
Two OWL class identifiers are predefined, namely the classesowl:Thingandowl:Nothing.The class extension ofowl:Thing is the set of allindividuals. The class extension ofowl:Nothing is theempty set. Consequently, every OWL class is asubclass ofowl:Thing andowl:Nothing is a subclassof every class (for the meaning of the subclass relation, see the section onrdfs:subClassOf).
A class description of the"enumeration" kind is defined with theowl:oneOfproperty. The value of this built-in OWL property must be a list of individuals that are theinstances of the class. This enables a class to be described byexhaustively enumerating its instances.The class extension of a class described withowl:oneOfcontains exactly the enumeratedindividuals, no more, no less. The list of individuals is typicallyrepresented with the help of the RDF constructrdf:parseType="Collection", which provides a convenientshorthand for writing down a set of list elements. For example, the following RDF/XML syntax defines a class of all continents:
<owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Eurasia"/> <owl:Thing rdf:about="#Africa"/> <owl:Thing rdf:about="#NorthAmerica"/> <owl:Thing rdf:about="#SouthAmerica"/> <owl:Thing rdf:about="#Australia"/> <owl:Thing rdf:about="#Antarctica"/> </owl:oneOf></owl:Class>
The RDF/XML syntax<owl:Thing rdf:about="..."/>refers to some individual (remember: all individuals are by definition instances ofowl:Thing).
In the section on datatypes we will see another use oftheowl:oneOf construct, namely to define anenumeration of data values.
NOTE: Enumeration is not part of OWL Lite
A property restriction is a special kind of classdescription. It describes an anonymous class, namely a class ofall individuals that satisfy the restriction.OWL distinguishes two kinds of property restrictions: valueconstraints and cardinality constraints.
Avalue constraint puts constraints on therange of the propertywhen applied to this particular classdescription. For example, we might want torefer to those individuals whose value of the propertyadjacentToshould be someRegion, and then use this within a class axiom, perhapseven a class axiom forRegion itself. Note that this is different fromrdfs:range, which isapplied to all situations in which the property is used.
Acardinalityconstraint puts constraints on the number of values a property can take,in the context of this particular class description. For example, we might want to say that for a soccer team thehasPlayer property has 11 values. For a basketball team the same propertywould have only 5 values.
OWL also supports a limited set of constructs for defining global propertycardinality, namelyowl:FunctionalProperty and owl:InverseFunctionalProperty(see the section on properties).
Property restrictions have the following general form:
<owl:Restriction> <owl:onProperty rdf:resource="(some property)" /> (precisely one value or cardinality constraint, see below)</owl:Restriction>
The classowl:Restrictionis defined as a subclass ofowl:Class. A restriction class shouldhave exactly one triple linking the restriction to a particular property, using the owl:onPropertyproperty. The restriction class should also have exactly one triple that represents the value constraintc.q. cardinalityconstraint on the property under consideration,e.g., that thecardinality of the property is exactly 1.
Property restrictions can be applied both todatatype properties (properties forwhich the value is a data literal) andobjectproperties (properties for which the value is an individual). Formore information about this distinction, see the section onproperties.
The value constraintowl:allValuesFromis a built-in OWL property that links a restriction class to either aclass description or adatarange. A restriction containing anowl:allValuesFromconstraint is used to describe a class of all individuals for which all values of the property under consideration are either members of the classextension of the class description or are data values within the specified datarange. In other words, it defines a class of individuals x for which holdsthat if the pair (x,y) is an instance of P (the property concerned), then yshould be an instance of the class description or a value in the data range,respectively.
A simple example:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:allValuesFrom rdf:resource="#Human" /></owl:Restriction>
This example describes an anonymous OWL class of all individuals for whichthehasParent property only has values of classHuman. Note that this class description does not statethat the property always has values of this class; just that this is true for individualsthat belong to the class extension of the anonymous restriction class.
NOTE: In OWL Lite the only type of class description allowed as object ofowl:allValuesFrom is a class name.
Anowl:allValuesFromconstraint is analogous to the universal (for-all) quantifier ofPredicate logic - for each instance of the class that isbeing described, every value for P must fulfill the constraint. Alsonotice that the correspondence ofowl:allValuesFrom with theuniversal quantifier means that anowl:allValuesFrom constraint fora property P is trivially satisfied for an individual that has novalue for property P at all. To see why this is so, observe that theowl:allValuesFromconstraint demands that all values of P should be of type T, and if nosuch values exist, the constraint is trivially true.
The value constraintowl:someValuesFromis a built-in OWL property that links a restriction class to aclass description or adata range. A restriction containing anowl:someValuesFrom constraintdescribes a class of all individuals for which at least one value of theproperty concerned is an instance of the class description or a data value inthe data range. In other words, it defines a class of individuals x forwhich there is at least one y (either an instance of the class description orvalue of the data range) such that the pair (x,y) is an instance of P. Thisdoes not exclude that there are other instances (x,y') of P for which y' doesnot belong to the class description or data range.
The following example defines a class of individuals which have at least oneparent who is a physician:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:someValuesFrom rdf:resource="#Physician" /></owl:Restriction>
Theowl:someValuesFromconstraint is analogous to the existential quantifier of Predicate logic - foreach instance of the class that is being defined, there exists atleast one value for P that fulfills the constraint.
NOTE: In OWL Lite the only type of class description allowed as object ofowl:someValuesFrom is a class name.
The value constraintowl:hasValueis a built-in OWL property that links a restriction class to a value V, which can be either anindividual or adata value. A restriction containing aowl:hasValue constraintdescribes a class of all individuals forwhich the property concerned has at least one valuesemantically equal to V (it may have other values as well).
NOTE: for datatypes "semantically equal" means that the lexical representation of the literals maps to the same value. For individuals it means that theyeither have the same URI reference or are defined as being the sameindividual (seeowl:sameAs).
NOTE: the value constraintowl:hasValue is not included in OWL Lite.
The following example describes the class of individuals who have theindividual referred to asClinton as their parent:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:hasValue rdf:resource="#Clinton" /></owl:Restriction>
In OWL, like in RDF, it is assumed that any instance of a class may have anarbitrary number (zero or more) of values for a particular property. To make aproperty required (at least one), to allow only a specific number of values forthat property, or to insist that a property must not occur, cardinalityconstraints can be used. OWL provides three constructs for restricting thecardinality of properties locally within a class context.
NOTE: OWL Lite includes the use of all three types of cardinalityconstraints, but only when used with the values "0" or "1".
The cardinality constraintowl:maxCardinalityis a built-in OWL property that links a restriction class to a data value belonging to the value space ofthe XML Schema datatypenonNegativeInteger. A restrictioncontaining anowl:maxCardinality constraint describes a class ofall individuals that haveat most N semantically distinct values(individuals or datavalues) for the property concerned, where N is the value of thecardinality constraint. Syntactically, the cardinality constraint isrepresented as an RDF property element with the correspondingrdf:datatypeattribute.
The following example describes a class of individuals that have at mosttwo parents:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality></owl:Restriction>
RDF datatyping is discussed in more detail inSec. 6.
The cardinality constraintowl:minCardinalityis a built-in OWL property that links a restriction class to a data value belonging to the value space ofthe XML Schema datatypenonNegativeInteger. A restrictioncontaining anowl:minCardinality constraint describes a class ofall individuals that haveat least N semantically distinct values(individuals or datavalues) for the property concerned, where N is the value of thecardinality constraint. Syntactically, the cardinality constraint is representedas an RDF property element with the correspondingrdf:datatypeattribute.
The following example describes a class of individuals that have at leasttwo parents:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:minCardinality></owl:Restriction>
Note that anowl:minCardinality of one or more means thatall instances of the class must have a value for the property.
The cardinality constraintowl:cardinalityis a built-in OWL property thatlinks a restriction class to a data value belonging to the range ofthe XML Schema datatypenonNegativeInteger. A restrictioncontaining anowl:cardinality constraint describes a class ofall individuals that have exactly N semantically distinct values(individuals or datavalues) for the property concerned, where N is the value of thecardinality constraint. Syntactically, the cardinality constraint is representedas an RDF property element with the correspondingrdf:datatypeattribute.
This construct is in fact redundant as itcan always be replaced by a pair of matchingowl:minCardinalityandowl:maxCardinalityconstraints with the same value. It is included as a convenient shorthand forthe user.
The following example describes a class of individuals that have exactlytwo parents:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:cardinality></owl:Restriction>
The three types of class descriptions in this section represent the moreadvanced class constructors that are used in Description Logic. They can beviewed as representing the AND, OR and NOT operators on classes. The three operators get the standard set-operatornames: intersection, union and complement. These language constructsalso share the characteristic that they contain nested class descriptions, either one (complement) or more (union, intersection).
Theowl:intersectionOfproperty links a class to a list ofclass descriptions. Anowl:intersectionOf statementdescribes a class for which the class extension containsprecisely those individuals that are members of the class extension ofall class descriptions in the list.
An example:
<owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Tosca" /> <owl:Thing rdf:about="#Salome" /> </owl:oneOf> </owl:Class> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Turandot" /> <owl:Thing rdf:about="#Tosca" /> </owl:oneOf> </owl:Class> </owl:intersectionOf></owl:Class>
In this example the value ofowl:intersectionOfis a list of twoclass descriptions, namely two enumerations, both describing a classwith two individuals. The resulting intersection isa class with one individual, namelyTosca. as this is the only individual that is common to both enumerations.
NOTE: This assumes that the three individuals are alldifferent. In fact, this is not by definition true in OWL. Different URI references may refer to the same individuals, because OWL does not have a "unique names" assumption. InSec. 5one can find OWL language constructs for makingconstraints about equality and difference of individuals.
NOTE: In this example we use enumerations to makeclear what the meaning is of this language construct. See the OWLGuide [OWL Guide] for moretypical examples.
NOTE: OWL Lite is restricted in its use ofowl:intersectionOf.This is discussed later in this document, seeSec. 3.2.3
owl:intersectionOfcan be viewed as being analogous to logicalconjunction.
Theowl:unionOfproperty links a class to a list ofclass descriptions. Anowl:unionOf statementdescribes an anonymous class for which the class extension containsthose individuals that occur in at least one of the class extensions of the class descriptions in the list.
An example:
<owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Tosca" /> <owl:Thing rdf:about="#Salome" /> </owl:oneOf> </owl:Class> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Turandot" /> <owl:Thing rdf:about="#Tosca" /> </owl:oneOf> </owl:Class> </owl:unionOf></owl:Class>
This class description describes a class for which the class extensioncontains three individuals, namelyTosca,Salome, andTurandot (assuming they are all different).
NOTE:owl:unionOf is not part of OWL Lite.
owl:unionOf is analogous to logical disjunction.
Anowl:complementOfproperty links a class to precisely oneclassdescription. Anowl:complementOf statement describes a class for which the classextension contains exactly those individuals that donot belong to the class extension of the class description that is the object of the statement.owl:complementOf isanalogous to logical negation: the class extension consists of thoseindividuals that are NOT members of the class extension of thecomplement class.
As an example of the use of complement, the expression "not meat" could be writtenas:
<owl:Class> <owl:complementOf> <owl:Class rdf:about="#Meat"/> </owl:complementOf></owl:Class>
The extension of this class description contains all individualsthat do not belong to the classMeat.
NOTE:owl:complementOf is not part of OWL Lite.
Class descriptions form the building blocks for defining classesthrough class axioms. The simplest form of a class axiom is a class descriptionof type 1, It just statesthe existence of a class, usingowl:Class with a class identifier.
For example, the following class axiom declares the URI reference#Human to be thename of an OWL class:
<owl:Class rdf:ID="Human"/>
This is correct OWL, but does not tell us very much about the classHuman. Class axioms typically contain additional components thatstate necessary and/or sufficient characteristics of a class. OWL containsthree language constructs for combining class descriptions into classaxioms:
rdfs:subClassOf allows oneto say that the class extension of a class description is a subset of the class extension of another classdescription.owl:equivalentClass allows oneto say that a class description has exactly the same class extension as another class description.owl:disjointWith allows oneto say that the class extension of a class description has no members incommon with the class extension of another class description.
Syntactically, these three language constructsare properties that have a class description asboth domain and range. We discuss these properties in moredetail in the following subsections.
In addition, OWL allows class axioms in which a class descriptionof the enumeration or the set-operator type is given a name. Theseclass axioms are semantically equivalent to class axioms with aowl:equivalentClass statement, so these will be discussedright after that subsection (seeSec. 3.2.3 "Axioms for complete classes withoutusing owl:equivalentClass").
AXIOM SCHEMA:class descriptionrdfs:subClassOfclassdescription
Therdfs:subClassOf construct is defined as part of RDF Schema[RDF Vocabulary]. Its meaning in OWLis exactly the same: if the class description C1 is defined as a subclass ofclass description C2, then the set of individuals in the class extension of C1should be a subset of the set of individuals in the class extension of C2. A class is by definition a subclass of itself (as the subset may bethe complete set).
An example:
<owl:Class rdf:ID="Opera"> <rdfs:subClassOf rdf:resource="#MusicalWork" /></owl:Class>
This class axiom declares a subclass relation between two OWL classes thatare described through their names (Opera andMusicalWork). Subclass relations provide necessary conditions for belonging to a class. Inthis case, to be an opera the individual also needs to be a musical work.
NOTE: In OWL Lite the subject of anrdfs:subClassOf statement must be a class identifier. Theobject must be either a class identifier or a property restriction.
For any class there may be any number of subClassOf axioms. For example, we could add the following axiom about the classOpera:
<owl:Class rdf:about="#Opera"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasLibrettist" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf></owl:Class>
This class axiom contains a property restriction. The example states thatOperais a subclass of an anonymous OWL class (remember:owl:Restrictionis a subclass ofowl:Class) that has as its class extension the set of all individualsfor which the propertyhasLibrettist has at least onevalue. Thus, operas should have at least one librettist.
Class axioms can get more complex when class descriptions are nested.For example, property restrictions with anowl:allValuesFromorowl:someValuesFromstatement may point to any class description.Consider the following example:
<owl:Class rdf:ID="TraditionalItalianOpera"> <rdfs:subClassOf rdf:resource="#Opera"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasOperaType"/> <owl:someValuesFrom> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#OperaSeria"/> <owl:Thing rdf:about="#OperaBuffa"/> </owl:oneOf> </owl:Class> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf></owl:Class>
This example shows the use of theowl:oneOf construct. The class axiom defines traditional Italian opera as a subclass of a class of operas that have as opera type eitheropera seria oropera buffa (without an additional cardinality constraint, itcould actually have both values).
More examples can be found in the Guide document[OWL Guide].Subclass axioms provide us with partial definitions: they represent necessarybut not sufficient conditions for establishing class membership of anindividual. In the next subsection we will see that for defining necessaryand sufficient conditions OWL provides theowl:equivalentClassconstruct. As a stepping stone to such axioms,consider the following example:
<owl:Class rdf:ID="Operetta"> <rdfs:subClassOf rdf:resource="#MusicalWork"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasLibrettist" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class> <owl:complementOf rdf:resource="#Opera"/> </owl:Class> </rdfs:subClassOf> </owl:Class>
This class axiom states that an operetta is a musical work, that has aat least one librettist and is not an opera. The use of the subclass relation leaves openthe possibility that there are other musical works that have a librettist andare not operas. If we had wanted to say that operetta's areexactlythose musical works that have a librettist but are not operas, wewould need to use theowl:equivalentClassconstruct.
AXIOM SCHEMA:class descriptionowl:equivalentClassclassdescription
A class axiom may contain (multiple)owl:equivalentClass statements.owl:equivalentClass is a built-inproperty that links a class descriptionto another class description. The meaning of such a class axiom is that the two class descriptions involved have the same class extension(i.e., both class extensions contain exactly the same set of individuals).
In its simplest form, an equivalentClass axiom states the equivalence (in terms of their class extension) of two namedclasses. An example:
<owl:Class rdf:about="#US_President"> <equivalentClass rdf:resource="#PrincipalResidentOfWhiteHouse"/></owl:Class>
NOTE:The use ofowl:equivalentClass does not imply classequality. Class equality means that the classes have the same intensionalmeaning (denote the same concept). In the example above, the concept of"President of the US" is related to, but not equal to the concept of theprincipal resident of a certain estate. Real class equality can only be expressed with theowl:sameAs construct. As this requires treating classes asindividuals, class equality can only be expressed in OWL Full.
Axioms withowl:equivalentClass can also be used todefine an enumerated class by linking a type 1 class description (aclass identifier) to a type 2 class description (an enumeration). Anexample:
<owl:Class rdf:ID="DaPonteOperaOfMozart"> <owl:equivalentClass> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <Opera rdf:about="#Nozze_di_Figaro"/> <Opera rdf:about="#Don_Giovanni"/> <Opera rdf:about="#Cosi_fan_tutte"/> </owl:oneOf> </owl:Class> </owl:equivalentClass></owl:Class>
This class axiom defines the class of operas that together represent the "Da Ponte operas of Mozart" (apopular subject in musicology). By using the equivalentClass construct we can statenecessary and sufficient conditions for class membership, in this caseconsisting of an enumeration of three individuals, no less, no more.
NOTE: OWL DL does not put any constraints on thetypes of class descriptions that can be used as subject and objectof anowl:equivalentClass statement. In OWL Litethe subject must be a class name and the object must be either a classname or a property restriction.
NOTE: Although in principle different types of class descriptions are allowedas the subject of an equivalentClass statement, in practice it usually is some classidentifier. This is also true for the examples in this section.
It is possible to have multiple equivalentClass axioms about the sameclass.However, this requires care. Both axioms must lead to the sameoutcome, i.e. exactly the same class extension. For example, an alternateequivalentClass axiom for Mozart's "Da Ponte operas" could be the followingone:
<owl:Class rdf:about="#DaPonteOperaOfMozart"> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:onProperty rdf:resource="#hasComposer"/> <owl:hasValue rdf:resource="#Wolfgang_Amadeus_Mozart"/> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="#hasLibrettist"/> <owl:hasValue rdf:resource="#Lorenzo_Da_Ponte"/> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:equivalentClass></owl:Class>
This states that the class extension of the Da Ponte operas ofMozart corresponds exactly to those operas which are composed byMozart and for which the libretto is written by Da Ponte (note:intersection = "and"). This axiom indeed defines a class with exactly the same instances as theprevious axiom.
NOTE: If we wanted to "upgrade" an axiom of the form"A subClassOf B" to "A equivalentClass B" (meaning that the classextension of A is not just any subset, but in fact the same set as theclass extension of B), we could add a second subClassOf axiom of theform (B subClassOf A), which by definition makes the two classextensions equivalent (and thus has the same meaning as "AequivalentClass B"). Such subClassOf "cycles" are explicitly allowed.As OWL is usable in a distributed environment, this can be a usefulfeature.
AXIOM SCHEMA:namedclass description of type 2 (withowl:oneOf) ortype 4-6 (withowl:intersectionOf,owl:unionOforowl:complementOf
OWL allows users to define class axioms by giving a name to classdescriptions of theenumeration or set-operator type. Such a class axiom defines necessary andsufficient conditions for establishing class membership. An example:
<owl:Class rdf:ID="DaPonteOperaOfMozart"> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Nozze_di_Figaro"/> <owl:Thing rdf:about="#Don_Giovanni"/> <owl:Thing rdf:about="#Cosi_fan_tutte"/> </owl:oneOf></owl:Class>
This class axiom should be interpreted as follows: the class extension ofthe classDaPonteOperaOfMozart is exactly defined by the enumeration.
This class axiom is semantically equivalent to thefirst opera example in the previous section, which included an additionalowl:equivalentClass statement. Axioms of this type can also beconstructed withowl:intersectionOf,owl:unionOf andowl:complementOf.An example with a union could be:
<owl:Class rdf:ID="LivingBeing"> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Plant"/> <owl:Class rdf:about="#Animal"/> </owl:unionOf></owl:Class>
This class axiom states that the class extension ofLivingBeing exactly correspondsto the union of the class extensions ofPlant andAnimal.
NOTE: OWL Lite only includes class axioms of this type which are constructed with theowl:intersectionOf property. The values of theintersectionOf list must be class identifiers and/or property restrictions. Thus, "complete class" axiomsusing enumeration, complement andunion are not allowed in OWL Lite.
AXIOM SCHEMA:class descriptionowl:disjointWithclassdescription
A class axiom may also contain (multiple)owl:disjointWithstatements.owl:disjointWith is abuilt-in OWL property with a classdescription as domain and range. Eachowl:disjointWith statement asserts that the class extensions of the two class descriptionsinvolved have no individuals in common. Like axioms withrdfs:subClassOf, declaring two classes to be disjoint is a partialdefinition: it imposes a necessary but not sufficient condition on theclass.
This is a popular example of class disjointness:
<owl:Class rdf:about="#Man"> <owl:disjointWith rdf:resource="#Woman"/></owl:Class>
Whether this is actually true is a matter for biologists todecide. The following example shows a common use of class disjointness insubclass hierarchies:
<owl:Class rdf:about="#MusicDrama"> <owl:equivalentClass> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Opera"/> <owl:Class rdf:about="#Operetta"/> <owl:Class rdf:about="#Musical"/> </owl:unionOf> </owl:Class> </owl:equivalentClass></owl:Class><owl:Class rdf:about="#Opera"> <rdfs:subClassOf rdf:resource="#MusicDrama"/></owl:Class><owl:Class rdf:about="#Operetta"> <rdfs:subClassOf rdf:resource="#MusicDrama"/> <owl:disjointWith rdf:resource="#Opera"/></owl:Class><owl:Class rdf:about="#Musical"> <rdfs:subClassOf rdf:resource="#MusicDrama"/> <owl:disjointWith rdf:resource="#Opera"/> <owl:disjointWith rdf:resource="#Operetta"/></owl:Class>
Here,owl:disjointWithstatements are used together withowl:unionOfin order to define a set of mutually disjoint and complete subclasses of asuperclass. In natural language: everyMusicDrama is either anopera, anOperetta, or aMusical (the subclasspartitioning is complete) and individuals belonging to one subclass,e.g.,Opera, cannot belong to another subclass,e.g.,Musical (disjoint or non-overlapping subclasses). This is a commonmodelling notion used in many data-modelling notations.
NOTE: OWL Lite does not allow the use ofowl:disjointWith.
OWL distinguishes between two main categories of properties that anontology builder may want to define:
- Object properties link individuals to individuals.
- Datatype properties link individuals to data values.
NOTE: OWL also has the notion of annotation properties(owl:AnnotationProperty) and ontology properties(owl:OntologyProperty). These are needed in OWL DL for semanticreasons. SeeSec. 7 and the OWL Semantics and Abstract Syntax document[OWL S&AS].
An object property is defined as an instance of the built-in OWL classowl:ObjectProperty. A datatype property is defined as an instance of the built-in OWL classowl:DatatypeProperty. Bothowl:ObjectProperty andowl:DatatypeProperty are subclasses of the RDF classrdf:Property (seeAppendix B).
NOTE: In OWL Full, object properties and datatype properties arenot disjoint. Because data values can be treated as individuals, datatypeproperties are effectively subclasses of object properties. In OWL Fullowl:ObjectProperty is equivalent tordf:Property In practice, thismainly has consequences for the use ofowl:InverseFunctionalProperty.See also the OWL Full characterization inSec. 8.1.
A property axiom defines characteristics of a property.In its simplest form, a property axiom just defines the existence ofa property. For example:
<owl:ObjectProperty rdf:ID="hasParent"/>
This defines a property with the restriction that its values should beindividuals.
Often, property axioms define additional characteristics of properties. OWLsupports the following constructs for property axioms:
- RDF Schema constructs:
rdfs:subPropertyOf,rdfs:domain andrdfs:range - relations to other properties:
owl:equivalentProperty andowl:inverseOf - global cardinality constraints:
owl:FunctionalProperty andowl:InverseFunctionalProperty - logical property characteristics:
owl:SymmetricProperty andowl:TransitiveProperty
In the next subsections, the various types of property axioms arediscussed in more detail.
NOTE: In this section we use the term "property extension" ina similar fashion to "class extension". The property extension is the set ofinstances that is associated with the property. Instances of properties are notsingle elements, but subject-object pairs of property statements. In relationaldatabaseterms, property instances would be called "tuples" of a binary relation (theproperty).
The constructs in this section are discussed in detail in the RDF Schemadocument [RDF Vocabulary]. Thedescription in this section provides a synopsis of these constructs andprovides some OWL-specific aspects and examples.
Ardfs:subPropertyOf axiom defines that the property is a subproperty of some other property.Formally this means that if P1 is a subproperty of P2, then the propertyextension of P1 (a set of pairs) should be a subset of the property extensionof P2 (also a set of pairs).
An example:
<owl:ObjectProperty rdf:ID="hasMother"> <rdfs:subPropertyOf rdf:resource="#hasParent"/></owl:ObjectProperty>
This states that all instances (pairs) contained in the property extensionof the property "hasMother" are also members of the property extension of theproperty "hasParent".
Subproperty axioms can be applied to both datatype properties and objectproperties.
NOTE: In OWL DL the subject and object of a subproperty statement must be either both datatype properties or both object properties.
For a property one can define (multiple)rdfs:domain axioms. Syntactically,rdfs:domain is a built-in property that links a property(some instance of the classrdf:Property) to aclassdescription. Anrdfs:domain axiom asserts that the subjects of such property statements must belong to the class extension ofthe indicated class description.
Multiplerdfs:domain axioms are allowed and should be interpreted as a conjunction: these restrict the domain of the property to those individuals that belong to theintersection of the class descriptions. If one would want to saythat multiple classes can act as domain, one should use a class descriptionof theowl:unionOf form. For example, if we want to say that the domain of the propertyhasBankAccount can be either aPerson or aCorporation, we would need tosay something like this:
<owl:ObjectProperty rdf:ID="hasBankAccount"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Person"/> <owl:Class rdf:about="#Corporation"/> </owl:unionOf> </owl:Class> </rdfs:domain></owl:ObjectProperty>
NOTE: In OWL Lite the value ofrdfs:domainmust be a class identifier.
For a property one can define (multiple)rdfs:range axioms. Syntactically,rdfs:range is a built-in property that links a property(some instance of the classrdf:Property) to to either aclassdescription or adata range. Anrdfs:range axiom asserts that the values of this property must belong to the class extension ofthe class description or to data values in the specified data range.
Multiple rangerestrictions are interpreted as stating that the range of the property is theintersection of all ranges (i.e., the intersection of the class extension of the class descriptionsc.q. the intersection of the data ranges). Similar tordfs:domain,multiple alternativeranges can be specified by using a class description of theowl:unionOf form (see the previoussubsection).
Note that, unlike any of thevalueconstraints described in the section on class descriptions,rdfs:range restrictions areglobal. Value constraints such asowl:allValuesFrom are used in a class description and are onlyenforced on the property when applied to that class. In contrast,rdfs:range restrictions apply to the property irrespective of theclass to which it is applied. Thus,rdfs:range should beused with care.
NOTE: In OWL Lite the only type of class descriptions allowed as objects ofrdfs:range are class names.
Theowl:equivalentProperty construct can be used to state that two properties have the same propertyextension. Syntactically,owl:equivalentProperty is abuilt-in OWL propertywithrdf:Property as both its domain and range.
NOTE: Property equivalence is not the same as propertyequality. Equivalent properties have the same "values" (i.e., the same property extension),but may have different intensional meaning (i.e., denote different concepts).Property equality should be expressed with theowl:sameAs construct. As thisrequires that properties are treated as individuals, such axioms are onlyallowed in OWL Full.
Properties have a direction, from domain to range. In practice, people oftenfind it useful to define relations in both directions: persons owncars, cars are owned by persons.Theowl:inverseOfconstruct can be used to define such an inverse relation betweenproperties.
Syntactically,owl:inverseOf is a built-in OWLproperty withowl:ObjectProperty as its domain andrange.An axiom of theformP1 owl:inverseOf P2 assertsthat for every pair(x,y) in the property extension of P1, there is a pair (y,x) in the propertyextension of P2, and vice versa. Thus,owl:inverseOf is asymmetric property.
An example:
<owl:ObjectProperty rdf:ID="hasChild"> <owl:inverseOf rdf:resource="#hasParent"/></owl:ObjectProperty>
A functional property is a property that can have only one (unique) value y for each instance x, i.e. therecannot be two distinct values y1 and y2 such that the pairs (x,y1) and(x,y2) are both instances of this property. Both object properties and datatype properties can be declared as"functional". For this purpose, OWL defines the built-in classowl:FunctionalPropertyas a special subclass of the RDF classrdf:Property.
The following axiom states that thehusband property isfunctional,i.e., a woman can have at most one husband (a goodexample of culture dependence of ontologies):
<owl:ObjectProperty rdf:ID="husband"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Woman" /> <rdfs:range rdf:resource="#Man" /></owl:ObjectProperty>
As always, there are syntacticvariations. The example above is semantically equivalent to the one below:
<owl:ObjectProperty rdf:ID="husband"> <rdfs:domain rdf:resource="#Woman" /> <rdfs:range rdf:resource="#Man" /></owl:ObjectProperty><owl:FunctionalProperty rdf:about="#husband" />
If aproperty is declared to be inverse-functional, then the object of aproperty statement uniquelydetermines the subject (some individual). More formally, if we state thatP is anowl:InverseFunctionalProperty, then this asserts that avalue y can only be the value of P for a single instance x, i.e. therecannot be two distinct instances x1 and x2 such that both pairs (x1,y) and(x2,y) are instances of P.
Syntactically, an inverse-functional property axiom is specified by declaring the property to be an instance of the built-in OWL classowl:InverseFunctionalProperty,which is a subclass of the OWL classowl:ObjectProperty.
NOTE: Because inOWL Full datatype properties are a subclass of objectproperties, an inverse-functional property can be defined for datatype properties. In OWL DL object properties and datatype properties aredisjoint, so an inverse-functional property cannot be defined for datatypeproperties. See alsoSec. 8.1 andSec. 8.2.
A typical example of an inverse-functional property:
<owl:InverseFunctionalProperty rdf:ID="biologicalMotherOf"> <rdfs:domain rdf:resource="#Woman"/> <rdfs:range rdf:resource="#Human"/></owl:InverseFunctionalProperty>
This example states that for each objectofbiologicalMotherOf statements (some human) one should be ableto uniquely identify a subject (some woman). Inverse-functionalproperties resemble the notion of a key in databases.
One difference with functional properties is that for inverse-functionalproperties no additional object-property or datatype-property axiom isrequired: inverse-functional properties are by definition object properties.
Notice thatowl:FunctionalProperty andowl:InverseFunctionalPropertyspecify global cardinality constraints. That is, no matter which class theproperty is applied to, the cardinality constraints must hold. This isdifferent from the cardinality constraints contained inproperty restrictions. The latter are classdescriptions and are only enforced on the property when applied to thatclass.
When one defines a property P to be a transitive property, this means that if a pair (x,y) is an instanceof P, and the pair (y,z) is also instance of P, then we can infer the the pair (x,z) is alsoan instance of P.
Syntactically, a property is defined as being transitive by making it aninstance of the the built-in OWL classowl:TransitiveProperty,which is defined as a subclass ofowl:ObjectProperty.
Typical examples of transitive properties are propertiesrepresenting certain part-whole relations.For example, we might want to say that thesubRegionOf property between regions is transitive:
<owl:TransitiveProperty rdf:ID="subRegionOf"> <rdfs:domain rdf:resource="#Region"/> <rdfs:range rdf:resource="#Region"/></owl:TransitiveProperty>
From this an OWL reasoner should be able to derive that ifChiantiClassico,Tuscany andItaly are regions, andChiantiClassico is a subregion ofTuscany, andTuscany is a subregion ofItaly, thenChiantiClassico is also a subregion ofItaly.
Note that becauseowl:TransitiveProperty is a subclass ofowl:ObjectProperty, the following syntactic variant is equivalentto the example above:
<owl:ObjectProperty rdf:ID="subRegionOf"> <rdf:type rdf:resource="&owl;TransitiveProperty"/> <rdfs:domain rdf:resource="#Region"/> <rdfs:range rdf:resource="#Region"/></owl:ObjectProperty>
NOTE: OWL DL requires that for a transitive property no local or globalcardinality constraints should be declared on the property itself or itssuperproperties, nor on the inverse of the property or its superproperties.
A symmetric property is a property for which holds that if the pair (x,y) is an instanceof P, then the pair (y,x) is alsoan instance of P. Syntactically, a property is defined as symmetric by making it aninstance of the built-in OWL classowl:SymmetricProperty,a subclass ofowl:ObjectProperty.
A popular example of a symmetric property is thefriendOf relation:
<owl:SymmetricProperty rdf:ID="friendOf"> <rdfs:domain rdf:resource="#Human"/> <rdfs:range rdf:resource="#Human"/></owl:SymmetricProperty>
The domain and range of a symmetric property are the same.
Individuals are defined with individual axioms (also called "facts"). We discuss two types of facts:
- Facts about class membership and property values of individuals
- Facts about individual identity
Many facts typically are statements indicating class membershipof individuals and property values of individuals.As anexample, consider the following set of statements about an instance of theclassOpera:
<Opera rdf:ID="Tosca"> <hasComposer rdf:resource="#Giacomo_Puccini"/> <hasLibrettist rdf:resource="#Victorien_Sardou"/> <hasLibrettist rdf:resource="#Giuseppe_Giacosa"/> <hasLibrettist rdf:resource="#Luigi_Illica"/> <premiereDate rdf:datatype="&xsd;date">1900-01-14</premiereDate> <premierePlace rdf:resource="#Roma"/> <numberOfActs rdf:datatype="&xsd;positiveInteger">3</numberOfActs> </Opera>
This example includes a number of facts about the individualTosca, an instance of the classOpera.Tosca is composed by Giacomo Puccini. The opera has three libretto writers. The propertypremiereDate links an opera to a typed literal with the XML Schema datatypedate. The XML schema document on datatypes[XML Schema Datatypes] contains the relevant information about syntax and semantics ofthis datatype.
Individual axioms need not necessarily be about named individuals: they canalso refer to anonymous individuals. As an example, consider the piece ofRDF/XML below. The example defines some facts about an anonymous instance ofthe classMeasurement, a quantitative observation for which facts such asthe subject under observation, the observed phenomenon, the observed value, andthe observation time are listed:
<Measurement> <observedSubject rdf:resource="#JaneDoe"/> <observedPhenomenon rdf:resource="#Weight"/> <observedValue> <Quantity> <quantityValue rdf:datatype="&xsd;float">59.5</quantityValue> <quantityUnit rdf:resource="#Kilogram"/> </Quantity> </observedValue> <timeStamp rdf:datatype="&xsd;dateTime">2003-01-24T09:00:08+01:00</timeStamp></Measurement>
This individual axiom contains two anonymous individuals, namely someMeasurement and someQuantity. In natural language,forthe subject Jane Doe the measured value of the phenomenonWeight is somequantity, which has a value of 59.5 using the unit of kilogram. The time ofmeasurement is January 24, 2003, eight seconds past nine in the morning, in thetime zone UTC+1 (winter time in Amsterdam, Berlin, Paris). As before,float anddateTime are XML Schema datatypes, thesyntactic and semantic details of which can be found in the relevant XML Schemadocumentation[XML Schema Datatypes].
Many languages have a so-called "unique names" assumption: different namesrefer to different things in the world. On the web, such an assumption is notpossible. For example, the same person could be referred to in many differentways (i.e. with different URI references). For this reason OWL does not makethis assumption. Unless an explicit statement is being made that two URIreferences refer to the same or to different individuals, OWL tools should inprinciple assume either situation is possible.
OWL provides three constructs for stating facts about the identity ofindividuals:
owl:sameAs is used to state that two URI references refer to the same individual.owl:differentFrom is used to state that two URI references refer to different individualsowl:AllDifferent provides an idiom for stating that a list of individuals are all different.
The built-in OWL propertyowl:sameAslinks an individual to an individual. Such anowl:sameAs statement indicates thattwo URI references actually refer to the same thing: theindividuals have the same "identity".
For individuals such as "people" thisnotion is relatively easy to understand. For example, we could state thatthe following two URI references actually refer to the same person:
<rdf:Description rdf:about="#William_Jefferson_Clinton"> <owl:sameAs rdf:resource="#BillClinton"/></rdf:Description>
Theowl:sameAs statements are often used in defining mappingsbetween ontologies. It is unrealistic to assume everybody will use the samename to refer to individuals. That would require some grand design, which iscontrary to the spirit of the web.
In OWL Full, where a class can be treated as instances of(meta)classes, we can use theowl:sameAs construct to define class equality,thus indicating that two concepts have the same intensional meaning. An example:
<owl:Class rdf:ID="FootballTeam"> <owl:sameAs rdf:resource="http://sports.org/US#SoccerTeam"/></owl:Class>
One could imagine this axiom to be part of a European sportsontology. The two classes are treated here as individuals, in thiscase as instances of the classowl:Class. This allows usto state that the classFootballTeam in some Europeansports ontology denotes the same concept as the classSoccerTeam in some American sports ontology. Note thedifference with the statement:
<footballTeam owl:equivalentClass us:soccerTeam />
which states that the two classes have the same class extension,but are not (necessarily) the same concepts.
NOTE: For details of comparison of URI references, see the section on RDF URI references in the RDF Concepts document [RDF Concepts].
The built-in OWLowl:differentFromproperty links an individual to an individual. Anowl:differentFrom statement indicates that two URI referencesrefer to different individuals.
An example:
<Opera rdf:ID="Don_Giovanni"/><Opera rdf:ID="Nozze_di_Figaro"> <owl:differentFrom rdf:resource="#Don_Giovanni"/></Opera><Opera rdf:ID="Cosi_fan_tutte"> <owl:differentFrom rdf:resource="#Don_Giovanni"/> <owl:differentFrom rdf:resource="#Nozze_di_Figaro"/></Opera>
This states that there are three different operas.For ontologies in which the unique-names assumption holds, the useofowl:differentFrom is likely to lead to a large numberof statements, as all individuals have to be declared pairwisedisjoint. For such situations OWL provides a special idiom in the formof the constructowl:AllDifferent.owl:AllDifferent is a special built-in OWL class, forwhich the propertyowl:distinctMembers isdefined, which links an instance ofowl:AllDifferent to alist of individuals. The intended meaning of such a statement is thatall individuals in the list are all different from each other.
An example:
<owl:AllDifferent> <owl:distinctMembers rdf:parseType="Collection"> <Opera rdf:about="#Don_Giovanni"/> <Opera rdf:about="#Nozze_di_Figaro"/> <Opera rdf:about="#Cosi_fan_tutte"/> <Opera rdf:about="#Tosca"/> <Opera rdf:about="#Turandot"/> <Opera rdf:about="#Salome"/> </owl:distinctMembers></owl:AllDifferent>
This states that these six URI references allpoint to different operas.
NOTE:owl:distinctMembers is a special syntactical construct addedfor convenience and should always be used with anowl:AllDifferentindividual as its subject.
6. Datatypes
In a number of places in this document we have seen the notion of adata rangefor specifying a range of data values. OWL allows three types of data rangespecifications:
The minimal level of tool support for datatypes is discussed inSec. 6.3.
6.1 RDF Datatypes
OWL makes use of the RDF datatyping scheme, which provides a mechanism forreferring to XML Schema datatypes[XML Schema Datatypes]. For adetailed description the reader is referred to the RDF documents,e.g., [RDF Concepts].For the convenience ofthe reader, we provide here a synopsis of the use of RDF datatypes.
Data values are instances of the RDF Schema classrdfs:Literal. Literals can be either plain (no datatype) or typed. Datatypes are instances of the classrdfs:Datatype. In RDF/XML, the type of a literal is specified by anrdf:datatypeattribute of whichthe value is recommended to be one of the following:
The RDF Semantics document [RDF Semantics, Section 5]. recommends use of the following simple built-in XML Schema datatypes.
- The primitive datatype
xsd:string, plus the following datatypes derived from xsd:string:xsd:normalizedString,xsd:token,xsd:language,xsd:NMTOKEN,xsd:Name,andxsd:NCName. - The primitive datatype
xsd:boolean. - The primitive numerical datatypes
xsd:decimal,xsd:float, andxsd:double, plus all derived types of xsd:decimal (xsd:integer,xsd:positiveInteger.xsd:nonPositiveInteger,xsd:negativeInteger,xsd:nonNegativeInteger,xsd:long,xsd:int,xsd:short,xsd:byte,xsd:unsignedLong,xsd:unsignedInt,xsd:unsignedShort,xsd:unsignedByte) - The primitive time-related datatypes:
xsd:dateTime,xsd:time,xsd:date,xsd:gYearMonth,xsd:gYear,xsd:gMonthDay,xsd:gDay, andxsd:gMonth. - The primitive datatypes
xsd:hexBinary,xsd:base64Binary, andxsd:anyURI.
NOTE: It is not illegal, although not recommended, for applications to definetheir own datatypes by defining an instance ofrdfs:Datatype. Suchdatatypes are "unrecognized", but are treated in a similar fashion as"unsupported datatypes" (seeSec. 6.3for details about how these should be treated by OWL tools).
When using datatypes, please note that even if a property is definedto have a range of a certain datatype, RDF/XML still requires thatthe datatype be specified each time the property is used. An example could be the declaration of a propertythat we used earlier in theMeasurement example:
<owl:DatatypeProperty rdf:about="#timeStamp"> <rdfs:domain rdf:resource="#Measurement"/> <rdf:range rdf:resource="&xsd;dateTime"/></owl:DatatypeProperty><Measurement> <timeStamp rdf:datatype="&xsd;dateTime">2003-01-24T09:00:08+01:00</timeStamp> </Measurement>
6.2 Enumerated datatype
In addition to the RDF datatypes, OWL provides one additional construct fordefining a range of data values, namely an enumerated datatype. This datatypeformat makes use of theowl:oneOf construct, that is also used fordescribing anenumerated class. In the case ofan enumerated datatype, the subject ofowl:oneOf is a blanknode of classowl:DataRange and the object is a list ofliterals. Unfortunately, we cannot use therdf:parseType="Collection" idiom for specifying the literal list,because RDF requires the collection to be a list of RDF nodeelements. Therefore we have to specify the list of data values with the basiclist constructsrdf:first,rdf:rest andrdf:nil.
NOTE: Enumerated datatypes are not part of OWL Lite.
The example below specifies the range of the propertytennisGameScore to be the list of integer values {0, 15,30, 40}:.
<owl:DatatypeProperty rdf:ID="tennisGameScore"> <rdfs:range> <owl:DataRange> <owl:oneOf> <rdf:List> <rdf:first rdf:datatype="&xsd;integer">0</rdf:first> <rdf:rest> <rdf:List> <rdf:first rdf:datatype="&xsd;integer">15</rdf:first> <rdf:rest> <rdf:List> <rdf:first rdf:datatype="&xsd;integer">30</rdf:first> <rdf:rest> <rdf:List> <rdf:first rdf:datatype="&xsd;integer">40</rdf:first> <rdf:rest rdf:resource="&rdf;nil" /> </rdf:List> </rdf:rest> </rdf:List> </rdf:rest> </rdf:List> </rdf:rest> </rdf:List> </owl:oneOf> </owl:DataRange> </rdfs:range></owl:DatatypeProperty>
6.3 Support for datatype reasoning
Tools may vary in terms of support for datatype reasoning. As a minimum,tools must support datatype reasoning for the XML Schema datatypesxsd:string andxsd:integer. OWL Full tools must also supportrdf:XMLLiteral. For unsupported datatypes, lexically identicalliterals should be considered equal, whereas lexically different literals would not be known to be either equal or unequal. Unrecognized datatypes should be treated in the same way asunsupported datatypes.
7.1 Annotations
OWL Full does not put any constraints on annotations in an ontology. OWL DL allows annotations on classes, properties, individualsand ontology headers, but only under the following conditions:
Five annotation properties are predefined by OWL, namely:
owl:versionInfordfs:labelrdfs:commentrdfs:seeAlsordfs:isDefinedBy
Here is an example of legal use of an annotation property in OWL DL:
<owl:AnnotationProperty rdf:about="&dc;creator"/><owl:Class rdf:about="#MusicalWork"> <rdfs:label>Musical work</rdfs:label> <dc:creator>N.N.</dc:creator></owl:Class>
The example assumes&dc; anddc: pointrespectively to the Dublin Core URI and namespace. Thus, using Dublin Core properties as annotation propertiesin OWL DL requires an explicit typing triple. This ensures annotations are handled in a semantically correct fashion by OWLDL reasoners (see the OWL Semantics and Abstract Syntax document [OWL S&AS] for details).
Once we definedc:creator as an annotation property, OWL DL doesNOT allow property axioms such as the range constraint below:
<-- This is illegal in OWL DL --><owl:AnnotationProperty rdf:about="&dc;creator"> <rdfs:range rdf:resource="&xsd;string"/></owl:AnnotationProperty>
Note that one can still specify the value type of a literal in an annotation-property statement:
<Opera rdf:about="#Tosca"> <dc:creator rdf:datatype="&xsd;string">Giacomo Puccini</dc:creator></Opera>
A document describing an ontology typically contains informationabout the ontology itself. An ontology is a resource, so it may bedescribed using properties from the OWL and other namespaces, e.g.:
<owl:Ontology rdf:about=""> <owl:versionInfo> ... </owl:versionInfo> <rdfs:comment>...</rdfs:comment> <owl:imports rdf:resource="..."/></owl:Ontology>
This is commonly called the ontology header and is typically foundnear the beginning of the RDF/XML document. The line
<owl:Ontology rdf:about="">
states that this block describes the current ontology. Moreprecisely, it states the current base URI identifies an instance ofthe classowl:Ontology. It is recommended that thebase URI be defined using anxml:base attribute in the<rdf:RDF> element at the beginning of the document.
A sample ontology header could look like this:
<owl:Ontology rdf:about=""> <owl:versionInfo>v 1.17 2003/02/26 12:56:51 mdean</owl:versionInfo> <rdfs:comment>An example ontology</rdfs:comment> <owl:imports rdf:resource="http://www.example.org/foo"/></owl:Ontology>
The following sections describe the various types of statements that aretypically used within the header.
NOTE: The ontology-import constructowl:importsand the ontology-versioning constructsowl:priorVersion,owl:backwardCompatibleWithandowl:incompatibleWithare defined in the OWL vocabulary as instances of the OWL built-inclassowl:OntologyProperty. Instances ofowl:OntologyProperty must have the classowl:Ontology as their domain and range. It is permitted to define other instances ofowl:OntologyProperty. In OWL DL forontology properties the same constraints hold as those specified forannotation properties inSec. 7.1.
Anowl:importsstatement references another OWL ontology containing definitions, whose meaning is considered to be part of the meaning of the importing ontology. Each reference consists of a URIspecifying from where the ontology is to be imported.Syntactically,owl:imports is a property with theclassowl:Ontology as its domain and range.
Theowl:imports statements are transitive, that is, ifontology A imports B, and B imports C, then A imports both B and C.
Importing an ontology into itself is considered a null action, so ifontology A imports B and B imports A, then they are considered to beequivalent.Note that whether or not an OWL tool must load an imported ontologydepends on the purpose of the tool. If the tool is a complete reasoner(including complete consistency checkers) then it must load all of theimported ontologies. Other tools, such as simple editors and incompletereasoners, may choose to load only some or even none of the importedontologies.
Although owl:imports and namespace declarations may appearredundant, they actually serve different purposes. Namespacedeclarations simply set up a shorthand for referring to identifiers.They do not implicitly include the meaning of documents located at theURI. On the other hand, owl:imports does not provide any shorthandnotation for referring to the identifiers from the imported document.Therefore, it is common to have a corresponding namespace declarationfor any ontology that is imported.
NOTE:owl:importsis an instance ofowl:OntologyProperty.
Anowl:versionInfostatement generally has as its object a string giving information about thisversion, for example RCS/CVS keywords. This statement does notcontribute to the logical meaning of the ontology other than thatgiven by the RDF(S) model theory.
Although this property is typically used to make statements aboutontologies, it may be applied to any OWL construct. For example, one couldattach aowl:versionInfo statement to an OWL class.
NOTE:owl:versionInfois an instance ofowl:AnnotationProperty.
Anowl:priorVersionstatement contains a reference to another ontology. This identifiesthe specified ontology as a prior version of the containing ontology.This has no meaning in the model-theoretic semantics other than thatgiven by the RDF(S) model theory. However, it may be used by softwareto organize ontologies by versions.
owl:priorVersion is a built-in OWL property with the classowl:Ontology as its domain and range.
NOTE:owl:priorVersionis an instance ofowl:OntologyProperty.
Anowl:backwardCompatibleWithstatement contains a reference to another ontology. This identifiesthe specified ontology as a prior version of the containing ontology,and further indicates that it is backward compatible with it. Inparticular, this indicates that all identifiers from the previousversion have the same intended interpretations in the new version.Thus, it is a hint to document authors that they can safely changetheir documents to commit to the new version (by simply updatingnamespace declarations andowl:imports statements to refer to the URL ofthe new version). Ifowl:backwardCompatibleWith is notdeclared for two versions, then compatibility should not be assumed.
owl:backwardCompatibleWith has no meaning in the model theoretic semantics other than that given by theRDF(S) model theory.
owl:backwardCompatibleWith is a built-in OWL property with the classowl:Ontology as its domain and range.
NOTE:owl:backwardCompatibleWith is an instance ofowl:OntologyProperty.
Anowl:incompatibleWithstatement contains a reference to another ontology. This indicates that thecontaining ontology is a later version of the referenced ontology, but is notbackward compatible with it. Essentially, this is for use by ontology authorswho want to be explicit that documents cannot upgrade to use the new versionwithout checking whether changes are required.
owl:incompatibleWith hasno meaning in the model theoretic semantics other than that given by theRDF(S) model theory.
owl:incompatibleWith is a built-in OWL property withthe classowl:Ontology as its domain and range.
NOTE:owl:backwardCompatibleWith is an instance ofowl:OntologyProperty.
Deprecation is a feature commonly used in versioning software (forexample, see the Java programming language) to indicate that aparticular feature is preserved for backward-compatibility purposes,but may be phased out in the future. Here, a specific identifier issaid to be of typeowl:DeprecatedClassorowl:DeprecatedProperty,whereowl:DeprecatedClass is a subclass ofrdfs:Class andowl:DeprecatedProperty is asubclass ofrdf:Property. By deprecating a term, itmeans that the term should not be used in new documents that commit tothe ontology. This allows an ontology to maintainbackward-compatibility while phasing out an old vocabulary (thus, itonly makes sense to use deprecation in combination with backwardcompatibility). As a result, it it easier for old data andapplications to migrate to a new version, and thus can increase thelevel of adoption of the new version. This has no meaning in themodel theoretic semantics other than that given by the RDF(S) modeltheory. However, authoring tools may use it to warn users whenchecking OWL markup.
An example of deprecation is:
<owl:Ontology rdf:about=""> <rdfs:comment>Vehicle Ontology, v. 1.1</rdfs:comment> <owl:backwardCompatibleWith rdf:resource="http://www.example.org/vehicle-1.0"/> <owl:priorVersion rdf:resource="http://www.example.org/vehicle-1.0"/></owl:Ontology><owl:DeprecatedClass rdf:ID="Car"> <rdfs:comment>Automobile is now preferred</rdfs:comment> <owl:equivalentClass rdf:resource="#Automobile"/> <!-- note that equivalentClass only means that the classes have the same extension, so this DOES NOT lead to the entailment that Automobile is of type DeprecatedClass too --> </owl:DeprecatedClass><owl:Class rdf:ID="Automobile" /><owl:DeprecatedProperty rdf:ID="hasDriver"> <rdfs:comment>inverse property drives is now preferred</rdfs:comment> <owl:inverseOf rdf:resource="#drives" /></owl:DeprecatedProperty><owl:ObjectProperty rdf:ID="drives" />
In the introduction we briefly discussed the three sublanguages of OWL. Inthis section an informative specification is given of the differences between thethree "species" of OWL. A formal account of the differences is given in theSemantics and Abstract Syntax document [OWL S&AS].
OWL Full is not actually a sublanguage. OWL Full contains all the OWLlanguage constructs and provides free, unconstrained use of RDF constructs. In OWL Full the resourceowl:Class is equivalent tordfs:Class. This is different from OWL DLand OWL Lite, whereowl:Class is a proper subclass ofrdfs:Class (meaning that not all RDF classes are OWLclasses in OWL DL and OWL Lite). OWL Full also allows classes to be treated as individuals. Forexample, it is perfectly legal in OWL Full to have a "Fokker-100" identifierwhich acts both as a class name (denoting the set of Fokker-100 airplanesflying around the world) and as an individual name (e.g.,an instance of theclassAirplaneType).
In OWL Full all data values are considered also to be part of the individualdomain. In fact, in OWL Full the universe of individuals consists of all resources (owl:Thing is equivalent tordfs:Resource).This means that object properties and datatype properties are notdisjoint. In OWL Fullowl:ObjectProperty is equivalent tordf:Property. The consequence isthat datatype properties are effectively a subclass of object properties. (Note: the fact thatowl:ObjectProperty andowl:DatatypeProperty are bothsubclasses ofrdf:Property is not inconsistent with this).
OWL Full will typically be useful for people who want to combine theexpressivity of OWL with the flexibility and metamodelling features of RDF. However, use of the OWL Full features means that one loses some guarantees (seebelow) that OWL DL and OWL Litecan provide for reasoning systems.
NOTE: RDF documents will generally be in OWL Full, unless they arespecifically constructed to be in OWL DL or Lite.
NOTE: Thus, in OWL Fullowl:Thing is equivalent tordfs:Resource,owl:Class is equivalent tordfs:Class, andowl:ObjectProperty is equivalent tordf:Property,
OWL DL is a sublanguage of OWL which places a number of constraints onthe use of the OWL language constructs. Briefly, these constraints are thefollowing:
- OWL DL requires a pairwise separation between classes, datatypes, datatype properties, object properties, annotation properties, ontology properties (i.e., the import and versioning stuff), individuals, data values and the built-in vocabulary. This means that, for example, a class cannot be at the same time an individual.
- In OWL DL the set of object properties and datatype properties are disjoint. This implies that the following four property characteristics: can never be specified fordatatype properties
- OWL DL requires that no cardinality constraints (local nor global) can be placed on transitive properties or their inverses or any of their superproperties.
- Annotations are allowed only under certain conditions. SeeSec. 7.1 for details.
- Most RDF(S) vocabulary cannot be used within OWL DL. See the OWL Semantics and Abstract Syntax document [OWL S&AS] for details.
- All axioms must be well-formed, with no missing or extra components, and must form a tree-like structure.
The last constraint implies that all classes and properties that one refers to are explicitly typed as OWL classes or properties, respectively. For example, if the ontology contains the following component:
<owl:Class rdf:ID="C1"> <rdfs:subClassOf rdf:resource="#C2" /> </owl:Class>
then the ontology (or an ontology imported into this ontology) should contain aowl:Class triple forC2.
- Axioms (facts) about individual equality and difference must be about named individuals.
These constraints of OWL DL may seem like an arbitrary set, but in factthey are not. The constraints are based on work in thearea of reasoners for Description Logic, which require these restrictions toprovide the ontology builder or user with reasoning support.In particular, the OWL DL restrictions allow the maximal subset of OWL Full against which current research can assure that a decidable reasoning procedure can exist for an OWL reasoner.
NOTE:Appendix E provides a set ofpractical guidelines for specifying OWL DL ontologies in RDF.
OWL Lite abides by all the restrictions OWL DL puts on the use of the OWLlanguage constructs. In addition, OWL Lite forbids the use of:
OWL Lite also requires that:
- the subject of
owl:equivalentClass triples be class names and the object ofowl:equivalentClass triples be class names or restrictions. - the subject of
rdfs:subClassOf triples be class names and the object ofrdfs:subClassOf triples be class names or restrictions; owl:intersectionOf be used only on lists of length greater than one that contain only class names and restrictions; NOTE: This is a prototypical example of legal use ofowl:intersectionOf in OWL Lite:
<owl:Class rdf:ID="Woman"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Female"/> <owl:Class rdf:about="#Human"/> </owl:intersectionOf> </owl:Class/>
- the object of
owl:allValuesFrom andowl:someValuesFrom triples be class names or datatype names; - the object of
rdf:type triples be class names or restrictions; - the object of
rdfs:domain triples be class names; and - the object of
rdfs:range triples be class names or datatype names.
The idea behind the OWL Lite expressivity limitations is that theyprovide a minimal useful subset of language features, that arerelatively straightforward for tool developers to support. Thelanguage constructs of OWL Lite provide the basics for subclasshierarchy construction: subclasses and propertyrestrictions. In addition, OWL Lite allows properties to be madeoptional or required. Thelimitations on OWL Lite place it in a lower complexity class than OWLDL. This can have a positive impact on the efficiency of completereasoners for OWL Lite.
Implementations that support only the OWL Lite vocabulary, but otherwise relax the restrictions of OWL DL, cannot make certain computational claims with respect to consistency and complexity. However, such implementations may be useful in providing interoperability of OWL systems with RDFS models, databases, markuptools, or other non-reasoning tools. The Web Ontology Working Group has not provided a name for thispotentially useful subset.
NOTE: This appendix only contains the OWL-specific constructs. For the RDF/RDFSconstructs see the relevant RDF documentation, in particular the RDF Schema document[RDF Vocabulary].
Appendix B. RDF Schema of OWL
SeeSec. 1.7 for a description of the purpose of this appendix. The RDF/XML version of this appendix can be found athttp://www.w3.org/2002/07/owl
<?xml version="1.0"?><!DOCTYPE rdf:RDF [ <!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 owl "http://www.w3.org/2002/07/owl#" > ]><rdf:RDF xmlns ="&owl;" xmlns:owl ="&owl;" xml:base ="http://www.w3.org/2002/07/owl" xmlns:rdf ="&rdf;" xmlns:rdfs="&rdfs;"><Ontology rdf:about=""> <imports rdf:resource="http://www.w3.org/2000/01/rdf-schema"/> <rdfs:isDefinedBy rdf:resource="http://www.w3.org/TR/2004/REC-owl-semantics-20040210/" /> <rdfs:isDefinedBy rdf:resource="http://www.w3.org/TR/2004/REC-owl-test-20040210/" /> <rdfs:isDefinedBy rdf:resource="http://www.w3.org/TR/2004/REC-owl-features-20040210/" /> <rdfs:comment>This file specifies in RDF Schema format the built-in classes and properties that together form the basis of the RDF/XML syntax of OWL Full, OWL DL and OWL Lite. We do not expect people to import this file explicitly into their ontology. People that do import this file should expect their ontology to be an OWL Full ontology. </rdfs:comment> <versionInfo>10 February 2004</versionInfo></Ontology><rdfs:Class rdf:ID="Class"> <rdfs:label>Class</rdfs:label> <rdfs:subClassOf rdf:resource="&rdfs;Class"/></rdfs:Class><Class rdf:ID="Thing"> <rdfs:label>Thing</rdfs:label> <unionOf rdf:parseType="Collection"> <Class rdf:about="#Nothing"/> <Class> <complementOf rdf:resource="#Nothing"/> </Class> </unionOf></Class><Class rdf:ID="Nothing"> <rdfs:label>Nothing</rdfs:label> <complementOf rdf:resource="#Thing"/></Class><rdf:Property rdf:ID="equivalentClass"> <rdfs:label>equivalentClass</rdfs:label> <rdfs:subPropertyOf rdf:resource="&rdfs;subClassOf"/> <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#Class"/></rdf:Property><rdf:Property rdf:ID="disjointWith"> <rdfs:label>disjointWith</rdfs:label> <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#Class"/></rdf:Property><rdf:Property rdf:ID="equivalentProperty"> <rdfs:label>equivalentProperty</rdfs:label> <rdfs:subPropertyOf rdf:resource="&rdfs;subPropertyOf"/></rdf:Property><rdf:Property rdf:ID="sameAs"> <rdfs:label>sameAs</rdfs:label> <rdfs:domain rdf:resource="#Thing"/> <rdfs:range rdf:resource="#Thing"/></rdf:Property><rdf:Property rdf:ID="differentFrom"> <rdfs:label>differentFrom</rdfs:label> <rdfs:domain rdf:resource="#Thing"/> <rdfs:range rdf:resource="#Thing"/></rdf:Property><rdfs:Class rdf:ID="AllDifferent"> <rdfs:label>AllDifferent</rdfs:label></rdfs:Class><rdf:Property rdf:ID="distinctMembers"> <rdfs:label>distinctMembers</rdfs:label> <rdfs:domain rdf:resource="#AllDifferent"/> <rdfs:range rdf:resource="&rdf;List"/></rdf:Property> <rdf:Property rdf:ID="unionOf"> <rdfs:label>unionOf</rdfs:label> <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="&rdf;List"/></rdf:Property><rdf:Property rdf:ID="intersectionOf"> <rdfs:label>intersectionOf</rdfs:label> <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="&rdf;List"/></rdf:Property><rdf:Property rdf:ID="complementOf"> <rdfs:label>complementOf</rdfs:label> <rdfs:domain rdf:resource="#Class"/> <rdfs:range rdf:resource="#Class"/></rdf:Property><rdf:Property rdf:ID="oneOf"> <rdfs:label>oneOf</rdfs:label> <rdfs:domain rdf:resource="&rdfs;Class"/> <rdfs:range rdf:resource="&rdf;List"/></rdf:Property><rdfs:Class rdf:ID="Restriction"> <rdfs:label>Restriction</rdfs:label> <rdfs:subClassOf rdf:resource="#Class"/></rdfs:Class><rdf:Property rdf:ID="onProperty"> <rdfs:label>onProperty</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="&rdf;Property"/></rdf:Property><rdf:Property rdf:ID="allValuesFrom"> <rdfs:label>allValuesFrom</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="&rdfs;Class"/></rdf:Property><rdf:Property rdf:ID="hasValue"> <rdfs:label>hasValue</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/></rdf:Property><rdf:Property rdf:ID="someValuesFrom"> <rdfs:label>someValuesFrom</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="&rdfs;Class"/></rdf:Property><rdf:Property rdf:ID="minCardinality"> <rdfs:label>minCardinality</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/></rdf:Property><rdf:Property rdf:ID="maxCardinality"> <rdfs:label>maxCardinality</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/></rdf:Property><rdf:Property rdf:ID="cardinality"> <rdfs:label>cardinality</rdfs:label> <rdfs:domain rdf:resource="#Restriction"/> <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/></rdf:Property><rdfs:Class rdf:ID="ObjectProperty"> <rdfs:label>ObjectProperty</rdfs:label> <rdfs:subClassOf rdf:resource="&rdf;Property"/></rdfs:Class><rdfs:Class rdf:ID="DatatypeProperty"> <rdfs:label>DatatypeProperty</rdfs:label> <rdfs:subClassOf rdf:resource="&rdf;Property"/></rdfs:Class><rdf:Property rdf:ID="inverseOf"> <rdfs:label>inverseOf</rdfs:label> <rdfs:domain rdf:resource="#ObjectProperty"/> <rdfs:range rdf:resource="#ObjectProperty"/></rdf:Property><rdfs:Class rdf:ID="TransitiveProperty"> <rdfs:label>TransitiveProperty</rdfs:label> <rdfs:subClassOf rdf:resource="#ObjectProperty"/></rdfs:Class><rdfs:Class rdf:ID="SymmetricProperty"> <rdfs:label>SymmetricProperty</rdfs:label> <rdfs:subClassOf rdf:resource="#ObjectProperty"/></rdfs:Class><rdfs:Class rdf:ID="FunctionalProperty"> <rdfs:label>FunctionalProperty</rdfs:label> <rdfs:subClassOf rdf:resource="&rdf;Property"/></rdfs:Class><rdfs:Class rdf:ID="InverseFunctionalProperty"> <rdfs:label>InverseFunctionalProperty</rdfs:label> <rdfs:subClassOf rdf:resource="&owl;ObjectProperty"/></rdfs:Class><rdfs:Class rdf:ID="AnnotationProperty"> <rdfs:subClassOf rdf:resource="&rdf;Property"/></rdfs:Class><AnnotationProperty rdf:about="&rdfs;label"/><AnnotationProperty rdf:about="&rdfs;comment"/><AnnotationProperty rdf:about="&rdfs;seeAlso"/><AnnotationProperty rdf:about="&rdfs;isDefinedBy"/><rdfs:Class rdf:ID="Ontology"> <rdfs:label>Ontology</rdfs:label></rdfs:Class><rdfs:Class rdf:ID="OntologyProperty"> <rdfs:subClassOf rdf:resource="&rdf;Property"/></rdfs:Class><rdf:Property rdf:ID="imports"> <rdfs:label>imports</rdfs:label> <rdf:type rdf:resource="#OntologyProperty"/> <rdfs:domain rdf:resource="#Ontology"/> <rdfs:range rdf:resource="#Ontology"/></rdf:Property><rdf:Property rdf:ID="versionInfo"> <rdfs:label>versionInfo</rdfs:label> <rdf:type rdf:resource="#AnnotationProperty"/></rdf:Property><rdf:Property rdf:ID="priorVersion"> <rdfs:label>priorVersion</rdfs:label> <rdf:type rdf:resource="#OntologyProperty"/> <rdfs:domain rdf:resource="#Ontology"/> <rdfs:range rdf:resource="#Ontology"/></rdf:Property><rdf:Property rdf:ID="backwardCompatibleWith"> <rdfs:label>backwardCompatibleWitesh</rdfs:label> <rdf:type rdf:resource="#OntologyProperty"/> <rdfs:domain rdf:resource="#Ontology"/> <rdfs:range rdf:resource="#Ontology"/></rdf:Property><rdf:Property rdf:ID="incompatibleWith"> <rdfs:label>incompatibleWith</rdfs:label> <rdf:type rdf:resource="#OntologyProperty"/> <rdfs:domain rdf:resource="#Ontology"/> <rdfs:range rdf:resource="#Ontology"/></rdf:Property><rdfs:Class rdf:ID="DeprecatedClass"> <rdfs:label>DeprecatedClass</rdfs:label> <rdfs:subClassOf rdf:resource="&rdfs;Class"/></rdfs:Class><rdfs:Class rdf:ID="DeprecatedProperty"> <rdfs:label>DeprecatedProperty</rdfs:label> <rdfs:subClassOf rdf:resource="&rdf;Property"/></rdfs:Class><rdfs:Class rdf:ID="DataRange"> <rdfs:label>DataRange</rdfs:label></rdfs:Class></rdf:RDF>
Appendix C.OWL Quick Reference
Classes in the OWL vocabulary:
Properties in the OWL vocabulary:
Appendix D. Changes from DAML+OIL
This section summarizes the changes fromDAML+OIL[DAML+OIL]to OWL.
- The semantics have changed significantly. With respect to the threesublanguages, the DAML+OIL semantics are closest to the OWL DL semantics.
- The namespace was changed tohttp://www.w3.org/2002/07/owl.
- Various updates to RDF and RDF Schema from theRDF Core Working Group were incorporated, including
- cyclic subclasses are now allowed
- multiple
rdfs:domainandrdfs:rangeproperties are handled as intersection - RDF Semantics [RDF Semantics]
- datatypes
- the
daml:List construct used to represent closed collections was largely incorporated into RDF
- Qualified restrictions were removed from the language,resulting in the removal of the following properties:
daml:cardinalityQdaml:hasClassQdaml:maxCardinalityQdaml:minCardinalityQ
- Various properties and classes were renamed,as shown in the following table:
owl:SymmetricPropertywas added.- Also added were
owl:AnnotationProperty,owl:OntologyProperty andowl:DataRange. - An
owl:DatatypePropertymay be anowl:InverseFunctionalPropertyin OWL Full. - Synonyms for RDF and RDF Schema classes and properties were removed from the language,resulting in the removal of:
daml:commentdaml:domaindaml:labeldaml:isDefinedBydaml:Literaldaml:Propertydaml:rangedaml:seeAlsodaml:subClassOfdaml:subPropertyOfdaml:typedaml:value
daml:disjointUnionOf was removed from the language, since it can be effected usingowl:unionOf orrdfs:subClassOf andowl:disjointWith.daml:equivalentTo was renamed toowl:sameAs, and is no longer a superproperty ofowl:equivalentClass andowl:equivalentProperty,- The following properties and classes were added to support versioning:
- owl:AllDifferent andowl:distinctMembers were added to address the Unique Names Assumption.
Appendix E. Rules of Thumb for OWL DL ontologies
The OWL Abstract Syntax and Semantics document[OWL S&AS]provides a characterization of OWL ontologies in terms of an abstractsyntax, along with a mapping to RDF triples.
The following rules give an informal characterization of theconditions for an RDF graph to be a DL ontology. This is not intendedto replace the characterization given in S&AS, but instead givessome general pointers — the idea is that if you stick to theseguidelines, you're more likely to produce OWL DL ontologies. Nor isthis intended to tell you how to turn the triple representation intosomething closer to the abstract syntax.
Don't mess with the vocabulary
The built-in properties and classes shouldnot beredefined. In general this means that things in the OWL, RDF or RDFSnamespaces should not appear as subjects of triples.
Provide Explicit Typing
Everything should have a type1. If anyURI referencex is used where a class is expected, thegraph should contain a triple stating that
x rdf:type owl:Class
Similarly, if a propertyp is used where an objectproperty is expected then there should be a triple2
p rdf:type owl:ObjectProperty
If a propertyq is used where a data property isexpected then there should be a triple
q rdf:type owl:DatatypeProperty
If a propertyo is used where an ontology property isexpected then it should either be one of the built in ontology properties(owl:imports,owl:priorVersion,owl:backwardCompatibleWith, andowl:incompatibleWith) or there should be a triple:
o rdf:type owl:OntologyProperty
If a propertya is used where an annotation propertyis expected then it should either be one of the built in annotationproperties (owl:versionInfo,rdfs:label,rdfs:comment,rdfs:seeAlso, andrdfs:isDefinedBy) or there should be a triple:
a rdf:type owl:AnnotationProperty
Any individuals that occur in the ontology should have at least onetype specified, i.e. for an individuali, there must bea triple:
i rdf:type c
wherec is anowl:Class orowl:Restriction.
Keep names separate
URI references for classes, properties (object, datatype, ontologyand annotation) and individuals should be disjoint. Thus we cannothave things like:
x rdf:type owl:Classx rdf:type owl:ObjectProperty
In particular, this means that we cannot useclasses asinstances, i.e.
x rdf:type owl:Classy rdf:type owl:Classx rdf:type y
is not valid OWL DL. A general rule here is that if there is a nodex in the graph with a triple:
x rdf:type owl:Class
thenx should not appear as the subject of any othertriple with predicaterdf:type.3
Restrictions
If a nodex hasrdf:typeowl:Restriction then the following should be the case:
- It is a blank node (i.e. unnamed).
- It is not the subject of any other triple with predicate
rdf:type3. - It is the subject of exactlyone triple with predicate
owl:onProperty, with the object of that triple being anowl:ObjectProperty orowl:DatatypeProperty. - It is the subject of exactlyone of:
- A triple with predicate
owl:someValuesFrom. In this case, the type of the property which is the object of theowl:onProperty triple should be appropriate. By this we mean that if the object of this triple is a datatype, the property should be anowl:DatatypeProperty. If the object is a class description, the property should be anowl:ObjectProperty. This typing information should be present (due to the restrictions outlinedabove). - A triple with predicate
owl:allValuesFrom. Similar restrictions hold as forowl:someValuesFrom - A triple with predicate
owl:hasValue. If the type of the property involved in theowl:onProperty triple isowl:ObjectProperty then the object of this triple should be an individual. If the type of the property involved in theowl:onProperty triple isowl:DatatypeProperty the the object of this triple should be a data literal. - A triple with predicate
owl:minCardinality. The object of this triple should be a data literal representing a non negative integer. - A triple with predicate
owl:maxCardinality. Restriction as forowl:minCardinality. - A triple with predicate
owl:cardinality. Restriction as forowl:minCardinality.
- Any other triples in which
x is the subject shouldhave predicateowl:equivalentClass orowl:disjointWith.
Class axioms
For any triples with predicaterdfs:subClassOf orowl:equivalentClass orowl:disjointWith,both the subject and object of the triples should be anowl:Class orowl:Restriction, i.e. if wehave:
x rdfs:subClassOf y
then the graph must contain one of:
x rdf:type owl:Class
or
x rdf:type owl:Restriction.
and one of
y rdf:type owl:Class
or
y rdf:type owl:Restriction.
Property axioms
For any triples with predicaterdfs:subPropertyOf orowl:equivalentProperty, both the subject and object of thetriples should have the same type which should be one ofowl:ObjectProperty orowl:DatatypeProperty,i.e. if we have:
p owl:equivalentProperty q
then the graph must contain either:
p rdf:type owl:ObjectPropertyq rdf:type owl:ObjectProperty.
or
p rdf:type owl:DatatypePropertyq rdf:type owl:DatatypeProperty.
Triples with predicaterdfs:domain should have as theirsubject anowl:ObjectProperty orowl:DatatypeProperty and as their object anowl:Class orowl:Restriction.
Triples with predicaterdfs:range should have as their subjecteither anowl:ObjectProperty or anowl:DatatypeProperty. In the case of the former, theobject of the triple should then be anowl:Class orowl:Restriction, in the case of the latter, the objectshould be either an XML Schema datatype,rdfs:Literal, or anowl:oneOfspecifying a data range with typeowl:DataRange.
Both the subject and object of anowl:inverseOf triplemust have typeowl:ObjectProperty.
Individual axioms
For any triples with predicateowl:sameAs orowl:differentFrom, the subject and object must be individuals.
Note that relating two classes viaowl:sameAs is a very different thing torelating them viaowl:equivalentClass. The former saysthat the two objects are in fact the same, is actually an example ofclass as instance, and thus pushes the ontology out of OWLDL. The latter is an assertion that the extension (e.g. the collectionof members) of the classes is equivalent.
Similarly, relating classes viaowl:differentFrom is notthe same as relating them viaowl:disjointWith (and isagain an example of an OWL Full construct). Two classes may bedifferent objects but still share the same extension.
Ifa nodex hasrdf:typeowl:AllDifferent, then the following should be thecase:
- It is a blank node (i.e. unnamed).
- It is the subject of a triple with predicate
owl:distinctMembers, the object of which should be a(well-formed)rdf:List, all of whose elements areindividuals. - It is not the subject (or object) of any other triples.
Boolean class expressions
Boolean Operators (and, or, not) are represented in OWL usingowl:intersectionOf,owl:unionOf andowl:complementOf.
The subject of anowl:complementOf triple must be anowl:Class, the object must be either anowl:Class orowl:Restriction.
The subject of anowl:unionOforowl:intersectionOf triple must be anowl:Class, the object must be a (well-formed)rdf:List, all of whose elements are eitherowl:Class orowl:Restriction. These could either be representedexplicitly using expandedrdf:Lists, or if RDF-XML isbeing used, anrdf:parseType="Collection" attribute.
<owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="x"/> <owl:Class rdf:about="y"/> </owl:intersectionOf></owl:Class>
If theowl:Class is a blank node (i.e. the class isunnamed), then it can only be the subject of at most one triple withpredicateowl:intersectionOf,owl:unionOf orowl:complementOf. If theclass is named, any number of such triples are allowed.
Enumerations
The subject of any triple with predicateowl:oneOf must beeither anowl:Class or anowl:DataRange. Inthe case of the former, the object must be a (well-formed)rdf:List, all of whose elements are individuals. In the case of the latter, the object must be a(well-formed)rdf:List, all of whose elements are dataliterals. Again, as with the boolean operators,rdf:parseType="Collection" can be used.
Ontology and Annotation Properties
The subject and object of any triple with an ontology predicateshould be an ontology, e.g. a nodex such that there is atriple:
x rdf:type owl:Ontology
The subject of any triple with an annotation predicate should be anamed (i.e. non-bnode) class, a property, an individual or anontology. The object of a triple with an annotation predicate shouldbe an individual, a data literal or an arbitrary URI reference.
With the exception of predicates within the OWL, RDF and RDFSvocabularies, annotation properties are theonlypredicates that should appear in triples with a class or property as thesubject.
Annotation and ontology properties themselves should betyped, and should not appear as thesubject or object of triples other than as the subject of a triplewith predicaterdf:type or an annotation property.
Avoid structure sharing
In general, the S&AS description of OWL does not permitstructure sharing in the RDF representation. This effectivelymeans that an anonymous node in the RDF graph representing aparticular description should only occur once (as the object of atriple). Thus things like:
x1 rdf:type owl:Classx1 rdfs:subClassOf _:yx2 rdf:type owl:Classx2 rdfs:subClassOf _:y_:y rdf:type owl:Class_:y owl:complementOf z
should be avoided. There are some tricky corner cases where thisis permitted. In general, however, graphs should use distinctblank nodes whenever a class description is used in more than one place.
Avoid orphan blank nodes
In general, blank nodes occurring in the graph either represent unnamedindividuals, or should be exactlyone of the following:
- The object of an
rdfs:subClassOf,owl:equivalentClass,owl:disjointWith,owl:someValuesFrom,owl:allValuesFrom orrdf:type triple. - The subject of an
rdf:type triple with objectowl:AllDifferent. - An element in an
rdf:List.
Orphan blank nodes, i.e. those which are not the object of a triple are,in general, not allowed (other than theowl:AllDifferentcase described above).
Ground facts
Ontologies may contain assertions of ground facts (e.g. triplesthat assert the properties of individuals). The properties used inthese assertions must be anowl:ObjectProperty orowl:DatatypeProperty. The subject of any such triple mustbe an individual (which should betyped). The object can either be a referenceto an individual (if the property is anowl:ObjectProperty) or a data literal (if the property isanowl:DatatypeProperty).
OWL Lite
OWL Lite documents should follow the same rules as OWL DLdocuments, with a number of extra restrictions, primarily concerningthe vocabulary allowed. An OWL Lite document shouldnot use any of the following vocabulary:
owl:unionOfowl:complementOfowl:oneOfowl:hasValueowl:disjointWith
Any objects which are the object or subject of a triple withpredicateowl:equivalentClass should not be b-nodes.
The object of any triples with predicateowl:minCardinality,owl:maxCardinality orowl:cardinality should be a data literal representing theinteger 0 or 1.
The situation regarding the use ofowl:intersectionOfin OWL Lite is a little more complex. The predicate shouldnot be used to form arbitrary expressions, butisneeded in order to represent complete class definitions. Therestrictions above tell us that the subject of any triple with predicateowl:intersectionOf should be aowl:Class. InOWL Lite, we have the further restriction that this class should benamed, i.e. the subject should not be a bnode.
Miscellaneous
Be careful of the use ofowl:Thing. For example, thefollowing OWL-RDF fragment:
<owl:Class rdf:about="#A"> <rdfs:subClassOf> <owl:Thing/> </rdfs:subClassOf></owl:Class>
doesnot describe a classA that is asubclass ofowl:Thing, but in fact describes a classA that is a subclass of some anonymous instance ofowl:Thing. This is thus a use of class as instance and isoutside OWL DL. The desired effect of a subclass ofowl:Thing is obtained through:
<owl:Class rdf:about="#A"> <rdfs:subClassOf> <owl:Class rdf:about="http://www.w3.org/2002/07/owl#Thing"/> </rdfs:subClassOf></owl:Class>
Be careful not to confuseowl:Class andrdfs:Class. The following isnot in DLdue to the fact thatc is not given an appropriatetype.
c rdf:type rdfs:Class
Notes
[1] Of course the necessity to type everything doesnot apply to things from the OWL, RDF or RDFS namespaces.
[2] Strictly speaking, if the property is defined asbeing anowl:TransitiveProperty,owl:SymmetricProperty orowl:InverseFunctionalProperty then this is notnecessary.
[3] An exception here is that we can have:
x rdf:type rdfs:Classx rdf:type owl:Class
p rdf:type rdf:Propertyp rdf:type owl:ObjectProperty
or
q rdf:type rdf:Propertyq rdf:type owl:DatatypeProperty
In addition, for restrictions, we can have:
x rdf:type owl:Restrictionx rdf:type rdfs:Classx rdf:type owl:Class
Appendix F.Change Log since PR
- Removed spurious endnote [4] in Appendix E.
- Added rdfs:label element to AnnotationProperty and OntologyProperty in AppendixB (RDF Schema of OWL) after comment fromJacco van Ossenbruggen.
- Fixed broken section reference plus corrected section reference style.
- Standardized reference section.
- Editorial revision of requirement description for rdf:RDF element after comment fromMinsu Jang.
- Several editorial changes in response to a review byLacy.
- Added explanatory text to Sec. 7.1 about OWL DL constraints on the use of annotation properties, after some public comments (for example, see the comments byBenjamin Nowack. Added also a sentence to Sec. 7.2to indicate that the same constraints hold for ontology properties.
- Several small editorial corrections after final read-though by editor.
- [OWL Overview]
- OWL Web Ontology Language Overview, Deborah L. McGuinness and Frank van Harmelen, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/ .Latest version available at http://www.w3.org/TR/owl-features/ .
- [OWL Guide]
- OWL Web Ontology Language Guide, Michael K. Smith, Chris Welty, and Deborah L. McGuinness, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-guide-20040210/ .Latest version available at http://www.w3.org/TR/owl-guide/ .
- [OWL Semantics and Abstract Syntax]
- OWL Web Ontology Language Semantics and Abstract Syntax, Peter F. Patel-Schneider, Patrick Hayes, and Ian Horrocks, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/ .Latest version available at http://www.w3.org/TR/owl-semantics/ .
- [OWL Test]
- OWL Web Ontology Language Test Cases, Jeremy J. Carroll and Jos De Roo, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-owl-test-20040210/ .Latest version available at http://www.w3.org/TR/owl-test/ .
- [OWL Requirements]
- OWL Web Ontology Language Use Cases and Requirements, Jeff Heflin, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-webont-req-20040210/ .Latest version available at http://www.w3.org/TR/webont-req/ .
- [RDF Concepts]
- Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ .Latest version available at http://www.w3.org/TR/rdf-concepts/ .
- [RDF Syntax]
- RDF/XML Syntax Specification (Revised), Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ .Latest version available at http://www.w3.org/TR/rdf-syntax-grammar/ .
- [RDF Semantics]
- RDF Semantics, Pat Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ .Latest version available at http://www.w3.org/TR/rdf-mt/ .
- [RDF Vocabulary]
- RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R. V. Guha, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ .Latest version available at http://www.w3.org/TR/rdf-schema/ .
- [DAML+OIL]
- DAML+OIL (March 2001) Reference Description.Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah L. McGuinness, Peter F. Patel-Schneider, and Lynn Andrea Stein.W3C Note 18 December 2001.Latest versionis available at
http://www.w3.org/TR/daml+oil-reference. - [XML-SCHEMA2]
- XML SchemaPart 2: Datatypes - W3C Recommendation, World Wide WebConsortium, 2 May 2001.
[8]ページ先頭