solution modifiers & construct/describe

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