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
Provides name of a meteorite, lunar sample, IDP, micrometeorite, etc from which the sample is extracted
Provides an ID of the sample.
Alternative target names/ID only - can't be used to store extra info on sample identification
To provide name/ID of measured sample in local collection (agreed)
Currently included in target_name.
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)
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.
Minor/trace components are not welcome here (would multiply false alarms)
Min/max defined somehow, left to data provider
provide the particle size range in µm
(max value not expected to be intensively used)
A very large value (eg, >1000 µm) can be used locally in a service to identify bulk material
? Sample_origin ?
Need to have a separated Origin parameter ? E.g.: Natural/synthetic, etc, including "mixture"?
Included in sample_classification
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?
Experimental conditions, in bar and K.
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)
proposed to store measurement_type in clear, associated to a specific UCD - see proposed list below
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
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?
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
(agreed upon during the workshop, then checked to be consistent with other fields)
Initially provided Dfreq in EPNCore 2.0
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
Band lists: tables with characteristics and attributions - EPNCore is not necessarily the best solution, see later proposal
Proposed value lists, from SSHADE:
direct, directional, bidirectional, specular, biconical, hemispheric, hemispheric-directional, directional-hemispheric, hemispheric-hemispheric, other geometry, unknown, ...
spectrum_type & 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)