Page tree
Skip to end of metadata
Go to start of metadata

Work in Progress

Please don't use this Document for now, we are currently updating it.

 

EPN2020-RI

 

EUROPLANET2020 Research Infrastructure 

H2020-INFRAIA-2014-2015 

Grant agreement no: 654208

 

Document: VESPA-WP6-3-020-TP-v0.1(45)

 

 

 

 

 

Building the resource descriptor for your EPN-TAP service in DaCHS

 

 

 

Date: 2017-11-16

 

Start date of project: 01 September  2015

 Duration: 48 Months

Responsible WP Leader: Stéphane Erard

 

Project co-funded by the European Union's Horizon 2020 research and innovation programme

Dissemination level

PU

Public

  •  

PP

Restricted to other programme participants (including the Commission Service)

  •  

RE

Restricted to a group specified by the consortium (including the Commission Services)

  •  

CO

Confidential, only for members of the consortium (excluding the Commission Services)

  •  

Project Number

654208

Project Title

EPN2020 - RI

Project Duration

48 months: 01 September 2015 – 30 August 2019

Document Number

WP6-task3-020-v0.1

Delivery date

 

Title of Document

Building the resource descriptor for your EPN-TAP service in DaCHS

Contributing Work package (s)

WP6

Dissemination level

PU

Author (s)

Abstract:

 

 

Document history (to be deleted before submission to Commission)

Date

Version

Editor

Change

Status

 

0.0

Initial version

DRAFT 

 

0.1

Added sections "Service Metadata" and "EPNcore Table Definition"

 DRAFT

 

 

 

Table of Contents


Introduction

This document describes how to build your Resource Descriptor (RD) for an EPN-TAP service using DaCHS. The full documentation of DaCHS is available at http://docs.g-vo.org/DaCHS/ref.html, including a section "Anatomy of an RD" that describes the RD structure and syntax in details.

Overall Structure

The RD file is an XML file. The properties of the RD file can be either set up as XML children elements or as attributes of their parent property. The two following examples are equivalent, the first show the attribute syntax, while the second illustrates the XML element child option.

  • Attribute syntax:
<resource schema="my_service">
	[...]
</resource>
  • Child syntax
<resource>
	<schema>my_service</schema>
	[...]
</resource>

The latter syntax is useful when the property has children properties.  

Service Metadata

The first property of an RD is the list of service metadata. They are specified in a series of <meta>[...]</meta> elements. The following <meta> elements should be present in your file:

<meta> element name attributeContentExample
titleThe title of your resource. This is the title of your database. This should be rather explicit, basically, the meaning of the acronym or the short description of the service.
<meta name="title">Nancay Decameter Array observation database</meta>
description

The description of you resource. This is long description. Put here anything that could be useful to understand the content or find the resource with full text search engines. Place yourself in the skin of your fellow scientists when writing this part. This must be understandable by non-specialist scientists

<meta name="description" format="plain">
	Decametric radio observation from Nancay decameter array.
	The Nancay Decameter Array (NDA) at the Station de
	Radioastronomie de Nancay (SRN) is a phased array of 144 
	"Teepee" helicoidal antenna, half of which being Right 
	Handed (RH) polarized and the other half being Left Handed
	(LH) polarized. Four receivers are currently connected to 
	the NDA, sampling data in spectral ranges within 5 to 80 MHz.
