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

Re: how to specify that in SERVICE VAR how we query all possible sparql endpoints

From: Carlos Buil Aranda <cbuil@fi.upm.es>
Date: Mon, 1 Aug 2011 08:56:59 -0400
Message-ID: <CABdcz9GmdLMPDSJSTSNDrHVLTDnCfOh84NELKZc1vGO0HLjNBQ@mail.gmail.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Cc: public-rdf-dawg@w3.org
By the way, since the SERVICE VAR section is informative, could I add a
reference to a research paper which points to a formal evaluation of SERVICE
VAR? I would add to the document something like: "The exact mechanism for
doing this is not defined in this document. Existing literature about this
particular topic [1] propose ways for safely executing SERVICE VAR
patterns."

what do you think?

cheers,

Carlos

[1] Buil-Aranda, C. and Arenas, M. and Corcho, Oscar (2011) *Semantics and
Optimization of the SPARQL 1.1 Federation Extension.* In: 8th Extended
Semantic Web Conference

2011/7/31 Carlos Buil Aranda <cbuil@fi.upm.es>

>  Thanks for your comments Andy,
>
> I just applied and uploaded them to the CVS.
>
> cheers,
>
>
> Carlos
>
> On 29/07/2011 8:50, Andy Seaborne wrote:
>
>> Comments on v1.65.
>>
>> Overall:
>>
>> 1/ the SERVICE/BINDINGS relationship example needs changing - suggestion
>> below.
>>
>> 2/ Some editorial things in passing.
>>
>> Other than that, it looks good-to-go to me.
>>
>>    Andy
>>
>>
>> ** Abstract
>>
>> s/of a SPARQL/of SPARQL/
>>
>> ** Intro
>>
>> "consumers" -> "data consumers"
>>
>> "joined with results" -> "combined with results"
>>
>> Both are correct but at this level, join seems a bit techy.
>>
>> s/.././ at end of para.
>>
>> ** 2.2
>>
>> "Data in default" -> "Data in the default"
>> "and data in default" -> "and data in the default"
>>
>> ** 2.3
>> "SILENT token" -> "SILENT keyword"
>> token a feature of parsing
>>
>> ** 2.4
>> "BINDINGS" -> "<tt>BINDINGS</tt>"
>>
>> "SERVICE and BINDINGS are combined"
>> ->
>> "SERVICE and BINDINGS can work together"
>>
>>
>> Example:
>> (this is a rough outline and needs editing to fit it into the document)
>> [NB: No BINDINGS no OPTIONAL in the top level query]
>>
>>
>> Suppose we have the query:
>>
>> PREFIX : <http://example.org/>
>> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>> SELECT ?s ?o
>> {
>>  ?s a foaf:Person
>>  SERVICE <http://example.org/sparql> {?s foaf:knows ?o }
>> }
>>
>> [NB: No BINDINGS no OPTIONAL.
>>
>> An implementation may choose to execute this as:
>>
>> 1/ Determine that "?s a foaf:Person" has 3 answers, :a :b :c
>>
>> 2/ Instead of asking {?s foaf:knows ?o } at the remote endpoint, it
>> restricts ?s by using BINDINGS:
>>
>> PREFIX : <http://example.org/>
>> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
>> SELECT *
>> {
>>  ?s foaf:knows ?o
>> } BINDINGS ?s { (:a) (:b) (:c) }
>>
>> If <http://example.org/sparql> contains a very large database,  {?s
>> foaf:knows ?o } may result in very large set of results.  By passing over
>> restricts for :s, the query process involding SERVICE limits the data
>> returned to the data it needs for the overall query.
>>
>>    Andy
>>
>>
>>
>>
>>
>>
>
>
Received on Monday, 1 August 2011 13:00:47 GMT

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