METS: An Introduction

Part III

METS and MOA2

MOA2: A Brief History

• Digital Library Federation project started in 1997

• Main goal was to create a digital library object standard for encoding descriptive, administrative and structural metadata along with primary content

• Result: MOA2.DTD

Different Means: Schema vs DTD

• MOA2 rules expressed as DTD, METS as a Schema

• Implications:– Datatypes of attributes more tightly controlled

in METS– METS schema and METS instance documents

can use elements and attributes defined in other schemas/namespaces.

Only the Name Has Been Changed

• Virtually every element carried over from MOA2 to METS has undergone a name change.– This presentation will not detail the name

changes

• Attribute names tend to be more constant

MOA2 & METS Outlines Compared

MOA2• [no header]• Desc MD Section• File Section• Admin MD section• Structural Map• [no behavior section]

METS• Header• Desc MD Section• Admin MD section• File Section• Structural Map• Behavior Section

Header Compared

MOA2• [no header]

METS• Header

– CREATEDATE, MODDATE, RECORDSTATUS

– agent

– alternate IDs

Header Discussion

• MOA2 makes no provision for header information.

• METS allows metadata about the METS object to be expressed including– CREATEDATE, MODDATE,

RECORDSTATUS– Agents and roles– Alternate IDS

Descriptive Metadata Compared

MOA2• DescMD

– External Reference

– Full dmd element set

– wrapped binary

METS• DescMD

– External Reference

– [No dmd element set]

– wrapped binary

Descriptive Metadata Discussion

• METS does not provide an element set for encoding descriptive metadata– Must use element set defined in external

schema to encode desc md within METS object– Implications for UCB:

• develop own desc md schema: gdm

• use available desc md schema: DC, MarcLite

Admin Metadata ComparedMOA2• Technical metadata

– [no reference]– image element set– text element set– no wrapped binary

• Rights metadata– [no reference]– rights element set– no wrapped binary

• Source metadata– [no reference]– source element set– no wrapped binary

• [No digital provenance]

METS• Technical metadata

– external reference– [no image element set]– [no text element set]– wrapped binary

• Rights metadata– external reference– [no rights element set]– wrapped binary

• Source metadata– external reference– [no source element set]– wrapped binary

• Digital Provenance md

Admin Metadata Discussion

• METS adds a category of Admin metadata: Digital Provenance– some of our current SourceMD should map to

digiprovMD

• METS does not provide an element set for encoding administrative metadata– Must use element sets defined in external schemas to

encode admin md within METS objects– Implications for UCB:

• develop own admin md schemas (hopefully not)• use admin md schemas being developed: LC’s work • potentially a lot of work here: selecting the most appropriate

schemas, working out mappings, etc.

Admin Metadata Discussion

• METS provides for external and wrapped binary admin md:– METS treats all desc & admin md identically

File Lists Compared

MOA2• File Group• File

– USE attribute– Dimensions attributes– no CHECKSUM

• FLocat– non-empty– no xlink attributes

METS• File Group• File

– no USE attribute– no Dimensions – CHECKSUM

• FLocat– empty element– uses xlink: SimpleLink

File List Discussion

• Dropped File attribute:USE– Regarded as admin md– Implications for UCB

• GenView tool does make some use of this attribute• May be able to use one of the xlink attributes (on FLocat for

this instead.

• Dropped File attributes: dimension– Regarded as image-specific adminMD.– Implications for UCB:

• Tools use to determine which images should be treated as thumbnails. Probably a better way of doing this anyway.

• If we want to record this data (and we probably do), then this change may cause proliferation of techMD: one for each file.

File List Discussion (contd)

• Use of xlink:href (etc) for FLocat– net locations of resources (content files) will be

carried as xlink:href attribute value, rather than as element value.

– Implications for UCB• Transition should be pretty straightforward

• Additional xlink:SimpleLink attributes may be useful as qualifiers of links

Structural Map Compared

MOA2• structMap• div

– no ORDERLABEL– no ADMID

• fptr– [no area]

• fptr can express BEGIN

– [no seq]– [no par]

• mptr– xlink

METS• structMap• div

– ORDERLABEL– ADMID

• fptr– area

• express BEGIN END

– seq– par

• mptr– xlink

StructMap Discussion

• METS StructMap represents superset of MOA2: nothing is lost; lots is added

• Implications for UCB:– mapping MOA2 to METS should be easy

– New elements/attributes open up lots of possibilities:• MOA2 restricted to image & text content; METS supports AV

• Within text file MOA2 can reference a BEGIN point only (via TAGID attribute on fptr). METS can reference both BEGIN and END point (via area BEGIN END attributes).

Behavior Compared

MOA2• [no behavior section]

METS• behavior section

– interface definition

– mechanism

Behavior Discussed

• Primarily added for FEDORA compliance/convenience

• Implications for us:– May want to consider implementing FEDORA

architecture– May want to apply FEDORA architecture

concepts even if we don’t implement FEDORA per se

Conclusion• Mapping MOA2 to METS should be fairly

straightforward. Main Difficulties:– identifying amd schemas we want to use and doing the

mapping• change mapping of “sourceMD” for derivatives to

“digiprovMD”

– dealing with loss of <file> USE and dimensions attributes; possible proliferation of TechMD

• METS opens up a lot of possibilities and opportunities– Additional content types accommodated– Bounded mapping to text transriptions