Jeni's Musings

“And that’s fine, because AtomPub is a read/write API. To add a tag to a photo, flickr simply edits the resource with PUT. To add a comment, it locates the comment feed (which would be referenced from the entry for the particular image) and POSTs to create a new resource. And everyone can see those changes — the added value that you get from a social network.”

There’s another way it might (also) work — a site like flickr could provide the “tag environment” (i.e. metadata framework) for your photos. So they still live on your own server space and even expose their own atom metadata. But instead of flickr editing (put-ing to) a resource on the server, it provides a new feed or set of feeds for your stuff. It’s just like the current situation, but flickr saves a URI instead of an image. This is exactly what happens with a site like REDDIT — pages on the web are re-contextualized in the REDDIT setting. A set of images may have numerous “contexts” in which to be viewed and understood. Even if we move towards a canonicalized digital object, there will be little need for canonicalized metadata — an object (identified by it’s URI) will live many lives simultaneously. Atom/AtomPub will provide a means by which these contexts can “converse”.

In my own experience in the university setting, I see the “institutional repository” as providing little more than a persistent URI for a paper, data set, image, etc. and perhaps some boilerplate metadata. These assets may appear in various contexts on the web: faculty member’s departmental web site, a personal web site, a discipline-specific web site, etc. and may have different metadata in each case. There may be a means by which some of that metadata flows back to the institutional repository (atom/atompub), but it may or may not — and the owner of the various sets of metadata may or may not be the same as the owner of the digital asset.

—peter keane UT Austin