An evaluation of DAML+OIL w.r.t. WebOnt candidate requirements

DRAFT $Revision: 1.8 $ of $Date: 2002/02/13 20:52:52 $
by Dan Connolly, @@Ian Horrocks, Mike Dean

following from NJ ftf

update in progress: use requirements draft of 7Feb

  1. Consensus requirements (A)
    1. Ontology namespaces/inter-ontology reference: yes.
    2. Annotation/tagging of ontologies (some particular properties): yes?
    3. lexical representation (internationalization): almost
    4. unambiguous term referencing using URIs: yes
    5. ability to state uniq. names: no/sort
    6. uniqueness of unicode strings: yes
    7. character set support: yes
    8. ontology management language features (versioning): ?
  2. widely supported requirements, with some opposition (B)
  3. requirements with considerable support and considerable opposition (C)
  4. non-requirements (little support or overwhelming opposition) (X)

Consensus (A) Requirements

Ontology namespaces/inter-ontology reference: yes.

For example, see the way the SRI topic ontology refers to terms from their organization, project, researcher, publication, and contactinfo ontologies:

<daml:Ontology rdf:about="">
  <daml:imports rdf:resource=""/>
  <daml:imports rdf:resource=""/>
  <daml:imports rdf:resource=""/>
  <daml:imports rdf:resource=""/>
  <daml:imports rdf:resource=""/>

Note that we're presumingontologyjust means a document that uses ontology-building vocabulary, and if http://example/vocab is a URI of an ontology and http://example/vocab#term is mentioned in that ontology, then http://example/vocab#term is from http://example/vocab.

There are two mechanisms:

  1. use of names from another ontology;

    DAML+OIL inherits from RDF 1.0 the ability to refer to/share terms from other documents, much like HTML <a href> and <a name>.

  2. daml:imports

    which explicitly says "commitment to this document entials commitment to that document".

Actually, it's not 100% clear what daml:imports says. The DAML+OIL specs don't provide a formal specification for it; its semantics seem connected to the state of the web, i.e. protocols, time, and that sort of thing, which are outside the realm of normal DAML+OIL reasoning.

Annotation/tagging of ontologies (some particular properties): yes?

The usual DAML+OIL practice is, for example:

<daml:Ontology rdf:about="">
  <daml:versionInfo>$Id: reqdo.html,v 1.8 2002/02/13 20:52:52 connolly Exp $</daml:versionInfo>
  <rdfs:comment>SRI's ontology for topics </rdfs:comment>

There are two mechanisms here:

  1. the versionInfo property, which is introduced in DAML+OIL
  2. the use of rdfs:comment, i.e. a term from another RDF vocabulary. Dublin Core is a popular ontology for giving title/date/author sorts of metadata.

This meets the requirements of a certain sort of book-keeping use cases, but it's little more than glorified comments. What were the use cases behind this requirement again?

A lexical representation (internationalization): yes, almost

DAML+OIL ontologies may, and often do, use the rdfs:label property to supply a lexical representation of each term; e.g. from a Chimaera-JTP testing ontology:

<QueryItem rdf:ID="Correct-Cardinality-Query">
  <rdfs:label> Correct-Cardinality-Query </rdfs:label>

RDF is intended to provide internationalization of labels, but it's not clear that it does. The spec says

The xml:lang attribute may be used as defined by [XML] to associate a language with the property value.

but then it goes on to say

There is no specific data model representation for xml:lang

The RDF Core WG is tracking this issue:

unambiguous term referencing using URIs: yes

DAML+OIL leverages the existing naming context of the web, i.e. URIs for its terms. This is an extremely widely deployed convention for allocating names and associating documents with them.

Meanwhile, the simultaneous use of URIs as logical names and as keys in network protocols, and the integration of URIs with XML raises issues such as:

ability to state uniq. names: no/sorta

DAML+OIL doesn't make the unique-names assumption for URIs/logical names. On the contrary, it has explicit vocabulary for stating that two names denote the same thing (sameIndividualAs, equivalentTo).

It's possible to use cardinality constraints with string-valued properties to express things like "if x's colorName is different from y's colorName, then x != y". For details, see:

But it's not clear that (a) this is sufficiently straightforward to be acceptable to ontology designers and content authors, nor (b) that this approach addresses the computational feasability issues that usually motivate the unique-names assumption. Also, Ian suggests there may be paradoxes in this sort of solution.

uniqueness of unicode strings

DAML+OIL meets this requirement (or fails to meet it) as much as any other XML-based data format.

There some cases where two different sequences of unicode characters, say one using pre-composed form (just one c-cedilla character) and another using decomposed form (a c character followed by a cedilla accent character) that look the same and are expected, by most users, to compare equal; e.g. to match in queries. There seem to be two ways to meet user expectations:

early normalization/sender-makes-right
everybody agrees to send only the precomposed form
late normalization/receiver-makes-right
all receivers are expected to handle the differences when doing string comparisons

The W3C I18N has decided on that early uniform normalization; their specification isn't a W3C recommendation yet, but consensus is building, and it should become one any time now.

character set support: yes

DAML+OIL meets this requirement (or fails to meet it) as much as any other XML-based data format.

Internationalization is one of the core features of XML. With regard to character sets, this means:

ontology management language features (versioning): ?

DAML+OIL has a few rudimentary features relevant to ontology management:

That doesn't seem to meet the user community's requirement for ontology management, but perhaps what is lacking is documentation and methodological advice, rather than language features.

B: widely supported requirements, with some opposition

@@needs elaboration

Define range contraints on data types - Definitional contraints of conjunctive type

@@I don't remember what this means well enough to evaluate DAML+OIL against it; I'll try again when we have a draft requirements document.

Relational Types: yes?

DAML+OIL can express, e.g. "partNumber is a myOraclMapping:Property".

It also has TransitiveProperty, and can express, indirectly, SymmetricProperty.

But I understand there's some problem with ReflexiveProperty.

Class as instance: ?

I'm not sure. @@Ian? help?

Ontology mapping relations (equivalento): yes?

yes/sorta. sameIndividualAs, sameClassAs, subClassOf, subPropertyOf

ontology partitioning

sorta; daml:imports

records (complex datatypes)

not explicitly.

But Ian mentioned something about a "keys for free in description logics" paper that suggested it can be layered on top "for free".

commitment to ontologies

yes/sorta (daml:imports)

ability to state closed worlds


solution to "tagging/grouping" problem


requirements with considerable support and considerable opposition (C)

layered approach

no: DAML is all one layer.

yes: DAML is layered in RDFS (which is layered on RDF, which is layered on XML and URIs)

capability (chaining of properties, transitivity)

no (no chaining of properties)

effective decision procedure

yes?(Ian, care to elaborate?)

commitment to portions of ontologies


non-requirements (little support or overwhelming opposition) (X)

multicultural mechanism (view) - arithmetic primitives


support for speech acts

no. no explicit support, anyway.

support for variables


pre and post conditions


ability to integrate signatures

no explicit support.

no obvious problems with straightforward application of XML Signature, meanwhile.

procedural attachment


unique name assumption


bit efficient encoding


support for expressing work flow



no. (we considered something ala rdfs:label, but didn't decide to do it)