Request for Modification (RFM) for the UCD vocabulary towards UCDList v1.6

This page summarises the steps for Modifications and Updates proposed in the UCD List Maintenance recommendation. The UCDListMaintenancePage summarises the past and current RFMs.

The third (on going) iteration for the Request for modifications of UCD terms is summarized in the following content.

These terms are submitted for evaluation to the UCD science committee (see details in the Maintenance Specification document).

UCDList v1.6 Request For Modifications, from Jan 2024 to now

Proposed RFMs

---

Still in discussion from RFM 1.5

Proposals from StephaneErard (VEP-UCD-003)

• Proposed term: pos.moc
• Proposed description: Multi-order coverage
• Prefix: S
• Rationale: This term is used to tag a parameter containing a MOC (of any type, e.g, temporal, spatial, both, or any future MOC types)
• Used-in: EPNcore-2.0
• Discussion:The closest term available is pos.contour, but it doesn't seem adequate for multi-order coverage.

Sci-UCD Discussion: Three cases:

• a VOTable field is tagged with "pos.moc", in this case, the xtype attribute must be present to tell what is the encoding of the MOC
• "pos.moc" is in the EpnCore "measurement_type", to advertise the content of the product. Could be used with "dataproduct_type", to tell which axes are in the MOC (e.g., 'im' for classical MOC, 'mo' for STMOC, 'ts' for TMOC...)
• A VOTable field with URLs pointing to MOC products. The UCD would be "meta.ref.url;pos.moc"

ML: To be discussed again

BC [2023-06-22]: "meta.coverage" proposition discussed in VEP

Decision: implement "meta.coverage" as proposed in VEP-UCD-003.

---

• Proposed term: pos.projection
• Proposed description: Geometric projection
• Prefix: S
• Rationale: This term is used to tag a parameter containing the projection in use, or to identified parameters that have been projected onto a map (map projected products).
• Used-in: EPNcore-2.0
• Discussion: The current UCD List contains `pos.lambert` which is a specific projection type, which can't cover all the needs for geometric projection tagging.

BC [2023-06-22]: accepted in VEP, to be used with meta.id as primary.

If `pos.lambert` is not used currently in registry => possibly deprecate and move to `pos.projection.lambert` ?

---

Sci-UCD Discussion: during EPN-TAP RFC review, MarkTaylor proposed to have Q prefixes for both pos.moc and pos.projection.

Proposal from AdaNebot (VEP-UCD-004)

• Proposed term: time.period.oscillation
• Proposed description: Period of pulsation of a body (similar to solar pulsations or oscillations)
• Prefix: Q
• Rationale: This term is used to measure periods in oscillating phenomena.
• Used-in: https://academic.oup.com/mnras/article/487/3/3523/5512602
• Discussion: This term was proposed actually by Ada Nebot to consider oscillating phenomena on sky objects and cover possible time measurements used in these studies. This is a first term proposal for addition concerning oscillating stars, etc ...

2022-05-20 ML pending . More discussion to refine a clear definition

BC [2023-06-22]: no objection, but ML to discuss again with Ada.

BC [2024-03-21]: proposed term: "time.period.pulsation" with Label "Period of pulsation or oscillation of a body or a phenomenon"

Proposal from MarkusDemleitner & BaptisteCecconi (VEP-UCD-005, initially in UCDList 1.4 RFM)

• Proposed term: stat.histogram
• Proposed description: An array-like object with counts or ratios in bins
• Prefix: P
• Rationale:
• Used-in:
• Discussion: See VEP-UCD-005, and UCDList 1.4 RFM for the detailed discussion.

Sci-UCD Further Discussion: The same discussion as that of pos.moc applies for the use cases. Depending on how what is tagged, P or S flag should be used, and a specific dataproduct_type may also be needed to advertise a product in an ObsTAP or EPN-TAP table.

BC [2023-06-22]: what about using `stat.distribution` which would be more generic (with possible child `stat.distribution.cumulative` or `stat.distribution.histogram`) ?

BC [2024-03-21]: pending , needs more discussion

Proposed RFMs - suggestions for datasets issued in the science domain of gravitational waves

