W3C home > Mailing lists > Public > www-rdf-logic@w3.org > April 2001

RE: DAML+OIL (March 2001) released

From: Hart, Lewis <lhart@grci.com>
Date: Tue, 10 Apr 2001 14:33:13 -0400
Message-ID: <09A65DF294F8D311AAB000105A02DBAF026E5D27@thumper.va.grci.com>
To: Dan Connolly <connolly@w3.org>
Cc: www-rdf-logic@w3.org
"Dan Connolly" wrote:
>
>"Hart, Lewis" wrote:

>> 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>
>
>I'm not sure; I suspect it's a bug/oversight.

Well, if it is, it is very consistent throughout the spec. The latter
definition is also using daml:domain and daml:range, which is the genesis of
the question below.

>
>> Specifically,
>> 
>> 1. The semantics of rdfs:domain, which are "believed to be flawed" [1],
are
>> different that the semantics of daml:domain. So, why is rdfs:domain used?
>> Would it not, in general,  be preferred to use daml:domain in the
DAML+OIL
>> specification?
>
>I suppose we estimated that it's more cost-effective to
>get the flawed semantics of rdfs:domain fixed than to
>manage a new property.

But the new property is defined as well...

<rdf:Property rdf:ID="domain">
  <samePropertyAs
rdf:resource="http://www.w3.org/2000/01/rdf-schema#domain"/>
</rdf:Property>

... but it is never used. 

>
>> 2. The property daml:unionOf is of type rdf:Property, but has domain and
>> range of daml:Class and daml:List. How should a RDF (but not DAML) aware
>> agent deal with that?
>
>Er... in the usual way; that is: by inferring daml:Class
>as a type of any subjects of statements whose predicate is
>daml:unionOf, and by inferring daml:List as a type
>of any objects of such statements.
>
>> Or, stated another way, if we are trying to allow some
>> usability of DAML by RDF/RDFS only applications, this doesn't seem to
>> support that.
>
>How so?
>
>If you mean that we haven't expressed daml:unionOf in
>terms of RDFS, then yes, that's the case, we have not.
>That seems impossible to do, no?

Yes, this is what I meant. In one of the other threads, I believe that the
point was raised that a less-expressive system could have trouble using
information from a more-expressive one. My point is -- if an RDF(S) system
could be corrupted by the combination of RDF(S) and DAML, then a delineation
should be made between the two. This is what I thought the purpose of the
samePropertyAs/sameClassAs definitions where initially, but I now see that
the DAML terms are not used consistently within the spec. (e.g. daml:domain)


What I am looking for is a nice DAML definition on top of RDF/RDFS (think
layer cake), but what I am seeing is conflation of RDF/RDFS/DAML (think
bread pudding). Once RDF/RDFS terms have been defined to be samePropertyAs
or sameClassAs a DAML term, I would expect to see the DAML term used in the
DAML specification, as in my example of unionOf above.  This would provide a
much cleaner definition, and it would isolate DAML from changes (or lack
there of) in RDF and RDFS. 

- Lewis

>> Thanks. - Lewis
>> 
>> [1] http://www.daml.org/2001/03/reference.html#domain-def
>> 
>
>-- 
>Dan Connolly, W3C http://www.w3.org/People/Connolly/
>
Received on Tuesday, 10 April 2001 14:33:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:38 GMT