Re: [Fwd: Unexpected DISTINCT?]

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