Item banks as repositories
At the last CETIS Metadata meeting in Bath there was a presentation by the UKCDR project (to a somewhat embarrassingly small crowd) about item banks - a concept that was fairly new to me at the time, but one which I understood to simply mean a repository containing "items", where each item is a question and its associated information conforming to the QTI spec.
Towards the end, the presenters asked for ideas about what standards and machine-interfaces an item bank should support. I volunteered an answer based largely on my work on the JISC Information Environment technical architecture. As a result, I've been asked to present a longer version of my answer at the next meeting of the SIG in Glasgow. The moral is probably "keep your head down unless you want to get asked to do stuff"! Actually, I'm very happy to be asked, and I like Glasgow as a city - though I have to confess to a growing concern about my personal carbon footprint and flying the length of the country for a one day meeting probably isn't doing the world any favours, but perhaps I should leave that as the topic of another post.
Anyway, I digress... to get back to the main point, my answer at the time can be summed up pretty simply. In short, an item bank is a repository and therefore it should support the same interfaces and standards that any other repository is expected to support - the OAI-PMH for harvesting item metadata, SRU for searching metadata and/or full-text, RSS for disseminating news feeds and other lists of items, HTTP for getting the items themselves, OpenURLs for any links to bibliographic resources and cool URIs as identifiers for everything that needs to be identified.
Of course, life isn't necessarily that simple and I presume that there will have to be discussions about what kind of metadata (e.g. DC and/or UK LOM Core) should be exposed thru the OAI-PMH and SRU interfaces. And, as with any repository, there are no widespread agreements in place yet about what API a repository should support to allow content to be deposited into it.
Furthermore, I guess it's also worth thinking about making sure that appropriate parts of the repository get into Google quickly by creating and registering a Google sitemap. And last but not least, if access control is required, particularly outside of a single institution, then adding support for Shibboleth is probably the way to go.
Overall, the list of things to support isn't that daunting, or so it seems to me. More importantly, I would argue that this list can be applied to any 'repository', whatever the complexity or nature of the resources it contains.
Image: Looking up at the dome of the Museum of Glass in Tacoma. Stu Weibel was good enough to spend some time showing me round the area south of Seattle last time I was over for a Dublin Core Usage Board meeting. [May 2006]