[Heig] [EXTERNAL] [BULK] Post running meeting thoughts

[BONNAREL FRANCOIS gmail]

Hi Tess, all


to illustrate number 3 I created a github issue on the document, 
rephrasing two of the use cases (A.1.3 and A.1.)


https://github.com/ivoa/HighEnergyObsCoreExt/issues/36



Le 27/01/2026 à 18:16, Jaffe, Tess (GSFC-6601) a écrit :
> Hi all,
>
> I agree with François about this.  At HEASARC, the philosophy is to 
> list individually in the ObsCore table only those things that somebody 
> might want to search for individually.  So each image, each spectrum 
> and its response matrix**, and one row for the whole observation.  For 
> some missions, a directory for each instrument.  Anybody who needs to 
> do processing that requires more than those quick look products above 
> will have to look at the whole observation that includes all of the 
> responses etc. We are still working out the datalink details to make a 
> product link back to the full observation, for instance, and a 
> spectrum links also to its matrix, but the screen shot below shows the 
> current selections.  We do not currently have the CSC products, but 
> our approach will likely be similar there.
>
> (** Currently we're also listing each filtered event file as well 
> though that's an odd use case we may change our minds about.)
>
> Antara has been following this group in more detail than I, so I'm not 
> keeping up with the idea of bundles.  But this is our approach, and 
> I'm not sure if we will use them.  And our selection doesn't quite 
> match any of the four possibilities François listed below.  But this 
> is all negotiable so that we are all as consistent as we can be.
>
> François's number 3 below is an interesting additional idea I hadn't 
> thought about, which solves the problem of discovering the real 
> access_format rather than the datalink.  I.e., you want the JPEG image 
> not the FITS image.  There is nothing to distinguish them in the 
> obscore table itself, since we are following the recommendation that 
> every row's access_url be a datalink call, so that's what's in 
> access_format.

Yes in that case you can select on datalink.response.content_type in the 
JOIN table


Cheers

François

> Just my thoughts....
>
> Cheers,
> Tess
> ​​
> ​​
>
> ------------------------------------------------------------------------
> *From:* heig <heig-bounces at ivoa.net> on behalf of BONNAREL FRANCOIS 
> gmail via heig <heig at ivoa.net>
> *Sent:* Tuesday, January 27, 2026 9:52 AM
> *To:* Janet Evans via heig <heig at ivoa.net>
> *Subject:* [EXTERNAL] [BULK] [Heig] Post running meeting thoughts
> *CAUTION:* This email originated from outside of NASA.  Please take 
> care when clicking links or opening attachments.  Use the "Report 
> Message" button to report suspicious messages to the NASA SOC.
>
>
>
>
> 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/20260204/66087725/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-ctxql1pf.png
Type: image/png
Size: 195365 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/heig/attachments/20260204/66087725/attachment-0002.png>
-------------- 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/20260204/66087725/attachment-0003.png>