Proposal from M.Louys , S.Derriere for P. Chanial (VEP-UCD-011)

• Proposed term: stat.confidenceLevel
• Proposed label: Level of confidence for a detection or classification process
• Proposed description: a value to state the level of confidence for a detection, usually in percent (?).
• Prefix: P
• Rationale: GW studies produce maps of the sky with regions showing detection likelihood at particular confidence level . Such a confidence level can be a selection criteria for a map, or a dataset in general.
• Used-in: Gravitational waves catalogs
• Discussion:

BC [2023-06-22]: Would be useful for a column providing the confidence level used to derive min/max values of a distribution. Could be associated with `stat.stdev` or `stat.percentile` (would require change `stat.stdev` to Q). Examples:

• 3 sigma confidence level => value = 3 and ucd = `stat.confidenceLevel;stat.stdev`
• 95 % confidence level => value = 95 and ucd = `stat.confidenceLevel;stat.percentile`

To be checked if applicable in some Vizier tables.

BC [2024-03-21]:Proposed solution:

• New Term: stat.confidenceLevel
• Action: Addition
• Label: Level of confidence for a detection or classification process
• Prefix: P

• Update Term: stat.stdev
• Action: Modification
• Prefix: Q

Proposal from M.Louys , S.Derriere for P. Chanial (VEP-UCD-012)

• Proposed term: phys.inspiralSpin
• Proposed description: Effective inspiral spin in binary mergers  (used in GW detections )
• Prefix: Q
• Label: Effective inspiral spin in binary mergers  (used in GW detections )
• Rationale: In the study of binary mergers, the notion of spin for each component of the system

determines the dynamics of the system and differs from the angular momentum already defined as a ucd term.

• Used-in: LIGO Virgo Gravitational waves detection
• Discussion:
  • https://en.wikipedia.org/wiki/List_of_gravitational_wave_observations#List_of_gravitational_wave_events
  • https://www.quora.com/What-is-the-inspiral-spin-parameter-and-why-are-we-surprised-that-it-is-so-low-in-the-LIGO-events

BC [2024-03-21]:Proposed solution: Accept

Proposals from M.Louys , S.Derriere for P. Chanial (VEP-UCD-013)

• Proposed term: stat.falsePositive
• Proposed description: Related to false alarm or false positive detection
• Prefix: Q
• Description: Used to evaluate the rate of false alarm in detection problems.
• Rationale:Needed for support of catalogs of events detection in various multi- messenger data collections.
• Used-in: Gravitational waves detection (LIGO, Virgo) and in event detections more generally.
• Discussion:
  • Dataset examples:
    • https://en.wikipedia.org/wiki/List_of_gravitational_wave_observations#List_of_gravitational_wave_events
    • Vizier catalogs on GW

BC [2024-03-21]:Proposed solution: Accept

---

• Proposed term: stat.falseNegative
• Proposed description: Related to missed or false negative detection
• Prefix: Q
• Description: Used to evaluate the rate of missed or false negative detection.
• Rationale:Needed for support of catalogs of events detection in various multi- messenger data collections.
• Used-in: Gravitational waves detection (LIGO, Virgo) and in event detections more generally.
• Discussion:
  • Dataset examples:
    • https://en.wikipedia.org/wiki/List_of_gravitational_wave_observations#List_of_gravitational_wave_events

BC [2024-03-21]:Proposed solution: Accept

Proposal from B.Cecconi (VEP-UCD-014)

• Proposed term: phys.adu
• Proposed description: Analog to digital units, raw samples of an instrument, not converted into physical unit.
• Prefix: P
• Description: The raw data samples, often referred to as analog-to-digital-units (ADU). They are not converted yet into physical units. In other words, the transfer function of the instrument has not been applied.
• Rationale: This term would be useful to refer to raw data. This term was mentionned during the preparation of the ObsCore for Radioastronomy extension. The first atom word ('phys.') could be something else (like 'meta.').
• Used-in:
  • Dataset examples:
    • cassini_rpws.epn_core table (on voparis-tap-maser TAP server), containing raw, calibrated and derived products.
