May 21, 2009

Not defunct, not yet: and afterthoughts on some basics for a repository’s early-days development

Filed under: Uncategorized — Neil Godfrey @ 9:26 pm

Hoo boy. I’ve been away from blogging here for so long I feel embarrassed to return. Glad to see that my posts from my previous life apparently continue to be of some use to others. I’m in such a totally different world now, however, that I wonder if my ongoing experiences will relate to many in the areas I’m most used to — building repositories in academic environments. Will see . . . . Most of what I have been engrossed in has been constructing application profiles and crosswalks for specialist types of resources (e.g. gi-normous datasets of newspaper articles, national heritage buildings, et al) and preparing Singapore Framework RDF based profiles and team management and education programs, and advising for anything from improved tools and workflows to semantic web directions, social tagging applications and a KOS (knowledge organisation system). Challenging stuff, not least the politics of it all. And cultural factors need negotiation, too.

Maybe I should start new posts here with a few more basics, like some implications of RDA changes for DC based schema or application profiles.

Building supports

I keep thinking of one thing I never got to discuss here, and that I regretted not staying long enough at my last university library to see through as far as I had wanted. That is the primary need for building institutional support for a repository that is expected to last the long haul.

Even in a more established setup where I am now the critical importance of this factor is all too obvious and all too easily relegated to secondary efforts. At the university where I was last year, as soon as we had sorted out the basics of our repository software (that is, actually got it working, well almost) and had something to show, the first priority was to invite and involve academic representatives from the different faculties (zeroing in on those few — even one if that’s all there is — with a real personal interest in the OA project), reps from the research reporting/admin department, and from the university governing bodies, and especially a key person from the IT support section. And some librarian liaisons, too.

At our first meeting we demonstrated what was being done, presented the benefits, some of the handicaps we faced, and asked for support — with inputs from these stakeholders into policy and objectives of the repository. As well as ongoing monitoring and finetuning of these policies and detailed objectives , with a view to the repository thus becoming an integral part of the larger institution’s self-identity, its face to the world, its internal workflows and consciousness.

And getting first things first

Project planning sounds like an obvious need, but I’ve seen places where it is only given slipshod attention, and I’ve also seen the very sticky consequences of that neglect. Not that the personnel involved are slack at all. They just have different talents and do what they do best. Hiring a project planner where this is the situation is a necessity, I think.

And then the second basic requirement is planning and working in accordance with known standards and best practice. Forget radical innovation — at least until after the basics are established and there’s a bit of a track record with working with a “basic” repository and workflow setup.

It’s much easier to do the boring bits first and involve stakeholders in negotiation to clearly define ones “designated community” of users, and the purposes of the repository and how it will be used by whom.

By doing this “obvious” stuff first so many questions along the way will become easy to answer. One can spend an awful lot of time and expense trying to design workflows and architecture models and working out what metadata to include in what places, etc etc. But having established from the very get-go exactly who one’s user group/s are to be, how and for what purposes they are to use the repository, and general policies to set the direction and purposes of the whole show, the time and stress on working out many of those metadata and workflow/architecture basics will just fall into place. The guidelines will be there to make finding the answers relatively easy. Without those prepared-in-advance guidelines one will be pretty much be mostly guessing about what to do next, no matter how often one attempts to rationalize those guesses.

No wonder that the ISO standard, the preservation repository OAIS reference model, mandates that one first document one’s designated community, negotiate policies and purposes with stakeholders, and how and for whom/why the repository’s resources are to be used and preserved.

Many academic libraries have a huge advantage over some national or state libraries in the world. Those libraries that are constantly being starved for funds are pretty much forced to find ways to cooperate with peers, to share experiences and resources and ideas, and to make the most cost-effective decisions. Too much $$$ and one major incentive to cooperate and learn from others can wilt. Not good.