# Presentation: 020700

## Infrastructure for preservation

- David Giaretta
- Director of CASPAR Project
- and
- Associate Director UK Digital Curation Centre

## Outline

- OAIS concepts
- Preservation Infrastructure – CASPAR and DCC
- Registry issues

## OAIS (ISO14721)

- Open Archival Information System Reference Model
**referenced in just about any serious work on digital preservation**
**Development hosted by CCSDS Panel 2**
- 5 year ISO review underway
**minor corrections and updates**
**No major changes**
- Revised version due early 2008

## Key OAIS (ISO 14721) Concepts

- Claiming “This is being preserved” is untestable
**Essentially meaningless**
- How can we make it testable?
**Claim to be able to continue to“do something” with it**
**Understand/use**
**Need Representation Information **
- Still meaningless...
**Things are too interrelated**
**Representation Information potentially unlimited**
**Designated Community**
- Plus many other concepts

**Notes:**
The Open Archival Information System (OAIS) Reference Model (ISO 14721)I’m not going through the OAIS Reference model, but I WILL say what I think are they key ideas, namely:

## OAIS Functional Entities

## Information Model & Representation Information

- The Information Model is key

- Recursion ends at KNOWLEDGEBASE of the DESIGNATED COMMUNITY
- (this knowledge will change over time and region)

**Notes:**
Just to be clear – I am focussing on the OAIS Information Model

## FITS FILE

- FITS
- STANDARD

- PDF
- STANDARD

- FITS
- JAVA s/w

- JAVA VM

- PDF
- s/w

- FITS
- DICTIONARY

- DICTIONARY
- SPECIFICATION

- UNICODE
- SPECIFICATION

- XML
- SPECIFICATION

## RepInfo Gap Management

**Notes:**
Point out the web of interrelationships

Further discussion in RESEARCH 

## Information is the important thing

- What information?
**Documents......**
**Data.......**
- Original bits?
- Look and feel?
- Behaviour?
- Performance?
- Explicit/ Implicit/ Tacit

**Information****:**** **
**Any type of knowledge that can be exchanged. In an exchange, it is represented by data. **

- Long Term is long enough to be concerned with the impacts of changing technologies, including support for new media and data formats, or with a changing user community. Long Term may extend indefinitely.

**Ensure that the information to be preserved is Independently Understandable to (and usable by) the Designated Community.**

**Notes:**
Taking the OAIS focus on INFORMATION we can ask what this really means:

## Documents vs Data

- Need to preserve information & _**knowledge**_ – not just “the bits”
**Documents, videos are *****rendered – *****simple?**
**Data – must be processed – in new ways - harder **
** ****more Representation Information**

- Publication of data as well as documents

**Notes:**
Although I risk offending people when I say this, there is an important distinction which must be made, otherwise the idea behind what we are doing will be lost and the project largely pointless!!!
SO here goes........

## Data

## Data – OAIS view

*A reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or processing*
* *
* **In 2006, the amount of digital information created, captured, and replicated worldwide was 161 exabytes(161 billion gigabytes) -roughly 3 million times the information in all the books ever written!*
* **Between 2006 and 2010, the information added annually to the digital universe will increase more than six fold from 161 exabytes to 988 exabytes*
*IDC (2007) The Expanding Digital Universe*

## Rendered Object

- Documents, articles, journals...
- Images
- Audio
- Video

**people**

**Documents **

***A reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or processing***

**Semantics tends to be ignored**

## Data

## Great Wall of China   

**Notes:**
UNESCO is providing data samples to CASPAR which will reflect this difference in periods and quality of data and obviously metadata.

## Taj Mahal   

**Notes:**
UNESCO is providing data samples to CASPAR which will reflect this difference in periods and quality of data and obviously metadata.

## UNESCO examples

**DATA**:
- Scanned documents and maps
- Aerial and close range photography (Digital photogrammetry)
- Monument measurements (Laser scanning)
- Satellite images (Remote sensing and image processing)
- Multi-scale digital cartography (Geographic information systems (GIS) and CAD)
- 3D models, virtual tours (Computer visualization)

**Mandatory Documentation:**
- Identification of property
- Description of property
- Justification of inscription
- State of conservation and factors affecting the property
- Protection and Management
- Monitoring
- Documentation
- Contact information of responsible authorities
- Signature on behalf of the State Party(ies)

- World Heritage List

**Notes:**
Note this included more “document” style objects.

