[Moims-dai] ESA SAFE test case

Wed Oct 8 21:17:15 UTC 2014

Hi all,

Please find enclosed, for your validation, the last version of the ESA SAFE test case, including the comments from Mike included in the Minutes dated the 14th August (also duplicated at the end of this mail).

To be discussed during our tomorrow telecon.

Cheers,

Daniele
____________________________________________________________________
Extract from the 14th August minutes

1.      Comments on the SAFE green book section (from emails MM 22nd July, DB 13th August).
1.      MM: Might want to include a url for SAFE documentation.
DB: agreement on:
"SAFE (Standard Archive Format for Europe, see reference [X] ) is an Earth Observation data archiving format standardized through the efforts of several European national, institutional and industrial space stakeholders. It aims at covering the role of OAIS AIP"

*       Action DB:  ask ESA for the reference to the SAFE 2.0 standard documentation.
2.      MM: E1 first paragraph, I don't think many people will understand the second sentence.  "It aims ..."  AIP should be spelled out.  Maybe something like "It provides a specification for the organization and content of an OAIS compatible archive information package."
DB: ok, with the exact meaning "Archival Information Package (AIP)"
3.      MM: E1 second paragraph, "These data are from the European Remote Sensing Satellite (ERS) Synthetic Aperture Radar (SAR)."
DB: change to "These data are samples and subset from the European Remote Sensing Satellite (ERS) Synthetic Aperture Radar (SAR), and tailored for the scope of this test case."

4.  MM: E1 third paragraph.  "In the context of this use case," is kind of complicated. How about "In this use case" instead.  Also, 'submission to an archive" instead of "submission into".  "The approach followed in this tutorial intends to show the possibility of:"  should be "This tutorial illustrates".

DB: agree with these proposals.

MM: As you can see, I am finding grammatical issues with every single paragraph.  Someone needs to carefully edit all the text in this section, but I don't have time to do in now.

*       Action all (at the end): overall reading of the document (consistency, coherence, grammatical issues, ...)

5.      MM: The diagram Figure E-4 shows the three sub-collections of the root collection.  I would expect to see a relation-association in the root that "contains" each of these sub collections.?  So I guess the arrows in the figures are generated by the parentCollection specification in each child collection.

DB: (not sure I correctly  understand the issue). You're right: In the CNES tool, the plain arrows are designed from the root towards the leaves, while actually the link in the XML files are specified into the sub collections or the leaves towards the parent element (the element "parentCollection").

MM: I brought this issue of downward and upward pointers or associations up in our discussions last year and Stephane seemed to think the upward pointers were the appropriate ones.  I am concerned that having two ways of specifying the same thing may be dangerous.  Anyway, I think there should be some guidance on this issue.  The question is: why does Don include "contains" associations from the root collection to the transfer objects in his example when Daniele doesn't include them between the collection and sub collections in her example?

DB: the "contains" association ("relationType) is not mandatory at all. I guess it is for better description and understanding. The "parentCollection = NASA_ESA_CNES_Test_Data_Exchange_02" in the Transfer Object is sufficient to explain the parent-child relationships between both nodes.
That's why in the ESA SAFE case this association has not been put over the parent-child relationship.

6.      MM: Why are the relations in the SAFE test case at the dataObject level and not at the transfer object level as they are in the ISEE test case?

DB: Up to the Producer and Archive to decide what makes sense.

In the "Simple case" where there are 4 group types, the association is described from the exact data object inside the right group type.
In the "Detailed case", the association could have been drawn from the Transfer Object, because there is only one group type and one data object inside. The choice of the data object as source of the association is to draw the parallel between simple and detailed case. In this case, both descriptions are possible.

Discussion on "open" possibilities in the standard, such as the way to express associations.
MM: informal expression of elements in the MOT -> practical use?
DS: different ways to model the same situation -> not easy to understand.
DS: Try to normalize the diagram?
MM: make the documentation clearer.

7.      MM: Why are the groupTypeStructureName entries "SET" in the simple case and "Directory" in the detailed case?

DB:  In both cases the "physical" high level group for the products on the Producer side is a directory and could have been viewed as "directory" "EO_PRODUCTS".  In fact this level has not been modeled.  So in the simple case we have a group (mandatory) of  one zip file that is the product itself -> viewed as a "set", in the detailed case we have a group (mandatory) of one directory that is the product itself containing different files -> viewed as a "directory".

DS: give more explanation in the tutorial (see point 2 below).

*       Action DB: give explanation on the reason why using group structure name = "directory" in the detailed case, and "set" in the simple case (from Minutes 14th August).
*       Action DB: updated version of the ESA SAFE test case with comments from the 14th August telecon.
______________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20141008/ac69352c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 651x2g0-[6.5]-esa-safe-final -2 .docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 253476 bytes
Desc: 651x2g0-[6.5]-esa-safe-final -2 .docx
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20141008/ac69352c/attachment.docx>