Metadata: use of METS with Fedora

Marie LagerwallTechnical Officer

m.e.lagerwall@lse.ac.uk

Centre for Learning TechnologyLondon School of Economics and Political

Science

MIDESS Dissemination Event May 4, 2007

METSMetadata Encoding & Transmission Standard

• METS is expressed using XML and its main function is to encode metadata and facilitate metadata transmission.

• Development is funded by the Digital Library Federation and steered by an Editorial Board meeting twice yearly at METS Opening Days. The official METS web site is hosted by the Library of Congress.

• Currently taking place in Göttingen, Germany:

– METS Editorial Board meeting - May 4, 2007 (today!) – METS Opening Day – May 7, 2007– METS Implementers meeting – May 8, 2007

METSMetadata Encoding & Transmission Standard

• Metadata Encoding:

– To encode administrative, descriptive and structural metadata for the purposes of managing digital objects within repositories.

• & Transmission Standard?

– Can be deployed as Submission Information Package, as has been done at the LSE.

– Can in theory be used for migrating/exchanging digital objects between systems, though in practice, this is made difficult by the existence of a variety of METS profiles.

• The Repository Bridge project answered some of these problems by developing DSpace and Fedora plug-ins for facilitating the exchange of METS files between systems.

• A collaborative project between Cornell University and SUB Göttingen is being planned to address the issue of interoperability of METS files between repositories.

METS: structure http://www.loc.gov/standards/mets/METSOverview.v2.html

• METS header <METS:metsHdr>, metadata describing METS file.• Descriptive Metadata <METS:dmdSec>, metadata such as DC,

MODS, MARCXML; metadata can either be embedded <mdWrap> or referenced <mdRef>.

• Administrative Metadata <METS:amdSec>, metadata such as MIX, PREMIS; either embedded or referenced.

• File Section <METS:fileSec>, comprises all files making up the object being encoded, such as Quicktime, Real Media, or JPEG, TIFF, etc. Files can either be referenced <FLocat> (using a URL) or embedded <FContent> (base 64 encoded).

• Structural Map <METS:structMap>, links files and metadata into a hierarchy.

• Structural Links <METS:smLink>, records the existence of hyperlinks between nodes in the hierarchy outlined in the Structural Map.

• Behavior <METS:behavior>, associates behaviours with the object or files.

METS at the LSE

• In the context of the MIDESS Project at the LSE, METS has been used to create Submission Information Packages (SIPs) for bulk ingesting digital objects and files into Fedora.

• Fedora’s METS extension (yet another profile!) available at http://www.fedora.info/download/2.2/userdocs/digitalobjects/rulesForMETS.html and example METS (mets-ingest-example.xml) were looked at, and form the basis of the ingest work carried out for the CLT media database (c. 700 objects).

• The Paradigm Project’s documentation on METS and the Fedora Directory Ingest Service available at http://www.paradigm.ac.uk/workbook/ingest/fedora-diringest.html, and Fedora’s example Submission Information Package (three.zip) were also studied, and inform the ingest work carried out for the Malinowski photographs (c. 1100 photographs in total and around 150 ingested).

CLT media database ingestusing Fedora Client Command-Line Utilities (CMD)

• METS: structure (METS file available as print-out or on request)

– METS header <METS:metsHdr RECORDSTATUS="A"/>– Adm. Metadata <METS:amdSec ID="CLT" STATUS="A"> - CLT

metadata.– Adm. Metadata <METS:amdSec ID="DC" STATUS="A"> - DC

metadata.– Adm. Metadata <METS:amdSec ID="RELS-EXT" STATUS="A"> -

RELS-EXT metadata, describing parent-child relations between objects.

– File Section <METS:fileSec><METS:fileGrp ID="DATASTREAMS"> - QuickTime and/or Real Media file(s).

– No Structural Map <METS:structMap>! It could thus be argued this does not constitute a METS file as such..

CLT media database ingest

• 1 METS file per object (mets_2000.xml-mets_2705.xml),• all 705 METS files placed in a directory:

• directory ingested to Fedora using CMD:

• ingest takes just under 1 minute (video files remain on CLT streaming server!).

Malinowski photographs ingest

using Fedora Directory Ingest Service (DirIngest)

• METS: structure (METS file available as print-out or on request)

– METS header– Descriptive Metadata <METS:dmdSec ID="EAD"> - EAD

metadata of ‘series’ object (for eg. Malinowski/3).– File Section <METS:fileSec>- with <METS:fileGrp> including EAD

and DC metadata of ‘sub-series’ object (for eg. Malinowski/3/7), and EAD and DC metadata, JPEG and TIFF locations of ‘illustrations’ objects (for eg. Malinowski/3/7/1-Malinowski/3/7/44).

– Structural Map <METS:structMap> - describes hierarchical relations between parent and child objects (in this case, there are three levels: ‘series’, ‘sub-series’, and ‘illustrations’).

Malinowski photographs ingest

• 1 METS file for all objects (for eg. Malinowski3_forDirIngest_7_dc.xml)• METS file is zipped with associated folders and files:

• Zip file ingested to Fedora using DirIngest:

METS and Fedora: conclusions

• To have any success with using METS to ingest objects to a Fedora repository, start with the Fedora METS examples and forget about standard METS files..

• It is arguable the Metadata Encoding and Transmission Standard is not a standard at all.. There seem to be more local application profiles than there are standardised implementations..

• Ensuing problems of interoperability have to an extent been addressed (Repository Bridge), and are being addressed (Cornell-SUB Göttingen?), but METS’ sustainability as a metadata encoding and transmission standard, and as a content-packaging tool seems insecure.