<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Hi all,</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
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. </div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
(** Currently we're also listing each filtered event file as well though that's an odd use case we may change our minds about.)</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
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. </div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
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.</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Just my thoughts....</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Cheers,</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Tess</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);" class="entityDelimiterBefore"></span><span class="_Entity _EType_OWALink _EId_OWALink_1 _EReadonly_1" style="display:inline-block"><span></span></span><span style="font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);" class="entityDelimiterAfter"></span></div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);" class="entityDelimiterBefore">
</span><span style="display: inline-block;" class="_Entity _EType_OWALink _EId_OWALink_2 _EReadonly_1"><span></span></span><span style="font-family: Arial, Helvetica, sans-serif; color: rgb(0, 0, 0);" class="entityDelimiterAfter"></span><img style="max-width: 541px;" id="image_0" data-outlook-trace="F:1|T:1" src="cid:eff24aa2-2f69-4c4b-93fc-f0cecb1cca17"> </div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From:</b> heig <heig-bounces@ivoa.net> on behalf of BONNAREL FRANCOIS gmail via heig <heig@ivoa.net><br>
<b>Sent:</b> Tuesday, January 27, 2026 9:52 AM<br>
<b>To:</b> Janet Evans via heig <heig@ivoa.net><br>
<b>Subject:</b> [EXTERNAL] [BULK] [Heig] Post running meeting thoughts</div>
<div style="direction: ltr;"> </div>
</div>
<table align="left" cellspacing="0" style="border-width: 2px; border-style: solid; border-color: black;">
<tbody>
<tr>
<td style="line-height: normal; background-color: rgb(255, 235, 156); padding: 5px; width: 100%;">
<div style="line-height: normal;"><span style="font-size: 10pt; color: rgb(0, 0, 0); line-height: normal;"><b>CAUTION:</b></span>
<span style="font-size: 10pt; line-height: normal;">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.</span></div>
</td>
</tr>
</tbody>
</table>
<div><br>
<br>
<br>
</div>
<p style="margin-top: 1em; margin-bottom: 1em;">Dear all,</p>
<p style="margin-top: 1em; margin-bottom: 1em;">After the meeting last week, I was still thinking about what the Chandra prototype could look like</p>
<p style="margin-top: 1em; margin-bottom: 1em;">For the Paris HESS prototype, I get the idea since a couple of years now.</p>
<p style="margin-top: 1em; margin-bottom: 1em;">Trying to understand what the CSC data products could be I came back to Ian's Malta interop presentation.</p>
<p style="margin-top: 1em; margin-bottom: 1em;">I copy/paste here one of the slides where some of these products are described.</p>
<p style="margin-top: 1em; margin-bottom: 1em;">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</p>
<p style="margin-top: 1em; margin-bottom: 1em;">an ObsTAP service.</p>
<p style="margin-top: 1em; margin-bottom: 1em;">For example background images, psf, pixel mask, bad pixel regions, ARF belong to the "response functions" category if I'm not mistaking.</p>
<p style="margin-top: 1em; margin-bottom: 1em;">They probably are attached to a photon event list or an image or ....</p>
<p style="margin-top: 1em; margin-bottom: 1em;">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.</p>
<p style="margin-top: 1em; margin-bottom: 1em;">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 ?</p>
<p style="margin-top: 1em; margin-bottom: 1em;">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.</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> 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.</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> 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.</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> 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</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> 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 :</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> - time range to a psf or</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> - specific release date and description to an arf or a bad pixel map</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> -....</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> Natural join on obs_publisher_did in both tables will allow to query those table at the same time with selection criteria from both.</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> Cheers</p>
<p style="margin-top: 1em; margin-bottom: 1em;">François</p>
<p style="margin-top: 1em; margin-bottom: 1em;"> </p>
<p style="margin-top: 1em; margin-bottom: 1em;"><br>
</p>
<p style="margin-top: 1em; margin-bottom: 1em;"><br>
</p>
<p style="margin-top: 1em; margin-bottom: 1em;"><img size="535066" style="margin-top: 0px; margin-bottom: 0px;" data-outlook-trace="F:1|T:1" src="cid:part1.601HUn9S.HmZf1KQZ@gmail.com"></p>
</body>
</html>