Hi Eld et al,

Thanks for this email. I think you're right, the extra level does not introduce any restrictions, and I support it. 

As I said in my previous email, we don't actually use these fields yet, but are approaching a phase where we may use them. With that in mind, I'd be really interested to know how other people use these fields. Is there a clarity of understanding across implementations? Are people using approximately the same values? 

Best from Wellington,


-----Original Message-----
From: Eld Zierau [mailto:[log in to unmask]] 
Sent: Saturday, 13 October 2012 2:54 a.m.
To: [log in to unmask]; Peter McKinney
Cc: Eld Zierau
Subject: Re: preservationLevelType -- request to PREMIS EC

Hi Pete, Angela and others

Firstly, I am very sorry for my late answer, I will be quicker next time!
As discussed in Toronto last week, the preservation level type is only
proposed as an extra field in order to be able to qualify the aspect of a
preservation level that the value is for. At the Royal Library of Denmark
the preservation level type will relate to the strategy of preservation we
use to achieve a specific preservation level. I have tried to give a more
thorough description below.

It was never the intention to suggest specific values for neither
preservation level nor the preservation level types. I think there is still
no common understanding of what preservation level means in practice. And I
think that your example Pete (together with mine) clearly shows that it
would be very useful for both of our interpretations of preservation levels,
- but also that the values we would use are very different.

And as a follow up to Toronto, I also think that this shows that this
introduces no restrictions to anyone - an optional PreservationLevelType
field is only meant as a help to express the complex concept of preservation
levels in a simple way.

Best Regards, Eld


Explanation of what we do at the Royal Library of Denmark

There are preservation levels for both bit preservation and functional
preservation as explained below:

On the Functional Preservation Level (i.e. preservation that ensures that
the bits remain understandable and usable according to preservation purpose)
there are one type:
- PreservationLevelType= FunctionalPreservationStrategy: covering strategies
like emulation or migration (at this stage we have 4 possible strategies)

On the bit preservation level (i.e. preservation that ensures that the
bit-streams remain intact and readable) there are several types to cover
different dimensions of bit preservation like integrity, confidentiality and
accessibility (in accordance to the paper "Evaluation of Bit Preservation
Strategies" from iPres 2010 and inspired by the ISO 27000 series):
- PreservationLevelType=BitSafety for bit integrity
- PreservationLevelType=Confidentiality for confidentiality
- PreservationLevelType= Accessibility for accessibility (Not implemented yet)
Along with these types we will use different values indicating the level for
each of the types - in my first mail I indicated 3 levels, but we actually
end up with seven levels.

As example of how the complexity is expressed in a simpler way is that the
above levels in combination covers 4*7*7*7=1372 possible preservation
levels. As a start we have identified  8 of these in practical use, but
where the number is very likely to be expanded and is far more readable by
level types than by a list that suits the requirement at a certain point in

CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.