1. Preserv: Preservation architecture and interface A brief overview of ideas wrt to the project plan For Preserv partners meeting, BL, London, 18th November 2005

2. From DCC Workshop on the Long-term Curation within Digital Repositories Preservation storage media, migration, etc. Preserv partner British Library Preservation service providers Preserv partners eprints.soton Oxford Univ. IRs, Eprints.org, DSpace, etc. User/authorUser/reader DepositAccess Machine interface OAI IR author deposit interface FormatFormat Format ID TNA + Pronom Users IR managers and admins Heads of institutions Research funders Course leaders Teachers Education funders Stakeholders

3. From the project work plan: workpackages (to end 2005) 1.Review preservation metadata 2.Pilot Eprints preservation-enabled deposit interface (with Pronom) 3.Pilot IRs, build and test 4.Preservation planning services Stakeholder survey Service provider business models 5.Preservation service harvesting

4. Preservation storage media, migration, etc. Preserv partner British Library Other preservation service providers Preserv partners eprints.soton Oxford Univ. IRs, Eprints.org, DSpace, etc. User/authorUser/reader DepositAccess Machine interface OAI IR author deposit Interface: capture preservation metadata FormatFormat Format ID TNA + Pronom Users IR managers and admins Heads of institutions Research funders Course leaders Teachers Education funders Stakeholders Workpackages are somewhat sequential, starting here, but need to take account of the whole picture inc. feedback loop

5. Preservation service providers Our model is defined by responsibility for preservation, i.e. implementation of OAIS This model is not very different from the schematic sketched for Preserv, especially in terms of the core components – Ingest, Data Management, Archival Store, Access

6. Preservation storage media, migration, etc. Preserv partner British Library Other preservation service providers Preserv partners eprints.soton Oxford Univ. IRs, Eprints.org, DSpace, etc. User/authorUser/reader DepositAccess Machine interface OAI IR author deposit Interface: capture preservation metadata FormatFormat Format ID TNA + Pronom Users IR managers and admins Heads of institutions Research funders Course leaders Teachers Education funders Stakeholders

7. Preservation service providers: business models for IRs There is more than one model, e.g. 1. Eprints + service provider (service provider is OAIS) the model we set out to test 2. Eprints + e.g. FEDORA (institution is OAIS) 3. Eprints + built-in preservation (repository is OAIS) c.f. DSpace, the minimal preservation approach 4. Eprints + federated (federation is OAIS), c.f. LOCKSS See also Knight, G., SHERPA-DP OAIS Report: An OAIS compliant model for Disaggregated services http://ahds.ac.uk/about/projects/sherpa-dp/sherpa-dp-oais-report.pdf

8. The feedback loop To decide which model might apply where, we need to survey the views of different stakeholders: users, IR managers and admins (e.g. Oxford, Soton), heads of institutions, research funders, as well as service providers (e.g. BL) To define what information to capture at the interface, we need to know what model we are applying

9. Chicken or egg? A way forward Series of reports with interim recommendations Consult stakeholder groups to identify preservation needs (Soton) Identify required and IR-collectable preservation metadata (Soton and BL) Enhancing Eprints software for preservation: – deposit interface (not just Soton and TNA: all partners!) – dissemination interface (Soton and BL)

10. Deposit interface Preservation features of IR software File formats and preservation PRONOM format ID and verification tool Discovered IR/self-archived formats Preservation implications of IR formats Working with PRONOM in EPrints (describing the implementation, experiences) Preservation metadata (main findings of PM report) Design for implementation

11. …Leading to implementation Specify scope and implementation of pilot IRs (Soton and Oxford) Source of content (deposit, copy from existing IR, harvest) IR requirements (set out manager, admin. and QA requirements) Contains basis for testing and evaluation