# |
Term |
Core Event? |
Definition/description |
Link |
Comment |
1 |
accession |
|
The process of adding an object to the inventory of a repository. This provides a clear delineation point for the assumption of responsibility for the digital content’s preservation. |
|
Peter McKinney [Institution]: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. |
2 |
adding emulation information |
|
Adding to an object's metadata, information necessary in order to emulate that object (such as the application used to create the object). This is a special case of "Information package modification". |
|
Libor Coufal [National Library of Australia]: The definition needs clarification as it is not the object which is emulated but rather the object is rendered in an emulated environment. Also, I am not sure that the emulation information would be added to the object's metadata, e.g. if you wanted to use emulation to render objects in the MS Works format, would you be adding (the same) emulation information to each object in the format? Probably not... I am also not sure what the use case for this event metadata is, possibly other than knowing how old/up-to-date the information is...?
|
3 |
appraisal |
|
The process of assessing whether a package of digital material should be included in the repository. It is recorded when an organisation accepts or rejects curatorial responsibility for a package, usually due to verification failure or a failure to meet expected standards. [eventOutcome being accepted or rejected] |
|
Bertram Lyons [AVPreserve]: Should event outcome include more than two options here? Some appraisals result in partial accessions - e.g., "We'll take some but not all."
Evelyn McLellan [Artefactual]: Agree. Maybe add partially accepted as a possible eventOutcome?
Libor Coufal [National Library of Australia]: Sometimes appraisals may happen after ingest (for practical reasons or because of an archive or institution's retention policy which may stipulate that records need to be retained for certain time, e.g. 30 years, after which they may (but may not) be disposed of. Could the definition be updated to reflect this? E.g. "should be included or retained in the repository"...?
|
4 |
capture |
core |
The process whereby a repository actively obtains an object. Includes the notion of "receipt" |
http://id.loc.gov/vocabulary/preservation/eventType/cap |
Libor Coufal [National Library of Australia]: I am confused by the second sentence - what does it mean in this context? Isn't the notion of "receipt" passive, i.e. the opposite of active capture?
|
5 |
compression |
|
The process of coding data to save storage space or transmission time. |
http://id.loc.gov/vocabulary/preservation/eventType/com |
Bertram Lyons [AVPreserve]: I know this is an old vocab item, but should compression and decompression distinguish clearly in the definition that this is about lossless approaches (e.g., zip, tar, etc.)? One could imagine an organization applying compression or decompression in a lossy way as well (even if one would not want that -- e.g., WAV -> MP3). |
6 |
creation |
|
The act of creating a new object. |
http://id.loc.gov/vocabulary/preservation/eventType/cre |
|
7 |
data carrier migration |
|
A transformation of an object resulting from the creation of a copy on a more contemporary data carrier. |
|
|
8 |
deaccession |
|
The formal process of removing an object from the inventory of a repository. This may be by transfer to another repository, return to the depositor or by permanent deletion. |
http://id.loc.gov/vocabulary/preservation/eventType/dea |
|
9 |
decompression |
|
The process of reversing the effects of compression. |
http://id.loc.gov/vocabulary/preservation/eventType/dec |
|
10 |
decryption |
core |
The process of converting encrypted data to plain text. |
http://id.loc.gov/vocabulary/preservation/eventType/der |
Evelyn McLellan [Artefactual]: Can we also add encryption as an Event? It may be desirable to describe this as a pre-ingest Event performed outside the repository, or some institutions may want to encrypt AIPs for storage or transfer to another repository.
Libor Coufal [National Library of Australia]: I second Evelyn in that encryption should also be added.
|
11 |
deletion |
core |
The process of permanently destroying an object in a repository. |
http://id.loc.gov/vocabulary/preservation/eventType/del |
Libor Coufal [National Library of Australia]: Could "destroying" be replaced, e.g. with "removing" (which btw seems to be commonly used in this sense in other parts of this document and elsewhere, such as the referenced LOC definition). Also, does "soft" and "hard" deletion need to be distinguished?
|
12 |
deselection |
|
A file or representation which is described and defined in the packaging information but is NOT ingested on purpose. This might happened if e.g. a file is migrated prior to ingest and only the migrated copy is kept. To provide a complete audit trail the original file has to be defined and has its own PREMIS record. |
|
|
13 |
digital signature validation |
|
The process of determining that a decrypted digital signature matches an expected value. |
http://id.loc.gov/vocabulary/preservation/eventType/dig |
|
14 |
dissemination |
|
The process of transforming one or more archival information packages (AIP) into a dissemination information package (DIP) for use outside of the preservation repository |
|
|
15 |
file extension change |
|
Assignment of a new filetype extension to a file object; typically done only if the existing extension was found to be incorrect. |
|
|
16 |
file system analysis |
|
The process of analysing one or more filesystems from raw or forensically packaged images |
|
|
17 |
file system extraction |
|
The process of extracting one or more filesystems from raw or forensically packaged images |
|
|
18 |
filename change |
|
Removal of prohibited characters from file and directory names |
|
|
19 |
fixity check |
core |
The process of verifying that an object has not been changed in a given period. |
http://id.loc.gov/vocabulary/preservation/eventType/fix |
|
20 |
forensic feature analysis |
|
The process of forensically analysing raw bitstreams |
|
|
21 |
format identification |
core |
Identification of the object's file format and version (note: this event is different from 'validation' which compares the object to known format specifications) |
|
|
22 |
format validation |
|
The process of comparing an object with a standard and noting compliance or exceptions. |
http://id.loc.gov/vocabulary/preservation/eventType/val |
|
23 |
identifier assignment |
core |
Assignment of an identifier – a special case of information package modification |
|
|
24 |
imaging |
|
The process of extracting a disk image from physical media |
|
|
25 |
Information Package merging |
|
Recorded when Information Packages (SIP, AIP, DIP) are merged together. |
|
|
26 |
Information Package splitting |
|
Recorded when Information Packages (SIP, AIP, DIP) are split apart. |
|
|
27 |
ingest end |
core |
Completion of the total ingest process. |
|
|
28 |
ingest start |
core |
An event will be generated when the ingest process is started and the ingest process will be completed when an approval/acceptance event is recorded.) |
|
|
29 |
ingestion |
core |
The process of adding objects to a preservation repository. More detail can be gained by utilising "Ingest Start" and "Ingest End" rather than this one event. |
|
|
30 |
message digest calculation |
core |
The process by which a message digest ("hash") is created. |
http://id.loc.gov/vocabulary/preservation/eventType/mes |
|
31 |
metadata extraction (propertyExtraction) |
core |
Extraction of technical (or non-technical) metadata like the resolution, colordepth etc. from a file using tools such as JHOVE. |
|
|
32 |
metadata modification |
|
Changes to the metadata about an object. Recorded when a package or file has been modified, added or deleted |
|
|
33 |
migration |
core |
A transformation of an object creating a representation in a more contemporary format. |
http://id.loc.gov/vocabulary/preservation/eventType/mig |
|
34 |
normalization |
core |
A transformation of an object creating a representation in a supported preservation format. |
http://id.loc.gov/vocabulary/preservation/eventType/nor |
|
35 |
object modification |
|
The act of changing a file or bitstream after receipt of the object, but before the object is ingested into the repository. |
|
Bertram Lyons [AVPreserve]: What terms are used if a repository "changes a file or bitstream" after the object is ingested into the repository? I am unclear of the intention of setting the "before the object is ingested" qualifier in this definition.
Evelyn McLellan [Artefactual systems]: Agree. Maybe just limit the definition to "The act of changing a file or bitstream".
|
36 |
object validation |
core |
Structure and compliance validation of the Object (e.g. an AIP) |
|
Evelyn McLellan [Artefactual systems]: This is a little confusing. Maybe the definition should be "Information Package validation"? |
37 |
quality review |
|
recorded when quality review is performed and noted as passed or failed |
|
|
38 |
quarantine |
|
Segregate objects for designated period of time (e.g. before running a virus check) |
|
|
39 |
recovery |
|
The act of regaining one or more files after a disaster. Usually occurs as part of a disaster recovery process. |
|
|
40 |
redaction |
|
The process of modifying the content of a digital object to remove or mask information considered to be sensitive in nature (that is, the information cannot be viewed by non-authorized users of the repository).
The process of eliminating potentially private and sensitive data from a disk image or copy thereof. |
|
|
41 |
replication |
|
The process of creating a copy of an object that is, bit-wise, identical to the original. |
http://id.loc.gov/vocabulary/preservation/eventType/rep |
|
42 |
SIP creation |
core |
Creation of the SIP |
|
|
43 |
storage migration |
|
A change to an object’s storage location |
|
|
44 |
unpacking |
|
Extracting objects from packages (e.g. .zip, .tar) |
|
Bertram Lyons [AVPreserve]: How is this semantically different from the current "decompression" term - which seems to assume the same action as this "unpacking" term?
Evelyn McLellan [Artefactual systems]: Unpacking does not necessarily involve decompression. Some types of packages are not compressed, so the action is simply to extract the contents from the package. Bertram Lyons [AVPreserve]: Right, but in some cases .zip and .tar are actually compressing and decompressing (not just unpacking). I'm wondering if we need clearer events in general, such as lossless compression/decompression; lossy compression/decompression; packaging/unpackaging (no compression is assumed here).
Evelyn McLellan [Artefactual systems]: Whether compression is lossy or lossless could go into eventDetail or eventOutcomeDetailNote or similar.
Evelyn McLellan [Artefactual systems]: If we add unpacking as an Event, can we also add packing (or unpackaging and packaging)? I can see a packing/packaging Event being used when an AIP is packaged into a bag, for example.
|
45 |
unquarantine |
|
Release of a file from quarantine |
|
|
46 |
virus check |
core |
The process of scanning a file for malicious programs. |
http://id.loc.gov/vocabulary/preservation/eventType/vir |
|
47 |
wellformedness check |
|
Checking if a file is wellformed. Often validation checks already include wellformedness checks. In any case the result of those combined checks is recorded in two separate events. |
|
|
Comments (0)
You don't have permission to comment on this page.