definitions for SELECT, projection, substitution [was: [Fwd: Re: ...]]

```On Tue, 2004-10-19 at 15:00, Seaborne, Andy wrote:
>
> Steve Harris wrote:
> > On Sun, Oct 17, 2004 at 06:27:31 +0100, Andy Seaborne wrote:
[...]
> >>SELECT projects just the "a" and "b" binding in each.  SELECT does not
> >>change the number of rows in the table;

It doesn't? Where does the spec say that? Surely SELECT is a projection,
which, in typical cases, does change the number of items in the set.

Hmm... the definitions seem to stop after "Definition: Query Results"
without specifying a projection step, i.e. without specifying how
SELECT works.

(http://www.w3.org/2001/sw/DataAccess/rq23/#MultipleMatches 1.120 )

>  SELECT DISTINCT does in this case.

Where is DISTINCT specified? Ah... in 11.1 Choosing which Variables
to Return. I see a semi-formal "Results can be thought of as a
table, with one row per query solution". Please formalize
that in the style of the other definitions, ala...
let's introduce "substitution" as discussed at the Bristol ftf:

Definition:
A substitution S is a functional relation
from variables to terms. We write S[v] for
the term that S pairs with the variable v.

Then:

Definition: Projection

For a substitution S and a finite set of variables
VS, project(S, VS) = { (v, S[v]) | v in VS }

For a query solution Q project(Q, VS) is
{ project(S, V) | S in Q }

For a set QS of query solutions,
project(QS, VS) is
{ project(Q, V) | Q in QS }

Then specify SELECT as a projection. Then it doesn't
matter whether you return duplicates or not in an API
or protocol, since the set {soutionX, solutionX} is the same thing
as the set {solutionX}.

I suggest that DISTINCT has no query language semantics;
it is a protocol keyword that means "don't repeat
substitutions when you tell them to me, please".

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
```

Received on Tuesday, 19 October 2004 21:00:27 UTC