- 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