Re: draft response for PW1

yes, it would be only an editorial change, just modify at the beginning of
Section 2 sonething like this:

The SERVICE keyword instructs a federated query processor to invoke a
portion of a SPARQL query against a remote SPARQL endpoint that complies
with the SPARQL Protocol [SPROT]

2012/7/3 Polleres, Axel <axel.polleres@siemens.com>

> In what form would tyou want to reference reference to the SPARQL protocol?
> If it's only an editorial change that clarifies matter, that should be ok,
> IMO.
>
> Axel
>
>
> --
> Dr. Axel Polleres
> Siemens AG Österreich
> Corporate Technology Central Eastern Europe Research & Technologies
> CT T CEE
>
> Tel.: +43 (0) 51707-36983
> Mobile: +43 (0) 664 88550859
> Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com
>
>
>
> ________________________________
>
>         From: Carlos Buil Aranda [mailto:cbuil@fi.upm.es]
>         Sent: Tuesday, 3 July 2012 4:48 PM
>         To: Andy Seaborne; Gregory Williams
>         Cc: public-rdf-dawg@w3.org
>         Subject: Re: draft response for PW1
>
>
>         Dear all,
>
>         I updated the response to PW. However and looking at the document,
> I think that it is a bit underspecify and it should be added a reference to
> the SPARQL protocol next to the explanation of what the SERVICE keyword
> does. Would it be possible to add it informally?
>
>         Carlos
>
>
>         2012/6/29 Andy Seaborne <andy.seaborne@epimorphics.com>
>
>
>                 I wonder if there is a need to specify the dataset.  The
> point about SERVICE is to send the query to another place, presumably
> because it has the data and the sender, and their service engine, does not.
>  This is emphasising the general SPARQL service that reads graphs off the
> web and queries them.
>
>                 Dataset description is used to select graphs from a local
> pool.  The use of GRAPH maybe enough to allow the sender to select the
> graphs of interest.  The only case missing is a merge of graphs to be the
> default graph.
>
>                 If an application wants to access a general purpose SPARQL
> processor, then it uses the the SPARQL protocol - not as part of a query
> because , after all, SERVICE happens inside a local query execution.
>  Shipping off a subpart of the query from one SPARQL engine to another
> seems a minor use case and if we were addressing that, there is a lot of
> other machinery that we'd want to put in place.
>
>                         Andy
>
>
>                 On 28/06/12 22:11, Gregory Williams wrote:
>
>
>
>                         On Jun 28, 2012, at 4:43 PM, Carlos Buil Aranda
> wrote:
>
>
>
>                                 Dear all,
>
>                                 I attach the draft response for PW-1
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Jun/0007.html<
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Jun/0007.html
> >
>
>                                 draft:
> http://www.w3.org/2009/sparql/wiki/CommentResponse:PW1 <
> http://www.w3.org/2009/sparql/wiki/CommentResponse:PW1>
>
>
>
>                         Hi Carlos,
>
>                         You say: "in the SPARQL 1.1 grammar there is no
> way for specifying the default dataset to query."
>
>                         Am I simply misunderstanding what you're saying?
> For query, you specify it with FROM/FROM NAMED.
>
>                         You continue:
>
>                         """
>                         In the same way there is no mechanism for
> specifying named graphs since the SERVICE keyword only provides mechanisms
> for directing specific pieces of SPARQL queries to an SPARQL endpoint.
> Thus, you correctly understood the specification.
>                         """
>
>                         I've brought this up before, but why can't the
> dataset for a SERVICE be specified using protocol parameters? i.e.:
>
>                         SERVICE <
> http://example.com/sparql?default-graph-uri=XXX&named-graph-uri=YYY <
> http://example.com/sparql?default-graph-uri=XXX&named-graph-uri=YYY> > {
> ... }
>
>                         Shouldn't this just work? (Assuming implementors
> have done the legwork to choose between using '?query=' and '&query=' when
> constructing the service invocation URI.)
>
>
>                         """
>                         The other possibility you point out (to send the
> default and named datasets defined by the main query) is not allowed: the
> SERVICE keyword translates the pattern inside into a new query to the
> remote dataset, using a SELECT * WHERE {...} without specifying the
> original query datasets. However, inside the SERVICE clause you can use a
> subquery in which you can specify to which graph direct the query:
>
>                         PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>                         SELECT ?name
>                         WHERE {
>                           SERVICE <http://example.org/sparql> {
>                            SELECT * WHERE
>                            {
>                             GRAPH <http://example.org/graph>
>                              { ?person foaf:name ?name ; foaf:mbox ?mbox }
>                            }
>                           }
>                         }
>                         """
>
>                         That won't specify the dataset, though. It only
> specifies the active graph for matching the two triple patterns.  Is that
> what you are intending to point out?
>
>                         .greg
>
>
>
>
>
>
>
>