- From: Hart, Lewis <lhart@grci.com>
- Date: Tue, 10 Apr 2001 14:33:13 -0400
- 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 UTC