[Moims-ipr] XFDU and SIPs

[Boucon Daniele]

 Hello Lou,

 Here is our answer to your last SIPXFDU proposal. I hope this is clear enough. Let me know if this is not the case.

 First of all, here is a recap of our needs:

 First need:
==================================================================================

 1. A SIP is a group of objects of the same or of different types, and so related to one or different Descriptors.
 2. All these objects have information in common, for example the Producer, the Project, the SIP template, ...: this is what we call the "global information".

 We need to access in an easy way in the XFDU :
 ==> only once for the global information, 
 ==> as many times as necessary for each embedded object for the associated information.
 
 Here is the list of the information needed in a SIPXFDU (M=Mandatory, O=Optional + occurrence number):

·	Global Information (M, 1..1) : 
o	SIP ID (M, 1..1) : SIP ID.
o	Producer ID (M, 1..1) : this ID should enable the Archive to identify the Producer,
o	Project ID (O, 0..1),
o	SIP template ID (M, 1..1) and SIP template location (M, 1..1) .
·	Information related to each embedded object (M, 1..N) :
o	Descriptor_ID (M, 1..1) and Descriptor location (M , 1..1) : necessary to validate the object with the POT. Each Data and Metadata ID included in the Descriptor should  be included as well in the SIP template (logical links inside the SIP) in order to identify the right Digital Objects with the excpected objects.
o	Last objet (O, 0..1) : Indicator specifying that it is the last object (among the Data Objects, Complementary Data Objects or Collections corresponding to the same POT node). This attribute is useful if the number of objects in a collection is not known ahead of time and is not defined in the POT. When it is used, a sequence management rule has to be specified for transferring the objects (case in which, during transfer, the last object would not arrive last).
o	Updated object (O, 0..1) : for re-delivered object.

==========================================================================================


 Second need:
==========================================================================================
Case of very big files that could not be delivered in the same XFDU.

 This file has to be broken in several pieces: how this is possible in the current XFDU, and how will the Archive know the way to reconstruct the expected Object from the several XFDUs (order, software requested, ...)?

Is it with an XFDU pointer?

==============================================================================

 To conclude
===============================================================================

 We don't really agree with your 2 proposals because:

 In your first proposal: the information is located in 2 places: there are 2 package maps, that seems not good and may be confusing.

 In your second proposal: the global information is repeated. It's up to the Producer to manage the occurrence by the means of hierarchy and options, that seems not clear.

 Our suggestion is for the global info: why not having something like a "header.globalinfo" in the packageHeader part? I feel this will be really useful for the "recipient" (the Archive) who may need all sort of information contained in the XFDU (provenance...) that is not possible to have easily at the moment.

 We are aware that this is not easy, but sure this is useful.

 Cheers,

 Claude, Arnaud, Daniele

 PS: Otherwise, to be added to the sipContentUnit part: the other information related to each embedded object, such as the "updatedObject" attribute. And it'll be better to change sipDescriptorName into descriptor_ID and sipDescriptor into descriptor_location (to be coherent with the Descriptor definition). We could decide this later.