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

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 second (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.5 Request For Modifications, from June 2021 to Oct 2021


Accepted RFMs


Pending RFMs

From UCDList 1.3 RFM: pos.rotation, pos.euleraAngle, pos.quaternion, ... pos.heliocentric, pos.heliographic, etc .. postponed for better understanding

From UCDList 1.4 RFM: stat.histogram (use case to be further detailed). See further discussion below.


Rejected RFMs

  • phys.rotMeasure (concept already existing as phys.polarization.rotMeasure)

Proposed RFMs

Proposals from VeroniqueDelouille (VEP-UCD-001)

  • Proposed term: stat.skew
  • Proposed description: Statistical skewness, third moment of normalised data distribution function
  • Prefix: P
  • Rationale: This term was proposed actually by Veronique Delouille after FITSKeyword evaluation for solar datasets. Would complete the stat properties within the UCD tree. Would be useful for other data as well.
  • Used-in: SDO/AIA FITS keywords
  • Discussion:The statistical moments (except for the mean value) don't have the same units as the observed quantity, and thus those are another quantity extracted from the data. We propose to set the prefix to P.
2022-01-17 ML: to be proposed for adoption to the UCD Board


  • Proposed term: stat.kurtosis
  • Proposed description: Statistical kurtosis, fourth moment of normalised data distribution function
  • Prefix: P
  • Rationale: This term was proposed actually by Veronique Delouille after FITSKeyword evaluation for solar datasets. Would complete the stat properties within the UCD tree. Would be useful for other data as well.
  • Used-in: SDO/AIA FITS keywords
  • Discussion: Skewness is related to the asymetry of the distribution, and the kurtosis helps to identify outliers.
2022-01-17 ML: to be proposed for adoption to the UCD Board


  • Proposed term: stat.mad
  • Proposed description: Statistical median absolute deviation from median
  • Prefix: P
  • Rationale: This term was proposed actually by Veronique Delouille after FITS Keyword evaluation for solar datasets. This is a robust quantity to measure the spread of values in a data set when the statistic is not a normal distribution. Would complete the stat properties within the UCD tree. Would be useful for other data as well.
  • Used-in: ?
  • Discussion: Similar to stat.stdev, but using median operators instead of the mean.
2022-01-17 ML proposal : we may need more examples of this statistical feature and an example to see it in action ?

Proposals from BaptisteCecconi (VEP-UCD-002)

UCD-SCI Answer: REJECTED. This term already exist as phys.polarization.rotMeasure

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

  • 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.

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

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.

Proposal from YanGrange (VEP-UCD-006)

  • Proposed term: meta.ref.epic
  • Proposed description:ePIC identifier (dereferenceable)
  • Prefix: P
  • Rationale: Data sets that have an ePIC PID could be referenced through this, chosen to propse this at the same level as meta.ref.doi.
  • Used-in: (LoTSS DR2 will use this one for each data product if accepted)
  • Discussion: See http://mail.ivoa.net/pipermail/semantics/2021-November/002893.html for the detailed discussion. In conclusion we have a few options. One of them is to have meta.ref.pid that covers all Persistent Identifiers, but it is a bit confusing that meta.ref.doi already exists. Alternatively, and this is what I would propose, we could have a meta.ref.XXX for each PID type so that it is clear how it should be resolved. This may lead to a growth in numbers of PID entries. Ideally we would have a P being meta.ref.pid and meta.ref.doi, meta.ref.epic, etc as S keywords but that would break backwards compatibility and I am not sure how problematic that would be (basically changing an existing P type UCD to S type). Making the new meta.ref.XXX of type Q, and changing meta.ref.doi to Q as well could be a way to move towards this while not breaking old data sets, but this may also be more confusing.
  • From a client perspective, meta.ref.handle could also be an option because in essence handles (that can be resolved through handle.net) are all resolvable the same way and that would be a very client-centric way of looking at it.

  • Proposed term: meta.ref.orcid
  • Proposed description:ORCID identifier (dereferenceable)
  • Prefix: P
  • Rationale: The ORCID is widely used as a person-identifier in science. Data ownership in tables could be linke to researchers using it
  • Used-in:
  • Discussion: See meta.ref.epic discussion. The reason to add this is not so much a very concrete use case, but mostly that the ORCID is the type of PID that would need to be included in tables of data so since I propse changes, I chose to include this one too even if this may lead for it to be refused for the lack of use cases.
ML: more discussion needed for the organisation of various Pids/ check on the semantic list.

<!--

-->
Topic revision: r9 - 2022-01-17 - MireilleLouys
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback