<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Dear all,</div>
<div> </div>
<div>Please find below the proposed agenda for tomorrow telecon:</div>
<div> </div>
<div>*ISEE Test case</div>
<div>* PAIS PDS-NSSDC Wrapup Document (email from Mike, 27th August)</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>* METS test case: first comments, organization (email from Daniele 13<font size="1"><span style="font-size:7.3pt;"><sup>th</sup></span></font> August)</div>
<ol start="2" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">* Information Curation Process: comments on documents sent by John (email from John, 11<font size="1"><span style="font-size:7.3pt;"><sup>th</sup></span></font> August), terminology (email from Daniele, 3<font size="1"><span style="font-size:7.3pt;"><sup>rd</sup></span></font>
September)</li><li style="margin-top:5pt;margin-bottom:5pt;">* DAI registry <a href="http://www.sanaregistry.org/r/daixml/daixml.html"><font face="Times New Roman" size="3" color="blue"><span style="font-size:12pt;"><u>http://www.sanaregistry.org/r/daixml/daixml.html</u></span></font></a><font face="Times New Roman" size="3"><span style="font-size:12pt;">
</span></font>(link towards CCSDS publication page)</li><li style="margin-top:5pt;margin-bottom:5pt;">* PAIS and ISO (20104)</li><li style="margin-top:5pt;margin-bottom:5pt;">* Next meeting preparation (topics, availability, constraints for agenda)</li><li style="margin-top:5pt;margin-bottom:5pt;">* Review of actions (email from John, 21<font size="1"><span style="font-size:7.3pt;"><sup>st</sup></span></font> August)</li><li style="margin-top:5pt;margin-bottom:5pt;"> </li></ol>
<div><u>Next telecons</u><font face="Times New Roman" size="3"><span style="font-size:12pt;"><b>: </b></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> <font face="Calibri" size="2"><span style="font-size:11pt;"> </span></font></span></font></div>
<div><b>* Tuesday 23</b><font size="1"><span style="font-size:5pt;"><b><sup>rd</sup></b></span></font><b> September</b></div>
<div><b>* Thursday 9</b><font size="1"><span style="font-size:5pt;"><b><sup>th</sup></b></span></font><b> October</b></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font color="#1F497D"><u>If available, I propose to use Dave's number</u><u> </u><font color="red"><u>(</u></font><font color="red"><u>be </u></font><font color="red"><u>careful, new number</u></font><u>)</u><u>:</u></font></div>
<div>Dave Williams<br>
Telecon information <br>
+<font face="Times New Roman" size="3"><span style="font-size:12pt;">1-720-259-6462</span></font> USA Toll free
<br>
+<font face="Times New Roman" size="3"><span style="font-size:12pt;">1-844-467-6272</span></font> Others
<br>
Passcode: <font face="Times New Roman" size="3"><span style="font-size:12pt;">841727</span></font></div>
<div> </div>
<div>Best regards,</div>
<div> </div>
<div>Daniele </div>
<div>___________________________________________________________________________________________________________</div>
<div><font size="4" color="red"><span style="font-size:14pt;"><b>14 August minutes</b></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>DB: Daniele Boucon</div>
<div>DS: Don Sawyer</div>
<div>JG: John Garrett</div>
<div>MM: Mike Martin</div>
<div>SM: Stephane Mbaye</div>
<div>WG: all</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><span style="background-color:aqua;"><b>D=Decision, A=action</b></span><b> (other = discussion)</b></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<ol style="margin:0;">
<font size="4"><span style="font-size:14pt;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b>Comments on the SAFE green book section </b><font size="2"><span style="font-size:11pt;"><b>(from emails MM 22</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>nd</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b>
July, DB 13</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>th</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b> August).</b></span></font></li></span></font>
</ol>
<div> </div>
<ol style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: Might want to include a url for SAFE documentation.</li></ol>
<div>DB: agreement on:</div>
<div>“SAFE (Standard Archive Format for Europe, <span style="background-color:yellow;">see</span> <span style="background-color:yellow;">reference [</span><font size="2"><span style="font-size:10pt;background-color:yellow;">X</span></font><span style="background-color:yellow;">]</span>
) 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”</div>
<div><font color="#548DD4"> </font></div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action DB:</u></b> ask ESA for the reference to the SAFE 2.0 standard documentation.</li></ul>
<div> </div>
<ol start="2" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">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."</li></ol>
<div> </div>
<div>DB: ok, with the exact meaning “Archival Information Package (AIP)“</div>
<div> </div>
<ol start="3" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: E1 second paragraph, "These data are from the European Remote Sensing Satellite (ERS) Synthetic Aperture Radar (SAR)."</li></ol>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>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."</div>
<div> </div>
<div style="text-indent:35.4pt;">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".</div>
<div> </div>
<div>DB: agree with these proposals.</div>
<div> </div>
<div>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.</div>
<div> </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action all (at the end)</u></b>: overall reading of the document (consistency, coherence, grammatical issues, …)</li></ul>
<div> </div>
<ol start="5" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">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.</li></ol>
<div> </div>
<div>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”).</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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.</div>
<div>That’s why in the ESA SAFE case this association has not been put over the parent-child relationship.</div>
<div> </div>
<ol start="6" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">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?</li></ol>
<div> </div>
<div>DB: Up to the Producer and Archive to decide what makes sense.</div>
<div> </div>
<div>In the “Simple case” where there are 4 group types, the association is described from the exact data object inside the right group type.</div>
<div>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.</div>
<div><font color="#548DD4"> </font></div>
<div><font color="#548DD4"> </font></div>
<div>Discussion on “open” possibilities in the standard, such as the way to express associations.</div>
<div>MM: informal expression of elements in the MOT -> practical use?</div>
<div>DS: different ways to model the same situation -> not easy to understand.</div>
<div>DS: Try to normalize the diagram?</div>
<div>MM: make the documentation clearer.</div>
<div> </div>
<ol start="7" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: Why are the groupTypeStructureName entries "SET" in the simple case and "Directory" in the detailed case?</li></ol>
<div> </div>
<div>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”.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div style="text-indent:18pt;">DS: give more explanation in the tutorial (see point 2 below). </div>
<div style="text-indent:18pt;"><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action DB:</u></b> give explanation on the reason why using group structure name = “directory” in the detailed case, and “set” in the simple case (from Minutes 14<font size="1"><span style="font-size:5pt;"><sup>th</sup></span></font>
August).</li><li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action DB:</u></b> updated version of the ESA SAFE test case with comments from the 14<font size="1"><span style="font-size:5pt;"><sup>th</sup></span></font> August telecon.</li></ul>
<div> </div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<ol start="2" style="margin:0;">
<font size="4"><span style="font-size:14pt;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b>Overall comments on Green Book </b><font size="2"><span style="font-size:11pt;"><b>(from emails MM 22</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>nd</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b>
July, DB 13</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>th</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b> August).</b></span></font></li></span></font>
</ol>
<div> </div>
<ol style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: Should show one example of a hierarchy of collections.</li></ol>
<div> </div>
<div style="text-indent:35.4pt;">DB: agree, with advice on the choice of collections: link between the physical organization on the Producer side, the physical organization of the delivery, the design of the MOT.</div>
<div> </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action SM</u></b>: check there is a section about the hierarchy of collections in the tutorial. If not, add it with example and explanation (from 14<font size="1"><span style="font-size:5pt;"><sup>th</sup></span></font>
August telecon)</li></ul>
<div> </div>
<div> </div>
<ol start="2" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: Tutorial should provide a short demonstration of every type of group structure: directory, set, sequence or undescribed structure. [Note: the word "undescribed" does not show up in some spelling dictionaries]</li></ol>
<div> </div>
<div>DB: agree. From discussion with other people, seems not so easy to understand, particularly the fact that there is no direct link with the SIP model (delivery), except the “transferObjectGroupInstanceName in the case of “directory” in the sipTranferObjectGroupType),
and that, a “Set” is physically included in a directory.</div>
<div>Questions that occur: What should be modeled? Which levels? Links or not with the delivery (way data are delivered to the Archive)?</div>
<div> </div>
<div>MM:tutorial should contain precise examples (same case/SIP with the different possibilities, when to use “directory” or not, “sequence” …).</div>
<div> </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action SM</u></b>: check there is a section in the tutorial about the type of group structure (directory, set, sequence, undescribed). If not, add it with the same case showing the different possibilities
and why use one or the other (from 14<font size="1"><span style="font-size:5pt;"><sup>th</sup></span></font> August telecon).</li></ul>
<div> </div>
<ol start="3" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: Tutorial should demonstrate the use of dataObjectTypeFileOccurrence.</li></ol>
<div> </div>
<div style="text-indent:35.4pt;">DB: agree, also to avoid potential confusion with dataObjectTypeOccurrence.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action SM</u></b>: check there is a section in the tutorial about the dataObjectTypeOccurrence (from 14<font size="1"><span style="font-size:5pt;"><sup>th</sup></span></font> August telecon).</li></ul>
<div><font color="#548DD4"> </font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<ol start="3" style="margin:0;">
<font size="4"><span style="font-size:14pt;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b>Comments on ISEE section </b><font size="2"><span style="font-size:11pt;"><b>(from emails MM 22</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>nd</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b>
July, DB 13</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>th</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b> August, DS 14</b></span></font><font size="1"><span style="font-size:5pt;"><b><sup>th</sup></b></span></font><font size="2"><span style="font-size:11pt;"><b>
August)</b></span></font><b>.</b></li></span></font>
</ol>
<div> </div>
<div>1. MM: Page 1, second paragraph, this sentence doesn't logically follow the preceding sentence. "This gives the Archive the ability to apply some automation in reviewing the received SIPs so they can be checked for conformance to the agreed plans, and
this helps to reduce errors."</div>
<div>DS: Yes, I’ve changed the order of the last 2 sentences.</div>
<div> </div>
<div>2. MM: Page 2, first paragraph, I am uncomfortable with this wording. </div>
<div>"The tree hierarchical levels"</div>
<div> </div>
<div>DB: the hierarchical tree structure? </div>
<div>DS: I’ve deleted ‘tree'</div>
<div> </div>
<ol start="4" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">MM: Page 2, last line, "how it should be broken into", I would prefer "divided into" or some other wording.</li></ol>
<div> </div>
<div>DS: Don: I’ve made it ‘divided'</div>
<div> </div>
<ol start="5" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Page 3, first paragraph, "Since the Transfer Object is the smallest unit of data that can be sent in a SIP and Transfer", I don't think this is worded quite right. The transfer object is the smallest unit that
can be deleted or replaced, but not the smallest unit that can be sent.</li></ol>
<div> </div>
<div>DS: the Transfer Object can’t actually be divided for sending. Another wording?</div>
<div>DS: The key is that a Transfer Object can’t be split across SIPs. I’ve updated the wording.</div>
<div> </div>
<ol start="6" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Page 3, third paragraph, "extensive validation requirement", should be "requirements".</li></ol>
<div> </div>
<div>DD and DS: ok</div>
<div> </div>
<ol start="7" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Page 3. I got lost reading paragraph 5. It seems like it repeats a lot of the previous paragraph but adds a few details. I think it needs to be simplified, building on the previous paragraph.</li></ol>
<div> </div>
<div>DS: The 4th paragraph talks about the types of Transfer Objects, while the 5th paragraph talks about the actual results of matching the Descriptor with the directory. However I’ve made a few updates to the 4th paragraph for clarity, and I’ve deleted
the 5th paragraph because it is now redundant with the next section discussion the MOT.</div>
<div> </div>
<div> </div>
<ol start="8" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Page 4. The MOT section is redundant to what was on page 3. Is all the redundancy required?</li></ol>
<div>DS: No, see above.</div>
<div> </div>
<ol start="9" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Page 5, paragraph 2, The words "data" and "metadata" preceding "Transfer Objects" should be in bold type to match earlier paragraphs.</li></ol>
<div>DS: I’ve taken away the bold attribute. </div>
<div> </div>
<ol start="10" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Page 5, section 6.1.2, why the underlined words?</li></ol>
<div>DS: They are not there when track changes is turned off, unless I missed something.</div>
<div> </div>
<ol start="11" style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">Discussion on the SIP Manifest (email from DS 14<font size="1"><span style="font-size:5pt;"><sup>th</sup></span></font> August).</li></ol>
<div> </div>
<div>The problem is that the CU organization among the SIP Manifest is not coherent with the organization of the Groups in the Descriptor.</div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;">SIP Manifest should be corrected, and see why not correctly generated by the SIP builder?</li><li style="margin-top:5pt;margin-bottom:5pt;">Validation on the SIP Manifest not done at the organizational level (perhaps only at the ID level) in the CNES proto.</li></ul>
<div> </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action SB</u></b>: correct the generation of the ISEE SIP Manifest from the SIP Builder</li></ul>
<div> </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action DB</u></b>: understand the validation at the group structure level from the CNES proto.</li></ul>
<div> </div>
<div>CU organization among the SIP should be:</div>
<div> </div>
<div>XFDU CU Transfer Object for data</div>
<div> XFDU CU Satellite Group ISEE1</div>
<div> XFDU CU Yearly Group 1978</div>
<div> XFDU CU data file 0001</div>
<div> XFDU CU data file 0002</div>
<div> XFDU CU data file 0003 (The above is consisted with the new manifest, but then the manifest continues with a new XFDU CU Satellite Group. Instead it should continue with the next satellite, ISEE2, as a group with the same year, as follows.)</div>
<div> </div>
<div> XFDU CU Satellite Group ISEE2</div>
<div> XFDU CU Yearly Group 1978</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file …</div>
<div>(Then a new Transfer Object)</div>
<div> </div>
<div>XFDU CU Transfer Object for data</div>
<div> XFDU CU Satellite Group ISEE1</div>
<div> XFDU CU Yearly Group 1979</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU Satellite Group ISEE2</div>
<div> XFDU CU Yearly Group 1979</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> </div>
<div>(Then a third Transfer Object)</div>
<div> XFDU CU Transfer Object for data</div>
<div> XFDU CU Satellite Group ISEE1</div>
<div> XFDU CU Yearly Group 1980</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU Satellite Group ISEE2</div>
<div> XFDU CU Yearly Group 1980</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file ...</div>
<div> XFDU CU data file …</div>
<div> </div>
<div> </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b><u>Action DS</u></b>: generate a new ISEE test case version with the updated SIP Manifest</li></ul>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<ol start="4" style="margin:0;">
<font size="4"><span style="font-size:14pt;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b>Other topics</b></li></span></font>
</ol>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>JG: RAC standard for bodies now ISO standard. First training class planned first week of October (John is one of the teachers).</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font size="4" color="red"><span style="font-size:14pt;"><b>End of 14 August minutes</b></span></font></div>
<div>___________________________________________________________________________________________________________</div>
<div><font size="4" color="red"><span style="font-size:14pt;"><b>Part of historical minutes to be reminded</b></span></font></div>
<div>___________________________________________________________________________________________________________</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> 2. <font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>GREEN BOOK</u></b></span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> <font face="Calibri" size="2"><span style="font-size:11pt;"><b>2.1 </b></span></font><font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>TOC for test cases</u></b></span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b>* on the content of the sections,</b></div>
<div><b>* on the title of the sections</b></div>
<div><b>* on the following question:</b><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font>is that better to describe the SIP constraints with the MOT (in section 6.1.3), or in a global section on SIPs (section 6.1.4)?</div>
<div> </div>
<div>Discussion: </div>
<div>Brief introduction about the sub-TOC by Stephane.</div>
<div>John and Don: <i>6.1.4.1 SIP constraints, included in 6.1.3</i></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b>Current Structure:</b></div>
<div><span style="text-transform:uppercase;"><b>6</b></span>... <span style="text-transform:uppercase;"><b>Use Cases. 6-1</b></span></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"><span style="text-transform:uppercase;">6.1</span><font size="2"><span style="font-size:11pt;"> </span></font><span style="text-transform:uppercase;"><i>NAME</i></span><span style="text-transform:uppercase;">
– </span><span style="text-transform:uppercase;"><i>TITLE</i></span><span style="text-transform:uppercase;">.. 6-1</span></span></font></div>
<div><span style="text-transform:uppercase;">Description</span></div>
<div><span style="text-transform:uppercase;">6.1.1</span> <i>TEST_CASE_</i><span style="text-transform:uppercase;"><i>NAME</i></span><span style="text-transform:uppercase;"> DATA SET</span></div>
<div><span style="text-transform:uppercase;">6.1.2</span> <i>TEST_CASE_</i><span style="text-transform:uppercase;"><i>NAME</i></span><span style="text-transform:uppercase;"> MOT AND SIP CONSTRAINTS</span></div>
<div><span style="text-transform:uppercase;">6.1.4</span> <i>TEST_CASE_</i><span style="text-transform:uppercase;"><i>NAME</i></span><span style="text-transform:uppercase;"> SIPS</span></div>
<div> </div>
<div> </div>
<div><b>Decision on the Structure:</b></div>
<div><span style="text-transform:uppercase;"><b>6</b></span>... <span style="text-transform:uppercase;"><b>Use Cases</b></span></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"><span style="text-transform:uppercase;">6.1</span><font size="2"><span style="font-size:11pt;"> </span></font><span style="text-transform:uppercase;"><i>NAME</i></span><span style="text-transform:uppercase;">
– </span><span style="text-transform:uppercase;"><i>TITLE</i></span><span style="text-transform:uppercase;">.</span></span></font></div>
<div><span style="text-transform:uppercase;">6.1.1</span> <span style="text-transform:uppercase;">Context And Benefits</span></div>
<div> <span style="text-transform:uppercase;"><i>Contains description + what this test case shows</i></span></div>
<div><i> give explanation at the beginning of each test case of the specificity of the test case, and how the method applies</i></div>
<div><span style="text-transform:uppercase;">6.1.2</span> <span style="text-transform:uppercase;">Objects to be transferred</span></div>
<div> <span style="text-transform:uppercase;">same as </span><i>TEST_CASE_</i><span style="text-transform:uppercase;"><i>NAME</i></span><span style="text-transform:uppercase;"> DATA SET</span><span style="text-transform:uppercase;"><i>: contains the
description of all the information (data, documents, …) that have to be transferred, and how this information is organized on the producer side</i></span></div>
<div><span style="text-transform:uppercase;">6.1.3</span> <span style="text-transform:uppercase;">Model OF OBJECTS For transfer and sip constraints</span></div>
<div> <span style="text-transform:uppercase;"><i>contains the description of the mot and the sip types and sequencing constraints</i></span></div>
<div><span style="text-transform:uppercase;">6.1.4</span> <span style="text-transform:uppercase;">sips</span></div>
<div> <i>Contains the description if SIP IMPLEMENTATION AND TRANSFER</i></div>
<div> <i>Contains an example of SIP manifest.</i></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>___________________________________________________________________________________________________________</div>
<div><b><u>2. GREEN BOOK</u></b></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> <font face="Calibri" size="2"><span style="font-size:11pt;"><b>2.2 </b></span></font><font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>Test cases review</u></b></span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b><u>2.2.3 ESA-SAFE test case</u></b></div>
<div>The 2 models have been shown during the 19-20 March LTDP meeting.</div>
<div>Exchanges between CNES, Gael and ESA on data sets.</div>
<div>First version of the green book part -> to be first reviewed by Daniele and Stephane, then send to the group.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>==> <u>Action Daniele (with Stephane)</u>: review the ESA SAFE test case, then send it to the group.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> <font face="Calibri" size="2"><span style="font-size:11pt;">LTDP actions (from 7th November meeting)-> </span></font><font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>closed</u></b></span></font><font face="Calibri" size="2"><span style="font-size:11pt;">
during the 19-20 March meeting</span></font></span></font></div>
<table width="790" style="width:474.3pt;margin-left:66.5pt;">
<col width="32" style="width:19.5pt;">
<col width="87" style="width:52.5pt;">
<col width="109" style="width:65.55pt;">
<col width="561" style="width:336.75pt;">
<tr height="32" style="height:19.35pt;">
<td><font face="Times New Roman" size="2"><span style="font-size:9pt;">25.3</span></font></td>
<td><font face="Times New Roman" size="2"><span style="font-size:9pt;">CNES/GAEL</span></font></td>
<td><font face="Times New Roman" size="2"><span style="font-size:9pt;">LTDP_WG#26</span></font></td>
<td><font face="Times New Roman" size="3"><span style="font-size:12pt;">Model the SIP Data Objects at the level of SAFE Metadata and Data Object in order to allow the transfer of sub-parts of SAFE products in different SIPs</span></font></td>
</tr>
<tr height="32" style="height:19.35pt;">
<td><font face="Times New Roman" size="2"><span style="font-size:9pt;">25.4</span></font></td>
<td><font face="Times New Roman" size="2"><span style="font-size:9pt;">ESA/PS</span></font></td>
<td><font face="Times New Roman" size="2"><span style="font-size:9pt;">End November 2013</span></font></td>
<td><font face="Times New Roman" size="3"><span style="font-size:12pt;">Gather any useful documents to allow the prototype development/tailoring and provide the EO-SIP of ERS for Test.</span></font></td>
</tr>
</table>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b><u>2.3 ISEE1-2 test case</u></b></div>
<div>Test case nearly finished.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Mail sent by Don 5th May "Partial update for Section 6.1": material for "ISEE - a typical use case"</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>MM: the history of the test case is not useful in the Green Book (was ok in the yellow book). Needs to show clear test cases -> highlight what the test case brings. </div>
<div> </div>
<div>DB: this test case shows the main features of the PAIS. Could have interest showing the differences between how the data are organized on the Producer side, how the data are modeled in the MOT (intermediary repositories may not be modeled with groups),
how they are gathered in SIPs?</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: the attached files (descriptors …) could be put at the end of each specific test case part, and then at the end we'll see how to organize the whole document gathering the different test cases.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b><u>2.4 COROT test case</u></b></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Daniele explains that CNES is pushing to get the CoRoT L0 data use case (from Daniele and Stephane) – for information this has to be finished by 13 May to get a chance to be used for L1 data.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b><u>2.5 METS test case</u></b></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Daniele had a meeting (9 April) with BNF that could help building a METS implementation of SIPs (documents).</div>
<div>Daniele introduces the need from BnF of transferring references to objects instead of the target objects themselves.</div>
<div>Stephane: this is ok for XFDU</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>=> <u>Action Stephane</u>: Provide example of XFDU with referenced data objects (remote URL or URI)</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Don finds a priori relevant</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Decision: Nothing to do on that topic until further inputs from Bn</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><b><u>2. PDS4 test case </u></b></div>
<div> </div>
<div>Mail sent by Mike (5h May): 2 figures and text for section 6.3 "Planetary Data System - a non XFDU implementation"</div>
<div> </div>
<div>Discussion on figure "PDS4 Bundle and Collection linkages": this is the current PDS4 Bundle description. </div>
<div>Data are localized via URN.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>MM: this figure is an overview of what the PDS4 bundle looks like. Same for every PDS archive. The test data sent before conform to this generic figure.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Figure "PDS4 SIP Organization"</div>
<div>MM: for NSSDC, show that Manifest is better than bundle level.</div>
<div> </div>
<div> </div>
<div>Mike has sent a complete email to Daniele concerning the CNES PAIS software (issues, context and associated files).</div>
<div>For the moment, Daniele is looking for a MAC machine to re-play the scenario in order to be able to undrestand the problems.</div>
<div>Mike will try it on a PC.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>=> <u>Action Daniele</u>: deliver the CNES proto software to John (ASAP)</div>
<div> </div>
<div><font face="Consolas" size="2"><span style="font-size:10.5pt;">There was a brief discussion of Mike’s e-mail (4th December) addressing the PDS4 Bundle organization and Don’s e-mail response (19th December) with possible modeling options. Mike agreed that
a hierarchy is a requirement for a bundle. Don gave two options. The first is a single Collection Descriptor holding a single Transfer Object, where the ‘group’ capability of the TO is used to completely model the bundle with the option of cutting off the
modeling at any point by use of the ‘undescribed’ attribute. This approach would be consistent with past PDS/NSSDC practice of transferring a PDS volume to NSSDC with the only requirement on NSSDC being the ability to return the volume unaltered. In other
words, PDS did not expect NSSDC to look into the volume and provide any services, such as replacement, at a lower level of granularity. The second option would be to model the bundle as composed of multiple Transfer Objects under multiple Collection Descriptors.
For example, there would be a set of Collection Descriptors corresponding to the PDS4 standard named collections, and under each of these there would be Transfer Objects and possibly more Collection Descriptors. There are a lot of possibilities for how the
resultant model might look. The advantage of modeling a bundle as consisting of multiple TOs is that it facilities replacement at the TO level, rather than the whole bundle, if that becomes a requirement. Regardless, it should not be too difficult to have
PDS4/NSSDC specific software what would start from a basic bundle model and then create a complete MOT by examining an existing bundle. It could be integrated with a SIP builder, but it would probably be preferable to have the MOT exchange with NSSDC prior
to any SIP exchange to reduce confusion and ensure both parties were ‘on the same page’.</span></font></div>
<div><font face="Consolas" size="2"><span style="font-size:10.5pt;"> </span></font></div>
<div><font face="Consolas" size="2"><span style="font-size:10.5pt;">Don agreed to look at Mike's example Descriptors to see how they might fit into the above options.</span></font></div>
<div> <font face="Consolas" size="2"><span style="font-size:10.5pt;"> </span></font></div>
<div><font face="Consolas" size="2"><span style="font-size:10.5pt;">==> <u>action Mike</u>: send samples of data </span></font></div>
<div> </div>
<div>What could really help in the use of the PAIS by the PDS, is a proposal of implementation without use of XFDU. To be done.</div>
<div>Suggestion from John: use XFDU, and then an XSLT style sheet to translate into another language (to be confirmed, not sure my understanding was correct).</div>
<div> </div>
<div>A PDS product = a Transfer Object.</div>
<div>A bundle = PDS tree data set. The size of the bundle is 1.7 Go, but files inside are quite small, around 250 ko).</div>
<div> </div>
<div>==> <u>Action Stephane</u>: propose a SIP implementation without XFDU</div>
<div> </div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> <font face="Calibri" size="2"><span style="font-size:11pt;">==> </span></font><font face="Calibri" size="2"><span style="font-size:11pt;"><u>action all</u></span></font><font face="Calibri" size="2"><span style="font-size:11pt;">:
send comments on Mike's information on PDS4 sample (email 30th October)</span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>22 April telecon: From file : met_abstract_sip_manifest.xml</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>MM: The file is a <u>flat</u> list of PAIS elements from SIP Model (PAIS BB §6) and some elements deriving from XMAN (PDS4).</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: sent a tc5-pds4-20140401.pdf providing an example of Non-XFDU SIP implementation also reusing the SIP Model elements from PAIS BB §6, but with a structure of nested elements.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>DS: reminds that nesting is not mandatory with respect to the PAIS BB §5 abstract SIP model. The structure of the manifest may depend from the context and what the Producer and the Archive actually want to convey.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: agrees that the provided example(s) are not implementing the PAIS BB §5 from scratch but are all reusing the SIP Model elements built for XFDU but getting rid of the XFDU elements. This may be confusing.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: the elements of the SIP Model built for XFDU require a nested structure, at least to identify to which Group occurrence a Data Object belongs to, or to which Transfer Object occurrence a Group instance belongs to. Alternate elements could have allowed
a flat structure as for XMAN.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>WG: The WG agrees that this in-between implementation may be confusing in the GB and a fully independent implementation should be preferred.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>WG: agrees that a table, a checklist or any other means that could help a user validating./tracking the level of implementation could be helpful in the GB e.g. is the Goup ID identified, is the SIP ID provided, other IDs, MIME types, etc.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>__________________________________________________________________________________________________________</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> 2. <font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>GREEN BOOK</u></b></span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>The Green Book has been split into several files, one for the core, and one per test case.</div>
<div> </div>
<div>=> <u>Action Stephane</u>: provide a description of the document breakdown and links to the shared repository</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> <font face="Calibri" size="2"><span style="font-size:11pt;"><b>2.3 </b></span></font><font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>Core document</u></b></span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Section 4.1.1 reviewed (ok)</div>
<div>Tabular representation is welcome but question remains about their systematic use (need an XML version in annex ?)</div>
<div> </div>
<div>CCSD0014: equivalent to TO Descriptor, and CCSD0015: equivalent to Collection Descriptor</div>
<div> </div>
<div>==> <u>Action Stephane</u> from MM: explain more the CCSD0015: how it is registered and reference where more information could be found on that subject</div>
<div> </div>
<div>Don: descriptorModelID has to be changed on any XSD change (specialization), the Archive has to maintain the versions</div>
<div> </div>
<div>Section 4.6.1 about PAIS XSD description should remain here for the time being</div>
<div> </div>
<div>John: The SANA registry is supposed to reference the (latest ?) PAIS XSD only (TBC). It is however sure that it should not contain any other resource e.g software, XML examples, etc.</div>
<div> </div>
<div>« open » enumeration technique is cumbersome (TBC)</div>
<div> </div>
<div>==> <u>Action (All):</u> table in section 4.6.4 should be reviewed for (during) next telecon</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Comment from previous telecons on method </div>
<div>* (Daniele): there are steps that conform to the PAIMAS process (first model, SIP constraints, then transfer and validation).</div>
<div>* Link between the data base on the Archive side, and the PAIS XML elements: example on how to match both (core document, test case?).</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>The following paragraph will be suppressed if ok:</div>
<div><font size="2"><span style="font-size:10pt;"><b><u>XML namespace for PAIS </u></b></span></font></div>
<div> <font color="#1F497D"> </font></div>
<div>John suggested that we pass the proposal on namespaces by SANA and Nestor and Peter as XML Co-chairs to make sure they agree.</div>
<div> </div>
<div>==> <u>action Stephane (20130821)</u><font color="#1F497D"><b><i>: </i></b></font>send proposal on namespace to SANA, Nestor and Peter, and ask if they have any objection to our proposal. </div>
<div><font size="2"><span style="font-size:10pt;">Use previous email sent by John to introduce Stephane in the group.</span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>It is agreed that not all positions where a pais :any element are possible have to be documented in the GB. Only a few example are necessary or even one.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>More concrete example should be provided than the abstract « foo »/« bar » currently proposed. Typical example would be a Collection holding a pais :any with the author of the descriptor, the Collection name/ID in the Producer semantic, or anything else
that could be specific to the Producer or the Archive side but not provided in the PAIS definitions.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>For time constraints, the WG jumped to the section 4.6.4 of the draft GB.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: Reminded that « true » restrictions of XML Schema guarantees that the original PAIS XML Schema’s rule are still applicable. Any instance following a restriction follows the original ones.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: The use of restrictions does not impose any system to use the derived PAIS schemas. Therefore, the restricted schemas have not to be shared with any user of the produced SIPs. The project specific schemas could even be discarded without losing control
of the produced SIPs.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>=> D – (DS) The rightmost column of the table in §4.6.4 shall be renamed « Restriction » instead of « Content »</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>MM: It is not clear that this table should be kept in that form or discarded at the end, but the target should not spend too much pages on that topic.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>WG: restrictions may be interesting for implementers and as such should be documented, but it is not clear if this should be proposed as a recommendation or a best practice.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: reminded that restricting elements such as the maxOccurrence’s should be a recommended practice since it can be very difficult to implement interoperable software exchanging elements of xs:nonNegativeInteger type.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: proposed to add prepared templates of restricting XML Schemas in annex. Something that could help implementers to quickly setup the restrictions of their needs.</div>
<div>WG: adding XML Schema’s in annex may not be so helpful because cut and paste from PDF may be very cumbersome.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>=> D – (JG) these XSD shall be placed side to the originals.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>SM: The problem is similar to other GB resources as the use case descriptors or the software prototypes.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>___________________________________________________________________________________________________________</div>
<div> </div>
<div><b><u>Preservation process </u></b></div>
<div> </div>
<div>DB: LOTAR representative is ok with "preservation", but not with "curation" (this word is not used in the community).</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>MM: links should be made between MTDP and warehousing. Not clear with the structure of the process for the moment.</div>
<div> </div>
<div>Discussion on terminology: preservation vs curation.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>LTDP definitions: </div>
<ul style="margin:0;">
<li style="margin-top:5pt;margin-bottom:5pt;"><b>Preservation:</b> aims at the generation of a single, consistent, consolidated and validated <b><i>“EO Missions/Sensors Dataset” </i></b>and at ensuring its long term integrity, discovery, accessibility and usability.
It is focused on an individual Mission/Sensor or on a multi-mission Dataset (when one Master Dataset is made up of data coming from different missions/sensors) and tailored according to its specific preservation/curation requirements. It consists of all activities
needed to ensure “EO Missions/Sensors Dataset” bit integrity over time and to optimize (in terms of format and coverage) its (re)use in the long term (e.g. through metadata and catalogue improvement, algorithms evolutions and related (re)processing, linking
and improvement of context/provenance information).</li><li style="margin-top:5pt;margin-bottom:5pt;"><b>Curation: </b>aims at establishing and increasing the value of <b><i>“EO Missions/Sensors Datasets” </i></b>over their lifecycle, at favouring their exploitation through the combination with other Datasets and
at extending their user base. It includes the activities for the definition of the preservation objectives, for the coordination and management of Data Time Series and Collections (e.g. from similar sensor family) in support to specific applications. It includes
international cooperation activities</li></ul>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>OAIS definitions:</div>
<div><b>Long Term Preservation</b>: The act of maintaining information, Independently Understandable by a Designated Community, and with evidence supporting its Authenticity,</div>
<div>over the Long Term.</div>
<div><b>Authenticity</b>: The degree to which a person (or system) regards an object as what it is purported to be. Authenticity is judged on the basis of evidence.</div>
<div> </div>
<div>Authenticity: in the sense of "original". This is not crucial in the domain of scientific data, but is an issue. Integrity could be a way to prove authenticity.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>We note that the LTDP definitions are not clear nor completely coherent. There is a mixture of both preservation/curation concepts in both definitions.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>Furthermore, the group thinks that the term "curation" used in the LTDP definition does not fit the usual usage, another term should be used. The sens is nearer of knowledge management. </div>
<div>Daniele will send tomorrow a summary of her comments.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;">=> <font face="Calibri" size="2"><span style="font-size:11pt;"><u>Action Daniele</u></span></font><font face="Calibri" size="2"><span style="font-size:11pt;">: ask David for preservation/curation
definition.</span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;">=> <font face="Calibri" size="2"><span style="font-size:11pt;"><u>Action all</u></span></font><font face="Calibri" size="2"><span style="font-size:11pt;">: give comments and proposals
as input for the LTDP terminology and steps of workflow. -> </span></font><font face="Calibri" size="2"><span style="font-size:11pt;"><b><u>for Monday at the latest.</u></b></span></font></span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><u>Previous discussion:</u></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>To be done: analyse and suggest, at different stages of the project (during data lifecycle), what should be done on an archiving point of view.</div>
<div> </div>
<div>Example of main issue: keep documentation up to date (when changes in formats, processing, … are made on the data).</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>The LTDP has written a document "PDSC" (Preservation Data Set Content), explaining what kind of information (data, software, documents, …) should be collected and at what step of the project.</div>
<div> </div>
<div>The subject is wide, Mike asks to focus on specific parts.</div>
<div> </div>
<div>Daniele explains her point of view: develop a "model" (magenta book) gathering all the basic components of the preservation activity (selection and appraisal, data and metadata preparation, access, maintenance …) that should cover all the data lifecycle
(even when data don't exist), in order to be able to answer the following question: what should be done from the beginning till the end to be able to preserve data, and at what moment? This should be done in a generic way, making links on standards related
to basic components when they exist.</div>
<div> </div>
<div>Suggestion to ask Barbara Sierman of existing works concerning this topic. Mail sent the 7/02 by Daniele.</div>
<div> </div>
<div>==> <u>Action Daniele</u>: write and send more precise elements on this process to the group.</div>
<div> </div>
<div>==> <u>Action all</u>: send comments.</div>
<div><font color="red"> </font></div>
<div>Nestor will send for the new project approval once the ¨PAIS BB has been published.</div>
<div> </div>
<div>Daniele underlines the need for CNES and LTDP group. CCSDS expertise will be very important.</div>
<div> </div>
<div>The PDS has its internal process ; for other agencies (particularly the LTDP member agencies) this process doesn't exist and is required.</div>
<div> </div>
<div>Question on how to make the link between a global process and the PAIMAS phases.</div>
<div> </div>
<div>20131030 Don's email and following discussions:</div>
<div>Don: The process could be focussed on the Archive point of view, and seen an internal OAIS issue for workflow, using then more OAIS concepts.</div>
<div>The "provenance" is practically a big issue, going back to the original information.</div>
<div>"Reprocessing, curation, stewardship" could be maped with OAIS migrations, new versions, …</div>
<div> </div>
<div>Update procedures exist at NSSDC.</div>
<div> </div>
<div>Daniele: appraisal should be the starting point. Workflow, on the Archive side, could begin early in a space project, even when data don't yet exist ; link with the Archive side of the PAIMAS.</div>
<div> </div>
<div>=> <u>action all</u>: exchange on high level process (3 main steps preparation/preservation/maintenance) and links with PAIMAS phases for return to the LTDP group.</div>
<div> </div>
<div>==> <u>action Daniele</u>: follow the work of LTDP group on preservation process, and send all available information to the DAI group on this subject.</div>
<div> </div>
<div>Need for return on the preservation process from all.</div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div>___________________________________________________________________________________________________________</div>
<div><b><u>Other subjects </u></b></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"><br>
<font face="Calibri" size="2"><span style="font-size:10pt;"><b><u>OAIS Magenta Book (French version)</u></b></span></font><font face="Calibri" size="2" color="#1F497D"><span style="font-size:10pt;"><b> </b></span></font></span></font></div>
<div> </div>
<div>Daniele has received the complete updated French version.</div>
<div>Complete validation to be performed now (text and figures)</div>
<div>This version will be also validated by the French National Archives.</div>
<div>Due to the amount of work on the PAIS, and priority to the PAIS green book, this will be treated after.</div>
<div> <font color="#1F497D"> </font> </div>
<div><b><u>XML schema for DEDSL </u></b></div>
<div>Seems possible for CNES to write the document on the model on the existing other DEDSL standards. At CNES, XML schema for DEDSL is already created and implemented.</div>
<div>Prototypes: CNES has already tested it on operational tool. This could play the role of prototype, and this could be enough.</div>
<div> </div>
<div>Nestor explained John that a 2nd prototype is required.</div>
<div><font color="#1F497D"> </font></div>
<div>A possibility could be to produce not a blue book, but a document that won't required 2 prototypes (orange book). To be more discussed.</div>
<div> </div>
<div><font color="#1F497D">____________________________________________________________________________________________</font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
<div><font face="Times New Roman" size="3"><span style="font-size:12pt;"> </span></font></div>
</span></font>
</body>
</html>