Re: solution modifiers & construct/describe

Kendall Clark wrote:
> 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.

True it's example driven but that can't mean there is an example for every 
possible usage pattern.   That would be a whole book.

> 
> 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.
> 

10.1 says:

"""
Query patterns generate a set of solutions, each solution being a function from 
variables to RDF terms. These solutions are treated as a sequence. Any sequence 
modifiers are applied before the solutions are used to form the final query result.
"""

then the definitions use "SM(QS)" to show the application of the modifiers.

Err - CONSTRUCt doesn't clearly - that needs to be corrected.

> 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?

I'd like to make it more permanent (it is currentl broken due to CSS chnages 
:-() and then a link in the doc could be made.  An alternatively, can we provide 
a static page of the definitons and reference that?

> 
> 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.

Err - that woudl make the defintions long, repetitive (obscuring the new salient 
part) and likely inconsistent as changes are made.

> 
> 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.

I can draw the point out somewhere - section 10.1 seems the obvious place to me 
but what text do you suggest over and above what's there?

> 
> 3. Example queries using the SMs w/ describe/construct should be added.

In my opinion, these fall below the cut line.  While there is this feature, it 
is not a partcularly important one for describe/construct as the returned graph 
is limited in ways that the requestor can't necessarily determine (limit/offset 
and ordering are a poor cursor mechanism).  In the case of construct or describe 
I think the use is more to do with error control than slicing graphs.


We should provide a defintions-only document, mechanically extracted from the 
the full document.

> 
> Best,
> Kendall Clark
> 
> PS--I don't think any of this should hold up LC, fwiw.
> 

	Andy

Received on Monday, 27 June 2005 15:57:40 UTC