## Convention for the safeguardingof intangible cultural heritage (entry into force: 2006)

**Notes:**
And in addition along with the UNESCO World Heritage Convention for the safeguarding of natural and cultural sites – UNESCO also has a new convention on the safeguarding of intangible cultural heritage that entered into force in 2006.

## Interactive Multimedia Performance (IMP):Music via Motion (MvM)

**Notes:**
Interactive Multimedia Performances are now a key section of the contemporary performing arts. 
It generally involves 3 main sections: input; mapping; output.
EX: 1) motion and colour controlled of music – dance to make music
EX: 2) augmented instrument (with sensor) – pressure to control digital audio effects
In this testbed, we use the Music via Motion system as a basis to analyse its components and preservation issues.

## Components of  an Interactive Multimedia Performance (IMP)

- People: directors, performers, technicians, programmers, etc
- Documents: e.g. performance plan and procedure, music scores, documentation about performance context, programmes
- Musical instruments: traditional (e.g. violin, cello, piano), augmented, ...
- Particular focus on 3D motion of the performer
- Mapping and content generation application (e.g. Max/MSP patches)
- Output multimedia contents (e.g. video, graphics, sound)
- Supporting applications (e.g. multimedia applications for processing and rendering)
- Operating system
- Hardware used in the performance: computer, camera, mixer, speakers, ...

**Analysis & Processing**

**Mapping**

**Multimedia Generation**

**GUI **

**Input**

- 3D motion data

- Multimedia output

- Mapping Parameters

## Data...

- Level 2 GOME Satellite instrument data

**Notes:**
This is a mosaic composed by the data retrieved over 14 orbits per day with interpolation of data values to fill the gap between two quasi-adjacent geographical areas covered by the satellite ground track. On that date the white zone over Asia indicates absence of useful data.
Format of file can be identified through a combination of file extension, physical location of file (as Indicated by Postgres database) and file name which indicates format. Textual description of the formats Is available on MST support pages 
Raw data  
IQ (In phase and quadrature) data - non standard binary format files format (textual description of format available)
Spectral - Raw data which has undergone first stage processing to spectral non standard binary file format. (textual description of format available)
Processed product
Version 2 processed data product 
Radial data: Nasa Ames format (product specific textual description available) 
Cartesian data: Nasa Ames format (product specific textual description available)
Version 1: processed data product
Radial data: Nasa Ames format (product specific textual description available)
Cartesian data: Nasa Ames format (product specific textual description available)
Version 0: processed data product
Time averaged radial data: non standard ASCII format (textual description available)
Unaveraged radial data: non standard ASCII format (textual description available)
Time averaged wind data: non standard ASCII format (textual description available)
Unaveraged wind data: non standard ASCII format (textual description available)
Time averaged power data: non standard ASCII format (textual description available)
Quick Look plots: graphic file png format generated from cartesian products using GNU plot
Under development 
With version 3 binary file of cartesian and radial product will be produced in the NetCDF format in tandem with a Nasa Ames ASCII versions.
Once Version 3 processing (Python producing NetCDF radial and Cartesian Product) is released a reprocessing of the archived Spectral file will be undertaken. In order to produce a consistent series of Cartesian and radial product.  As they will be of higher quality and more easily supported.
After a period of time the BADC would wish to dispose of the old higher level product but would like to maintain the ability to recreate it. 

## Format “vs” Representation Information

- Format
**IS Structural Representation Information**
**IS adequate for rendering a digital object**
**IS NOT adequate for understanding – especially data**

**Notes:**
I apologise if I over-emphasise the point but what one sees is that many people talk about FORMAT
PRONOM
GDFR
But.....

However there may be some argument about what a FORMAT includes

## Just Format?

- sfqsftfoubujpo jogpsnbujpo svmft

- representation information rules

**You have a file**
**JHOVE tells you it is WORD version 7**

- Format Registries – useful but not enough: formats can be used for multiple purposes e.g. audio files used to store configuration parameters

## SEAWIFS  IMAGE

**Notes:**
The true colour image of the Bering Sea is interesting, and as a GIF could be displayed for many years to come.
BUT
At every point on the image there are actually many measurements. These can be processed to show many other pieces of information in the data
SO....
We can see the concentration of chlorophyll in the sea

## XML enough?

- <family>
-    <father>John</father>
-    <mother>Mary</mother>
-    <son>Paul</son>
- </family>

