Now let’s turn our attention to ingest and include any preservation actions and storage. According to the DCC data life cycle model, ingest, preservation actions and storage are defined as follows:
- Ingest involves the transfer data to an archive, repository, data centre or other custodian while adhering to documented guidance, policies or legal requirements.
- Preservation action consists of actions to ensure long-term preservation and retention of the authoritative nature of data. Preservation actions should ensure that data remains authentic, reliable and usable while maintaining its integrity. Actions include data cleaning, validation, assigning preservation metadata, assigning representation information and ensuring acceptable data structures or file formats.
- Storage of the data is in a secure manner adhering to relevant standards.
We are very familiar with this type of action. For those that work with their ILS, ingest is a large part of the work that is done. Ingest can be single or batch upload. The same is true for digital repositories and even data creators. Of course, the ILS manages and stores metadata but not the objects themselves. For physical objects, we have our bookshelves. For electronic resources, we have a link to the resource, which is stored and managed on a server that may or may not belong to the institution. This means that the level of control in regards to storage and preservation vary between the systems in play: ILS, digital repository, subject repository, hosted digital library, database, etc. Institutions have a number of platforms that manage metadata and sometimes the resources about which they describe. Think of the “silos” that many of us encounter. One of the issues is how to make our work seem seamless with these silos, especially for our patrons. This doesn’t always work.
Where I work, we have a variety of “options” for our users: WorldCat, Summon, Homer. Then there are our digital collections. There are other collections on other servers and the list goes on. One issue is how to provide seemless access and discovery to all of these or at least a majority of these systems for our users. For staff, it is knowing where to find information as well as knowing the flow of information between the various groups that need to do something to a resource before it is delivered to the user. Can next generation ILS solve many of these issues? Probably not. Most likely there will be a need for a discovery layer that deliveries metadata and/or objects in a variety of presentation formats based on the needs of a particular community. Suffice to say that this will take work behind the scenes certainly in terms of programming but also metadata. Metadata will power these discovery and presentation layers. It will be essential to have decent metadata or data that are accurate, consistent and of fairly good quality (or good enough to unique describe a resource). Not all of these metadata can be created and maintained automatically. In short, these metadata will have to be created and then also maintained. In not, then the toys our users expect from metadata will be absent and they will head somewhere else.