Update UCD section relative to last discussion with Semantics WG by loumir · Pull Request #61 · ivoa/HighEnergyObsCoreExt

loumir · 2026-05-27T17:54:26Z

I would like the results of the semantics WG discussions that happened to appear in this note. This was part of the work all along the year.
Therefore in the listed requirements for UCD we should use the terms that have been recently discussed and approved by the semantics group .
I have updated various parts of this section and included %comments to explain the changes .

…ics WG

Clarified the usage of Particle Data Group Identifier for particle detection and the electron case.

loumir

Please review the UCD changes, a few inconsistencies may still be hidden.
thanks

showing the result of recent discussions with Semantics WG

loumir

thanks for your careful reading.
many places changed due to the UCD related elements .

The different roles between the column names , using the dedicated language of the specific domain , here high energy , and the UCD terms using a more general language to foster crosswalks between the various usage in other spectral domains , should be clear in the note.

iannevans

Added a few comments and recommended changes where I thought they made sense.

iannevans · 2026-05-27T20:05:48Z

 \subsubsection{Instrument-related Quantities}

-We propose to add a new UCD {\em instr.event\/} as the base of the hierarchy to describe instrument-related properties of particle events detected by \gls{HEA} detectors.  Initially, we propose a small set of event-related UCDs that identify key properties that are particularly important for \gls{HEA} data analysis.
+We propose to add a new UCD {\em instr.detection\/} as the base of the hierarchy to describe instrument-related properties of particle events detected by \gls{HEA} detectors.  Initially, we propose a small set of event-related UCDs that identify key properties that are particularly important for \gls{HEA} data analysis.


As I've argued before, instr.detection is in my view worse than instr.event because "detection" has a real and widely used meaning.

Agree with you. But as it is just an UCD, I am in favor to make this compromise

iannevans · 2026-05-27T20:33:26Z

-P & {\em stat.error.positive\/}  & Positive statistical error  \cr
-P & {\em stat.lowerlimit\/}  & Lower limit \cr
-P & {\em stat.upperlimit\/}  & Upper limit \cr
+% Mireille we cannot have these terms in the UCD tree ; that would imply importing all possible encoding of any kind 


I disagree about phys.particle.pdgid. phys.particle.pdgid is a UCD that identifies a Particle Group Identifier, for example a column in a FITS file that records the pdgid for each event. It's not the same as UCDs that encode all possible pdgids as part of the UCD name.

Ok for me Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

+1 Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Updated UCD descriptions for event grade, type, and physical quantities in HighEnergyObsCoreExt.tex.

loumir

I hope I filled the changes . I am not used to the GitHub on line editor , so what is taken into account for the PDF compilation is not clear to me.

loumir

test

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

bkhelifi

Thanks a lot to all! OK for me

bkhelifi · 2026-06-02T13:19:51Z

@iannevans: a very last short question about proposal_id (section 3.11). When we have a list of IDs, should we recommand to use # as separator? If you agree, you can make directly the change and do the merge!

iannevans · 2026-06-02T15:24:42Z

@iannevans: a very last short question about proposal_id (section 3.11). When we have a list of IDs, should we recommand to use # as separator? If you agree, you can make directly the change and do the merge!

We want to bring proposal_id into line with facility_name and instrument_name, which are the other two "provenance" attributes in ObsCore. They already support multiple values. For facility_name, the REC says "For combined observations stemming from multiple facilities the name may contain a list of comma separated strings, or the word "Many"; if the list is too long, as defined in the VODataservice specification." and instrument_name states "Multiple values are also allowed for complex observations as defined for facility name."

For proposal_id, could recommending adding the same sentence (i.e.,) "Multiple values are also allowed for complex observations as defined for facility name." but I'm not convinced it's necessary.

iannevans · 2026-06-02T15:24:45Z

@iannevans: a very last short question about proposal_id (section 3.11). When we have a list of IDs, should we recommand to use # as separator? If you agree, you can make directly the change and do the merge!

We want to bring proposal_id into line with facility_name and instrument_name, which are the other two "provenance" attributes in ObsCore. They already support multiple values. For facility_name, the REC says "For combined observations stemming from multiple facilities the name may contain a list of comma separated strings, or the word "Many"; if the list is too long, as defined in the VODataservice specification." and instrument_name states "Multiple values are also allowed for complex observations as defined for facility name."

For proposal_id, could recommending adding the same sentence (i.e.,) "Multiple values are also allowed for complex observations as defined for facility name." but I'm not convinced it's necessary.

iannevans · 2026-06-02T18:20:53Z

 \paragraph{Event Grade}

