Difference between revisions of "ESciDoc Item Container Version History"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<accesscontrol>MPDL</accesscontrol>
[[Category:LZA]]
 
''In progress''
= Concepts =
= Concepts =
See Item, Container Specs&APIs [http://www.escidoc.org/JSPWiki/en/ObjectManager here]  
See Item, Container Specs&APIs [http://www.escidoc.org/JSPWiki/en/ObjectManager here]  
Line 66: Line 66:
** linkingObjectRole (O, R)
** linkingObjectRole (O, R)


===PREMIS data dictionary===
=== eventType ===
 
See [[ESciDoc_Version_History_Event_Type]].
{| class="wikitable" style="text-align: left;"
!style="background:#87CEEB; width:150px;"| Semantic unit
!style="background:#87CEEB; width:600px;" id="eventIdentifier" | 2.1 eventIdentifier
|-
!style="background:#87CEEB"| Semantic<br/>components
|style="background:#87CEEB"| [[#eventIdentifierType|2.1.1 eventIdentifierType]]<br/>2.1.2 [[#eventIdentifierValue|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
|-
!align="left"| Obligation
| Mandatory
|-
! Creation /<br> 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.
|-
!style="background:#98FB98"| eSciDoc
|style="background:#98FB98"| Each event recorded by the preservation archive must have a unique
identifier to allow it to be related to objects, agents, and other events.
|}
 
 
{| class="wikitable" style="text-align: left;"
!style="background:#87CEEB; width:150px;"| Semantic unit
!style="background:#87CEEB; width:600px;" id="eventIdentifierType"| 2.1.1 eventIdentifierType
|-
!style="background:#87CEEB"| Semantic<br/>components
|style="background:#87CEEB"| 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<br/>Stanford Repository Event ID<br/>UUID
|-
! Repeatability
| Not repeatable
|-
! Obligation
| Mandatory
|-
! Creation /<br> 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.
|-
!style="background:#98FB98"| eSciDoc
|style="background:#98FB98"| URL
 
|}
 
 
{| class="wikitable" style="text-align: left;"
!style="background:#87CEEB; width:150px;"| Semantic unit
!style="background:#87CEEB; width:600px;" id="eventIdentifierValue"| 2.1.2 eventIdentifierValue
|-
!style="background:#87CEEB"| Semantic<br/>components
|style="background:#87CEEB"| None
|-
! Definition
| The value of the [[#eventIdentifier|2.1 eventIdentifier]]
|-
! Data constraint
| None
|-
! Examples
| [a binary integer] <br/> E-2004-11-13-000119 <br/> 58f202ac-22cf-11d1-b12d-002035b29092
|-
! Repeatability
| Not repeatable
|-
! Obligation
| Mandatory
|-
!style="background:#98FB98"| eSciDoc
|style="background:#98FB98"| Value of the URL <br/> --[[User:Makarenko|Makarenko]] 14:19, 5 January 2010 (UTC): For the moment values like <br/> /ir/container//version-history#v40e1257337841231 <br/> /ir/container/escidoc:29780:39version-history#v39e1257337708130 <br/> To be consolidated.
 
|}
 
 
{| class="wikitable" style="text-align: left;"
!style="background:#87CEEB; width:150px;"| Semantic unit
!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"| 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. <br/> 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. <br/> 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/
 
|}


=Links=
=Links=
Line 250: Line 83:
=Examples=
=Examples=
*container version-history, dev-coreservice, [http://dev-coreservice.mpdl.mpg.de:8080/ir/container/escidoc:29780/resources/version-history escidoc:29780]
*container version-history, dev-coreservice, [http://dev-coreservice.mpdl.mpg.de:8080/ir/container/escidoc:29780/resources/version-history escidoc:29780]
*item version-history, dev-coreservice, [http://dev-coreservice.mpdl.mpg.de:8080/ir/container/escidoc:29777/resources/version-history escidoc:29777]
** Not Found [[User:Frank|Frank]] 13:19, 8 March 2010 (UTC)
*item version-history, dev-coreservice, [http://coreservice.mpdl.mpg.de/ir/item/escidoc:66603/resources/version-history escidoc:66603]
** Not Found (neither as container nor as item) [[User:Frank|Frank]] 13:19, 8 March 2010 (UTC)
 
 
[[Category:ESciDoc|Item Container Version History]]

Latest revision as of 09:39, 7 January 2011

In progress

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)

eventType[edit]

See ESciDoc_Version_History_Event_Type.

Links[edit]

Examples[edit]

  • container version-history, dev-coreservice, escidoc:29780
    • Not Found Frank 13:19, 8 March 2010 (UTC)
  • item version-history, dev-coreservice, escidoc:66603
    • Not Found (neither as container nor as item) Frank 13:19, 8 March 2010 (UTC)

Preservation Metadata: Implementation Strategies

Error Management and Project Management Software

Application Programming Interface

Coordinated Universal Time

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=ESciDoc_Item_Container_Version_History&oldid=58110"