Fw: Re: What do the resolutions on language tags mean for equality of tagged strings?

I’m re-stating this message since it appeared to be buried in the recent discussions and issues.

--Peter

From: Peter Occil 
Sent: Sunday, June 09, 2013 7:06 PM
To: Gregg Kellogg 
Cc: public-rdf-comments@w3.org 
Subject: Re: What do the resolutions on language tags mean for equality of tagged strings?

I agree that two literals that differ only in the case of their language tags are “value-equal” (denote the same value), but not necessarily that they’re term-equal.  That’s because it still currently says: “Two literals are term-equal (the same RDF literal) if [among other things] the two language tags (if any) compare equal, character by character.” Accordingly: 

   - if you believe the two literals are term-equal, then that definition should necessarily change, and/or
   - an example that states whether, say, “chat”@fr and “chat”@FR are “term-equal” and/or “value-equal” should be given,
     as is now done for “1”^^xs:integer and “01”^^xs:integer.

--Peter

From: Gregg Kellogg 
Sent: Sunday, June 09, 2013 6:48 PM
To: Peter Occil 
Cc: public-rdf-comments@w3.org 
Subject: Re: What do the resolutions on language tags mean for equality of tagged strings?

On Jun 9, 2013, at 3:39 PM, Peter Occil <poccil14@gmail.com> wrote:


  I’m referring to the current Editor’s Draft [1], not the current Working Draft.  See section 3.3 of the current Editor’s Draft, in particular the changed definition of “language tag” and “literal equality” (now called “literal term equality”, which is why I used “term equality” and “value equality”).  One of the changes “[i]mplemented [a resolution] regarding rdf:langString case sensitivity” [2].

That resolution just clarifies that the value-space for the language tag is always in lower case. I don't see that that contradicts the current WD, and I don't believe that was the intent. If the value space is always in lower case, then @FR and @fr will compare identically.

This version does make a weaker statement, though, which captures actual practice. RDF 1.0 requires that language tags be normalized to lower case, while RDF 1.1 just says that the value-space is lower case, giving room for implementations to actually store the language tag in the original case, as long as the comparison is performed case-insensitively. IMO, this SHOULD mean that they are the same term, and a store will only have a single triple, where multiple triples would vary only in the case of the language tag.

Gregg