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

This is the disposition of the comments received by the RDF Data Access Working Group during the Candidate Recommendation publication period of the SPARQL Query Language for RDF. The disposition of comments received prior to the CR publication of this document can be found in the request to transition this specification to CR.

The Working Group has asked commenters to let the group know if they were not satisfied with the response to their comments.

In the table below, red in the WG decision column indicates that no changes to the document or related materials were made based on the comment, and green indicates that a change was made to accommodate the comment.

In the "Commenter reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the Working Group response to the comment.

CommenterCommentWorking Group decisionCommenter reply
Alexander Richter SPARQL Feedback: Support for Prefixed Names allowing Leading Digits

I wish to express in the strongest terms my support for maintaining the policy to allow leading digits in prefixed names...
The WG has received no requests to remove the at-risk feature of allowing leading digits in prefixed names, and the specification has maintained the feature. No response was solicited from the original commenter.
Arjohn Kampman minimim cardinality of REDUCED solution sets

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.
Editorial fix. None.
Axel Polleres example in current cand. rec....

these two examples seem to have some copy-paste-errors, yes?
Another question concerning FILTERs in OPTIONALS
Answers the second question.
Editorial fix.
Acknowledged answer.
Richard Newman !=

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.

Operator extensibility already allows for the proposed behavior. "Ah, operator extensibility hadn't occurred to me..."
Arjohn Kampman EBV of invalid numeric literals

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.
Editorial clarification made. Acknowledged clarification.
Malcolm Crowe SPARQL Query language for RDF

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)
Editorial bug fixed. (Document correct as is for first comment.) None.
Richard Newman Syntax error in algebra example

12.2.2 has a minor error...
Editorial fix. None.
Frank McCabe Cannot make sense of this

  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?

Editorial clarifications Acknowledged clarification
Frank McCabe Issue against june 14th edition of SPARQL

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


Section 9.1, #modOrderBy, specifies the behavior in question None.
Frank McCabe Comments on June 14th release

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?

Sections 4.1.4 and 12.3.1 specify the behavior of blank nodes in SPARQL queries; accessing collections is a postponed issue. The Chair received offlist acknowledgement to this response.
Frank McCabe Issue with top-down and bottom-up semantics

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.

No new information here; the Working Group has on record a long-standing objection against the requirement for OPTIONAL matching and a more recent objection against the use of an algebraic semantics Offlist, the commenter asked to be recorded as objecting to the inclusions of OPTIONAL in SPARQL.
Andrew Newman Objections to current SPARQL specification


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

Formal objection noted. See objection #bindingBased. None.

RDF Data Access Working Group