[Heig] HEIG Obscore Note - ready for final review/ comments on the Note #part 1

[Mireille Louys]

Hi Janet , Hi HEIG members,

Here are my comments about the last version of the note from August 03.
I just want to mention that july-august is the summer leave period for 
people working at the university,
that is why I answer now.

I will try to put my remarks and suggestions in Github , but I cannot 
put comments on the current version via the web interface currently.

Here are my remarks:

I believe some features need to be improved before submission :

/*Terms for data products : */
we have used advanced data products and analysis data products to 
express, I suppose new elaborated products that are more easy
to the user to take a decision, in data selection or in data 
interpretation.

/I think we must provide a clear definition for them. /
I believe both terms are fuzzy:

Why "advanced"? with respect to today’s available data products? 
 What 
will it mean in 2 years ?
Are some advanced products not used for science analysis? dedicated to 
data selection only?

What are these data products intended for ?
To understand better the content of a dataset, ease data analysis or 
data selection or data processing ?
Can we precise this goal better?

This question will need to be adressed for Obscore 1.2 , but for this 
Note we can keep "advanced data products"
with the caveat that clarification is needed.

*/Labels :/*

#pdf
evoques a Probability analysis result for some variable quantity 
contained in the data.
--> seems understandable
#draws
Analysis result after a MCMC computation for some variable in the data 
like aperture photometry, astrometry, etc.
Seems useful for characterising the observed dataset content, its 
quality / interpretability.
Q:Is it the result of interpretation of the observed data or a side 
product to help or it?
--> Can the definition be clarified ?

#region
Used for Chandra.
Does it apply to other projects? How is it called elsewhere?
Is it a spatial ancillary dataproduct ?
Spatial map ? 
Multi-dimensional significance map?
STMOC is a possible format for a multi-order map, but the geometry of 
the regions
are tiles and not circles or polygons as shown in the exemple proposed for
#region  in the VEP currently submitted at
https://github.com/ivoa-std/VEPs/pull/21/changes/c4195e1975341881d8fda22cb851ff11b5b74c1f#top

--> Seems useful for characterising the dataset quality / interpretability.
Q:Is it the result of observed data interpretation or a side product to 
help or it?

*/Appendix B : Response table /*
In order to distinguish response files from observation files as 
targeted in the ObsCore specification, we propose to distribute response 
data products in a separate table  in TAP and to use it in a Join 
operation with the  ivoa.obscore table that describes the event-list .

The type of response is defined in the column 
\emph{resp_dataproduct_type} and follows the /response-type/ ivoa 
vocabulary.

Each response is searchable by its dataproduct_type (resp_dataproduct_type)
and by some axes properties on position, energy, time for selection .
They correspond to the actual coverage of the response data set,
which can differ slightly from the one of the original data set 
(event-list) they can apply to.
The response file may apply on selected events from the event-list, 
based on event_type,
source modeling , or energy constraints.
Therefore the coverage in space, energy and time of a response function 
may differ
from the one computed on the primary event-list taken in the observation.

In the uses cases discussed in the note, responses are searched based on 
the IDs for observation or event-list
they are linked to in the archive, so by \emph{obs_id} or 
\emph{obs_publisher_id} in the ObsCore table. 

These can be used as foreign keys in the join operation between the 
response table and the ivoa.obscore. 


The results can be sorted by their /resp_data_product_type/ to discover 
#psf or #edisp or #arf, etc.
So one response table only is needed .

Introducing  for instance /response_psf/  or r/esponse_edisp/ tables 
whose metadata content can vary for each archive,
  just break interoperability.
The response_table should contain the mandatory attributes defined in 
the core response table defined Tab. 8,
and if needed , can also contain optional columns  for some particular 
data providers and users.

Those columns can’t be standardized.
We have not explored use cases requiring any distinction between 
response tables .

In any case it is up to the user to finally check the response file in 
details before using it for calibration.

thanks for your reading,

Best , Mireille


Le 12/08/2026 à 11:08 PM, Janet Evans via heig a écrit :
> 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://github.com/ivoa/HighEnergyObsCoreExt?tab=readme-ov-file); 
> 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
>
>
>
>
-- 
--
Mireille Louys, MCF (Assistant Professor)
Centre de données Astronomiques (CDS)       Equipe Images, ICube
Observatoire de Strasbourg                  Telecom Physique Strasbourg
11, rue de l' Université                    300, Bd Sebastien Brandt CS 10413
F-67000 Strasbourg                          F-67412  Illkirch Cedex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260824/7eb1c17a/attachment.htm>