[Moims-dai] Minutes of today telecon (9th January)

Fri Jan 9 17:54:15 UTC 2015

Hi all,

Please find below the minutes of today telecon. Feel free to correct or comment.

Next telecon:
Friday 30th January (15h EU time, 9h US time-Washington)

Agenda for next telecon (2 different parts with corresponding timing):
1st hour:
* Corot test case
* Core GB
* METS test case
2nd hour:
* ICP

If available, proposal to use Dave's new number for the sound:
Dave Williams
Telecon information
+1-844-467-6272      USA Toll Free
+1-720-259-6462      Others
Passcode:    841727

To view screen and documents, please connect to the following :
        https://webconference.cnes.fr/ccsds_2015_jan_30/

Attached is the updated list of Stephane's action (John, could you please update the Action table with it?)

Best regards,

Daniele
____________________________________________________________________________
9th January meeting minutes

DB: Daniele Boucon
DG: David Giaretta
DS: Don Sawyer
ES: Esther Conway
JG: John Garrett
MM: Mike Martin (NASA)
RD: Robert Downs
SM: Stephane Mbaye
SR: Stephane Reecht
BC: Bertrand Caron (BnF)
PT: Philippe Tramoni (BnF)
WG: all

D=Decision, A=action (other = discussion)

1. 1  Information Curation Process -ICP
ICP is made up activities or grouping of activities, divided into levels and sub levels. Risk management is one of them. ICP should include a kind of roadmap, pointing out stages and where responsibility is handed over, instead of describing in details each activity.
Where OAIS applies should be identified  (from last minutes).

MM: need for a framework showing how the activities fit together. The LTDP document recovers areas of OAIS + PAIS, thus making a redundancy with other standards.

DG + DB: the LTDP document is at the starting point of the ICP. We need to be practical and to focus on the scope.

All: LTDP document in the scope of EO and is very specific to EO. CCSDS needs to enlarge this scope to be generic with a broader set of activities.

EC (information sent yesterday by email on risk and planning management): need to take into account the risk, and a more dynamic iterative system.

D => (all): framework, wider than EO domain, in the form of a draft document describing high level steps and referring to a number of area specific standards to be produced.

2 METS test case

Also see emails sent by SR the 7th and 9th January

New version sent the 3rd December for review and discussion. Updates presented by SM (homogenization of terms in the text and in the implementation).

BC: presentation of the new PAIS-METS Manifest. 3 possibilities: minimal PAIS implementation (1st Manifest), complete PAIS implementation, PAIS implemented through METS -> the one chosen and presenter. Places for the different PAIS elements:

sip Global Info -> digital provenance info
sipTransferObject, sipTransferObjectGroup, sipDataObject -> technical MD (amdsec)

A=>(all): send comments on the proposed implementation, and other material sent by BnF.

3 DEDSL XML schema
Planning sent by Daniele yesterday validated by the group.
DB will finalize the project on the CWE framework with resources (NASA to be added as contributor).
The idea is to have a first document for next meeting.

4 Corot Test case
Not discussed, but updated descriptors and SIPs sent by SM to DB today.
DB will test these files with the tools.

Actions review

Updated actions will be sent separately by JG.

End of 9th December meeting minutes
___________________________________________________________________________________________________________
Part of historical minutes to be reminded (slightly updated the 9th Januaru 2015)
__________________________________________________________________________________________________________
 2. GREEN BOOK

        2.2 Core document

Section 4.1.1 reviewed (ok)
Tabular representation is welcome but question remains about their systematic use (need an XML version in annex ?)

CCSD0014: equivalent to TO Descriptor, and CCSD0015: equivalent to Collection Descriptor

==> Action Stephane from MM: explain more the CCSD0015: how it is registered and reference where more information could be found on that subject

Don:  descriptorModelID has to be changed on any XSD change (specialization), the Archive has to maintain the versions

Section 4.6.1 about PAIS XSD description should remain here for the time being

« open » enumeration technique is cumbersome (TBC)

Comment from previous telecons on method
* (Daniele): there are steps that conform to the PAIMAS process (first model, SIP constraints, then transfer and validation).
* Link between the data base on the Archive side, and the PAIS XML elements: example on how to match both (core document, test case?).

The following paragraph will be suppressed if ok:
XML namespace for PAIS

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.

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.

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.

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.

=> D - (DS) The rightmost column of the table in §4.6.4 shall be renamed « Restriction » instead of « Content »

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.

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.

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.

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.
WG: adding XML Schema's in annex may not be so helpful because cut and paste from PDF may be very cumbersome.

=> D - (JG) these XSD shall be placed side to the originals.

SM: The problem is similar to other GB resources as the use case descriptors or the software prototypes.

___________________________________________________________________________________________________________

Preservation process

DB: LOTAR representative is ok with "preservation", but not with "curation" (this word is not used in the community).

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.

Example of main issue: keep documentation up to date (when changes in formats, processing, ... are made on the data).

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.

Suggestion to ask Barbara Sierman of existing works concerning this topic. Mail sent the 7/02 by Daniele.

Daniele underlines the need for CNES and LTDP group. CCSDS expertise will be very important.

The PDS has its internal process ; for other agencies (particularly the LTDP member agencies) this process doesn't exist and is required.

Question on how to make the link between a global process and the PAIMAS phases.

20131030 Don's email and following discussions:
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.
The "provenance" is practically a big issue, going back to the original information.
"Reprocessing, curation, stewardship" could be maped with OAIS migrations, new versions, ...

Update procedures exist at NSSDC.

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.

___________________________________________________________________________________________________________
Other subjects

OAIS Magenta Book (French version)

Complete validation to be performed now (text and figures)
This version will be also validated by the French National Archives.
Due to the amount of work on the PAIS, and priority to the PAIS green book, this will be treated after.

____________________________________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20150109/7b8ed418/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccsds-pais-sm-action-status-20150109.pdf
Type: application/pdf
Size: 275384 bytes
Desc: ccsds-pais-sm-action-status-20150109.pdf
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20150109/7b8ed418/attachment.pdf>