Re: lang

On 12/12/2013 07:09 AM, Andy Seaborne wrote:
> On 12/12/13 11:16, Markus Lanthaler wrote:
>
>> This is completely off-topic and I'm asking it just out of curiosity: 
>> What
>> would break if we would have decided to define a datatype for each 
>> language.
>> So instead of rdf:langString we would have had something like 
>> rdf:lang-xxx
>> similar to the container membership properties rdf:_xx:
>>
>>    <> rdfs:comment "An explanation in English"^^rdf:lang-en
>>
>
> We ended up here, at least in part, because XML has language tag and 
> they are not datatypes.
>
> They are case-insensitive matches.
>
> "An explanation in English"^^rdf:lang-en
> owl:sameAs
> "An explanation in English"^^rdf:lang-EN
>
> and
> RFC4647 "Matching of Language Tags"
>
> Language tags can be compared in ways that classes can't
>
>  "en-us" lang-matches "en"
>  "en-us" lang-matches "en-*"
>
> so inheritance-ishness in datatypes is needed, but it's not like XSD 
> derived types on the same value space.
>
> It seems to me that you end up with some additional machinery at which 
> point the nice model of datatypes is a bit lost.
>
> With rdf:langString, the language tag is the "additional machinery" in 
> a way that does not leak out to other datatypes.
>

All true.

We do not appear to have kept good records on this issue.  I can't 
figure out which issue number it was (sort of 12...?) and the only 
relevant resolution is on a detail:

2013/05/22-rdf-wg RESOLVED:  The value space of rdf:langString has the 
language tag in lower case; in the lexical form, the language tag MAY be 
converted to lower case (as RDF 1.0 says, but not everyone does).

(Personally I've never liked the current design.   My preference was to 
use predicates ( _:someAbstractMessage)---expressedInEnglish--->"...."), 
or datatypes.     But we settled this a long time ago, even if I can't 
find the resolution.)

      -- Sandro

>     Andy
>
>
>

Received on Thursday, 12 December 2013 13:18:51 UTC