[Heig] vocabulary update: proposal for dataproduct_type update for high energy data : event-list definition and event-bundle

[Markus Demleitner]

Dear Colleagues,

On Wed, May 21, 2025 at 02:16:52PM -0400, Dr. Ian N. Evans via semantics wrote:
> In the current draft of the HEA ObsCore note, I access a PSF using
>
> dataproduct_type = ‘response-function’
> dataproduct_subtype = ‘psf’
>
> because a PSF is a type of response-function (and there are many
> types of response function so adding all of these separately as
> different dataproduct_type would grow the list very significantly.

Let me first retract my earlier appeal to have these in
datalink/core; that would have been the right choice if these were
really only auxiliary artefacts.

Since there seems to be a wide consensus that these beasts ought be
be able to live within dataproduct-type.  That would mean that, when
they *are* in datalink, they'd be semantices #calibration and
content-qualifier something narrower or equal to response-function.

Are we in rough agreement here?

If so:

> “response-function” is technically correct.  Response-functions are
> widely applicable across multiple wavebands.  For example, a point
> spread function is a type of response-function that is used across
> all wavebands.  Similarly, a line spread function is a
> response-function used in UV through IR spectroscopy.  The term
> “irf” is not generally used across all high-energy projects.  In
> the USA, most high-energy projects follow the NASA HEASARC OGIP
> standards, and so will use “rmf” for the redistribution matrix
> file” and “arf” for the “auxiliary response file” (and will keep
> these separate).  Internationally, some projects historically used
> “irf” to represent the product of the rmf and arf.  More recently
> some projects have used “irf” as the equivalent of
> “response-function” giving it a broader interpretation.  So this
> can be a source of confusion and lack of clarity.  I also note that
> “irf” stands for “instrument response function” and there are
> certainly response-functions such as software filters (e.g., a
> modified Hanning filter used for optimal extraction) where
> “instrument” would be a misnomer.

Thank you for that clarification.  Is something like this already in
the HEIG note?  If not, can I ask you to prepare a PR putting this
in?

> I might suggest something more like
> response-function
> arf as child of response-function
> rmf as child of response-function
> psf as child of response-function
> lsf as child of response-function (not HEA)

Which begs the question: Do we have cases where we actually need to
tell those apart *in discovery*?  What sort of obscore query would
need to constrain discovery to rmf and would be severely less useful
if you got psfs and arfs in, too?

Full disclosure up front: I'd be very skeptical about an arument that
you need it to tell apart the individual artifacts; I'm 100% sure
that type information needs to be in the dataset itself, and that we
need to fix the datasets if they are lacking this kind of metadata.

Thanks,

         Markus