Discussion of the purpose of collection feeds

[heuer]

In http://www.egovpt.org/fg/CWA_Part_1b#head-cfc066c9ca58d6eb6880b6c4d357b62e2b7a7403 the collection feed provided aside from the links to the snapshots feed and fragments feed optional <sd:dependency> elements. In SDShare 1.0 dependencies are no longer supported.

I wonder if it has been discussed to remove the collection feed and add the links to snapshots feed/fragments feed directly to the overview feed.

[heuer]

It would make sense to keep the collection feed if the spec defines that the atom:updated time stamp of the snapshots feed entry MUST reflect the time stamp of the last snapshot and the atom:updated time stamp of the fragments feed MUST be equal to the time stamp of the last fragment.

Currently, the spec is silent about the atom:updated constraints and the Atom spec says:

The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value.

So the SDShare spec and Atom spec allow a broad interpretation about the semantics of atom:updated

[heuer]

Maybe this comes too late, but I favour to remove the collection feed and add additional options to the overview feed.

My favorite solution:

• Define a feed service endpoint which takes an optional "graph" parameter
• If no "graph" parameter is provided, an overview over all graphs is provided (pretty much the same as the current overview feed but all collection entries have a link to their fragments feed/snapshots feed)
• If a graph parameter is provided and a graph with the provided URI exists, the feed is filtered and it contains just one collection entry which contains links to the collection's fragments feed and snapshots feed
• If the graph parameter is provided and the graph does not exist, the server MUST answer with 404

Examples:

• Server provides graphs with the URI http://www.example.org/graph-A and http://www.example.org/graph-B

a) List all available graphs

Request:

GET http://www.example.org/feed-service

Response:

<feed xmlns="http://www.w3.org/2005/Atom">
[...]
   <entry>
     <title>Graph A</title>

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

   <link href="http://example.org/collections/collection-one/fragments"
             rel="alternate" 
             type="application/atom+xml"/>
    <link href="http://example.org/collections/collection-one/fragments" 
             rel="http://www.sdshare.org/2012/core/fragmentsfeed" 
             type="application/atom+xml"/>

    <link href="http://example.org/collections/collection-one/snapshots"
             rel="alternate"
             type="application/atom+xml"/>
    <link href="http://example.org/collections/collection-one/snapshots"
             rel="http://www.sdshare.org/2012/core/snapshotsfeed" 
             type="application/atom+xml"/>

[...]
   </entry>

[ entry for graph-B ]

 </feed>

b) List a specific, existing graph

Request:

GET http://www.example.org/feed-service?graph=http://www.example.org/graph-A

Response:

<feed xmlns="http://www.w3.org/2005/Atom">
[...]
   <entry>
     <title>Graph A</title>

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

   <link href="http://example.org/collections/collection-one/fragments"
             rel="alternate" 
             type="application/atom+xml"/>
    <link href="http://example.org/collections/collection-one/fragments" 
             rel="http://www.sdshare.org/2012/core/fragmentsfeed" 
             type="application/atom+xml"/>

    <link href="http://example.org/collections/collection-one/snapshots"
             rel="alternate"
             type="application/atom+xml"/>
    <link href="http://example.org/collections/collection-one/snapshots"
             rel="http://www.sdshare.org/2012/core/snapshotsfeed" 
             type="application/atom+xml"/>

[...]
   </entry>
 </feed>

c) Request for a non-existing graph

Request:

GET http://www.example.org/feed-service?graph=http://www.example.org/graph-C

Response:

404 - Not found

d) Check if the feed service provides information about a graph

Request:

HEAD http://www.example.org/feed-service?graph=http://www.example.org/graph-A

Response:

200 - Ok

Request:

HEAD http://www.example.org/feed-service?graph=http://www.example.org/graph-C

Response:

404 - Not Found

In summary:

• Overview feed and collection feed would be merged into the feed service
• Fragments feed stays unchanged
• Snapshots feed stays unchanged

[heuer]

See also SPARQL 1.1 Graph Store HTTP Protocol http://www.w3.org/TR/sparql11-http-rdf-update/

The solution for direct graph identification http://www.w3.org/TR/sparql11-http-rdf-update/#direct-graph-identification could also be adopted: GET http://www.example.org/feed-service/graph-C would return a feed with the collection entry for the graph with the URI http://www.example.org/feed-service/graph-C

[larsga]

The reason we do it this way is that the endpoint people subscribe to is the collection feed URI, because they subscribe to a particular collection. The solution you describe would mean abandoning the HATEOAS principle, which we feel is one of the strongest points of the standard.

At the moment there are no particular requirements for the atom:updated element in the collection feed, and I don't know of any implementations that use it.

Personally, I feel very strongly that the current shape of the spec (with the collection feed) is the right one.

[heuer]

Well, the solution wouldn't violate HATEOAS iff each entry whoud contain a link to itself which seems to be good practice anyway:

<entry>
  <title>Graph A</title>

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

  <link href="http://www.example.org/endpoint/?graph=http://www.example.org/graph-A"/ rel="self"/>

  <link href="http://example.org/collections/collection-one/fragments"/>
  <link href="http://example.org/collections/collection-one/fragments" 
         rel="http://www.sdshare.org/2012/core/fragmentsfeed" 
         type="application/atom+xml"/>

  <link href="http://example.org/collections/collection-one/snapshots"
         type="application/atom+xml"/>
  <link href="http://example.org/collections/collection-one/snapshots"
         rel="http://www.sdshare.org/2012/core/snapshotsfeed" 
         type="application/atom+xml"/>
[...]
</entry>

The overview feed would provide at least 5 (3 if issue #55 would have beed accepted) self-describing links instead of 2 (or 3 if link rel="self" is part of the entry) which point to the same resource.