![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
k-federated gets divorced!
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
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
no subject
Re: 2. If it needs perpetual preservation, put it in the IR. If not, don't. Your other problem is access rights, of course -- but if your IR is campus-only access, that becomes less of an issue.
My sense is that in five to ten years the multiple-product problem will be less annoying; we should have much better interop and more fully-featured offerings. But for now, yes, it's a distinct problem.
no subject
The thing about perpetual preservation is bit institutional repository isn't the only place to put assets which need perpetual preservation. Archives and special collections, for example, also need perpetual preservation. Unless you are using the wider the definition of institutional repository which I have been seeing lately?