- <VOTABLE version="1.1"
-  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-  xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.1 http://www.ivoa.net/xml/VOTable/v1.1"
-  xmlns="http://www.ivoa.net/xml/VOTable/v1.1">
- <RESOURCE>
- <TABLE name="6dfgs_E7_subset" nrows="875">
- <PARAM arraysize="*" datatype="char" name="Original Source" value="http://www-wfau.roe.ac.uk/6dFGS/6dfgs_E7.fld.gz">
- <DESCRIPTION>URL of data file used to create this table.</DESCRIPTION>
- </PARAM>
- <PARAM arraysize="*" datatype="char" name="Comment" value="Cut down 6dfGS dataset for TOPCAT demo usage."/>
- <FIELD arraysize="15" datatype="char" name="TARGET">
- <DESCRIPTION>Target name</DESCRIPTION>
- </FIELD>
- <FIELD arraysize="11" datatype="char" name="DEC" unit="DMS">
- <DATA>
- <FITS>
- <STREAM encoding='base64'>
- U0lNUExFICA9ICAgICAgICAgICAgICAgICAgICBUIC8gU3RhbmRhcmQgRklUUyBm
- b3JtYXQgICAgICAgICAgICAgICAgICAgICAgICAgICBCSVRQSVggID0gICAgICAg
- ICAgICAgICAgICAgIDggLyBDaGFyYWN0ZXIgZGF0YSAgICAgICAgICAgICAgICAg
- ICAgICAgICAgICAgICAgIE5BWElTICAgPSAgICAgICAgICAgICAgICAgICAgMCAv
- IE5vIGltYWdlLCBqdXN0IGV4dGVuc2lvbnMgICAgICAgICAgICAgICAgICAgICAg

**Notes:**
We can easily guess (perhaps) what the meaning of this snippet of XML is.

BUT, looking at something more realistic we have a VOTABLE.....not so easy to guess

## OAIS Representation Information

## OAIS Package Description

## Levels of applicability of OAIS

- Checklist – not just “metadata” e.g.
**Representation Information (RepInfo)**
**Preservation Description Information**
**Packaging Information**
- Exhaustive text documentation
- RepInfo supporting:
**Interoperability**
**Automation**
- Double payback
**Applicable in “GRID” context**
**usability now as well as later**

**Notes:**
Before we leave taking “about” OAIS rather than using its concepts, I can bring out another distinction which is worth making – if only to position ourselves with respect to what other do...

We get double payback because things we do for PRESERVATION will ALSO be useful for GRID interoperability

## Outline

- OAIS concepts
- Preservation Infrastructure – CASPAR and DCC
- Registry issues

## Sharing

- What can be shared?
**Care of the bits .....**
**Representation Information about....**
- How to share it?
**Need a way that is independent of domain and type**

**Notes:**
what can we share
Care of the bits – warnings about obsolescence – Technology watch is one way
BUT
Representation Information
It applies to 

## CASPAR Project

**CASPAR Project**

*http://www.casparpreserves.eu*

**EU FP6 Integrated Project**
**Total spend approx. 16MEuro (8.8 MEuro from EU)**
**Started April 2006, for 42 months**
**David Giaretta is Co-ordinator**

**Notes:**
Start with SCIENCE – and then C and A at the end – throwing new light on “preservation”

Brief introduction to the CASPAR consortium – not all of whom are represented here.

## CASPAR Aims

**Produce tools and techniques to support digital preservation and make it easier to share the cost**
- must** be relatively easy to use**
- must** have a low “buy-in” in terms of effort required for adoption**
- must** avoid requiring wholesale change of everyone else’s systems**
- must** be decentralised and reproducible so that it can live on after the formal end of the **CASPAR** project**
- must** be “**preservable**”**
- must** be open: open source, open standards**
- Cannot do everything
**Working closely with other projects**

**Notes:**
It is I think very important for us to recognise a number of very important constraints on what we do – IF we are serious about wanting a wide take-up of our tools and techniques

In particular we need to recognise the ephemeral nature of many of current systems. For example we know that the CASPAR project has a finite lifetime. We know that if we were talking about this 6 or 8 years ago then Web Services would not have been a consideration – should we rely on Web Services in a decade’s time?

Any infrastructure we build upon 

## Sharing the burden of preservation