</meta>
copyrightThis contains the copyright, rules of use and acknowledgments related to the resource and the data served by the resource. Indicate here the distribution licence if there is one selected. Specify the "rules of use" or "rules of the road", or "data use policy"... You can also give acknowledgment policy and citation rules.
<meta name="copyright">
	Rules of Use:<br/>
	SRN/NDA observations in open access can be freely used for 
	scientific purposes. Their acquisition, processing and 
	distribution is ensured by the SRN/NDA team, which can be 
	contacted for any questions and/or collaborative purposes. 
	Contact email: contact.nda@obs-nancay.fr
	<br/><br/>
	We kindly request the authors of any communications and 
	publications using these data to let us know about them, 
	include minimal citation to the reference and 
	acknowledgements as presented below.
	<br/><br/>
	Acknowledgement:<br/>
	The authors acknowledge the Station de Radioastronomie de 
	Nancay of the Observatoire de Paris (USR 704-CNRS, supported 
	by University d'Orleans, OSUC, and Region Centre in France) 
	for providing access to NDA observations accessible 
	online at http://www.obs-nancay.fr
	<br/><br/>
	Reference:<br/>
	A. Lecacheux, The Nancay Decameter Array: A Useful Step 
	Towards Giant, New Generation Radio Telescopes for Long 
	Wavelength Radio Astronomy, in Radio Astronomy at Long 
	Wavelengths, eds. R. G. Stone, K. W. Weiler, M. L. Goldstein, 
	and J.-L. Bougeret, AGU Geophys. Monogr. Ser., 119, 321, 2000.
</meta>
creationDate

The creation date of the resource descriptor (ISO-8601 formatted)

<meta name="creationDate">2016-03-30T15:52:00</meta>
creator.nameThe name of the creator of the resource (can be a person or an institute)
<meta name="creator.name">Station de Radioastronmie de Nancay</meta>
subjectThere can be as many <meta name="subject"> metadata elements as needed. The values to input here should be taken from the Unified Astronomy Thesaurus when available.
<meta name="subject">Jupiter</meta>
<meta name="subject">Sun</meta>
<meta name="subject">Radio emission</meta>
<meta name="subject">Aurora</meta>
<meta name="subject">Planet</meta>
<meta name="subject">Magnetosphere</meta>
<meta name="subject">Solar Wind</meta>
<meta name="subject">Radio astronomy</meta>
contact.emailThe email address for questions and requests about the service. It is preferable to provide the users with an alias email that points to a one or few persons in your team. Having a real person email here may break the process if that person leaves your institute and you don't update the resource descriptor.
<meta name="contact.name">Laurent Lamy</meta>
contact.nameThe name of the person to contact for questions and requests about the service
<meta name="contact.email">contact.nda@obs-nancay.fr</meta>
contact.addressThe real mail address of the institution or data center that distributes the resource.
<meta name="contact.address">
	Station de Radioastronomie Route de Souesmes, F-18330 Nancay, France
</meta>
referenceURLAn http URL that points to a description of the resource
<meta name="referenceURL">
	http://www.obs-nancay.fr/-Le-reseau-decametrique-.html?lang=en
</meta>
facilityIf you are serving observational data, you can give here the name of the observatory / spacecraft. Note that several names (including acronyms) could be provided in a #-separated list (see example).
<meta name="facility">Station de Radioastronomie de Nancay#SRN</meta>

instrument

If you are serving observational data, you can give here the name of the telescope / experiment / instrument.
<meta name="instrument">Nancay Decameter Array#NDA</meta>
sourceThis should be an ADS bibcode to a paper presenting the resource of the data present in the resource.
<meta name="source">2000GMS...119..321L</meta>
ContentLevelIn general, there are 4 elements of those, with the following values: "General", "University", "Research", "Amateur". You can restrict the list.
<meta name="contentLevel">General</meta>
<meta name="contentLevel">University</meta>
<meta name="contentLevel">Research</meta>
<meta name="contentLevel">Amateur</meta>
typeThe type of resource should be "Catalog" for an EPN-TAP service, as you serve a metadata catalog for your data products.
<meta name="type">Catalog</meta>
coverage

The "coverage" elements can be used to add the electromagnetic spectral band your data are related to. The allowed values are provided in the VODataService specification and are:

  • Radio any wavelength > 10 mm (or frequency < 30 GHz))
  • Millimeter 0.1 mm <= wavelength <= 10 mm; 3000 GHz >= frequency >= 30 GHz.
  • Infrared 1 micron <= wavelength <= 100 microns
  • Optical 0.3 microns <= wavelength <= 1 micron; 300 nm <= wavelength <= 1000 nm; 3000 Angstroms <= wavelength <= 10000 Angstroms
  • UV 0.1 micron <= wavelength <= 0.3 microns; 100 nm <= wavelength <= 300 nm; 1000 Angstroms <= wavelength <= 3000 Angstroms
  • EUV 100 Angstroms <= wavelength <= 1000 Angstroms; 12 eV <= energy <= 120 eV
  • X-ray 0.1 Angstroms <= wavelength <= 100 Angstroms; 0.12 keV <= energy <= 120 keV
  • Gamma-rayenergy >= 120 keV

This property must be declared as a child of the <meta name="coverage"> element, see example.

<meta name="coverage">
	<meta name="waveband">Radio</meta>
</meta>

EPNcore table definition

The EPNcore table should be defined in the RD using the epntap2 mixin. This ensures that your EPN-TAP service is compliant with the EPNcore specification. The epntap2 mixin will be updated as needed via the DaCHS debian package update. If you only plan to use the EPNcore mandatory parameters, your table definition section will be very simple:

<table id="epn_core" onDisk="true" adql="True" primary="granule_uid">
	<mixin spatial_frame_type="body">//epntap2#table-2_0</mixin>
</table>

This minimal table definition says:

  • define an epn_core table
  • write it on disk (i.e., do not keep it in RAM)
  • activate ADQL for query
  • use the granule_uid column for the primary key of the table
  • use the epntap2 template table with only mandatory parameters, and with spatial_frame_type = "body"

The spatial_frame_type = "body" attribute is required, even if you don't use the spatial coordinate columns, as the mixin has to know what to put into the column headers. The spatial coordinate columns' definitions depend on the spatial_frame_type.

If you plan to use some optional parameters, as defined in the EPNcore specification, the table definition will look like:

<table id="epn_core" onDisk="true" adql="True" primary="granule_uid">
	<mixin 
		spatial_frame_type="body"
		optional_columns="access_url access_format access_estsize thumbnail_url publisher bib_reference target_region feature_name"
		>//epntap2#table-2_0</mixin>
</table>

The extra optional_columns attribute tells the template engine to set up those extra columns, as they are defined in the epntap2 mixin.

If you plan to use custom columns of your own, you have to define them in the table definition element, as shown in the following example:

<table id="epn_core" onDisk="true" adql="True" primary="granule_uid">
	<mixin 
		spatial_frame_type="body"
		optional_columns="access_url access_format access_estsize thumbnail_url publisher bib_reference target_region feature_name"
		>//epntap2#table-2_0</mixin>
	<column name="receiver_name" type="text" ucd="meta.id" description="Receiver name used with the instrument." />
</table>

The column elements defines an extra column of the EPNcore table.

Data ingestion



  • No labels
Write a comment…