RE: DAML+OIL (March 2001) released

From: Peter F. Patel-Schneider [pfps@research.bell-labs.com]

>From: "Hart, Lewis" <lhart@grci.com>
>Subject: RE: DAML+OIL (March 2001) released
>Date: Tue, 10 Apr 2001 11:11:28 -0400
>
>> Some examples of questions I have are: 
>> 
>> Consider this partial definition from the latest spec...
>> 
>> <rdf:Property rdf:ID="unionOf">
>>   ... omitted ...
>>   <rdfs:domain rdf:resource="#Class"/>
>>   <rdfs:range rdf:resource="#List"/>
>> </rdf:Property>
>> 
>> Why is it not defined like this:
>> 
>> <ObjectProperty rdf:ID="unionOf">
>>   ... omitted ...
>>   <domain rdf:resource="#Class"/>
>>   <range rdf:resource="#List"/>
>> </ObjectProperty>
>
>The main reason, in my mind, at least, would be that ObjectProperty should
>be used for properties in a particular theory (or KB, or whatever you want
>to call it).  unionOf is an interpreted property (for DAML+OIL), with a
>specific meaning for DAML+OIL (i.e., it is part of the theory of DAML+OIL,
>and thus part of the meta-theory).  I don't think that there is any
>indication in the DAML+OIL documents that this distinction should be made,
>but perhaps it should.

I do not see why the distinction is needed.  daml:unionOf is still an
interpreted property even if it is defined as a daml:ObjectProperty. It is
still part of the meta-theory, as are all of definitions in the "daml+oil"
namespace and ontology. The principle difference is a DAML-aware agent would
"know" that unionOf is a property that relates DAML objects and that it may
have different semantics than a rdf:Property. By making the most specific
definition possible, the most information can be conveyed.

(I now assume then that the definition some properties as daml:Properties
(e.g. equivalentTo, sameClassAs...) is an oversight, and they should also be
rdf:Properties. If this is not a correct assumption, could someone explain
the rational for the difference. Thanks.)

I think there is also an element of good design here. If the objective of
DAML is to be the next generation of, or an enhancement to, RDFS then it
makes sense design-wise to couple DAML closely with RDF/RDFS. Any agent that
use DAML will need to know quite a bit about RDF/RDFS as well. In this case,
it also becomes less desirable to define fundamental DAML elements that are
the same as RDF/RDFS elements, for example Property and Class.

If however, DAML is to be built from RDF/RDFS as the next meta-level, then
the use of RDF/RDFS in the DAML definition should be minimized. This gets
back to my layer cake vs bread pudding comparison. Let me take a shot at a
layer cake:


[ Things that use DAML, but don't need to  ] 
[ know much about RDF(S)                   ]
 ------------------------------------------ 
[ DAML definitions in DAML not using RDF(S)]
              [ DAML defined in RDF(S)     ]
[ DAML sameAs RDF(S)  ]
 ------------------------------------------
[ RDF and RDFS                             ]
 ------------------------------------------ 
[ XML and things below...                  ]


The top layer could use RDF/RDFS if it had need to, it would not be required
to use it to understand DAML. I would prefer to see this layered approach.

- Lewis
>
>
>
>Peter Patel-Schneider
>Bell Labs Research
>
>PS:  Thanks for the questions!
>
PS Thanks for the answers!

Received on Thursday, 12 April 2001 09:28:12 UTC