« DCMI Architecture Forum video conferences | Main | Images DC Application Profile Working Group »

October 31, 2007

Repository as platform

The recently announced Call for Plugins from the EPrints team is interesting for a couple of reasons.  Firstly because, although offering prizes for software ideas is not as new phenomenon, I'm not sure that I've seen it used in the repositories space until now...  it'll be interesting to see what ideas people come up with.  Secondly, and perhaps more importantly, because it positions the repository as a platform rather than as a monolithic application.

I haven't looked in detail yet at the APIs being offered here but I'm hopeful that this notion of repository as platform is more than trivial word smithing.  Assuming that a resource-centric approach has been adopted (in line with the Web architecture) my gut feeling is that this is very much a step in the right direction.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Repository as platform:


I'm not entirely sure I buy into the repository-as-platform notion, for much the same reasons I'm less than impressed with the "Facebook is a platform" approach.

Leaving aside the typically "one-way" nature of the traffic in the Facebook case, the risk is ending up with all these different "platforms", all these different systems tending to define their own different "APIs", and the developer ending up programming once for the Facebook platform, once for the MySpace platform, once for the my-new-social-networking-bobbins platform etc etc etc.

I don't really want lots of "platforms", I don't think. For me, the Web is the platform and the important thing is that all these different systems become "of the Web", to borrow the term that Paul Miller used over on Nodalities http://blogs.talis.com/nodalities/2007/07/the_platform_and_the_web_what.php
and they support a uniform interface to resources, use URIs in representations etc etc etc.

I guess this is what you are getting at with the reference to a resource-oriented approach, but I couldn't turn down the opportunity to labour the point anyway ;-)


I agree, and that's why efforts such as SWORD are so attractive. If repository development can coalesce around such standards -- e.g., if Fedora, EPrints, and DSpace build SWORD support atop their APIs -- developers can "write once, deploy indefinitely" and circumvent the issue. I'm not sure we're there yet, but I applaud the SWORD folks for their work, and folks who are interested should advocate for support for their repository system of choice.

To me the "platform" snark is beside the point.

What's happening -- and it's VITAL -- is that we're finally taking baby steps to move past the notion that clunky metadata web forms and an Upload button are THE way to get stuff into repositories.

This was a preposterous notion from the start and it can't die fast enough.

I think that all these earlier comments reflect the fact that people don't want to think of a repository as a kind of theme-park attraction that you have to visit, even if you can waste all day on all sorts of exciting rides while you are there.

SWORD means that you don't have to fly to Florida and pay the entrance fee for any of the three big venues Disney, Universal or SeaWorld.

EPrints plugins mean that you can enjoy the thrills and spills of the park wherever you like.

Oh dear, it looks like I have put insufficient planning into this metaphor. And I can't even decide which of DSpace, EPrints or Fedora is which of the theme parks.

My point is that the role of the repository is to capture and curate interesting and useful information in as unobtrusive a way as possible and to yield it up in as many varied and useful ways as possible. But the repository per se shouldn't be the main focus of attention, or even the destination of navigation.

The repository should be like housework - not noticed if done well. Or like a well-mannered host that doesn't draw attention to itself.

Now. Away from aspirational talk, and down to technical details.

EPrints export filters (like Fedora disseminators) define views or transformations on the content of an eprint (or on a collection of eprints). You can choose to apply an export to the result set of any query and each individual eprint web page has a LINK element to each of its alternative representations under the applicable transformations.

Some of these URLs just yield data in various formats (EndNote, BibTeX, ZIP etc) while others pass the data on to other Web services (e.g. Google Maps).

So the Call for Plugins is a request for people to increase the valency of their repositories by helping to get the data IN from other services or OUT into the big wide world of something much more useful than a repository.

Like my mum used to say to me - you don't want to be stuck in the house all day. Get out in the fresh air!

The comments to this entry are closed.



eFoundations is powered by TypePad