professional reflections

A minor response to Repositories thru the looking glass

In Repositories thru the looking glass over on the eFoundations blog, Andy Powell gives a summary of a keynote he gave to the Vala Conference last week. It's interesting stuff, and I will take the time to look at the presentation slides as well. I mostly agree (vehemently in some instances) with Andy's points, though I do find myself questioning some parts of this, so I'll quote some snippets and make a few comments here.

Firstly, that our current preoccupation with the building and filling of 'repositories' (particularly 'institutional repositories') rather than the act of surfacing scholarly material on the Web means that we are focusing on the means rather than the end (open access)

It's hard to deny that there is a current preoccupation with establishing repository systems of one kind or another and populating them with content, and also that there is a focus on institutional deployments. However, I'm not convinced that open access is (or at least is going to remain) the sole driver behind the development of institutional repositories. From an institutional perspective, it absolutely makes sense to want to manage the outputs of research conducted within the auspices of that institution.

A common use for an institutional repository is to house eprints. Were it not for the open-access imperative, we might have expected software designed to manage eprints to fall somewhere between a document-management and a content-management system - both familiar to a large number of institutions. I think it is interesting that it might be considered to be open-access which has skewed the development of repository software in some respects - the community has largely started from scratch, building repository software, where it might have made more sense to simply adapt what was there.

So I half agree with Andy - we do seem to be focussed on the means, but I think I am sympathetic to those (institutions at least) who find themselves pre-occupied with this.

Secondly, that our focus on the 'institution' as the home of repository services is not aligned with the social networks used by scholars, meaning that we will find it very difficult to build tools that are compelling to those people we want to use them. As a result, we resort to mandates and other forms of coercion in recognition that we have not, so far, built services that people actually want to use. We have promoted the needs of institutions over the needs of individuals.
Instead, we need to focus on building and/or using global scholarly social networks based on global repository services.

There are four sentences here, and I completely agree with the first three and a half! I find myself wondering who 'we' are in this. Now that institutional repositories are becoming a reality, the 'we' is going to expand to include people who simply have institutional interests - who have no real interest in open-access for example beyond it being a requirement for them to support. The MIS Manager of your average institution, for example, will start to get involved once institutional repositories get embedded into the business which is a university. The half sentence I don't quite buy is the "global repository services". Why can't we "focus on building and/or using global scholarly social networks" (which I support) based on institutional repository services? We don't have a problem with institutional web sites do we? Or institutional library OPACs? We have certainly managed to network the latter on a global scale, and built interesting services around this….

Finally, that the 'service oriented' approaches that we have tended to adopt in standards like the OAI-PMH, SRW/SRU and OpenURL sit uncomfortably with the 'resource oriented' approach of the Web architecture and the Semantic Web. We need to recognise the importance of REST as an architectural style and adopt a 'resource oriented' approach at the technical level when building services.

Absolutely - couldn't agree more. Yesterday, at a JISC committee meeting, I argued that a resource-oriented-architecture and the service-oriented-approaches being encouraged by the e-Framework could complement each other if intelligently and judiciously applied. Incidentally, last Friday, I attended an excellent CRIG workshop devoted to exploring the relevance of ReST to repositories. Matt Zumwalt of MediaShelf showed a working ReST interface on Fedora, and Oxford University's Ben O'Steen used this to develop a client app, in real time, in Python.

I think we agree that the individual's interests may often be orthogonal to those of the institution. This may have always been the case but it is, perhaps, increasingly an issue as recent developments and trends on the Web empower the individual at an accelerating rate. I wonder if the user-centric/institutional/global debate around repositories is just symptomatic of a tension about to become apparent all over the (institutional) Web?

Having said all this, when visiting the outer limits of repository software development, I am occasionally reminded of the Knight:

'I see you're admiring my little box.' the Knight said in a friendly tone. `It's my own invention – to keep clothes and sandwiches in. You see I carry it upside-down, so that the rain can't get in.'
'But the things can get OUT,' Alice gently remarked. Do you know the lid's open?

