Re: WHERE clause optional?

On Fri, 08 Apr 2005 15:17:25 +0100, Graham Klyne <gk@ninebynine.org> wrote:

> At 13:30 08/04/05 +0100, Dave Beckett wrote:
> Hmmm, maybe.  Let me expand a little:  I see my query processor working 
> something like this:
> 
>    Locate graph(s) to query
>    >> match query pattern against graph

That won't work for DESCRIBE <uri> when there's no query pattern or constraint.

>    >> construct desired result from match (per SELECT/CONSTRUCT/ASK)
> 
> The result of the second step is, I think, a collection of variable 
> bindings and a set of triples used for each.  The CONSTRUCT clause is 
> applied for each member of this collection.  Now, if there is no pattern to 
> match, how many times is it matched?  For your interpretation to work under 
> this regime, it must be at least once or the result graph would be empty.

I said it could be a legal query.  The current wording is talking about
constructing per-match.  My example had 0 matches, ergo there is no construction
so the result is 0 triples, an empty RDF graph.  But this is hard to figure out.

> One alternative is that a null pattern matches *any* graph, so there may be 
> an arbitrary number of matches (number of permutations of triples in the 
> queried graph (or number of subgraphs), I suggest), but the result is still 
> as you say because each match generates the same result and a graph is a 
> _set_ of triples.  This works, but it feels a bit messy to me.
>
> But that's not consistent, or a non-null pattern would match for each 
> subgraph of the original that it matches.  Observing that (with a non-null 
> pattern) every triple of a matched subgraph is used for each match 
> generated, so a null pattern would exactly match a null subgraph, and every 
> graph has exactly one null subgraph, so the null pattern would consistently 
> match any graph exactly once.  This sits nicely with your example.

I suppose that works; 'where {}' or omitted always returns 1 match with no
bindings.

> A consequence of this would be that:
>    prefix ex: <http://example.org/>
>    ask
> always returns the value True.
> 
> ...
> 
> BTW, I see you use lowercase in your SPARQL examples:  keywords are all 
> uppercase in the grammar -- are they meant to be case-insensitive?  I can't 
> find anything in the spec to tell me about this.

It's in the grammar, at least in the editor's draft I reviewed
last. I don't bother typing uppercase sparql keywords except when
eneded for clarity reasons.  The only keyword that is lower-case only
is'a' - the turtle keyword, in the editor's draft.

Dave

Received on Friday, 8 April 2005 15:02:23 UTC