Difference between revisions of "ESciDoc Item Container Version History"

From MPDLMediaWiki
Jump to navigation Jump to search
Line 168: Line 168:
!style="background:#87CEEB; width:150px;"| Semantic unit  
!style="background:#87CEEB; width:150px;"| Semantic unit  
!style="background:#87CEEB; width:600px;" id="eventType"| 2.2 eventType
!style="background:#87CEEB; width:600px;" id="eventType"| 2.2 eventType
|-
!style="background:#87CEEB"| Semantic<br/>components
|style="background:#87CEEB"| None
|-
! Definition
| A categorization of the nature of the event.
|-
! Rational
| Categorizing events will aid the preservation repository in machine processing of event information, particularly in reporting.
|-
! Data constraint
| Value should be taken from a controlled vocabulary.
|-
! Examples
| E77 [a code used within a repository for a particular event type] <br/> Ingest
|-
! Repeatability
| Not repeatable
|-
! Obligation
| Mandatory
|-
! Usage Notes
| 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): <br/> capture = the process whereby a repository actively obtains an object <br/> compression = the process of coding data to save storage space or transmission time <br/> creation = the act of creating a new object <br/> deaccession = the process of removing an object from the inventory of a repository <br/> decompression = the process of reversing the effects of compression <br/> decryption = the process of converting encrypted data to plaintext <br/>  deletion = the process of removing an object from repository storage <br/> digital signature validation = the process of determining that a decrypted digital signature matches an expected value <br/> dissemination = the process of retrieving an object from repository storage and making it available to users <br/> fixity check = the process of verifying that an object has not been changed in a given period <br/> ingestion = the process of adding objects to a preservation repository <br/> message digest calculation = the process by which a message digest (“hash”) is created <br/> migration = a transformation of an object creating a version in a more
contemporary format. <br/>normalization = a transformation of an object creating a version more conducive to preservation<br/>replication = the process of creating a copy of an object that is, bitwise, identical to the original<br/>validation = the process of comparing an object with a standard and noting compliance or exceptions<br/>virus check = the process of scanning a file for malicious programs. Note that migration, normalization, and replication are more precise subtypes of the creation event. “Creation” can be used when more precise terms do not apply, for example, when a digital object was first created by scanning from paper. In general, the level of specificity in recording the type of event (e.g., whether the eventType indicates a transformation, a migration or a particular method of migration) is implementation specific and will depend upon how reporting and processing is done. Recommended practice is to record detailed information about the event itself in eventDetail rather than using a very granular value for eventType.
|-
!style="background:#98FB98"| eSciDoc
|style="background:#98FB98"| --[[User:Makarenko|Makarenko]] 14:43, 5 January 2010 (UTC) For the moment the following values are presented: <br/> create <br/> update <br/> submitted <br/>  assignVersionPid <br/>  released <br/> ... <br/>
Should be replaced with the [[Talk:ESciDoc_Item_Container_Version_History#eSciDoc_event_types|list of eventType values]] from controlled vocabulary. <br/> NS suggestion: http://purl.org/escidoc/versionhistory/ves/0.1/
|}
{| class="wikitable" style="text-align: left;"
!style="background:#87CEEB; width:150px;"| Semantic unit
!style="background:#87CEEB; width:600px;" id="eventDateTime"| 2.3 eventDateTime
|-
|-
!style="background:#87CEEB"| Semantic<br/>components
!style="background:#87CEEB"| Semantic<br/>components

Revision as of 15:36, 5 January 2010

This is a protected page.

Concepts[edit]

See Item, Container Specs&APIs here

Container Handler[edit]

Containers offer the concept of aggregation, i.e. they can contain other (simple and complex) objects. Each container includes a structural map, which manages references to all members of the aggregation. Containers are versionable. They can be associated with a persistent identifier. Containers have a built-in basic object lifecycle. The status of a Container within its object lifecycle influences which actions are applicable and which user privileges are to be evaluated.

Item Handler[edit]

Items are objects representing the actual content of the repository. An item is a simple or complex object like an article, a report or a translation. Items are versionable. They can be associated with a persistent identifier. Items have a built-in basic object lifecycle. The status of an Item within its object lifecycle influences which actions are applicable and which user privileges are to be evaluated.

Premis Event Entity[edit]

The Event entity aggregates information about an action that involves one or more Object entities. Metadata about an Event would normally be recorded and stored separately from the digital object.

Whether or not a preservation repository records an Event depends upon the importance of the event. Actions that modify objects should always be recorded. Other actions such as copying an object for backup purposes may be recorded in system logs or an audit trail but not necessarily in an Event entity. Mandatory semantic units are: eventIdentifier, eventType, and eventDateTime.

This is a hierarchical listing of the semantic units included in the Data Dictionary. The information in parentheses following each semantic unit indicates whether the element is Mandatory (M) or Optional (O), followed by whether it is Repeatable (R), Not repeatable (NR) or Attribute (A).

V1.0[edit]

  1. eventIdentifier (M, NR)
    1. eventIdentifierType (M, NR)
    2. eventIdentifierValue (M, NR)
  2. eventType (M, NR)
  3. eventDateTime (M, NR)
  4. eventDetail (O, NR)
  5. eventOutcomeInformation (O, R)
    1. eventOutcome (O, NR)
    2. eventOutcomeDetail (O, R)
  6. linkingAgentIdentifier (O, R)
    1. linkingAgentIdentifierType (M, NR)
    2. linkingAgentIdentifierValue (M, NR)
    3. linkingAgentRole (O, R)
    4. linkingAgentXmlID (O, A)
  7. linkingObjectIdentifier (O, R)
    1. linkingObjectIdentifierType (M, NR)
    2. linkingObjectIdentifierValue (M, NR)
    3. linkingObjectXmlID (O, A)
  8. xmlID (M, A)

V2.0[edit]

  1. eventIdentifier (M, NR)
    1. eventIdentifierType (M, NR)
    2. eventIdentifierValue (M, NR)
  2. eventType (M, NR)
  3. eventDateTime (M, NR)
  4. eventDetail (O, NR)
  5. eventOutcomeInformation (O, R)
    1. eventOutcome (O, NR)
    2. eventOutcomeDetail (O, R)
      1. eventOutcomeDetailNote (O, NR)
      2. eventOutcomeDetailExtension (O, NR)
  6. linkingAgentIdentifier (O, R)
    1. linkingAgentIdentifierType (M, NR)
    2. linkingAgentIdentifierValue (M, NR)
    3. linkingAgentRole (O, R)
    4. LinkAgentXmlID (O, A)
  7. linkingObjectIdentifier (O, R)
    1. linkingObjectIdentifierType (M, NR)
    2. linkingObjectIdentifierValue (M, NR)
    3. linkingObjectRole (O, R)
    4. LinkObjectXmlID (O, A)
  8. xmlID (M, A)

Changes v1.0=>v2.0[edit]

  • Complete schema in one file instead of separate files.
  • Added elements:
    • eventOutcomeDetailNote (O, NR)
    • eventOutcomeDetailExtension (O, NR)
    • linkingObjectRole (O, R)

PREMIS data dictionary[edit]

Semantic unit 2.1 eventIdentifier
Semantic
components
2.1.1 eventIdentifierType
2.1.2 eventIdentifierValue
Definition A designation used to uniquely identify the event within the

preservation repository system.

Rationale Each event recorded by the preservation archive must have a unique

identifier to allow it to be related to objects, agents, and other events.

Data constraint Container
Repeatability Not repeatable
Obligation Mandatory
Creation /
Maintenance notes
The eventIdentifier is likely to be system generated. There is no

global scheme or standard for these identifiers. The identifier is therefore not repeatable.

eSciDoc Each event recorded by the preservation archive must have a unique

identifier to allow it to be related to objects, agents, and other events.


Semantic unit 2.1.1 eventIdentifierType
Semantic
components
None
Definition A designation of the domain within which the event identifier is unique.

ifier to allow it to be related to objects, agents, and other events.

Data constraint None
Examples FDA
Stanford Repository Event ID
UUID
Repeatability Not repeatable
Obligation Mandatory
Creation /
Maintenance notes
For most preservation repositories, the eventIdentifierType will be its

own internal numbering system. It can be implicit within the system and provided explicitly only if the data is exported.

eSciDoc URL


Semantic unit 2.1.2 eventIdentifierValue
Semantic
components
None
Definition The value of the 2.1 eventIdentifier
Data constraint None
Examples [a binary integer]
E-2004-11-13-000119
58f202ac-22cf-11d1-b12d-002035b29092
Repeatability Not repeatable
Obligation Mandatory
eSciDoc Value of the URL
--Makarenko 14:19, 5 January 2010 (UTC): For the moment values like
/ir/container//version-history#v40e1257337841231
/ir/container/escidoc:29780:39version-history#v39e1257337708130
To be consolidated.


Semantic unit 2.2 eventType
Semantic
components
None
Definition A categorization of the nature of the event.
Rational Categorizing events will aid the preservation repository in machine processing of event information, particularly in reporting.
Data constraint Value should be taken from a controlled vocabulary.
Examples E77 [a code used within a repository for a particular event type]
Ingest
Repeatability Not repeatable
Obligation Mandatory
Usage Notes 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.
normalization = a transformation of an object creating a version more conducive to preservation
replication = the process of creating a copy of an object that is, bitwise, identical to the original
validation = the process of comparing an object with a standard and noting compliance or exceptions
virus check = the process of scanning a file for malicious programs. Note that migration, normalization, and replication are more precise subtypes of the creation event. “Creation” can be used when more precise terms do not apply, for example, when a digital object was first created by scanning from paper. In general, the level of specificity in recording the type of event (e.g., whether the eventType indicates a transformation, a migration or a particular method of migration) is implementation specific and will depend upon how reporting and processing is done. Recommended practice is to record detailed information about the event itself in eventDetail rather than using a very granular value for eventType.

eSciDoc --Makarenko 14:43, 5 January 2010 (UTC) For the moment the following values are presented:
create
update
submitted
assignVersionPid
released
...

Should be replaced with the list of eventType values from controlled vocabulary.
NS suggestion: http://purl.org/escidoc/versionhistory/ves/0.1/


Semantic unit 2.3 eventDateTime
Semantic
components
None
Definition A categorization of the nature of the event.
Rational Categorizing events will aid the preservation repository in machine processing of event information, particularly in reporting.
Data constraint Value should be taken from a controlled vocabulary.
Examples E77 [a code used within a repository for a particular event type]
Ingest
Repeatability Not repeatable
Obligation Mandatory
Usage Notes 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.

eSciDoc --Makarenko 14:43, 5 January 2010 (UTC) For the moment the following values are presented:
create
update
submitted
assignVersionPid
released
...

Should be replaced with the list of eventType values from controlled vocabulary.
NS suggestion: http://purl.org/escidoc/versionhistory/ves/0.1/

Links[edit]

Examples[edit]