From c690630a5e39067014007a4986d3a538baacecbb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Kh=C3=A9lifi?= <khelifi@in2p3.fr>
Date: Fri, 25 Jul 2025 13:11:52 +0200
Subject: [PATCH 1/4] update

---
 HighEnergyObsCoreExt.tex | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/HighEnergyObsCoreExt.tex b/HighEnergyObsCoreExt.tex
index de545d4..1509b08 100644
--- a/HighEnergyObsCoreExt.tex
+++ b/HighEnergyObsCoreExt.tex
@@ -237,38 +237,42 @@ \subsection{{\em ev\_xel}}
 
 \subsection{{\em s\_ref\_energy\/}/{\em em\_ref\_energy\/}/{\em s\_ref\_oaa\/}/{\em em\_ref\_oaa}}
 
-For HEA datasets that typically span decades of energy, both spatial resolution and sky coverage, and spectral resolution, can be strongly dependent on particle energy.  The ObsCore Recommendation suggests that in such circumstance a {\em characteristic\/} value be specified for the spatial and spectral characterization attributes ({\em e.g.\/}, {\em s\_fov\/}, {\em s\_region\/}, {\em s\_resolution\/}, {\em em\_res\_power\/}, {\em em\_resolution\/}).  We propose adding optional attributes ({\em s\_ref\_energy\/} for spatial characterization attributes and {\em em\_ref\_energy\/} for spectral characterization attributes) that define the energy (in units of eV) at which these characteristic values are specified.
+For \gls{HE} datasets that typically span decades of energy, both spatial resolution and sky coverage, and spectral resolution, can be strongly dependent on particle energy.  The ObsCore Recommendation suggests that in such circumstance a {\em characteristic\/} value be specified for the spatial and spectral characterization attributes ({\em e.g.\/}, {\em s\_fov\/}, {\em s\_region\/}, {\em s\_resolution\/}, {\em em\_res\_power\/}, {\em em\_resolution\/}).  We propose adding optional attributes ({\em s\_ref\_energy\/} for spatial characterization attributes and {\em em\_ref\_energy\/} for spectral characterization attributes) that define the energy (in units of eV) at which these characteristic values are specified.
 
-For some HEA datasets these attributes vary strongly with position in the field of view, typically as a function of off-axis angle ({\em i.e.\/}, the angular separation of the target or source from the telescope optical axis). We similarly propose adding optional attributes ({\em s\_ref\_oaa\/} for spatial characterization attributes and {\em em\_ref\_oaa\/} for spectral characterization attributes) that define the off-axis angle (in units of arcmin) at which these characteristic values are specified.
+For some \gls{HE} datasets, these attributes vary strongly with position in the field of view, typically as a function of off-axis angle ({\em i.e.\/}, the angular separation of the target or source from the telescope optical axis). We similarly propose adding optional attributes ({\em s\_ref\_oaa\/} for spatial characterization attributes and {\em em\_ref\_oaa\/} for spectral characterization attributes) that define the off-axis angle (in units of degrees) at which these characteristic values are specified.
 
 \subsection{{\em t\_intervals}}
 
-The global time bounds described by {\em t\_min\/}/{\em t\_max} in general are not sufficiently flexible when representing HEA datasets and advanced data products from any waveband.  The former are typically composed of many \gls{STIs}/\gls{GTIs}, where data are only valid during the stable or good intervals, while advanced data products may be constructed from multiple progenitor observations that can span decades from the start time of the first observations to the stop time of the last observation (albeit very sparsely).  For both cases, data queries using only {\em t\_min\/}/{\em t\_max} may not be adequate to determine whether useful scientific data coincide with a transient cosmic phenomenon.  In such cases, a more detailed knowledge of the observation time coverage is necessary.  We propose to add a new optional attribute {\em t\_intervals} that would contain the list of observation intervals or STIs/GTIs as a TMOC description following the \gls{MOC} IVOA standard  \citep{2022ivoa.spec.0727F}. This element could then be compared across data collections to make the data set selection via simple intersection or union operations in TMOC representation.
+The global time bounds described by {\em t\_min\/}/{\em t\_max} in general are not sufficiently flexible when representing \gls{HE} datasets and advanced data products from any waveband.  The former are typically composed of many \gls{STIs}/\gls{GTIs}, where data are only valid during the stable or good intervals, while advanced data products may be constructed from multiple progenitor observations that can span decades from the start time of the first observations to the stop time of the last observation (albeit very sparsely).  For both cases, data queries using only {\em t\_min\/}/{\em t\_max} may not be adequate to determine whether useful scientific data coincide with a transient cosmic phenomenon.  In such cases, a more detailed knowledge of the observation time coverage is necessary.  We propose to add a new optional attribute {\em t\_intervals} that would contain the list of observation intervals or STIs/GTIs as a TMOC description following the \gls{MOC} IVOA standard  \citep{2022ivoa.spec.0727F}. This element could then be compared across data collections to make the data set selection via simple intersection or union operations in TMOC representation.
 
 \subsection{{\em energy\_min\/}/{\em energy\_max\/}}
 
-The existing attributes {\em em\_min\/} and {\em em\_max\/} that define the coverage of the spectral axis (defined as wavelength expressed in units of m) are not user friendly for HEA where datasets are generally selected according to an energy range ({\em i.e.\/}, inverse wavelength) in units of eV (or scaled units of eV, for example keV, MeV, GeV, TeV, PeV).  Unlike the radio domain where $\lambda = c/\nu$, where $c$ is an almost universally remembered physical constant, the conversion $\lambda = hc/E$ is not simple for the user to express.  As the spectral range covered by HE data is many decades larger than for other wavebands, the accurate numerical representations of typical HE spectral ranges as {\em em\_min\/}/{\em em\_max\/} requires quantities with many digits of precision and exponents ranging from $\sim\!10^{-5}$--$10^{-22}$.  Since specification of the spectral range is largely fundamental to data discovery in the HE regime, we propose to add attributes {\em energy\_min\/} and {\em energy\_max\/} that specify the minimum and maximum spectral range values in units of eV\null.  Note that the sense of these attributes is {\em opposite\/} that of {\em em\_min\/} and {\em em\_max\/} because of the inverse wavelength relationship between energy and wavelength, so numerical comparisons must be transposed ({\em e.g.\/}, $E>E_{\rm thresh}$ becomes $\lambda<hc/E_{\rm thresh}$).  (An alternate approach would be to add attributes {\em em\_min\_energy\/} and {\em em\_max\_energy\/} that represent the energies corresponding to {\em em\_min\/} and {\em em\_max\/} in units of eV\null.  This is less desirable since queries on an energy would need to be specified as {\em em\_max\_energy\/}${}\leq E <{}${\em em\_min\_energy\/}, which is likely confusing.)
+The existing attributes {\em em\_min\/} and {\em em\_max\/} that define the coverage of the spectral axis (defined as wavelength expressed in units of m) are not user friendly for \gls{HE} where datasets are generally selected according to an energy range ({\em i.e.\/}, inverse wavelength) in units of eV (or scaled units of eV, for example keV, MeV, GeV, TeV, PeV).  Unlike the radio domain where $\lambda = c/\nu$, where $c$ is an almost universally remembered physical constant, the conversion $\lambda = hc/E$ is not simple for the user to express.  As the spectral range covered by \gls{HE} data is many decades larger than for other wavebands, the accurate numerical representations of typical \gls{HE} spectral ranges as {\em em\_min\/}/{\em em\_max\/} requires quantities with many digits of precision and exponents ranging from $\sim\!10^{-5}$--$10^{-22}$.  Since specification of the spectral range is largely fundamental to data discovery in the \gls{HE} regime, we propose to add attributes {\em energy\_min\/} and {\em energy\_max\/} that specify the minimum and maximum spectral range values in units of eV\null.  Note that the sense of these attributes is {\em opposite\/} that of {\em em\_min\/} and {\em em\_max\/} because of the inverse wavelength relationship between energy and wavelength, so numerical comparisons must be transposed ({\em e.g.\/}, $E>E_{\rm thresh}$ becomes $\lambda<hc/E_{\rm thresh}$).  (An alternate approach would be to add attributes {\em em\_min\_energy\/} and {\em em\_max\_energy\/} that represent the energies corresponding to {\em em\_min\/} and {\em em\_max\/} in units of eV\null.  This is less desirable since queries on an energy would need to be specified as {\em em\_max\_energy\/}${}\leq E <{}${\em em\_min\_energy\/}, which is likely confusing.)
 
 \subsection{{\em obs\_mode}}
 
-Many HEA instruments may be configured using multiple observing modes and these observing modes may significantly impact the structure and characteristics ({\em e.g.\/}, calibration accuracy) of the resulting observation datasets.  We propose to add an optional attribute {\bf obs\_mode} that allows the data provider to specify the observation mode for an observation.  Constraints on observation mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf obs\_mode} values will vary from facility to facility and from instrument to instrument.
+Many \gls{HE} instruments may be configured using multiple observing modes and these observing modes may significantly impact the structure and characteristics ({\em e.g.\/}, calibration accuracy) of the resulting observation datasets.  We propose to add an optional attribute {\bf obs\_mode} that allows the data provider to specify the observation mode for an observation.  Constraints on observation mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf obs\_mode} values will vary from facility to facility and from instrument to instrument.
 % Need more input/justification from facilities that support these capabilities
 
 \subsection{{\em scan\_mode}}
 
-Some HEA facilities can obtain observations using different spatial scan modes ({\em e.g.\/}, target pointing, spatial scans [including raster scans], slew data, and so on) that will affect the content of the observation.  We propose to add an optional attribute {\bf scan\_mode} that allows the data provider to specify the scan mode for an observation.  Constraints on scan mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf scan\_mode} values may vary from facility to facility and from instrument to instrument.
+Some \gls{HE} facilities can obtain observations using different spatial scan modes ({\em e.g.\/}, target pointing, spatial scans [including raster scans], slew data, and so on) that will affect the content of the observation.  We propose to add an optional attribute {\bf scan\_mode} that allows the data provider to specify the scan mode for an observation.  Constraints on scan mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf scan\_mode} values may vary from facility to facility and from instrument to instrument.
 % Need more input/justification from facilities that support these capabilities
 
 \subsection{{\em tracking\_mode}}
 
