Having been involved in many projects over the years, including some that were purely IT (information technology), I know that we often don't go through this exercise as thoroughly as we should. We think of the project, outline it, create goals/deliverables/etc., and then rush into it. Stopping to examine the project from different viewpoints could be very helpful and might even ensure that the project can be completed as envisioned! (As a business searcher, I often will "walk through" a search reuqest, in a similar fashion, before agreeing to do it. What would the search statements me? Who might keep that type of information? What will the results look like? Over the years, stopping to think ahead like that has served me well.)
As for this mythical project for Harrisburg, PA, one important area to consider further is access (see part 2 for information on the products to be created). Two areas that important when thinking about access are:
- The content management system (software that will house the a metadata and allow it to be searched) or digital asset management system
- The metadata
- Madison Digital Image Database (MDID)
- Luna Insight
In order for this project to decide on software, I would first ask it to think about its resources -- both short and long-term -- for providing support and maintenance of such software. If the collaborators felt confident that they could support the software themselves (primarily) long-term, then I would suggest that they look at an open source package, since it would likely be more customizable to their situation. If they felt that they wanted to rely on the vendor to provide support long-term, then I would suggest that they look at those products that they could license. No matter what their answer, I would want them to look at and evaluate several packages and not just accept a piece of software because "someone else" is using it.
I would advise this group to select something that it felt it could live with for 5 - 10 years, not because moving to a new package would be difficult (it shouldn't be), but that it would be best to be on a stable platform for a period of time so they can focus on other areas that will need their attention.
BTW here is a document that compares some of these products, created by the CURL Task Force on Digital Content Creation and Curation.
As for metadata, they should use qualified Dublin Core, which is being widely used, especially when the content is not being integrated into a library management system (OPAC). They should define the individual elements (fields) and appropriate content. Since the creation of the metadata could be divided among the collaborators -- or outsourced -- they should have an authority file that details everything, so that there is consistency across metadata creators. The team should provide sample records for each type of material digitized, so that the metadata creators have examples to follow.
Metadata can be time-consuming to create, if there is research needed. Therefore the collaborators should try to provide as much information for each item digitized, so research can be limited.
As a librarian who does not consider herself a cataloguer, I would want the team to be sure to discuss the metadata with those who "live and breath" cataloguing in order to get their input. If the metadata is being created by people who are not cataloguers, the team should be sure to provide as much training as possible in order to infuse them with knowledge.
There are two areas left to discuss -- preserving this new digital work and marketing. Tomorrow we'll continue with those topics.
For the first parts of this series, read part 1, part 2, part 3 and part 4.
Technorati tags: Digitization, Harrisburg, Pennsylvania