Graph URI -- Proposal for an extension of SDShare to automate graph discovery

[heuer]

Example: Org A defines a graph A http://www.example.org/graph-A but provides no SDShare feed. Person B imports the graph and provides a SDShare feed for the above mentioned graph among other collections on server http://www.example.net/sdshare/ How should a client know that the collection XY provided by B is about graph A? The current SDShare spec provides no indicator for graph URIs, just collection identifiers which have no implied meaning aside from beeing unique.

If the overview feed (and possibly all other feeds, too) provides a graph URI indicator, clients would be able to discover the collection feed (and all subsequent feeds) for a specific graph easily. The graph indicator could be an element like <sd:graph/>. The value would be the graph URI. The graph indicator would be a subelement of <atom:entry/> in the overview feed. All other feeds use the graph indicator as subelement of the <atom:feed/> element.

Example excerpt for an overview feed:

[...]
<entry>
     <title>Collection for graph A</title>

     <sd:graph>http://www.example.org/A</sd:graph>

     <link rel="http://www.sdshare.org/2012/core/collectionfeed" type="application/atom+xml"
           href="http://example.org/collections/collection-one"/> 
     <link rel="alternate" type="application/atom+xml"
           href="http://example.org/collections/collection-one"/> 
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
     <updated>2008-12-13T18:30:02Z</updated>
   </entry>
<entry>
     <title>Collection for graph B</title>

     <sd:graph>http://www.someotherdomain.here/B</sd:graph>

     <link rel="http://www.sdshare.org/2012/core/collectionfeed" type="application/atom+xml"
           href="http://example.org/collections/collection-two"/> 
     <link rel="alternate" type="application/atom+xml"
           href="http://example.org/collections/collection-two"/> 
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-dddddddd</id>
     <updated>2008-12-13T18:30:02Z</updated>
   </entry>
[...]

[heuer]

Another possibility which works for the overview feed: The <atom:id> element must be equal to the graph URI.

[larsga]

We discussed having the graph URI in the Atom feed, but decided against it, because it felt like telling the client what it should do with the data. I guess what you've done is to come up with a use case for having it anyway.

I guess I'm neutral on this. Graham, what do you think?

[heuer]

Another possibility which works for the overview feed: The <atom:id> element must be equal to the graph URI.

Update: I'd prefer a dedicated element over <atom:id> because reusing atom:id attaches semantics at the element which are not covered by the Atom spec. Further, a dedicated element would work for the other feeds (collection, snapshots, fragments) as well while atom:id wouldn't.

[larsga]

Yeah, I prefer the custom element myself, for the same reason. If we're going to do this, that is.

[heuer]

LMG:

We discussed having the graph URI in the Atom feed, but decided against it, because it felt like telling the client what it should do with the data.

Well, I'd keep the freedom of the client to decide what to do with the data. It's just an information to identify graphs, it does not affect the update algorithm. A client could use the information or ignore it.

[larsga]

5.2.3 discusses what graph to apply the fragments to, but it's true that we don't have to say that clients MUST use the uri given in the feed. We could instead say that they MAY, thus making the connection in people's minds, without forcing them to do that.

I'm beginning to like this.