-
Notifications
You must be signed in to change notification settings - Fork 6
2023 08 17 Board Meeting Notes
- Karin Bredenberg
- Aaron Elkiss
- Inge Hofsink
- Tobias Steinke
- Robin Wendler
- Andreas Nef
-
Next steps from the last meeting: work on tutorial, schema cleanup and documentation. XSLT will not be completed before iPres. White paper is finalized.
-
iPres METS tutorial: Karin, Tobias, Juha, Andreas, Inge, and Aaron will meet Thursdays, 9AM Eastern/ 1500 Central European summer, 1600 Finland, weekly starting August 24 until iPres. Aaron will respond to questions received about online availability (streaming and recording is OK; will need someone monitoring online questions and need to confirm that we will be able to see online questions if registered as onsite participants). Will have a room for 30 people. PC with projector; 16:9 ratio. Look at previous tutorial and case studies to determine what can be adapted for METS 2.
-
METS2 overview and tutorial: want to have English version ready prior to iPres. Action Item: Review
-
Request to retain structLink. Tobias responded to the requester. There is no plan to reinstitute structLink in METS 2. However, it may be possible to expand the semantics of mptr to support the concept per Aaron’s July 7 email, “linking between structmaps.”
-
Referring to local files in METS. Relative URIs are valid URIs. Solution: incorporate information from Aaron’s July 7 email “relative file references / SYSTEM/LOCAL”:
- …”a standard method for referring to local files via a relative path would be . The default base URI for METS should be (in accordance with RFC3986) the URL from where it was fetched, and so the implication is that 0001.pdf is a file in the same directory as the METS file.
- “If additional context is needed to interpret the reference, then it would be best to either use a full URI or an application-specific LOCTYPE. Even in this case a relative URI is still a valid URI, although it may be ambiguous and its interpretation is left up to the application (https://datatracker.ietf.org/doc/html/rfc3986#section-5.1.4)”
-
Suggested attributes: The problem and advantage of METS is flexibility. If the semantics and format of the values are not specified, that hinders interoperability. Support suggested value lists and extension mechanism for specifying other values/value lists. This will not be finalized before iPres—use the tutorial as an opportunity for feedback; show values from METS 1, note they are no longer controlled, but offer them for reference. Leave it up to profiles to define the semantics of individual values.
Next meeting: keep existing meeting on 2023-09-28.