METS: An Introduction

1
METS An Introduction

• Part III
• METS and MOA2

2
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

3
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.

4
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

5
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

6
Header Compared

• MOA2
• no header

• METS
• Header
• CREATEDATE, MODDATE, RECORDSTATUS
• agent
• alternate IDs

7
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

8
Descriptive Metadata Compared

• MOA2
• DescMD
• External Reference
• Full dmd element set
• wrapped binary

• METS
• DescMD
• External Reference
• No dmd element set
• wrapped binary

9
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

10
Admin Metadata Compared

• MOA2
• 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

11
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 LCs work
• potentially a lot of work here selecting the
  most appropriate schemas, working out mappings,
  etc.

12
Admin Metadata Discussion

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

13
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

14
File List Discussion

• Dropped File attributeUSE
• 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.

15
File List Discussion (contd)

• Use of xlinkhref (etc) for FLocat
• net locations of resources (content files) will
  be carried as xlinkhref attribute value, rather
  than as element value.
• Implications for UCB
• Transition should be pretty straightforward
• Additional xlinkSimpleLink attributes may be
  useful as qualifiers of links

16
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

17
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).

18
Behavior Compared

• MOA2
• no behavior section

• METS
• behavior section
• interface definition
• mechanism

19
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 dont implement FEDORA per se

20
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 ltfilegt 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