ECHO DEPository

1
ECHO DEPository

• Repository Evaluation
• Tools development
• Web harvesting and archiving
• Preservation Research
• preserving the authenticity and semantic meaning
  of digital resources through time.

2
Hub and Spoke

• Repository Interoperability Architecture with a
  forward-looking emphasis on preservation metadata
  and activities

3
The problem

• Plethora of repositories
• Not just across institutions, but even with a
  single institution
• Overabundance of data sources
• Web crawlers like Heritrix or OCLC's WAW,
  digitization and scanning services, individual
  authors, batch ingest from legacy systems
• Current integration solutions are local and ad
  hoc
• Enforcing centralized preservation policy
  difficult

4
The solution

• A common METS-based profile
• A standard programming API
• A series of scripts that use the API and METS
  profile for creating SIPs and DIPs which can be
  used across different repositories

5
(No Transcript)
6
Details of current implementation

• Based on ingest scripts that were developed to
  support the repository evaluation
• Java except at the outermost layers where native
  API calls are utilized
• We consider this a proof-of-concept
  implementation the goal being to demonstrate
  round-trip interoperability between three
  repositories DSpace, Eprints, and Fedora

7
Phased implementation

• Phase 1 Interoperability
• Phase 2 Persistent Storage Layer
• METS Profile as an AIP
• JSR-170 content repository standard
• End-user Access (search/browse/render) is low
  priority

8
To-Hub Spoke
Data Store / DIPs
Extract format-specific technical metadata
Generate/collect digital provenance metadata
Embed links to digital items
image.jpg
Model structure of the item
Embed native metadata
Transform/enrich native metadata
metadata.xml
9
From-Hub Spoke
SIPs
Transform hub metadata to repository-compatible
metadata
Assemble into packages for repository ingest
Add the METS file as an item in the submission
package
metadata.xml
hubMets.xml
10
METS Profile

• DRAFT http//dli.grainger.uiuc.edu/echodep/mets/
  DRAFTS/BaseMETSProfile.xml
• May be overlaid on top of, or inherited from,
  other profiles
• Foci
• Repository interoperability
• minimally at the file and descriptive metadata
  level, probably not at the structural level
• Digital preservation
• Web captures
• Focus on preservation, not access
• agnostic regarding file formats or structures

11
METS Profile

• Descriptive Metadata
• Required MODS
• Retain any native descriptive metadata
• Technical Metadata
• Required PREMIS Object for each file or
  bit-stream
• File level technical metadata appropriate per
  format
• E.g. textMD for text files, MIX for images
• Raw JHOVE output

12
METS Profile

• Provenance
• Recorded for all non-trivial changes to
• Descriptive Metadata
• Files and Bitstreams
• Structural Maps
• PREMIS Event and optional associated Agent
• ECHODEP Event Types
• METADATA_TRANSFORMATION
• METADATA_CREATION
• STRUCTMAP_MODIFICATION
• STRUCTMAP_DELETION

13
METS Profile

• Requirements for use of PREMIS
• All linking via ID IDREF-type attributes not
  identifier elements
• Embedding
• Object in techMD
• Event in digiprovMD
• Rights in rightsMD
• Agent in digiprovMD or rightsMD
• All Files at a Composition level of 0
• No packaging, compression, or encryption

14
Possible Outcome

• Extension of the Harvard METS API for support of
  PREMIS elements
• instantiate PREMIS schema elements as objects
• set element and attribute values
• add to the content model of its parent METS
  element