• Discussion [2024-03-21]
  • in the ObsCore Radio extension (as of this date): "In the current UCD vocabulary (UCD1+ controlled vocabulary - Updated List of Terms Version 1.5) there appear to be no primary words suitable to describe raw SD data. o_ucd=phot.flux.density, which fits well for appropriate data, does not seem appropriate, since the single dish measured quantity is expressed in raw counts coming from the digitisation of a voltage signal generated in the receiver chain by the incoming electromagnetic field. Further discussion on o_ucd is ongoing within the Semantics WG."
  • A proposal could be to use the secondary word "stat.uncalib" to indicate the "raw" status of the quantity, but a primary UCD word must be used, such as "phot.count", or "phys.current" (or "phys.voltage" which doesn't exist yet)
  • Conceptually the "stat.adu" is referring to the output of an analogue-to-digital sampler.
  • If we add "phys.voltage", a solution would be phys.voltage;stat.uncalib

• BC [2024-03-21]: Proposed change:
  • New term: phys.voltage
  • Prefix: Q
  • Description: Electric potential difference over a distance or measured by an instrument.

Proposal from M.Louys (VEP-UCD-015)

• Proposed term: phys.pulseHeight or phys.pulse.amplitude
• Proposed description: Amplitude measured by a pulse analyser after a particle or radiation detector (photon, gamma ray, ...).
• Prefix: Q
• Description: In event-list data product obtained in X-ray or Gamma-ray, the need to characterise the raw measure provided by the detector has appeared. A similar requirement was formulated for radio data as well.
• Rationale: This term would be useful to refer to raw data coming out of a detector and not calibrated yet. The need for such a term was mentionned during the preparation of the IVOA Note "VO Data discovery for High Energy data sets".
• Used-in: Chandra event-list, CTA event-list before calibration.
• Discussion:
  • There may be an overlap with the proposal for "phys.adu" in VEP-UCD-14.txt. To be discussed.
  • [2024-03-21] Existing UCD for pulse: "src.var.pulse" and for amplitude: "src.var.amplitude" (but with E prefix, which should be changed Q to have this word applied to any other primary word)
• BC [2024-03-21]: Proposed change: "src.var.amplitude" prefix set to "Q".
  • proposed solution: * "src.var.amplitude;src.var.pulse;stat.uncalib"

Proposed RFMs for Ambiant Conditions at telescopes sites

Proposals from A. Micol , ESO Archive

List of terms and concepts to cover (open for discussion) : ESO VLT Ambient parameters with new terms proposed.

Example Proposal for new term humidity under the subtree obs.atmos.

• Proposed term: obs.atmos.humidity
• Proposed description:
• Prefix: S
• Rationale: Ambient conditions measure various physical parameters at telescope site to monitor turbulence, seeing, etc.
• Used-in: ESO FITS keywords for observations at Paranal , etc .
• Discussion: Some of these parameters are general, some have a very specific definition for the assessment of physical conditions at the telescope's site. Their meaning may be restricted to a the local definition of the measure at the site. In this case , such terms can be branched under the cud node 'obs.atmos'.

On the contrary general terms can be branched below phys.*.

The proposal for adding a obs.atmos subtree to the UCD tree is explained in Proposal for obs.atmos subtree

---

Proposed RFMs - modification suggestions for planetary science

Proposals from J. Berthier , IMCCE, Paris Observatory

List of terms and concepts to cover (open for discussion) : UCDs Requests for Planetary data

See VEP-UCD-016 document for discussions.

Generic comment: We need "Used-in" sections to be filled.

Summary for iteration UCDList1.5 to UCDList1.6

UCD proposal applied as changes for UCDList1.6

Term	VEP-UCD link	Modification Type	Decision
xxx	VEP-UCD-yy.txt	action	approved

UCD proposals rejected and solved

Term	VEP-UCD link	Suggestion	Use instead
pos.moc	VEP-UC-003	meta.coverage for general	meta.coverage
		rely on xtype to clarify ST-Moc, T-Moc, etc.

UCD proposals not solved yet --> for next step

Term	VEP-UCD link	Modification Type	Decision