Plasma Node demonstrators 1/Registry : –Set of XML descriptors of planetary plasma data (MAPSKP, VEX, MEX ) –Compliant with the SPASE data model –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

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

AMDA Automated Multi-Dataset Analysis (  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, …)

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

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

Mapskp Registry Search Engine : 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

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

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

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.

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

VSPO : an example of VxO VSPO: Virtual Space Physics Observatory Could be a model for the plasma node(at least) ?

VSPO metadata registry metadata registry based on the eXist XML databaseeXist XML database metadata registry accessed via: –VSPO –database browser –OAI-PMH : VSPO's OAI-PMH Repository instance is based on the OAIcat software: to harvest the registry :