- 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