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...
hmm... "set of bindings" is awkward to write about... please
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