|
Introduction to DAML: Part II
by Roxane
Ouellet, Uche Ogbuji | Pages: 1, 2,
3
Property Restrictions
Finally, we have reached the most fundamental and most radical facility
added by DAML+OIL. For many reasons ranging from convenience to access
control, one might not directly assert a classification for a resource.
DAML+OIL provides property restrictions, which are a way to restrict
classes to a set of resources based on particular properties of theirs,
the number of these properties that are asserted, or the value of these
properties. The easiest way to consider property restrictions is by
example. <daml:Class rdf:ID="MensProduct">
<rdfs:label>Men's Product</rdfs:label>
<rdfs:comment>A product particularly designed to
be used by men</rdfs:comment>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="#targetSex"/>
<daml:hasValue rdf:resource="#Male"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
This defines the MensProduct class as a subclass of
another class defined in-line as a DAML+OIL restriction. These special
classes are defined by rules that specify what conditions of a resources
properties must be met for that resource to be a member of the class.
daml:onProperty identifies which property is to be checked.
daml:hasValue then declares that the property in question
must have a particular value. So, in effect, the above says that a men's
product is a subclass of all resources which have at least one
targetSex property whose value is Male.
Of course, because MensProduct is a subclass of this
restriction, there could be resources that meet this restriction but are
not in the MensProduct class. To assert that a men's product
is any resource that meets this restriction, one would write: <daml:Class rdf:ID="MensProduct">
<rdfs:label>Men's Product</rdfs:label>
<rdfs:comment>A product particularly designed to
be used by men</rdfs:comment>
<daml:sameClassAs>
<daml:Restriction>
<daml:onProperty rdf:resource="#targetSex"/>
<daml:hasValue rdf:resource="#Male"/>
</daml:Restriction>
</daml:sameClassAs>
</daml:Class>
daml:hasClass
You can also define property restrictions by the class of the values of
a property, rather than its value. <daml:Class rdf:ID="Ball">
<rdfs:label>Ball</rdfs:label>
<rdfs:comment>A ball designed to be used in sports</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Product"/>
</daml:Class>
<daml:Class rdf:ID="BallSport">
<rdfs:label>Ball Sport</rdfs:label>
<rdfs:comment>Activities that involve play using balls</rdfs:comment>
<daml:sameClassAs>
<daml:Restriction>
<daml:onProperty rdf:resource="#gear"/>
<daml:hasClass rdf:resource="#Ball"/>
</daml:Restriction>
</daml:sameClassAs>
</daml:Class>
Which defines a ball sport as a thing which counts among its gear at
least one product classified as a ball. Remember that gear is
a property we defined as the inverse of usedFor, and its
domain is fixed as Activity. This means that all ball sports
must also be activities, since they must have a gear
property, and the domain of this property is Activity.
But we can also express more clearly the fact that all ball sports are
activities. <daml:Class rdf:ID="BallSport">
<rdfs:label>Ball Sport</rdfs:label>
<rdfs:comment>Activities that involve play using balls</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Activity"/>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="#gear"/>
<daml:hasClass rdf:resource="#Ball"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
This says that a ball sport is a subclass of activities and a
subclass of those things that count at least one ball among their gear.
Therefore, all ball sports must be activities and must meet this
restriction; but note that as stated above, it is possible for an activity
to have a ball as gear and yet not be a ball sport. We can eliminate this
loophole by rewriting to: <daml:Class rdf:ID="BallSport">
<rdfs:label>Ball Sport</rdfs:label>
<rdfs:comment>Activities that involve play using balls</rdfs:comment>
<daml:intersectionOf parseType="daml:collection">
<daml:Class rdf:resource="#Activity"/>
<daml:Restriction>
<daml:onProperty rdf:resource="#gear"/>
<daml:hasClass rdf:resource="#Ball"/>
</daml:Restriction>
</daml:intersectionOf>
</daml:Class>
We can do this because daml:Restriction is a valid class
expression, which opens it up for use in many DAML+OIL constructs.
daml:toClass
There is another type of property restriction that considers the class
of property values. daml:toClass makes a requirement that
all the property values for a resource be of a certain class. <daml:Class rdf:ID="ObsoleteActivity">
<rdfs:label>Obsolete activity</rdfs:label>
<rdfs:comment>Activities for which all related products have been discontinued</rdfs:comment>
<daml:intersectionOf parseType="daml:collection">
<daml:Class rdf:resource="#Activity"/>
<daml:Restriction>
<daml:onProperty rdf:resource="#gear"/>
<daml:toClass rdf:resource="#DiscontinuedProduct"/>
</daml:Restriction>
</daml:intersectionOf>
</daml:Class>
So if an activity has any gear that is not a discontinued product, it
is not considered an obsolete activity. One must be careful with
daml:toClass. Because of the details of its semantics, a
resource will actually meet such a restriction if it does not have the
property given daml:onProperty at all. If you're not careful,
you could have a resource unexpectedly meet a daml:toClass
restriction if the property in question is optional. This is especially
treacherous because on the face of it, daml:toClass is more
restrictive than daml:hasClass, and yet the latter will not
allow a resource that is missing the property in question. For this
reason, unless it is usual for a resource to have more than one instance
of a particular property, it is probably safer to use
daml:hasClass for restrictions according to the class of the
property's value.
Bringing It All Together
Here
is an update of the Super Sports ontology, using the DAML+OIL features
introduced in this article.
More To Learn
In the first two articles of this series, we have presented the basics
of DAML+OIL by example. There are additional property restrictions based
on the cardinality (number of occurrences) of a property for each
instance, and there are many nuances we have not covered. DAML+OIL
introduces many constructs, and at first it can be a bit vexing to try to
remember all the different constructs from RDF, RDFS, and DAML+OIL. The
final article will provide some assistance by tabulating all these
constructs, noting which specification defines them, and briefly
describing their usage.
 Share your comments on this article in our
forum.
(* You must be a member
of XML.com to use this feature.)
Comment
on this Article
- Errata
2002-04-03 06:57:38 uche
 |
