- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 05 Mar 2007 09:29:13 +0000
- 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 UTC