DAML+OIL Layer 1

From: Stefan Decker (stefan@db.stanford.edu)
Date: 05/15/01


Dear all,

please find attached a first draft of the layer proposal with some
suggestions for changes.
I apologize for the late notice - I hope it will be still possible to
discuss some of the language features and proposed changes,
and to point out mistakes or wrong assumptions.

Thanks and all the best,

	Stefan



DAML+OIL Layer 1



1.0 Introduction
----------------

DAML+OIL has its roots in description logic. Description logics developed
were developed originally from as a formalization of frame based systems. 
Modeling
languages like UML or Entity Relationship models are quite popular (also for
ontology engineering tasks). However, it is not easy
to see how current DAML+OIL relates to traditional frame-like modeling 
languages
like UML, 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 computational
  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.
Then language users and tool vendors are able to publish
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 engines.

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

    * allows to define simple ontologies
    * enables checking of integrity constraints for instances
    * can be deployed in large scale applications (> 100k concepts)
    * can be deployed by average programmers
**************************************************************

Checking ontologies for inconsistencies (and thus providing the expressive
power to create inconsistencies) is not our primary concern.

2.0 Layers
----------

2.1 DAML+OIL:  Level 0 Language
------------------------------


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


2.1 DAML+OIL: Level 1
---------------------

a) Class Elements
  contains:
     rdfs:subClassOf
       value: simple Class and simplified Property Restrictions

     daml:sameClassAs
       value: simple Class

     daml:equivalent
       value: simple Class

     zero or more enumeration elements.


b)   Property Restrictions
         daml:Restriction
            daml:toClass  (with just a simple class as value)
            daml:hasValue
            daml:hasClass (with just a simple class as value)
            daml:cardinality
            daml:maxCardinality
            daml:minCardinality
            daml:cardinalityQ (with just a simple class as qualifier)
            daml:maxCardinalityQ (with just a simple class as qualifiers
            daml:minCardinalityQ


c)   Property elements
	rdf:Property
	   rdfs:subPropertyOf (note that the handling of subPropertyOf also 
requires some
                 reasoning. For compatibility purposes it seems appropriate 
to have subProperties
                 in Layer 1.
	rdfs:domain (simple class as value)
	rdfs:range (simple class as value)
         daml:samePropertyAs
         daml:equivalentTo
         daml:inverseOf (also inverse requires some reasoning. However, 
daml:inverseOf
                 seems to be to useful to be left out)
         daml:TransitiveProperty
         daml:UniqueProperty (can be used as integrity constraints)
         daml:UnambigousProperty  (to be used as integrity constraints)


d)   Instances
         daml:sameIndividualAs
         daml:equivalentTo
         daml:differentIndividualFrom (but see Proposed Changes)


3 Removals from DAML+OIL Layer 1
--------------------------------
    Complex Class Expressions
    Axioms ( Disjoint Declarations)


4 Proposed Changes
------------------

Unique Name Assumption
----------------------
The unique name assumption is often quite useful when dealing with
large datasets. Since this will be the usual usecase of DAML+OIL Level 1,
I would propose to make the unique name assumption the default case.
Equivalences are usually the exception.
Not adopting the unique name assumption as the default case would
result in an large amount of daml:differentIndividualFrom statements.


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 of a naive understanding what
restrictions are, but not how it relates to subClasses.



Complex Datatypes
-----------------
Complex XML-Schema Datatypes currently don't have a RDF graph representation.
This requires more complex processing, storage and query software.
Complex Datatypes should be given a graph representation.


Cardinality
-----------
Since daml:cardinality is really superflous and a possible source of
confusion and inconsistencies, it should is discarded from level 1.


Languages Header
----------------

An an example for an ontology header look at the following definition:

<Ontology rdf:about="">
   <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"/>
</Ontology>

The namespace of the current document is treated as an object on its own,
but is otherwise unrelated to the defined classes and properties in this 
ontology.
Another approach is to explicitly create an ontology object, which acts as 
an container
object for the defined properties, classes and axioms.
Using the container approach it is easy detectable, which classes belong to 
which ontology.
This treatment is necessary, since applications don't talk about documents 
any more
(like they would in the XML world). Instead applications talk about RDF models
(= sets of statements). A common way to operate with sets of statements are 
set
theoretic operations (union, difference, etc). So it is possible to compute 
the
union of two RDF models representing two different ontologies, which 
results in another
RDF model. where it is not possible to distinguish the ontologies without 
an explicit
analysis of the namespaces of the classes.


This archive was generated by hypermail 2.1.4 : 04/02/02 EST