-Some HEA telescopes can obtain observations using different tracking modes ({\em e.g.\/}, sidereal rate, moving target [solar system] tracking, drift scans, and so on) that affect the content of the observation.  We propose to add an optional attribute {\bf tracking\_mode} that allows the data provider to specify the tracking mode for an observation.  Constraints on tracking mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf tracking\_mode} values may vary from facility to facility and from instrument to instrument.
+Some \gls{HE} telescopes can obtain observations using different tracking modes ({\em e.g.\/}, sidereal rate, moving target [solar system] tracking, drift scans, and so on) that affect the content of the observation.  We propose to add an optional attribute {\bf tracking\_mode} that allows the data provider to specify the tracking mode for an observation.  Constraints on tracking mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf tracking\_mode} values may vary from facility to facility and from instrument to instrument.
 % Need more input/justification from facilities that support these capabilities
 
 \subsection{{\em analysis\_mode}}
 
-Some HEA instruments allow data to be reduced/analyzed in multiple ways and these analysis modes may significantly impact the content of the reduced datasets, as well as calibration accuracy.  We propose to add an optional attribute {\bf analysis\_mode} that allows the data provider to specify the data reduction/analysis mode for an observation.  Constraints on analysis mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf analysis\_mode} values will vary from facility to facility and from instrument to instrument.
+Some \gls{HE} instruments allow data to be reduced/analyzed in multiple ways and these analysis modes may significantly impact the content of the reduced datasets, as well as calibration accuracy. We propose to add an optional attribute {\bf analysis\_mode} that allows the data provider to specify the data reduction/analysis mode for an observation. Constraints on analysis mode can provide a simple way to discover data sets for a specific facility/instrument combination. We note that permissible {\bf analysis\_mode} values will vary from facility to facility and from instrument to instrument.
 % Need more input/justification from facilities that support these capabilities
 
