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

Re: Graph store protocol editor's draft updated

From: Chimezie Ogbuji <chimezie@gmail.com>
Date: Tue, 14 Feb 2012 00:33:51 -0500
Message-ID: <CAKSO3unP_QxNzmpNLsUCFxWpZ+ko=GjSW9mRxTFBuLDo68bkrg@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
We discussed these changes in our last teleconference, so I'm
surprised that you weren't expecting them.  See my response below.

On Mon, Feb 13, 2012 at 2:34 PM, Sandro Hawke <sandro@w3.org> wrote:
>>  - Removed Protocol service discovery section 5.8 (addressing issue of
>> confusion regarding SPARQL protocol URL and that of a GSP
>> implementation)
>>  - Changed URL used to for indirect identification to reflect that it
>> identifies a graph store (removed all references to 'service')
> I wasn't expecting these changes together, like this.   Like this, it is
> impossible for a client to construct an indirect graph IRIs, since (as
> the spec says) the graph store IRI needs to be known "a priori".

As I've said (many times) before:  without a discovery method, this
will remain a problem.  I don't see how how using the service as the
'base' for constructing indirect IRIs makes this problem go away since
the 'service' URL will still need to be known 'a priori' and a) there
is no mechanism to discover it and b) the GSP is explicitely divorced
from the SPARQL protocol.  As you allude to below, this also muddles
the protocol model. The combination is more problematic than these
changes, in my opinion.

> I really liked indirect IRIs, and I think the Provenance WG was counting
> on them, since they let folks use an IRI to talk about a graph in
> SPARQL-land.  But now they don't do that any more.
> I'd be okay with either:
>  (1) putting 5.8 back

Note, Greg is not okay with this.

> or
>  (2) building the indirect IRIs off the endpoint address instead of the
> graphstore address.   (I think this is the vastly preferable solution,
> BTW, because it's just so simple, even if the modeling isn't quite as
> elegant.)

Unfortunately, I don't agree for the reasons stated above.

-- Chime
Received on Tuesday, 14 February 2012 05:34:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:06 UTC