Aubrey: Our content delivery/metadata management system.

Aubrey is what we decided to call the system responsible for a variety of tasks which are all public facing. This system handles both content delivery as well as allowing collection owners to edit metadata and object records as needed.

You can see the content delivery side of Aubrey in the following two systems:

The creation of Aubrey was funded by a generous grant from the Institute of Museum and Library Services as part of a national leadership grant to design and develop a rapid development framework for interface development in digital libraries. The grant was written because all too often in digital libraries there is a disconnect between what the users of digital libraries request in terms of user interfaces and feature and what we are able to provide them given the digital library platform we are trying to use.

There are several reasons we chose to roll our own content delivery system, as time goes on I keep adding to this list, some are of more importance than others but all added up to us creating our own content delivery and metadata management system.

Here are some of the reasons we decided to do this. Please don’t take any of these as an attack on any systems, most likely they can do the things that we are trying to do but I wasn’t smart enough to figure out how to make them bend in the way needed…

  • We wanted a system built on a modern Web framework that takes care of most of the fiddly bits of Web application building.
  • We wanted to work in Python, we use Python, we love Python, we get stuff done in Python.
  • We wanted a system that was itself loosely coupled so we could swap things out as technologies changed.
  • We wanted one system to serve all digital content, audio, video, books, newspapers, data sets, photographs, stuff…
  • We wanted a system that could scale horizontally in respect to handling more requests and adding more content.
  • We wanted redundancy in as many areas as possible so if one server goes down the whole application still runs.
  • We wanted to let our UI people do the user interface, ie. we wanted to use a templating language that our UI people wanted to work with.
  • We had a specific idea of how we wanted to deliver content to users and how those ideas mapped to urls, so a framework that promoted beautiful urls was ideal.
  • We wanted a huge community solving most of the problems with a big Web application (most of those problems aren’t library problems)
  • We wanted to treat the application as a replaceable set of services that sits on top of our own digital object model. We really like the idea of “permanent objects, disposable systems”.
  • We wanted a system than would allow for metadata more complex than simple key value pairs.
  • We wanted to manage the editing interface for the 120+ partner institutions that use our infrastructure.

In the end we arrived at a system that makes use of these components

  • Python
  • Django
  • Ubuntu
  • Perlbal
  • Memcached
  • OpenLayers
  • JQuery
  • Solr
  • AtomPub

The digital objects this collection of technologies sits atop use the following standards and specifications:

  • METS
  • Dublin Core – (Locally Qualified)
  • PairTree
  • Namaste
  • BagIt

Aubrey is the name of a town north of Denton and served us with a name that is as good as any other name.

So we had support, funding, people, ideas of what we wanted and a set of technologies we were all excited to work with. This turned out to be quite fun.

Aubrey was built over the two year period and consisted of three major releases, during each release the underlying objects never changed, and in fact the plan is to never change the digital objects that sit on disk, there are just too many for us to reasonably touch and most likely the changes aren’t worth that overhead. We built Aubrey around an abstraction of what a digital object is to us in the system, that internal abstraction can change easily as it is only ever stored in cache, that’s where stuff changes.

So anyway, Aubrey meet people, people meet Aubrey.

I’ll flesh out the under the hood stuff in following posts, if I can figure out how to use some of this new software to draw pictures you might even have graphics.

4 thoughts on “Aubrey: Our content delivery/metadata management system.

  1. Mike G.

    Great to read more about UNT’s work, Mark. Out of curiosity, is Aubrey available under an open source license, or do you plan on making it available?

    Reply
  2. vphill Post author

    From the beginning of the project we knew we weren’t going to be releasing the code for this one. Mainly because I know that we don’t have the resources to support this sort of thing. I would however be interested in groups interested in hosting collections with our framework in our infrastructure. I haven’t figured out much of the issues with that , but that’s the model I think we would go for.

    Reply
  3. Natalie

    This looks really interesting. You said that you don’t want to ‘move’ the digital objects. What will you do in case of hardware failure or warranty expiration? If some new repo suite comes out that makes Aubrey’s job easier, would you consider moving your stuff?

    Reply
  4. vphill Post author

    I guess when I say move I don’t really mean move…

    I’m thinking more of “convert” especially when you get larger and larger collections of digital content, at some point it makes more sense to leave the content in place and build a delivery system on top of it instead of converting it into another slightly different format.

    As far as “moving” content we do in fact move content all the time. We have multiple copies of each object in the delivery application so that one storage node can go down and we can continue to serve content from another . This has been helpful in several situations.

    Sorry for the confusion.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *