Difference between revisions of "ESciDoc Version History Event Type"

From MPDLMediaWiki
Jump to navigation Jump to search
(New page: == Premis Event Type in eSciDoc Version History == The eSciDoc infrastructure maintains a version history for every versioned resource. The version history consists of version elements con...)
 
Line 1: Line 1:
== Premis Event Type in eSciDoc Version History ==
== Premis Event Type in eSciDoc Version History ==
The eSciDoc infrastructure maintains a version history for every versioned resource.
The eSciDoc infrastructure maintains a version history for every versioned resource.
The version history consists of version elements containing premis:event elements for every operation pertaining the respective version.
The version history consists of version elements containing premis:event elements for every operation pertaining to the respective version.


premis:eventType is a mandatory element inside a premis:event. The value of premis:eventType should follow a controlled vocabular.
premis:eventType is a mandatory element inside a premis:event. The value of premis:eventType should follow a controlled vocabular.

Revision as of 14:12, 14 January 2010

Premis Event Type in eSciDoc Version History[edit]

The eSciDoc infrastructure maintains a version history for every versioned resource. The version history consists of version elements containing premis:event elements for every operation pertaining to the respective version.

premis:eventType is a mandatory element inside a premis:event. The value of premis:eventType should follow a controlled vocabular. For now, the following event type values are used in eSciDoc infrastructure.

create
update
submitted
released

Please use the Talk:ESciDoc_Version_History_Event_Type page to discuss the eSciDoc event type vocabulary.

Premis Specification of premis:eventType[edit]

The Premis Data Dictionary (in http://www.loc.gov/standards/premis/v2/premis-2-0.pdf) says about the eventType element:

Definition[edit]

A categorization of the nature of the event.

Rationale[edit]

Categorizing events will aid the preservation repository in machine processing of event information, particularly in reporting.

Data constraint[edit]

Value should be taken from a controlled vocabulary.

Examples[edit]

E77 [a code used within a repository for a particular event type] Ingest

Repeatability[edit]

Not repeatable

Obligation[edit]

Mandatory

Usage notes[edit]

Each repository should define its own controlled vocabulary of eventType values. A suggested starter list for consideration (see also the Glossary for more detailed definitions):

capture = the process whereby a repository actively obtains an object

compression = the process of coding data to save storage space or transmission time

creation = the act of creating a new object

deaccession = the process of removing an object from the inventory of a repository

decompression = the process of reversing the effects of compression

decryption = the process of converting encrypted data to plaintext

deletion = the process of removing an object from repository storage

digital signature validation = the process of determining that a decrypted digital signature matches an expected value

dissemination = the process of retrieving an object from repository storage and making it available to users

fixity check = the process of verifying that an object has not been changed in a given period

ingestion = the process of adding objects to a preservation repository message digest calculation = the process by which a message digest (“hash”) is created

migration = a transformation of an object creating a version in a more contemporary format