Unlike descriptive metadata, we feel that documenting provenance in a mailbag to be very important. Since PREMIS is the most popular metadata standard for documenting provenance, we considered including PREMIS events in a mailbag, but we felt that including a full representation of PREMIS would add additional complexity with little benefit.
From the knowledge of the Mailbag Advisory Board, we concluded that archivists commonly create complex PREMIS XML as part of their workflows, but rarely use that data for anything useful. We wish to prioritize interoperability over strict PREMIS compliance, and we are concerned that the complexity introduced with a full PREMIS implementation may actually make it more difficult for downstream applications to use, as there are few tools available that actually parse and use PREMIS. Frankly, we feel that it’s just more useful to document the tool, the version, and the date of packaging in a few simple fields, rather than a huge XML file.
Still, we do want to be compatible with existing standards, so we plan to make the fields containing this provenance information in a mailbag’s bag-info.txt file easily map-able to PREMIS elements. We would be very interested in any use cases for PREMIS events, as we would want to include enough information to meet these needs.
If you disagree, you can still include a full PREMIS XML file in a mailbag, it just won’t be defined in the specification. Just like any bag, you’re welcome to include any additional tag files to meet local needs.
The text was updated successfully, but these errors were encountered:
I think there is a significant misunderstanding here of what PREMIS is and how it can be implemented. In general, PREMIS is a data model with a data dictionary - it is implementation agnostic. So an xml - much less a "complex PREMIS XML" is not needed to implement PREMIS. Furthermore, not the full data dictionary has to be implemented. If you look at the PREMIS data dictionary, there are clear indicators of what semantic units are mandatory and which are optional. Also - semantic units, when being implemented, don't have to be called the same as in the Data Dictionary for PREMIS conformance. To give an example - the objectIdentifier from the object entity doesn't have to be called that - it can just as well be called MessageIdentifier. The only limitation is that you should not implement semantic units of the same name as PREMIS semantic units but store different semantic information in them (e.g., including a file format PUID in an objectIdentifier).
As a community, we are not doing ourselves a favor by saying that PREMIS is complex and no one uses it ... all values described in PREMIS as key preservation metadata - things like file preservationLevel, significantProperties, size, format, creatingSoftwareApplication ARE crucial information in EVERY preservation process. You stress that interoperability is what you wish to prioritize - and PREMIS achieves exactly that.
I would therefore strongly recommend that you map the metadata you describe in the spec, such as messageID, against the PREMIS dictionary as the most important lingua franca of preservation metadata. And via completing this mapping you actually ARE using PREMIS. In a conformant way :-)
Also, you can implement PREMIS using just the object entity without having to implement the events entity, if you feel it does not serve your purpose. Your answer seems to suggest that events would have to be implemented for full PREMIS conformance (see PREMIS conformance document, Level 1 A - conformance through mapping, object entity only).
You don't have to implement the whole of the PREMIS data dictionary to be compliant and you can have your own names but don't have the same name as in PREMIS and give it another definition. (All already written)
I also came to the conclusion that what you are talking about in the final end of implementing is the object which in its turn can be connected to events but its totally up to you in the creation of the implementation to decide how much of PREMIS that are being implemented.