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

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

EPN-TAP mandatory & regular optional parameters are in italics in the first column (the other ones are from the experimental spectroscopy and other extensions)

New parameters / ideas from workshop in dark red-brown

Usage in PDS_speclib service no longer consistent with column 3 are underlined in blue (would have to be changed also in the 2 DLR services)

Lab spectroscopy extension

 group related to:

Iterated from SSHADE and other proposals in Rome

 Initial proposal from PDS_speclib implementation


sample reference

'sample', constant

'sample', constant


Provides name of a meteorite, lunar sample, IDP, micrometeorite, etc from which the sample is extracted
- empty otherwise, no local ID

Provides an ID of the sample.
Introduces the name of a meteorite or a lunar sample when applicable.


Alternative target names/ID only - can't be used to store extra info on sample identification

not used


To provide name/ID of measured sample in local collection (agreed)

Currently included in target_name.
Various parts of the same sample can be indicated and described in sample_desc (such as "Location A", etc)


measurement origin

These two provide enough credits in the table (agreed)

 provide reference to whom measured the sample




Standard name of the lab/facility



 Name of instrument (as in publications)


sample description

provides composition as group, class, sub-class, etc… of sample, concatenated in a hash-list (=> flexible searches with LIKE and %)

Provides composition as group, class, sub-class, etc… of sample, concatenated in a hash-list (=> flexible searches with LIKE and %)


Name of mineral to be included


Must include specification "meteorite" plus the meteorite type when applicable, as well as description of (main) mixtures ingredients


Meteorite types as in Krot et al 2005.
Dana or Struntz classification tags can be used for minerals.


Minor/trace components are not welcome here (would multiply false alarms)


Min/max defined somehow, left to data provider
Proposed code for bulk = 99999

 provide the particle size range in µm


(max value not expected to be intensively used)
Proposed code for bulk = 99999

 A very large value (eg, >1000 µm) can be used locally in a service to identify bulk material
- see if we define a code for this (-1 could do, but we also have to reserve a code for N/A)

? Sample_origin ?

Need to have a separated Origin parameter ? E.g.: Natural/synthetic, etc, including "mixture"?
The drawback is the need to check several parameters 


Included in sample_classification


environment parameters

complement incidence, emergence, and phase

Azimuth angle in degrees - see if negative values of angles can have a special meaning


negative values for azi and phase have a special meaning?


unit TBC 

Experimental conditions, in bar and K.
Unit bar is not recommended by VO practices, TBC






Description of experimental conditions, free string. Measurements under vacuum are indicated here with the word "vacuum".


relative to setup

Contains UCD for this type of spectrum

The type of measurement/scale (REFF, I_over_F, etc…) provided as a UCD (being discussed at IVOA)


same, see proposed list below

such as bidirectional, biconical, directional-hemispherical, etc - see if this list can be frozen (not likely)
Can be a hash-list if composited from several spectral segments


proposed to store measurement_type in clear, associated to a specific UCD - see proposed list below
UCD proposal to be forwarded to IVOA (but doubtful…). The main benefit is to have a detailed description of complex measurements independent from UCDs

Relies on measurement_type, but accuracy of UCDs is not excepted to reach this level



free string describing the sample, its origin, and possible preparation

Free string describing the sample, its origin, and possible preparation (hash-list forbidden, as samples ID may contain # character)



Free string or hash-list describing the experimental setup if needed - may include Aperture (size of sample measured), etc



Free string or hash-list describing data post-processing / calibration


std parameters with special use

provides a link to a small spectral plot for quicklook only in VESPA portal
(larger plots to be provided as separated granules with dataproduct_type = im)

Provides a link to a small spectral plot - caution should be taken to have units / values readable in full size (will be reduced in VESPA portal)


Can contain a series of links to descriptive files providing extra information (image, text…)

Best solution to link descriptive files providing extra information (such as chemical analyses, samples images…)


Use it to store a chemical formula (alt: a list of atoms) - TBD

Comment: this parameter can be misleading if used only in some services / cases - will suggest that products not found do not exist at all

More for basic atm in obsevational data, not used here.

See if usage can be enlarged (e.g., to InChiKeys) - but for minerals?

species_inchikey ?

Check if required/useful, TBC


'sp' for spectra, but need for other values in SSHADE

'sp' for spectra

spectral_range_min (& *_max)


Provide spectral range as frequency in Hz (EPNCore standard)

spectral_sampling_step_min (& *_max)


Provide sampling step as frequency in Hz (EPNCore standard - mostly to support radio range)

spectral_resolution_min (& *_max)

spectral_resolution_min/max should instead provide 
| fq / Dfq | = | lam / Dlam | 

(agreed upon during the workshop, then checked to be consistent with other fields)

Initially provided Dfreq in EPNCore 2.0
(to be changed in next DaCHS mixin)

Other ideas:

A parameter to identify a source database in a compilation service (such as SSHADE, or PDS_speclib)

original_publisher may complement producer_name & producer_institute if required (from contributive work extension)

Uses producer_name & producer_institute to refer to original measurements

(service_title + server name) is intended to track data from another EPN-TAP service — Use of ivoID of service is more secure and would support all VO services, TBC

Photometric measurement sets?


not considered, although some are present

Optical constants: ~ two associated spectral a single file, or one / complex type? Description / table should be identical


not considered

Band lists: tables with characteristics and attributions - EPNCore is not necessarily the best solution, see later proposal


not considered

Proposed value lists, from SSHADE:


direct, directional, bidirectional, specular, biconical, hemispheric, hemispheric-directional, directional-hemispheric, hemispheric-hemispheric, other geometry, unknown, ...

PDS_speclib also contains:
biconical, off-axis
biconical, on-axis
biconical on-axis reflectance factor - this one is inconsistent

=> hemispherical should be used instead of hemispheric in the first list.

spectrum_type (and measurement_type, when converted in UCD)
raw, transmission, absorbance, normalized absorbance, optical density, absorption coefficient, optical constants, ATR transmission, ATR absorbance, corrected ATR absorbance, admittance, impedance, dielectric constant, electric conductivity, magnetic permeability, electric permittivity, loss tangent, radiance factor, reflectance, reflectance factor, albedo, complex reflectance ratio, reduced Stokes parameter Pq, reduced Stokes parameter Pv, polarization degree, polarization angle, thermal emission, thermal radiance, thermal emittance, thermal emissivity, scattering, radiative transfer model parameters, Raman scattering, normalized Raman scattering, Raman scattering coefficient, Raman scattering efficiency, fluorescence emission, normalized fluorescence emission, fluorescence emission efficiency

Comment: it is highly unlikely that such a detailed description can be supported with UCDs - they are not intended for this, although UCDs for some of these quantities are already defined

(+ may need to remove duplicates from spectrum_type list)

  • No labels