Talk:ESciDoc Item Container Version History

General[edit]

In general, as eSciDoc only records premis-event information, it would be good to focus on premis-v2 for event only for start. Not clear whether further premis data should be considered when exporting to LTA, but this would be minimal start.

   *  2.1 eventIdentifier (M, NR)
         o 2.1.1 eventIdentifierType (M, NR) --Natasa 16:26, 22 December 2009 (UTC)no changes
         o 2.1.2 eventIdentifierValue (M, NR)--Natasa 16:26, 22 December 2009 (UTC)no changes
   * 2.2 eventType (M, NR) --Natasa 16:26, 22 December 2009 (UTC)changes from controlled vocabulary (to be developed)
   * 2.3 eventDateTime (M, NR) --Natasa 16:26, 22 December 2009 (UTC) no changes
   * 2.4 eventDetail (O, NR) --Natasa 16:26, 22 December 2009 (UTC) change: to be provided by the end user
                               with the operation (additionally for update, create)
   * 2.5 eventOutcomeInformation (O, R)
         o 2.5.1 eventOutcome (O, NR) --Natasa 16:26, 22 December 2009 (UTC)change: in here system generated messages e.g. itemhandler.update
         o 2.5.2 eventOutcomeDetail (O, R) 
               + 2.5.2.1 eventOutcomeDetailNote (O, NR) --Natasa 16:26, 22 December 2009 (UTC)more details
                                                         e.g. itemhandler.addcontentrelations,
                                                          containerhandler.addcontentrelations (more details on the event 
                                                          that actually happened with update operation) - valid for Update
                                                          operation
               + 2.5.2.2 eventOutcomeDetailExtension (O, R)
   * 2.6 linkingAgentIdentifier (O, R) 
        o 2.6.1  linkingAgentIdentifierType (M, NR) --Natasa 16:26, 22 December 2009 (UTC)proposal use:
                                                       "escidoc.user.id" or smth better
        o 2.6.2  linkingAgentIdentifierValue (M, NR)--Natasa 16:26, 22 December 2009 (UTC)no change
        o 2.6.3  linkingAgentRole(O, R) --Natasa 16:26, 22 December 2009 (UTC) two possible values 
                                                                                               ( user, system)

   * 2.7 linkingObjectIdentifier (O, R)--Natasa 16:26, 22 December 2009 (UTC) this information should be
                                         populated only in particular cases in case of eSciDoc repository, for example: 
                                         when a handle is assigned then this is an information of the handle, when item
                                         relation is created in the item - then this is an information on the item that has
                                         been related, when a member is added to the container, then this is an information of
                                         the item related as a member (respectively the object role: identifier, member.. 
                                         in case of relations, then i would suggest the role is the relation predicate itself)
         o 2.7.1 linkingObjectIdentifierType (M, NR) --Natasa 16:26, 22 December 2009 (UTC)proposal use:
                                                              "escidoc.item.id", "escidoc.container.id" or smth better
         o 2.7.2 linkingObjectIdentifierValue (M, NR)--Natasa 16:26, 22 December 2009 (UTC)no change
         o 2.7.3 linkingObjectRole (O, R) --Natasa 16:26, 22 December 2009 (UTC)see comment above

Schema[edit]

http://www.loc.gov/standards/premis/v2/premis-v2-0.xsd

eSciDoc event types[edit]

Note: such event types can be used in both "eventType" and "eventOutcomeDetailNote"

to be checked exactly what the namespace e.g. controlled vocab should look like (this may be also created in CONE)

Identifier types[edit]

to be checked exactly what the namespace e.g. controlled vocab should look like (this may be also created in CONE)

Object Role[edit]

URIs can be provided also for object roles (as these are already having property namespaces)

core-service 1.3 potential implementation[edit]

migrate version-history data
enable item.xml with operation comments by the user, related to changes proposed at unification of the presentation
- alternative1: provide operation-comment as optional attribute within the <item> element (no change of the external interfaces in this case is needed)
- alternative2: provide operation-comment in <version><comment> element
- other?

In any case, these operation-comments would have to be ignored when task-oriented methods are performed.