Re: Understanding datatypes in RDF 1.1 - was various things

(and now, press "send" not "save")

On 02/12/13 12:35, Hugh Glaser wrote:
> Hmm,
> My head is spinning a bit now - I’m trying to understand something simple - "1"^^xsd:boolean.
>
> So my reading says that is a valid lexical form (in the lexical space) for the value ’true’ (in the value space).
> (http://www.w3.org/TR/rdf11-concepts/#dfn-lexical-space )
> I think that ‘value space’ is where the other documents talk about 'RDF term’, but I’m not sure.

"RDF Term" covers IRI, blank Node or Literal.  So it's on the (abstract) 
syntax side, not the value side.

>
> And I also I read:
> "Literal term equality: Two literals are term-equal (the same RDF literal) if and only if the two lexical forms, the two datatype IRIs, and the two language tags (if any) compare equal, character by character.”
> (http://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal )

Literal term equality = compare the three parts of a literal - lexical 
form, datatype and language tag.  Lang tags are lower case (yes, that's 
different to the RFC :-().

>
> So the language processor will (must) take my lexical form
> "1"^^xsd:boolean
> and make it an RDF term
> “true"

It may do, probably doesn't - but there is no requirement to work in 
"values" at all.

> And then if I ask the store (sorry, I am rather engineering in this) if 2 terms are equal, it will always be comparing two similar terms (from the literal space), (probably, but see below):
> “true"^^xsd:boolean
>
> And I can expect a sensible querying engine to consider
> "1"^^xsd:boolean
> as a shorthand for
> “true"

Definitely in a SPARQL FILTER, for "=", etc which are value based 
comparisons, not for sameTerm(...).

SPARQL graph pattern matches has to follow RDF (with or with D-entailment).

> It could be confusing, which it was for a bit for me, because the equality constraint says "the two lexical forms”, but in this case there is more than one lexical from for the value form.
> So I think it means that a processor must always choose the same lexical form for any given value form.

It could, but not required.  The loading of the data might canonicalize 
the RDF terms.  Then comparing terms and comparing values is quite 
similar. thats outside SPARQL Query.

Still not the same though:

"1"^^xsd:integer = "1"^^xsd:double

but the rules of XSD arithmetic mean you can't easily drop the type 
distinction.

xsd:long + integer -> integer
integer + double -> double

xsd:doubles are not xsd:decimals.  Sometimes the loss of precision is 
unacceptable (insert finance example).

Whether loosing the original datatype and/or exact way the literal was 
written may sometimes matter to the app.

> I am guessing that processors could consistently choose
> "1"^^xsd:boolean
> as the value form for
> “true"
> but that would be pretty perverse.
>
> A little further confusion for me arises as to whether the datatype IRI is part of the value space.
> I have taken off any ^^xsd:boolean from my rendering of the “true” in the value space because the documentation seems to leave it out.
> (The table says: '<“true”, xsd:boolean>’ and ‘true’ are the literal and value.)
> So I am left assuming that the datatype IRI is somewhere in the RDF term world, although we know it isn’t in the graph.
> Not something I need to worry about as a consumer, as it is all an internal issue, I think, but I thought I would mention it.
>
> Best
> Hugh
>

	Andy

Received on Friday, 6 December 2013 15:33:45 UTC