- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 30 Oct 2002 10:25:58 +0300
- To: "RDF core WG" <w3c-rdfcore-wg@w3.org>, "ext Graham Klyne" <GK@NineByNine.org>, Patrick Stickler <patrick.stickler@nokia.com>
_____________Original message ____________
Subject: Datatyping literals: question and test cases
Sender: ext Graham Klyne <GK@NineByNine.org>
Date: Wed, 30 Oct 2002 09:38:43 +0300
This arose when trying to adjust CC/PP to take account of the datatyping
decision.
For starters, under the current datatyping decisions, I understand that:
_:x ex:prop "10" .
ex:prop rdfs:range xsd:integer .
is not satisfiable under under any interpretation that conforms to the
xsd:integer datatype constraints.
I also understand that, following DanC's requests,
_:x ex:prop "foo" .
ex:prop rdfs:range xsd:string .
will be satisfiable in conformance with xsd:string datatypeconstraints.
No, it is *not* satisfyable. (and since when does one member's
request result in a major change to a WG decision?)
But, what about this:
_:x ex:prop "http://example.org/" .
ex:prop rdfs:range xsd:anyURI .
This also is not satisfyable.
The ramifications of string-based semantics is that
there is *no* implicit datatyping of any kind and one must
explicitly type each and every occurence of every value
and rdfs:range assertions are only compatable with
explicitly typed literals.
It is like having to cast every lexically represented value
in a programming language rather than basing the
interpretation on the type of the variable. E.g.
one must always explicitly say
int x = (int) 1 + (int) 2 + (int) 3;
not
int x = 1 + 2 + 3;
as the latter is interpreted as
int x = "1" + "2" + "3";
and thus just as a compiler is going to treat the above
as a type conflict, so also will inlined literals conflict
with any datatype range assertion.
(I wonder if all the WG members realize just how divergent
the RDF string-based semantics are from every programming
language on the planet and just how *#&£ EUR 'd up it is)
Patrick
#g
--
PS: in my subject line, I say "test cases", which these are strictly
not. How does one express a satisfiability question as a test case? I
suppose that is something is not satisfiable then it entails anything you
care to choose:
ex:a ex:notSatisfiable ex:b .
entails
ex:anySubjectYouLike ex:anyPropertyYouLike ex:anyObjectYouLike .
?
-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Wednesday, 30 October 2002 03:28:58 UTC