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

2022-02 MD: modified definitions proposed

2022-02. VD : better stat.skewness for the complete label see

2022-03-14 ML: updated definition in VEP-UCD-001 on vespa repo

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

2022-03-14 ML: updated definition in VEP-UCD-001 on vespa repo


  • 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 statistics is not a normal distribution. Would complete the stat properties within the UCD tree. Would be useful for other data as well.
  • Used-in: ? This terms is used for a robust estimation of standard deviation in signal ( https://en.wikipedia.org/wiki/Median_absolute_deviation ) and hence I think we should keep it. But at the moment I cannot really provide an example of its use in solar physics. I checked the Solarnet FITS keywords recommendation (live document is at http://sdc.uio.no/open/solarnet/ ) and what they define as 'datamad' as the mean absolute deviation from the mean, avg( abs( x-avg(x) ) ), because this is what they use for the Gregor high resolution telescope.
  • 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 ?

2022-02-01 VD adds some precisions on the definitions

2022-03-14 ML: updated definition in VEP-UCD-001 on vespa repo

2022-05-20 ML: include in proposed Endorsed Note PEN UCDList 1.5

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 ...
2022-05-20 ML pending . More discussion to refine a clear definition

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 (Discussion for IDs on Semantics list )

  • 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.
Semantics: Proposal to adopt several flavors of ids , as meta.ref.doi used for their distinguished role and not only the way they are resolved. completed VEP-UCD-008.txt and created VEP-UCD-006.txt

Sci-UCD Further Discussion: all ids approved

Proposal from StephaneErard (VEP-UCD-007)

  • Proposed term: spect.line.intIntensity
  • Proposed Description: integrated line intensity (on a band)
  • Prefix: P
  • Rationale: This term is proposed to support spectroscopy of solids, which have broad bands.
This will be used by the SSHADE bandlist service (and possibly other services in this field) and may be computed from observational data to compare with laboratory data. Eventually, this may be used by CASSIS to handle solid spectroscopy.
  • Used-in:
  • Discussion: Integrated intensity is different from Intensity (at band center) which is used in parallel, and eqWidth (equivalent width) is not relevant in this field.
ML: suggestion to use the combined UCD spect.line.intensity;arith.sum

Proposal from MireilleLouys (VEP-UCD-009)

  • Proposed term: stat.percentile
  • Proposed Description: Percentile of a statistical distribution
  • Prefix: Q
  • Rationale: This term is proposed to characterize a percentile for a distribution of values in a dataset.
It is parametrized by another metadata providing the level of confidence at which this percentile value is computed e.g 68th percentile, 25th percentile etc ...

  • Used-in: Comparison of distributions within catalogs.
Sci-UCD Further Discussion: approved

Proposal from Mireille Louys VEP-UCD-010.txt

  • * Term: meta.curation
  • * Proposed Action*: Amendment
  • * New Label: Parameter informing about the curation of the data.
  • * New Prefix: Q

  • * Description: Parameter informing about the curation of the data.
  • * Rationale: This UCD was originally defined with a P prefix and focussed on the identity of people involved in the task of curation of the data. It has been used more widely to qualify some other properties dealing with curation. This proposal suggests to relax the suffix from P to Q, and to broaden the meaning the label.
* * Used-in: Simple Spectral Access protocol, SSA v1.1 uses "meta.version;meta.curation" or "meta.ref.url;meta.version"

* * Discussion: The simple ucd='meta.curation' indeed was used for the identifier of a person /organisation doing the curation. ucd='meta.id;meta.curation' should be encouraged in the future instead. Further combinations can be used like "meta.mail;meta.curation" for the email of the people in charge of the data curation, "time.processing;meta.curation" for the date of the executed curation task, "meta.ref.url;meta.curation" for linking some documentation on the applied curation, etc..

Sci-UCD Further Discussion: approved

Summary - UCD applied changes for UCDList1.5

Term VEP-UCD link Modification Type Decision
stat.skewness VEP-UCD-001.txt addition accepted for insertion
stat.kurtosis VEP-UCD-001.txt addition accepted for insertion
stat.mad VEP-UCD-001.txt addition accepted for insertion
meta.ref.pid VEP-UCD-006.txt addition accepted for insertion
meta.ref.epic      
meta.ref.orcid      
meta.ref.rorid VEP-UCD-008.txt addition all 3 accepted for insertion
stat.percentile VEP-UCD-009.txt addition approved for insertion
meta.curation VEP-UCD-010.txt amendment approved

<--! * Set ALLOWTOPICRENAME = TWikiAdminGroup -->

Topic revision: r13 - 2022-06-20 - 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