1 / 16

Plasma Node demonstrators

Plasma Node demonstrators. 1/Registry : Set of XML descriptors of planetary plasma data (MAPSKP, VEX , MEX ) Compliant with the SPASE data model 1.2.0 eXist database (native XML, parameter level) Search engine ( measurement type, region)

evette
Download Presentation

Plasma Node demonstrators

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. Plasma Node demonstrators 1/Registry : • Set of XML descriptors of planetary plasma data (MAPSKP, VEX, MEX) • Compliant with the SPASE data model 1.2.0 • eXist database (native XML, parameter level) • Search engine ( measurement type, region) • Goals: demonstration and experimentation (standard versus user requirements, SPASE extensions, …) 2/Science : • Based on AMDA • Use remote data (MAPSKP, VEX-MAG, HST) and local data • High level tools and functionalities • Goals: demonstration and experimentation

  2. Prototype application on use cases Request of resource location Registry prototype Searching the resource location (MAPSKP, HST aurora, VEX, ACE) Local database MAPSKP USER AMDA/Planeto Science prototype Access, extraction of the targeted data (distant or local) Integrated analysis VEX-MAG Graz HST

  3. AMDAAutomated Multi-Dataset Analysis (http://cdpp-amda.cesr.fr) • Multi-spacecraft and multi-instrument data • Visualisation • User defined parameter computation • Standard model computation • Data and computed parameter extraction • Event list production and management • Automated and semi-automated (visual) search on the content of the data • Access to external databases (now: CDAWeb, MAPSKP , next: SKR, VEX-MAG, HST images, MEDOC solar data, …)

  4. AMDA/”External Data” SPASE descriptors Others SPASE Connector MAPSKP SPASE descriptors AMDA CDPP (Sitools) System Local Database CDAWeb others

  5. Mapskp registry interface AMDA Build data tree Build parameters data tree spase descriptor URLs of granules getAvailableData getDatasetInfo getDatasetURLs Wget(datasetURLs) WEB SERVICES SOAP XQUERY Registry MapsKP server Spase XML Descriptors describes (data) (metadata) Daily update

  6. Mapskp Registry Search Engine • Available @ : http://cdpp-spase.cesr.fr:8800/exist-1.1.1/xquery/PlasmaNodeRegistry.xql • Search criteria: • Time span • Measurement type • Observed region • Resource type ( numerical data , display data or catalog) • Response: • Spase Xml descriptor • Possibility to use XSL style sheet for better presentation

  7. Plasma Node Registry: Next step • Implement an OAI interface (to be harvestable by other VOs) • Add metadata (HST,VEX, …)

  8. IDIS Atmosphere Node Small Body Node Surface/ Interior Node Plasma Node IDIS Geological Data Geological Models Mineralogical Data Abundance models Atmospheric Composition Data Spectroscopy Data Magnetospheric Models Plasma Data Dust Data Rings Data User Comet Data Implement a Registry for each node ? Which data model ?  Tasks for FP7

  9. Architecture of IDIS registries • Inventory of resources: to what level ? • Need at least « measurement type » to implement a use case • For this level of metadata, it is mandatory to use a data model • Current status not sufficient for FP6 ? • Final goal: up to the « parameter » level • For the current inventory: • it is not necessary to have a distributed architecture ( one search engine + registry on every node) • It is not necessary to use the SPASE model to describe high level resources ( person, repository,…) (see IVOA VOResource ) • To implement harvestable registries, it is necessary to use a data model to describe resources  unreachable in the FP6 context. • For FP7 we have planned to establish at least one model and dictionnary for EuroPlaNet: • Study the existing models (IPDA, IVOA,SPASE) to know whether they fit the requirements of IDIS • One data model for IDIS, and a dictionnary for each node ? Several models? These questions requier a full analysis and experimental study.

  10. What is necessary to implement a searchable/publishing Registry? • A data model : SPASE,IVOA, … • A data dictionary • Tools to edit XML descriptors • Schemas to validate the descriptors • A database to store the descriptors • Science and use cases to implement the search interface • Implement OAI interface to be harvestable

  11. VSPO : an example of VxO VSPO: Virtual Space Physics Observatory http://vspo.gsfc.nasa.gov/websearch/dispatcher Could be a model for the plasma node(at least) ?

  12. VSPO metadata registry • metadata registry based on the eXist XML database • metadata registry accessed via: • VSPO • database browser http://vspo.vs3o.aquilent.com/exist/admin/admin.xql • OAI-PMH : VSPO's OAI-PMH Repository instance is based on the OAIcat software: http://vspo.vs3o.aquilent.com/oaicat. to harvest the registry : http://vspo.vs3o.aquilent.com/oaicat/OAIHandler

More Related