[datacatalogs] Request for Comments on Draft Data Catalog Standard (Schema and Protocol)

[Ed Summers]

On Tue, Jun 12, 2012 at 11:22 AM, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> One question of course is whether the URL is the API url or the url of
> the human readable version (sure with content-negotiation this isn't
> so relevant but will everyone support that ...)

Yes, I agree. One approach to entertain would be support for a JSON
equivalent of Atom's link element in the changes.json:

    <entry>
    ...
    <link rel="alternate" type="text/html"
href="http://example.org/dataset/1234.html">
    <link rel="altnernate" type="application/json"
href="http://example.org/dataset/1234.json">
    <link rel="alternate" type="application/rdf+xml"
href="http://example.org/dataset/1234.rdf">
    </entry>

This allows clients to pick the mediatype they understand and act
accordingly. If the server supported negotiation at one URL it could
supply a JSON version of this instead:

    <entry>
    ...
    <link rel="alternate" type="text/html"
href="http://example.org/dataset/1234">
    <link rel="alternate" type="application/json"
href="http://example.org/dataset/1234">
    <link rel="alternate" type="application/rdf+xml"
href="http://example.org/dataset/1234">
    </entry>

I imagine conneg wouldn't get implemented that much, but you never
know. For what this might look like in JSON the page on RESTful JSON
[1] and in particular this post by Subbu Allamaraju might provide some
guidance [2]. I could sketch up an example if you are interested.

>> 2) Are the full representations of the dataset made available in the
>> changes.json, or will clients need to fetch the dataset to get the
>> full information?
>
> They will need to fetch. changes.json is lightweight.

All the more reason for supplying a URL for the dataset so that
clients can fetch it easily without needing to construct URLs.

>> 4) Are both JSON and RDF representations of the dataset required?
>
> No only the JSON representation is *required* atm with option to
> provide other formats (n3 / rdf/xml etc)

I think the link constructs discussed above, or something like them,
would allow servers to describe what representations are available.
Maybe?

Thanks for the feedback Rufus, and for talking openly about this as it
is being developed--much appreciated.
//Ed

[1] http://microformats.org/wiki/rest/json
[2] http://www.subbu.org/blog/2008/10/generalized-linking