Re: Datayped tagged literals: a case for option 4 vs option 2d

On 26 Sep 2011, at 10:51, Jan Wielemaker wrote:

> 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).

Broadly I agree, but how would you ask the query "is ?x a string (of some kind)"?.

I'ts a pretty common use case, and currently it's a pain, but I think this would make it even harder. I'm not keen on any solution which requires reasoning over language tag URIs, or regex matching.

> 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.

Not me!

- Steve

Received on Monday, 26 September 2011 13:04:41 UTC