- 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