RE: response to semantics comment pfps-01

OK, how about this. RDF can't say whether a datatype that
is asserted as a member of rdfs:Datatype does or does not
conform to the minimal characteristics of all instances
of rdfs:Datatype, no more than it can know explicitly what
the L2V mapping is, etc. of a given datatype.

It is syntactically correct to say rdf:datatype="&xsd;ENTITY"
and only a datatype aware processor that recognizes the
(possibly non-RDF-valid) datatype xsd:ENTITY can say if it
is or is not RDF-valid, and if not, that processor may choose
to issue a warning or error, but may still do something
useful.

I.e., I don't want to preclude folks from doing it, but I
want it to be clear that it is in some key ways wrong,
because of the nature of the datatype in question.

Just as we define some test cases where we say that

   _:x _:y "10"^^xsd:int .

XSD entails 

   _:x _:y "010"^^xsd:int .

but does not XSD entail

   _:x _:y "0005"^^xsd:int .

even though RDF/S alone says and knows nothing about
XSD semantics, so too we should be able to say that

   "xyz"^^xsd:ENTITY 

is in certain ways wrong, erroneous, false, whatever
based on the same source of knowledge that allows us
to assert the above entailment and non-entailment.

And the reason why those key characteristics of rdfs:Datatype
are important is that they insure against ambiguity. For
any datatype ddd which is in rdfs:Datatype, it is assumed
that for a lexical form lll, that "lll"^^ddd will always
denote one and only one resource. Datatypes that fail to
conform to the characteristics of rdfs:Datatype may very
well allow "lll"^^ddd to denote multiple resources, which
breaks the very foundation of RDF. 

Patrick


> -----Original Message-----
> From: ext Frank Manola [mailto:fmanola@mitre.org]
> Sent: 04 February, 2003 16:10
> To: Stickler Patrick (NMP/Tampere)
> Cc: phayes@ai.uwf.edu; w3c-rdfcore-wg@w3.org
> Subject: Re: response to semantics comment pfps-01
> 
> 
> 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
> 
> 
>

Received on Tuesday, 4 February 2003 09:21:19 UTC