[Heig] HEIG Obscore Note - ready for final review

Wed Aug 26 19:55:16 CEST 2026

Dear Ian, Dear Karl,

I have studied the note again and could not find anything in addition to what Karl already mentioned below. I am impressed with the quality and thank you a lot for all the work that went into it.

I found only some typos:

  *
P7: covering up to the full (the) sky
  *
P9: will be included in (the) next version
  *
P56: Ob(s)core

I also wanted to underline that I find the use cases and implementation examples in Sec. 6 very helpful. I might expect that we will try some of these examples even with other data levels.

With best wishes,
      Matthias.

From: heig <heig-bounces at ivoa.net> on behalf of Dr. Ian N. Evans via heig <heig at ivoa.net>
Date: Monday, 24. August 2026 at 20:47
To: Karl Kosack <karl.kosack at cta-observatory.org>
Cc: Evans, Janet <jdeponte at cfa.harvard.edu>; Janet Evans via heig <heig at ivoa.net>
Subject: Re: [Heig] HEIG Obscore Note - ready for final review

Hi Karl,

See responses in-line below.

Cheers,
—Ian

On Aug 24, 2026, at 04:56, Karl Kosack via heig <heig at ivoa.net> wrote:

On Aug 21, 2026, at 17:31, Evans, Janet <jdeponte at cfa.harvard.edu<mailto:jdeponte at cfa.harvard.edu>> wrote:

Hi Karl,
It's depends on the content.  Is it something big (hope not) like a new section that is better discussed in email or a few tweaks or typos?  Why don't you describe it in email and then we'll provide feedback.

The draft looks quite good, I just have a few minor comments, listed below:

- P8: standard set of independent [IRF] components: I think mentioning different particle progenitor types here is confusing, as those are not sub-components of an IRF, but a different IRFs. Instead could mention effective collection area if you want a third example?

Agreed.  We can change “different messenger particle types” to “telescope effective area” or something similar.

- P8: "... and make rationale and well-considered proposals..." is awkward, did you mean "rational"? or "rationales"? Maybe just omit rationale, as a well considered proposal should contain a rationale.

Should be “rational”.

- P8: Omit "very" in sentence "Some attributes are [very] specific to our domain..."  (meaningless)

Agreed.

- P11: It might be good to define what a "draw" is mathematically, perhaps in a footnote, as this is jargon and would help understand why the "draws" dataset is defined. Also, when using the word to represent a data product, please either put it in \emph{draws} or say "draws data product", which will make the paragraph read better. E.g. "The \emph{draws} can be interpreted to provide..."  , since draws is an English word that is not usually used in that way.

I agree with the adding a footnote to define draws.  Within the document, a data product type is written in bold.  I think “The draws can be interpreted …” is not however referring to the data product, but to the statistical draws that the {\bf draws} dataset records.  Changing that sentence to “The statistical draws can be interpreted …” would be more clear.

- P11: maybe mention that _region_ datasets are not specific to HEA, but are used also in optical and other wavebands?

Agreed.  This is a good idea.

- P13: "However, some hea-event-lists include _spatial_ and time axes that are
calibrated physical quantities..."  Is that true? I think there is always a PSF, which is the calibration or IRF for the spatial axis.  For time, this is fine.

I would say this is true in the way astronomers generally discuss calibrated spatial axes, i.e., most astronomers would consider an image that has axes with a World Coordinate System (e.g., absolute RA and Dec axes) as opposed to pixel number to be calibrated spatially.  Spatial deconvolution using the PSF is generally not considered a requirement for spatial axes to be calibrated.  This is different from a spectral axis that uses PHA for example.

- P15: the term "drift scans" is used without any context or definition.  This is jargon and should be defined. It's just an observation made at a fixed alt/az coordinate rather than ra/dec, so is specific to alt/az mounted ground-based telescopes.

I think “drift scans” is a common term that would be well understood by the astronomical community.  We could add a footnote if you prefer.

- P21: same for "Tracking mode" (and probably "Scan mode" and "pointing mode"), which are not really HEA specific, but ground-based instrument-specific.  Maybe a general comment is that we introduce some of these terms not for HEA specifically, but for ground based instruments that do not use e.g. equatorial mounts, which happens to be common for some  HEA instruments.

Tracking mode and scan mode (at least) are not HEA-specific, but they are defined in the HEA-specific extension for the moment.  The radio extension also defines these in the radio-specific extension and we have tried to harmonize with the set of definitions that they use.  Actually we have defined a superset of values because these concepts are *not* specific to ground-based AltAz telescopes (although a subset of the values such as the “fixed-az-el-transit” pointing_mode are).  I’m aware of several space-based HEA missions that use “sidereal” “solar-system-object-tracking” and “none” tracking_modes, and “on-source”, “raster-map”, and “slew” scan_modes.  Hopefully, the TCG will recognize that these modes (at least) are common across multiple wavebands (also in the infrared) and promote them.

