W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > October 2002

Re: Datatyping literals: question and test cases

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 31 Oct 2002 09:29:00 +0200
Message-ID: <009701c280af$2fbf1800$6d9316ac@NOE.Nokia.com>
To: "Graham Klyne" <GK@NineByNine.org>, "ext pat hayes" <phayes@ai.uwf.edu>
Cc: <w3c-rdfcore-wg@w3.org>

[Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com]

> >But, what about this:
> >
> >   _:x ex:prop "http://example.org/" .
> >   ex:prop rdfs:range xsd:anyURI .
> That depends on how xsd:anyURI defines its value space. If its the 
> set of strings conforming to the URI syntax, then OK. 

ARGH! Pat, no!

The WG has decided (with Nokia's dissent) that inlined literals
denote their string components (i.e. string-semantics) and therefore
the above range assertion is a datatype clash! It is *never* OK.
Never ever ever. It is not possible for it to ever be OK.

If it were to be valid, the literal must be explicitly typed, *always*

   _:x ex:prop "http://example.org/"^^xsd:anyURI .

Furthermore, not that xsd:anyURI is *not* a subtype even of xsd:string!
I.e., even XML Schema says that a member of the value space of xsd:anyURI
is *not* a member of the value space of xsd:string -- a URI is not a string!

Now... if we had made the more rational decision to adopt value-based
semantics for inlined literals, then Jeremy's example would have
been fine and dandy, with the range assertion providing the interpretation
of the inlined literal, and all would be well.

But as it is, were stuck with this insane (IMO) string-based
semantics that makes inlined literals and typed literals forever
disjunct (even if we call inlined literals 'typed' as members of
rdfs:StringLiteral or some such datatype).

Inlined literals and rdfs:range will *never* work together, except
in the single case of rdfs:StringLiteral. I wonder if folks appreciate
that oddity.

Received on Thursday, 31 October 2002 02:29:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:16 UTC