W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

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

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 10 Nov 2004 18:23:17 -0000
Message-ID: <8D5B24B83C6A2E4B9E7EE5FA82627DC94D32B9@sdcexcea01.emea.cpqcorp.net>
To: "Dan Connolly" <connolly@w3.org>
Cc: "RDF Data Access Working Group" <public-rdf-dawg@w3.org>


Text added in v1.129

	Andy

-------- Original Message --------
> From: Dan Connolly <mailto:connolly@w3.org>
> Date: 19 October 2004 22:01
> 
> 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
Received on Wednesday, 10 November 2004 18:23:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT