- From: Graham Klyne <GK@NineByNine.org>
- Date: Tue, 04 Feb 2003 18:30:32 +0000
- To: Frank Manola <fmanola@mitre.org>
- Cc: w3c-rdfcore-wg@w3.org
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