- P21: Pointing mode is specific to telescope *arrays*, which maybe is not obvious in the text. It might even be better to call it `array_pointing_mode` to be clear that it doesn't apply to individual telecopes, as this is quite a generic term?

I don’t mind changing this to “array_pointing_mode” if nobody objects.

- P24: When discussion "messenger_name", it might be good to mention that even a single HEA observatory may produce data for different messengers, e.g. HESS (and IACT) is nominally a gamma-ray instrument, but also has published papers on electron, iron, and proton spectra. Therefore the instrument name alone is not sufficient to distinguish the messenger, hence why this is proposed.

This is a good point.

- the definition of effective area is maybe a bit simplistic described  as the geometric area * efficiency (even if technically that is what it is): it is the true collection area (usually computed by Monte-carlo integration), of a system where the geometric collection area is difficult to define or is affected by spatial and/or energy-dependent instrumental effects such as vignetting, mirror reflectivity, detector quantum efficiency, etc.   E.g. for IACTs, the "geometric collection area" is not something we can compute.

I think the *definition* should probably reflect the wording in the appropriate reference.  However, you make a very valid point and if you agree we can add a footnote that highlights that the geometric collection area may not be easily computed using your wording.

Cheers,
Karl

Thanks,
-janet

On Fri, Aug 21, 2026 at 11:07 AM Karl Kosack <karl.kosack at cta-observatory.org> wrote:
Hi Janet,

For the final HEIG review, would you prefer our comments via email, or as an issue in the github repo?

Regards,
Karl

On Aug 12, 2026, at 23:08, Janet Evans via heig <heig at ivoa.net> wrote:

Dear HEIG,
Apologies for the long gap in communication.  Here is a summary of some of the things that have happened since our last HEIG meeting.

o IVOA Interop in Strasbourg
Great meeting for HEIG with interest in the Obscore extension, a plenary to present the HE Obscore extension doc details and the demos prepared by this group.
o Semantics meeting at Interop
Several of us met with the Semantics WG to settle several vocabulary keywords - it was a good meeting
o Further Obscore Note input and final review/scrub
There is a new section 6 along with a vocabulary update and scrub for typos/etc.

It’s now your turn to review the document as we prepare to turn it over to the TCG/Exec for Endorsed Note status.
Here’s the schedule we’re working to:
Wed, Aug 12 — Janet sends notice of final doc to HEIG for review (typos/minor edits, no new content)
Tue, Aug 25 — End of HEIG review/feedback
Thu, Aug 27 — Janet sends note to TCG with request for review/endorsed status

The document is available in GitHub (https://www.google.com/url?q=https://github.com/ivoa/HighEnergyObsCoreExt?tab%3Dreadme-ov-file&source=gmail-imap&ust=1788166575000000&usg=AOvVaw0a0PIhyixIhB6eFU2NNfOM); I’ve also appended the PDF below.

Best regards,
-janet

Janet Evans | Software Development Manager | Chandra X-ray Center
Center for Astrophysics | Harvard & Smithsonian
Office: (617) 495-7160
60 Garden Street | MS 81 | Cambridge, MA 02138

<HighEnergyObsCoreExt-draft.pdf>

--
heig mailing list
heig at ivoa.net<mailto:heig at ivoa.net>
https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1788166575000000&usg=AOvVaw2gVUCOCpVb6HQilWiK5bO9

—

Dr. Ian Evans
Astrophysicist
Chandra X-ray Center
Center for Astrophysics | Harvard & Smithsonian

Office: (617) 496 7846 | Cell: (617) 699 5152
60 Garden Street | MS 81 | Cambridge, MA 02138

[PastedGraphic-2.png]

[PastedGraphic-3.png]

cfa.harvard.edu<http://cfa.harvard.edu/> | Facebook<http://cfa.harvard.edu/facebook> | Twitter<http://cfa.harvard.edu/twitter> | YouTube<http://cfa.harvard.edu/youtube> | Newsletter<http://cfa.harvard.edu/newsletter>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260826/00ecb732/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-2.png
Type: image/png
Size: 581 bytes
Desc: PastedGraphic-2.png
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260826/00ecb732/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-3.png
Type: image/png
Size: 21717 bytes
Desc: PastedGraphic-3.png
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260826/00ecb732/attachment-0003.png>