-For imaging X-ray instruments (especially those based on CCD detectors), detected events typically deposit charge into more than a single detector pixel.  The events are assigned a ``grade'' based on how charge is deposited into the central pixel and surrounding pixels, and the grade information is essential for data analysis since typically only a subset of grades will correspond to valid events.  We propose to add a new UCD {\em instr.event.grade\/} that identifies event grades.
+For imaging X-ray instruments (especially those based on CCD detectors), detected events typically deposit charge into more than a single detector pixel.  The events are assigned a ``grade'' based on how charge is deposited into the central pixel and surrounding pixels, and the grade information is essential for data analysis since typically only a subset of grades will correspond to valid events.  We propose to use these combined UCD terms {\em meta.code.class;instr.detection\/} to provide the UCD string for the {\bf event\_grade} column.


"for the {\bf event_grade} column" is not correct because there is no standardization of the names of columns such as this from instrument to instrument or from facility to facility. We certainly don't use the column name "event_grade" anywhere: our ACIS event lists have two columns that identify event grades: grade and fltgrade (but other instruments/facilities use different column names). This is the same issue I've raised repeatedly - without a UCD specifically for event grade, "meta.code.class;instr.detection" does nothing to help interoperability across HEA facilities.

iannevans · 2026-06-02T18:32:56Z

 For many X-ray and gamma-ray instruments, the signal observed in a given detector spectral channel is the result of event counting and would typically be recorded as a Pulse Height Amplitude (PHA), or perhaps a Pulse Invariant (PI) value that is calculated from PHA by applying an appropriate gain calibration.  The PHA (or PI) can be related to the incident particle energy by applying the appropriate {\bf response-function}, and higher data calibration level products may replace or augment these values with quantities such as energy, or perhaps particle or energy flux.

-There is currently no UCD defined for a raw pulse height amplitude measure like PHA (or PI). PHA is such an important quantity to \gls{HEA} datasets that we propose adding a new UCD {\em instr.event.pulseHeight\/} for these raw data values.  We note that the background signal (both of instrumental and cosmological origin) may be significant for many \gls{HEA} detectors and so the detected events may be unrelated to any observed source on the sky.  For Cherenkov neutrino detectors, this quantity might refer to the number of observed photon hits from secondary particle photon generation.
+There is currently no UCD defined for a raw pulse height amplitude measure like PHA (or PI). PHA is such an important quantity to \gls{HEA} datasets that we propose adding a new UCD {\em instr.pulse\/} for these raw data values, that can be combined with more general UCD terms to describe parameters of the pulse, like {\em instr.pulse;stat.max}, {\em instr.pulse;arith.sum} as an integrated quantity, {\em instr.pulse;stat.fwmh}, etc.  We note that the background signal (both of instrumental and cosmological origin) may be significant for many \gls{HEA} detectors and so the detected events may be unrelated to any observed source on the sky.  For Cherenkov neutrino detectors, this quantity might refer to the number of observed photon hits from secondary particle photon generation.


Suggested change

There is currently no UCD defined for a raw pulse height amplitude measure like PHA (or PI). PHA is such an important quantity to \gls{HEA} datasets that we propose adding a new UCD {\em instr.pulse\/} for these raw data values, that can be combined with more general UCD terms to describe parameters of the pulse, like {\em instr.pulse;stat.max}, {\em instr.pulse;arith.sum} as an integrated quantity, {\em instr.pulse;stat.fwmh}, etc. We note that the background signal (both of instrumental and cosmological origin) may be significant for many \gls{HEA} detectors and so the detected events may be unrelated to any observed source on the sky. For Cherenkov neutrino detectors, this quantity might refer to the number of observed photon hits from secondary particle photon generation.

There is currently no UCD defined for a raw pulse height amplitude measure like PHA (or PI). PHA is such an important quantity to \gls{HEA} datasets that we propose adding a new UCD {\em instr.pulse\/} for these raw data values. {\em instr.pulse\/} can be combined with more general UCD terms to describe pulse parameters recorded by the pulse height analyzer electronics. Typically, PHA corresponds to the integrated signal detected by the electronics, which could therefore be described using the UCD {\em instr.pulse;arith.sum}. For some detectors, additional pulse parameters such as the peak pulse height or pulse width are important, and could be described by UCDs {\em instr.pulse;stat.max} and {\em instr.pulse;stat.fwmh}, respectively, and so on. We note that the background signal (both of instrumental and cosmological origin) may be significant for many \gls{HEA} detectors and so the detected events may be unrelated to any observed source on the sky. For Cherenkov neutrino detectors, this quantity might refer to the number of observed photon hits from secondary particle photon generation.

iannevans · 2026-06-02T19:19:19Z

 \paragraph{Event Type}

-For \gls{VHE} (and GeV) gamma-ray data, there is the notion of event type (see \S~\ref{sec:evttype}) that can be mandatory for some data releases.  We propose to add a new UCD {\em instr.event.type\/} that identifies these data values.
+For \gls{VHE} (and GeV) gamma-ray data, there is the notion of event type (see \S~\ref{sec:evttype}) that can be mandatory for some data releases.  We propose to use a combined UCD {\em meta.code.class;instr.detection\/} to tag the proposed {\bf event\_type} parameter.