(from Alice Through the Looking Glass, via Project Gutenberg)


I agree with much of your case, but it falls short on the history of repository software and its original focus on OA.

> I think it is interesting that it might be considered to be open-access which has skewed the development of repository software in some respects - the community has largely started from scratch, building repository software, where it might have made more sense to simply adapt what was there.

EPrints was announced in 2000 and formally launched at the announcement of OAI 1.0 in 2001, and represented the first software for broad IR purposes. Its origins were in Ginsparg's arXiv software, but it evolved some way from that via the Cogprints project. What are you suggesting it should have been based on at that time?

Perhaps we should all have used a CMS (I'm not sure what was available in 2000), but the difference is like that between and Connotea - one is designed for general use and the other for scholarly purpose and detail.

The OAI model was predicated on two earlier subject-based approaches - RePEc and NCSTRL. Going forward, DSpace followed in 2002, written by the original developer of EPrints. Fedora was around prior to EPrints - in fact it was being used in the JISC OpCit project that produced EPrints - but was only repurposed as repository software when it was picked up from Cornell by Virginia Tech, like much of the other repository software promoted by DL systems suppliers which saw the growth in this market from 2004. There has been a lot of adapting going on, and much of it started with EPrints.

EPrints was designed specifically to promote (what later became formally known as) open access. Stevan Harnad wasn't just urging open access, he was giving institutions the tool to do it. So how has that 'skewed' the development of repository software? If anything, it is the objectives of many that have followed that have skewed repositories.

There is no problem with repositories having other objectives, providing there is one. As I said in my response to Andy's blog, where is the objective in this cross-blog debate about the future of repositories? The brief history is by way of showing there has been at least one common objective throughout - OA - and it is still widely shared and strong.

haha! Last time I looked the Deposit API was still in the "evaluating all possibilities stage". I think I met with Julie or Rachel and recommended AtomPub ;)

I'm glad that's what they went for in the end, although I'm not convinced by all of the extensions; but then again, I don't believe in metadata either ;)

Yes - and funny you should mention AtomPub - it was very much a topic of discussion at the CRIG event. Note the JISC funded SWORD project, based on a profile of AtomPub

Did it add any more than, for example, applying the AtomPub rules might?

I'd like to refer to at this point :)

[…] ??????????  ?????????????????????“???????????????????????????????”?????????Brian Kelly???Panlibus??????Andy Powell?“……???‘??’?????????????????????????????????????????????????????????????????????”???????????Paul Walk????????????“??????????e-Framework???????????????????2.0-???REST???????????????????”Brian Kelly ????????,??????????????Brian Kelly, UK Web Focus February 19, 2008 [Link] [Tags: Networks, Web 2.0, Learning Object Repositories] [Comment] […]

[…] RESTful repository discussion in the wake of Andy Powell’s keynote at VALA (responses a, b, c, […]

[…] on his blog my colleague Paul Walk has given his thoughts on Andy’s post expressing agreement in several areas but disagreeing with Andy’s view […]

I guess Representational State Transfer ought to be 'ReST', or even 'RST' but as Fielding himself uses 'REST' then I take your point! Of course there's strict REST and there's the looser notion of RESTful. The CRIG workshop was exploring the application of strict REST to repositories and, as such, was really interesting.

While the Web itself is vaguely RESTful (it's made up of HTTP and addressed resources, many web applications are not….

Unless it's a different acronym, it's REST, not ReST (which I think is the ReStructured Text markup).

"the community has largely started from scratch"

and it's complete madness. To even need a "workshop devoted to exploring the relevance of ReST to repositories" !!! I mean, REST is how the web works. If it's not baked in from the start, what chance do you stand?

On the note of wikipedia in search rankings, it's important to recognise things like stable URIs, internal linking, massive incoming links etc. all contribute hugely.

Just on the point about the eFramework, and "business-level" SOA v "technical" SOA, I found this post

and this presentation

both by Stefan Tilkov quite helpful.

Leave a comment!

Designed by Paul Walk