XML.com: Introduction to DAML: Part II

Introduction to DAML: Part II
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

Titles Only

Newest First

camper trailer
2009-05-29 00:27:14 evani dale [Reply]

Discountcampertrailers offers Australian campers a great way to find the best camper trailer deal possible. Each and every person will have a different set of requirements so when choosing a camper trailer you need to first consider exactly how your going to use it.

evani dale
camper trailers ()

confused
2002-11-01 08:39:46 j d [Reply]

I am confused about the need for all of these:

rdf:about
rdf:resource
rdf:ID

and how do I decide when to use which one ?
- camper trailers
  2009-05-29 00:25:44 evani dale [Reply]
  
  Discountcampertrailers offers Australian campers a great way to find the best camper trailer deal possible. Each and every person will have a different set of requirements so when choosing a camper trailer you need to first consider exactly how your going to use it.
  
  evani dale
  [url="http://www.discountcampertrailers.com.au"]camper trailers[/url]

Errata
2002-04-03 06:57:38 Uche Ogbuji [Reply]

1) 'Inverse properties are quite common. If A is the father of B, then B is the child of A. The properties "father" and "child" are the inverse of each other.'

This should state that If A is the *parent* of B, then B is the child of A. The properties "parent" and "child" are the inverse of each other.

2) "Only one of the properties need carry the daml:inverseOf property, as it is reflexive."

This property is symmetric, not reflexive.

3) Throughout the article, 'parseType="..."' is used. These should all be 'rdf:parseType="..."'

Thanks to Bijan Parsia for catching (1) and (2), and to "cicho" for catching (3).

Re: I don't get it
2002-04-03 06:46:07 Uche Ogbuji [Reply]

The fact that you can express the models described in this article in any computer language is completely outside any useful point.

Almost any construct expressed in one language can be expressed in any other. This does not argue that there should be only one computer language. A diversity of computer languages gives programmers the best tools for each specific modeling tasks, and advances innovation in computing as a whole. That having been said, I have a long experience in programming in many languages, and I assure you that many of the constructs that DAML+OIL provides simply are feindishly difficult to express in mainstream computer languages. This makes perfect sense, as aminstream computer languages are not designed to represent arbitrary graph navigation patterns.

Good article
2002-03-19 23:31:52 Charlie Abela [Reply]

The article is quit good and hopefully there will be more of the same.
NB: the decleration of parseType should be

<daml:unionOf rdf:parseType="daml:collection">
.....

Thanks

don't get it
2002-03-15 14:06:46 Son To [Reply]

RDF is elusive to me... I do not see the benefit it offers over a strongly typed programming language like Java. The relationships that RDF/DAML defines can be done in any programing language.