-
Notifications
You must be signed in to change notification settings - Fork 6
2021 06 03 Board Meeting Notes
These are attributes in use for Finnish national METS standard via local extension. CONTRACTID is used for identifying the contract/submission agreement to an which object belongs; CONTENTID for breaking up large content in multiple packages or if the content is produced periodically and then updated - so the dataset belongs together. It may not be known ahead of time how many packages will have a a particular CONTENTID.
There is already an attribute called CONTENTIDS used elsewhere. Others are using the altRecordId attribute to document the submission agreement.
CONTRACTID also has something to do with rights governing the package, so that's perhaps a better location for it. Many of these kinds of metadata have other metadata schemas that could express things more precisely.
There is an open question for best practices for splitting up large objects and for representing objects that are part of larger collections. There are several ways to express these things - PREMIS, local metadata schemas, etc.
-
xsd:anyAttr for adding additional local attributes on the root namespace (as with this option)
-
PREMIS events (BNF is using this)
-
mptr option for linking multiple packages. For many kinds of collections the members may not be known ahead of time, so it makes sense to link from the object to the collection it's in rather than updating a METS document for the collection. Some may be using this to express the relationship of an object to its parent collection.
Do we want to change anything in METS2 regarding this? It would be worthwhile to think about best practices regarding collections of objects and to collect examples of how people are doing this, but preferable to avoid adding something to METS2 for this if possible. Adding extra attributes in the schemas seems counter to the idea of simplification for METS2.
Consensus is for METS2 that we will not add anything for now. We will collect some examples and decide on best practices.
Question of whether it is possible to have md directly under mdSec / file optionally directly under fileSec? We don't want to remove grouping entirely, and anything for mdSec should be parallel with fileSec. If possible, we should avoid mixing md/mdGrp under mdSec and likewise for file/fileGrp/fileSec.
There are certainly cases where it might be unnecessary to have fileGrp and mdGrp. Processing software might be more complicated if the group structure is optional, and especially if mixing is allowed.
Making mdGrp optional could be useful if it helps avoid multiple IDREFs and the need to tokenize IDREFs.
We will draft something for making the nesting optional, and make sure it is possible to prohibit mixing mdGrp and md at the same level, and fileGrp / file at the same level.
Question of whether we should collapse a layer of hierarchy and have e.g. mdBinWrap / mdBinData rather than mdWrap + xmlData or mdWrap + binData, and question of whether the binData is useful at all.
There are some examples and use cases of embedding binData (thumbnails, cryptographic signatures, etc), but concern that binData is potentially difficult to decode and use appropriately.
Question of whether this simplifies things, or does it make things more complicated by having to look things in a different place? What do we gain?
Given that binData/xmlData is in use for the same reasons in multiple places, and collapsing these elements would require multiple new elements, we will leave as-is for now.
The CREATED attribute is allowed on files, mdWrap, etc. Should we allow imprecise dates via EDTF? PREMIS3 decided to go to xsd:string for date time for handling imprecise dates. It is hard to define validation for EDTF. There was a regex implementation for this in PREMIS2, but it was removed in PREMIS3.
Curious in practice if this attribute is more likely used for last modified date? Could add MODIFIED attribute in addition (for parity with filesystem dates). Perhaps worth considering further.
Karin has updated the tutorial proposal.
Likely to be a virtual conference for those outside China. No-one on the board is likely to be able to attend in person. There is likely to be a significant registration fee even for virtual participation.
Timing will likely also be difficult for US & Europe participants.
- All to gather examples of OTHERLOCTYPE
- All to gather examples of how to represent things that are part of collections
- Aaron to draft update to allow md directly under mdSec and likewise for file/fileSec