Talk:ESciDoc Item Container Version History

General
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
http://www.loc.gov/standards/premis/v2/premis-v2-0.xsd

eSciDoc event types
Note: such event types can be used in both "eventType" and "eventOutcomeDetailNote"
 * Isn't the detail note more an explanation or further detailed information? (http://www.loc.gov/standards/premis/v2/premis-2-0.pdf, P. 141) I expected the comment to be placed therein. Frank 13:02, 8 March 2010 (UTC)


 * agreed: Event types in eSciDoc version history

Identifier types

 * URL
 * http://escidoc.org/identifier-types/user
 * http://escidoc.org/identifier-types/item
 * http://escidoc.org/identifier-types/container
 * http://escidoc.org/identifier-types/organizational-unit


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

The Premis Data Dictionary seems to mean a string to denote the context from which the identifier comes. That primarily means where the identifier is unique. One example is just "local". But the identifier type should be specific as possible. E.g. to use "URL" is not recommended. Frank 13:16, 8 March 2010 (UTC)

The above example might indicate there is an identifier of an user or item etc. of the eSciDoc Infrastructure. On one side that seems to be more specific as an identifier in the eSciDoc Infrastructure and on the other side it is not very specific because the indentifier is not unique in eSciDoc Infrastructure at all but in one specific infrastructure. But the latter seems to apply for "local" too. Frank 13:16, 8 March 2010 (UTC)

See http://www.loc.gov/standards/premis/v2/premis-2-0.pdf#page=17, P. 10, 12. Frank 13:16, 8 March 2010 (UTC)

In another example "URI" -- which is less specific than URL -- is used as identifier type. (http://www.loc.gov/standards/premis/v2/premis-2-0.pdf#page=160, P. 153) Frank 13:41, 8 March 2010 (UTC)

Object Role

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

core-service 1.3 potential implementation
In any case, these operation-comments would have to be ignored when task-oriented methods are performed.
 * 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 element (no change of the external interfaces in this case is needed)
 * alternative2: provide operation-comment in element
 * other?
 * Does that mean in case of the optional attribute within the element if such an attribute appears in the task param of a task oriented method it should be ignored because there is already the possibility to send a operation-comment in a element? Frank 08:47, 21 January 2010 (UTC)
 * Alternatively the functionality for providing the comment can be aligned for both, resource and task oriented methods!? Frank 08:47, 21 January 2010 (UTC)