Thanks for this update Rebecca.
> 3. To allow for terms of restrictions (e.g. for embargo periods). Currently there is just term of grant.
They way we dealt with this in our implementation, using the current
version of the standard, was to provide a controlled vocabulary for
22.214.171.124 Act, then limited the input values for 126.96.36.199 Restriction to
either "true" or "false", that way the the date range values for 188.8.131.52
can refer to either a permission or a restriction, e.g. "allow" the act
or "disallow" the act for the period of time.
An embargo period can be dealt with by creating two rights entities for
a given object, one that disallows the act for a period of time, another
that allows it for the subsequent time period.
> The PREMIS-EC is working on a major revision for version 3.0. This will include changes in the data model, where intellectual entity will become another level of object instead of a separate entity and environment will become another entity rather than tied to an object. This new version won't be available probably until at least April 2012. We have had several requests to implement these rights changes earlier so are proposing the following. We would do a version 2.2 early in 2012 to include these changes. The only change that is not compatible with the existing data dictionary is changing the name of licenseIdentifier (and its components) to licenseDocumentationIdentifier (it is currently licenseIdentifier; it was felt that the name did not convey what it actually was). Thus, to do as a minor revision 2.2, the plan is to add all the new elements to the schema and state in a comment that licenseIdentifier and its components are deprecated. Then in version 3.0 they will dis
appear and only licenseDocumentationIdentifier (and its components) will remain.
I known that everyone involved appreciates the importance of keeping a
Preservation Metadata standard backwards compatible and that these 3.0
changes are coming from pragmatic feedback from early PREMIS
implementers. I agree the data model update are theoretically sound
However, I would argue that after release 3.0 it will be more important
to work within the constraints of that version, e.g. like we've done in
our restrictions/permissions implementation, to avoid mass batch updates
of preservation metadata in archival storage. I think the standard is
flexible enough to accommodate this and I believe that long-term
stability to accommodate ongoing cross-repository interoperability
should trump making it "perfect". For one, you can change the definition
of an element to indicate a wider or narrower scope rather than changing
the element name.
In spite of backwards compatibility, interoperating PREMIS-aware
applications will still have to perform additional parsing/mapping if
they are using different versions of the standard to accommodate
application logic. Even in simple cases this can create issues or
require lots of additional resources which adds to long-term
accessibility risks. Let's not make our preservation metadata standard
yet another we have to worry about :-)
Is there a position on post 3.0 updates? e.g. a standard 5yr revision
cycle vs. (my preference) "we will only update if something is utterly
broken and puts objects in preservation at risk".
I assume that the PREMIS-EC has had its fair share of discussion on this
already so please excuse me if there is existing thread on this
elsewhere. I think PREMIS is fantastic and believe its widespread
adoption will be key to supporting a global preservation infrastructure
so I appreciate all the hard work of this committee.
Peter Van Garderen
Archivematica & ICA-AtoM Project Manager