- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Sun, 06 Mar 2011 16:37:13 +0000
- To: Steve Harris <steve.harris@garlik.com>
- CC: Sandro Hawke <sandro@w3.org>, Pat Hayes <phayes@ihmc.us>, RDF Working Group WG <public-rdf-wg@w3.org>
On 06/03/11 08:12, Steve Harris wrote:
>> What about just saying, "please don't use xs:string any more", and
>> "if
>>> you (some RDF software) find an xs:string, you SHOULD convert it
>>> to a plain literal". Would that pretty much solve the problem?
> That's the inverse of what I suggested just before I read this mail.
> It works for me (from a storage point of view it's probably simpler),
> but I understand that it's not ideal for some reasoning systems?
the inverse was:
On 06/03/11 07:59, Steve Harris wrote:
> "foo"^^xsd:string -> "foo"^^xsd:string
> "foo" -> "foo"^^xsd:string
> "foo"@de -> "foo"^^xsd:string @de
I think it works better as
"foo"^^xsd:string -> "foo"
"foo"@de -> "foo"@de
because at the moment, code can assume that a literal has either a lang
tag or a datatype but not both. If that changes, a niggly bugs may appear.
A parser(only)-change doing the conversation preserves current RDF
except for the loss of round trip appearance but if xsd:string acquires
a lang tag, code outside the parser changes.
rdf:PlainLiteral is the wrong solution - it hides the lang tag in the
lexical form.
If we had that
"foo" -> "foo"^^xsd:string
"foo"@de -> "foo"^^xsd:lang-de
"foo"^^xsd:string -> "foo"^^xsd:string
i.e a datatype per language tag, that might work but it is still
assuming re-tooling of RDF processors and RDF-driven application to
handle properly.
"foo"^^xsd:string -> "foo"
seems to be best for backwards compatibility.
The value space of plain literal without language tag (SPARQL:simple
literals) is xsd:string.
The value space*s* of plain literal with language tag needs sorting out.
A simple RDF processor can work by xsd:string -> simple literal.
Current systems and applications continue to work.
Andy
Received on Sunday, 6 March 2011 16:37:51 UTC