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

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