- From: Jan Wielemaker <J.Wielemaker@vu.nl>
- Date: Mon, 26 Sep 2011 11:51:29 +0200
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Antoine Zimmermann <antoine.zimmermann@emse.fr>, <public-rdf-wg@w3.org>
On 09/26/2011 11:28 AM, Richard Cyganiak wrote: > You understate the issues. > > Every existing application that uses the Literal.getLexicalForm() call of some API to get at the xxx part of xxx@lll would have to be changed, because the lexical form of xxx@lll is now xxx@lll. > > That's a complete non-starter. I fully agree. Also note that APIs for (notably in-core) RDF stores can now typically work on a single shared representation of the literal. If we add a tag to the literal many of the operations will have to create a copy without the tag. I'm not saying this cannot be solved, but I fear it will be natural nor pretty, especially for existing stores that did not anticipate this in their design phase. I must admit that I'm only following this from the sideline. As an implementor I'm starting to get worried about some wild ideas though. The solution I still like best is that foo@tag is the same as "foo"^^langbase:tag, where langbase is some to be decided prefix for language identifiers. Any implementation should be fairly comfortable with that (typically it will just simplify things). I understand things get complicated if we want to attach semantics to the these datatypes, so I'd propose not to do that. Most likely others will make an attempt. Regards --- Jan
Received on Monday, 26 September 2011 09:52:39 UTC