- Must be able to pass on custody of “the bits”
**May involve transformations over time **
**Can involve many duplicate copies**
- Need to harness the “wisdom of crowds”
**Wikipedia**
**Wiki-radio – annotation**
**Google page-ranking**
**“****given enough eyeballs, all bugs are shallow”**
- BUT – if we are serious about the long term
- Need to be proactive
**To avoid death by neglect**
**Need more than a Wiki!**

**Notes:**
Clearly the bits must be passed on (but may be transformed along the way)
This can involve duplicate copies – the analogy of multiple copies of books – and in the digital world we have for example LOCKSS
But there is something more – because of the need to maintain UNDERSTANDABILITY – rather than just access
An analogy which recently occurred to me is that of the Wikipedia – many, many contributors producing/correcting/moderating content – becoming one of the most authoritative sources of information on the Internet
Similar efforts are going on e.g. the BBC is setting up a “wiki-radio” where the public can annotate recorded material
Google is another where it relies not on its own judgement on the value of a page but rather on the value other place on that page – the page ranking algorithm
Now there are books such as “The wisdom of crowds” which describe many more such examples

However we need to more than just provide a Wiki
We need to be proactive otherwise the information will be lost through neglect.

## Infrastructure

- Somewhere to collect the contributed “wisdom”
**Registry/Repositories**
- Something to remind people to take action
**Gap Manager**
**Orchestration Manager**
- More “local” tools
**Creation of Representation Information, PDI etc**
**Persistent Storage**
**...**