+\subsection{{\em event\_type}}
+
+Some \gls{HE} instruments allow data to have event partitioning based on a data analyis quality associated with the reconstruction and the discrimination. Some analyses can flag each event by a quality label, partitionning the dataset into strictly disjoint event subsets. And for each quality label, a set of \glspl{IRF} should be derived and can be render public.  We propose to add an optional attribute {\bf event\_type} that specifies the data quality flag for an observation. It will allow the data provider to split the event list into several event lists labelled by an unique \bf event\_type} for a given observation, and to distribute their associated \glspl{IRF}. Constraints on event type can provide a simple way to discover data sets for a specific facility/instrument combination and to reduce the downloaded data volume. We note that permissible {\bf event\_type} values will vary from facility to facility and from instrument to instrument.
+
 \section{Vocabulary Enhancements}
 
 While the IVOA Data Product Type Vocabulary (\url{http://www.ivoa.net/rdf/product-type}) provides terms, labels, and descriptions for many types of astronomical data products, there are some additions and changes that are appropriate to better support HEA datasets.  
@@ -290,7 +294,7 @@ \section{Vocabulary Enhancements}
 {\bf draws} & Draws & A dataset that records statistical draws computed from a probability distribution, for example Markov chain Monte Carlo (MCMC) draws used when computing the Bayesian marginal probability density function for a random variable.& \cr
 {\bf edisp} & Energy Dispersion & A dataset that records the probability density function for the energy migration as a function of true energy and spatial position.\footref{fn:dfgamma} & \#response-function, \#pdf \cr
 {\bf event-bundle} & Event Bundle & An event-bundle dataset is a complex object containing an {\bf event-list} and multiple files or other substructures that are products necessary to analyze the {\bf event-list}. & \cr
-{\bf event-list} & Event list & A dataset containing a collection of observed events, such as incoming HE particles, where an event is typically characterized by a spatial position, a time, and a spectral value ({\em e.g.\/}, an energy, a channel, a pulse height) & \#temporally-resolved-dataset \cr
+{\bf event-list} & Event list & A dataset containing a collection of observed events, such as incoming \gls{HE} particles, where an event is typically characterized by a spatial position, a time, and a spectral value ({\em e.g.\/}, an energy, a channel, a pulse height) & \#temporally-resolved-dataset \cr
 {\bf pdf} &\raggedright Probability Density Function & A dataset that records the probability density function of a quantity, for example the Bayesian marginal probability density function for a random variable. & \#measurements \cr
 {\bf psf} &\raggedright Point Spread Function & A dataset that records the probability density function of spatial/angular spreading of incident photons from a point source caused by the instrument (detector and/or mirror and/or analysis).\footref{fn:dfgamma}$^{,}$\footnote{I.M. George and R. Yusaf. The OGIP Format For 2-D (image) Point Spread Function Datasets. Technical Report OGIP/92-027, NASA/GSFC, Nov 2011. (\url{https://heasarc.gsfc.nasa.gov/docs/heasarc/caldb/docs/memos/cal_gen_92_027/cal_gen_92_027.pdf}).} & \#response-function, \#pdf  \cr
 {\bf region} & Region & A dataset that encodes (one or more) regions of parameter space, for example a spatial region or a region of phase space covered by a dataset. The set of dimensions represented by the region can be arbitrary. & \#measurements \cr

From bdbff85c7ce837035843ab990ce0afc464ef2cd3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Kh=C3=A9lifi?= <khelifi@in2p3.fr>
Date: Fri, 25 Jul 2025 13:12:52 +0200
Subject: [PATCH 2/4] typo

---
 HighEnergyObsCoreExt.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/HighEnergyObsCoreExt.tex b/HighEnergyObsCoreExt.tex
index 1509b08..5d2b352 100644
--- a/HighEnergyObsCoreExt.tex
+++ b/HighEnergyObsCoreExt.tex
@@ -271,7 +271,7 @@ \subsection{{\em analysis\_mode}}
 
 \subsection{{\em event\_type}}
 
-Some \gls{HE} instruments allow data to have event partitioning based on a data analyis quality associated with the reconstruction and the discrimination. Some analyses can flag each event by a quality label, partitionning the dataset into strictly disjoint event subsets. And for each quality label, a set of \glspl{IRF} should be derived and can be render public.  We propose to add an optional attribute {\bf event\_type} that specifies the data quality flag for an observation. It will allow the data provider to split the event list into several event lists labelled by an unique \bf event\_type} for a given observation, and to distribute their associated \glspl{IRF}. Constraints on event type can provide a simple way to discover data sets for a specific facility/instrument combination and to reduce the downloaded data volume. We note that permissible {\bf event\_type} values will vary from facility to facility and from instrument to instrument.
+Some \gls{HE} instruments allow data to have event partitioning based on a data analyis quality associated with the reconstruction and the discrimination. Some analyses can flag each event by a quality label, partitionning the dataset into strictly disjoint event subsets. And for each quality label, a set of \glspl{IRF} should be derived and can be render public.  We propose to add an optional attribute {\bf event\_type} that specifies the data quality flag for an observation. It will allow the data provider to split the event list into several event lists labelled by an unique {\bf event\_type} for a given observation, and to distribute their associated \glspl{IRF}. Constraints on event type can provide a simple way to discover data sets for a specific facility/instrument combination and to reduce the downloaded data volume. We note that permissible {\bf event\_type} values will vary from facility to facility and from instrument to instrument.
 
 \section{Vocabulary Enhancements}
 

From 41536df419ede90290c4c54caed386f15b46c765 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Kh=C3=A9lifi?= <khelifi@in2p3.fr>
Date: Mon, 4 Aug 2025 17:42:04 +0200
Subject: [PATCH 3/4] Update

---
 HighEnergyObsCoreExt.glg |  6 +++---
 HighEnergyObsCoreExt.gls | 21 +++++++++++----------
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/HighEnergyObsCoreExt.glg b/HighEnergyObsCoreExt.glg
index 35e0aeb..00ad196 100644
--- a/HighEnergyObsCoreExt.glg
+++ b/HighEnergyObsCoreExt.glg
@@ -1,7 +1,7 @@
 This is makeindex, version 2.15 [TeX Live 2022/dev] (kpathsea + Thai support).
 Scanning style file ./HighEnergyObsCoreExt.ist.............................done (29 attributes redefined, 0 ignored).
-Scanning input file HighEnergyObsCoreExt.glo....done (62 entries accepted, 0 rejected).
-Sorting entries....done (398 comparisons).
-Generating output file HighEnergyObsCoreExt.gls....done (36 lines written, 0 warnings).
+Scanning input file HighEnergyObsCoreExt.glo....done (76 entries accepted, 0 rejected).
+Sorting entries....done (514 comparisons).
+Generating output file HighEnergyObsCoreExt.gls....done (37 lines written, 0 warnings).
 Output written in HighEnergyObsCoreExt.gls.
 Transcript written in HighEnergyObsCoreExt.glg.
diff --git a/HighEnergyObsCoreExt.gls b/HighEnergyObsCoreExt.gls
index 64e1f8e..d3f5e6b 100644
--- a/HighEnergyObsCoreExt.gls
+++ b/HighEnergyObsCoreExt.gls
@@ -2,33 +2,34 @@
 \begin{theglossary}\glossaryheader
 \glsgroupheading{G}\relax \glsresetentrylist %
 \glossentry{GTI}{\glossaryentrynumbers{\relax 
-		\setentrycounter[]{page}\glsnumberformat{14}}}\glsgroupskip
+		\setentrycounter[]{page}\glsnumberformat{15}}}\glsgroupskip
 \glsgroupheading{H}\relax \glsresetentrylist %
 \glossentry{HE}{\glossaryentrynumbers{\relax 
 		\setentrycounter[]{page}\glsnumberformat{4\delimN 5}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{26}}}%
+		\setentrycounter[]{page}\glsnumberformat{20}\delimN 
+		\setentrycounter[]{page}\glsnumberformat{28}}}%
 \glossentry{HEA}{\glossaryentrynumbers{\relax 
 		\setentrycounter[]{page}\glsnumberformat{1}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{4}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{6\delimR 10}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{12\delimN 13}}}%
+		\setentrycounter[]{page}\glsnumberformat{4\delimR 11}\delimN 
+		\setentrycounter[]{page}\glsnumberformat{13\delimR 17}}}%
 \glossentry{HEIG}{\glossaryentrynumbers{\relax 
 		\setentrycounter[]{page}\glsnumberformat{4}}}\glsgroupskip
 \glsgroupheading{I}\relax \glsresetentrylist %
 \glossentry{IRF}{\glossaryentrynumbers{\relax 
 		\setentrycounter[]{page}\glsnumberformat{5\delimR 7}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{9\delimN 10}}}%
