Re: REDUCED and the SPARQL XML Results Format

* Seaborne, Andy <andy.seaborne@hp.com> [2007-03-21 14:39+0000]
> 
> 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.

The key is that is really is NOT defined. That is, whatever reason we
have to communicate the cardinality of ALL ([@distinct="false"]), is
also a motivation to communicate loose cardinality. I don't see a lot
of people making use of @distinct, @ordered or @loose except those
using the SPARQL query tests; each has a distinct testing semantics:

ordered: make sure the order is the same
unorderd: you can sort both and compare.

distinct: make sure there is a one-for one correspondance between test and ref
loose: you can eilminiate dupes in your test (or equivilent algorithm)
neither: make sure there is a one-for one correspondance between test and ref

(hmm, does [@ordered="true" AND @loose="true"] have any use cases?)


> 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.

how about, a wierd results aggregator that didn't otherwise need to
parse the query? pretty wierd, huh?

Any interesting superlanguage would have to parse, in order to
re-write and finalize stuff like
  SELECT ?name ?year SUM(?pay)
   WHERE { ?person :name ?name .
           ?person :monthlyCheck ?check .
           ?check :amount ?pay .
           ?check :issueYear ?year }
   GROUP BY ?year
so I think our users are basically us, and we can, if we want, get
that info from the query.

> I don't know of any use of the attributes other than just to record 
> information that is also in the query request.

i'm content to dip back trhough LC, mark the whole lot of the attributes
"at-risk", and see if anyone cares about them. but then, maybe i'm too
excited abou the at-risk tool.

> 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?
> 
> 
> The JSON format [3] is also impacted.
> 
> 	Andy
> 
> [1] http://www.w3.org/TR/rdf-sparql-XMLres/
> [2] http://www.w3.org/TR/rdf-sparql-XMLres/#vb-results
> [3] http://www.w3.org/TR/rdf-sparql-json-res/
> 
> 
> 

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.