W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2006

[TO SETTLE] nonliteralValueTesting

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 6 Sep 2006 12:05:44 +0100
Message-Id: <350952B9-4CAA-46FB-8E75-EDB675C93212@cs.man.ac.uk>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>


There are two parts.


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:
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.


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

	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:

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.

Received on Wednesday, 6 September 2006 11:12:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:51 UTC