Re: language-tagged literal datatypes

On 19/08/11 14:28, Richard Cyganiak wrote:
> On 19 Aug 2011, at 00:11, Pat Hayes wrote:
>> Option 2. All literals have a type. rdf:LangString is a special
>> datatype whose L2V mapping takes a pair of strings as input and
>> returns a language-tagged pair as output. This mapping is the
>> identity mapping on pairs<string, tag>, just as xsd:String is the
>> identity mapping on single strings. DATATYPE("foo"@en) returns
>> rdf:LangString, following the normal rules for datatyping.
>
> There's also 2b:
>
> All literals have a type. rdf:LangString is a special type, where the
> lexical form is<string,langtag>  rather than just a string, and it
> doesn't have an L2V mapping. The value of an rdf:LangString literal
> is the same as the lexical form. DATATYPE("foo"@en) returns
> rdf:LangString, following the normal rules.
>
> (The advantage of 2b versus 2 is that the L2V mechanism can remain
> unchanged. It can remain defined as functions from string to value,
> rather than functions from anything to value as required by 2. In 2,
> the L2V of rdf:LangString is just the trivial identity mapping
> anyways, and resorting to the L2V mapping device just to explain a
> no-op mapping is overkill.)
>
> (2b also makes it easy to re-write the rdf:PlainLiteral spec into a
> spec titled “An L2V mapping for rdf:LangString” that just defines an
> L2V mapping that takes "foo@en" to<"foo","en">, while keeping the
> current restrictions on use of such lexical forms. So I'd hope it
> would be an easier sell to the OWL/RIF WGs.)

Slight problem:

STR(?x) returns the lexical form of a literal.  The language string is 
the conventional extension to SPARQL in current deployments.

If the lexical form is <string,langtag>, then that would be returned. 
There is also whether you can write

???^^rdf:LangString

c.f. rdf:PlainLiteral.

A solution is to just say in the syntaxes '''the value of "foo"@en is 
<foo, en>'''

This leave L2V alone 9it's not used) and answers what happens if you 
write  ???^^rdf:LangString -- it's an ill-defined literal.


It's also posisble to define STR() specifically for language tagged 
literals to mean the string part.  that stil leaves opne about writing 
^^rdf:LangString.

	Andy


>
>> option 2: + simplifies literal syntax + removes SPARQL errors +
>> theoretically clean -- requires change to the datatyping model
>
> option 2b: + simplifies literal syntax + removes SPARQL errors + no
> changes to datatyping model -- introduces one exceptional datatype
> that works differently from all others
>
>> If we say that the L2V mapping takes as input all the syntactic
>> 'components' of a literal, rather than forcing these to be all
>> inside one string, then we allow such things as literals with
>> latitude and longitude denoting positions, complex numbers with
>> real and imaginary parts, etc.., without forcing people to invent
>> coding tricks (like the trailing '^' in rdf:PlainLiteral) to
>> artificially map these into a single string. This might be a
>> genuinely useful extension, in other words.
>
> Being able to express lat/long pairs and complex numbers in the
> abstract syntax isn't really if you have no way of writing them down
> in a concrete syntax. So you either still need to squish them into a
> single string, or extend your RDF syntax of choice with additional
> syntactic sugar for expressing that kind of literal.
>
>> We can also quietly deprecate rdf:PlainLiteral along with 8-track
>> tape players.
>
> A major motivation for rdf:PlainLiteral is the desire to
> stick<string,langtag>  pairs into a single string, so I'm afraid it
> won't be quite as easy.
>
> Best, Richard

Received on Monday, 5 September 2011 21:52:31 UTC