Would "to tag event type" make more sense? Similar comment to "event_grade": assuming all instruments/facilities use "event_type" as a column name is too optimistic.

iannevans · 2026-06-02T19:20:46Z

-One should note that electrons are denoted by the UCD {\em phys.electron\/} in the current version of the UCD list \citep{2024ivoa.spec.1218C} and are inappropriately not grouped under the {\em phys.particle\/} hierarchy.  This causes some inconsistencies that could be solved by marking {\em phys.electron\/} (and {\em phys.electron.degen\/}) as obsolete or not recommended, and adding the term  {\em phys.particle.electron\/} to the UCD list.
+One should note that electrons are denoted by the UCD {\em phys.electron\/} in the current version of the UCD list \citep{2024ivoa.spec.1218C} and are not grouped under the {\em phys.particle\/} hierarchy.
+Marking {\em phys.electron\/} (and {\em phys.electron.degen\/}) as obsolete or not recommended and adding the term  {\em phys.particle.electron\/} to the UCD list would improve the consistency of the {\em phys.particle\/} branch.
+However, as many data sets in the IVOA projects may already be tagged with {\em phys.electron\/} this may require maintenance costs that should be evaluated. 


Suggested change

However, as many data sets in the IVOA projects may already be tagged with {\em phys.electron\/} this may require maintenance costs that should be evaluated.

However, as many data sets in the IVOA projects may already be tagged with {\em phys.electron\/} this may incur maintenance costs that should be evaluated.

iannevans

I made a few suggestions but this is definitely converging. There's a question for Bruno hidden in my comment on the description of phys.pulse ;-)

loumir and others added 3 commits May 27, 2026 19:46

Update UCD discussion section relative to last discussion with semant…

5815b90

…ics WG

Update UCD terms and particle identifier usage

a22fef9

Clarified the usage of Particle Data Group Identifier for particle detection and the electron case.

Update UCDs from Semantics WG discussion part2

2120e6e

loumir commented May 27, 2026

View reviewed changes

loumir added 2 commits May 27, 2026 20:38

Update UCD terms for event-list and pulse height

36aabbe

showing the result of recent discussions with Semantics WG

Update UCD for event as instr.detection

bd8c626

loumir commented May 27, 2026

View reviewed changes

iannevans requested changes May 27, 2026

View reviewed changes

loumir and others added 5 commits May 28, 2026 15:33

Update HighEnergyObsCoreExt.tex

414356e

Ok for me Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

typos

befb151

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

formalizing line 540

0de2202

+1 Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

l 172

f8559c9

+1 Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Refine UCD terms for event properties in HEA data

089fa73

Updated UCD descriptions for event grade, type, and physical quantities in HighEnergyObsCoreExt.tex.

loumir commented May 28, 2026

View reviewed changes

Fix formatting of event_type parameter in LaTeX file

bc65706

loumir commented May 28, 2026

View reviewed changes

loumir and others added 2 commits June 2, 2026 11:33

update with suggestion about phys.particle.electron

d7d697d

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

9c64623

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

loumir requested a review from iannevans June 2, 2026 09:38

bkhelifi and others added 10 commits June 2, 2026 12:09

Update HighEnergyObsCoreExt.tex

bda8f9d

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

99190a4

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

227c20e

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

a472252

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

b7460ee

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

4ab6409

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

8e3d36c

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

ae4cb3a

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

ffa83f5

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

Update HighEnergyObsCoreExt.tex

a497f98

Co-authored-by: Ian Nigel Evans <ievans@cfa.harvard.edu>

bkhelifi approved these changes Jun 2, 2026

View reviewed changes

iannevans reviewed Jun 2, 2026

View reviewed changes

	However, as many data sets in the IVOA projects may already be tagged with {\em phys.electron\/} this may require maintenance costs that should be evaluated.
	However, as many data sets in the IVOA projects may already be tagged with {\em phys.electron\/} this may incur maintenance costs that should be evaluated.

Conversation

loumir commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loumir left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loumir left a comment

Choose a reason for hiding this comment

Uh oh!

iannevans left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

iannevans May 27, 2026

Choose a reason for hiding this comment

Uh oh!

bkhelifi Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

iannevans May 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

loumir left a comment

Choose a reason for hiding this comment

Uh oh!

loumir left a comment

Choose a reason for hiding this comment

Uh oh!

bkhelifi left a comment

Choose a reason for hiding this comment

Uh oh!

bkhelifi commented Jun 2, 2026

Uh oh!

iannevans commented Jun 2, 2026

Uh oh!

iannevans commented Jun 2, 2026

Uh oh!

iannevans Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

iannevans Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

iannevans Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

iannevans Jun 2, 2026

Choose a reason for hiding this comment

Uh oh!

iannevans left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

loumir commented May 27, 2026 •

edited

Loading

loumir left a comment •

edited

Loading

iannevans Jun 2, 2026 •

edited

Loading