Disposition of Candidate Recommendation comments for the SPARQL Query Language for RDF dated 14 Jun 2007

...
The "at least one" part should probably be removed, or replaced with something that states that it is equal to or larger than the DISTINT solution set.
...

...
these two examples seem to have some copy-paste-errors, yes?
...
Another question concerning FILTERs in OPTIONALS
...

My suggestion is either:

• that != is defined in terms of sameTerm (which never returns a type error), not RDFterm-equal, or
• that fn:not is replaced by a SPARQL operator that masks SPARQL type errors, treating them as false, but otherwise behaving as fn:not.

The current specification defines extremely unintuitive behavior that baffles even experienced users, and should be changed.

It's not completely clear to me what the Effective Boolean Value of invalid numeric literals should be. I have been unable to find a decisive answer in the current SPARQL specification.

I have noticed some small errors in section 12: 12.2.1 in the algorithm, LeftJoin(G,A,true) should read LeftJoin(G,SA,true) 12.5 the evaluation of Filter(P,F) should read eval(D(G),Filter(P,F)) = Filter(eval(D(G),p),F)

12.2.2 has a minor error...

1. The variable SP is not mentioned again in the algorithm, and presumably is not needed?
2. if SA is an algebra expression (as opposed to a pattern expression), then presumably it cannot be of the form OPTIONAL anything ... as one of the purposes of the algrebafication (sic) is to eliminate optional clauses

3. On the other hand, immediately prior to this is the suggestion that this is a recursive algorithm:

   A group pattern is mapped into the SPARQL algebra as follows: first, convert all elements making up the group into algebra expressions using this transformation process recursively, then apply the following transformation:

   which implies that algebrafication (sic again) has already taken place.

4. What exactly, is implied by:

   Let F := all filters in the group (not in sub-patterns)

   Does this mean that all FILTER(constraint) expression should be wrapped into a big conjunction prior to determining what to do with them?

This grammar permits *any* expression or constraint to be an order condition. But the text fails to give clear semantics for this.

For example, what does

.... order by ?x < 34

mean?

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

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

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)

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

I believe that is important that SPARQL have a declarative semantics. This both reflects the fundamental purpose of a query language -- it is not a programming language -- and will make it easier to communicate to non-professionals the merits and benefits of using it.

...

Although there may appear to be compelling pragmatic reasons for retaining the OPTIONAL feature; I believe that they are outweighed by the conflicts that they raise with the fundamental nature of the Semantic Web.

...

The basis of my objection is founded on SPARQL being an RDF query language and that it should use an RDF data model throughout...

One feature that SPARQL lacks is closure. Having closure on all operations means that intermediate results and answers are always tied to an RDF graph. It means that in each step of the query evaluation you are dealing with valid subsets of RDF graphs...