Re: response to semantics comment pfps-01

I have some hope that in the next few weeks I'll have a running code 
example of *one way* to bind a formal datatype definition (not in RDF) into 
an RDF processor.  So far, I see no problem.

#g
--

At 09:10 AM 2/4/03 -0500, Frank Manola wrote:

>Guys--
>
>This seems like something we could clarify a bit.  On the one hand, we 
>have some "explicit characteristics" (to use Patrick's term) we define for 
>datatypes to be considered instances of rdfs:Datatype, and which these 
>datatypes don't (entirely) possess.  On the other hand, we seem to say 
>that any of these datatypes need to be processed by "datatype-aware" 
>processors that grok both RDF and the datatypes in question, and are 
>capable of doing useful things with them (consistent with the semantics of 
>the datatypes).  Now, presumably XML Schema processors can do useful 
>things with those datatypes, so it must be possible to build other 
>processors to handle those datatypes in appropriate ways, whether they 
>satisfy the characteristics we've identified for rdfs:Datatypes or 
>not.    So, given that we, in effect, "hand off" processing the datatypes 
>to separate processors that are suppoed to be fully capable of handling 
>them (whatever their definitional defects as far as RDF is concerned), 
>what is the problem?  I'm not denying that there may *be* a problem, but 
>it seems to me could clarify this some.  This would seem to be of 
>particular interest to people who are interested in using RDF together 
>with datatypes *other* than XML Schema datatypes, that aren't defined 
>according to its abstract framework (which we claim they can do).
>
>--Frank
>
>Patrick.Stickler@nokia.com wrote:
>
>>
>>     -----Original Message-----
>>     From: ext pat hayes [mailto:phayes@ai.uwf.edu]
>>     Sent: 04 February, 2003 00:51
>>     To: w3c-rdfcore-wg@w3.org
>>     Subject: response to semantics comment pfps-01
>>     Some XML Schema primitive datatypes are impossible to use as RDF
>>     datatypes.  Therefore XSD intepretations are ill-defined.
>>     The problematic datatypes include:
>>     duration - because equality in its value space is not well defined
>>     QName - because there is no fixed lexical-to-value mapping
>>     ENTITY - because there is no fixed value space
>>     NOTATION - because there is no fixed lexical space
>>     ----
>>
>>     I don't consider these to be fatal problems which make it
>>     'impossible' to use these datatypes.
>>
>>I'm not particularly confortable with that statement. RDF Datatyping is 
>>based on explicit characteristics
>>which should be embodied by each and every member of rdfs:Datatype. If 
>>some XML Schema datatype
>>fails to have any of those characteristics, then they are not valid 
>>instances of rdfs:Datatype and I
>>would expect not usable with RDF. I.e., I would consider those to be 
>>fatal problems.
>>
>>To use a datatype with RDF, i.e. to specify it as the value of the 
>>attribute rdf:datatype is to assert that
>>it is a member of rdfs:Datatype. And to assert that a datatype is a 
>>member of rdfs:Datatype is to
>>assert that it has a value space, a lexical space, and an N:1 mapping 
>>from lexical to value space
>>where N >= 1.
>>
>>Thus rdf:datatype="&xsd;ENTITY" would be an error, if so asserted, as it 
>>in fact has no fixed value
>>space, etc.
>>
>>
>>      What is true however is that these are examples of
>>     *underdetermined* datatypes, ie datatypes about which the available
>>     information is incomplete in some way.
>>
>>My hope is that it is the specs which are incomplete and that the XML 
>>Schema WG could clarify the definitions
>>of these datatypes in a manner that would allow them to be treated as 
>>valid members of rdfs:Datatype.
>>
>>     For example, the set of durations is underdetermined; what this
>>     means is that *any* set which conforms to the XSD spec will suffice
>>     as a value space of xsd:duration, and there may be more than one
>>     such set. There may therefore be more XSD interpretations than the
>>     XML authors intended. As usual in such situations, the effect on
>>     inference is that some inferences simply cannot be made, eg it is
>>     simply unknown whether or not one xsd:duration literal can be
>>     substituted for another, so to this extent the corresponding
>>     inference rule does not apply. The text makes it clear that these
>>     rules apply only in cases where certain kinds of information are
>>     provided by the datatype information source.
>>
>>     In sum, I don't think there is any need to do anything about this
>>     issue, except possibly to add some explanatory prose to clarify the
>>     point.
>>
>>
>>Explanations, yes, but let's be careful about exactly what we're saying.
>>
>>Cheers,
>>
>>Patrick
>>
>>     Pat
>>
>>--
>>     ---------------------------------------------------------------------
>>     IHMC                                       (850)434 8903 or (650)494
>>     3973   home
>>     40 South Alcaniz St.                       (850)202 4416   office
>>     Pensacola                                 (850)202 4440   fax
>>     FL 32501                                     (850)291 0667    cell
>>     phayes@ai.uwf.edu            http://www.coginst.uwf.edu/~phayes
>>     s.pam@ai.uwf.edu   for spam
>
>
>--
>Frank Manola                   The MITRE Corporation
>202 Burlington Road, MS A345   Bedford, MA 01730-1420
>mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 4 February 2003 14:20:50 UTC