> -----Original Message-----
> From: James Leigh [mailto:[EMAIL PROTECTED]
> Sent: 29 July 2008 18:59
> To: Seaborne, Andy
> Cc: [email protected]; 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. [*]
http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality
> James
Andy
[*] 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.
http://www.w3.org/TR/rdf-syntax-grammar/#parseTypeLiteralPropertyElt
