1 / 23

Heppenheim

Heppenheim. Producer-Archive Interface Specification Prototype for the MOT design and for the Transfer follow-up. Contents. Tool presentation MOT design Validation of XFDUs Transfer follow-up Use cases CDPP use case presentation : Wind waves TNR L2 data

fulton-guthrie
Download Presentation

Heppenheim

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Heppenheim 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 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).

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

  19. 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

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

  21. Start of demonstration

More Related