CommentResponse:JL-3

James Leigh wrote:

> 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 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.
> 
> 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.

James,

After discussion, the Working Group has decided against making any changes to provide discoverable indirect graph URL templates for two reasons. The primary reason is due to an earlier resolution by the Working Group that the use of the Service Discovery specification with the Graph Store protocol is out of scope for this specification, as the SD specification was not designed to work with the graph store protocol.

Secondly, it is not immediately apparent why the current approach can be considered a hardcoding approach as this critique can be applied to other specified HTTP APIs (such as the SPARQL RDF protocol's use of the ?query query string to specify the SPARQL to evaluate). Given the specific role of this protocol (the management of a graph store over HTTP) it is not immediately clear how it could come to be in conflict with other types of indirect requests.

However, we have added the mechanism you describe to the Future Work Items list (as "Templating of indirect graph identification").

We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.

Regards, Chime Ogbuji, on behalf of the SPARQL WG.