- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Wed, 22 Jun 2005 16:52:24 -0400
- To: DAWG Mailing List <public-rdf-dawg@w3.org>
I have a cluster of issues w/r/t rq23; they fall somewhere between mere editorial suggestions and design issues: 1. I only just realized, by reading the grammar, that limit/offset/order-by solution modifiers can be used with construct & describe. Initially, this seems like a mistake in the grammar. So I go to the describe & construct parts of the spec, thinking that if I saw an example including these SMs, then I could infer what the semantics are, especially since this is supposed to be an example-driven spec. But there are no such examples. Bother... so what do they mean? I guess, next, that if I look at the description of the solution modifiers themselves, that will tell me what their semantics are w/r/t describe & construct. Again, no joy, since there's no mention... 2. Now I'm bothered, because there's a condition that the grammar says is legal (namely, CONSTRUCT|DESCRIBE...LIMIT n ORDER BY m OFFSET o), and I can't get the spec to tell me what the semantics of this condition is. 3. I decide to look at the definitions to see if they mention any of this. Hmm, sorta, but not really. They are so far apart in the spec, and they don't always define all of their terms (for example, "QS" isn't defined in the DESCRIBE definition... Does it mean "query solutions"? Maybe? I don't know)... But I decide that the project(SM(QS), VS) bit in DESCRIBE's defintion means that the SMs are applied to the query "hits" or solutions, which are then written into a graph. Uh, okay, this isn't incoherent... I don't really like it, per se, but the spec *really* needs to talk about this, provide examples, something, because how many users are going to study the grammar carefully? And this is assuming that I've correctly guessed what the semantics are, since the spec doesn't state them clearly, and there are other competing interpretations -- which may not be as plausible, but who's to say? (I assume the spec says clearly some place that SMs are only ever applied to query solutions, or "hits", and not to the results form (whether XML or RDF), and from that statement one can infer the likely semantics of SMs applied to describe & construct -- if so, this is far, far too oblique for a spec, IMO, and the semantics should be stated explicitly.) I'd like to make some recommendations based on this little odyssey: 1. The formal definitions should be gathered together and moved into an appendix of the spec (it can be normative or informative, I don't really care), so that they can be read & evaluated altogether. I appreciate the XSLT extraction script, but what status (or permanence) does it have? 1'. Alternately, no definition terms should be carried forward from earlier definitions -- all terms in every definition should be explicitly defined in every definition. As-is, the definitions are too far apart to carry forward terms, IMO. 2. Some discussion of what the solution modifiers mean w/r/t describe & construct should be added somewhere in the spec, ideally in the describe & construct sections. 3. Example queries using the SMs w/ describe/construct should be added. Best, Kendall Clark PS--I don't think any of this should hold up LC, fwiw.
Received on Wednesday, 22 June 2005 20:53:35 UTC