200 likes | 230 Views
Explore the shift from MOA2 to METS metadata standards, implications on encoding metadata, and how it impacts digital libraries.
E N D
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 [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 MOA2 & METS Outlines Compared
MOA2 [no header] METS Header CREATEDATE, MODDATE, RECORDSTATUS agent alternate IDs Header Compared
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
MOA2 DescMD External Reference Full dmd element set wrapped binary METS DescMD External Reference [No dmd element set] wrapped binary Descriptive Metadata Compared
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
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] Admin Metadata Compared • 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
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 Lists Compared
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
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 Structural Map Compared
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).
MOA2 [no behavior section] METS behavior section interface definition mechanism Behavior Compared
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