Re: Comments on SPARQL WD

Lee Feigenbaum wrote:
> These are responses to the substantive parts of Olivier's comments. Andy 
> or Eric, when you respond to the editorial matters, please include these 
> comments.

Will do.

> 
> (Andy, you might in particular want to take a look at the response to the 
> RDFTerm-equal function. While I know the group has discussed this in the 
> past, I can't find a specific URL to a discussion or decision that I could 
> refer to.) 

Thanks for pointing this out.

> 
> Lee
> 
> Olivier Corby wrote on 03/28/2007 10:51:19 AM:
> 
>> Hi,
>>
>> Here are some comments on current SPARQL WD.
> 
> ...
> 
>> 4.2.3 RDF Collections
...

>> 5.2.2 Scope of Filters
...

>> 9.3 DISTINCT
...

>> 11.4.10 RDFterm-equal
>>
>> RDFterm-equal produces a type error if the arguments are both literal 
> but
>> are not the same RDF term.
>>
>>
>> So, following the current draft :
>>
>> 'Jules'@en = 'Jim'@en
>>
>> produces a type error because they are not the same RDF term.
>>
>> It is the same with != < <= > >=
>> ]]
> 
> By design, SPARQL does not define semantics for comparing plain literals 
> with language tags, as you've noted. Note that query writers can compare 
> literals themselves:
> 
>   !langMatches(lang(?a), lang(?b)) || !(str(?a) = str(?b))

langMatches is asymmetric in its arguments:

langMatches("en-us", "en") is true

so the full equality test needs to be something like:

   langMatches(lang(?a), lang(?b)) &&
   langMatches(lang(?b), lang(?a)) &&
   (str(?a) = str(?b))

> 
> The Working Group has not been motivated in the past to define the 
> comparison operators on plain literals with language tags. Section 11.3.1 
> Operator Extensibility licenses SPARQL language extensions that add rows 
> to the operator table, such that implementations may support comparing 
> plain literals with language tags.
> 
> I hope that this addresses this concern; please let us know if not, and 
> the Working Group will weigh changes to the operator table versus the 
> schedule risks of publishing a new Last Call draft.

relating to this general area: Olivier also said:

 > [[regex could operate on xsd:string as well as simple literal.]]

That is a legal extension because regex("foo"^^xsd:string,...) is a dispatch 
type error so an implementation can add it if it wishes.  ARQ does this in 
normal mode and not in strict mode.

	Andy

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Friday, 30 March 2007 11:03:32 UTC