- From: James Leigh <james@3roundstones.com>
- Date: Tue, 08 May 2012 13:11:59 -0400
- To: Sandro Hawke <sandro@w3.org>
- Cc: public-rdf-dawg-comments@w3.org
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 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 > [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, 8 May 2012 17:12:35 UTC