- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 21 Mar 2007 17:27:25 +0000
- To: dawg mailing list <public-rdf-dawg@w3.org>
On 21 Mar 2007, at 14:39, Seaborne, Andy wrote: > > There is an interaction between REDUCED and the SPARQL Query > Results XML > Format [1]. The results format defines a variable binding form [2] > which > includes a 'distinct' attribute: > > <results distinct="false"> > ... > </results> > > Which brings up the question of what happens with a REDUCED query? > > We could add a similar 'reduced' attribute, which could not be > present when 'distinct' is, or have both and only one can be true. > An alternative design is have a single attribute/value of something > like: "cardinality=distinct/reduced/all" which is more disruptive. > > But because the cardinality of REDUCED is not completely defined, > there is no need to do anything: the results could just come back > with distinct="false" and no promise is broken. > > So significant here is what use is made, for real, of the > attributes in SPARQL results files (which are in CR). If the > answer is "not much" then not doing anything is more acceptable to > me. If we know of a significant use, we need to see the impact. > > I don't know of any use of the attributes other than just to record > information that is also in the query request. > > > Subsidiary questions: > > If there is way to indicate "reduced", and the service > implementation of REDUCED is to do "all" for this service request, > can the service just omit the reduced because results are all present? > > If there is way to indicate "reduced", and the service > implementation of REDUCED is to do DISTINCT? Is it permissible to > set the 'distinct' attribute true? Woudl we recommended to doing so? FWIW, my preference is to not explicitly flag REDUCED result sets as such. Whether the distinct attribute should be set where appropriate is an interesting question. It also applies to SPARQL services that currently implicitly DISTINCT. - Steve
Received on Wednesday, 21 March 2007 17:27:33 UTC