Attributes in the results format

[fulfillment of an unrecorded action :-) ]

Currently, in the results format, we have two attributes that record whether 
the results are ordered and whether they are distinct. [1]

<results ordered="false" distinct="false">


With the introduction of REDUCED, we need to consider what we do, if anything.

Further, in the discussion [1], it seems that the meaning of the attributes is 
not completely clear or as expected:

Lee quoted:
"""
The distinct attribute indicates that the results are distinct (contain no
duplicates), such as given by a SPARQL query using SELECT DISTINCT.
"""
which reads as if distinct="true" must be used if the results are distinct 
even if the query did not use DISTINCT.  This breaks streaming because the 
<results> attributes go before all the results are seen.

Similarly:
"""
The ordered attribute indicates whether or not the results have an ordering, 
such as given by a SPARQL query containing ORDER BY.
"""

For example:

?x=1
?x=2

is always ordered - so should ordered="true" be specificed?  Problems arise 
with partially ordered results - we didn't specify the ordering relationship, 
nor the variables involved so it may be "ordered by" but it does not tell us 
in which order, or even the direction (hard to determine when there is a 
partial ordering - you can't just look at the first solutions that are not the 
same; if it is order by expression, nothing is certain.)

I see the following possibile ways forward:

1/ Keep the status quo.  Nothing for REDUCED, weak text for definitions.

2/ Make the attributes only be true when explicitly requested.
    2a/ No reduced="true"
    2b/ Add a reduced=

3/ Drop one or both of the current attributes.  Fix or leave the other.

I think the intention was to use attributes to specificy whether an explciit 
distinct or ordered request was made (by including the keywords or vai an 
API), not to make the query processor determine the fact for the client in 
query requests without some explicit marker.  That is the "such as" means this 
is "one way of doing it but alternative indications, like API calls are OK".


I am against (1) and for (3), dropping both attributes.

I can live with variations of (2), which is to fix things up.  I've not 
actually seen a good use for the attributes - it's only the case of passing 
through queries that seems to have any impact and since the outcome, 
especially the potentially efficient "ordered=", is underdefined, they seem to 
have little value now.

 Andy

[1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0169.html
and thread

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

Received on Monday, 30 April 2007 14:07:05 UTC