-
Notifications
You must be signed in to change notification settings - Fork 6
2020 11 12 Board Meeting Notes
Aaron Elkiss edited this page Mar 11, 2021
·
2 revisions
Attendees:
- Tobias Steinke (host)
- Karin Bredenberg
- Brian Tingle
- Aaron Elkiss
- Andreas Nef
- Inge Hofsink (minutes)
Because we will discuss further the future of METS, we start with a recap from last week’s meeting, see https://github.com/mets/METS-board/wiki/2020-11-05-Board-Meeting-Notes
- Tutorial: Nestor network is also interested in co-hosting. TBD how we want to do it precisely
- MDTYPE EBUCORE: relates to METS2 ; no longer want to maintain enumerations for MDTYPE (and other attributes), but only recommended standards/values in documentation
- Future of METS: both METS light and METS 2 overlap to a large degree on aspects of simplification/cleanup:
-
- Make structMap optional
-
- Drop structLink and behaviorSec
-
- All technical metadata should be covered by respective standards rather than METS - to discuss further today
-
- Get rid of the xlink schema import, have the attributes just without the "xlink:" namespace
-
- Drop static lists and make more general (MDTYPE etc)
We should make version mandatory in METS profile.
No changes, apart from enumerations for attributes agent/@ROLE and agent/@TYPE -> drop static lists and make more general
Proposed / discussed simplifications:
- To use only general mdSecs with attributes of type instead of existing dmdSec etc
- Introduce mdGroup (parallel to fileGrp) ; hierarchy of mdSec / mdGrp / MD to make fileSec and mdSec more equal
- Attribute mdRef/@XPTR ; according to EXCEL “Evaluate dmdSec Usage in METS” this attribute is not used in any of the registered profiles; mdRef/@href will be sufficient to link to metadata files. Example from HathiTrust METS (apparently based on somebody's misunderstanding 15 years ago):
<METS:mdRef MDTYPE="MARC" LOCTYPE="OTHER" OTHERLOCTYPE="Item ID stored as second call number in item record" XPTR="uc1.b3387194"/>; further no live examples of XPTR usage in METS in a quick google search (just documentation or libraries that try to completely cover the METS standard) - If we make metadata sections more general, IDREFS attributes @DMDID and @ADMID can both become @MDID
- No nested fileGrps is a suggestion to make it more simple. Are institutions using nested filegGrps? Maybe 1 or 2 profiles ; we wouldn’t recommend it anyway
- We discuss no nested files, but decide to keep them for tar, gz, etc
- Element transformFile can be kept, even without link to dropped behaviorSec ; typical information in behaviorSec can be moved to amdSec with PREMIS or so. Shared example:
<mets:file ID="file-BagTransfer_1563459917-a12eaa60-abd4-4aae-bb35-3acb065311ef" GROUPID="Group-a12eaa60-abd4-4aae-bb35-3acb065311ef" ADMID="amdSec_5">
<mets:FLocat xlink:href="/var/archivematica/sharedDirectory/www/AIPsStoreEncrypted/a12e/aa60/abd4/4aae/bb35/3acb/0653/11ef/BagTransfer_1563459917-a12eaa60-abd4-4aae-bb35-3acb065311ef.7z" LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM"/>
<mets:transformFile TRANSFORMKEY="BFB2DB6A93C985224F0729B3ACE9200CE0D11C3B" TRANSFORMTYPE="decryption" TRANSFORMORDER="1" TRANSFORMALGORITHM="GPG"/>
<mets:transformFile TRANSFORMTYPE="decompression" TRANSFORMORDER="2" TRANSFORMALGORITHM="bzip2"/>
</mets:file> - Elements stream, FContent: we discuss inline files in METS; other example from Aaron https://met.refeds.org/met/entity/http%3A//www.hathitrust.org/shibboleth-sp/?viewxml=true&federation=openathens-federation. We leave stream and FContent as it is
- Attribute FLocat/@LOCTYPE can be dropped, because all location types are URL; also @OTHERLOCTYPE can be dropped. To distinguish between different location types, attribute @USE can be used. We all recognize discussions about the number of slashes in FLocat ; see also https://tools.ietf.org/html/rfc8089
- No changes, because use of structMap is very specific for different users with specific use cases
- Probably introduce structural Map Section / structSec for multiple structMaps, parallel to fileSec
- Because we drop static lists and make more general, all attributes starting with @OTHER can be dropped also (@OTHERROLE, @OTHERTYPE, @OTHERMDTYPE, @OTHERLOCTYPE)
mets
/ metsHdr (optional, non repeatable)
/ / mdSec (optional, non repeatable)
/ / / mdGrp (mandatory within mdSec, repeatable, no nested mdGrps)
/ / / / MD (mandatory within mdGrp, repeatable)
/ / fileSec (optional, non repeatable)
/ / / fileGrp (mandatory within fileSec, repeatable, no nested fileGrps)
/ / / / file (mandatory within fileGrp, repeatable)
/ / structSec (optional, non repeatable)
/ / / structMap (mandatory within structSec, repeatable, no nested structMaps)
/ / / / div (mandatory within structMap, repeatable)
/ / / / / div/fptr/mptr (etc)
- Drop attribute mdRef/@XPTR ; attribute mdRef/@href will be sufficient
- If we make metadata sections more general, IDREFS attributes @DMDID and @ADMID can both become @MDID
- Nested fileGrps will be dropped
- Nested files are maintained for tar, gz, etc
- Element transformFile is maintained, even without link to dropped behaviorSec
- Element stream is maintained
- Element FContent is maintained (use cases thumbnails, cryptographic signatures, etc)
- Attributes FLocat/@LOCTYPE can be dropped, because all location types are URL; also @OTHERLOCTYPE can be dropped. To distinguish between different location types, attribute @USE can be used
- Because we drop static lists and make more general, all attributes starting with @OTHER can be dropped also (@OTHERROLE, @OTHERTYPE, @OTHERMDTYPE, @OTHERLOCTYPE)
We’ll make a page in GitHub with all discussed changes for METS 2. This page will be the base for a whitepaper on METS 2 that will be published to discus with community / users.