Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Note: from 5 July 2021, these pages are no longer the primary source of the EPN-TAP doc - see instead the IVOA latex source: https://github.com/ivoa-std/EPNTAP


List of EPN-TAP parameters
v2, 3/8/2015 (SE)
v3, 29/8/2015 (SE, integrating comments by PLS and BC)
v4, 7/9/2015 (SE, integrating comments by PLS)
v5, 7/10/2015 (SE, integrating comments by PLS: time_scale UCD)
v6, 7/11/2015 (SE, integrating comments by PLS/BC)
v7, 14/12/2015 (SE, added point 8, clarification of an older idea)
v8, 24/12/2015 (SE, review/integration of comments/corrections)
v9, 5-7/01/2016 (SE/BC, including comments from Chiara Marmo and Michel Gangloff)
v10, 21/02/2016 (SE, from model implementation of IKS)
v11, 11/5/2016 (SE, systematic comparison with ObsCore again & variations for spatial coordinates)

 

 

New in v2

  • The "laundry list" format makes services easier to design and to query
  • Allows grouping of results from several services at once
  • Supports multispacecraft observations
  • Speeds up mirroring of services (support for partial updates)
  • Better support of footprints, and better interface with GIS

 

Main evolution relative to v1

1) The previous notion of dataset is deprecated

This was complex to handle in the database, and in general not relevant for the services.

 

2) Grouping of products is rationalized in version 2

A granule is still a record/line in the epn_core view database, and corresponds to the smallest data unit described by the service.

A "product" is typically a data file, or a service output, that can be reached through a URL

In version 2 both concepts coincide, while in v1 the same granule could be composed of several products related to the same initial data (an "observation")

 

In EPN-TAP v2, granules are referenced by 3 parameters:

  • granule_uid provides a unique ID for the granule in the service, ie for each line in the epn_core view. It is equivalent to the previous index parameter (index is a reserved word in many database languages and should not have been used in the first place)
  • granule_gid is related to a type of product: it is identical for all granules containing the same type of information for different observations (e.g., calibrated files). An explicit string is recommanded in this field, with suggested standard values (e.g., preview/native/calibrated/geometry/projection…).
  • obs_id is related to an observation: it is identical for all granules related to the same observation, containing different type of data (e.g.: raw and calibrated data, associated geometry, etc). In many EPN-TAP v1 services, such products were described together on the same line with a unique index parameter.

These 3 parameters can be arbitrary alphanumeric strings — see example application to APIS service below.

 

In practice, different products related to the same observation are no longer described together on a single line of the epn_core view, but on successive lines associated by the same obs_id, each with a different granule_gid (and a specific granule_uid, see Table 2 below).

Each line in the epn_core view must describe only one product (plus a thumbnail wherever relevant). The notion of "main product" (which was more or less explicit in v1) is therefore deprecated, and the epn_core view in v2 includes more lines than in v1. Although less compact that the previous table presentation, this list presentation is much more efficient for machine-handling, and easier to design.

 

3) The notion of table/service parameters is deprecated

Such parameters were not directly accessible by TAP. In v2, constant parameters must be replicated in every line of the epn_core view.

Such parameters may be duplicated in the registry declaration though, so as to provide a fast description of services.

 

4) Footprints can be provided through s_region

s_region is a parameter in the ObsCore standard of IVOA, and ADQL allows for powerful query functions such as intersections. s_region introduces a pgSphere variable of type spoly providing description of the observed area on a sphere, which allows for accurate searches.

This can be used to provide footprint of spatially extended data either on the sky or on a planetary surface (as long as it is reasonably ellipsoidal). Use with 3D shape models needs study (should fail with concave 3D shapes such as 67P). Also study how concave footprints/polygons are handled, TBC.

The use in the context of GIS also has to be studied.

 

5) Better support of evolving services

creation_date and modification_date are now mandatory parameters for every granule. The latter is intended to optimize mirroring of services, by identifying the granules to be updated/copied.

These parameters must be provided as ISO 8601 strings with format "2013-11-17T10:41:00.00+01:00" (with no space) where the indication of time zone is mandatory. The associated data type must be "date". ADQL supports this format and filtering using time zone is possible.

 

6) Support of coordinated observations

The target_time_min/max parameters now provide observation time in the reference frame of the target. This is intended to facilitate the cross-correlation of observations from different locations, e.g., telescopic observations in support of space missions, or multi-spacecraft campaigns.

 

7) Axes ranges

All parameters defining a range are now introduced with a min and max value.

All floating point parameters are now in double precision to prevent errors.

 

8) Thematic extensions

Some science fields will require optional parameters, which need to be used consistently between services addressing the same field. Such extensions have to be designed by sub-groups involved in the corresponding data services, either as providers or users. This includes:

  • Lab spectroscopy: parameters to describe mineralogical samples (and possibly other samples)
  • Orbital/rotational parameters and physical properties of Solar System bodies
  • Results of planetary 3D modelling run
  • Exoplanets / planetary systems properties
  • Bibliographic entries? May be manageable otherwise, through bibcode / doi interpretation

 

9) Parameters which must be provided

are now clearly identified - those are not only mandatory, they also must provide a value.

They are mostly related to service description and granule identification.

 

 

+ See notes below the table.

...

Name, v2

...

Name, v1

...

SQL type

...

Unit / Format / Range

...

Description

...

UCD

Please comment!
 

...

EPNCore mandatory parameters
(Must be present, possibly empty)
New or modified
relative to v1

...

 

...

 

...

 

...

 

...

Current value
current but dubious or undefined
possible alternative

...

— ? : closest sense

_ : N/A in ObsCore

...

granule_uid

...

index

...

Text

...

 

...

Internal table row index
Unique ID in data service, also in v2. Can be alphanum.

...

meta.id

  meta.id;meta.dataset

...

granule_gid

...

Text

...

 

...

Common to granules of same type (e.g. same map projection, or geometry data products). Can be alphanum.

...

meta.id

...

obs_id

...

Text

...

 

...

Associates granules derived from the same data (e.g. various representations / processing levels). Can be alphanum., may be the ID of original observation.

...

meta.id

  meta.id;obs

...

_

...

resource_type

...

Text

...

 

...

Can be dataset or granule

...

(meta.code.class)

...

_

...

dataset_id

...

Text

...

 

...

Dataset identification & granule reference

(meta.id)

...

dataproduct_type

...

dataproduct_type

...

Text

...

 

...

Organization of the data product, from enumerated list

...

meta.code.class

...

target_name

...

target_name

...

Text

...

 

...

Standard IAU name of target (from a list related to target class), case sensitive

...

meta.id;src

...

target_class

...

target_class

...

Text

...

 

...

Type of target, from enumerated list

...

meta.code.class;src

 src.class

...

time_min

...

time_min

...

Double

...

d (date as JD)

...

