# Presentation: 530467

## Interoperability and Preservation with the Hub and Spoke (HandS)

- Matt Cordial, Tom Habing, Bill Ingram, Robert Manaster
- University of Illinois Urbana-Champaign
- cordial;thabing;wingram2;manaster@uiuc.edu

- Repository Interoperability

## Interoperability is useful in its own right, but it is also important for preservation

Out-of-the-box repository interoperability is low
Institutions commonly rely on multiple repositories
Repository support for emerging preservation standards is low
Repositories change over time

- Interoperability is useful in its own right, but it is also important for preservation
- Out-of-the-box repository interoperability is low
- Institutions commonly rely on multiple repositories
- Repository support for emerging preservation standards is low
- Repositories change over time

- Key Ideas

## Slide 3

## The Essentials

- Extensible METS profile
- Repository specific processing and transformation utilities
- Java API for local integration and extensibility
- Apache XML Beans
- Dissemination/Submission Web-service
- RESTful

## Slide 5

## Slide 6

## Functional Overview

- METS Profiles

- Repository

## Non-prescriptive in regards to structure or file formats 
Intended to overlay other profiles which specify case-specific needs (i.e. web captures)
PREMIS 
MODS 
Must conform to the DLF Aquifer profile 
File-format specific technical metadata 
MIX, VIDEOMD, AUDIOMD, others as appropriate

- Intended to overlay other profiles which specify case-specific needs (i.e. web captures)
- PREMIS
- MODS
- Must conform to the DLF Aquifer profile
- File-format specific technical metadata
- MIX, VIDEOMD, AUDIOMD, others as appropriate

- METS Profiles

## Master METS + Snapshots

## Functional Overview

- METS Profiles

- Repository

## Technical Metadata Generation/Augmentation

- JHOVE Output + Custom XSLT
- Java “Applicators” for specific technical metadata schemas
- MIX
- TEXTMD
- AUDIOMD
- PREMIS
- Class hierarchy to support new Applicators

## Functional Overview

- METS Profiles

- Repository

## To-Hub Processing

- Data Store / DIPs

- metadata.xml

- image.jpg

- Extract format-specific technical metadata

- Transform/enrich native metadata

- Embed native metadata

- Generate/collect digital provenance metadata

**To-Hub Processing**

- Embed links to digital items

- Model structure of the item

## From-Hub Processing

- SIPs

- hubMets.xml

- Add the METS file as an item in the submission package

- Transform hub metadata to repository-compatible metadata

- Assemble into packages for repository ingest

**From-Hub Processing**

- metadata.xml

## Functional Overview

- METS Profiles

- Repository

## Packages usable by a repository’s native ingestion routines
REST Web-Service 
Client integrated into processing workflow
DSpace, EPrints, and others in the next year
Specification and API to create service for other repository systems
Similar to SWORD (Simple Web-service Offering Repository Deposit) 

- Packages usable by a repository’s native ingestion routines
- REST Web-Service
- Client integrated into processing workflow
- DSpace, EPrints, and others in the next year
- Specification and API to create service for other repository systems
- Similar to SWORD (Simple Web-service Offering Repository Deposit)

- LRCRUD

## Service calls the native DSpace dissemination routine

- Client submits a GET request to LRCRUD service for a specific item
- Service receives the output from the dissemination, creates a header file, and adds both the header file and the disseminated content to a zip-file
- Service returns a zip-file containing the package to the client

## Create stub record

_**Create stub record**_
- Client issues a POST request to LRCRUD specifying “where” to create the record (e.g. communities or collections) if needed
- LRCRUD calls the native Fedora creation routine
- Fedora supplies LRCRUD with the ID for the newly created record
- LRCRUD responds to the client with an HTTP 201 “Created” message and returns the ID in the Location: header
_**Upload and ingest the item**_
- Client issues a PUT request to LRCRUD to replace the package identified by the URI. The entity body of the request must contain the zip-file containing the package to be ingested.
- LRCRUD unpacks the files and calls the native Fedora ingestion routine.
- Fedora tells LRCRUD that ingestion was successful
- LRCRUD responds to the client with an HTTP 204 “No Content” message indicating that the request was successful.

## Other Technologies

- Open Archives InitiativeObject Reuse and Exchange
- http://www.openarchives.org/ore/

## Open Source Code:
	http://sourceforge.net/projects/echodep

LRCRUD Service Specification:
	http://dli.grainger.uiuc.edu/echodep/hns/LRCRUDS.htm

METS Profiles:
	Generic - http://www.loc.gov/standards/mets/profiles/00000015.xml

	Web Capture - http://www.loc.gov/standards/mets/profiles/00000016.xml

Java API Documentation (Javadoc):
	http://echodep.sourceforge.net/javadoc/index.html

Project Web Sitehttp://ndiipp.uiuc.edu/ 

- _Open Source Code:_
- 	http://sourceforge.net/projects/echodep
- _LRCRUD Service Specification:_
- 	http://dli.grainger.uiuc.edu/echodep/hns/LRCRUDS.htm
- _METS Profiles:_
- 	Generic - http://www.loc.gov/standards/mets/profiles/00000015.xml
- 	Web Capture - http://www.loc.gov/standards/mets/profiles/00000016.xml
- _Java API Documentation (Javadoc):_
- 	http://echodep.sourceforge.net/javadoc/index.html
- _Project Web Site_http://ndiipp.uiuc.edu/

- More Information

## Questions?

- Tom Habing
- thabing@uiuc.edu