W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: Oh my GOD, another datatype document.

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 6 Feb 2002 17:59:23 -0600
Message-Id: <p0510144bb887732ab4d9@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-02-06 18:04, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:
>>>  My question is about the lack of an explicit triple giving the dType, this
>>>  was one of my problem cases in the TDL model theory.
>>  The whole point of the 'ranging' semantic condition is to allow
>>  <range> info to entail <dtype> info, so that if the 'local' idiom
>>  works then the 'global' one will as well (though you have to do some
>>  extra inference, of course). It works for all the cases that use
>>  bnodes, but it doesn't work very well for the inline-literal case.
>>  Thats also why one needs to use a separate namespace (or some
>>  equivalent trick) to stop having too many possible leaks from
>>  rdfs:range to rdf:type. If we only used local typing there wouldnt be
>>  any real need for that.
>>  Pat
>If we went with the revised global idiom that is a derivative
>of the local idiom with rdf:type optional, but with the bNode
>    Bob ex:age _:1 .
>    _:1 rdf:value "30" .
>Then can we also get away with rdf:type rather than rdf:dtype?

NOt sure I follow which revised global you are referring to 
(pointer??), but I doubt it. Seems to me that there really isn't ANY 
way to use 'normal' rdfs reasoning to connect rdfs:range with 
rdf:type that can possibly be a safe way to do datatyping, and still 
have the bnodes denote values.

>If so, then I think that's another point in favor of the
>convergence proposal, since we don't have to add any new
>vocabulary to RDF at all.

If it can be done it would certainly be a plus. I don't see how, though.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 6 February 2002 18:58:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:09 UTC