W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

Re: draft response for PW1

From: Carlos Buil Aranda <cbuil@fi.upm.es>
Date: Tue, 3 Jul 2012 10:47:53 -0400
Message-ID: <CABdcz9HagaCvFBwqoOnrzcOstbAGRrf1+GbvpoF5jZ=f66+BuQ@mail.gmail.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>, Gregory Williams <greg@evilfunhouse.com>
Cc: public-rdf-dawg@w3.org
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
>>
>>
>>
>
>
Received on Tuesday, 3 July 2012 14:48:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:48 GMT