|
|
Line 5: |
Line 5: |
| * [[ User:Jules/digitalarchitecturearchives | Digital architecture archives (Henk Vanstappen and Wim Lowet) ]] | | * [[ User:Jules/digitalarchitecturearchives | Digital architecture archives (Henk Vanstappen and Wim Lowet) ]] |
|
| |
|
| <u>Some resources :</u> <br>
| |
| http://www.packed.be <br>
| |
| http://www.projectcest.be (tool box, good practices guidelines) <br>
| |
| http://www.scart.be <br>
| |
| http://www.projecttracks.be <br>
| |
| http://www.scoremodel.org (preservation of digital audiovisual material) <br><br>
| |
|
| |
| Digital heritage field <br>
| |
| → solving problems in accessibility and preservation, expertise and advising <br>
| |
| Problem → once things get understood it's too late, it is important to work on preservation before it is too late, before obsolescence <br>
| |
| Art is a good way to envision problems to come up with more general digital content <br><br>
| |
|
| |
| content for the morning <br>
| |
| - preservation<br>
| |
| - threats<br>
| |
| - strategies<br><br>
| |
|
| |
| <b>ANALOGUE PRESERVATION?</b> <br>
| |
| → analogue material can subsist for several decades, time doesn't flow the same way with digital content <br>
| |
| With digital content you don't have time. <br>
| |
| For instance with software... problem of and text editors evolution and text document formats.<br>
| |
| Problem of digital repositories? How to physically store but not sustain readability<br><br>
| |
|
| |
| OAIS MAGENTA BOOK<br>
| |
| → repository shall identify the Content Information<br><br>
| |
|
| |
| BUT In practice :<br>
| |
| - normalisation > only for specific formats (digital black hole)<br>
| |
| Also, sometimes institution cannot do the research, don't really understand how to deal with it<br><br>
| |
|
| |
| ALTERNATIVE APPROACH – MATURITY MODEL (C'h. Dollar)<br>
| |
| 7 aspects:<br>
| |
| - policy<br>
| |
| -strategy<br>
| |
| - expertise and organisation<br>
| |
| - storage<br>
| |
| - planning and control<br>
| |
| - ingest<br>
| |
| - access<br>
| |
| → at the end you get some score.<br><br>
| |
|
| |
| Preservation :<br>
| |
| Intervene in the environment where you create and store documents to reduce the risk of damage to the minimum<br><br>
| |
|
| |
| Identify threats and apply strategy to counter it<br>
| |
| technical solutions + proper arrangements, clever tool and getting stuff organised<br><br>
| |
|
| |
| THREATS<br>
| |
| - obsolete technology<br>
| |
| - unreliable carriers<br>
| |
| - rights infringement<br>
| |
| - managing extent<br>
| |
| → what applies to your content<br><br>
| |
|
| |
| Digital life cycle <br>
| |
| Encoding can be a problem too<br><br>
| |
| 1# Access depends on the availability of the corresponding technology<br>
| |
| 2# unreliable carriers (cd rooms, floppy disks) – physical deterioration, damages, errors decoding/encoding<br>
| |
| 3# rights infringement – for the technologies you use (proprietary software) – patents, intellectual property etc<br>
| |
| Different levels : Format (wrapper), codec (essence), software (implementation), hardware (carrier, hardware codec)<br>
| |
| Jpeg2000 – patent issue (legality of using the format)<br>
| |
| Mini disk was completely patented :-)<br>
| |
| Open source is good :-)<br><br>
| |
|
| |
| 4# Managing extent<br>
| |
| Meta data appear outside the object with older carriers<br>
| |
| - lacking metadata, endless copying, ignorance, project-based work.<br><br>
| |
|
| |
| Good to store copies over network
| |
| Hashtags, checksums, comparing file versions, check if something changed throughout transfering the file.
| |
| Also hardware like hard drive and third location.
| |
| https://en.wikipedia.org/wiki/DNA_digital_data_storage > not applicable on large scale
| |
|
| |
|
| |
| CONSERVATION
| |
| → store hardware, software etc in safe, climatised environment
| |
| pro : relevant when the essence is in both the digital and physical manifestation of the project
| |
| con : maintenance and obsolescence
| |
|
| |
| DOCUMENTATION
| |
| → manuals of hardware and software, technical specs of hardware, software and file formats, also the OS, library, languages, environment
| |
| pro: helpful for reverse engineering/emulation
| |
| con: passive, depends on future expertise
| |
|
| |
| COPY AND DISTRIBUTE
| |
| → copying and distributing is essential
| |
| different types of copies (archive vs reproduction vs access)
| |
| backup strategies : full/incremental – frequency – locations
| |
| pro: risk distribution
| |
| con: risk of losing track of copies
| |
| what shape for sharing? How do you copy files and why?
| |
|
| |
| REGULAR CHECKS
| |
| checksum
| |
| completeness of archive, integrity, virus control
| |
| pro: identify preservation issues at early stage, can be automated
| |
| con: allocate responsabilities, discipline, IT expertise
| |
|
| |
| MIGRATION and TRANSCODING<br>
| |
| Format policies.<br>
| |
| Transcode to open and sustainable archive formats<br>
| |
| pro: by far the most efficient way of extending life cycle of a file<br>
| |
| con : risk information loss, risk functionality loss, expertise<br><br>
| |
|
| |
| Archivists have expertise in what to through away rather than what to keep <br><br>
| |
|
| |
| EMULATION<br>
| |
| mimic original environment in which the file was used<br>
| |
| pro: last resort for obsolete content<br>
| |
| con: specialist work, available for specific platforms, requires reverse engineering<br><br>
| |
|
| |
| There is no single strategy applicable to all. Long-term preservation = chain of short term solutions based on a long term vision
| |
| technology evolves, update your strategies.
| |
| </div> | | </div> |