Account from OGF25 Repositories Workshop: Creating a Repository Standard?
04 March 2009
Catania, Sicily, Italy
Open Grid Forum 25th Conference (OGF25)
It’s not entirely clear when I figured out that I was sitting on a standards body panel discussing the creation of a digital repository related standard. I’m pretty sure it finally clicked sometime after the session was over, once I had consumed a couple glasses of wine.
I still don’t see what I contributed to the conversation, though the other participants assured me that my comments were useful. The experience reminds me of my friend, let’s call him Josh, a community organizer who was recently pulled onto one of the Obama administration’s advisory panels. Shortly after joining the advisory panel, Josh confessed that at the end of most calls he has to follow up with a friend and ask “Ok. So what exactly did we just decide and who is responsible for doing what?”
The panel discussion started by making observations that we’re all familiar with:
- the importance, and associated challenges, of unique identifiers and persistent URIs
- search, retrieval, and management are separate concerns, each with appropriate standards associated (ie. SWORD, OpenSearch, etc.)
- cloud computing is very different from cloud storage
After this, I quickly found myself in completely unfamiliar waters when conversation abruptly turned to the creation of a standard for digital repositories. I thought “Pshaw. We don’t need Yet Another Standard. Where did this come from?” In fact, the whole field of repositories is so new that the prospect of a repository standard seems absurdly premature to me. Discussion on the panel honed in on the two obvious contenders for a standard: 1) metadata requirements, and 2) functionality profiles (a list of features necessary in order for a repository system to be deemed compliant and interoperable). From my perspective, repositories already swim in a glut of metadata standards (as well as non-standard, ad-hoc metadata) and, by nature, must embrace heterogeneous metadata. The second notion, that of functionality profiles, sounds like something that few will read and none will understand. To be honest, the entire discussion confused me. I did my best to contribute to the discussion where I could.
After the workshop ended, I had a chance to catch my breath and discuss the panel with a couple of people. Eventually, I came to look at the whole scenario from a different perspective and had a mild change of heart. In a discussion with Neil Chue Hong, a very smart guy from Edinburgh, I started thinking about all the informal conclusions that frame discussions between developers at conferences like Dev8D, Code4Lib and RepoCamp. I then thought about all the little architectural wins and failures that I see in software like Flickr, YouTube, Hulu and (woah) ABC’s full episode player. After all, these are repositories too. Within a few moments of pondering, an initial list of obvious basic guidelines shone through quite clearly.
- give permanent, unique URIs to all content you expose, even if you intend to limit access to that content based on geography or time of access
- support linking with versioning or datetime info
- expose a RESTful API
- give preference to AtomPub
- consider ORE when you need to express aggregations of data
- provide linked data (RDF) endpoints
Some open topics also seem like obvious fodder for discussion:
- what query language(s) to use in search APIs
- navigating the difference between standards and interoperability
- leveraging standards where possible (ie SWORD)
These are merely the things that seem obvious to me right away. What would happen if we got the really smart people talking in this vein?
I think this warrants further exploration and, strange though it is, I expect that the outputs of such exploration might resemble the stuff of standards bodies (be it a recommendation, a community document, or a standard). Possibly I have been infected with that odd standards-wonk bug, or possibly I’m just catching up with the rest of the world in acknowledging the inevitable.