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

(forwarded to the lists)

Addison Phillips wrote:
> 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
>

Received on Thursday, 26 April 2007 07:28:03 UTC