W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > November 2011

Indirect Graph Identification

From: James Leigh <james@3roundstones.com>
Date: Mon, 28 Nov 2011 13:55:39 -0500
Message-ID: <1322506539.1790.25.camel@james-laptop>
To: public-rdf-dawg-comments@w3.org

Please consider using a more general, well-known, indirect graph
identification[1] URI pattern.

The cases stated for requiring indirect graph identification are shared
by the Linked Data community for indirect resource identification[2].
Linked Data is often mirrored for the purposes of creating
visualizations of the data, merging some or all of the data with data
from other sources and/or enhancing responsiveness to queries.

For your convince, I have copied the indirect graph cases from
rdf-update[1] below.

      * the naming authority associated with the URI of an RDF graph in
        a Graph Store is not the same as the server managing the
        identified RDF content
      * the naming authority is not available
      * the URI is not dereferencable (i.e., when dereferenced, it does
        not produce a RDF graph representation)

Replacing "RDF graph" above with "RDF resource", the same cases are
equally a challenge for managing RDF data in the Linked Data community.

I propose that this working group consider using a more general URI
pattern that could be equally applied to both RDF graph storage and RDF
resource resolution.

Such a general prefix should use a well known[3] path prefix to allow
clients to infer the identified graph or resource without resolution.
The request-URI below could be recognized by both clients and servers as
identifying the graph with the identifier of

   GET /.well-known/alias;http%3A//www.example.com/other/graph HTTP/1.1
   Host: example.com
   Accept: application/rdf+xml


[1] http://www.w3.org/TR/sparql11-http-rdf-update/#indirect-graph-identification
[2] http://www.w3.org/2011/09/LinkedData/ledp2011_submission_10.pdf
[3] http://tools.ietf.org/html/rfc5785
Received on Monday, 28 November 2011 18:56:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:29 UTC