- From: Howard Katz <howardk@fatdog.com>
- Date: Fri, 8 Oct 2004 12:52:19 -0700
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: "Dave Beckett" <dave.beckett@bristol.ac.uk>, "Dan Connolly" <connolly@w3.org>, "Andy Seaborne" <andy.seaborne@hp.com>, "Steve Harris" <S.W.Harris@ecs.soton.ac.uk>, "RDF Data Access Working Group" <public-rdf-dawg@w3.org>
Just to add, so as not to impede publication, that I'm satisfied with the current state of the working draft. I consider this a publishable document. Again, good work, Howard > -----Original Message----- > From: Howard Katz [mailto:howardk@fatdog.com] > Sent: Friday, October 08, 2004 10:47 AM > To: Eric Prud'hommeaux > Cc: Dave Beckett; Dan Connolly; Andy Seaborne; Steve Harris; RDF Data > Access Working Group > Subject: RE: SPARQL / Language spec ready for review [Howard's feedback] > > > Changes look good, Eric, > > just two very minor comments: > > 1) a TOC with bolded and non-bolded sections looks very odd to > me. I don't think I've ever seen that as a stylistic device. I'd > kill the bolding. > > 2) 4.2 Multiple Optional Blocks, first sentence: > > "optionals blocks" -> "optional blocks" > > Other than that, nice work! > Howard > > > -----Original Message----- > > From: public-rdf-dawg-request@w3.org > > [mailto:public-rdf-dawg-request@w3.org]On Behalf Of Eric Prud'hommeaux > > Sent: Thursday, October 07, 2004 3:07 PM > > To: Howard Katz > > Cc: Dave Beckett; Dan Connolly; Andy Seaborne; Steve Harris; RDF Data > > Access Working Group > > Subject: Re: SPARQL / Language spec ready for review [Howard's feedback] > > > > > > Hi Howward, thanks for the feedback and many apologies for the delay > > in response. > > > > All issues should have responses here. Let me know if they are > > satisfactory, with special indication if they are not satisfactory for > > 1st WD. > > > > On Tue, Oct 05, 2004 at 07:12:27AM -0700, Howard Katz wrote: > > > Hi Eric, > > > > > > This is done off a fairly quick read. I haven't tried to correlate my > > > feedback against Dave's or anyone else's comments. I'm mostly > > *not* doing a > > > lot of nit-picking against spelling errors and other typos at > > this point, > > > ie, this is a bit of a higher-level view. This was reviewed > > against 1.82. > > > > > > Hope it's useful, > > > Howard > > > > > > ------------------------ > > > 1 Introduction > > > > > > If you're having sub-headings, as in "Document Outline" and "Document > > > Conventions", wouldn't it be more consistent to sub-number > > them, as in "1.1" > > > and "1.2"? > > 1.97: > > Outline is gone. Convention is now section 1.1 and in the TOC > > > > > --------------------- > > > 2 Making Simple Queries > > > > > > Why not use the same data and query example(s) in the initial > pictorial > > > section and the following SPARQL syntax section? That way > > readers would get > > > a better feel for how one form translates into the other. > > > > Nack. DanC and DaveB (I think) have suggested that we not use bNodes > > in the first example. Thus the SVG will have to be reworked so it's > > not worth bringing the following examples to convergence. > > > > > ----------------------- > > > last paragraph > > > > > > Where doesn't the "andy" come from? I don't see him in the > graph above. > > 1.97: > > [[ > > ...known by Alice (specifically, the person with the mbox > > alice@work.example) > > ]] > > > > > ------------------------ > > > 2.1 Writing a Simple Query > > > > > > Second paragraph, "The terms quoted ..." > > > > > > It's a fair distance from this sentence to the actual example > > below, and the > > > reader's eyes have to jump down to the example and then find > > their way all > > > the way back up again. Why not move this paragraph to either after the > > > "Data:" section or after the "Query:" section? > > 1.97: > > I didn't want to break up the association between Data, Query, > > Results, so I moved the explanation below the results. It's an after > > the fact explanation, but that may be clearer. > > > > > ---------------------- > > > 2.2 Triple Patterns > > > > > > I'm not sure if this requires a bit of reorg or not, but all > > the examples in > > > the preceding section have WHERE clauses containing triple > > patterns, but you > > > don't introduce the concept until here. > > > > Nack. Yeah, but they don't know it yet. I think this is a fairly good > > solution to the usual tension caused by needing to introduce > > everything at once. > > > > > More importantly, you never say what a triple pattern IS (ie, > something > > > along the lines of "A template for describing an s-p-o triple, with > > > variables representing missing information to be filled in by > > the query" or > > > some such. That would be very useful for reader. > > > > > > At a minimum, I'd change sentence one from > > > "The building blocks of queries are triple patterns" > > > to > > > "The building blocks of queries are triple patterns, shown as > > the arguments > > > of the WHERE clauses in the three queries in the preceding section." > > > > > > --------------------- > > > As well, a brief sentence explaining that triple patterns are > > delimited by > > > parentheses ("(" and ")") would be useful. > > 1.97: > > [[ > > The building blocks of queries are triple patterns. Syntactically, a > > SPARQL triple pattern is a subject, predicate and object enclosed in > > '()'s. The previous example shows a triple pattern with a variable > > subject (book), a predicate of dcore:title and a variable object > > (title). > > > > ( ?book dcore:title ?title ) > > ]] > > > > > -------------------- > > > Paragraph 2, "A triple pattern has either a graph label > > (URIRef, literal) or > > > a named variable in each of the subject, predicate and object > > positions." > > > Literals of course can only go in the object position. Is it ok > > to be this > > > imprecise? (I'm asking because I don't know and don't have a strong > > > opinion.) > > > > Nack. (the question didn't result in a change of text.) > > > > A lot of people think that RDF triples should be fully > > symmetrical. I'm agnostic on this, but don't feel compelled to > > complicate the spec to reduce the expressivity to RDF. Model > > conformance can be enforced practically -- people generating queries > > will not see data that requires literals in the predicate or subject. > > > > > ---------------------- > > > Definition: Triple Pattern > > > "3" -> "three" > > ?.??: > > addressed by Andy's earlier changes to the defintion. > > > > > ---------------------- > > > 2.3 Graph Patterns > > > First paragraph, "This starts with conjunction - the 'and' of triple > > > patterns." > > > > > > It's not clear what "This ..." refers to. How about something > > like, "We'll > > > first look at conjunctions, which combine triple patterns using "and". > > 1.97: > > [[ > > The keyword WHERE is followed by a Graph Pattern which is made of one > > or more Triple Patterns. These Triple Patterns are "and"ed > > together. More formally, the Graph Pattern is the conjunction of the > > Triple Patterns. In each query solution, each triple pattern must be > > satisfied with the same binding of variables to values. > > ]] > > Better? > > Sort of an oversimlification (elides OPTIONALs and maybe ORs if they > > get in the lang). > > Good enough? > > > > > ----------------------- > > > Paragraph starting "There are is a bNode ..." > > > > > > 1) "are is" -> "is" > > ?.??: > > Andy got it. > > > > > 2) I don't understand the final clause in second sentence: ", > nor to any > > > query." > > 1.97: > > [[ > > There is a bNode [12] in this dataset. Just within the file, for > > encoding purposes, the bNode is identified by _:a but the information > > about the bNode label is not in the RDF graph. No query will be able > > to identify that bNode by name. > > ]] > > I wrestled with "identify that bNode by the name _:a" but it seemed > > worse. > > > > > ------------------------ > > > 2.4 Multiple Matches > > > > > > "The results of query" -> "The results of a query" > > 1.97: > > > > > ------------------------ > > > 4.2 Multiple Optional Blocks > > > > > > Second paragraph, you introduce the concept of outer block. > > This hasn't been > > > previously discussed, so it's unclear what this refers to. > > Please define. As > > 1.97: > > [[ > > In this example, there are two, independent optional blocks. Each > > depends only on variables defined in the non-optional part of the > > graph pattern. > > ]] > > > > > well, you follow with a hypothetical, "If a new variable is > > introduced in an > > > optional block ...", a short "WHERE" snippet example showing > > this would be > > > very helpful. > > 1.97: > > wordsmithed text to show it from the previous example > > [[ > > In this example, there are two, independent optional blocks. Each > > depends only on variables defined in the non-optional part of the > > graph pattern. If a new variable is introduced in an optional block > > (as mbox and hpage are introduced in the previous example), that > > variable can be bound in that block and can not be mentioned in a > > subsequent block. > > ]] > > Slightly awkward, but an improvement in clarity, I think. > > > > > ------------------------ > > > 4.3 Optional Matching > > > > > > Is there a new syntactic feature introduced here? If so, an > > example would be > > > helpful. > > 1.97: > > This section is a definition for the syntactic feature introduced > > in 4.1 by > > [[ > > Optional portions of the graph may be specified in either of two > > equivalent ways: > > ]] > > I changed the titles around to reflect that: > > s/4.3 Optional Matching/4.3 Optional Matching -- Formal Definition/ > > s/4.1 Optional binding/4.1 Optional Matching/ > > > > > ------------------------ > > > 5 Nested Patterns > > > > > > It would be useful to introduce this section with a brief > explanation of > > > what nesting is. Ie, What is its purpose? Why is it useful? > > > > Nack. Punting. I want to wait until the WG decides whether to include > > OR in the language before attacking this. > > > > > ------------------------ > > > Final example in section: > > > > > > I don't see a correspondance between the arguments of the > > SELECT statement > > > and the headings in the result table. "mbox" would have to be > > SELECTed to be > > > output, wouldn't it, and what happened to "name"? > > 1.97: > > changed SELECT to make example internally consistent (and still > sensible) > > [[ > > SELECT ?foafName ?mbox ?fname ?gname > > ]] > > > > > ------------------------ > > > 8 Choosing What to Query > > > > > > Third paragraph, "To execute a query, there needs to be the > > query and an RDF > > > graph." > > > Awkward. How about: "Query execution requires both a query and an RDF > > > graph." > > 1.97: > > [[ > > A SPARQL query must be executed against some real or virtual RDF > > graph. > > ]] > > > > > ------------------------- > > > 9 Querying the Origin of Statements > > > > > > I realize you have a footnote on the first sentence saying the > > semantics are > > > undefined, but how about at least a very loose explanation of > > what a SOURCE > > > is in the paragraph itself, so the reader at least has a rough idea of > > > you're talking about? Maybe the footnote could be reworked and > > moved into > > > sentence number two? Ie, something like (I'm not claiming this is > > > technically accurate): > > > > > > " ... many RDF data stores augment this with the source of each > > statement. > > > Source is at present undefined, but is expected to refer in some > > > implementation-dependent way to the document of origin, > > possibly given by a > > > URL." > > > > > > or some such. > > 1.97: > > I hit it with my (real or virtual) real-or-virtual hammer. > > [[ > > While the RDF data model is limited to expressing statements with a > > subject, predicate and object, many RDF data stores augment this with > > a notion of the source of each statement. Typically, > > implementations associate RDF triples or graphs with a URI specifying > > their real or virtual origin. > > ]] > > > > > ------------------------ > > > 10 Summary of Query Patterns > > > > > > Does the bullet "disjunction" correspond to the "alternatives" > > mentioned in > > > "6 More Pattern Matching - Alternatives"? I don't know the ultimate > > > dispostion of this section but suggest if it stays and is > > mentioned in this > > > list, that the terminology be made consistent. > > ?.??: > > That reference, and the whole neighborhood, was wiped out by > > Hurricane Andy. > > > > > ------------------------ > > > 11.2 Constructing an Output Graph > > > > > > I'm confused by the three boxed snippets. #3 is labelled > > "Example" -- are > > > the first two NOT examples as well? What distinguishes #3 from > > #1 and #2? > > > > > > Also, #3 has "PREFIX . . . CONSTRUCT". Are the ellipses part of > > the syntax?? > > ?.??: > > > > > -------------------------- > > > 11.4 Asking "yes" or "no" questions > > > -> 11.4 Asking "Yes" or "No" Questions > > > > > > I'd also invert sentence #1 and tighten a bit: > > > "In order just to test whether a query pattern has a query > > solution or not, > > > the application can use the ASK form." > > > -> > > > "Applications can use the ASK form to test whether a query > pattern has a > > > solution or not." > > 1.97: > > [[ > > Applications can use the ASK form to test whether or not a query > > pattern has a solution. > > ]] > > > > > ------------------------------ > > > 12.1 Standard Operations > > > > > > "The SPARQL language provides some of the operations on plain > > literals, XSD > > > integers and XSD floats taken from those in XQuery and XPath > > Functions and > > > Operators <http://www.w3.org/TR/xpath-functions/>." > > > > > > A bit awkward. Do you mean: > > > > > > "The SPARQL language provides a subset of the operations on > > plain literals, > > > XSD integers and XSD floats defined in XQuery and XPath Functions and > > > Operators <http://www.w3.org/TR/xpath-functions/>." > > 1.97: > > verbatim > > > > -- > > -eric > > > > office: +81.466.49.1170 W3C, Keio Research Institute at SFC, > > Shonan Fujisawa Campus, Keio University, > > 5322 Endo, Fujisawa, Kanagawa 252-8520 > > JAPAN > > +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA > > cell: +1.857.222.5741 (does not work in Asia) > > > > (eric@w3.org) > > Feel free to forward this message to any list for any purpose other than > > email address distribution. > >
Received on Friday, 8 October 2004 19:50:38 UTC