Back to DAML homepage

Some Notes on the Differences Between DAML+OIL and DAML-ONT

Feedback to www-rdf-logic, please.

Ian Horrocks (editor)

Contributors: Tim Berners-Lee, Dan Brickley, Dan Connolly, Mike Dean, Stefan Decker, Frank van Harmelen, Pat Hayes, Jeff Heflin, Jim Hendler, Deb McGuinness, Lynn Andrea Stein

1. Thing is made equal to the union of Nothing and the complement of Nothing. This isn't necessary, but it does give it some built-in semantics.

2. Local cardinality restrictions have been added. These allow both simple and qualified (including a class restriction) restrictions.

3. The restrictedBy property has been deleted as it was redundant: it was a synonym for subclassOf.

4. The distinction between restrictions and qualifications has been removed - there are now only restrictions. Having both restrictions and qualifications meant that the domain of "onProperty" had to be the union of the two. This was done by relying on the disputed union semantics for rdfs:domain (although it could have been done by using a  superclass of restriction and qualification).

5. The semantics of restrictions has been changed to being a necessary and sufficient condition in line with all the other "class constructors" (and, or, not etc.). "Primitive" classes can be specified by adding restrictions with the subClassOf property, while "defined" classes can be specified with the equivalentTo property. e.g.:

<Class ID="Animal">
    <label>Animal</label>
    <subClassOf>
        <Restriction>
            <onProperty resource="#parent"/>
            <cardinality>2</cardinality>
        </Restriction>
    </subClassOf>
</Class>
states that all Animals have 2 parents (primitive), while
<Class ID="Animal">
    <label>Animal</label>
    <equivalentTo>
        <Restriction>
            <onProperty resource="#parent"/>
            <cardinality>2</cardinality>
        </Restriction>
    </equivalentTo>
</Class>
states that something is an Animal if and only if it has 2 parents (defined). More complex defined classes can be created using the boolean connectives. e.g.:
<Class ID="Human">
    <label>Human</label>
    <intersectionOf parseType="daml:collection">
        <Class about="#Animal"/>
        <Restriction>
            <onProperty resource="#parent"/>
            <hasValue resource="#Human"/>
        </Restriction>
    </intersectionOf>
</Class>
states that something is a Human if and only if it is an Animal that has some Human parent.

6. Cardinality facets on slots have been deleted as they are now redundant and have strange/doubtful semantics. If it is really necessary to add a global cardinality restriction to a property, this can be done by placing a restriction on "Thing":

<Class about="#Thing">
    <subClassOf>
        <Restriction>
            <onProperty resource="#parent"/>
            <maxCardinality>2</maxCardinality>
        </Restriction>
    </subClassOf>
</Class>
7. While DAML-ONT generally did a good job of naming classes and properties, the choices of "toValue" and "hasValue" are not so good: "hasValue" and "hasClass" respectively are better choices. These names reflect more clearly the meaning of the two restrictions. In particular, in the old scheme toValue suggests the same kind of restriction as toClass, which is not the case: toClass is a universal quantification (and is satisfied in the case where there is no relevant property), while toValue insists on the existence of a relevant property (but does not exclude the existence of additional values for the same property). In fact toValue(R, V) is equivalent to {hasValue(R, X), oneOf(X, V)}. To sum up, DAML+OIL implements the following property renamings:
 
DAML
 DAML+OIL
 toValue  hasValue
 hasValue   hasClass
8. "default" was removed due to its lack of semantics.

9. Local namespace equivalents for rdf and rdfs resources are defined, but may compromise portability if used.

Note: DAML+OIL uses the daml:collection parseType to extend the syntax of RDF with a convenient notation for collections. Current RDF parsers (RDF specification of February '99) will not support the daml:collection parseType. In order to process DAML+OIL documents, such parsers will have to be extended, or a separate preprocessing stage is required which translates the first form above into the second before the DAML+OIL code is given as input to the RDF parser. See the reference document on DAML+OIL for further details.
 

$Revision: 1.4 $ of $Date: 2001/01/10 20:00:00 $