W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2011

Re: subtypes of xsd:string

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 26 May 2011 12:20:07 +0100
Cc: RDF Working Group <public-rdf-wg@w3.org>
Message-Id: <0677B164-20FE-4203-823F-7E5BFBB8DBED@garlik.com>
To: Ivan Herman <ivan@w3.org>
On 2011-05-26, at 11:32, Ivan Herman wrote:
> 
> On May 26, 2011, at 03:21 , Peter Frederick Patel-Schneider wrote:
> [skip]
>> 
>>> - add a subtype of xsd:string for language tagged strings;
>>> 
>>> "foo"@en -> "foo"^^xsd:LanguageTaggedString@en or some such.
>> 
>> Here is where this breaks down, just like the previous proposals like
>> it.
>> 
> 
> I may be wrong in what David wants, so I try to interpret what he says which is
> 
> "foo"@en -> "foo"^^rdf:language-tag/en
> 
> or something like that. 
> 
> We always fall back to the same two choices, actually: either we define a generic URI scheme to define a load of datatype URI-s for language tags, or we go down the rdf:LanguageTaggedString route.
> 
> I must admit I begin to more in favour of the datatype per language tag idea than I was before, provided that we do not even try to enforce any kind of extra semantics for them. Ie, we do _not_ claim to know whether

I think I agree, it seems like the least intrusive for current implementations, while keeping the desired behaviour. 

> rdf:language-tag/lang-extras
> 
> is a subclass of
> 
> rdf:language-tag/lang
> 
> Smart and language aware implementations may add their own extra knowledge in terms of extra axioms (and let the generic inference mechanism work). We can only say that all these classes are subclasses of xsd:string.
> 
> I would still like to see what the implementation costs of all this would be for Jena, Sesame, RDFLib, etc; something that we might explicitly ask the community to comment upon.

I can speak for 4store.

I think it depends on what happens it we find a "foo"^^rdflang:en in the wild. If it's "undefined" then it's trivial to handle (natch). Otherwise transforming it to the same internal representation as "foo"@en is also not too bad, as is emitting an error, but it's some work.

Other than that, the biggest change would be to make DATATYPE("foo"@en) return the appropriate URI, which isn't that difficult.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Thursday, 26 May 2011 11:20:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:43 GMT