Acquisition start time (in JD). UTC measured at time_origin location (default is observer's frame)

...

time.start

 time.start;obs

...

time_max

...

time_max

...

Double

...

d (date as JD)

...

Acquisition stop time (in JD). UTC measured at time_origin location (default is observer's frame)

...

time.end

 time.end;obs

...

time_sampling_step_min

...

time_sampling_step_min

...

Double

...

s

...

Min time sampling step

...

time.interval;stat.min

...

time_sampling_step_max

...

time_sampling_step_max

...

Double

...

s

...

Max time sampling step

...

time.interval;stat.max

...

time_exp_min

...

time_exp_min

...

Double

...

s

...

Min integration time

...

time.duration;obs.exposure;stat.min

...

time_exp_max

...

time_exp_max

...

Double

...

s

...

Max integration time

...

time.duration;obs.exposure;stat.max

...

spectral_range_min

...

spectral_range_min

...

Double

...

Hz

...

Min spectral range (frequency)

...

em.freq;stat.min

...

em.wl;stat.min

...

spectral_range_max

...

spectral_range_max

...

Double

...

Hz

...

Max spectral range (frequency)

...

em.freq;stat.max

...

spectral_sampling_step_min

...

spectral_sampling_step_min

...

Double

...

Hz

...

Min spectral sampling step

...

em.freq.step;stat.min

...

spectral_sampling_step_max

...

spectral_sampling_step_max

...

Double

...

Hz

...

Max spectral sampling step

...

em.freq.step;stat.max

...

spectral_resolution_min

...

spectral_resolution_min

...

Double

...

Hz

...

Min spectral resolution

...

spect.resolution;stat.min

...

spectral_resolution_max

...

spectral_resolution_max

...

Double

...

Hz

...

Max spectral resolution

...

spect.resolution;stat.max

...

c1min

...

c1min

...

Double

...

(1)

Longitude from 0. to 359.9999

RA from 0. to 23.9999

...

Min of first coordinate

...

pos;stat.min

pos.distance;stat.min
or pos.radius;stat.min (does not exist)
  for spherical & cylindrical?

pos.eq.ra;stat.min for celestial 

pos.bodyrc.lon;stat.min for body

pos.cartesian.x;stat.min for Cartesian

pos.healpix for healpix (with 2 parameters?  - weird)

...

c1max

...

c1max

...

Double

...

(1)

Latitude from -89.9999 to +89.9999

...

Max of first coordinate

...

pos;stat.max

...

c2min

...

c2min

...

Double

...

(1)

...

Min of second coordinate

...

pos;stat.min

pos.angDistance;stat.min
or pos.az;stat.min (for azimuth)
  for spherical & cylindrical?

pos.eq.dec;stat.min for celestial 

pos.bodyrc.lat;stat.min for body

pos.cartesian.y;stat.min for Cartesian

...

c2max

...

c2max

...

Double

...

(1)

...

Max of second coordinate

...

pos;stat.max

...

c3min

...

c3min

...

Double

...

(1)

...

Min of third coordinate

...

pos;stat.min

pos.AngDistance;stat.min
or pos.az.zd;stat.min (for zenithal distance)
  for spherical?

pos.distance;stat.min  for cylindrical?

pos.distance;stat.min for celestial 

pos.bodyrc.alt;stat.min for body? (from surface only, implicitly from reference level)
or
pos.distance;pos.bodyrc;stat.min for body (from center)?

pos.cartesian.z;stat.min for Cartesian

...

c3max

...

c3max

...

Double

...

(1)

...

Max of third coordinate

...

pos;stat.max

...

s_region

...

 

...

spoly

...

PgSphere spoly

...

ObsCore-like footprint,valid for celestial, spherical, or body-fixed frames.

...

instr.fov

  phys.outline;obs.field

...

ObsCore value recently updated (was phys.angArea;obs)

Frame may be identified in q.rd (UNKNOWNFrame)

Do we need another param for GIS interface?

...

c1_resol_min

...

c1_resol_min

...

Double

...

(1)

...

Min resolution in first coordinate

...

pos.resolution;stat.min
 pos.angResolution
;stat.min
if angular

...

c1_resol_max

...

c1_resol_max

...

Double

...

(1)

...

Max resolution in first coordinate

...

pos.resolution;stat.max

...

c2_resol_min

...

c2_resol_min

...

Double

...

(1)

...

Min resolution in second coordinate

...

pos.resolution;stat.min
 pos.angResolution;stat.min
if angular

...

c2_resol_max

...

c2_resol_max

...

Double

...

(1)

...

Max resolution in second coordinate

...

pos.resolution;stat.max

...

c3_resol_min

...

c3_resol_min

...

Double

...

(1)

...

Min resolution in third coordinate

...

pos.resolution;stat.min
 pos.angResolution;stat.min
if angular
(spherical only)

...

c3_resol_max

...

c3_resol_max

...

Double

...

(1)

...

Max resolution in third coordinate

...

pos.resolution;stat.max

...

spatial_frame_type

...

spatial_frame_type

...

Text

...

(1)

...

Flavor of coordinate system, defines the nature of coordinates. From enumerated list

...

meta.code.class;pos.frame

...

incidence_min

...

incidence_min

...

Double

...

deg

...

Min incidence angle (solar zenithal angle)

...

pos.posAng;stat.min
 pos.incidenceAng;stat.min

...

incidence_max

...

incidence_max

...

Double

...

deg

...

Max incidence angle (solar zenithal angle)

...

pos.posAng;stat.max
 pos.incidenceAng;stat.max

...

emergence_min

...

emergence_min

...

Double

...

deg

...

Min emergence angle

...

pos.posAng;stat.min
 pos.emergenceAng;stat.min

...

emergence_max

...

emergence_max

...

Double

...

deg

...

Max emergence angle

...

pos.posAng;stat.max
 pos.emergenceAng;stat.max

...

phase_min

...

phase_min

...

Double

...

Min phase angle

...

pos.phaseAng;stat.min

...

phase_max

...

phase_max

...

Double

...

deg

...

Max phase angle

...

pos.phaseAng;stat.max

...

instrument_host_name

...

instrument_host_name

...

Text

...

 

...

Standard name of the observatory or spacecraft

...

meta.id;instr.obsty

...

instrument_name

...

instrument_name

...

Text

...

 

...

Standard name of instrument

...

meta.id;instr

...

measurement_type

...

measurement_type

...

Text

...

 

...

UCD(s) defining the data

...

meta.ucd

...

processing_level

...

processing_level

...

Integer

...

 

...

CODMAC calibration level in v1

...

meta.code;obs.calib
   meta.calibLevel

...

meta.code;obs.calib

...

creation_date

...

(ISO-8601 String)

...

Date of first entry of this granule

...

time.creation

...

modification_date

...

Date of last modification (used to handle mirroring)

...

time.update
    time.process

...

release_date

...

(ISO-8601 String)

...

Start of public access period (set to creation_date if no proprietary period)

...

time.release

...

service_title

...

service_title
(still "title" in many v1 services)

...

Text

...

 

...

Title of resource (an acronym really, will be used to handle multiservice results)

...

meta.title

...

Optional parameters

...

 

...

 

...

 

...

 

...

 

...

access_url

...

access_url

...

Text

...

 

...

URL of the data file, case sensitive. Can point to a script. If present, next 2 parameters must also be present.

...

meta.ref.url;meta.file

...

access_format

...

access_format

...

Text

...

 (mime type in lowercase)

...

File format type  

...

meta.code.mime

...

access_estsize

...

access_estsize

...

Integer

...

kbyte

...

Estimate file size in kbyte (with this spelling)

...

phys.size;meta.file

...

data_access_url

(best avoided and replaced by datalink in access_url, TBC)

...

 _

...

preview_url

...

Integer

...

 

...

URL of a preview image (std format with adequate resolution for user's purpose)

...

(meta.ref.url;meta.file)

...

 _

...

native_access_url

...

Text

...

 

...

URL of the data file in native form, case sensitive

...

(meta.ref.url;meta.file)

...

 _

...

native_access_format

...

Text

...

 

...

File format type in native form

...

(meta.id;class)
(or meta.code.mime if we use MIME type)

...

thumbnail_url

...

Text

...

 

...

URL of a thumbnail image with predefined size (png ~200 pix, for use in a client only)

...

meta.ref.url;meta.file

 meta.ref.url;meta.preview 

...

file_name

...

file_name

...

Text

...

 

...

Name of the data file only, case sensitive

...

meta.id;meta.file

...

species

...

species

...

Text

...

 

...

Identifies a chemical species, case sensitive

...

meta.id;phys.atmol

...

target_region

...

target_region

...

Text

...

 

...

Type of region of interest

...

meta.id;class

  obs.field

...

feature_name

...

element_name

...

Text

...

 

...

Secondary name
(can be standard name of region of interest)

...

meta.id;pos

  obs.field 

...

bib_reference

...

reference

...

Text

...

 

...

Bibcode preferred if available (does that include link?), doi, or other biblio id, URL…

...

meta.bib

 meta.bib.bibcode (if bibcode)

...

meta.bib.bibcode

(always as bibcode)

...

ra

...

ra

...

Double

...

deg or h:m:s?

...

Right ascension (not hour angle!)

...

pos.eq.ra;meta.main

...

dec

...

dec

...

Double

...

deg

...

Declination

...

pos.eq.dec;meta.main

...

solar_longitude_min

...

solar_longitude

...

Double

...

deg

...

Min Solar longitude Ls (location on orbit / season)

...

pos.posangle

pos.posAng;pos.heliocentric;stat.min
or

pos.angDistance;pos.heliocentric;stat.min

...

solar_longitude_max

...

solar_longitude

...

Double

...

deg

...

Max Solar longitude Ls (location on orbit / season)

...

pos.posangle

pos.posAng;pos.heliocentric;stat.max
or

pos.angDistance;pos.heliocentric;stat.max

...

local_time_min

...

local_time_min

...

Double

...

h

...

Local time at observed region

...

time.phase;stat.min

  time.period.rotation;time.phase;stat.min

...

local_time_max

...

local_time_max

...

Double

...

h

...

Local time at observed region

...

time.phase;stat.max

 time.period.rotation;time.phase;stat.max

...

target_distance_min

...

target_distance

...

Double

...

km

...

Observer-target distance

...

pos.distance;stat.min

...

Double

...

target_time_min

...

Double

...

d

...

Observing time in target frame

...

time.start

...

target_time_max

...

Double

...

d

...

time.end

...

pos.distance;stat.max

...

particle_spectral_type

...

particle_spectral_type

...

Text

...

 

...

 

...

Use phys.particle?

...

particle_spectral_range_min

...

particle_spectral_range_min

...

Double

...

 

...

 

...

Use phys.particle?

...

particle_spectral_range_max

...

particle_spectral_range_max

...

Double

...

 

...

 

...

Use phys.particle?

...

particle_spectral_sampling_step_min

...

particle_spectral_sampling_step_min

...

Double

...

 

...

 

...

Use phys.particle?

...

particle_spectral_sampling_step_max

...

particle_spectral_sampling_step_max

...

Double

...

 

...

 

...

Use phys.particle?

...

particle_spectral_resolution_min

...

particle_spectral_resolution_min

...

Double

...

 

...

 

...

spect.resolution;stat.min

Use phys.particle?

...

particle_spectral_resolution_max

...

particle_spectral_resolution_max

...

Double

...

 

...

 

...

spect.resolution;stat.max

Use phys.particle?

...

More optional parameters (TBC)

...

were "Relative to service" (in Table header)

...

 

...

 

...

 

...

 

...

publisher

...

publisher

...

Text

...

 

...

Resource publisher

...

meta.name
  meta.curation

...

spatial_coordinate_description

...

spatial_coordinate_description

...

Text

...

 

...

ID of specific coordinate system and version

...

meta.code.class;pos.frame

...

spatial_origin

...

spatial_origin

...

Text

...

 

...

Defines the frame origin

...

meta.ref;pos.frame

...

time_origin

...

time_origin

...

Text

...

 

...

Defines where the time is measured (e. g., ground vs spacecraft) [target_time is of course always on target].

...

meta.ref;time.scale
or
pos;time.scale

...

time_scale

...

 

...

Text

...

 

...

Always UTC in data services (may be relaxed in computational services such as ephemeris) - from enumerated list

...

time.scale

...

 

(1): depending on context (as given by spatial_frame_type). Please comment here: EPN-TAP v2: Current discussion topic

Beware that datatypes apply to the epn_core view, not to the q.rd file where they can be different

...

File name-type

granule_uid

granule_gid

obs_id

A-Raw

1

native

A

A-Calib

2

calibrated

A

A-geom

3

geometry

A

A-proj

4

projected

A

B-Raw

5

native

B

B-Calib

6

calibrated

B

B-geom

7

geometry

B

B-proj

8

projected

B

 

Other modifications 

...

This can be parsed by ADQL/RegTAP function ivo_hashlist_has like this:
  select * from vvex.epn_core where 1 = ivo_hashlist_has(lower(target_name),'Venus')

Where the lower function is mandatory to handle values possibly containing upper cases (this is implicit on the 2nd argument)

Beware that only complete elements between separators will be found. The provider has to split the string according to expected searches, e.g.:
    Composite Infrared Spectrometer#CIRS
not    Composite Infrared Spectrometer (CIRS)

...

 

UCDs: to be reviewed against PDS4 and IPDA, and completed (ObsCore checked)

Processing levels: to be reviewed against PDS4 (again- mostly related to geometry, considered as derived in PDS4)

min vs max:
if only one value available, it must appear in both fields

• Optional parameters: they come in sets that are logically related; if one is present, the related ones must be present also (e.g., 3 access_* parameters)

• Granule_gid: any general indication to providers? I.e.: preview, native, calibrated, geometry… 
A client should be able to display the values present in a service, TBC

• Reshuffle previous "service parameters":

  • Mandatory :
    processing_level -mandatory
    service_title –mandatory
    publisher -mandatory???
  • Optional - TBC
    spatial_coordinate_description  (default = body-fixed or J2000)
    spatial_origin  (default = body center or SS barycenter? Or observer location)
    time_origin  (default = observer)
    time_scale (default = UTC – no other values allowed in data services? [only in computational services, e.g. ephemeris])
    Same values to be used in registry declaration 

 

Support for PDS3 detached labels (proposal)

access_format = "PDS3label" (it has to be here: we need to know that there is a detached label)
then access_url points to the label, and data_access_url points to the file (param is mandatory in this case - although the data file name is in the label, it can be in another directory)
A script can then recover both files and do something with them. This mechanism can be extended to other formats with detached labels (ENVI…).
Check solution with datalink first

 

Example of V1 to V2 conversion with APIS database:

EPNcore Table v1

(was not really compliant…)

...

o5g202x4q_x2d.fits

...

(refreshed/completed April 2019, Oct 2020, June 2021, Oct 2021) (SE) 

You can use this file to keep track of your service parameters: EPN-TAP_parameters_List_template.xlsx

EPN-TAP

  • EPN-TAP is a VO access protocol dedicated to Planetary Science data. It is based on the TAP mechanism from IVOA, completed with sets of parameters and associated lists of values. In this regard, it is similar to ObsTAP but with a different scope.
  • EPN-TAP version 2 is a major update of the protocol to accommodate larger services and simplify setup and use of data services. All parameters are described here.

Parameters which must be provided

are now clearly identified - those are not only mandatory, they also must provide a value.
They are mostly related to service description and granule identification.

+ See notes below the table.

Thematic extensions

Some science fields will require optional parameters, which need to be used consistently between services addressing the same field. Such extensions have to be designed by sub-groups involved in the corresponding data services, either as providers or users. This includes:

  • Lab spectroscopy: parameters to describe mineralogical samples (and possibly other samples)
  • Solar System objects: covers orbital/rotational parameters, physical properties, and taxonomy
  • APIS: for consistency with APIS service. Contains parameters for observing programs (most parameters are actually included in other extensions)
  • Contributive works / observing programs: enlargement of APIS extension to other data
  • Exoplanets / planetary systems properties
  • Map extension (to be enlarged)
  • Events: covers the VOevent standard and other types of events
  • Particle spectroscopy (to be finalized)
  • Results of planetary 3D modelling run (in progress)
  • Bibliographic entries? May be manageable otherwise, through bibcode / doi interpretation

Support file

You can use this file to keep track of your service parameters: EPN-TAP_parameters_List_template.xlsx


Name

SQL type

Unit

Description

UCD

UCD in Obscore 1.1

(9/5/2017 REC version)

Utype

(tentative) 

Comments

EPNCore mandatory parameters
 (Must be present, possibly empty)
 (bold face: a value is required)




Current value
current but dubious or undefined

— ? : closest sense

_ : N/A in ObsCore

from epntap v2 mixin (aug 2017)
equivalent/close in ObsCore doc 1.1

 

granule_uid

Text


Unique ID in data service

meta.id

meta.id
 Can be alphanum.

granule_gid

Text


Common to granules of same type

meta.id

meta.id
E.g. same map projection, or geometry data products. Can be alphanum.

obs_id

Text


Associates granules derived from the same data

meta.id;obs

meta.idobscore:DataID.observationID E.g. various representations / processing levels. Can be alphanum., may be the ID of original observation.
Keep it simple in intricate situations.

dataproduct_type

Text


Organization of the data product, from enumerated list

meta.code.class

meta.id

Epn.dataProductType

obscore:ObsDataset.dataProductType


measurement_type

Text


UCD(s) defining the data

meta.ucd

meta.ucdEpn.Measurement_typeAdd ;meta.modelled if simulation or model
Add ;stat.uncalib if uncalibrated data - in which case processing_level must be 0 or 1

processing_level

Integer


Dataset-related encoding, or simplified CODMAC calibration level

meta.calibLevel

meta.code;obs.calib

~ obscore:ObsDataset.calibLevel To be replaced by PDS4 values in v2.1?

target_name

Text


Standard IAU name of target (must match target_class), case sensitive

meta.id;src

meta.id;srcEpn.TargetNameCase sensitive
Services with no target_name do exist

target_class

Text


Type of target, from enumerated list

src.class

src.classEpn.TargetClass

time_min

Double

d

Start time (in JD). UTC measured at time_origin location (default is observer's frame)

time.start;obs

time.start;obs.exposure

Char.TimeAxis.Coverage.Bounds.Limits.Interval.StartTime



time_max

Double

d

Stop time (in JD). UTC measured at time_origin location (default is observer's frame)

time.end;obs

time.end;obs.exposure

Char.TimeAxis.Coverage.Bounds.Limits.Interval.StopTime



time_sampling_step_min

Float

s

Min time sampling step

time.resolution;stat.min

time.resolution Epn.Time.Time_sampling_step_min

time_sampling_step_max

Float

s

Max time sampling step

time.resolution;stat.max


Epn.Time.Time_sampling_step_max

time_exp_min

Float

s

Min integration time

time.duration;obs.exposure;stat.min

time.duration;obs.exposureEpn.Time.Time_exp_min

time_exp_max

Float

s

Max integration time

time.duration;obs.exposure;stat.max


Epn.Time.Time_exp_max

spectral_range_min

Float

Hz

Min spectral range (as frequency)

em.freq;stat.min

em.wl;stat.min (always as wl)

Epn.Spectral.Spectral_range_minAlways as frequency

spectral_range_max

Float

Hz

Max spectral range (as frequency)

em.freq;stat.max

em.wl;stat.maxEpn.Spectral.Spectral_range_max

spectral_sampling_step_min

Float

Hz

Min spectral sampling step

em.freq;spect.binSize;stat.min

meta.numberEpn.Spectral.Spectral_sampling_step_min

spectral_sampling_step_max

Float

Hz

Max spectral sampling step

em.freq;spect.binSize;stat.max

meta.numberEpn.Spectral.Spectral_sampling_step_max

spectral_resolution_min

Float


Min spectral resolution (resolving power)

spect.resolution;stat.min

spect.resolution (relates to resolving power)

Epn.Spectral.Spectral_resolution_min

Now (2019) provides resolving power |(lambda / delta(lambda)| = |f /Df|
How do we accommodate FWHM for filters?

spectral_resolution_max

Float


Max spectral resolution (resolving power)

spect.resolution;stat.max


Epn.Spectral.Spectral_resolution_max

Now (2019) provides resolving power |(lambda / delta(lambda)| = |f /Df|
How do we accommodate FWHM for filters?

c1min

Float

(1)


Min of first coordinate, depends on the frame

see table below

pos.eq.raEpn.Spatial.Spatial_range.c1min

Typo in current mixin (.lonG => .lon

UCDs for cyl and sph coord are from PEN-UCDlist-20210430

c1max

Float

(1)

Max of first coordinate, depends on the frame



Epn.Spatial.Spatial_range.c1max

c2min

Float

(1)


Min of second coordinate, depends on the frame. 


pos.eq.decEpn.Spatial.Spatial_range.c2min

c2max

Float

(1)

Max of second coordinate, depends on the frame



Epn.Spatial.Spatial_range.c2max

c3min

Float

(1)

Min of third coordinate



Epn.Spatial.Spatial_range.c3min

c3max

Float

(1)

Max of third coordinate



Epn.Spatial.Spatial_range.c3max

s_region

Text

(3)

ObsCore-like footprint in 2D (if spatial_frame_type = celestial or body)

pos.outline;obs.field

pos.outline;obs.fieldobscore:Char.SpatialAxis.Coverage.Support.Area

(was initially instr.fov, to be corrected)
ObsCore value updated (was phys.angArea;obs) to phys.outline, 
then corrected to pos.outline

Must have xtype= adql:REGION to work with TAP
Frame may be identified in q.rd (UNKNOWNFrame).
Use value given in spatial_frame_type - very unclear…
Do we need another param for GIS interface?

c1_resol_min

Float

(2)

Min resolution in first coordinate

(2)

pos.angResolution;stat.minEpn.Spatial.Spatial_resolution.c1_resol_minpos.resolution restored in 2018
In body fixed frame, use pixelscale_min/max for resolution at the surface 

c1_resol_max

Float

(2)

Max resolution in first coordinate

(2)

pos.angResolution;stat.maxEpn.Spatial.Spatial_resolution.c1_resol_max_

c2_resol_min

Float

(2)

Min resolution in second coordinate

(2)


Epn.Spatial.Spatial_resolution.c2_resol_min_

c2_resol_max

Float

(2)

Max resolution in second coordinate

(2)


Epn.Spatial.Spatial_resolution.c2_resol_max_

c3_resol_min

Float

(2)

Min resolution in third coordinate

(2)


Epn.Spatial.Spatial_resolution.c3_resol_minpos.resolution restored in 2018

c3_resol_max

Float

(2)

Max resolution in third coordinate

(2)


Epn.Spatial.Spatial_resolution.c3_resol_maxpos.resolution restored in 2018

spatial_frame_type

Text

(1)


Flavor of coordinate system, defines the nature of coordinates. From enumerated list. Use "none" if undefined

meta.code.class;pos.frame

_

A value is required by DaCHS (query will return errors if empty)
Default value = none

incidence_min

Float

deg

Min incidence angle (solar zenithal angle)

 pos.incidenceAng;stat.min

_Epn.View_angle.Incidence_angle_minUCD for angles included in 2018 

incidence_max

Float

deg

Max incidence angle (solar zenithal angle)

 pos.incidenceAng;stat.max

_Epn.View_angle.Incidence_angle_maxUCD for angles included in 2018

emergence_min

Float

deg

Min emergence angle

 pos.emergenceAng;stat.min

_Epn.View_angle.Emergence_angle_minUCD for angles included in 2018

emergence_max

Float

deg

Max emergence angle

 pos.emergenceAng;stat.max

_Epn.View_angle.Emergence_angle_maxUCD for angles included in 2018

phase_min

Float

deg

Min phase angle

pos.phaseAng;stat.min


Epn.View_angle.Phase_angle_min

phase_max

Float

deg

Max phase angle

pos.phaseAng;stat.max


Epn.View_angle.Phase_angle_max

instrument_host_name

Text


Standard name of the observatory or spacecraft

meta.id;instr.obsty

meta.id;instr.telProvenance.ObsConfig.Facility.name

instrument_name

Text


Standard name of instrument

meta.id;instr

meta.id;instrProvenance.ObsConfig.Instrument.name

service_title

Text


Title of resource = schema name

meta.title



May be used to handle multiservice results

creation_date

Timestamp

(4)

Date of first entry of this granule

time.creation

time;meta.dataset

modification_date

Timestamp(4)

Date of last modification

time.processing



Used to handle mirroring
UCD value being discussed in 2018

release_date

Timestamp

(4)

Start of public access period (set to creation_date if no proprietary period)

time.release

time.releaseobscore:Curation.releaseDate

The value is in ISO 8601 format reusing this pattern: (“YYYY-MM-DDThh:mm:ss”) If release_date is in the future, the data is proprietary.

Common optional parameters








access_url

Text


URL of the data file, case sensitive (additional files may be linked through datalink_url). Can point to a script. If present, next 2 parameters must also be present

meta.ref.url;meta.file

meta.ref.urlObs.Access.Reference

Use this to link data!
Could accommodate a datalink with access_format = 'application/x-votable+xml;content=datalink'
(from ObsCore)
- but this is a funny idea…

access_format

Text


RFC 2045 media type (mime), required to be all-lower case 

meta.code.mime

meta.code.mimeObs.Access.Format

access_estsize

Integer

kbyte

Estimate file size in kbyte (with this spelling)

phys.size;meta.file

phys.size;meta.fileObs.Access.Size
access_md5Text
MD5 Hash for the file when available (real file, not script) meta.checksum;meta.file


thumbnail_url

Text


URL of a thumbnail image with predefined size (png ~200 pix, for use in a client only)

meta.ref.url;meta.preview




file_name

Text


Name of the data file only, case sensitive

meta.id;meta.file

meta.title;obs — ?
ObsCore obs_title is for a short free text string describing the granule. Do we want this?
datalink_urlText
Provides links to files or services on the servermeta.ref.url

Associated mime-type is 'application/x-votable+xml;content=datalink'
(from ObsCore)

bib_reference

Text


Bibcode or doi preferred; can be a URL or anything else. Refers to the granule

meta.bib

meta.bib

obscore:Curation.referenceBibcode & doi can be completed in TOPCAT

publisher

Text


Resource publisher

meta.curation

meta.ref.uri;meta.curation~ obscore:Curation.publisherID

processing_level_desc

Text
Describes specificities of the processing levelmeta.note


internal_referenceText
Related granule_uid(s) in the current servicemeta.id.cross

Use to link one granule to a set of other granules. To be used only if required - e.g. to solve situations that would otherwise require several tables
external_linkText
Web page providing more details on the granulemeta.ref.url

Link to an individual page in a web site associated to the database, e.g., a planet page in Exoplanets service. This is a way to provide extra granule information which cannot be accommodated in the table.

species

Text


Identifies a chemical species, case sensitive

meta.id;phys.atmol



This is the only case sensitive parameter (with target_name)
messengerText

Vector of measured signal, including electromagnetic 
band, from enumerated list

instr.bandpass


filterText Identifies filter in use, typically for imagesmeta.id;instr.filter

Informative only, free format (no list, but see http://svo2.cab.inta-csic.es/svo/theory/fps3/). Search can only rely on spectral range, as ObsCore does.
alt_target_nameText
Provides alternative target name(s). Can be a hash listmeta.id;src


feature_name

Text


Secondary name (e.g. standard name of a region of interest)

meta.id;src;obs.field 



Anchor
featurename
featurename

target_region

Text


Type of region or feature of interest

meta.id;src;obs.field




shapeText

introduces an ascii (ST)MOC, v2 (2D footprint on celestial, spherical, or body-related frames, possibly including time)

pos.outline;obs.field

Must have xtype="MOC" (follow DALI recommendation)

outline doesn't fit definition (refers to a contour)

spatial_coordinate_description

Text


ID of specific coordinate system and version / properties

meta.code.class;pos.frame



~COOSYS, but includes planetary ones
Still TBD, needs to be OGC compliant. Discussion in progress here: EPN-TAP v2: Current discussion topic

spatial_origin

Text


Defines the frame origin

meta.ref;pos.frame




time_refposition

Text


Defines where the time is measured (e. g., ground vs spacecraft). Default is observer's frame

meta.ref;time.scale



target_time is of course always on target.

time_scale

Text


Defaults to UTC in data services - from enumerated list

time.scale




solar_longitude_min

Float

deg

Min Solar longitude Ls (location on orbit / season)

pos.ecliptic.lon;pos.heliocentric;stat.min 




solar_longitude_max

Float

deg

Max Solar longitude Ls (location on orbit / season)

pos.ecliptic.lon;pos.heliocentric;stat.max




local_time_min

Float

h

Min local time at observed region

time.phase;time.period.rotation;stat.min




local_time_max

Float

h

Max local time at observed region

time.phase;time.period.rotation;stat.max 




target_distance_min

Float

km

Min observer-target distance

pos.distance;stat.min




target_distance_max

Float

kmMax observer-target distancepos.distance;stat.max


target_time_min

Timestamp

(4)

Min observing time in target frame

time.start;src



(simplest way to look for coordinated observations)

target_time_max

Timestamp

(4)

Max observing time in target frame

time.end;src




earth_distance_minFloatAUMin Earth-target distancepos.distance;stat.min


earth_distance_maxFloatAUMax Earth-target distance

pos.distance;stat.max




sun_distance_minFloatAUMin Sun-target distancepos.distance;stat.min


sun_distance_maxFloatAUMax Sun-target distancepos.distance;stat.max


subobserver_longitude_minFloatdegMinimum sub-observer point longitude (sub-Earth for ground based observations)pos.bodyrc.lon;stat.min

_
subobserver_longitude_maxFloatdegMaximum sub-observer point longitude (sub-Earth for ground based observations)pos.bodyrc.lon;stat.max

_
subobserver_latitude_minFloatdegMinimum sub-observer point latitude (sub-Earth for ground based observations) pos.bodyrc.lat;stat.min

_
subobserver_latitude_maxFloatdegMaximum sub-observer point latitude (sub-Earth for ground based observations) pos.bodyrc.lat;stat.max

_
subsolar_longitude_minFloatdegMinimum sub-solar point longitudepos.bodyrc.lon;stat.min

Provided in the most natural body-related coordinate frame, E-handed - seems to require 'body'
subsolar_longitude_maxFloatdegMaximum sub-solar point longitudepos.bodyrc.lon;stat.max

Provided in the most natural body-related coordinate frame, E-handed - seems to require 'body'
subsolar_latitude_minFloatdegMinimum sub-solar point latitudepos.bodyrc.lat;stat.min

_
subsolar_latitude_maxFloatdegMaximum sub-solar point latitudepos.bodyrc.lat;stat.max

_

ra

Float

deg

Right ascension

pos.eq.ra;meta.main



deg only (like ObsCore)

dec

Float

deg

Declination

pos.eq.dec;meta.main




radial_distance_minFloatkmMin distance from observed area to body center pos.distance;pos.bodyrc;stat.min


radial_distance_maxFloatkmMax distance from observed area to body center pos.distance;pos.bodyrc;stat.max


altitude_fromshape_minFloatkmMin altitude of observed area above shape model / DTMpos.bodyrc.alt;stat.min


altitude_fromshape_maxFloatkmMax altitude of observed area above shape model / DTMpos.bodyrc.alt;stat.max


Parameters from extensions








APIS extension






obs_modeText
Observing modemeta.code;instr.setup

From APIS + observation extensions (with adapted UCDs)
detector_nameText
Detector namemeta.id;instr.det


opt_elemText
Optical element namemeta.id;instr.param


instrument_typeText
Type of instrumentmeta.id;instr

Informative only (not a reliable search parameter): free format, no reference list intended.
acquisition_idText
ID of the data file/acquisition in the original archivemeta.id


proposal_idText
Proposal identifiermeta.id;obs.proposal


proposal_piText
Proposal principal investigator

meta.id.PI;obs.proposal




proposal_titleText
Proposal titlemeta.title;obs.proposal


campaignText
Name of the observational campaignmeta.id;obs.proposal


target_descriptionText
Original target keywordsmeta.note;src


proposal_target_nameText
Target name as in proposal titlemeta.note;obs.proposal


target_apparent_radiusFloatarcsecApparent radius of the target

phys.angSize;src




north_pole_positionFloatdegNorth pole (of target) position angle with respect to celestial north pole

pos.posAng



Group of 5 parameters very specific to APIS.
Name is ~ OK, but actually provides the position angle of the planet axis. Use "orientation" for the image.
target_primary_hemisphereText
Primary observed hemispheremeta.id;obs.field


target_secondary_hemisphereText
Secondary observed hemispheremeta.id;obs.field


platescFloatarcsec/pixPixel angular size or platescale (on sky only)instr.scale


orientationFloatdegPosition angle of image y axis (on sky only), direct sense from north directionpos.posAng

Provides the direction of the polar axis in the image, counted clockwise from north.
measurement_unitText
Physical unit, same as Bunit in fitsmeta.unit


Contributive work extension






observer_nameText
Observer name

meta.id.PI;obs.observer




observer_idInteger
Observer's numeric identifier

meta.id.PI




Group of 5 from PVOL, OK for general use but UCDs have to be changed in PVOL.
meta.pubid in PVOL

observer_codeText
Observer's service usernamemeta.id.PI

meta.pubcode in PVOL
observer_instituteText
Observer institutemeta.note


observer_countryText
Observer's country of residencemeta.note;obs.observer

meta.pubcountry in PVOL
observer_locationText
Broad location of the observer or telescope. Can be used when the exact location cannot be releasedpos;obs.observer - not in mixin!

meta.pubcountry in PVOL
observer_lonFloatdegObserver's approximate longitudeobs.observer;pos.earth.lon


meta.publon in PVOL
observer_latFloatdegObserver's approximate latitudeobs.observer;pos.earth.lat

meta.publat in PVOL

original_publisher


Text
Refers to the source of the data, e.g.,  in compilations of observations or experimental datameta.note

Experimental spectroscopy + contributive work extensions

Solar System objects extension






mean_radiusFloatkm
phys.size.radius


equatorial_radiusFloatkm
phys.size.radius


polar_radiusFloatkm
phys.size.radius


diameterFloatkmTarget diameter, or equivalent diameter for binary objectsphys.size.diameter

Used in tnosarecool, not very consistent (use radius?)
massFloatkgMass of objectphys.mass

Solar System Objects extension (generic values in catalogues, not observations)
sidereal_rotation_periodFloathObject rotation ratetime.period.rotation


semi_major_axis

FloatAU

phys.size.smajAxis




inclinationFloatdegOrbit inclination

src.orbital.inclination




eccentricityFloat
Orbit eccentricity

src.orbital.eccentricity




long_ascFloatdegLongitude of ascending node, J2000.0src.orbital.node


arg_perihelFloatdegArgument of perihelion, J2000.0src.orbital.periastron


mean_anomalyFloatdegMean anomaly at the epochsrc.orbital.meanAnomaly


epochDoubled

Epoch of interest in JD

time.epoch


magnitudeFloatmagAbsolute magnitude. For small bodies, from HG magnitude systemphys.magAbs

Actually depends on service (eg, spectro_planets vs DynAstVO vs tnosarecool).
UCD may include mention of the photometric band.
fluxFloatmJyTarget fluxphot.flux.density


albedoFloat
Target albedophys.albedo


dynamical_class

Text
Class of small body, from enumerated listmeta.code.class;src


dynamical_typeText
Subdivision of the class, from enumerated listmeta.code.class;src


taxonomy_codeText
Code for target taxonomysrc.class.color

Possible values depend on target type and possibly on service
Map extension






map_projection

Text
ID from enumerated list, or string with parameters (referring to a standard)pos.projection

Map extension

map_height

FloatpixMap size in px

phys.size




map_widthFloatpixMap size in px

phys.size




map_scaleText
Preferably a ratio (e. g., "1:50000")

pos.wcs.scale




pixelscale_minFloatkm/pixMin pixel size on a surface

instr.scale;stat.min




pixelscale_maxFloatkm/pixMax pixel size on a surface

instr.scale;stat.max




Particle spectroscopy extension








particle_spectral_type

Text


From enumerated list

meta.id;phys.particle




particle_spectral_range_min

Float



phys.energy;phys.particle;stat.min

phys.mass;phys.particle;stat.min




particle_spectral_range_max

Float



phys.energy;phys.particle;stat.max

phys.mass;phys.particle;stat.max




particle_spectral_sampling_step_min

Float



spect.resolution;phys.particle;stat.min




particle_spectral_sampling_step_max

Float



spect.resolution;phys.particle;stat.max




particle_spectral_resolution_min

Float



spect.resolution;phys.particle;stat.min




particle_spectral_resolution_max

Float



spect.resolution;phys.particle;stat.max




Experimental spectroscopy extension








producer_name

Text
Data producer name, especially in compilations of experimental datameta.note


producer_institute

Text
Data producer institute, e. g., in compilations of experimental datameta.note


sample_idText
Provides a local ID in an existing catalogue meta.id;src

In addition to target_name

sample_classification

Text
Information related to class, sub-class, species… as hash listmeta.note;phys.composition

This uses standard names for classes… 
sample_descText
Describes the sample, its origin, and possible preparation. Can be a hash listmeta.note


species_inchikeyText

Fixed length string identifying the species. Can be a hash list

meta.id;phys.atmol



Follows IUPAC standard (Heller et al 2015)

grain_size_min

FloatumMin sample particle size 

phys.size;stat.min




grain_size_maxFloatumMax sample particle size 

phys.size;stat.max




azimuth_minFloatdegMin azimuth angle for illuminationpos.azimuth;stat.min

Check meaning/requirements for <0 values?
UCD added in 2018 (instead of pos.azimuthAng requested - OK)

azimuth_maxFloatdegMax azimuth angle for illuminationpos.azimuth;stat.max

UCD added in 2018

pressure

FloatbarAmbient pressure

phys.pressure



VOunits says: Pascal.

measurement_atmosphere

Text
Describes experimental conditions. "vacuum" for measurements under vacuum

meta.note;phys.pressure




temperatureFloatKAmbient temperature

phys.temperature




setup_descText
Describes the experimental setup. Can be a hash listmeta.note

May include Aperture (size of sample measured), etc

data_calibration_desc

Text
Provides information on post-processing. Can be a hash listmeta.note

(preferably to a "comment" parameter)

geometry_type

Text
Type of observation, from enumerated list. Can be a hash listmeta.note;instr.setup


spectrum_type

Text
Type of spectral observation, from enumerated list TBD. Can be a hash listmeta.note;instr.setup

Alternative to UCD, very detailed

Event extension








event_type

Text

Type of event from enumerated list

meta.code.class



Events extension
If dataproduct_type = ev
UCDs should be provided with the standard

event_statusText

From enumerated list

meta.code.status




event_citeText

From enumerated list

meta.code.status





(1): depending on context (as given by spatial_frame_type), see table below

Longitude and RA range from 0. to 360; Latitude and Dec range from -90. to +90.

For spatial_frame_type = "none": no value is provided, UCD are empty strings (""), and no unit is provided

(2) Spatial resolution parameters have the same unit as spatial coordinate parameters. The associated UCD combine either pos.resolution (if linear) or pos.angResolution (if angular) with secondary stat.min or stat.max

c1: only body and celestial are angular; c2: only cartesian is linear; c3: only spherical is angular

(3): Any contour type that works with ADQL's geometry operators (CONTAINS, INTERSECTS...) is legal here

(4): Timestamps are provided as ISO-8601 String as specified by DALI. On VOtable output, xtype="timestamp" attribute is required.


Frame coordinates UCD/unitscelestialbodycartesiansphericalcylindrical

c1min

pos.eq.ra;stat.min 

pos.bodyrc.lon;stat.min

pos.cartesian.x;stat.min

(in km)

pos.spherical.r;stat.min 

(in m)

pos.cylindrical.r;stat.min 

(in km)

c1maxpos.eq.ra;stat.maxpos.bodyrc.lon;stat.max

pos.cartesian.x;stat.max

(in km)

pos.spherical.r;stat.max 

(in m)

pos.cylindrical.r;stat.max 

(in km)

c2minpos.eq.dec;stat.minpos.bodyrc.lat;stat.min

pos.cartesian.y;stat.min

(in km)

pos.spherical.colat;stat.min

pos.cylindrical.azi;stat.min

c2maxpos.eq.dec;stat.maxpos.bodyrc.lat;stat.max

pos.cartesian.y;stat.max

(in km)

pos.spherical.colat;stat.max

pos.cylindrical.azi;stat.max

c3min

pos.distance;stat.min

(in AU)

pos.bodyrc.alt;stat.min (from surface only, implicitly from reference level)
or
pos.distance;pos.bodyrc;stat.min (from center)?

(in km)

pos.cartesian.z;stat.min

(in km)

pos.spherical.azi;stat.min

pos.cylindrical.z;stat.min

(height, in km)

c3max

pos.distance;stat.max

(in AU)

pos.bodyrc.alt;stat.max (from surface only, implicitly from reference level)
or
pos.distance;pos.bodyrc;stat.max (from center)?

(in km)

pos.cartesian.z;stat.max

(in km)

pos.spherical.azi;stat.max

pos.cylindrical.z;stat.max

(height, in km)

Example table for IDs:

File name-type

granule_uid

granule_gid

obs_id

A-Raw

1

native

A

A-Calib

2

calibrated

A

A-geom

3

geometry

A

A-proj

4

projected

A

B-Raw

5

native

B

B-Calib

6

calibrated

B

B-geom

7

geometry

B

B-proj

8

projected

B 


Syntax


multivalued lists = first entry#second entry#…#last entry, or scalar (with no #)
Values separator = #
No quotes around the list

This can be parsed by ADQL/RegTAP function ivo_hashlist_has like this:
  select * from vvex.epn_core where 1 = ivo_hashlist_has(lower(target_name),'Venus')

Where the lower function is mandatory to handle values possibly containing upper cases (this is implicit on the 2nd argument)

Beware that only complete elements between separators will be found. The provider has to split the string according to expected searches, e.g.:
    Composite Infrared Spectrometer#CIRS
not    Composite Infrared Spectrometer (CIRS)

Parameters supporting multivalued lists include:
dataproduct_type (only when present in the same file; best avoided when possible)
target_name (for different targets only, but only one target can be described in the granule; use alt_target_name for other names of the same target)
alt_target_name
target_class (in association with target_name)
instrument_host_name (e.g. acronym and full name)
instrument_name (e.g. acronym and full name)
measurement_type (when present in the same file)
processing_level (when present in the same file)
bib_reference


NULL and special values:
A standard query on a parameter will not return granules with NULL/void value. E.g. target_name LIKE '%toto%' will only select granules with this value (standard ADQL behavior).
NULL/void has to be tested specifically (e.g., when it means "I don't know") using the IS operator (IS is used only to test the NULL value in ADQL): 

target_name LIKE '%toto%' OR target_name IS NULL

Syntax IS NULL stands for both strings and numerical parameters (the = operator is accepted in this context only by latest DaCHS servers)

No inf, inf, or NaN value in ADQL? At least Inf/-Inf should be there, as per DALI.

UCDs: the above table has been reviewed against the UCD documents, including latest discussions (4/2019). Review against PDS4 and IPDA to be performed.

2018 discussions / conclusions have been included herehttps://wiki.ivoa.net/twiki/bin/view/IVOA/UCDList1dot42017June2018FebRFM

• *_min vs *_max parameters

If only one value is available, it must appear in both fields

• Optional parameters: some of these come in sets that are logically related; if one is present, the related ones must be present also (e.g., 3 access_* parameters)

• Granule_gid: any general indication to providers? I.e.: preview, native, calibrated, geometry… 
A client should be able to display the values present in a service (feasible in TOPCAT)

• Reshuffle previous "service parameters":

  • Mandatory :
    publisher - make it mandatory???
    add publisher_did as in Obscore? (for DaCHS/registry; provides unique ID of service for this publisher/server), with UCD = meta.ref.uri;meta.curation 
  • Optional 
    spatial_coordinate_description  (default = none)
    spatial_origin  (default = body center or SS barycenter? Or observer location)
    time_origin  (default = observer)
    time_scale (default = UTC – no other values allowed in data services? [only in computational services, e.g. ephemeris])
    Same values to be used in registry declaration 

• Call-back parameters / reference

Currently using service_title (= schema name) + granule_uid. 

May use ivoID in the future.

Other parameters

The most recent extra parameters often have names starting in prefix_*, where prefix identify the scope or context (e.g., spase_, vims_, image_, etc). Seems to be a good practice.

Accref is introduced by the EPN-TAP localfile mixin, but not used - in principle not included in TAP response, be may be present anyway. It may be better to hide it also in the portal.


Parameters introducing error bars/uncertainties

Some parameters providing a scalar value X in the EPN-TAP table may be associated with an error bar in a related parameter. This is currently (4/2019) entered as:

In Basecom: Xerr (to be changed when upgrading to mixin version)
In DynAstVO: X_error
In Exoplanets: X_error_min; X_error_max
In planets: X_uncertainty
TNOsarecool: X_sigma_plus, X_sigma_minus (to be changed?)

The associated UCDs start with stat.error; or stat.error;stat.min; & stat.error;stat.max;


Support for PDS3 detached labels (proposal)

Solution with datalink seems OK: data files under access_url and detached labels provided under datalink_url in a link table - although no attempt made to read them from the portal yet (use VIR unpublished service to test this).


Utypes

Need to clean up current doc (2.0). Utypes are = DM fields. They are supposedly used to identify the meaning of parameters and help e.g. tools to grab required quantities - This will not work in some areas though, e. g. with spectral tools as they currently use UCD instead of Utype for this purpose (not many tools appear to actually rely on Utype in fact). See discussion here for usage (a bit old?): http://www.ivoa.net/documents/Notes/UTypesUsage/20130213/NOTE-utypes-usage-1.0-20130213.html

To handle this in practice:

  • Associate each parameter to a specific Utype in EPNCore - all names need to start with the epncore: prefix/namespace.
  • Then map epncore Utype to other DM (find equivalent parameter, or trace back the original templates of EPNCore parameters - often from ObsCore)
  • Reuse Utype from other DM each times it makes sense - TBC: the epncore: namespace is still required (even when using Utypes from other DM)
    This allows tools to handle EPNCore parameters like existing parameters from other DM, i.e., with no specific implementation
    Pb is that small differences in the use of parameters may preclude reusing the same Utype (TBC: does that applies to units also?)
  • Cross our fingers: known Utype (from other DMs) may be usable in existing tools (e.g. a tool supporting Provenance would grab equivalent info in EPN-TAP services transparently)
    Unclear if the use of the namespace makes it more complicated in tools.


Example of V2 with APIS database:

EPNcore Table v2

granule_uidgranule_gidobs_idaccess_urlaccess_formatthumbnail_url
o5g202x4q_x2doriginal_datao5g202x4qo5g202x4q_x2d.fitsimage/fitso5g202x4q_x2d_small.jpg
o5g202x4q_x2d_prevoriginal_data_previewo5g202x4qo5g202x4q_x2d.jpgimage/jpgo5g202x4q_x2d_small.jpg
o5g202x4q_procprocessed_datao5g202x4qo5g202x4q_proc.fitsimage/fitso5g202x4q_proc_small.jpg
o5g202x4q_proc_prevprocessed_data_previewo5g202x4qo5g202x4q_proc.jpgimage/jpgo5g202x4q_proc_small.jpg
o5g202x4q_cylcylindrical_projectiono5g202x4q o5g202x4q_cyl.jpgimage/jpgo5g202x4q_cyl_small.jpg
o5g202x4q_pol_npolar_projection_northo5g202x4q o5g202x4q_pol_n.jpgimage/jpgo5g202x4q_pol_n_small.jpg
o5g202x4q_pol_spolar_projection_southo5g202x4q o5g202x4q_pol_s.jpgimage/jpgo5g202x4q_pol_s_small.jpg