Re: Indirect Graph Identification

Sorry I dropped this thread. Resuming...

On 05/08/2012 01:11 PM, James Leigh wrote:
> On Tue, 2012-05-08 at 11:08 -0400, Sandro Hawke wrote:
>> James, I must apologize for failing to get back to you with an official
>> response to your comment [1].   Since then, a new draft has been
>> published:
>>
>>          http://www.w3.org/TR/2012/WD-sparql11-http-rdf-update-20120501/
>>          
>> ... which may not address your comment, but does change somewhat how
>> indirect graph identification is done.
>>
>> Please let us know if you're satisfied with this response.  If not,
>> please try to suggest some specific change to the document which would
>> address your concern.   Thank you!
>>
> Thanks Sandro, but I am not satisfied. I would like to be assured that
> the working has discussed generalizing indirect requests to allow
> indirect graph requests to co-exists with other types of indirect
> requests. I believe indirect requests is going to become a significant
> social issue for our community and needs a common approach.

I don't think the group has talked about it.  I can request it be on the 
agenda, but I'd like to understand the case better, first.

> I suggest that the working group consider providing a way for the
> indirect graph URL template to be discoverable and avoid explicitly hard
> coding a template pattern in the specification.
>
> I suggest that the graph protocol adopt a service description that will
> include a URL to the default graph and a URL template that can be used
> for indirect graph identification, if the service support such
> indirection.
>
> For example a request like the one below would return a service
> description that would include triples that point to the default graph
> URL and a URL template for indirect graph identification.
>
>
> Given the HTTP request:
>
>          GET /rdf-graph-store HTTP/1.1
>          Host: example.com
>          Accept: text/turtle; charset=utf-8
>
> the graph service responds with a service description.
>
>          HTTP/1.1 200 OK
>          Date: Fri, 09 Oct 2009 17:31:12 GMT
>          Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
>          Connection: close
>          Content-Type: text/turtle
>          
>          @prefix sd: <http://www.w3.org/ns/sparql-service-description#> .
>          @prefix ent: <http://www.w3.org/ns/entailment/> .
>          @prefix prof: <http://www.w3.org/ns/owl-profile/> .
>          @prefix scovo: <http://purl.org/NET/scovo#> .
>          @prefix void: <http://rdfs.org/ns/void#> .
>          
>          [] a sd:Service ;
>              sd:defaultGraphIdentification </rdf-graph-store?default> ;
>              sd:indirectGraphIdentification "http://www.example.com/rdf-graph-store?graph={sd:graphIri}" ;
>              sd:endpoint <http://www.example.com/sparql/> ;
>              sd:supportedLanguage sd:SPARQL11Query ;
>              sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML>, <http://www.w3.org/ns/formats/Turtle> ;
>              sd:feature sd:DereferencesURIs ;
>              sd:defaultEntailmentRegime ent:RDFS  .
>
>
> The predicate sd:defaultGraphIdentification would point to the URL that
> should be used in operations to indirectly identifies the default graph
> in the Graph Store.
>
> The predicate sd:indirectGraphIdentification would have a URL template
> similar to the URL patterns from the OpenSearch specification[2]. The
> fully qualified parameter name "{sd:graphIri}" would be replaced with
> the percent encoded graph IRI the needs to be identified.
>
> This would give implementations much more freedom in how they handle
> indirect requests, if the implementation support indirect requests at
> all.
>
> Regards,
> James

I agree this design would work, technically, but it seems like in the 
common case this requires more work for the client folks (people writing 
GSP clients would need to understand SD), more work for the server folks 
(people running SPARQL servers would have to set up the right SD).   A 
little more load: GSP clients would need to do an extra round-trip once 
in a while.   And generally more complexity and possibilities for things 
to go wrong.

And what does it buy us?    Clearly, as you say, more flexibility; but I 
can't think of a plausible situation where that flexibility would be 
important (and yet the other SPARQL protocol elements would be 
acceptable.)    Can you give me some stories that might convince the WG 
and everyone struggling with the additional complexity that this was all 
worth it?

        -- Sandro

>> [1]
>> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Nov/0048
>>
> [2] http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_URL_template_syntax
>
>

Received on Tuesday, 4 September 2012 13:43:58 UTC