[Heig] Post running meeting thoughts

[BONNAREL FRANCOIS gmail]

Dear all,
Just to advise you I raised a PR with some changes/addition on use case 
1.4 and 1.6 of the HighEnergyObsCoreExt note.
For some reasons the build workflow was not run on it, so you are 
probably not made aware of this by github
I also plan to write an issue on use case 1.3 and 1.9 in the coming 
hours/days
An issue because the changes there would need more discussion than on 
1.4 and 1.6
Cheers
François

Le 27/01/2026 à 15:52, BONNAREL FRANCOIS gmail a écrit :
>
> Dear all,
>
> After the meeting last week, I was still thinking about what the 
> Chandra prototype could look like
>
> For the Paris HESS prototype, I get the idea since a couple of years now.
>
> Trying to understand what the CSC data products could be I came back 
> to Ian's Malta interop presentation.
>
> I copy/paste here one of the slides where some of these products are 
> described.
>
> Before trying to define dataproduct_type vocabulary terms for those 
> products I am wondering if we really need to expose all this data 
> directly in
>
> an ObsTAP service.
>
> For example background images, psf, pixel mask, bad pixel regions, ARF 
> belong to the "response functions" category if I'm not mistaking.
>
> They probably are attached to a photon event list or an image or ....
>
> Including all this in the main ObsCore table will overload it very 
> heterogeneously. Some of these response functions will be similar to 
> what we get in other domains (psf) some will be very different and 
> specific to Xray.
>
> I understood that the spatial, spectral, time characterization of 
> these specific products could be borrowed from the observation they 
> are associated with. It's ok but is that useful ?
>
> For accessing these response functions I can imagine 4 solutions which 
> all will have the  advantage to let the OBsTAp service be focused on 
> measurements obtained from the sky at whatever calib level.
>
>     1 ) the photon event list and response functions are gathered 
> together in the same tar or archive file (or MEF) which is typed as an 
> event-bundle. Direct access to this bundle from Obstap access_url is 
> then easy. It's the client task to figure out what to do with the 
> content of the bundle.
>
>    2 ) the various response material is kept as a set of individual 
> products. All are associated to an event list or an image or a 
> spectrum. In that case ObsTAP point to a datalink response which lists 
> all these different products. The semantics FIELD writes calibration 
> or response function.  Content_qalifier FIELD writes the very nature 
> of the product.
>
>    3 ) the DataLink reponse content may be organized as a TAP table. 
> It's then possible to query at the same time the  ObsTAP table and the 
> DataLink-like table by a join on ObsCore/obs_publisher_did-DataLink/ID
>
>   4 ) if we need a more detailed description of the response products 
> to help discover and select them we could imagine creating a specific 
> "response product" table following a specific datamodel as proposed by 
> Mireille in her Gorlitz presentation. This will allow to attach 
> specific eg :
>
>       - time range to a psf or
>
>       - specific release date and description to an arf or a bad pixel map
>
>       -....
>
>       Natural join on obs_publisher_did in both tables will allow to 
> query those table at the same time with selection criteria from both.
>
>    Cheers
>
> François
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260203/b6bdf98a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulnvpjC4zXtPT0zn.png
Type: image/png
Size: 241214 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260203/b6bdf98a/attachment-0001.png>