W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2007

RE: [Fwd: Unexpected DISTINCT?]

From: imikhailov <imikhailov@openlinksw.com>
Date: Mon, 5 Mar 2007 19:22:58 +0600
To: "'RDF Data Access Working Group'" <public-rdf-dawg@w3.org>
Message-ID: <E1HOD9a-0000aO-9x@lisa.w3.org>


IMHO, explicit ALL and implementation-specific default could be nice. But if
select is implementation-dependent then UNION should become UNION ALL /
UNION / UNION DISTINCT with unspecified behaviour for UNION. That's OK for

In addition, BEST EFFORT UNION can be good addition for distributed systems.
But this is too specific for common use and it has as significant
disadvantage as two extra keywords. So this is not for the core of the

> SQL defaults to ALL because, I think, of the strong perception that it is
"always" cheaper.
Yes, the perception is true for 'not very distributed' systems. SPARQL is
definitely not similar to SQL in this aspect.

Best Regards,
Ivan Mikhailov
OpenLink Software.

-----Original Message-----
From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
On Behalf Of Bijan Parsia
Sent: Monday, March 05, 2007 2:58 PM
To: Lee Feigenbaum
Cc: RDF Data Access Working Group
Subject: Re: [Fwd: Unexpected DISTINCT?]

In SQL, SELECT has two parameters, ALL and DISTINCT with ALL being implicit.

One way to handle the sort of variability in result set desired here is to
make ALL *not* be implicit, but have the bare SELECT mean something like
"something between ALL and DISTINCT depending on the implementation".

SQL defaults to ALL because, I think, of the strong perception that it is
"always" cheaper (which in fact depends on the relative cost of pruning dups
and transmitting them). Making the default "whatever the implementation
thinks is cheapest" seems in the spirit of this and ALL allows access to the
max sane result set (plus, implementations can chose not to support it...it
can be tricky in OWL since you'd have to get all derivations...not
impossible but non-trivial).

Received on Monday, 5 March 2007 13:23:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:53 UTC