Re: Indirect Graph Identification

[unofficial response]

On Mon, 2012-01-16 at 09:20 -0500, James Leigh wrote:
> Has the group come to any agreement on this issue?
> 
> From what I have seen, some think named graphs must be only be located
> at the graph authority, others think incomplete named graphs can be
> served from any services. 

I might be missing some context, but I think the text on Indirect Graph
Identification in SPARQL 1.1 Graph Store HTTP Protocol is pretty clear
that SPARQL named graphs can be served from other servers...

http://www.w3.org/2009/sparql/docs/http-rdf-update/#indirect-graph-identification

I'm not sure what you mean by "incomplete".   Perhaps you're thinking
about the case where TimBL publishes

http://www.w3.org/People/Berners-Lee/card

and then some crawler fetches it and stores a copy under that name in
its graphstore.   As I understand it, that's fine, and the crawler is
welcome to republish it, using a URL like:

http://example.com/service?graph=http%3A//www.w3.org/People/Berners-Lee/card

Whether it's a complete copy, or a copy at all, is totally up to the
people running example.com/service -- the specs don't care.

> Regardless, my point is that these same issues
> are the same weather we talk about resource descriptions or named
> graphs. Will the group consider addressing the broader issue of indirect
> resource URI requests?

At this point, we've gone to Last Call on everything but this GSHP
document, which I think we'll be done with very soon.  So, I don't think
we'll be addressing anything not already addressed in the documents,
unless we get public comments convincing us it's necessary to make our
the material we have function properly.

   -- Sandro

> Thanks,
> James
> 
> On Mon, 2011-11-28 at 13:55 -0500, James Leigh wrote:
> > Hello,
> > 
> > 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
> > "http://www.example.com/other/graph".
> > 
> >    GET /.well-known/alias;http%3A//www.example.com/other/graph HTTP/1.1
> >    Host: example.com
> >    Accept: application/rdf+xml
> > 
> > Thanks,
> > James
> > 
> > [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 Tuesday, 17 January 2012 12:51:24 UTC