Ramblings on Librarianship, Technology, and Academia

You know it's a good conference when you've sent your coworkers countless caffeine-fueled e-mail messages that read I AM SO BRILLIANT LOOK AT MY BRILLIANT IDEA or WE ARE SO STUPID WHY DIDN'T WE THINK OF THIS BRILLIANT THING THAT EVERYBODY ELSE IS DOING. Or when you've made a blog post illustrating academic repositories as toddlers playing with a toy truck. I strongly suspect my coworkers wish I would lay off the café con Leche already.

I have this crazy WordPad document open full of notes and links, and I can't figure out which of them are e-mails to specific departments, which of them are notes for myself for further investigation, in which of them are totally awesome blogable exciting links to share with YOU, my loyal readers.

( trying not to ramble too much outside of cut: scientific workflows, datasets, faculty information systems )

I see two overarching themes of the conference: the first is Interoperability Is the One True Religion. No silo-like repository can solve everybody's problems. We are interdisciplinary and inter-institution, and we won't solve any problems and less our resources and data can be used by other tools, other resources, other datasets, etc. The second theme I see is Duraspace Helps Those Who Help Themselves. This is open-source software, and we all need to pitch in, and everything is going to be perfect in a modular happy world where everyone writes the tools they want and shares them in an open source community.

Yesterday, in the Tufts Digital Collections and Archives blog (tufts_dca), I talked about our newly-launched institutional repository, Tufts eScholarship. I'm very optimistic about the success of our IR, though there has been a lot of conversation in the IR world about what makes institutional repositories fail. The number one reason I'm optimistic about our IR: it's not what purists would call an institutional repository.

( I'd like to buy university digitization efforts a Coke and teach everyone how to work with each other: cut for length )

The decisions leading to this wonderful conjunction of circumstances all predate my presence here at the university by many years. I'm talking about this not to toot Tufts' horn, but to push this vital idea of collaboration. Even now, I see so many institutions in the repository space that have entirely orthogonal approaches within their own organizations. The people digitizing images aren't talking to the people digitizing texts aren't talking to the people dealing with digital records aren't talking to the people doing institutional repository. Sure, maybe you would never use the same software platform or workflow approaches for all of these efforts. But maybe you will. Maybe instead of getting six different perfect software packages, you will find something that is good enough for all of you, and uses only one license, a smaller number of technical support staff, and something which will continue to be supported by your university even if hard economic times make some of the digital collections look less important.

Heck, I'm looking at this entirely selfishly, and you should too. In tough economic times, digital archives might go by the wayside. Open access institutional repositories are still untested. But management of the university's digital records is never going to be unnecessary. Work with other people instead of merely alongside them, intertwine your jobs, and you will not just save your institution money and resources, but you will increase the number of ways in which you are vital. Job security FTW.

Okay, folks, I need your help. I am currently getting soaked in a brainstorm, and I'd like to get this idea down before I lose the details. But since this is a brainstorm, it might make no sense at all. Tell me if what I'm talking about is an incredibly stupid idea that will never work. Alternately, tell me if what I'm suggesting is ridiculously common, and everybody does it this way already, and how could I not have noticed?

The two-part problem:

1. As we investigate products for digital asset management in the library, it's extremely likely that no one product will solve all of our needs. We will perforce find ourselves with digital resources in a number of different products, and will need to design either a single front end, or we'll have to accept a certain amount of user confusion at not knowing which tool holds the resources they need.

2. It's entirely possible that a single asset might be simultaneously part of our institutional repository and yet necessary for our learning management software, or similarly dual-purposed. How do these assets get filed? In what product?

My idea: carefully design an institution-specific set of metadata fields for each purpose. One indicating institutional repository, for example, and another indicating learning management. Assign as many of these metadata fields as necessary to each asset, no matter what product the asset is stored in. Store the asset in a product which is best suited for that asset-type. Then, using some kind of harvesting (e.g. Z39.50, OAI), harvest the contents of the various products and repositories. Write an institution-specific search mechanism that knows how to search the harvested data for all, say, institutional repository items. Or for all items in the special collections.

This idea of course ellides several major problems: designing the metadata; building what is effectively a small-scale federated search tool; deciding the appropriate product for the appropriate kind of asset; submitting assets into a multitude of products, possibly by non-librarian users such as faculty members and students. But is there any meat to this idea?ed