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 5 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

target_class

sample reference

'sample', constant

'sample', constant

target_name


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.

alt_target_name


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

not used

sample_id


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)





producer_name

measurement origin

These two provide enough credits in the table (agreed)

 provide reference to whom measured the sample

producer_institute




instrument_host_name


same

Standard name of the lab/facility

instrument_name


same

 Name of instrument (as in publications)





sample_classification

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 %)



same

Name of mineral to be included



same

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



same

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



same

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

grain_size_min


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

 provide the particle size range in µm

grain_size_max


(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 

TBC

Included in sample_classification





azimuth_min

environment parameters

complement incidence, emergence, and phase

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

azimuth_max


negative values for azi and phase have a special meaning?


pressure


unit TBC 

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

temperature


K

 K

measurement_atmosphere


same

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





measurement_type

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)

geometry_type


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

spectrum_type ?


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…)
TBC
(may need to remove duplicates from Bernard's list)






sample_desc

descriptions

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)

setup_desc


same

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

data_calibration_desc


same

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





thumbnail_url

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)

datalink_url


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…)

Species


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


dataproduct_type


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

'sp' for spectra

spectral_range_min (& *_max)


same

Provide spectral range as frequency in Hz (EPNCore standard)

spectral_sampling_step_min (& *_max)


same 

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?

TBD

not considered, although some are present


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

TBC

not considered


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

TBD

not considered

Proposed value lists, from SSHADE:

geometry_type

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)

  • No labels