OWL指南 推薦標準-3
TransWiki - W3CHINA.ORG开放翻译计划（OTP）
摘要_文檔狀態_目錄 第1節 第2節 第3節 第4節 第5節 第6節 第7節 鳴謝_辭彙表_術語索引_參考文獻 附錄
3. Basic Elements
Most of the elements of an OWL ontology concern classes, properties, instances of classes, and relationships between these instances. This section presents the language components essential to introducing these elements.
3.1. Simple Classes and Individuals
Many uses of an ontology will depend on the ability to reason about individuals. In order to do this in a useful fashion we need to have a mechanism to describe the classes that individuals belong to and the properties that they inherit by virtue of class membership. We can always assert specific properties about individuals, but much of the power of ontologies comes from class-based reasoning.
Sometimes we want to emphasize the distinction between a class as an object and a class as a set containing elements. We call the set of individuals that are members of a class the extension of the class.
3.1.1. Simple Named Classes Class, rdfs:subClassOf
The most basic concepts in a domain should correspond to classes that are the roots of various taxonomic trees. Every individual in the OWL world is a member of the class owl:Thing. Thus each user-defined class is implicitly a subclass of owl:Thing. Domain specific root classes are defined by simply declaring a named class. OWL also defines the empty class, owl:Nothing.
For our sample wines domain, we create three root classes: Winery, Region, and ConsumableThing.
<owl:Class rdf:ID="Winery"/>
<owl:Class rdf:ID="Region"/>
<owl:Class rdf:ID="ConsumableThing"/>
Note that we have only said that there exist classes that have been given these names, indicated by the 'rdf:ID=' syntax. Formally, we know almost nothing about these classes other than their existence, despite the use of familiar English terms as labels. And while the classes exist, they may have no members. For all we know at the moment, these classes might as well have been called Thing1, Thing2, and Thing3.
It is important to remember that definitions may be incremental and distributed. In particular, we will have more to say about Winery later.
The syntax rdf:ID="Region" is used to introduce a name, as part of its definition. This is the rdf:ID attribute (http://www.w3.org/TR/rdf-syntax-grammar/#idAttr) ([RDF (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#RDF1)], 7.2.22) that is like the familiar ID attribute defined by XML. Within this document, the Region class can now be referred to using #Region, e.g. rdf:resource="#Region". Other ontologies may reference this name using its complete form, "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Region".
Another form of reference uses the syntax rdf:about="#Region" to extend the definition of a resource. This use of the rdf:about="&ont;#x" syntax is a critical element in the creation of a distributed ontology. It permits the extension of the imported definition of x without modifying the original document and supports the incremental construction of a larger ontology.
It is now possible to refer to the classes we defined in other OWL constructs using their given identifier. For the first class, within this document, we can use the relative identifier, #Winery. Other documents may need to reference this class as well. The most reasonable way to do so is to provide namespace and entity definitions that include the defining document as a source:
...
<!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
<!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" >
...
<rdf:RDF xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" ... >
...
Given these definitions we can refer to the winery class either using the XML tag vin:Winery or the attribute value &vin;Winery. More literally, it is always possible to reference a resource using its full URI, here http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Winery.
The fundamental taxonomic constructor for classes is rdfs:subClassOf. It relates a more specific class to a more general class. If X is a subclass of Y, then every instance of X is also an instance of Y. The rdfs:subClassOf relation is transitive. If X is a subclass of Y and Y a subclass of Z then X is a subclass of Z.
<owl:Class rdf:ID="PotableLiquid">
<rdfs:subClassOf rdf:resource="#ConsumableThing" />
...
</owl:Class>
We define PotableLiquid (liquids suitable for drinking) to be a subclass of ConsumableThing.
In the world of Web-based ontologies, both of these classes can be defined in a separate ontology that would provide the basic building blocks for a wide variety of food and drink ontologies, which is what we have done - they are defined in the food (http://www.w3.org/TR/2004/REC-owl-guide-20040210/food.rdf) ontology, which is imported (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#import) into the wine ontology. The food ontology includes a number of classes, for example Food, EdibleThing, MealCourse, and Shellfish, that do not belong in a collection of wine facts, but must be connected to the wine vocabulary if we are going to perform useful reasoning. Food and wine are mutually dependent, in order to satisfy our need to identify wine/food matches.
A class definition has two parts: a name introduction or reference and a list of restrictions. Each of the immediate contained expressions in the class definition further restricts the instances of the defined class. Instances of the class belong to the intersection of the restrictions. (Though see the details of owl:equivalentClass.) So far we have only seen examples that include a single restriction, forcing the new class to be a subclass of some other named class.
At this point it is possible to create a simple (and incomplete) definition for the class Wine. Wine is a PotableLiquid. We also define Pasta as an EdibleThing.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
<rdfs:label xml:lang="en">wine</rdfs:label>
<rdfs:label xml:lang="fr">vin</rdfs:label>
...
</owl:Class>
<owl:Class rdf:ID="Pasta">
<rdfs:subClassOf rdf:resource="#EdibleThing" />
...
</owl:Class>
The rdfs:label entry provides an optional human readable name for this class. Presentation tools can make use of it. The "lang" attribute provides support for multiple languages. A label is like a comment and contributes nothing to the logical interpretation of an ontology.
Our wine definition is still very incomplete. We know nothing about wines except that they are things and potable liquids, but we have sufficient information to create and reason about individuals.
3.1.2. Individuals
In addition to classes, we want to be able to describe their members. We normally think of these as individuals in our universe of things. An individual is minimally introduced by declaring it to be a member of a class.
<Region rdf:ID="CentralCoastRegion" />
Note that the following is identical in meaning to the example above.
<owl:Thing rdf:ID="CentralCoastRegion" />
<owl:Thing rdf:about="#CentralCoastRegion">
<rdf:type rdf:resource="#Region"/>
</owl:Thing>
rdf:type is an RDF property that ties an individual to a class of which it is a member.
There are a couple of points to be made here. First, we have decided that CentralCoastRegion (a specific area) is member of Region, the class containing all geographical regions. Second, there is no requirement in the two-part example that the two elements need to be adjacent to one another, or even in the same file (though the names would need to be extended with a URI in such a case). We design Web ontologies to be distributed. They can be imported and augmented, creating derived ontologies.
In order to have available a few more classes for the properties introduced in the next sections, we define a branch of the Grape taxonomy, with an individual denoting the Cabernet Sauvignon grape varietal. Grapes are defined in the food ontology:
<owl:Class rdf:ID="Grape">
...
</owl:Class>
And then in the wine ontology we have:
<owl:Class rdf:ID="WineGrape">
<rdfs:subClassOf rdf:resource="&food;Grape" />
</owl:Class>
<WineGrape rdf:ID="CabernetSauvignonGrape" />
As discussed in the next section, CabernetSauvignonGrape is an individual because it denotes a single grape varietal.
3.1.3. Design for Use
There are important issues regarding the distinction between a class and an individual in OWL. A class is simply a name and collection of properties that describe a set of individuals. Individuals are the members of those sets. Thus classes should correspond to naturally occurring sets of things in a domain of discourse, and individuals should correspond to actual entities that can be grouped into these classes.
In building ontologies, this distinction is frequently blurred in two ways:
- Levels of representation: In certain contexts something that is obviously a class can itself be considered an instance of something else. For example, in the wine ontology we have the notion of a Grape, which is intended to denote the set of all grape varietals. CabernetSauvingonGrape is an example instance of this class, as it denotes the actual grape varietal called Cabernet Sauvignon. However, CabernetSauvignonGrape could itself be considered a class, the set of all actual Cabernet Sauvignon grapes.
- Subclass vs. instance: It is very easy to confuse the instance-of relationship with the subclass relationship. For example, it may seem arbitrary to choose to make CabernetSauvignonGrape an individual that is an instance of Grape, as opposed to a subclass of Grape. This is not an arbitrary decision. The Grape class denotes the set of all grape varietals, and therefore any subclass of Grape should denote a subset of these varietals. Thus, CabernetSauvignonGrape should be considered an instance of Grape, and not a subclass. It does not describe a subset of Grape varietals, it is a grape varietal.
Note that the same distinction arises with the treatment of the Wine class. The Wine class actually denotes the set of all varieties of wine, not the set of actual bottles that someone may purchase. In an alternate ontology, each instance of Wine in the current ontology could instead designate a class consisting of all the bottles of wine of that type. It is easy to imagine an information system, such as an inventory system for a wine merchant, that needs to consider individual bottles of wine. The wine ontology as it currently exists would require the ability to treat classes as instances in order to support such an interpretation. Note that OWL Full permits such expressivity, allowing us to treat an instance of a wine variety simultaneously as a class whose instances are bottles of wine.
In a similar vein, the wines produced by wineries in specific years are considered vintages. In order to represent the notion of a vintage, we must determine where it fits in the current ontology. An instance of the Wine class, as discussed above, represents a single variety of wine produced by a single winery, for example FormanChardonnay.
Adding that the wine produced in the year 2000 is considered a vintage poses a challenge, because we don't have the ability to represent a subset of a given wine individual. This vintage is not a new variety of wine, it is a special subset of the wine - that produced in the year 2000. An option would be to use OWL Full and treat the wine instances as classes with subclasses (subsets) denoting vintages. Another option is to use a workaround and to consider Vintage as a separate class whose instances have a relationship to the Wine they are a vintage of. For example, FormanChardonnay2000 is an individual Vintage with a vintageOf property whose value is the Wine, FormanChardonnay. We define the Vintage class below.
The point of this discussion is to note that the development of an ontology should be firmly driven by the intended usage. These issues also underlie one major difference between OWL Full and OWL DL. OWL Full allows the use of classes as instances and OWL DL does not. The wine ontology is designed to work in OWL DL, and as a result individuals like FormanChardonnay are not simultaneously treated as classes.
3.2. Simple Properties
This world of classes and individuals would be pretty uninteresting if we could only define taxonomies. Properties let us assert general facts about the members of classes and specific facts about individuals.
3.2.1. Defining Properties ObjectProperty, DatatypeProperty, rdfs:subPropertyOf, rdfs:domain, rdfs:range
A property is a binary relation. Two types of properties are distinguished:
- datatype properties, relations between instances of classes and RDF literals and XML Schema datatypes
- object properties, relations between instances of two classes. Note that the name object property is not intended to reflect a connection with the RDF (http://www.w3.org/RDF/) term rdf:object (http://www.w3.org/TR/rdf-schema/#ch_object) ([RDF (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#RDF1)], 5.3.4).
When we define a property there are a number of ways to restrict the relation. The domain and range can be specified. The property can be defined to be a specialization (subproperty) of an existing property. More elaborate restrictions are possible and are described later (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#PropertyCharacteristics).
<owl:ObjectProperty rdf:ID="madeFromGrape">
<rdfs:domain rdf:resource="#Wine"/>
<rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="course">
<rdfs:domain rdf:resource="#Meal" />
<rdfs:range rdf:resource="#MealCourse" />
</owl:ObjectProperty>
In OWL, a sequence of elements without an explicit operator represents an implicit conjunction. The property madeFromGrape has a domain of Wine and a range of WineGrape. That is, it relates instances of the class Wine to instances of the class WineGrape. Multiple domains mean that the domain of the property is the intersection of the identified classes (and similarly for range).
Similarly, the property course ties a Meal to a MealCourse.
Note that the use of range and domain information in OWL is different from type information in a programming language. Among other things, types are used to check consistency in a programming language. In OWL, a range may be used to infer a type. For example, given:
<owl:Thing rdf:ID="LindemansBin65Chardonnay">
<madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing> ?
we can infer that LindemansBin65Chardonnay is a wine because the domain of madeFromGrape is Wine.
Properties, like classes, can be arranged in a hierarchy.
<owl:Class rdf:ID="WineDescriptor" />
<owl:Class rdf:ID="WineColor">
<rdfs:subClassOf rdf:resource="#WineDescriptor" />
...
</owl:Class>
<owl:ObjectProperty rdf:ID="hasWineDescriptor">
<rdfs:domain rdf:resource="#Wine" />
<rdfs:range rdf:resource="#WineDescriptor" />
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasColor">
<rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />
<rdfs:range rdf:resource="#WineColor" />
...
</owl:ObjectProperty>
WineDescriptor properties relate wines to their color and components of their taste, including sweetness, body, and flavor. hasColor is a subproperty of the hasWineDescriptor property, with its range further restricted to WineColor. The rdfs:subPropertyOf relation in this case means that anything with a hasColor property with value X also has a hasWineDescriptor property with value X.
Next we introduce the locatedIn property, which relates things to the regions they are located in.
<owl:ObjectProperty rdf:ID="locatedIn">
...
<rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
Notice how the domain and range of locatedIn are defined. The domain permits anything to be located in a region, including regions themselves. And the transitive (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#owl_TransitiveProperty) composition of this relation essentially creates a network of geographically included subregions and things. Those things that have nothing located in them can be of any class, while those that contain others must be regions.
It is now possible to expand the definition of Wine to include the notion that a wine is made from at least one WineGrape. As with property definitions, class definitions have multiple subparts that are implicitly conjoined.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#madeFromGrape"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class>
The highlighted subclass restriction above
<owl:Restriction>
<owl:onProperty rdf:resource="#madeFromGrape"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
defines an unnamed class that represents the set of things with at least one madeFromGrape property. We call these anonymous classes. Including this restriction in the Wine class definition body states that things that are wines are also members of this anonymous class. That is, every individual wine must participate in at least one madeFromGrape relation.
We can now describe the class of Vintages, discussed previously (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#vintageIntro).
<owl:Class rdf:ID="Vintage">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#vintageOf"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class> ?
The property vintageOf ties a Vintage to a Wine.
<owl:ObjectProperty rdf:ID="vintageOf">
<rdfs:domain rdf:resource="#Vintage" />
<rdfs:range rdf:resource="#Wine" />
</owl:ObjectProperty> ?
We relate Vintages to their years in the next section.
3.2.2. Properties and Datatypes
We distinguish properties according to whether they relate individuals to individuals (object properties) or individuals to datatypes (datatype properties). Datatype properties may range over RDF literals or simple types defined in accordance with XML Schema datatypes (http://www.w3.org/TR/xmlschema-2/).
OWL uses most of the built-in XML Schema datatypes. References to these datatypes are by means of the URI reference for the datatype, http://www.w3.org/2001/XMLSchema. The following datatypes are recommended for use with OWL:
xsd:stringxsd:normalizedStringxsd:boolean
xsd:decimalxsd:floatxsd:double
xsd:integerxsd:nonNegativeIntegerxsd:positiveInteger
xsd:nonPositiveIntegerxsd:negativeInteger
xsd:longxsd:intxsd:shortxsd:byte
xsd:unsignedLongxsd:unsignedIntxsd:unsignedShortxsd:unsignedByte
xsd:hexBinaryxsd:base64Binary
xsd:dateTimexsd:timexsd:datexsd:gYearMonth
xsd:gYearxsd:gMonthDayxsd:gDayxsd:gMonth
xsd:anyURIxsd:tokenxsd:language
xsd:NMTOKENxsd:Namexsd:NCName
The above datatypes, plus rdfs:Literal, form the built-in OWL datatypes. All OWL reasoners are required to support the xsd:integer and xsd:string datatypes.
Other built-in XML Schema datatypes may be used in OWL Full, but with caveats described in the OWL Semantics and Abstract Syntax (http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html) documentation.
<owl:Class rdf:ID="VintageYear" />
<owl:DatatypeProperty rdf:ID="yearValue">
<rdfs:domain rdf:resource="#VintageYear" />
<rdfs:range rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty>
The yearValue property relates VintageYears to positive integer values. We introduce the hasVintageYear property, which relates a Vintage to a VintageYear below. (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#FunctionalProperty)
The OWL Reference (http://www.w3.org/TR/2004/REC-owl-ref-20040210/#EnumeratedDatatype) ([Reference], 6.2) describes the use of owl:oneOf and rdf:List and rdf:rest to define an enumerated datatype. The example shows how to construct the owl:DatatypeProperty, tennisGameScore, with a range equal to the elements of the list of integer values {0, 15, 30, 40}.
3.2.3. Properties of Individuals
First we describe Region and Winery individuals, and then we define our first wine, a Cabernet Sauvignon.
<Region rdf:ID="SantaCruzMountainsRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
</Region>
<Winery rdf:ID="SantaCruzMountainVineyard" />
<CabernetSauvignon
rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
<locatedIn rdf:resource="#SantaCruzMountainsRegion"/>
<hasMaker rdf:resource="#SantaCruzMountainVineyard" />
</CabernetSauvignon>
This is still incomplete. There are other aspects of the wine flavor that are defined in the full ontology. But the pieces are falling together. We could begin reasoning about what menu items in our food ontology this wine might accompany. We know from the definition above that the Santa Cruz Mountain Vineyard makes it. Because it is a Cabernet Sauvignon (see wine.rdf (http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine.rdf)), we know it is a dry, red wine.
Datatype properties can be added to individuals in a similar fashion. Below we describe an instance of VintageYear and tie it to a specific value of type &xsd:positiveInteger.
<VintageYear rdf:ID="Year1998">
<yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue>
</VintageYear>
3.3. Property Characteristics
The next few sections describe the mechanisms used to further specify properties. It is possible to specify property characteristics, which provides a powerful mechanism for enhanced reasoning about a property.
3.3.1. TransitiveProperty
If a property, P, is specified as transitive then for any x, y, and z:
P(x,y) and P(y,z) implies P(x,z)
The property locatedIn is transitive.
<owl:ObjectProperty rdf:ID="locatedIn">
<rdf:type rdf:resource="&owl;TransitiveProperty" />
<rdfs:domain rdf:resource="&owl;Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
<Region rdf:ID="SantaCruzMountainsRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
</Region>
<Region rdf:ID="CaliforniaRegion">
<locatedIn rdf:resource="#USRegion" />
</Region>
Because the SantaCruzMountainsRegion is locatedIn the CaliforniaRegion, then it must also be locatedIn the USRegion, since locatedIn is transitive.
3.3.2. SymmetricProperty
If a property, P, is tagged as symmetric then for any x and y:
P(x,y) iff P(y,x)
The property adjacentRegion is symmetric, while locatedIn is not. To be more precise, locatedIn is not intended to be symmetric. Nothing in the wine ontology at present prevents it from being symmetric.
<owl:ObjectProperty rdf:ID="adjacentRegion">
<rdf:type rdf:resource="&owl;SymmetricProperty" />
<rdfs:domain rdf:resource="#Region" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
<Region rdf:ID="MendocinoRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
<adjacentRegion rdf:resource="#SonomaRegion" />
</Region>
The MendocinoRegion is adjacent to the SonomaRegion and vice-versa. The MendocinoRegion is located in the CaliforniaRegion but not vice versa.
3.3.3. FunctionalProperty
If a property, P, is tagged as functional then for all x, y, and z:
P(x,y) and P(x,z) implies y = z
In our wine ontology, hasVintageYear is functional. A wine has a unique vintage year. That is, a given individual Vintage can only be associated with a single year using the hasVintageYear property. It is not a requirement of a owl:FunctionalProperty that all elements of the domain have values. See the discussion of Vintage cardinality.
<owl:Class rdf:ID="VintageYear" />
<owl:ObjectProperty rdf:ID="hasVintageYear">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Vintage" />
<rdfs:range rdf:resource="#VintageYear" />
</owl:ObjectProperty>
3.3.4. inverseOf
If a property, P1, is tagged as the owl:inverseOf P2, then for all x and y:
P1(x,y) iff P2(y,x)
Note that the syntax for owl:inverseOf takes a property name as an argument. A iff B means (A implies B) and (B implies A).
<owl:ObjectProperty rdf:ID="hasMaker">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="producesWine">
<owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>
Wines have makers, which in the definition of Wine are restricted to Winerys. Then each Winery produces the set of wines that identify it as maker.
3.3.5. InverseFunctionalProperty
If a property, P, is tagged as InverseFunctional then for all x, y and z:
P(y,x) and P(z,x) implies y = z
Notice that producesWine in the preceding section is inverse functional. The reason is that the inverse of a functional property must be inverse functional. We could have defined hasMaker and producesWine as follows and achieved the identical effect as the preceding example.
<owl:ObjectProperty rdf:ID="hasMaker" />
<owl:ObjectProperty rdf:ID="producesWine">
<rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
<owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty> ?
Think of the elements of the range in an inverse functional property as defining a unique key in the database sense. owl:InverseFunctional implies that the elements of the range provide a unique identifier for each element of the domain.
In OWL Full, we can tag a DatatypeProperty as inverseFunctional. This permits us to identify a string as a unique key. In OWL DL literals are disjoint from owl:Thing, which is why OWL DL does not permit InverseFunctional to be applied to DatatypeProperty.
3.4. Property Restrictions
In addition to designating property characteristics, it is possible to further constrain the range of a property in specific contexts in a variety of ways. We do this with property restrictions. The various forms described below can only be used within the context of an owl:Restriction. The owl:onProperty element indicates the restricted property.
3.4.1. allValuesFrom, someValuesFrom
We have already seen one way to restrict the types of the elements that make up a property. The mechanisms to date have been global in that they apply to all instances of the property. These next two, allValuesFrom and someValuesFrom, are local to their containing class definition.
The owl:allValuesFrom restriction requires that for every instance of the class that has instances of the specified property, the values of the property are all members of the class indicated by the owl:allValuesFrom clause.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
...
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:allValuesFrom rdf:resource="#Winery" />
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class>
The maker of a Wine must be a Winery. The allValuesFrom restriction is on the hasMaker property of this Wine class only. Makers of Cheese are not constrained by this local restriction.
owl:someValuesFrom is similar. If we replaced owl:allValuesFrom with owl:someValuesFrom in the example above, it would mean that at least one of the hasMaker properties of a Wine must point to an individual that is a Winery.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:someValuesFrom rdf:resource="#Winery" />
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class> ?
The difference between the two formulations is the difference between a universal and existential quantification.
RelationImplications
allValuesFromFor all wines, if they have makers, all the makers are wineries.
someValuesFrom For all wines, they have at least one maker that is a winery.
The first does not require a wine to have a maker. If it does have one or more, they must all be wineries. The second requires that there be at least one maker that is a winery, but there may be makers that are not wineries.
3.4.2. Cardinality
We have already seen examples of cardinality constraints. To date, they have been assertions about minimum cardinality. Even more straight-forward is owl:cardinality, which permits the specification of exactly the number of elements in a relation. For example, we specify Vintage to be a class with exactly one VintageYear.
<owl:Class rdf:ID="Vintage">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasVintageYear"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
We specified hasVintageYear to be a functional property, which is the same as saying that every Vintage has at most one VintageYear. This application of that property to Vintage using the cardinality restriction asserts something stronger, that every Vintage has exactly one VintageYear.
Cardinality expressions with values limited to 0 or 1 are part of OWL Lite. This permits the user to indicate 'at least one', 'no more than one', and 'exactly one'. Positive integer values other than 0 and 1 are permitted in OWL DL. owl:maxCardinality can be used to specify an upper bound. owl:minCardinality can be used to specify a lower bound. In combination, the two can be used to limit the property's cardinality to a numeric interval.
3.4.3. hasValue [OWL DL (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#OWL_DL_tag) ]
hasValue allows us to specify classes based on the existence of particular property values. Hence, an individual will be a member of such a class whenever at least one of its property values is equal to the hasValue resource.
<owl:Class rdf:ID="Burgundy">
...
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasSugar" />
<owl:hasValue rdf:resource="#Dry" />
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Here we declare that all Burgundy wines are dry. That is, their hasSugar property must have at least one value that is equal to Dry.
As for allValuesFrom and someValuesFrom, this is a local restriction. It holds for hasSugar as applied to Burgundy.
R>
...
<!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" >
<!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" >
...
<rdf:RDF xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" ... >
...
Given these definitions we can refer to the winery class either using the XML tag vin:Winery or the attribute value &vin;Winery. More literally, it is always possible to reference a resource using its full URI, here http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Winery.
The fundamental taxonomic constructor for classes is rdfs:subClassOf. It relates a more specific class to a more general class. If X is a subclass of Y, then every instance of X is also an instance of Y. The rdfs:subClassOf relation is transitive. If X is a subclass of Y and Y a subclass of Z then X is a subclass of Z.
<owl:Class rdf:ID="PotableLiquid">
<rdfs:subClassOf rdf:resource="#ConsumableThing" />
...
</owl:Class>
We define PotableLiquid (liquids suitable for drinking) to be a subclass of ConsumableThing.
In the world of Web-based ontologies, both of these classes can be defined in a separate ontology that would provide the basic building blocks for a wide variety of food and drink ontologies, which is what we have done - they are defined in the food (http://www.w3.org/TR/2004/REC-owl-guide-20040210/food.rdf) ontology, which is imported (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#import) into the wine ontology. The food ontology includes a number of classes, for example Food, EdibleThing, MealCourse, and Shellfish, that do not belong in a collection of wine facts, but must be connected to the wine vocabulary if we are going to perform useful reasoning. Food and wine are mutually dependent, in order to satisfy our need to identify wine/food matches.
A class definition has two parts: a name introduction or reference and a list of restrictions. Each of the immediate contained expressions in the class definition further restricts the instances of the defined class. Instances of the class belong to the intersection of the restrictions. (Though see the details of owl:equivalentClass.) So far we have only seen examples that include a single restriction, forcing the new class to be a subclass of some other named class.
At this point it is possible to create a simple (and incomplete) definition for the class Wine. Wine is a PotableLiquid. We also define Pasta as an EdibleThing.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
<rdfs:label xml:lang="en">wine</rdfs:label>
<rdfs:label xml:lang="fr">vin</rdfs:label>
...
</owl:Class>
<owl:Class rdf:ID="Pasta">
<rdfs:subClassOf rdf:resource="#EdibleThing" />
...
</owl:Class>
The rdfs:label entry provides an optional human readable name for this class. Presentation tools can make use of it. The "lang" attribute provides support for multiple languages. A label is like a comment and contributes nothing to the logical interpretation of an ontology.
Our wine definition is still very incomplete. We know nothing about wines except that they are things and potable liquids, but we have sufficient information to create and reason about individuals.
3.1.2. Individuals
In addition to classes, we want to be able to describe their members. We normally think of these as individuals in our universe of things. An individual is minimally introduced by declaring it to be a member of a class.
<Region rdf:ID="CentralCoastRegion" />
Note that the following is identical in meaning to the example above.
<owl:Thing rdf:ID="CentralCoastRegion" />
<owl:Thing rdf:about="#CentralCoastRegion">
<rdf:type rdf:resource="#Region"/>
</owl:Thing>
rdf:type is an RDF property that ties an individual to a class of which it is a member.
There are a couple of points to be made here. First, we have decided that CentralCoastRegion (a specific area) is member of Region, the class containing all geographical regions. Second, there is no requirement in the two-part example that the two elements need to be adjacent to one another, or even in the same file (though the names would need to be extended with a URI in such a case). We design Web ontologies to be distributed. They can be imported and augmented, creating derived ontologies.
In order to have available a few more classes for the properties introduced in the next sections, we define a branch of the Grape taxonomy, with an individual denoting the Cabernet Sauvignon grape varietal. Grapes are defined in the food ontology:
<owl:Class rdf:ID="Grape">
...
</owl:Class>
And then in the wine ontology we have:
<owl:Class rdf:ID="WineGrape">
<rdfs:subClassOf rdf:resource="&food;Grape" />
</owl:Class>
<WineGrape rdf:ID="CabernetSauvignonGrape" />
As discussed in the next section, CabernetSauvignonGrape is an individual because it denotes a single grape varietal.
3.1.3. Design for Use
There are important issues regarding the distinction between a class and an individual in OWL. A class is simply a name and collection of properties that describe a set of individuals. Individuals are the members of those sets. Thus classes should correspond to naturally occurring sets of things in a domain of discourse, and individuals should correspond to actual entities that can be grouped into these classes.
In building ontologies, this distinction is frequently blurred in two ways:
- Levels of representation: In certain contexts something that is obviously a class can itself be considered an instance of something else. For example, in the wine ontology we have the notion of a Grape, which is intended to denote the set of all grape varietals. CabernetSauvingonGrape is an example instance of this class, as it denotes the actual grape varietal called Cabernet Sauvignon. However, CabernetSauvignonGrape could itself be considered a class, the set of all actual Cabernet Sauvignon grapes.
- Subclass vs. instance: It is very easy to confuse the instance-of relationship with the subclass relationship. For example, it may seem arbitrary to choose to make CabernetSauvignonGrape an individual that is an instance of Grape, as opposed to a subclass of Grape. This is not an arbitrary decision. The Grape class denotes the set of all grape varietals, and therefore any subclass of Grape should denote a subset of these varietals. Thus, CabernetSauvignonGrape should be considered an instance of Grape, and not a subclass. It does not describe a subset of Grape varietals, it is a grape varietal.
Note that the same distinction arises with the treatment of the Wine class. The Wine class actually denotes the set of all varieties of wine, not the set of actual bottles that someone may purchase. In an alternate ontology, each instance of Wine in the current ontology could instead designate a class consisting of all the bottles of wine of that type. It is easy to imagine an information system, such as an inventory system for a wine merchant, that needs to consider individual bottles of wine. The wine ontology as it currently exists would require the ability to treat classes as instances in order to support such an interpretation. Note that OWL Full permits such expressivity, allowing us to treat an instance of a wine variety simultaneously as a class whose instances are bottles of wine.
In a similar vein, the wines produced by wineries in specific years are considered vintages. In order to represent the notion of a vintage, we must determine where it fits in the current ontology. An instance of the Wine class, as discussed above, represents a single variety of wine produced by a single winery, for example FormanChardonnay.
Adding that the wine produced in the year 2000 is considered a vintage poses a challenge, because we don't have the ability to represent a subset of a given wine individual. This vintage is not a new variety of wine, it is a special subset of the wine - that produced in the year 2000. An option would be to use OWL Full and treat the wine instances as classes with subclasses (subsets) denoting vintages. Another option is to use a workaround and to consider Vintage as a separate class whose instances have a relationship to the Wine they are a vintage of. For example, FormanChardonnay2000 is an individual Vintage with a vintageOf property whose value is the Wine, FormanChardonnay. We define the Vintage class below.
The point of this discussion is to note that the development of an ontology should be firmly driven by the intended usage. These issues also underlie one major difference between OWL Full and OWL DL. OWL Full allows the use of classes as instances and OWL DL does not. The wine ontology is designed to work in OWL DL, and as a result individuals like FormanChardonnay are not simultaneously treated as classes.
3.2. Simple Properties
This world of classes and individuals would be pretty uninteresting if we could only define taxonomies. Properties let us assert general facts about the members of classes and specific facts about individuals.
===3.2.1. Defining Properties
ObjectProperty, DatatypeProperty, rdfs:subPropertyOf,
rdfs:domain, rdfs:range===
A property is a binary relation. Two types of properties are distinguished:
- datatype properties, relations between instances of classes and RDF literals and XML Schema datatypes
- object properties, relations between instances of two classes. Note that the name object property is not intended to reflect a connection with the RDF (http://www.w3.org/RDF/) term rdf:object (http://www.w3.org/TR/rdf-schema/#ch_object) ([RDF (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#RDF1)], 5.3.4).
When we define a property there are a number of ways to restrict the relation. The domain and range can be specified. The property can be defined to be a specialization (subproperty) of an existing property. More elaborate restrictions are possible and are described later (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#PropertyCharacteristics).
<owl:ObjectProperty rdf:ID="madeFromGrape">
<rdfs:domain rdf:resource="#Wine"/>
<rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="course">
<rdfs:domain rdf:resource="#Meal" />
<rdfs:range rdf:resource="#MealCourse" />
</owl:ObjectProperty>
In OWL, a sequence of elements without an explicit operator represents an implicit conjunction. The property madeFromGrape has a domain of Wine and a range of WineGrape. That is, it relates instances of the class Wine to instances of the class WineGrape. Multiple domains mean that the domain of the property is the intersection of the identified classes (and similarly for range).
Similarly, the property course ties a Meal to a MealCourse.
Note that the use of range and domain information in OWL is different from type information in a programming language. Among other things, types are used to check consistency in a programming language. In OWL, a range may be used to infer a type. For example, given:
<owl:Thing rdf:ID="LindemansBin65Chardonnay">
<madeFromGrape rdf:resource="#ChardonnayGrape" />
</owl:Thing> ?
we can infer that LindemansBin65Chardonnay is a wine because the domain of madeFromGrape is Wine.
Properties, like classes, can be arranged in a hierarchy.
<owl:Class rdf:ID="WineDescriptor" />
<owl:Class rdf:ID="WineColor">
<rdfs:subClassOf rdf:resource="#WineDescriptor" />
...
</owl:Class>
<owl:ObjectProperty rdf:ID="hasWineDescriptor">
<rdfs:domain rdf:resource="#Wine" />
<rdfs:range rdf:resource="#WineDescriptor" />
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="hasColor">
<rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" />
<rdfs:range rdf:resource="#WineColor" />
...
</owl:ObjectProperty>
WineDescriptor properties relate wines to their color and components of their taste, including sweetness, body, and flavor. hasColor is a subproperty of the hasWineDescriptor property, with its range further restricted to WineColor. The rdfs:subPropertyOf relation in this case means that anything with a hasColor property with value X also has a hasWineDescriptor property with value X.
Next we introduce the locatedIn property, which relates things to the regions they are located in.
<owl:ObjectProperty rdf:ID="locatedIn">
...
<rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
Notice how the domain and range of locatedIn are defined. The domain permits anything to be located in a region, including regions themselves. And the transitive (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#owl_TransitiveProperty) composition of this relation essentially creates a network of geographically included subregions and things. Those things that have nothing located in them can be of any class, while those that contain others must be regions.
It is now possible to expand the definition of Wine to include the notion that a wine is made from at least one WineGrape. As with property definitions, class definitions have multiple subparts that are implicitly conjoined.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#madeFromGrape"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class>
The highlighted subclass restriction above
<owl:Restriction>
<owl:onProperty rdf:resource="#madeFromGrape"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
defines an unnamed class that represents the set of things with at least one madeFromGrape property. We call these anonymous classes. Including this restriction in the Wine class definition body states that things that are wines are also members of this anonymous class. That is, every individual wine must participate in at least one madeFromGrape relation.
We can now describe the class of Vintages, discussed previously (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#vintageIntro).
<owl:Class rdf:ID="Vintage">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#vintageOf"/>
<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class> ?
The property vintageOf ties a Vintage to a Wine.
<owl:ObjectProperty rdf:ID="vintageOf">
<rdfs:domain rdf:resource="#Vintage" />
<rdfs:range rdf:resource="#Wine" />
</owl:ObjectProperty> ?
We relate Vintages to their years in the next section.
3.2.2. Properties and Datatypes
We distinguish properties according to whether they relate individuals to individuals (object properties) or individuals to datatypes (datatype properties). Datatype properties may range over RDF literals or simple types defined in accordance with XML Schema datatypes (http://www.w3.org/TR/xmlschema-2/).
OWL uses most of the built-in XML Schema datatypes. References to these datatypes are by means of the URI reference for the datatype, http://www.w3.org/2001/XMLSchema. The following datatypes are recommended for use with OWL:
xsd:stringxsd:normalizedStringxsd:boolean
xsd:decimalxsd:floatxsd:double
xsd:integerxsd:nonNegativeIntegerxsd:positiveInteger
xsd:nonPositiveIntegerxsd:negativeInteger
xsd:longxsd:intxsd:shortxsd:byte
xsd:unsignedLongxsd:unsignedIntxsd:unsignedShortxsd:unsignedByte
xsd:hexBinaryxsd:base64Binary
xsd:dateTimexsd:timexsd:datexsd:gYearMonth
xsd:gYearxsd:gMonthDayxsd:gDayxsd:gMonth
xsd:anyURIxsd:tokenxsd:language
xsd:NMTOKENxsd:Namexsd:NCName
The above datatypes, plus rdfs:Literal, form the built-in OWL datatypes. All OWL reasoners are required to support the xsd:integer and xsd:string datatypes.
Other built-in XML Schema datatypes may be used in OWL Full, but with caveats described in the OWL Semantics and Abstract Syntax (http://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html) documentation.
<owl:Class rdf:ID="VintageYear" />
<owl:DatatypeProperty rdf:ID="yearValue">
<rdfs:domain rdf:resource="#VintageYear" />
<rdfs:range rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty>
The yearValue property relates VintageYears to positive integer values. We introduce the hasVintageYear property, which relates a Vintage to a VintageYear below. (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#FunctionalProperty)
The OWL Reference (http://www.w3.org/TR/2004/REC-owl-ref-20040210/#EnumeratedDatatype) ([Reference], 6.2) describes the use of owl:oneOf and rdf:List and rdf:rest to define an enumerated datatype. The example shows how to construct the owl:DatatypeProperty, tennisGameScore, with a range equal to the elements of the list of integer values {0, 15, 30, 40}.
3.2.3. Properties of Individuals
First we describe Region and Winery individuals, and then we define our first wine, a Cabernet Sauvignon.
<Region rdf:ID="SantaCruzMountainsRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
</Region>
<Winery rdf:ID="SantaCruzMountainVineyard" />
<CabernetSauvignon
rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
<locatedIn rdf:resource="#SantaCruzMountainsRegion"/>
<hasMaker rdf:resource="#SantaCruzMountainVineyard" />
</CabernetSauvignon>
This is still incomplete. There are other aspects of the wine flavor that are defined in the full ontology. But the pieces are falling together. We could begin reasoning about what menu items in our food ontology this wine might accompany. We know from the definition above that the Santa Cruz Mountain Vineyard makes it. Because it is a Cabernet Sauvignon (see wine.rdf (http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine.rdf)), we know it is a dry, red wine.
Datatype properties can be added to individuals in a similar fashion. Below we describe an instance of VintageYear and tie it to a specific value of type &xsd:positiveInteger.
<VintageYear rdf:ID="Year1998">
<yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue>
</VintageYear>
3.3. Property Characteristics
The next few sections describe the mechanisms used to further specify properties. It is possible to specify property characteristics, which provides a powerful mechanism for enhanced reasoning about a property.
3.3.1. TransitiveProperty
If a property, P, is specified as transitive then for any x, y, and z:
P(x,y) and P(y,z) implies P(x,z)
The property locatedIn is transitive.
<owl:ObjectProperty rdf:ID="locatedIn">
<rdf:type rdf:resource="&owl;TransitiveProperty" />
<rdfs:domain rdf:resource="&owl;Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
<Region rdf:ID="SantaCruzMountainsRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
</Region>
<Region rdf:ID="CaliforniaRegion">
<locatedIn rdf:resource="#USRegion" />
</Region>
Because the SantaCruzMountainsRegion is locatedIn the CaliforniaRegion, then it must also be locatedIn the USRegion, since locatedIn is transitive.
3.3.2. SymmetricProperty
If a property, P, is tagged as symmetric then for any x and y:
P(x,y) iff P(y,x)
The property adjacentRegion is symmetric, while locatedIn is not. To be more precise, locatedIn is not intended to be symmetric. Nothing in the wine ontology at present prevents it from being symmetric.
<owl:ObjectProperty rdf:ID="adjacentRegion">
<rdf:type rdf:resource="&owl;SymmetricProperty" />
<rdfs:domain rdf:resource="#Region" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
<Region rdf:ID="MendocinoRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
<adjacentRegion rdf:resource="#SonomaRegion" />
</Region>
The MendocinoRegion is adjacent to the SonomaRegion and vice-versa. The MendocinoRegion is located in the CaliforniaRegion but not vice versa.
3.3.3. FunctionalProperty
If a property, P, is tagged as functional then for all x, y, and z:
P(x,y) and P(x,z) implies y = z
In our wine ontology, hasVintageYear is functional. A wine has a unique vintage year. That is, a given individual Vintage can only be associated with a single year using the hasVintageYear property. It is not a requirement of a owl:FunctionalProperty that all elements of the domain have values. See the discussion of Vintage cardinality.
<owl:Class rdf:ID="VintageYear" />
<owl:ObjectProperty rdf:ID="hasVintageYear">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Vintage" />
<rdfs:range rdf:resource="#VintageYear" />
</owl:ObjectProperty>
3.3.4. inverseOf
If a property, P1, is tagged as the owl:inverseOf P2, then for all x and y:
P1(x,y) iff P2(y,x)
Note that the syntax for owl:inverseOf takes a property name as an argument. A iff B means (A implies B) and (B implies A).
<owl:ObjectProperty rdf:ID="hasMaker">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="producesWine">
<owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty>
Wines have makers, which in the definition of Wine are restricted to Winerys. Then each Winery produces the set of wines that identify it as maker.
3.3.5. InverseFunctionalProperty
If a property, P, is tagged as InverseFunctional then for all x, y and z:
P(y,x) and P(z,x) implies y = z
Notice that producesWine in the preceding section is inverse functional. The reason is that the inverse of a functional property must be inverse functional. We could have defined hasMaker and producesWine as follows and achieved the identical effect as the preceding example.
<owl:ObjectProperty rdf:ID="hasMaker" />
<owl:ObjectProperty rdf:ID="producesWine">
<rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
<owl:inverseOf rdf:resource="#hasMaker" />
</owl:ObjectProperty> ?
Think of the elements of the range in an inverse functional property as defining a unique key in the database sense. owl:InverseFunctional implies that the elements of the range provide a unique identifier for each element of the domain.
In OWL Full, we can tag a DatatypeProperty as inverseFunctional. This permits us to identify a string as a unique key. In OWL DL literals are disjoint from owl:Thing, which is why OWL DL does not permit InverseFunctional to be applied to DatatypeProperty.
3.4. Property Restrictions
In addition to designating property characteristics, it is possible to further constrain the range of a property in specific contexts in a variety of ways. We do this with property restrictions. The various forms described below can only be used within the context of an owl:Restriction. The owl:onProperty element indicates the restricted property.
3.4.1. allValuesFrom, someValuesFrom
We have already seen one way to restrict the types of the elements that make up a property. The mechanisms to date have been global in that they apply to all instances of the property. These next two, allValuesFrom and someValuesFrom, are local to their containing class definition.
The owl:allValuesFrom restriction requires that for every instance of the class that has instances of the specified property, the values of the property are all members of the class indicated by the owl:allValuesFrom clause.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
...
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:allValuesFrom rdf:resource="#Winery" />
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class>
The maker of a Wine must be a Winery. The allValuesFrom restriction is on the hasMaker property of this Wine class only. Makers of Cheese are not constrained by this local restriction.
owl:someValuesFrom is similar. If we replaced owl:allValuesFrom with owl:someValuesFrom in the example above, it would mean that at least one of the hasMaker properties of a Wine must point to an individual that is a Winery.
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="&food;PotableLiquid" />
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasMaker" />
<owl:someValuesFrom rdf:resource="#Winery" />
</owl:Restriction>
</rdfs:subClassOf>
...
</owl:Class> ?
The difference between the two formulations is the difference between a universal and existential quantification.
RelationImplications
allValuesFromFor all wines, if they have makers, all the makers are wineries.
someValuesFrom For all wines, they have at least one maker that is a winery.
The first does not require a wine to have a maker. If it does have one or more, they must all be wineries. The second requires that there be at least one maker that is a winery, but there may be makers that are not wineries.
3.4.2. Cardinality
We have already seen examples of cardinality constraints. To date, they have been assertions about minimum cardinality. Even more straight-forward is owl:cardinality, which permits the specification of exactly the number of elements in a relation. For example, we specify Vintage to be a class with exactly one VintageYear.
<owl:Class rdf:ID="Vintage">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasVintageYear"/>
<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
We specified hasVintageYear to be a functional property, which is the same as saying that every Vintage has at most one VintageYear. This application of that property to Vintage using the cardinality restriction asserts something stronger, that every Vintage has exactly one VintageYear.
Cardinality expressions with values limited to 0 or 1 are part of OWL Lite. This permits the user to indicate 'at least one', 'no more than one', and 'exactly one'. Positive integer values other than 0 and 1 are permitted in OWL DL. owl:maxCardinality can be used to specify an upper bound. owl:minCardinality can be used to specify a lower bound. In combination, the two can be used to limit the property's cardinality to a numeric interval.
3.4.3. hasValue [OWL DL (http://www.w3.org/TR/2004/REC-owl-guide-20040210/#OWL_DL_tag)]
hasValue allows us to specify classes based on the existence of particular property values. Hence, an individual will be a member of such a class whenever at least one of its property values is equal to the hasValue resource.
<owl:Class rdf:ID="Burgundy">
...
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#hasSugar" />
<owl:hasValue rdf:resource="#Dry" />
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
Here we declare that all Burgundy wines are dry. That is, their hasSugar property must have at least one value that is equal to Dry.
As for allValuesFrom and someValuesFrom, this is a local restriction. It holds for hasSugar as applied to Burgundy.
