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.

---

---

2. camper trailer
   2009-05-29 00:27:14 evani dale
4. confused
   2002-11-01 08:39:46 j d
• camper trailers
  2009-05-29 00:25:44 evani dale
6. Errata
   2002-04-03 06:57:38 Uche Ogbuji
8. Re: I don't get it
   2002-04-03 06:46:07 Uche Ogbuji
10. Good article
    2002-03-19 23:31:52 Charlie Abela
12. don't get it
    2002-03-15 14:06:46 Son To