Re: (Editorial) comments on the SPARQL 1.1 Query Language draft

  > Hi guys,
  >
  > a few editorial issues. Note that I have_not_  yet read through the
  > algebra (ie, section 18); I may need some more time (and taking a
  > deep breath) before doing that:-)
  >
  > General comments:
  > =================
  >
  > Sections like #5, #6, #7, etc, very much read like a tutorial (which
  > is good!). Most of these do not make a reference to the algebra, ie,
  > one can really read these sections without problems "linearly".
  > However, the description of, say, GROUP BY uses a formalism that, at
  > this point in reading, is not understandable, unless the reader jumps
  > ahead and reads the formal algebra. The same occurs in section 11.5,
  > 11.6, but also in 12 (e.g., "Subqueries require one additional
  > algebra operator, ToMultiset, which takes lists and returns
  > multistep." or "Becomes ToMultiset(Project(BGP(?x ?y ?z), {?z})).").
  > Is this really necessary? Can't we stay at that "tutorial" level in
  > those sections? I think this would make the spec much more
  > palatable.

Yes, we will look at moving all the algebra to the later sections of the 
document.  Noted at [*].

  > A related issue is the usage of the term 'project' (like "GROUP BY
  > clause cannot be projected") that comes up fairly often but it is not
  > really explained when just reading the document linearly. As an
  > example, I do not really understand what the following clause means
  > in 11.4:
  >
  > "In a query level which uses aggregates, only expressions consisting
  > of aggregates and constants may be projected, with one exception.
  > When GROUP BY is given with one more more simple expressions
  > consisting of just a variable, those variables may be projected from
  > the level."

The term projects is used extensively in earlier sections, and there's a 
forward link to the definition the first time it is used, so I don't 
think that the use in this cases is especially problematic.

  > Well, probably I would if I read first the algebra, but I am not yet
  > there…
  >
  > ----
  >
  > do functions/operators like 'bound' 'sameTerm' have a URI now? I saw
  > that, a while ago, the
  >
  > http://www.w3.org/ns/sparql#bound
  >
  > was defined, but the namespace document does not have anything more
  > at the moment. Is the intention to complete that file?

Yes - The Working Group will allocate IRIs to all SPARQL functions and 
operators and setup the namespace document before CR. The text of the 
query spec will include these links in the function descriptions.

  > Also, if there is indeed a URI for these terms, it may be worth
  > noting this fact in the query document itself.

This will be done.  See [*]

  >
  > -----
  >
  > There are several references to the vcard vocabulary in the examples.
  > There is now a new and widely used version with the vocabulary URI:
  >
  > http://www.w3.org/2006/vcard/ns#
  >
  > I think it would be good to use that in the examples

The examples are the original ones from SPARQL 1.0.  They occur in 
section 16.2 (CONSTRUCT) and 16.4 (DESCRIBE).  Both these sections are 
unchanged from SPARQL 1.0.  Therefore, we tend to leaving the example 
unchanged unless time permits.

  > -----
  >
  > Specific editorial buglets:
  >
  > 1.2.4: 'following' ->  'following'

This editorial correction seems to have been applied to itself.
Changed s/follwoing/following/.

  > 11.5 second paragraph 'infact' ->  'in fact'

Done

  >
  > 11.5 last paragraph, 'unless the ; separator is used this requires'
  > ->  'unless the ; separator is used, this requires'

I believe that the grammar as used in the document correctly expresses 
the intention.

  >
  > 17.4.2.1 there seems to be an extra \t for isURI in its definition

Done

  > Thanks!
  >
  > Ivan

We would be grateful if you would acknowledge that your comment has been 
answered by sending a reply to this mailing list.

Andy and Steve, on behalf of the working group.

[*] http://www.w3.org/2009/sparql/wiki/PostLastCall

Received on Tuesday, 14 June 2011 15:11:09 UTC