W3C home > Mailing lists > Public > public-rdf-wg@w3.org > December 2013

Re: lang

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 12 Dec 2013 09:22:13 -0800
Cc: Andy Seaborne <andy@apache.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, RDF WG <public-rdf-wg@w3.org>
Message-Id: <1FFB59F1-BBAC-475E-8399-51A0E4504548@ihmc.us>
To: Sandro Hawke <sandro@w3.org>

On Dec 12, 2013, at 5:18 AM, Sandro Hawke <sandro@w3.org> wrote:

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

Abstract messages, poppycock :-)

My own favorite is just to go beyond XSD and declare that datatypes are allowed to have multi-string lexical spaces, which would also then permit datatypes like time-intervals (two points) or geographical rectangles (point plus two lengths) to be handled naturally. But the WG felt that was dissing XSD. It is quite amazing how hard it is to get a clean story about things as simple as datatypes. I recall the 2004 WG spent more time on datatyping than almost any other topic, as well. 


> , or datatypes.     But we settled this a long time ago, even if I can't find the resolution.)
>     -- Sandro
>>    Andy

IHMC                                     (850)434 8903 home
40 South Alcaniz St.            (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile (preferred)
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 12 December 2013 17:23:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:37 UTC