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

On Thu, 2011-09-08 at 18:43 +0200, Richard Cyganiak wrote:
> Sandro,
> 
> I could now point out how that code is more complicated than the equivalent option 2 code and consider your simplicity argument refuted.

> But it just strikes me as remarkable that you seriously put forward the potential saving of two lines of code in the *implementation* (not even interface) of *one class* as an argument for changing a W3C Recommendation.

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.

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

> 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.  At the
purely syntactic level, as in SPARQL, those are distinct.  If you don't
implement the datatype, you have to keep them distinct.  But if you know
what xs:decimal means, in most RDF situations, you can smoosh them into
one thing.  I suggest it's reasonable to have a similar situation with
language tags.   If you implement language tag processing, then you'll
smoosh/normalize those.

> 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 Thursday, 8 September 2011 21:02:08 UTC