No life cycle is complete without investigated how to migrate your data. This includes continually appraising your metadata in addition to changing ways of implementing it. According to the DCC, migration includes the following:
- Dispose: Dispose of data, which has not been selected for long-term curation and preservation in accordance with documented policies, guidance or legal requirements.
- Reappraise: Return data which fails validation procedures for further appraisal and re-selection.
- Migrate: Migrate data to a different format. This may be done to accord with the storage environment or to ensure the data’s immunity from hardware or software obsolescence.
Migration includes a discussion about what to do with these metadata, or data, in the future, in addition to right now. This is an extremely important topic, one that is often left out of discussions on metadata. A recent comment brought this into perspective and let me quote the question here:
How does metadata solve the needs of today but also last and become responsive to metadata that’s needed in the future, or systems that become used in the future?
What happens if you don’t consider the future needs of your metadata?
Before speculating about the future, let’s consider the three categories above from the DCC for metadata. It is essential to continually re-appraise your metadata and implementation of metadata in projects. Rights can change over time. You might acquire more information on a resource. You might be changing from one metadata schema to another more granular allowing for more detailed description. A good example that comes to my mind is that recently one of our curators re-evaluated how finding aids were being described in EADs. These finding aids also go into our catalog and in the near future will be added to our digital repository. This cross pollination requires forethought about how these different systems work and how to facilitate the movement of data and metadata from one system to the next. Our digital repository uses the linked data FAST. The EADs use the DACS content standard. Our MARC records can accommodate both this content standard (to a certain extent) and linked data FAST. Already, you can see the complexity and interplay between encoding and content standards as well as the choices made for controlled vocabularies. Before coming to a decision, it was necessary to re-evaluate how these metadata were being used in each system, those systems’ environments and more importantly the possible future uses of our metadata. Currently, we don’t implement linked data. But this is a direction we want to go. In light of this, we are beginning to add linked data uri’s especially to subjects, genres, and names.
Any re-appraisal also includes some disposal. In the example above, we decided to no longer implement Library of Congress subject headings. One reason is that we wanted an easier way to facet our search and discovery and found FAST more amenable to this for our digital repository. This decision meant “disposing” or more appropriately changing the LCSH to FAST terms. A lot of work yes. Necessary – not for everyone. Think of RDA. Not everyone will change their entire catalog to conform to RDA. Though I recently listened to a Marcive representative who explained that this is possible through their data cleanup and reconciliation process; no fee was mentioned. What is important is that with any disposal of metadata, it needs to be done consistently and accurately. Hopefully the metadata that needs to be disposed of was implemented accurately and consistently. If there is a readme file that accompanies how you implemented your metadata, this process is much simpler. Such readme files are AACR2 and the LC site that explains how to implement MARC21. Or these files can be the DLF Aquifer MODS Implementation Guidelines.
It could happen that you need to migrate your data completely. It could be that your are building a new digital repository and want to expose collections there. In this case, which is something we’re doing, we have EADs in Archivist Toolkit and then we also migrate these metadata to the digital repository. The data (or resources) are on a separate storage device. In this scenario, the metadata are moving and being transformed more often than the resources, which is a good thing. One of the great advantages of such a project, at least where I am, is that we can really sit down to evaluate and appraise our metadata, our approaches to metadata and how we implement them. It is really these discussions that lead us to consider the metadata needs of the future. Again we come to the question asked by one of my commentators in the beginning of this post.
What happens if you don’t consider the future needs of your metadata? Well, there is a good chance that your metadata will no longer be able to describe the item appropriately in the environment in which it is stored. Isn’t this the problem of MARC21 and why people are searching to make our data visible or more visible on the web? We really can’t know what the future holds. However, we know it will change. To help make these changes in the future, we have to plan know by asking key questions about our metadata:
Who is going to use it? How is it going to be searched, displayed and accessed? How will it be stored? How can metadata be uploaded and extracted? Are there mechanisms in the system to update the metadata schema in place?
And there are so many more questions. Essentially, you need to plan the entire life cycle of metadata in addition to the different types of data you need to uniquely describe in relation to the platform where these will be stored and managed. No matter what plan you decide on, always remember: standards, standards, standards! Be sure to start with consistent and accurate metadata and data as possible. Even if you use a home grown system, make sure it is accurate and consistent. Create a readme text file or some other documentation that explains the plan in place, the metadata standards in place, local practices and implementation guidelines. This is essential because when (not if but when) you need to migrate, this documentation and accurate/consistent metadata will help you make a more efficient and easier migration from one metadata schema version to the next or from one system to the new and improved system. The big lesson from DCC is that appraisal happens at each step of the way. With some planning, using standards, and documenting decisions, and always re-appraising your needs, your metadata can solve your current needs and be transformed to respond to future needs as well.