(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
