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/
