W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2005

Re: SPARQL Protocol for RDF

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 2 Jun 2005 18:44:52 +0300
Message-Id: <af673230a7c65a8164176bd6e83a2e52@nokia.com>
Cc: public-rdf-dawg-comments@w3.org, Danny Ayers <danny.ayers@gmail.com>
To: kendall@monkeyfist.com

On Jun 2, 2005, at 17:01, ext Kendall Clark wrote:
>> - ok, I have doubts about this, and it's appearance in the 
>> latestdraft -
>> default-graph-uri - shouldn't the default graph be 
>> somethingdetermined in
>> the scope of the query engine? If it does need to benamed, shouldn't 
>> that go
>> in the query itself?
> The design we've come up with allows the RDF dataset (which is 
> composed of
> zero or one default (sometimes called "background") graph and zero or 
> more
> named graphs) to be specified either in the protocol, or in the query
> language, or in both. In the case where it is specified in both, but 
> the RDF
> datasets are not identical, the dataset specified in the protocol 
> trumps the
> one specified in the query.

Why is it necessary/beneficial to be able to specify any graphs
in the protocol? Why isn't the query sufficient?  A use case and
some rationale would help understand the (presumed) requirement
for this feature.

> This is spelled out in the latest draft thus:
>   The RDF dataset may be specified either in a legal [SPARQL] query 
> using
>   FROM and FROM NAMED keywords; or it may be specified in the protocol
>   described in this document; or it may be specified in both the query
>   proper and in the protocol. In the case where both the query and the
>   protocol specify an RDF dataset, but not the identical RDF dataset, 
> the
>   dataset specified in the protocol must be the RDF dataset consumed by
>   SparqlQuery's query operation.
> Since both you and Patrick asked about this, this bit must either be 
> vague
> or just doesn't stand out enough in the draft presently. I'll think 
> about
> ways to make it more difficult to miss. :>

Some use cases which clearly illustrate the requirement for the
feature in the protocol would be very valuable.


Received on Thursday, 2 June 2005 15:45:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:06 UTC