Re: [CLOSED] Re: [SPARQL] i18n comment: Modification in description of langMatches operator

Eric Prud'hommeaux wrote:

>The last draft SPARQL was defined in terms of RFC3066 matching (single
>language range). 
>
RFC 3066 did an incomplete job of specifying matching algorithms, though :-(

>Changing this would require all the implementations
>to re-visit their code. I will bring this up in the next DAWG telecon,
>noting that your comment can be satisfied even if it isn't adopted. To
>that end, let me make sure I understand your arguments:
>
>Were you arguing that SPARQL implementations may already take priority
>lists? or that if some used out-of-the-box libraries, the libraries
>might take priority lists?
>  
>

The latter. Implementations of language matching in the future are at 
least a little bit likely to look at 4647 and implement language 
priority lists. Calling those functions will work, of course, with a 
"list" containing a single item.

>Are there any applications that use basic language priority lists
>today (I know, classic chicken and egg problem)? HTTP Accept-Language
>headers are more complex as they include quality quotients.
>  
>
I've written a couple. Note that HTTP Accept-Language headers are more 
complex than a simple list, but are still clearly "language priority lists".

>  
>
>>>>>2. The special range "*" usually matches all language tags, including 
>>>>>the empty tag. If it didn't, you would have the problem of not being 
>>>>>able to select contents with no tag except explicitly. That is, to 
>>>>>select everything, you'd need two queries: one for "*" and one for the 
>>>>>empty tag. (Obviously, omitting the langmatches statement has the same 
>>>>>effect, so your current text may be by design??)
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>Yes, lang("abc") returns an empty string as giving type errors would
>>>make the language more cumbersome. The use case for looking for
>>>anything with a language tag drove langMatche("", "*") => false.
>>>
>>>
>>>      
>>>
>>Okay, that makes sense. But it should be documented clearly, since it 
>>isn't quite RFC 4647. This suggests, please note, something that I 
>>should take back to the LTRU WG at IETF (where 4647 is maintained).
>>    
>>
>
>Agreed, though I quibble with the wording below, believing that there
>are no literals with a language tag of "" as they are represented as
>literals with no language tag. 
>
That's entirely possible. I thought RDF would just copy the xml:lang="" 
construct if it appears (XML makes it legal??)

>I propose pointing that out in the lang
>function call. I've added a sentence to the editor's draft:
>
>http://www.w3.org/2001/sw/DataAccess/rq23/rq25#func-lang
>[[
>simple literal   lang (literal ltrl)
>
>Returns the language tag of ltrl, if it has one. It returns "" if ltrl
>has no language tag. Note that the RDF data model does not include
>literals with an empty language tag.
>]]
>  
>

Good.


>You can't distinguish by using langMatches(lang(?x)) , but by using
>lang(?x)="" .
>
>In fact, this works for queries for literals with our without a
>language tag. Ultimately, I think the motivation for the "*" rules is
>to be an intuitive interpretation of "matches any tag" and that it is
>more intuitive that it not match literals with no language tag; an
>artifact that it's being used on data with and without language
>tags. That said, I can't promise that that was the extent of the
>wisdom. Some of these things require sending mail and regretting.
>
>http://rfc.net/rfc4647.html#s3.3.1.
>[[
>The special range "*" in a language priority list matches any tag.  A
>protocol that uses language ranges MAY specify additional rules about
>the semantics of "*"; for instance, HTTP/1.1 [RFC2616] specifies that
>the range "*" matches only languages not matched by any other range
>within an "Accept-Language" header.
>]]
>  
>
Yes. So long as you specify the additional semantic, I'm fine.

>Given the 4647 "matches any tag" wording, and the new "Note that the
>RDF data model does not include literals with an empty language tag"
>in 11.4.6 lang, I propose:
>
>http://www.w3.org/2001/sw/DataAccess/rq23/rq25#func-langMatches
>[[
>Returns true if language-tag (first argument) matches language-range
>(second argument) per the basic filtering scheme defined in [RFC4647]
>section 3.3.1. language-range is a basic language range per Matching
>of Language Tags [RFC4647] section 2.1. A language-range of "*"
>matches any non-empty language-tag string.
>]]
>
><insert usual, feel-free-to-close clause here>
>  
>
I'm satisfied with this, given the explanations, et al, above. Feel free 
to close it from here (pace the I18N WG's satisfaction).

Addison