Re: Comments on June 14th release

Hi Frank,

Thanks for the comments. We appreciate hearing about your experiences 
implementing SPARQL.

I've replied below to the ones that seem to be seeking information.

Francis McCabe wrote:
> 
> I have posted a couple of issues regarding what I felt were less than 
> clear areas of the SPARQL spec.
> 
> This is a comment on the nature of the language itself.
> 
> 1. Overall, it is a nice addition to the RDF universe. It is 
> particularly relevant in industry because of prior familiarity with SQL. 
> (It is a big bonus to be able to tell my boss that SPARQL=SQL for RDF; 
> even it is not quite accurate:)
> 
> 2. I am implementing the spec as an exercise; in a white room 
> environment (i.e., no JENA etc.)
> 
> 3. Some of the features of the language I will almost certainly not be 
> implementing are:
>  REDUCE and OFFSET. The first because I can see no need for it; and the 
> second because it is tacky.
> 
>  (There are features that I will not implement at this time; mainly all 
> the stuff about GRAPH -- simply because I do not need it.)

Thanks for the information about your implementation.

> 4. Having an algebraic semantics is potentially very helpful. However, 
> there are a number of corners skipped in the current presentation:
>  (a) the transformation from abstract syntax to algebra (this is being 
> fixed?)
>  (b) the specification of the interpretation of ORDER BY

We've dealt with these two in the threads specific to these issues.

> 5. A major issue for me is the apparent confusion about blank nodes. 
> This is not dealt with fully in the spec.
>  For example, can a blank node in the query match a non-blank node in 
> the graph? (I believe yes; but I have not done enough homework to prove it)

The specification deals with blank nodes in queries in several places. 
It is first mentioned in 4.1.4 Syntax for Blank Nodes:

"""
Blank nodes in graph patterns act as non-distinguished variables, not as 
references to specific blank nodes in the data being queried.
"""

The full semantics of pattern matching is given in 12.3.1 SPARQL Basic 
Graph Pattern Matching, which includes

"""
Basic graph patterns can be instantiated by replacing both variables and 
blank nodes by terms, giving two notions of instance. Blank nodes are 
replaced using an RDF instance mapping,  σ, from blank nodes to RDF 
terms; variables are replaced by a solution mapping from query variables 
to RDF terms.
"""

Thus, blank nodes can match any RDF term in the target RDF dataset.

Finally, 12.3.2 Treatment of Blank Nodes, attempts to clarify the lack 
of a relationship between query blank nodes and dataset blank nodes; it 
also deals with the infinite redundancy that SPARQL deals with by use of 
the RDF instance matching mapping, sigma.

> 6. It would be *nice* if there were standard built-ins around collection 
> and container membership. But perhaps this is my ignorance?

Many on the working group and in the community agree. This is an issue 
that th Working Group postponed in 2005, citing a lack of mature 
designs. Since then, some implementations have explored this space, and 
it is many people's hope that a future Working Group might tackle this area.

For a bit more, see:
   http://thefigtrees.net/lee/sw/sparql-faq#transitiv8

thanks,
Lee

> I hope that this comment is helpful
> 
> Frank McCabe
> 
> 
>

Received on Friday, 19 October 2007 21:47:24 UTC