{"id":531,"date":"2009-11-02T17:02:37","date_gmt":"2009-11-02T16:02:37","guid":{"rendered":"http:\/\/blog.soton.ac.uk\/keepit\/?p=531"},"modified":"2009-11-02T17:02:37","modified_gmt":"2009-11-02T16:02:37","slug":"an-architecture-for-preservation","status":"publish","type":"post","link":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/2009\/11\/02\/an-architecture-for-preservation\/","title":{"rendered":"An architecture for preservation?"},"content":{"rendered":"

\"Preservation<\/a>Do we need an architecture for digital preservation? If so, what might it cover? Perhaps content types (e.g. data, teaching materials), management types (e.g. repositories), institutions, infrastructure (networks, storage) and services. Something more concrete than OAIS (references below), for example, which is after all a reference model, not an implementation.<\/p>\n

Working on the Preserv projects and now KeepIt, whenever it might have seemed possible to map a preservation architecture for institutional repositories, things have suddenly changed. There’s one advantage already of a reference model over an implementation. For example, we had a powerful new Sun Honeycomb storage server for Preserv, and not long after Sun announced it was being withdrawn from the market. Think again. Now we have cloud storage. How long until the fatal flaw in that strategy emerges, if it hasn’t already, although colleagues are working on a promising way of applying the Honeycomb principles in an institutionally controlled cloud (see these\u00a0slides<\/a>, but note this blog comment<\/a> on the live presentation: “extraordinary presentation … The slides don’t give the flavour; you just had to be there”).<\/p>\n

A preservation architecture is a nice idea in principle, for example being able to say: here is a repository responsible for content (a) which it can predict and plan, it can assess the risk and manage this content using tools (b) and outsource some technical functions to service (c), keeping copies of the content at locations (d) and (e) for access and archiving. Such a prescription, if it were possible, might appeal to repository managers, and might act as a template for repository preservation. In turn, it would become easier to plan and develop the sort of services on which such an architecture depends.<\/p>\n

Admittedly, it all sounds a bit Soviet-style and rests on the assumption that once framed nothing will change this architecture, the antithesis of the digital environment where everything changes all the time. Would we want it any other way?<\/p>\n

I was prompted to revisit these architectural thoughts by a curious story<\/a> about a joint project –\u00a0on Collection Development, Acquisitions, Preservation –\u00a0between the university libraries of Cornell and Columbia. Actually I wasn’t that curious until this part: “Cornell and Columbia assert that the project\u2014not a merger\u2014could be …” Hold it there. It hadn’t seemed remotely like a merger story, but now you mention it, there is an interesting idea here. Are digital libraries enhanced by mergers? Certainly there is a scale problem with digital preservation that might be helped by a joint approach.<\/span><\/strong><\/p>\n

I don’t know to what extent digital academic libraries will be transformed by the open Web, that is, to become sources of content from the institution rather than acquirers of content from elsewhere. That’s my institutional repository viewpoint again. In the IR scenario, of the titular functions from the story above, preservation remains a concern.<\/span><\/strong><\/p>\n

You see, what they have done in this project by collaborating and suggesting a merger, is they have altered another of the factors in our nascent architecture: this time it’s the institutions and the\u00a0infrastructure that have changed, rather than the storage service.<\/p>\n

How would OAIS handle this? OAIS allows us to model a preservation architecture and build an implementation. If we are rigorous, we are encouraged to become ‘OAIS-compliant’, that is, we don’t simply treat OAIS as helpful advice, but we fulfil all the necessary requirements. This is important because one day we may want to be seen as a ‘trusted repository’, and that is likely to be measured against OAIS-related criteria. If we take library 1 and library 2, both of which are OAIS-compliant, and put them together as at Cornell and Columbia, is the result OAIS-compliant, or are we breaking compliance? Probably, initially at least until a full analysis has been performed on the new organisational framework. If we add in services, what needs to be OAIS-compliant? Without practice and experience, we don’t know. When it comes to institutional repositories we don’t have this experience, and I suspect not many others have it either, likely excepting the established preservation centres such as national libraries, and their experience may not be directly applicable.<\/p>\n

There are certain places that digital preservation should begin, but these should not be the same for everyone. A manager of an institutional repository, for example, need not be a preservation specialist. At the moment, however, we seem to be expecting everyone to begin with OAIS (formal<\/a>, intermediate (tutorial)<\/a> or\u00a0less formal<\/a>), formats, etc. Instead there should be tools, services, interfaces, and perhaps a preservation architecture, that embed specialist knowledge and practice, and provide a better starting point for non-specialists. We have to be bold to move forward from the abstract model.<\/p>\n","protected":false},"excerpt":{"rendered":"

Do we need an architecture for digital preservation? If so, what might it cover? Perhaps content types (e.g. data, teaching materials), management types (e.g. repositories), institutions, infrastructure (networks, storage) and services. Something more concrete than OAIS (references below), for example, which is after all a reference model, not an implementation. …<\/p>\n","protected":false},"author":869,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[4],"tags":[],"class_list":["post-531","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/posts\/531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/users\/869"}],"replies":[{"embeddable":true,"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/comments?post=531"}],"version-history":[{"count":0,"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/posts\/531\/revisions"}],"wp:attachment":[{"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/media?parent=531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/categories?post=531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/generic.wordpress.soton.ac.uk\/test-media\/wp-json\/wp\/v2\/tags?post=531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}