W3C home > Mailing lists > Public > public-awwsw@w3.org > March 2008

Re: plain literals without language tag compare xsd:string in RDF

From: Sandro Hawke <sandro@w3.org>
Date: Mon, 10 Mar 2008 14:56:32 -0400
To: Alan Ruttenberg <alanruttenberg@gmail.com>
Cc: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, Pat Hayes <phayes@ihmc.us>, public-awwsw@w3.org, "Carroll, Jeremy John" <jeremy.carroll@hp.com>
Message-ID: <20911.1205175392@ubuhebe>


[sorry for the second copy for some of you; my first transmission was
pulverized by the merciless gears of lists.w3.org.]

> > xsd 1a:  uuu aaa "sss" => uuu aaa "sss"^^xsd:string .
> > xsd 1b:  uuu aaa "sss"^^xsd:string => uuu aaa "sss".
> > Again, as with the rules rdfD2 and rdfD3, applications may use a  
> > systematic replacement of one of these equivalent forms for the  
> > other rather than apply these rules directly.

> 
> Regrettably, SPARQL uses the RDFS syntactic equality in its  
> definition of equality for literals :(

I have only a tentative grasp on this, but my understanding is that, as
you say, in SPARQL, "1"^^xs:int, "01"^^xs:int, and "001"xs:int are three
different things.  None of them are equal to each other.

This makes sense only with the understanding that, in practice, one is
expected to use SPARQL along with some entailment regime.  It is the job
of that regime, not SPARQL, to make 01 == 001.

It's easy to see it as a failing of the Semantic Web architecture that
it provides no way to communicate the intended entailment regime.  

However, if all entailment regimes are in some sense compatible
(properly layered), then I think the problem of communicating intended
entailment regimes is equivalent to the problem of communicating
intented related data-sources/imports.  That is, one can imagine
entailment regimes as rulesets which can imported or merged just like
other data.  So in that sense, whether 01 == 001 in sparql depends on
the dataset you are querying.  It's an elegant idea that would be nice
to see seriously deployed.  (cwm does some of this with the "-a" flag,
but I'm not aware of any real applications using it.)

> I wonder what RIF is planning to do

As I understand it (which is not all that well), RIF equality is in the
semantic domain, so "1"^^xs:int == "01"^^xs:int, etc.  I should make
this a test case to be sure.

Our current drafts equate RDF plain literals (without a language tag) to
xs:strings.  For plain literals with language tags, we made up a new
data type, rif:text, which includes a language tag.  In RIF, literals
are all data-typed literals.  For details, see [1]

I hope that helps.

     -- Sandro  (RIF-WG and OWL-WG staff contact)

[1] http://www.w3.org/2005/rules/wiki/SWC#RDF_Compatibility

> All right, I see (RDF-MT) :
> > These rules may not provide a complete set of inference principles  
> > for D-entailment, since there may be valid D-entailments for  
> > particular datatypes which depend on idiosyncratic properties of  
> > the particular datatypes, such as the size of the value space (e.g.  
> > xsd:boolean has only two elements, so anything established for  
> > those two values must be true for all literals with this datatype.)  
> > In particular, the value space and lexical-to-value mapping of the  
> > XSD datatype xsd:string sanctions the identification of typed  
> > literals with plain literals without language tags for all  
> > character strings which are in the lexical space of the datatype,  
> > since both of them denote the Unicode character string which is  
> > displayed in the literal; so the following inference rule is valid  
> > in all XSD-interpretations. Here, 'sss' indicates any RDF string in  
> > the lexical space of xsd:string.
> >
> > xsd 1a:  uuu aaa "sss" => uuu aaa "sss"^^xsd:string .
> > xsd 1b:  uuu aaa "sss"^^xsd:string => uuu aaa "sss".
> > Again, as with the rules rdfD2 and rdfD3, applications may use a  
> > systematic replacement of one of these equivalent forms for the  
> > other rather than apply these rules directly.
> >
> >
> 
> Regrettably, SPARQL uses the RDFS syntactic equality in its  
> definition of equality for literals :(
> 
> I wonder what RIF is planning to do
> 
> -Alan
> 
> 
> 
> 
> On Mar 7, 2008, at 10:31 AM, Williams, Stuart (HP Labs, Bristol) wrote:
> 
> > Alan,
> >
> > I raised you question with my colleague, Jeremy Carrol (Cc'd) who  
> > responded as follows:
> >
> > <quote>
> > They are identical
> >
> > "foo" owl:sameAs "foo"^^xsd:string .
> >
> > is necessarily true.
> >
> > http://www.w3.org/2000/10/rdf-tests/rdfcore/datatypes/test011a.nt
> > entails
> > http://www.w3.org/2000/10/rdf-tests/rdfcore/datatypes/test011b.nt
> > as recorded in the RDF Test Cases doc
> >
> > Jeremy
> > </quote>
> >
> > In a further exchange he also confirmed/clarified that it is  
> > neccessarily the case that:
> >
> >         "1234" owl:sameAs "1234"^^xsd:string .
> >
> > ie. (I think) that means that:
> >
> >         "1234" owl:sameAs "1234"^^xsd:integer .  ## or some other  
> > numeric datatype.
> >
> > is necessarily false (which is what I would expect).
> >
> > Cheers,
> >
> > Stuart
> > --
> > Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
> > Berks RG12 1HN
> > Registered No: 690597 England
> >
> >
> >> -----Original Message-----
> >> From: public-awwsw-request@w3.org
> >> [mailto:public-awwsw-request@w3.org] On Behalf Of Alan Ruttenberg
> >> Sent: 04 March 2008 15:29
> >> To: Pat Hayes
> >> Cc: public-awwsw@w3.org
> >> Subject: plain literals without language tag compare xsd:string in  
> >> RDF
> >>
> >>
> >> Is there any utility to having these being disjoint classes?
> >> It would seem to me that it would be more sensible to say
> >> that any string that doesn't have a  language type or a
> >> datatype is inferred to be of type xsd:string.
> >>
> >> Did this situation come about because it was easier to make
> >> the RDF semantics look cleaner, or was there some principled
> >> reason for making the distinction?
> >>
> >> -Alan
> >>
> >>
> >>
Received on Monday, 10 March 2008 18:56:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 July 2008 07:55:27 GMT