Before I start my next job I’ve decided it’s time to look back on the things I’ve learned, where I’ve succeeded and where I did not (and why), in working as a “metadata specialist” for two years and 2 months with RUBRIC, and before that working in various capacities (mostly as a cataloguer/editor) with an EPrints repository.
RUBRIC was a project funded by a national government department to assist university libraries to implement repositories. The acronym stands for Regional Universities Building Repository Infrastructure Collaboratively.
There was a “RUBRIC Central”, consisting of a technical team, a planning and PR person, and project manager and myself, the metadata specialist, and this Central team worked as per the acronym collaboratively with repository managers in different universities. How this worked can be seen in a PowerPoint presentation by Kate Watson and Vicki Picasso, both involved repository managers, titled The RUBRIC Project: the benefits of collaboration through partnerships. This is linked on the IDEA 2006 page.
So my introduction into the nitty gritty of metadata and repositories with RUBRIC was in the context of working with several universities, each with different library practices, priorities and infrastructure, most of whom did not yet have repositories. The requirement was to help each get started with a “first generation” repository. The couple that did have repositories were still in their neophyte stages and welcoming of professional assistance to help establish themselves on the right footing.
The first step was to evaluate different repository systems so each university could better assess the one most suited to their situation. We investigated DSpace, VTLS’s VITAL and the University of Queensland’s Fez (two Fedora based repositories), and I also had had experience with EPrints.
This evaluation meant working closely with the technical team of programmers. This involvement consisted of weekly meetings where goals and needs were raised and assessed, and sitting beside them in the same workroom so we could regularly talk the issues through together.
It also, most importantly, meant regular communication and prioritization and troubleshooting through TRAC, wikis and teleconferences.
So the technical skills of the programmers was combined with my library cataloguing skills and understanding of library terminology needs.
So I was put in a rare and enviable position of being able to begin studying metadata issues in the context of:
- a variety of repository systems
- different universities with different needs and resources
- close daily liaison with computer technicians and regular liaison with project partners
- and a well resourced and coordinated team and collaborative partnership that kept us all focussed on the issues
Unfortunately the weather can change and towards the end of the project some of the above started to fade, and in hindsight I can see where I could have been more alert to have worked to compensate or correct that, and how I could have improved on some of what I attempted, but that’s hindsight. I’ll discuss that side of it when the time comes for that particular meta-reflection.
It was a great start. I needed to understand metadata not just for one institution, but for eight universities, and how metadata would or could work in four different repository systems, with a marriage of technical and metadata specialists.
Subsequent discussions with more experienced repository managers who were not part of the RUBRIC project began to help me understand just how well positioned I was to help new repository managers avoid certain pitfalls and risks — and to help me acquire an expanding awareness of what future needs would be and the broader environment our partners would be entering.
Next post will begin to discuss the first metadata specifics that needed exploration and solutions.