- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Mon, 18 Oct 2004 13:50:38 +0100
- To: "'RDF Data Access Working Group'" <public-rdf-dawg@w3.org>
On Sun, Oct 17, 2004 at 06:27:31 +0100, Andy Seaborne wrote: > >1. Is the SELECT clause really useful? My implementations return all > >variable bindings from the query, and I simply ignore those I don't want. > > > >... > > Locally, that is true - I'm sure that when the query processor and the > application are in the same process, the QP may ignore the SELECT (I know > I do for everything except presenting results - anything else would be > pure overhead). Also SELECT allow you to specify ordering of result columnss, which can e helpful for XSLT processing or similar. > >6. Can the resulting variable bindings contain repeated > >binding-tuples; e.g. in response to a query like: > > SELECT ?a ?c > > WHERE ( ?a ?b ?c ) > >against the graph: > > :s1 :p1 :o1 . > > :s1 :p2 :o1 . > > Yes - there can be repeated rows in the table. It's a bag by the time > SELECT has projected out any variables. > > There seems to be a problem with terminology that needs correcting. The > term "query solution" is used but it is confusing where it applies. At > least the Query Results definition either has to use "bag" or be clear > what it applies to. Alternative naming might also help. > > There are two solutions (sets of bindings for variables "a" "b" and "c") > to the pattern match. Query solutions are not effected by the query > result form. > > The query form takes solutions and transforms them into the > application-level results. (Implementations may, of course, use all > information available in the query request and dataset to perform > optimizations to query execution.) > > SELECT projects just the "a" and "b" binding in each. SELECT does not > change the number of rows in the table; SELECT DISTINCT does in this case. > > The language in the document is clearly confusing and I will go back and > find better wording and terminology in the pattern matching sections and > query form sections. > > [Steve - you may wish to comment here] You certainly would expect repeated results if you think of it as a results table, I'm not sure sure about when you think of it of a set/list/bag of bindings. Someone (posibly SimonR?) mentioned that they wouldnt expect multiple identical "rows" from a variable binding result, but that outside my experience really. 3store only returns unique results, and its never caused any problems to my knowledge. Theres a slight overhead, but its not that great and gnerally offset (time wise) by the bandwidth saving. I have no strong feelings either way. If we dont specify unique results then I would like a DISTINCT keyword or equivalent. - Steve
Received on Monday, 18 October 2004 12:50:46 UTC