- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Wed, 6 Sep 2006 12:05:44 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
http://www.w3.org/2001/sw/DataAccess/issues#nonliteralValueTesting
There are two parts.
ILLFORMED LITERAL TESTING
I think this pretty much has rough consenus. Illformed literals
should return errors in a variety of value testing situations, e.g.,
"abc"^xsd:integer< 1
One corner case might be DATATYPE, since, semanticaly *I think*, ill
formed literals don't have a (knowable) type. But it is true that in
a real sense they don't have the type that their literal form
indicates. So if Datatype just means "extract the datatype field of
the typed literal form" then it's fine for
DATATYPE("-5"^^xsd:positiveInteger) = xsd:positiveInteger
(This seems to be what the current spec says. It's quite justifiable
as a function on the syntax.)
But I think it's justifiable that:
DATATYPE("-5"^^xsd:positiveInteger)
is an error. The value denoted by the literal is not a positive integer.
I believe isLiteral("-5"^^xsd:positiveInteger) will return true (it
is a literal, just not well formed).
We do need a section in the text making this clear and amending the
definition of datatype if we change it.
==========
NON LITERAL VALUE testing
Under RDF and D entailment, non literal forms might denote data
values. For example, given:
:x rdf:type rdf:XMLLiteral
It is the case that:
isURI(:x) = true
and
isLiteral(:x) = false
But that :x denotes a data value (we don't know which one).
Of course, we have no functions on XMLLiterals, but we do have integers:
:x rdf:type xsd;positiveInteger.
:y rdf:type xsd:negativeInteger.
:z :p :y.
isURI(:x) = true
isURI(:y) = true
isURI(:z) = true
isLiteral(:x) = false
isLiteral(:y) = false
isLiteral(:z) = false
-2< :z = error
-2 < :x =?? error? or true (it's true semantically)
-2 < :y = ?? error? we don't know! :y could be -1 (note we don't
have unknowns for value testing, only errors)
So, we could
1) Restrict value testing to data values with literal form
(I think this is the implicit understanding)
2) Allow value testing to test non literal data values
(Implementation wise, this would require preserving the type of URIs
and BNodes in internal tables, at least; there's no syntax to pass
that into result sets).
Consider also DATATYPE(:x).
If the group decides 1, then some text, probably in:
http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#tests
to the effect that that the value testing is restricted to data
values with literal forms is required. We should add variants of the
above examples as test cases (with the right resolutions).
If the group decides on 2, then I will happily produce a proposal
that covers the various cases. I'm pretty sure it's straight forward,
but examples like -2 < :y show that we need to be a bit careful.
Cheers,
Bijan.
Received on Wednesday, 6 September 2006 11:12:35 UTC