2020 11 05 Board Meeting Notes

METS meeting (2020-11-05)

• Host: Tobias Steinke
• Notes: Andreas Nef

Attendees

• Tobias Steinke
• Karin Bredenberg
• Brian Tingle
• Jukka Kervinen
• Robin Wendler
• Aaron Elkiss
• Andreas Nef

METS tutorial on-line? Discuss if/when/how

Continuing the discussion from a week ago.

Timewise, given that it's going to be online, it's probably limited to around 2-3 hours. We should not dive too much into PREMIS aspects except for general guidelines. Re-use existing presentations for the introduction, use cases based on recent work (for example E-ARK). Also discuss/show METS profiles. We should promote it through DPC and OPF mailing lists, but not necessarily in collaboration. Aaron could provide the platform (zoom). Target for a few dates in spring, at least one in EST and one in CET:

• week 15 (april 12-16)

EBUCORE as explicit value for MDTYPE

While adding this value is not required for it to work, it is not complicated to add it and create a new minor version of the schema. The value of having such a list instead of an unrestricted attribute is to prevent typos and also to indicate widely used standards. We don't want to continue extending the static list, but put EBUCORE on the webpage of the endorsed schemas, and also update the instructions on using OTHER/OTHERMDTYPE attributes. Future releases of METS could also use dynamic external vocabularies for this.

Future of METS

Major new version (METS 2)

• XLINK: removing it is difficult without breaking backwards-compatibility
• MDTYPE: remove hard-coded list of attribute values
• remove behaviourSec would create incompatibility, but presumably be relevant only for edge cases.

From earlier discussions/sessions, we gathered that people are not interested in breaking changes or a wholesale rethinking of METS. Problems are more on the practical level (validating/profiles, complicated), but they want to keep existing files.

METS light

• Dropping stuff (like behaviourSec as above) could open up for getting rid of
• structMap: removal or just making it optional

It seems that both perspectives overlap to a large degree on aspects of simplification/cleanup. Working on a future version of METS would focus on existing core aspects, but get rid of current technical, organizational or functional overflow.

Assumptions:

• get rid of the behaviourSec
• get rid of the structLink
• all technical metadata should be covered by respective standards rather than METS
  • MIME type, checksum/checksumtype
• get rid of the xlink schema import, have the attributes just without the "xlink:" namespace
• have MDTYPE (and others like CHECKSUMTYPE) more generic, not static.
  • MDTYPE are self-defining, i.e. the embedded metadata is already specifying its type
    • Have a value with an optional Schematron linked to it. Should this rather go into an improved METS profile area?
  • Have recommended values as documentation, but not as part of the schema/validation part.