[Fwd: Unexpected DISTINCT?]

The modifier order is:

     * 9.1 ORDER BY
     * 9.2 Projection
     * 9.3 DISTINCT
     * 9.4 OFFSET
     * 9.5 LIMIT

so the test is correct.

We don't document anywhere (IIRC) anything about auto DISTINCT.

When DISTINCT is applied after ORDER.  The ORDER step emits [1, 1, 2, ...] so

limit(
    distinct([1, 1, 2, ...]),
    2)
    = [1, 2]


The question of implicit DISTINCT remains -

Any opinions of saying anything about implicit DISTINCT for simple entailment 
(all we define SPARQL for).  Because DISTINCT is after projection, there are 
several ways to get duplicates, all of which are well-defined within BGP 
matching (blank nodes for simple entailment matches), the algebra (UNION), and 
projection.  Just projection alone suggests to be that we should not define 
implicit DISTINCT and leave it to implementations to provide as an extra but I 
don't have a strong opinion to that effect.

	Andy

-------- Original Message --------
Subject: Unexpected DISTINCT?
Resent-Date: Sun, 25 Feb 2007 17:58:17 +0000
Resent-From: public-rdf-dawg-comments@w3.org
Date: Sat, 24 Feb 2007 23:27:53 -0800
From: Richard Newman <rnewman@franz.com>
To: public-rdf-dawg-comments@w3.org


DAWG,

    I have an implementation question for which I cannot find an
answer in the spec.

    Given a SELECT query for which some results are duplicated, and
which does not specify DISTINCT, is it acceptable for an
implementation to return DISTINCT (or partially DISTINCT) results?

    This is exercised by <http://www.w3.org/2001/sw/DataAccess/tests/
#modifer-limit>:

- with no DISTINCT processing, the results are [ 1, 1 ].
- with DISTINCT processing, the results are [ 1, 2 ].

    I seem to recall from informal sources that this is acceptable,
but it would be good to get a firm documented answer, particularly
when I can see that this could be contentious.

    Thanks,

-R

Received on Monday, 26 February 2007 16:03:59 UTC