Re: Comments on SPARQL WD

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.

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

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
> 
> [[Suggestion : the (1 ?x 3 4) notation for rdf list could not generate 
the
> _:b rdf:rest rdf:nil triple; in such a way we could match lists that may
> have more elements.]]

The syntax of SPARQL triple patterns, and in particular of the syntactic 
sugar forms given in section 4.2 ( 
http://www.w3.org/TR/rdf-sparql-query/#QSynTriples ), is designed to be 
consistent with the syntax of Turtle ( 
http://www.dajobe.org/2004/01/turtle/ ). In Turtle, the (1 2 3) syntax 
specifies a closed collection (i.e. one terminated by an rdf:nil triple), 
and SPARQL adopts this meaning for this bit of syntax.

Of course, you can match a subset of a collection by explicitly including 
the component pieces of the collection explicitly:

    _:b0  rdf:first  1 ;
          rdf:rest   _:b1 .
    _:b1  rdf:first  ?x ;
          rdf:rest   _:b2 .
    _:b2  rdf:first  3 ;
          rdf:rest   _:b3 .
    _:b3  rdf:first  4 .


> 5.2.2 Scope of Filters
> 
> A constraint, expressed by the keyword FILTER, is a restriction on
> solutions over the whole group in which the filter appears.
> 
> [[What happens if a variable in the filter is not bound in the current
> group, but is bound in another group  after current group? Does the 
filter
> fail? ]]

As per the text you've cited and the algebra given in Section 12, Filters 
are evaluated in terms of the solution mappings of the group in which the 
filter appears. If a variable in the filter is unbound in a solution 
mapping, then as per Section 11.2 any function or operator (except 
bound()) on the variable produces a type error. If this propagates to the 
top of the filter, then the solution is removed from the multiset of 
solution mappings.

 
> 9.3 DISTINCT
> 
> What is the solution of :
> 
> select distinct ?y where {
>    ?x c:friend ?y
> }
> 
> on this graph :
> 
> ex:Jules c:friend ex:Jimmy
> ex:Jules c:friend ex:James
> ex:Jimmy owl:sameAs ex:James

SPARQL is defined for simple entailment, with no notion of the semantics 
of owl:sameAs. The result of this query is:

  ?y
--------
ex:Jimmy
ex:James


> [[
> I think there should be an = operator for plain literals because
> otherwise, RDFterm-equal applies, in which case :
>
> 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))

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.

Received on Thursday, 29 March 2007 16:56:49 UTC