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

Re: draft response for PW1

From: Carlos Buil Aranda <cbuil@fi.upm.es>
Date: Fri, 29 Jun 2012 09:37:20 -0400
Message-ID: <CABdcz9FenvztODmb+2RoMe8YMdn3YayGHFoBDjoQiQM5FsnjrQ@mail.gmail.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Cc: public-rdf-dawg@w3.org
Hi Andy,

I agree about the point that SERVICE is to send a query to another place,
nothing more. Also, I wanted to point out that the use of GRAPH would be
enough if he wanted to select some of the graphs in the remote dataset and
there might not be the need of specifying the dataset.

I will add your comments to the answer.

thanks,


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 Friday, 29 June 2012 13:38:14 GMT

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