 |
 |
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 4.1.7.1 Act, then limited the input values for 4.1.7.2 Restriction to either "true" or "false", that way the the date range values for 4.1.7.3 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 improvements. 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. Cheers, Peter Van Garderen Archivematica & ICA-AtoM Project Manager