W3C home > Mailing lists > Public > public-sparql-dev@w3.org > July to September 2008

RE: Mulgara and sameTerm

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 30 Jul 2008 08:22:07 +0000
To: James Leigh <james-nospam@leighnet.ca>
CC: "public-sparql-dev@w3.org" <public-sparql-dev@w3.org>, Arjohn Kampman <arjohn@aduna-software.com>, Andrae Muys <andrae@netymon.com>, Paul Gearon <gearon@ieee.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA345D535097F@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: James Leigh [mailto:james-nospam@leighnet.ca]
> Sent: 29 July 2008 18:59
> To: Seaborne, Andy
> Cc: public-sparql-dev@w3.org; Arjohn Kampman; Andrae Muys; Paul Gearon
> Subject: RE: Mulgara and sameTerm
> Thanks Andy,
> As I understand this: adding triples is out side the scope of SPARQL and
> an RDF store can add triples as-is or do add just about anything instead
> and still be SPARQL compliant.

Yes, from SPARQL's point of view when the dataset comes from the execution context.

> I just want to clarify a point on sameTerm.
> On Tue, 2008-07-29 at 16:33 +0000, Seaborne, Andy wrote:
> > sameTerm works on the definition of equality from RDF Concepts so no
> > D-entailment. [B]  But SPARQL does not prescribe what is "in" the
> > store - there is dataset that is queried.  Especially in the case
> > where the dataset comes from execution context (no FROM etc, no
> > protocol parameter), SPARQL says nothing about how that dataset came
> > to be.  It just is.  So if you load RDF that has "+1"^^xsd:int,
> > whether the store preserves the exact lexical form, or it's datatype,
> > is a feature of the store.  SPARQL does not cover this step.  If you
> > load "+1"^^xsd:integer and "01"^^xsd:byte, it's a store decision
> > whether there are two terms or one, or whether what is stored and
> > returned is "1"^^xsd:integer which wasn't directly mentioned (or even
> > "1"^^xsd:decimal as the primitive XSD type that they are all derived
> > from).
> Lets say an RDF store chooses to "translate" certain RDF terms on insert
> into others. Like "+1"^^xsd:int is always inserted as "1"^^xsd:int. Can
> the same translation be done to query bindings?
> Does SPARQL specify an exact response to the filter
> 'sameTerm("1"^^xsd:int, "+1"^^xsd:int)'?

SPARQL does specify that - it evaluates to false.

sameTerm(?x , ?y)

where ?x is returned as "1"^^xsd:int and ?y returned as "+1"^^xsd:int is false as well.  Once query solutions get terms bound to variables, they stay bound as terms not values.  I don't see how any sameTerm can do anything else - it acts on
on the components of the literal of (lexical form, datatype, language tag) because that is the definition of equality from RDF concepts which does not operate on the value space. [*]


> James


[*] rdf:XMLLiteral excepted everywhere.  Their lexical forms are canonicalized which presumably is sorted out by the RDF/XML parser.  Nothing to do with the datatype lexical to value space mapping nor D-entailment.  And not optional.


Received on Wednesday, 30 July 2008 08:23:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:50 UTC