Transcript PV2009 An interoperable architecture using AMDA

An interoperable architecture
using the CDPP/AMDA service
and the SPASE model
Michel GANGLOFF CNRS/CESR/CDPP
17/07/2015
PV2009 MADRID
1
Introduction
A use case of Virtual Observatory with a science tool (AMDA)
and a metadata model (SPASE)
This work was done for the EuroPlaNet/IDIS Plasma Node
17/07/2015
PV2009 MADRID
2
Overall architecture of a Virtual Observatory
Portals,User Interfaces,Tools
SPASEQL
SIAP,ADQL
Responses
CDF,ASCII,FITS…
VOTable
Queries
DATA ACCESS LAYER
HTTP ,Web Services
Registries
Data Models,Semantics,Metadata
Resource
Discovery
Catalogs, Archives, Collections, Models
17/07/2015
PV2009 MADRID
3
A Virtual Observatory
•
One of the goals of IDIS is to provide a Virtual Observatory
environment for Planetary sciences
•
Access to remote data from software tools is essential in a Virtual
Observatory environment
•
This access should be made in a standard way to avoid duplicating
efforts in software development
•
To reach this goal, we developed a prototype of remote data access
from AMDA
17/07/2015
PV2009 MADRID
4
A Use Case
Registry prototype
Searching the resource location
(MAPSKP, HST aurora,
VEX, ACE)
Request of
Local
database
resource
location
MAPSKP
USER
AMDA/Planeto
Science prototype
Access, extraction of the
targeted data (distant or local)
VEX-MAG
Graz
Integrated analysis
17/07/2015
PV2009 MADRID
HST
5
Two successive versions implemented:
• One with a specific interface for each
source of data
• One with a standard interface
17/07/2015
PV2009 MADRID
6
AMDA/IDIS Version 1
AMDA
SKR
System
CDAWeb
Local
Database
Specific
interpretors
17/07/2015
MAPSKP
THEMIS
Web-services:
Content of the database?
Get the descriptors
Get data (url list)
PV2009 MADRID
7
AMDA/IDIS Version 2
: SPASE compliant
SPASE layer
SPASE metadata translator
VEX-MAG
AMDA
MAPSKP
System
SKR
Local
Database
THEMIS
CDAWeb
Any database including a SPASE based interoperability layer can be used by AMDA
17/07/2015
PV2009 MADRID
8
What is needed to implement a standard interface ?
• A standard data model
• Descriptions of resources , compliant with
this model
• A Registry
• An interface to the Registry
17/07/2015
PV2009 MADRID
9
Hierarchical view of the Spase model
17/07/2015
PV2009 MADRID
10
EPN Plasma Node Registry of Data Products
– Set of XML descriptors of planetary plasma data
(MAPSKP, VEX, MEX), down to the physical parameter
level
– Compatible with the SPASE model
– eXist database (XML native)
– Associated Web accessible Search Engine
• Measurement Type
• Region
• Time
17/07/2015
PV2009 MADRID
11
Plasma Node Registry Search Web interface
Possibility to select a measurement type
17/07/2015
PV2009 MADRID
12
Architecture
AMDA
Build data tree
data tree
getAvailableData
(measurementType=
ThermalPlasma)
Build parameters
spase descriptor
getDatasetInfo
URLs of granules
getDatasetURLs
Wget(datasetURLs)
SOAP WEB SERVICES
XQUERY
Registry
Remote
Spase XML Descriptors
Database
describes
(metadata)
(data)
Daily update
17/07/2015
PV2009 MADRID
13
An auxiliary XML descriptor is used to describe information
needed to access the tabular data in an ASCII file
<dataset xml:id="MAG_KG">
<parameter xml:id="VECTOR">
<data_type>FLOAT</data_type>
</parameter>
<parameter xml:id="MAGNITUDE">
<data_type>FLOAT</data_type>
</parameter>
</dataset>
17/07/2015
PV2009 MADRID
14
An example of Data File : Magnetic Field in KG Coordinates
Parameter key
Field 0
Time [UTC]
2004-182T00:00:58.000
2004-182T00:01:58.000
2004-182T00:02:58.000
2004-182T00:03:58.000
17/07/2015
Field 1
Field2
Field3
Field4
Bx
By
Bz
|B|
0.897
0.954
0.897
0.897
5.648
5.669
5.648
5.648
-2.254
-2.222
-2.254
-2.254
PV2009 MADRID
6.147
6.163
6.147
6.147
15
Use « ParameterKey » to
read Elements
17/07/2015
PV2009 MADRID
16
Save parameter to user’s workspace
Select data on a remote server
17/07/2015
PV2009 MADRID
17
Conclusion
SPASE is a good candidate to describe and access remote
plasmas physics data with AMDA
More work is needed to handle more complex queries
17/07/2015
PV2009 MADRID
18