Re: example of options 3 & 4 simplifying code (ACTION-86)

On 8 Sep 2011, at 23:01, Sandro Hawke wrote:
> My argument is about who bears the cost, not whether there is a cost.
> Language tagging is complicated; I just don't want people to have to be
> aware of it *at all* until/unless they are using it or writing complete
> general-purpose libraries.

I don't understand this.

So let's assume a scenario where everyone just uses untagged string literals.

Who in this scenario are the people bearing the unnecessary cost from the i18n support of RDF?

>> Also, your proposal seems to be motivated by a desire to reduce the total number of distinct parts in a literal from three to two. Why not go further and reduce them to one? Surely that would be superior to your proposal by your own metric?
> 
> To quote Occam and/or Einstein: Things should be as simple as possible,
> but not simpler.

They already are as simple as possible. Thanks for “proving” my point!

>> Also, "foo"@en and "foo"@EN and "foo"@eN are all the same literal in Turtle, SPARQL and N-Triples. Would "foo"^^rdfl:en, "foo"^^rdfl:EN and "foo"^^rdfl:eN be the same or different in your proposal?
> 
> It's like "0.1"^^xs:decimal and "00.1"^^xs:decimal, I think.  

No. "0.1"^^xsd:decimal and "00.1"^^xsd:decimal are *distinct* in the abstract syntax. "foo"@en and "foo"@EN are the *same* in the abstract syntax.

rdfl:en and rdfl:EN are *distinct* URIs in the abstract syntax.

So either you end up with a situation where language tags are sometimes case sensitive and sometimes not. Or you end up with a situation where IRIs are sometimes case sensitive and sometimes not.

> If you implement language tag processing, then you'll
> smoosh/normalize those.

Why “if”? Language tag processing is a normative part of RDF, so any conforming implementation has to implement this proposed “IRI case smushing”.

If your proposal is to normatively define a profile of RDF that removes i18n support, then say so. Spec-wise that would be easy to do.

Best,
Richard



> 
>> Also, this:
>> http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0425.html
> 
> I understand that paper to show that we can't use existing RDF inference
> machinery to address language tag machinery.  That's okay; it would have
> been nice, but I'm not suggesting we do so.  I'm not saying by using
> language tags as datatypes we get any subsumption or other reasoning for
> free.  The only benefit, and one I continue to think is worthwhile but
> certainly not the most important thing in the RDF world, is to move all
> the complexity of language tags -- including their very existence -- out
> of RDF itself and into a family of datatypes.
> 
> I'm really sorry, again, the was I wasn't able to engage on this a few
> weeks ago, for personal reasons.
> 
>      -- Sandro
> 
>> Best,
>> Richard
>> 
>> 
>> On 8 Sep 2011, at 14:13, Sandro Hawke wrote:
>> 
>>> On Thu, 2011-09-08 at 10:12 +0200, Richard Cyganiak wrote:
>>>> On 7 Sep 2011, at 19:34, Sandro Hawke wrote:
>>>>> I argued in todays meeting, off the cuff, that option 2 (in Pat's
>>>>> email [1]) offers only aesthetic improvements, while options 3 and 4
>>>>> will result in simpler code.  
>>>> 
>>>> Please provide some example code for:
>>>> 
>>>> Option 3:
>>>> 
>>>> - checking whether a literal is a string
>>> 
>>> LANG = "http://www.w3.org/ns/lang/"
>>> XS = "http://www.w3.org/2001/XMLSchema" 
>>> 
>>> def is_string(node):
>>>  return is_literal(node) and (
>>>     node.datatype == XS+"string" or
>>>     node.datatype.startswith(LANG) )
>>> 
>>>> - returning the language tag of a language-tagged string
>>> 
>>> def lang_tag(node):
>>>  assert node.datatype.startswith(LANG) 
>>>  return node[len(LANG):]
>>> 
>>>> Option 4:
>>>> 
>>>> - returning the lexical form of a literal
>>> 
>>> node.lexrep
>>> 
>>> I agree this is a significant compatibility problem, since it will
>>> return chat@fr.
>>> 
>>>    -- Sandro
>>> 
>>>> Thanks,
>>>> Richard
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
>

Received on Friday, 9 September 2011 05:02:14 UTC