**Notes:**
Leaping forwards somewhat, what we will talk about is an Infrastructure which includes:
Registry/Repositories to store the additional information we need (note that this is separate from the archives which store the digital content -  although in the recursions which appear so frequently, a Registry/Repository is itself and archive
The pro-active part come from the “Orchestration manager” and the “Gap manager” – I apologise in advance for the names
We also need some what I would call “local” tools to create the information (metadata) we need.
We clearly also need to address the way in which the digital objects are stored

## Things change/disappear

- Software
- Hardware
- Environment
**E.g. Network links to related information**
- People
**What is “common knowledge” **

- How can we ensure that the information trapped in the “bits” remains understandable despite all these changes?

- How can a digital curator even be aware of these changes?

## Validation

- How can we judge any proposed solution?
- CASPAR validation metrics:
**Theoretic underpinning**
**Testbed scenarios addressing real issues**
**No “hand-waving” – use what is there now**
**Accelerated lifetime tests**
**Hardware and Software **
**Environment**
**People**
**Improved “trustability”/”certifiability”**

- Live a long time

- Evidence - not proof

**Notes:**
It is easy to propose something and wave ones hands
But how CAN we judge any proposed solution
OTHER than ....

We believe that this is an important topic which we will return to
In summary we propose:
Theory
Testbed scenarios – and here we look at actual example – no hand–waving (well... not much) – no saying that we could just do THIS [wave hands] for example just convert everything to XML and everything is OK.
The really difficult steps involve addressing REAL issues and then showing that the digitally encoded information remains UNDERSTANDABLE/USABLE

Note that we cannot provide ABSOLUTE proof – only EVIDENCE 

**CASPAR information flow architecture**

**Rep**
**Info**

- Virtualisation

**How do we capture the Representation Information?**

**Notes:**
Introducing the layered view of CASPAR which points out that we need to deal with more than RepInfo e.g. Digital Rights etc.

Follow the “life-cycle” description in the CM.

The items in the red ellipse are the RepInfo we have been talking about previously.

The virtualisation is introduced in order to help with automation i.e. we need programmes to process the bytes – how can we make this easier?

## Preservability Infrastructure

- Persistent Identifiers
- Distributed and Persistent Storage
- Identifying relevant information
- Registries of Representation Information
- Messaging infrastructure
- Workflow
- .......

**Notes:**
Elements of an infrastructure which supports PRESERVABILITY of digital information

## Registry/Repository Scenario

- User gets data from archive.
- User may be unfamiliar with the data so needs Representation Information. Some may be packaged with the data

- Archive

- User

- Digital

- Object

- CPID

- CPID

- CPID

- CPID

- CPID

- Archive

- Digital

- Object

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- The Digital Object could have some RepInfo packed with it.

**Notes:**
This gives an example of the way in which a Registry might be used in more detail.

WE CAN DEMONSTRATE VARIOUS PIECES OF THIS

Note that the RepInfo may kept WITH the data in the archive. However we should look on this as a form of “caching” of the RepInfo.

- Archive

- Digital

- Object

- CPID

- CPID

- CPID

- CPID

- CPID

- Archive

- Digital

- Object

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- May need MORE Representation Information.
- Obtain this from one or more Registry/Repository of Rep.Info.

- Do not want to guess which RepInfo is needed – use an identifier (CPID) associated with the data

**Notes:**
This gives an example of the way in which a Registry might be used.

Note that the RepInfo may kept WITH the data in the archive. However we should look on this as a form of “caching” of the RepInfo.

- Archive

- Digital

- Object

- CPID

- CPID

- CPID

- CPID

- CPID

- Archive

- Digital

- Object

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

- CPID

**Notes:**
This gives an example of the way in which a Registry might be used.

Note that the RepInfo may kept WITH the data in the archive. However we should look on this as a form of “caching” of the RepInfo.

## Use of RepInfo

**CPID**

- External

- Registry

- Each “bag of bits” has an associated pointer (**CPID**) to a Label

- copy

**Notes:**
More detail about the link between the data and the registry

## Registry

**Registry**

**Create RepInfo**

**Notes:**
The next slides are a series of related animations which show some of the processes needed, building up entities

It end up superimposed on the STRAWMAN architecture

## Registry

**Registry**

**Use Data**

## RegRep

**RegRep**

**Registry**

**Create RepInfo**

## Registry

**Registry**

## Content independent infrastructure - 2

- Important to note that:
**All the above has been rather independent of specifics of the information.**
**The domain specifics – the hard parts are hidden in e.g. the exact type of RepInfo**
- Domain independence allows wide applicability

## Content dependent components 

- Representation Information tools
**Structure**
**EAST**
**DRB**
**DFDL**
**Virtualisation assistant**
**Semantics**
**RDF editors**
**RDFSuite**
**Terminology capture**
**Software**
**UVC**
**Hardware emulators**
- Trust, Authenticity & Provenance tools
**Certification assistant**
**PREMIS**
- Packaging tools
**XFDU toolkit**

- Use existing tools where applicable
- Develop new tools as needed and resources allow

**Notes:**
The difficuties have been isolated in the various tool-kits

Here are some examples of the sorts of tools we will be using and developing
Some of the tools will need their own RepInfo.

We will use existing tools where applicable
Develop new tools as needed – as part of iterative process

## Unfamiliar information

- Preservation
**Digitally encoded information which must be usable and understandable**
**Unfamiliar because of separation in time**
- E-Science/GRID/CyberInfrastructure for data
**Digitally encoded information which must be usable and understandable**
**Unfamiliar because of separation in discipline or location – even if created yesterday**

**Notes:**
Recognising the strong links between Preservation and the GRID allow us to put preservation into its proper context

## E-Infrastructures

- Doing preservation “right” produces gains in usage
**Preservation useful for E-science/GRID**
**Enables multi-disciplinary usage**
**Virtualisation allows one to deal with unfamiliar objects more easily**
- E-Infrastructures need components to support preservation – and gain interoperability
**Additional types of Finding Aids also useful**
- Double payback
**Applicable in “GRID” context**
**usability now as well as later**

**Notes:**
Usability is the key requirement – shows that we can get a DOUBLE payback for investment in preservation infrastructures

## Alliance for Permanent Access

- Part of strategy from Task Force for Permanent Access to the Records of Science
**With Research programme outline**
**Aim to “align” digital curation activities in the members**
- Members of Alliance:
**The European Science Foundation **
**European Space Agency**
**CERN**
**Max Planck Gesellschaft**
**Centre National d'Etudes Spatiales**
**Science and Technology Facilities Council**
**The British Library**
**Koninklijke Bibliotheek**
**Deutsche Nationalbibliothek**
**Joint Information Systems Committee**
**International Association of Scientific, Technical and Medical Publishers**
**National Archives of Sweden**
**Centre Informatique National de l'Enseignement Superieur**
**Digital Preservation Coalition**
**NESTOR**
**Perennisation des Informations Numeriques**
**Netherlands National Coalition for Digital Preservation**

**http://www.alliancepermanentaccess.eu/**

**Notes:**
The Alliance for Permanent Access is being formed – it is bringing together many of the major holders of digital information.
Collectively these organisations expend of great deal of funds on creating, preserving and making digital information available

## Audit & Certification

- Need for a way to judge digital repositories has been demanded for > 10 years
- RLG/NARA produced TRAC (Trusted Repository Audit Checklist)
- Follow on work on OAIS aims to lead to ISO standard on which an accreditation and certification process can be based
- Such a certification process could shape digital “market” in future

**Notes:**
Another area of standards important as part of the preservation infrastructure is concerned with CERTIFICATION
Work is on-going on producing an ISO standard in this area, as a follow on of OAIS

## Outline

- OAIS concepts
- Preservation Infrastructure – CASPAR and DCC
- Registry issues

## Common Capabilities required

- Given an Identifier return:
**The RepInfo required (as a BLOB)**
**Identifier for the RepInfo of the RepInfo**
**plus:**
**Access to PDI **
**includes Provenance**
**Status e.g. approved/ deprecated/ draft**
- Ability to search for existing RepInfo in Registry
**Text search on description or name**
**Perhaps via one or more classifications**

## Registry properties

- Must be a trustable archive
**Certifiable**
**Care needed to define Designated Communities**
- Longevity of archive may be uncertain
**should be able to hand on its holdings**
**actionable persistent identifiers needed**
- RepInfo must be cachable
**Since archives will probably not be **_**so**_** trusting**
**They will want to keep a copy of the Relevant RepInfo they need right now**
- RepInfo Network must be extensible
**So additional RepInfo can be added, as things change**

## Registry API

- API allows applications to talk to many different implementations

**Registry API**

**Browser**

**Clone Registry**
**Implementation**

**Other **
**Registry**
**implementation**

**JAXR based **
**Registry**
**Implementation**

**Application**

**Application**

**Application**

**ebXML **
**Registry**
**Implementation**

**UDDI **
**Registry**
**Implementation**

## The Market

- Multiplicity of descriptions possible
**Even for the same digital object e.g.**
**Documentary description or**
**Formal description**
**EAST**
**DRB**
- How to choose?
**“****Page rank” equivalent i.e. which RepInfo do most others use?**
- Use may be difficult to monitor in general
**The pointer is uni-directional from the Data Object ******** RepInfo**
**Info could be collected on RepInfo ********Data Object association**
**By data collection rather than data object**
- Within Registries info is available and reference statistics could be compiled

## Management

- We cannot control everything
- Some groupings will be tightly coupled
- But
- At least some will be independent
**Registries may wish to cache or replicate RepInfo from other Registries**
**Possibly with different Identifiers!**
**Provenance should be added to make the source clear**

## Contributions

- Assume there is no single source of wisdom
- The owners of the digital objects probably know them best
**Particularly Semantics**
- Registries will have different policies
**Some may require central approval before adding**
**Others may approve or deprecate after addition**
**To avoid hackers and to maintain provenance all Registries will probably need registration of users**

## Persistent Identifiers

- No need for yet another Persistent Identifier system!
- Limit to RepInfo – not for general digital objects
- Spread the risk
- <cpid>
-     <value>xxxxxxxxxxx
-         <nameresolver type=n1>http://x.y.z</nameresolver>
-         <nameresolver type=n2>DOI:123456</nameresolver>
-         <nameresolver type=n3>urn::xx::dd</nameresolver>
-     </value>
- </cpid>

## Versioning

- Need update policy – who can change what
**Over the long term when people change**
- Keep each version available
- Allow reference to “latest version”
- Logical Identifier = Root Identifier + version
- Any version accessible via either
**Its own unique ID **
**Root identifier + version**

## Links

**CASPAR project **
**EU project on digital preservation – Science, Culture and Arts data**
**Infrastructure, tools and detailed case studies – what does one need to actually “understand” the data?**
_**[http://](http://www.casparpreserves.eu/)**__**[www.casparpreserves.eu](http://www.casparpreserves.eu/)**_*** ***
***and draft UML diagrams for OAIS based Information Model ***_**[http://wiki.casparpreserves.eu/pub/Main/CasparDevelopmentGuidelines/InformationModel-interfaces.doc](http://wiki.casparpreserves.eu/pub/Main/CasparDevelopmentGuidelines/InformationModel-interfaces.doc)**_** **
**Digital Curation Centre**
_**[http://www.dcc.ac.uk](http://www.dcc.ac.uk/)**_***  ***
**Audit and Certification group Wiki: **
_**[http://](http://wiki.digitalrepositoryauditandcertifiation.org/)**__**[wiki.digitalrepositoryauditandcertifiation.org](http://wiki.digitalrepositoryauditandcertifiation.org/)**_
**Alliance Permanent Access **
_**[http://www.alliancepermanentaccess.eu](http://www.alliancepermanentaccess.eu/)**_***  ***