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 Act, then limited the input values for Restriction to 
either "true" or "false", that way the the date range values for 
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