May 28 2001

1.0 Introduction

DAML+OIL has its roots in description logic, which originally developed as a formalization of frame based systems. However, it is not easy to see how current popular modeling languages like UML or Entity Relationship relate to DAML+OIL, and support for the full DAML+OIL language requires a full fledged description logic inference engine. It seems unlikely that every application will use a Description Logic Engine. Furthermore large scale applications (100k classes and more) require simple inference mechanisms. Thus large scale application needs to built upon software which is not able to support the complete DAML+OIL language.

To avoid fragmentation and facilitate exchange of ontologies the definition of several layer of DAML+OIL seems worthwhile. Language users and tool vendors are able to specify their level of compliance with the full DAML+OIL specification.

In this paper we propose language features which can be supported within large-scale ontology-based applications without using an inference engine.

1.0 Classification or Constraint Checking?

An important use for schemata is to check instance data for compliance with the schema. However, within the description logic framework the focus is on classification of class definitions and instance data, not to check instance data for compliance with the schema.

Goal of this style guide is to provide a useful language, which

Checking ontologies for inconsistencies (and thus providing the expressive power to create inconsistencies) is not our primary concern. Rather we use an extensional interpretation of classes and check the instances of the classes for inconsistencies.

Notation: With rules we mean horn rules plus well founded negation. A domain independent full first order logic formula is a formula where the domain of interpretation can be changed without changing the truth value of forumula (as long as the interpretation of constants, functions and predicates are not changed). A non domain independent formula: EXISTS X not p(X)). An integrity constraint is a domain independent full first order logic formula. The comp-operator is the completion operator known from logic programming, which completes <- to <->. We note a RDF triple syntactically as subject[predicate->object].

Def.: Let D be a set of triples and rules operating on the triples. Let IC be a set of integrity constraints. D fulfills IC iff comp(D) |= IC.

Given an DAML+OIL ontology the next step is to identify the set of rules and integrity constraints, that a DAML+OIL ontoloy has to fulfill. So we divide a DAML+OIL ontology into two subsets of formulas: one subset is interpreted as deduction rules, the other subset is interpreted as integrity constraints, specifying requirements for a corresponding set of instance data. Please note that for efficiency reasons checking of IC is unlikely to be done by a general purpose inference engine. Instead it is assumed that specialized procedures will perform the checking.

2.0 Layers

2.1 DAML+OIL: Level 0

DAML+OIL is essential identical to RDF Schema ( with the semantic clarification and restrictions that DAML+OIL defined).

2.2 DAML+OIL: Level 1

DAML+OIL Level 1 focuses primarily on the enabling of integrity constraint checking. The language allows the definition of constraints, but does not regard them as a means to do classification. Therefore we focus on the semantics for constraint checking, not for classification.
Named classes are classes identified by a URI.

2.2 DAML+OIL: Level 2

Level 2 is identical to the existing DAML+OIL language.

3.0 Removals from DAML+OIL Layer 1

Complex Class Expressions

Axioms ( Disjoint Declarations)

4 Proposed Changes

Unique Name Assumption

Problem description:

The unique name assumption is often quite useful when dealing with large datasets, since usually different name identify different entities (e.g. in catalogs). Therefore it would be often useful to make the unique name assumption the default case and equivalences should be stated as an exception. Not adopting the unique name assumption as the default case requires a large amount of daml:differentIndividualFrom statements.

Proposed Solution:

Dan Conolly suggested to use the daml:UniqueProperty element together with the fact, that literals are unique.
@@@ Does this also work for classes?
Two instances with a unique property (e.g. a label), which have different literals as values, need to be different.

<rdf:Description rdf:about="http://www.w3.org/2001/04dun/colors#colorName">
   <rdf:type rdf:resource="http://www.daml.org/2001/03/daml+oil#UniqueProperty"/> 
   <rdfs:domain rdf:resource="http://www.w3.org/2001/04dun/colors#Color"/> 
   <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#label"/> 

<rdf:Description rdf:about="http://www.w3.org/2001/04dun/colors#green">
  <rdf:type rdf:resource="http://www.w3.org/2001/04dun/colors#Color"/> 
</rdf:Description> <rdf:Description rdf:about="http://www.w3.org/2001/04dun/colors#orange"> <rdf:type rdf:resource="http://www.w3.org/2001/04dun/colors#Color"/>

Property Restrictions

Viewing Property Restrictions as class expressions is a unusual viewpoint for people used to object oriented or frame based modeling. The was also a major point of critique to DAML+OIL. The reference description says: "Notice that the restrictedBy element which was associated with slot-restrictions in earlier versions of the language has now been removed, since it is completely synonymous with subClassOf."

While this might be true, users of OO language have a naive understanding what restrictions are, but not how it relates to subclasses.

Therefore the restrictedBy element is reintroduced into the language.

Complex Datatypes

Complex XML-Schema Datatypes currently don't have a RDF graph representation. This requires complex processing, storage and query software. If complex datatypes have a graph representation, then the existing RDF infrastructure is able to process and query datastructure definitions.

Languages Header

Problem description:
The ontology header defines a node of type ontology. This node is unrelated (in the RDF model) to the classes defined in that ontology - so a posing the query "Retrieve all classes defined in that ontology" (and similar queries) is not possible by just querying the RDF graph.

Proposed Solution:
Dan Connolly suggested to use property "rdfs:isDefinedBy" to indicate the ontology in which classes or properties are defined.


<Ontology rdf:about="http://www.daml.org/2001/03/daml+oil-ex.daml">
   <versionInfo>$Id: reference.html,v 1.10 2001/04/11 16:27:53 mdean Exp    $</versionInfo>
   <rdfs:comment>An example ontology</rdfs:comment>
   <imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/>

<daml:Class rdf:ID="Animal">
<rdfs:label>Animal</rdfs:label> <rdfs:definedBy rdf:resource="http://www.daml.org/2001/03/daml+oil-ex.daml"/>
This class of animals is illustrative of a number of ontological idioms.