+		\setentrycounter[]{page}\glsnumberformat{9}\delimN 
+		\setentrycounter[]{page}\glsnumberformat{11}\delimN 
+		\setentrycounter[]{page}\glsnumberformat{17}}}%
 \glossentry{IVOA}{\glossaryentrynumbers{\relax 
 		\setentrycounter[]{page}\glsnumberformat{4}\delimN 
 		\setentrycounter[]{page}\glsnumberformat{6\delimN 7}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{14}\delimN 
-		\setentrycounter[]{page}\glsnumberformat{26}}}\glsgroupskip
+		\setentrycounter[]{page}\glsnumberformat{28}}}\glsgroupskip
 \glsgroupheading{M}\relax \glsresetentrylist %
 \glossentry{MOC}{\glossaryentrynumbers{\relax 
-		\setentrycounter[]{page}\glsnumberformat{14}}}\glsgroupskip
+		\setentrycounter[]{page}\glsnumberformat{15}}}\glsgroupskip
 \glsgroupheading{S}\relax \glsresetentrylist %
 \glossentry{STI}{\glossaryentrynumbers{\relax 
-		\setentrycounter[]{page}\glsnumberformat{14}}}\glsgroupskip
+		\setentrycounter[]{page}\glsnumberformat{15}}}\glsgroupskip
 \glsgroupheading{V}\relax \glsresetentrylist %
 \glossentry{VO}{\glossaryentrynumbers{\relax 
 		\setentrycounter[]{page}\glsnumberformat{4}\delimN 

From ada5c456d9c3da27d61a45d28f7c31d602ef4717 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bruno=20Kh=C3=A9lifi?= <khelifi@in2p3.fr>
Date: Mon, 4 Aug 2025 17:42:15 +0200
Subject: [PATCH 4/4] review comments

---
 HighEnergyObsCoreExt.tex | 44 ++++++++++++++++++++++------------------
 1 file changed, 24 insertions(+), 20 deletions(-)

diff --git a/HighEnergyObsCoreExt.tex b/HighEnergyObsCoreExt.tex
index 0be07ea..fcbfe79 100644
--- a/HighEnergyObsCoreExt.tex
+++ b/HighEnergyObsCoreExt.tex
@@ -26,7 +26,8 @@
 \usepackage{amsmath}
 \usepackage{amssymb}
 
-\usepackage[toc]{glossaries}
+\usepackage[nopostdot,style=super,nonumberlist,toc]{glossaries}
+
 \newacronym{IVOA}{IVOA}{International Virtual Observatory Alliance}
 \newacronym{VO}{VO}{Virtual Observatory}
 \newacronym{HE}{HE}{High Energy}
@@ -74,9 +75,6 @@
 \newacronym{HAWC}{HAWC}{High Altitude Water Cherenkov Experiment}
 \newacronym{LHAASO}{LHAASO}{Large High Altitude Air Shower Observatory}
 \newacronym{CAOM}{CAOM}{Common Archive Observation Model}
-\newacronym{IRFs}{IRFs}{Instrument Response Functions}
-\newacronym{GTIs}{GTIs}{good time intervals}
-\newacronym{STIs}{STIs}{stable time intervals}
 \newacronym{MOC}{MOC}{Multi-Order-Coverage}
 
 \makeglossaries
@@ -139,7 +137,7 @@ \subsection{{\em dataproduct\_type}}
 We propose to add the following {\em dataproduct\_type} term in both the Obscore standard and into the \gls{IVOA} vocabulary is of Product Types\footnote{See \url{https://www.ivoa.net/rdf/product-type}.} to better define a \gls{HEA} \textbf{event-list} and a  \textbf{event-list} that includes the event-list and its associated data:
 
 \begin{quote}
-{\bf event-list}: a collection of observed events, such as incoming high-energy particles. The table of event list is typically characterised by a spatial position, a time and an energy proxy. 
+{\bf event-list}: a collection of observed particle-detection events, such as incoming high-energy particles. The table of event list is typically characterised by a spatial position, a time and an energy proxy. 
 
 {\bf event-bundle}: compounded dataset containing an {\bf event-list} and multiple files or other substructures that are products necessary to analyze the event-list. Data in an event-bundle may thus be used to produce higher level data products such as images or spectra when containing \glspl{IRF}.
 \end{quote}
@@ -147,7 +145,7 @@ \subsection{{\em dataproduct\_type}}
 It may be worth mentioning that the term ``event'' caused confusion in the past, as it also is used for astrophysical events like supernova explosions ({\em e.g.\/} VOEvent), and that is not the type of event that is being described here, which are particle detection events. Using "event-list" was meant to help to resolve this ambiguity.
 
 An {\bf event-bundle} might for example consist of an {\bf event-list} and the associated {\bf response-functions} (see below) used to calibrate the dataset; alternatively an {\bf event-bundle} may include the {\bf event-list} and associated  data products necessary for the user to create the {\bf response-functions} (for those X-ray cases where detailed knowledge of the scientific use case — for example, the user’s selection of events — may be required to compute the responses).\\
-
+particle-detection
 In addition to {\em dataproduct\_type} terms that focus on event data, we note that existing ObsCore definitions do not adequately span the breadth of advanced data products (with {\em calib\_level} $\ge$ 3) that may be generated from astronomical observations by users or observatories. The computational complexity of analyzing \gls{HEA} data robustly in the extreme Poisson regime ({\em e.g.\/}, Bayesian X-ray aperture photometry applied simultaneously to multiple overlapping detections and ob-
 servations) means that data providers may choose to provide such analysis products directly to the end user. For example, the Chandra Source Catalog includes 38 types of advanced data products (for a total of $\sim$90 million files) and $\sim$50\% of these data product types are not well represented by a  {\em dataproduct\_type} value that allows for meaningful data discovery. Users will certainly want to discover these data products independently from the associated observation data (and many of these data products combine data from multiple observations). We therefore propose the following additional
 {\em dataproduct\_type} (or {\em dataproduct\_subtype}) terms for these advanced data products, and note that these terms will certainly be useful independent of waveband (i.e., they can be equally applicable to UV/optical, IR, and radio datasets):
@@ -257,41 +255,47 @@ \subsection{{\em ev\_xel}}
 
 \subsection{{\em s\_ref\_energy\/}/{\em em\_ref\_energy\/}/{\em s\_ref\_oaa\/}/{\em em\_ref\_oaa}}
 
-For \gls{HE} datasets that typically span decades of energy, both spatial resolution and sky coverage, and spectral resolution, can be strongly dependent on particle energy.  The ObsCore Recommendation suggests that in such circumstance a {\em characteristic\/} value be specified for the spatial and spectral characterization attributes ({\em e.g.\/}, {\em s\_fov\/}, {\em s\_region\/}, {\em s\_resolution\/}, {\em em\_res\_power\/}, {\em em\_resolution\/}).  We propose adding optional attributes ({\em s\_ref\_energy\/} for spatial characterization attributes and {\em em\_ref\_energy\/} for spectral characterization attributes) that define the energy (in units of eV) at which these characteristic values are specified.
+For \gls{HEA} datasets that typically span decades of energy, both spatial resolution and sky coverage, and spectral resolution, can be strongly dependent on particle energy. The ObsCore Recommendation suggests that in such circumstances a {\em characteristic\/} value be specified for the spatial and spectral characterization attributes ({\em e.g.\/}, {\em s\_fov\/}, {\em s\_region\/}, {\em s\_resolution\/}, {\em em\_res\_power\/}, {\em em\_resolution\/}). We propose adding optional attributes ({\em s\_ref\_energy\/} for spatial characterization attributes and {\em em\_ref\_energy\/} for spectral characterization attributes) that define the energy (in units of eV) at which these characteristic values are specified.
 
-For some \gls{HE} datasets, these attributes vary strongly with position in the field of view, typically as a function of off-axis angle ({\em i.e.\/}, the angular separation of the target or source from the telescope optical axis). We similarly propose adding optional attributes ({\em s\_ref\_oaa\/} for spatial characterization attributes and {\em em\_ref\_oaa\/} for spectral characterization attributes) that define the off-axis angle (in units of degrees) at which these characteristic values are specified.
+For some \gls{HEA} datasets, these attributes vary strongly with position in the field of view, typically as a function of off-axis angle ({\em i.e.\/}, the angular separation of the target or source from the telescope optical axis). We similarly propose adding optional attributes ({\em s\_ref\_oaa\/} for spatial characterization attributes and {\em em\_ref\_oaa\/} for spectral characterization attributes) that define the off-axis angle (in units of degrees) at which these characteristic values are specified.
 
 \subsection{{\em t\_intervals}}
 
-The global time bounds described by {\em t\_min\/}/{\em t\_max} in general are not sufficiently flexible when representing \gls{HE} datasets and advanced data products from any waveband.  The former are typically composed of many \gls{STIs}/\gls{GTIs}, where data are only valid during the stable or good intervals, while advanced data products may be constructed from multiple progenitor observations that can span decades from the start time of the first observations to the stop time of the last observation (albeit very sparsely).  For both cases, data queries using only {\em t\_min\/}/{\em t\_max} may not be adequate to determine whether useful scientific data coincide with a transient cosmic phenomenon.  In such cases, a more detailed knowledge of the observation time coverage is necessary.  We propose to add a new optional attribute {\em t\_intervals} that would contain the list of observation intervals or STIs/GTIs as a TMOC description following the \gls{MOC} IVOA standard  \citep{2022ivoa.spec.0727F}. This element could then be compared across data collections to make the data set selection via simple intersection or union operations in TMOC representation.
+The global time bounds described by {\em t\_min\/}/{\em t\_max} in general are not sufficiently flexible when representing \gls{HEA} datasets and advanced data products from any waveband.  The former are typically composed of many \glspl{STI}/\glspl{GTI}, where data are only valid during the stable or good intervals, while advanced data products may be constructed from multiple progenitor observations that can span decades from the start time of the first observations to the stop time of the last observation (albeit very sparsely).  For both cases, data queries using only {\em t\_min\/}/{\em t\_max} may not be adequate to determine whether useful scientific data coincide with a transient cosmic phenomenon.  In such cases, a more detailed knowledge of the observation time coverage is necessary.  We propose to add a new optional attribute {\em t\_intervals} that would contain the list of observation intervals or STIs/GTIs as a TMOC description following the \gls{MOC} IVOA standard  \citep{2022ivoa.spec.0727F}. This element could then be compared across data collections to make the data set selection via simple intersection or union operations in TMOC representation.
 
 \subsection{{\em energy\_min\/}/{\em energy\_max\/}}
 
-The existing attributes {\em em\_min\/} and {\em em\_max\/} that define the coverage of the spectral axis (defined as wavelength expressed in units of m) are not user friendly for \gls{HE} where datasets are generally selected according to an energy range ({\em i.e.\/}, inverse wavelength) in units of eV (or scaled units of eV, for example keV, MeV, GeV, TeV, PeV).  Unlike the radio domain where $\lambda = c/\nu$, where $c$ is an almost universally remembered physical constant, the conversion $\lambda = hc/E$ is not simple for the user to express.  As the spectral range covered by \gls{HE} data is many decades larger than for other wavebands, the accurate numerical representations of typical \gls{HE} spectral ranges as {\em em\_min\/}/{\em em\_max\/} requires quantities with many digits of precision and exponents ranging from $\sim\!10^{-5}$--$10^{-22}$.  Since specification of the spectral range is largely fundamental to data discovery in the \gls{HE} regime, we propose to add attributes {\em energy\_min\/} and {\em energy\_max\/} that specify the minimum and maximum spectral range values in units of eV\null.  Note that the sense of these attributes is {\em opposite\/} that of {\em em\_min\/} and {\em em\_max\/} because of the inverse wavelength relationship between energy and wavelength, so numerical comparisons must be transposed ({\em e.g.\/}, $E>E_{\rm thresh}$ becomes $\lambda<hc/E_{\rm thresh}$).  (An alternate approach would be to add attributes {\em em\_min\_energy\/} and {\em em\_max\_energy\/} that represent the energies corresponding to {\em em\_min\/} and {\em em\_max\/} in units of eV\null.  This is less desirable since queries on an energy would need to be specified as {\em em\_max\_energy\/}${}\leq E <{}${\em em\_min\_energy\/}, which is likely confusing.)
+The existing attributes {\em em\_min\/} and {\em em\_max\/} that define the coverage of the spectral axis (defined as wavelength expressed in units of m) are not user friendly for \gls{HEA} where datasets are generally selected according to an energy range ({\em i.e.\/}, inverse wavelength) in units of eV (or scaled units of eV, for example keV, MeV, GeV, TeV, PeV). Unlike the radio domain where $\lambda = c/\nu$, where $c$ is an almost universally remembered physical constant, the conversion $\lambda = hc/E$ is not simple for the user to express. As the spectral range covered by \gls{HEA} data is many decades larger than for other wavebands, the accurate numerical representations of typical \gls{HEA} spectral ranges as {\em em\_min\/}/{\em em\_max\/} requires quantities with many digits of precision and exponents ranging from $\sim\!10^{-5}$--$10^{-22}$.  Since specification of the spectral range is largely fundamental to data discovery in the \gls{HEA} regime, we propose to add attributes {\em energy\_min\/} and {\em energy\_max\/} that specify the minimum and maximum spectral range values in units of eV\null. Note that the sense of these attributes is {\em opposite\/} that of {\em em\_min\/} and {\em em\_max\/} because of the inverse wavelength relationship between energy and wavelength, so numerical comparisons must be transposed ({\em e.g.\/}, $E>E_{\rm thresh}$ becomes $\lambda<hc/E_{\rm thresh}$).  (An alternate approach would be to add attributes {\em em\_min\_energy\/} and {\em em\_max\_energy\/} that represent the energies corresponding to {\em em\_min\/} and {\em em\_max\/} in units of eV\null. This is less desirable since queries on an energy would need to be specified as {\em em\_max\_energy\/}${}\leq E <{}${\em em\_min\_energy\/}, which is likely confusing.)
+
 
 \subsection{{\em obs\_mode}}
 
-Many \gls{HE} instruments may be configured using multiple observing modes and these observing modes may significantly impact the structure and characteristics ({\em e.g.\/}, calibration accuracy) of the resulting observation datasets.  We propose to add an optional attribute {\bf obs\_mode} that allows the data provider to specify the observation mode for an observation.  Constraints on observation mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf obs\_mode} values will vary from facility to facility and from instrument to instrument.
-% Need more input/justification from facilities that support these capabilities
+Many \gls{HEA} instruments may be configured using multiple observing modes and these observing modes may significantly impact the structure and characteristics ({\em e.g.\/}, calibration accuracy) of the resulting observation datasets.
 
-\subsection{{\em scan\_mode}}
+We propose to add an optional attribute {\bf obs\_mode} that allows the data provider to specify the observation mode for an observation.  Constraints on observation mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf obs\_mode} values will vary from facility to facility and from instrument to instrument.
 
-Some \gls{HE} facilities can obtain observations using different spatial scan modes ({\em e.g.\/}, target pointing, spatial scans [including raster scans], slew data, and so on) that will affect the content of the observation.  We propose to add an optional attribute {\bf scan\_mode} that allows the data provider to specify the scan mode for an observation.  Constraints on scan mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf scan\_mode} values may vary from facility to facility and from instrument to instrument.
-% Need more input/justification from facilities that support these capabilities
 
 \subsection{{\em tracking\_mode}}
 
-Some \gls{HE} telescopes can obtain observations using different tracking modes ({\em e.g.\/}, sidereal rate, moving target [solar system] tracking, drift scans, and so on) that affect the content of the observation.  We propose to add an optional attribute {\bf tracking\_mode} that allows the data provider to specify the tracking mode for an observation.  Constraints on tracking mode can provide a simple way to discover data sets for a specific facility/instrument combination.  We note that permissible {\bf tracking\_mode} values may vary from facility to facility and from instrument to instrument.
-% Need more input/justification from facilities that support these capabilities
+Since \gls{HEA}  telescopes are  event-counting instruments, data can be accumulated even if the pointing moves or rotates relative to the sky during an observation.  However, they way in which this happens has an impact on how the data are later processed. \emph{Tracking} is defined by what the  center of the field-of view moves with during an observation: fixed to a celestial coordinate (the most common case for ground telescopes with movable mounts or those in space),  fixed to a horizontal coordinate (also called a "drift scan", and the standard case for telescopes without movable mounts),  fixed to a celestial body position like a planet or moon, or with no particular fixed coordinate system such as data taken when the instrument is slewing (\emph{i.e.} where the field of view moves with arbitrary direction and speed while the instrument is repositioning).
+
+To distinguish these, we propose to add an optional attribute {\bf tracking\_mode}. Constraints on tracking mode can provide a simple way to discover data sets for a specific facility/instrument combination. We note that permissible {\bf tracking\_mode} values may vary from facility to facility and from instrument to instrument.
+
+{\bf BKH: where to put in addition convergent/divergent/parallel pointing? should we replace scan\_mode by pointing\_mode? KK: any opinion?}
 
 \subsection{{\em analysis\_mode}}
 
-Some \gls{HE} instruments allow data to be reduced/analyzed in multiple ways and these analysis modes may significantly impact the content of the reduced datasets, as well as calibration accuracy. We propose to add an optional attribute {\bf analysis\_mode} that allows the data provider to specify the data reduction/analysis mode for an observation. Constraints on analysis mode can provide a simple way to discover data sets for a specific facility/instrument combination. We note that permissible {\bf analysis\_mode} values will vary from facility to facility and from instrument to instrument.
-% Need more input/justification from facilities that support these capabilities
+Most \gls{HEA} instruments employ significant software processing to transform raw data into the \emph{event-bundle} data exposed to users, including algorithms for calibration and event property reconstruction. The way in which this processing is configured therefore has a potentially large impact the content of the reduced datasets; indeed the same observation processed with two different configurations may result in different scientific performance. In some cases, multiple processing configurations within the same observation collection are used to provide users with a wider range of scientific coverage.
+
+We propose to add an optional attribute {\bf analysis\_mode} that allows the data provider to specify the data reduction/analysis mode for an observation, in case more than one are employed. Constraints on analysis mode can provide a simple way to discover data sets for a specific facility/instrument combination. We note that permissible {\bf analysis\_mode} values will vary from facility to facility and from instrument to instrument.
+
 
 \subsection{{\em event\_type}}
 
-Some \gls{HE} instruments allow data to have event partitioning based on a data analyis quality associated with the reconstruction and the discrimination. Some analyses can flag each event by a quality label, partitionning the dataset into strictly disjoint event subsets. And for each quality label, a set of \glspl{IRF} should be derived and can be render public.  We propose to add an optional attribute {\bf event\_type} that specifies the data quality flag for an observation. It will allow the data provider to split the event list into several event lists labelled by an unique {\bf event\_type} for a given observation, and to distribute their associated \glspl{IRF}. Constraints on event type can provide a simple way to discover data sets for a specific facility/instrument combination and to reduce the downloaded data volume. We note that permissible {\bf event\_type} values will vary from facility to facility and from instrument to instrument.
+Some \gls{HEA} instruments allow data to have event partitioning based on a data analyis quality associated with the reconstruction and the discrimination. Some analyses can flag each event by a quality label, partitionning the dataset into strictly disjoint event subsets. And for each quality label, a set of \glspl{IRF} should be derived and can be render public\footnote{As made by the Fermi-LAT collaboration, \glspl{IRF} are produced for each event type: see \url{https://fermi.gsfc.nasa.gov/ssc/data/analysis/documentation/Cicerone/Cicerone_LAT_IRFs/IRF_overview.html}.}.
+
+We propose to add an optional attribute {\bf event\_type} that specifies the data quality flag for an observation. It will allow the data provider to split the event list into several event lists labelled by an unique {\bf event\_type} for a given observation, and to distribute their associated \glspl{IRF}. Constraints on event type can provide a simple way to discover data sets for a specific facility/instrument combination and to reduce the downloaded data volume. We note that permissible {\bf event\_type} values will vary from facility to facility and from instrument to instrument.
+
 
 \section{Vocabulary Enhancements}
 \label{sec:voc}