Re: REDUCED and the SPARQL XML Results Format

Eric Prud'hommeaux wrote:
> * 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:

I can't see much use for @distinct, but @ordered is a bit more useful.

@distinct, where the result set is likely to be in in-memory as its read off 
the network, isn't that expensive.

For a result processor which did not originate the query (e.g. it was supplied 
as a plain string - or the result set is being passed from one piece of 
software to another) knowing the results are ordered (OK - don't know how they 
are ordered) might drive display decisions such as not to do a sort 
client-side for display consistency.

> 
> 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?)

No, it doesn't - you can eliminate duplicates to get a canonical result set.

e.g ALL is 1,1,2, limit 2

=> 1 and 1,2 are both duplicate-eliminated possible result sets.

 Andy

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

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

Received on Monday, 26 March 2007 11:32:27 UTC