Re: Review of SPARQL 1.1

Hi all,
I cannot attend tomorrow's telecon (travelling) and I haven't said in
my review whether I think that the doc is ready to go to FPWD or not
because I am not entirely sure what the criteria are. There are a few
things that need fixing, but overall the document is in an ok shape,
so I won't object it to go to FPWD I guess.
Birte

2009/10/2 Birte Glimm <birte.glimm@comlab.ox.ac.uk>:
> Hi all, Andy, Steve,
> here is my review for the FPWD of SPARQL 1.1. I'll not be able to
> attend the telecon on Tuesday since I'll be travelling, but I hope we
> can sort out all questions before.
> Birte
>
>
> I am not sure what will happen with all the @@ comments, some might
> stay, but will, for example, the Abstract be rewritten before FPWD or
> will it just be annotated with @@ Old intro - rewrite?
>
> I understand that the doc will eventually b merged with the SPARQL 1.0
> doc, but in several places you rely on definitions from Sec 12 of
> SPARQL 1.0. If after the merge your sections will be before Sec 12,
> you will have lots of forward references. Another way of merging would
> be to have all the examples in an earlier section and put the
> definitions into the section that is now Sec 12 of SPARQL 1.0. This
> would then follow the way that the SPARQL 1.0 doc is organised (all
> features introduced by motivation and examples and one section with
> fomal definitions). This is just something to keep in mind for the
> doc.
>
> In general, I would prefer to see some introductory sentence at the
> beginning of the sections. In Sec 2 (and others), for example, you
> directly start with an example without saying anything of what
> aggregate functions are, what the example will demonstrate, etc. One
> can just guess from the section heading that the example will
> demonstrate how aggregate functions work.
>
> I woud also prefer if each grammar bit is preceeded with a short
> explanation of which parts of the grammar are new, which ones extend
> previous definitions and which ones replace previous definitions.
>
> Intro, 1st par: ... the backgraound to *the* choice
>
> Sec 2:
> Add headings Data:, Query:, and Query Result/Resuts: to the example to
> be consistent with the rest of SPARQL 1.0 and 1.1.
> The @@ comment for ProjectValues refers to the Project rule, but that
> is only introduced later in the doc and is not from SPARQL 1.0, please
> add a link.
> Algebra Operators:
> I suggest a complete sentence at the beginning, e.g.:
> The operators that make up aggregates consist of three functions: Key,
> Partition, and Aggregations.
> and then continue to define the three. Since the definitions are quite
> long, it is otherwise hard not to loose the context.
> Key is lowercase, but partition and aggregation are uppercase.
> I would also prefer complete sentences above the definitions, e.g.,
> Key *is* as function...
> I do understand what you mean by single-valued? Is it injective (a
> unique argument produces a unique result)? I don't think it is. Is the
> result always a singleton set? Also not really I think.
> Further, I think varlist in partition is not the same as varlist in
> key and I would prefer to name them something like namedVars and
> groupVars because for key it refers to the named variables from the
> select part of a query and for partition it refers to the named
> variables from the group by part of the query. I do not understand the
> def of partition and I am not sure whether or not you would need both
> var lists in partition. Here is my understanding of partition by means
> of an example (about books and their avarage price per publisher):
> Data:
> :a :publishes :a1 .
> :a :publishes :a2 .
> :b :publishes :b1 .
> :a1 :costs 12 .
> :a2 :costs 20 .
> :b1 :costs 4 .
> Query:
> SELECT ?p, AVG(?price) AS avg WHERE { ?p :publishes ?book . ?book
> :costs ?price . } GROUP BY ?p
> Result:
> p/:a, avg/16
> p/:b, avg/4
> Now I have solution mappings
> m1={ ?p/:a, ?book/:a1, ?price/12 }
> m2={ ?p/:a, ?book/:a2, ?price/20 }
> m3={ ?p/:b, ?book/:b1, ?price/4 }
> and omega = { m1, m2, m3 }
> I expect a partition
> { {m1, m2}, {m3} } or if you want to project out variables there already
> { { key(namedVars, m1), key(namedVars, m2) }, { key(namedVars, m3) } }
> For the first, I would define partition as follows:
> partition(groupVars, omega)={ { m_1, ..., m_n } | m_1, ..., m_n in
> omega and key(groupVars, m_1) = ... = key(groupVars, m_n) }
> for the latter
> partition(groupVars, namedVars, omega)={ { key(namedVars, m_1), ...,
> key(namedVars, m_n) } | m_1, ..., m_n in omega and key(groupVars, m_1)
> = ... = key(groupVars, m_n) }
> I don't think you want the later though because you still need the
> whole solution mapping to compute the average.
> I am not sure why you keep omega as part of the mappings in a
> partition and in the definition of aggregation it seems that partition
> returns a different omega then what it got as input, but this is not
> clear from the definition of partition. Maybe that is because you
> write omega in omega and that should be something else?
> For the aggregation, it remained completely unclear why it is defined
> as it is and how it is supposed to work. I would assume that I have in
> the example, AVG as agg, and I would need the partioning and then I
> compute a mapping that contains the aggregated values?
>
> What does AST stand for in the section headings (Mapping from AST to
> Algebra)? Later in Sec 3 it says ASP. Is that intended?
> Below the example just before section 3, you use BGP(triple pattern).
> That is not really defined neither in SPARQL 1.0 nor here. SPARQL 1.0
> mentions that briefly in 12.2.1, but I suggest a more precise
> definition somewhere.
>
> Will the wiki references stay in the doc? If so, I suggest to give
> them a heading such as "Further Material", "Relevant Links/Material".
>
> Sec 3: Add "Query:" above the query in line with the SPARQL 1.0 doc.
>
> Will the comments such as -- Andy at the top of Sec 4 stay?
>
> Sec 4, 1st par: It *it* does
>
> Sec 4, 2nd par: ...a fil*t*er expression
>
> Sec 4, Syntax, text below grammar rules for FILTER: ... and
> NotExistsPattern *s*but ...
> following note: equivalence to -> equivalent to
>
> I would prefer complete sentences, e.g., "To facilitate this, "
> followed by a definition with a border around it looks awkward.
> Similarly in the paragraph below the definition the last sentence is
> just: See below. I would delete that.
>
> I would not say "We define:" in the definition because it has already
> the heading "Definition: term to be defined"
>
> The subsection "Mapping from AST to Algebra" in Sec 4 starts directly
> with some data, no introductory sentence and after the data part of a
> sentence starts in lowercase "becomes a filter..." Also, in the given
> data, are <t> and <p> supposed to be a full URIs/IRIs? Is <p> the same
> as :p? The forms <p>, <t> are not used anywhere in SPARQL 1.0 other
> when t or are fullly qualified IRIs.
>
> The section needs more explanation.
>
> Sec 5, Definition Extend: an RD*F* *T*erm. Again, I would prefr not to
> say "We define " in the definition.
> Note below syn*ta*ctic
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529

Received on Monday, 5 October 2009 10:42:50 UTC