Not all subqueries have an equivalent, at least not in SQL.
- Steve
On 4 Nov 2007, at 13:05, Alan Ruttenberg wrote:
Is there a reason one would like to do a local subquery? Isn't it
equivalent to something that you could write at top level with about
the same number of characters?
-Alan
On Nov 4, 2007, at 7:55 AM, Steve Harris wrote:
Well, that would be the obvious syntax for a local sub-query too.
- Steve
On 4 Nov 2007, at 12:48, Alan Ruttenberg wrote:
Although I intended that the specification of this was that it was
only legal for an endpoint, as that's what makes it easy. I'm not
sure it's a useful construct otherwise, as you don't need it
nested in the FROM if you have to download the file.
-Alan
On Nov 4, 2007, at 7:38 AM, Alan Ruttenberg wrote:
Good point. Perhaps FROM ENDPOINT.
-Alan
On Nov 4, 2007, at 7:35 AM, Steve Harris wrote:
On 4 Nov 2007, at 04:09, Alan Ruttenberg wrote:
This is a particularly easy one, since it adds no new
expressivity. The form
below can be syntactically transformed into SPARQL as specified
now by way
of using the SPARQL protocol for the construct in the FROM.
Since this is the only reasonable way we have to do federation
now, within
spec, it's more like adding friendly syntactic sugar.
As far as I can tell there's no way to tell that <http://example.com/sparql?
> is a SPARQL endpoint, rather that a graph served by a CGI
script with no arguments.
- Steve
On 11/3/07, Dan Connolly <[EMAIL PROTECTED]> wrote:
Alan Ruttenberg wrote:
SELECT ?a ?b
FROM ( CONSTRUCT { ?d <b> ?b }
FROM < http://example.com/sparql?>
WHERE { ?b <b> ?d } )
WHERE { ?a <b> ?b }
Yes... the Data Access WG considered this sort of thing briefly;
we didn't see any particular reason not to do it but we...
RESOLVED 2005-01-20: to postpone cascadedQueries; while
federation use
cases are interesting, the designs don't seem mature and the
use cases
are not urgent; with KendallC abstaining.
http://www.w3.org/2001/sw/DataAccess/issues#cascadedQueries
I'm happy to see people playing around with it; I hope the
designs get mature soonish.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
