1. Heppenheim Prototype for the MOT design and for the Transfer follow-up
Producer-Archive Interface Specification
Prototype for the MOT design and
for the Transfer follow-up

2. Contents Tool presentation MOT design Validation of XFDUs
Transfer follow-up
Use cases
CDPP use case presentation: Wind waves TNR L2 data
NASA use case: NARA USGS Ag-Chem Data
Conclusion
Demo

3. Tool presentation Two parts
MOT creation and visualisation (during the Formal Definition Phase)
Design of the MOT structure
Easy filling up of Descriptors and validation
Centralized information
MOT visualisation
With easy GUI
SIP validation (SIP Content Types, SIP sequencing constraints, Transfer Object structure)
And: Transfer follow-up and visualisation (during the Transfer Phase)
State of the delivered Transfer Objects in the MOT and follow-up detail visualisation
Using the same graphical visualisation

4. Tool presentation: objective
Cover the PAIS requirements:
MOT design
SIP validation and transfer follow-up
Help the Producer and the Archive during the Formal and Transfer Phases:
easy and visual tool
no need for technical requirements (XML form …)
Provide a standard validation

5. Tool presentation 3 kinds of users (rights not implemented yet)
Reader only
No possible modification
MOT designer
MOT structure creation/modification
Descriptors instantiation/modification
Administrator
Producer-Archive Project creation ….

6. Tool presentation: technical characteristics
XSD schema for Descriptor Models
XML files for Descriptors
XAmple, JGraph (Open source)
Requirements
JAVA 1.5
Compatible with different OS (PC, MAC, UNIX)

7. MOT Design The MOT a tree made of nodes and leaves
Node: Collection
Leaf: Transfer Object
each node/leaf is associated with
an XSD descriptor (Descriptor Model)
an XML file (Descriptor)
used during the phases
Formal Definition
Transfer (and Validation)

8. MOT Design: Main functionalities (1/3)
Model structure design
descriptor_ID, title, Descriptor Model using the list of descriptor_model_ID
creation of nodes and first graphical view without the need to give further Object information

9. MOT Design: Main functionalities (2/3)
Descriptors creation
node instantiation (possible to do it in several times with automatic base updates) and validation (XAmple form).
The XML files thus created populate the ingest base (complete view on the nodes of the MOT and the links between these nodes)

10. MOT Design: Main functionalities (2/3)
Descriptors creation
node instantiation (possible to do it in several times with automatic base updates) and validation (XAmple form).
The XML files thus created populate the ingest base (complete view on the nodes of the MOT and the links between these nodes)

11. MOT Design: Main functionalities (3/3)
Graphical representation of the MOT which can be seen and understood by the Producer and the Archive

12. SIP/XFDU validation
Remark: “The PAIS does not address the actual transfer of a SIP nor how the archive does validation upon the received SIP. The extent of such validation will depend, in part, on the details of Descriptor implementations and the level of validation required by the Producer-Archive project.”
Validations are performed on the XFDU manifest (not on the attached Data):
SIP Content Type,
SIP sequencing constraints,
Descriptor content: number of expected Transfer Objects, etc,
Structure of embedded Data Objects,
Conformity between the mime type in the XFDU manifest, and in the Descriptor.

13. Transfer follow-up Same graphical visualisation as the MOT design
Visualisation of the progress, graphical conventions
Progressing (still in transfer)
Terminated (transfer completed)
Number of objects already transferred
(and number of objects to be transferred, if known) on links

14. MOT Icon states and representations
Formal Definition Phase
Transfer Phase
Initialized
Validated
Unvalidated
Initialized
Progressing
Completed N o d e L e a f
Remark: no special icon for errors on Transfer Objects during the Transfer Phase (only validated objects)

15. CDPP use case presentation

16. CDPP use case presentation
Associations
From a Collection to another Collection: association 1.
From a Transfer Object to a Collection: association 2.
From a Transfer object to another Data object (inside a different Transfer Object): associations 3 and 4.
From a Data object (inside a Transfer Object) to another Data object (inside the same Transfer Object): association 5.
3 SIP Content Types
SIP Type 1: one document (the Waves experiment description): delivered once.
SIP Type 2: two documents describing each element of the TNR L2 data, the EAST description and the Waves TNR L2 catalog: delivered once.
SIP Type 3: the TNR L2 data (each Transfer Object contains 2 Data Objects). The number of delivered SIP of Type 3 is unknown at the beginning, and each SIP can contain several TNR L2 data Transfer Objects.

17. CDPP use case presentation
Sequencing constraints
one constraint between SIP Type 2 and SIP Type 3, and no constraint on SIP Type 1:
SIP Type 1 can be transferred at any moment.
SIP Type 2 must be delivered before the first occurrence of SIP Type 3 (The EAST description and the XML catalog schema must be delivered before any TNR L2 data).

19. NASA use case presentation
tgz file
ROOT
USGS Ag-Chem
Collection
NARA
Desc..
ArcInfo
Data
SDTS
Rep.
Ag-Chem
Doc.
Context
Desc.
Rep. file
gz file
Three files
Six files

21. Conclusion
A tool:
easy to install, easy to use, easy to specialize (new Models),
covers the PAIS requirements.
It’s a prototype (needs more checks, other functions must/could be implemented or improved: user rights, error management …).
Implementation strongly linked to:
some PAIS descriptors attributes:
descriptor ID, title, descriptor Model (for the structure of MOT),
all identifiers (for the validation part),
the SIP schema attributes: all attributes (for the validation and transfer follow up),
the XFDU schema: attributes (mime type …) and extensions.
important to agree on the standard Descriptors and the SIP Model to have a PAIS Red Book Version (stable version of the Descriptors)
important to have a stable XFDU schema

22. Conclusion: future architecture
.XSD
DESCRIPTOR MODELS
.XML DESCRIPTORS
Producer
WWW
Archive
SERVER
POT.XML

23. Start of demonstration