Re: Indirect Graph Identification

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