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

Re: [Fwd: Unexpected DISTINCT?]

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 05 Mar 2007 09:29:13 +0000
Message-ID: <45EBE2E9.1080303@hp.com>
To: Bijan Parsia <bparsia@cs.man.ac.uk>
CC: Lee Feigenbaum <feigenbl@us.ibm.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>



Bijan Parsia wrote:
> 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).
> 
> Cheers,
> Bijan.

The cardinality for extensions of BGP matching isn't prescribed by the spec - 
it's just a matter of an extension deciding what is appropriate for it's 
extension.

http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#sparqlBGPExtend

which does not include anything on cardinality induced from blank nodes in 
BGPs.  Hopefully, that should give freedom to extended matchings such as OWL-DL.

	Andy
Received on Monday, 5 March 2007 09:29:25 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:36 GMT