<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Monaco;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:-webkit-standard;
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">Hi everybody,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">I agree with Francois on a number of things, but especially that there is a lot of misunderstanding and misrepresentation going on here.
<b>Nobody</b> has ever expressed reluctance to ensure that HEA-specific ancillary products such as responses etc. are made available easily through VO protocols. Let’s focus on what the issue actually is, because I think the discussion has lost sight of it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">In my opinion, the main issue is not whether things like response matrices are science data, are needed by the users, or should be in the VO. I think we all agree that this
is obvious. The question is what is the best method for making them accessible <i>
in the needed context</i> and how far we need to customize what goes in the ObsCore table itself for different fields. That then is a question about discoverability and complexity. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">Having an individual row in an ObsCore table enables a user to
<b>search for</b> that one specific thing. The best practice recommendation for the use of ObsCore is that the access_url be a datalink. So for a given product listed in an ObsCore table, three queries are needed: one to find the product, one to get its
datalinks, and then one to download the file(s). I cannot recall having heard of a use case where somebody was interested in finding only the RMFs from a given instrument in a given year. (Please let me know if you have a use case for this so that we can
address it directly. I can think of calibration projects, but this is an edge case that can be addressed another way.) Users will instead want to find all of the spectra from some source/time/waveband. That is why ObsCore has a row for such a product. Nobody
disputes that to do the scientific analysis on that spectrum requires the user to also have an RMF. But that RMF does not need to be independently discoverable, just correctly linked to the spectrum that is of interest.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">Francois has proposed a number of solutions to this. ObsCore has a very reasonable amount of flexibility and specificity, and it is quite important to worry about adding unnecessary
complexity and size. (I myself was worried about the additional complexity of the datalink layer, but now in implementation, I’m becoming a fan.) The radio extension doc you may note proposes a number of fields that are
<i>all about discovery</i>. It then states, “Auxiliary datasets such as uv distribution map, dirty beam maps, frequency/amplitude plots, phase/amplitude plots are useful for astronomers to check data quality. In that case DataLink … may provide a solution
to attach these auxiliary data to ObsCore records.” That makes sense to me. <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">So I suggest we follow what the radio folks are doing. With this in mind, I think that three of the proposed columns -- T_intervals , Obs_mode , Event_type – are very clearly
applicable to data discovery and should be added to the ObsCore table. But some of the other proposed fields would be better added in datalinks with a HEA-specific vocabulary. We should discuss these on a case-by-case basis after having agreed on the purpose
of a row in ObsCore. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">I hope this helps the discussion move along productively.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><br>
Tess<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-family:"Calibri",sans-serif;color:black">From:
</span></b><span style="font-family:"Calibri",sans-serif;color:black">heig <heig-bounces@ivoa.net> on behalf of Bruno KHELIFI via heig <heig@ivoa.net><br>
<b>Reply-To: </b>Bruno KHELIFI <khelifi@apc.in2p3.fr><br>
<b>Date: </b>Friday, March 20, 2026 at 4:49 AM<br>
<b>To: </b>BONNAREL FRANCOIS gmail <francois.bonnarel@gmail.com><br>
<b>Cc: </b>"heig@ivoa.net" <heig@ivoa.net><br>
<b>Subject: </b>[EXTERNAL] [BULK] Re: [Heig] Post running meeting thoughts<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<table class="MsoNormalTable" border="1" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%;border:solid black 1.5pt">
<tbody>
<tr>
<td width="100%" style="width:100.0%;border:none;background:#FFEB9C;padding:3.75pt 3.75pt 3.75pt 3.75pt">
<p class="MsoNormal" style="mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly">
<b><span style="font-size:10.0pt;color:black">CAUTION:</span></b><span style="color:black">
</span><span style="font-size:10.0pt;color:black">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><span style="color:black">
</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Hi all,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">This is a pleasure to see active thoughts from anyone to expose the new HE products!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Few words inline..<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div id="signature-content-da635f11-d113-45d6-a470-925f0c958d7f">
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><br>
---------------------------------------------------<br>
Bruno Khelifi<br>
Physicist in CNRS, APC, Paris<br>
Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71<br>
APC, Universite Paris Diderot-Paris 7<br>
Bat. Condorcet, Case 7020, 75205 Paris Cedex 13<o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<div id="OLK_SRC_BODY_SECTION">
<div id="OLK_SRC_BODY_SECTION">
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><img width="548" height="1" style="width:5.7083in;height:.0104in" id="Horizontal_x0020_Line_x0020_1" src="cid:image001.png@01DCB85C.70866470"></span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<strong><span style="font-family:"Arial",sans-serif;color:black">De: </span></strong><span style="font-family:"Arial",sans-serif;color:black">BONNAREL <francois.bonnarel@gmail.com><br>
<strong><span style="font-family:"Arial",sans-serif">à: </span></strong>Ian <ievans@cfa.harvard.edu><br>
<strong><span style="font-family:"Arial",sans-serif">Cc: </span></strong>Bruno <khelifi@apc.in2p3.fr>; heig <heig@ivoa.net><br>
<strong><span style="font-family:"Arial",sans-serif">Envoyé: </span></strong>vendredi 20 mars 2026 00:12 CET<br>
<strong><span style="font-family:"Arial",sans-serif">Sujet : </span></strong>Re: [Heig] Post running meeting thoughts<o:p></o:p></span></p>
<div>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Dear Ian,</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Sorry but I think there is a misunderstanding of my intentions in this discussion. I will start by answering your conclusion before replying to some details</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Sorry, but we need to to take full advantage of the flexibility provided by the ObsCore Recommendation as written to serve our science users our science data,
based on our familiarity with how our science users want to access and use those data. If the IVOA is unwilling to support the needs of high-energy astrophysics, or at least of this very large HEA data provider, then I want to hear that stated directly and
clearly by the IVOA Exec.<o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#EF2929">T</span><span style="font-family:"Arial",sans-serif;color:#6699FF">wo things :
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">First : I never, never claimed that data which are important for your group, for Chandra to expose should not be exposed in the VO. I thought I was clear on that several
times. I only challenge the idea that ObsCore is the right way for everything. And<u> I proposed
</u>several other solutions fully VO consistent to do that (two DataLink solutions, multiple tables with joins) in my post 4 weeks ago on PR #35 (<a href="https://github.com/ivoa/HighEnergyObsCoreExt/pull/35" target="_blank">https://github.com/ivoa/HighEnergyObsCoreExt/pull/35</a>).
It would be good to have you opinion about those.</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Second : I am interested in this project and insist to give some advice because I think my experience in building several VO protocols can be useful, as well as my knowledge
of the way several major data providers such as CADC, GAVO, VizieR and others implemented them and I hope the exec will not consider I am doing any harm in discussing the best way to expose data.
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">A few more details below
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Le 02/03/2026 à 23:01, Dr. Ian N. Evans a écrit :<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Dear Francois,
<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">You are of course entitled to your opinion. However, what you are arguing is in my view inconsistent with the wording of the ObsCore Recommendation, Version
1.1.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">As stated in section “1. Introduction”, of the Recommendation “... The ability to pose a single scientific query to multiple archives simultaneously is a
fundamental use case for the Virtual Observatory. Providing a simple standard protocol such as the one described in this document increases the chances that a majority of the data providers in astronomy will be able to implement the protocol, thus allowing
data discovery for almost all archived astronomical observations.” That is exactly what we are proposing here, with the scientific data products required for high-energy astrophysics.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">---> I think many of the products you store in your archive (as presented in the document) are fundamentally not so far from "flat fields", "dark images"
"psf" in optical astronomy, not to speak about various auxiliary data in radio interferometry. I don't know any of the main services exposing such response functions in the same service than the main sky data. However most of them provide ways to retrieve
such response functions or auxiliary data from fundamental sky data. Even The HESS prototype is not exposing response functions as independent products in ObsCore. Why Would Chandra be so different that you need to use the ivoa.ObsCore table to expose them
instead of other related tables ? </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For HESS we have not (yet) expose the IRFs in VO because we could not without the HE extension... simply ;)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">The peculiarity of the VHE data, compared to other field, is that we have IRFs PER observation en general. This explains the need of bundles.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Without it, we would have 2 separated registries, implying to make 2 big queries and then leave the user to recombine the data. I think this is quite odd!<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Further, under section “2. Use cases”, the Recommendation states “Support any type of science data products (image, cube, spectrum, time series, instrumental
data, etc.).” All of our data products satisfy this definition (and in fact instrument responses are a perfect example of “instrumental data”).<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">--> Our understanding of "instrumental data" was sky data at a very raw level. And again there is absolutely no practice in the VO to expose response functions
in ObsCore</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">IRFS are not raw data, but products of high level. So info, almost the same pipeline is used to make the event list and the IRFs. The pipeline runs on observation
raw data yo get the event list and on the stimulated raw data yo get the IRFs.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">There are somehow at the same calib level, which is not intuitive for non-experts.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">But you say “By science data we mean data where we can detect some information of interest coming from the sky.” Sorry, but YOU don’t get to tell US what
constitutes OUR “science data”. Section “3.3.3. Observation and Observation Dataset” of the Recommendation states “exactly what comprises an “observation” is not well defined within astronomy and is left up to the data provider to define for their data.”
for a reason. Science data products vary dramatically from waveband to waveband, and even within a waveband from instrument to instrument depending on the physical mechanism used by the detector. We consider instrument responses to be “science data” and
very much part of the “observation dataset”.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">---> Ok if you don't agree with my definition of science data which was based on what I have seen in ObsTAP services so far, let's talk about "sky data"
instead. Again I am not arrogant enough to force you to expose or not such and such data, but I think I can give advice on where to put them according to experience that all the services have followed so far. What they have done is consistent with the sentence
in the same section 3.3.3 which reads "ObsTAP only directly supports the description of science data products, i.e., data products which contain science data having some physical (spatial, spectral, temporal) coverage."
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Again, the HE is peculiar and naturally the past definitions need updates.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For us, since 30 years, products like exposure is a science data. Not intuitive again.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">An exposure is by definition deeply associated to a spatial, spectral and temporal coverage. It permits to derive the expected number of counts per forward-folding.
Only HE (and polarisation) are using this statistical technics to get advanced products (like flux, spectrum, sed, morphology).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">So, indeed, this is this new in IVOA, oldish for us. Definitions would need to be updated, even we do not aim for the moment to use ObsTAP standards. <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Further down, section 3.3.3. Observation and Observation Dataset” of the Recommendation states “Two different approaches can be followed for exposing the
instrumental data from an observation. One can either expose the individual science data products resulting from the observation, all sharing the same obs_id, or one can “package” the data products and expose the package as a single complex instrumental data
product. ... Which approach is best depends upon the anticipated scientific usage and is up to the data provider to determine.” Again this is sensibly up to the data provider because the data provider is the one with the understanding of how the provider’s
science users access and use their data.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">---> the same section reads immediately after "If the data products comprising an observation are exposed individually then attributes such<br>
as the calibration level can vary for different data products, e.g., the raw instrumental data as observed might be level 1, a standard pipeline data product might be level 2, and a custom user-processed data product subsequently published back to the archive
might be level 3. All such data products would share the same obs_id." Clearly this sentence highlighted the intention that we were building a protocol to expose "sky data" at whatever calibration level and not for response functions. Because I don't understand
how we can define a calibration level for a response function !</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">You are hard with us! Again, without response functions, no flux! Then, we do not need VO!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Either people accept responses, either we leave IVOA.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Concerning the definition os calibration level, I would like to stress that he current definition is not coherent, not logical. One can not derive a coherent
data model from it. Taking its definition to reject responses is a bit difficult to read and to understand.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">You further posit that “If we don't do this and extend the domain of ObsCore too much we force it to become something else and to loose universality.” On
what basis do you make that assumption? Certainly for Chandra data for example, our instrument responses all map to a specific spatial, spectral, and temporal coverage region on the sky. The use cases in Appendix A of the HEA ObsCore Extension almost all
comprise queries that are based on sky geometry, spectral, or temporal coverage, with a few others based on obs_id.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">---> I think there are two situations : </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> - either response function are estimated by exposing the instrument to experimental flux in order to provide a generic response function
valid for a set of observations (like we can do for a dark or a flat or a spectral response). In that case the "obscore characterisation" of this response function considered as a dataproduct in ivoa.obscore table would simply be borrowed from the sky data
we would relate to this response function. So mapping those to a specific spatial, spectral, and temporal coverage region on the sky is wrong because the actual characterisation of the response dataset in its own domain is probably very different. Appendix
A examples don't go against this interpretation of how the obscore parameters are filled. This is why I think we are losing universality in doing this. This would be a very divergent way of interpreting the ObsCore characterisation parameters.</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> - or response function are directly estimated from the sky data themselves via an analysis (I guess this is how psf are generally obtained
by estimating the profile of a point source in the data). Then the response is actually part of the description of the sky data. It's level 4 characterisation ( 1 -> location, 2 -> bounds, 3 -> support, 4 -> functional response) It's not a different product. </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">But the ivoa.obscore table doesn't provide level 4 characterisation. If desired it has to be provided by a link.
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> In both cases the binding to all response or auxiliary functions can be done with the main sky dataset either by Classical DataLink or by joining
two different tables (ivoa.obscore with any kind of description/access table for response function) as I have explained in my post in PR #35 (<a href="https://github.com/ivoa/HighEnergyObsCoreExt/pull/35" target="_blank">https://github.com/ivoa/HighEnergyObsCoreExt/pull/35</a>)</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">None is these 2 cases, and at the same times both. We have 4 IRFs, and depending of its type we have a different process.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">I can give you a technical talk to have an idea how the 4 are generated.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">You commented “When we designed ObsCore the intention was to design a data model and an associated tap table to expose science data.”, and that is great.
However, I doubt very much that the design team included representation from the full range of wavebands or complete representation of different types of experiments, facilities, or missions, and as a result the inputs that went into building the standard
(for example, what constitutes “science data”) would have been incomplete. You did an amazing job given the inputs that you had! But standards evolve with time as they become more complete, or they wither and die. ObsCore is currently evolving based on
needs from radio, timing, and high-energy astrophysics, and this should be celebrated because it means that the standard is not withering and dying.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">---> The radio extension was a way to provide a better description of radio sky data themselves, not to add calibration data, this is already a great evolution
and the additional parameters in the HeIG extension follow the same philosophy. That's already a great change. And for root ObsCore itself the characterisation datamodel which is at the basis of it and the Obscore specification itself were co-authored with
people from almost all domains including High Energy. The HESS prototype doesn't provide access to response function apart from the event list via the event-bundle product type. So I don't think High energy use cases were totally ignored in this work.
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">See my reply about HESS above! We can't<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Radio is not HE: the comparison does not hold.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Sorry, but we need to to take full advantage of the flexibility provided by the ObsCore Recommendation as written to serve our science users our science data,
based on our familiarity with how our science users want to access and use those data. If the IVOA is unwilling to support the needs of high-energy astrophysics, or at least of this very large HEA data provider, then I want to hear that stated directly and
clearly by the IVOA Exec.<o:p></o:p></span></p>
</div>
</blockquote>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">---> My final question to you : "what is so wrong with combining ObsCore and other adapted VO Technics to expose all kind of data with more flexibility". </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Awfull, nightmare, complexity, reduced maintability... should I continue?</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">We are not ready to support this proposal, that will imply to reject the HE specificities by the IVOA, illustrating the rigidity of IVOA to new bands in
the em spectrum and to new messagers. But I know that this not your case. You have just to realize that, without bundling IRFs to events, any other technical solution will lead to NEVER use the VO for the HE. We will then continue to use standard web sites,
leading to no interoperability between all wavelengths and messengers of the IVOA, which at the opposite of all EU and USA astrophysics roadmaps.</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Responses are MANDATORY and just be delivered with the event list with the SAME query.</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Thanks again,</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Cheers,</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Bruno</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF"> </span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 12.0pt;margin-left:9.6pt;margin-right:0in">
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">I am ready to write a section highlighting how this combination can be done.</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">Best regards</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:#6699FF">François</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">—Ian<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">On Feb 24, 2026, at 08:43, BONNAREL FRANCOIS gmail via heig
<a href="mailto:heig@ivoa.net" target="_blank"><heig@ivoa.net></a> wrote:<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Dear Bruno, dear Ian, all<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">We come back to this.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">There is no doubt for us that VO should provide ways to expose such things as "background images" or in your case, Bruno, background rate.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Our concern is about forcing ObsCore to be this way to expose such datasets.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">When we designed ObsCore the intention was to design a data model and an associated tap table to expose science data.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">By science data we mean data where we can detect some information of interest coming from the sky.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">If we don't do this and extend the domain of ObsCore too much we force it to become something else and to loose universality.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">So according to this general definition we don't think response function belong to the ObsCore domain. Advanced data products are another issue we won't discuss
them today.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Of course there are plenty of ways to expose those data and relate them with science data. VO must for sure improve their description and access modes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">DataLink is the minimal method to make response data accessible and relate them to relevant science data but may present the drawback to be a "two steps"
process. If direct access to response data is required in a one step process we suggest to explore the solution of defining the DataLink response table as a TAP table in order to allow JOINS with the ObsCore science data table. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">But it is true that the description provided by DataLink is rather poor. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">So, alternativeky, when needed, different tables may be defined to describe response function datasets and provide pointers to them if necessary.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> A table with ucd on most of the columns (existing ucds or new ones to define) would already provide a lot of interoperability between services providing
response data.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> Moreover, defining "response function data models" may provide more flexible and accurate descriptions and acces methods. Datamodels may be embedded in
VOTables and mapped to columns using utypes or Mango+Mivot.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> We think some sections of the HeiG note should be revised in these directions.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> We are ready to help to do that. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">François with Mireille<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Le 07/02/2026 à 19:15, Bruno Khelifi via heig a écrit :<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Hi all,<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">About "Background images and pixel masks are not response-function data products", maybe this is the case for X-rays. I won't discuss it.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">As reminder, the term `background` is very generic and can be used for everything. In gamma-ray astronomy, it is from cosmic rays (it is not broken pixels, that are handled
much more earlier during the raw data processing). In the GeV, TeV, PeV, the background rate is without any doubt an IRF!<br>
In contrary to X-rays, 3D analysis are routinely made. For that the counts are compared with the predicted counts, that is the sum of the ones associated to gamma rays and the ones associated to the background rate, that are badly classified events as gamma-rays
(see our notes). The estimation of the background rate can not be done on the data, because they are gamma rays everywhere in the field of view for the galactic plane (ie one can not use 'OFF' regions). As reminder, the Fermi bubble or eRosita bubble are going
very up in latitudes. Also, one can not use simulations of cosmic rays to estimate the background, because the resources would be much too high and also because the simulations badly reproduce the reality (many studies made since decades show that). We use
a complex pipeline that takes in input data, creates some exclusion masks iteratively in 3D, generates templates of rate in an hypercube ( [X,Y] or theta, atmospheric quality observable, optical efficiency of our instruments, Zenith angles, azimuth angles
between of the geomagnetic effect on the extensive air showers, and reconstructed energy), curates the data to handle empty bins and low statistics bin, interpolates this hypercube template to compute the observation-wise background rate.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For the neutrino telescopes, real data are also used. A specific pipeline is of use also to compute the background rate.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">So, one should keep without any doubt the background rate as data product!<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Best,<br>
Bruno<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Le 04/02/2026 à 20:38, Dr. Ian N. Evans via heig a écrit :<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Dear Francois,
<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">I consider the arf, rmf, and psf to be response-function data products. Background images and pixel masks are not response-function data products - they
are determined directly from the observation event list similarly to a total counts image. Bad pixel is a region data product, but it’s something of a gray area since it’s a combination of known bad pixel regions plus bad pixel regions derived directly from
the observation event list.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For the Chandra Source Catalog (CSC) prototype, at least initially we plan to expose all of the data products directly to demonstrate that the extension provides
the flexibility that we need. However in production, we likely would not expose all of the data products individually but rather combine some of them with the event lists as event bundles (at least for the individual observation full-field data product set).
We would want to expose the individual observation event lists individually, but might choose for example to construct an event bundle that exposes (at least) the event list, bad pixel regions, aspect histogram, and possible aspect solution as a bundle since
there is very little use for the latter 3 types of data product without the event list.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">While tying associated and derived data products to an event list in an event bundle seems sensible for individual observations, our experience is that this
isn’t appropriate for the CSC advanced data products. Since CSC 2.0 was released we have had millions of catalog data product downloads and surveyed our user base as to data product usage.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">The typical usage patterns for the CSC advanced data products are different from the typical usage patterns for individual X-ray observation data.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For the latter the user typically downloads the event list and ancillary data products (such as responses or other data products that can be used to build
responses) as a set, and then performs data analysis steps directly on the event list using the ancillary data products, often after applying spatial/spectral/temporal filters to the data. Event bundles facilitate this usage.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For the CSC advanced data products the usage patterns are quite different. Many (most) of these advanced data products are derived from multiple (in some
cases hundreds) observations. Typically the users aren’t interested in performing data analysis steps on the event lists themselves, and often aren’t interested in knowing which observation(s) they are derived from (at least not from the perspective of having
to perform a data query). They just want (e.g.) all the spectra (or light curves, or photometry MPDFs, or ...) in a certain region of the sky, or in a given time range, etc. And given the data volume that’s all they want. Maybe they’ll come back later and
ask for a subset of additional data products after they’ve performed some preliminary analyses on those data products, but they don’t want those up front.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Based on these usage patterns, I think we will likely want to expose the remaining CSC data products individually.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">—Ian<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">On Jan 27, 2026, at 09:52, BONNAREL FRANCOIS gmail via heig
<a href="mailto:heig@ivoa.net" target="_blank"><heig@ivoa.net></a> wrote:<o:p></o:p></span></p>
</div>
<div>
<div>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Dear all,<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">After the meeting last week, I was still thinking about what the Chandra prototype could look like<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For the Paris HESS prototype, I get the idea since a couple of years now.
<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">Trying to understand what the CSC data products could be I came back to Ian's Malta interop presentation.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">I copy/paste here one of the slides where some of these products are described.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">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<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">an ObsTAP service.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">For example background images, psf, pixel mask, bad pixel regions, ARF belong to the "response functions" category if I'm not mistaking.
<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">They probably are attached to a photon event list or an image or ....<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">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.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">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 ?<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">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.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> 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.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> 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.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> 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<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> 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 :<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> - time range to a psf or<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> - specific release date and description to an arf or a bad pixel map<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> -....
<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> Natural join on obs_publisher_did in both tables will allow to query those table at the same time with selection criteria from both.<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> Cheers<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">François<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">
<o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><ulnvpjC4zXtPT0zn.png><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">--
<br>
heig mailing list<br>
<a href="mailto:heig@ivoa.net" target="_blank">heig@ivoa.net</a><br>
<a href="https://www.google.com/url?q=https://www.google.com/url?q%3Dhttp://mail.ivoa.net/mailman/listinfo/heig%26source%3Dgmail-imap%26ust%3D1770130364000000%26usg%3DAOvVaw1NuTRL3a6Ib8NM2g8f0TM8&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1VPiNz8zudrIQeUMJoRNTa" target="_blank">https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1770130364000000&usg=AOvVaw1NuTRL3a6Ib8NM2g8f0TM8</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><b><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">—</span></b><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><b><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Dr. Ian Evans</span></b><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><strong><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Astrophysicist</span></strong><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><strong><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Chandra X-ray Center</span></strong><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><b><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black;background:white">Center for Astrophysics | Harvard & Smithsonian</span></b><span style="font-size:9.0pt;font-family:"-webkit-standard",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Office: (617) 496 7846 | Cell: (617) 699 5152</span><span style="font-size:9.0pt;font-family:"-webkit-standard",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">60 Garden Street | MS 81 | Cambridge, MA 02138</span><span style="font-size:9.0pt;font-family:"-webkit-standard",serif;color:black"><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><PastedGraphic-2.png>
</span><span style="font-size:9.0pt;font-family:Monaco;color:black"><br>
<br>
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Monaco;color:black"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><PastedGraphic-3.png>
</span><u><span lang="EN" style="font-family:"Arial",sans-serif;color:black"><a href="https://www.google.com/url?q=http://cfa.harvard.edu/&source=gmail-imap&ust=1772545426000000&usg=AOvVaw0uFI_1KoCUvDnmcfLwnZWl" target="_blank">cfa.harvard.edu</a></span></u><span lang="EN" style="font-family:"Arial",sans-serif;color:black"> | <u><a href="https://www.google.com/url?q=http://cfa.harvard.edu/facebook&source=gmail-imap&ust=1772545426000000&usg=AOvVaw02xqYrC2mM2M8D3GD_fAAy" target="_blank">Facebook</a></u> | <u><a href="https://www.google.com/url?q=http://cfa.harvard.edu/twitter&source=gmail-imap&ust=1772545426000000&usg=AOvVaw3ilzQjksdV2EyBorR2VpR3" target="_blank">Twitter</a></u> | <u><a href="https://www.google.com/url?q=http://cfa.harvard.edu/youtube&source=gmail-imap&ust=1772545426000000&usg=AOvVaw39-gxMDL8maWEsAwabab0W" target="_blank">YouTube</a></u> | <u><a href="https://www.google.com/url?q=http://cfa.harvard.edu/newsletter&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1GftJaRGdajEXnp9-teyn8" target="_blank">Newsletter</a></u></span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<pre style="margin-left:.5in"><span style="color:black">-- <o:p></o:p></span></pre>
<pre style="margin-left:.5in"><span style="color:black"><o:p> </o:p></span></pre>
<pre style="margin-left:.5in"><span style="color:black"> Bruno Khelifi<o:p></o:p></span></pre>
<pre style="margin-left:.5in"><span style="color:black"> Physicist at CNRS (laboratory APC, Paris)<o:p></o:p></span></pre>
<pre style="margin-left:.5in"><span style="color:black"> Phone: +33.1.57.27.61.58 - Fax: +33.1.57.27.60.71<o:p></o:p></span></pre>
<pre style="margin-left:.5in"><span style="color:black"> APC, IN2P3/CNRS - Universite de Paris Cite<o:p></o:p></span></pre>
</blockquote>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black">--
<br>
heig mailing list<br>
<a href="mailto:heig@ivoa.net" target="_blank">heig@ivoa.net</a><br>
<a href="https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1CKWt3qicSCcjAbQuwDfB1" target="_blank">https://www.google.com/url?q=http://mail.ivoa.net/mailman/listinfo/heig&source=gmail-imap&ust=1772545426000000&usg=AOvVaw1CKWt3qicSCcjAbQuwDfB1</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><b><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">—</span></b><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><b><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Dr. Ian Evans</span></b><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><strong><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Astrophysicist</span></strong><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><strong><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Chandra X-ray Center</span></strong><span style="font-size:9.0pt;font-family:Monaco;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><b><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black;background:white">Center for Astrophysics | Harvard & Smithsonian</span></b><span style="font-size:9.0pt;font-family:"-webkit-standard",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">Office: (617) 496 7846 | Cell: (617) 699 5152</span><span style="font-size:9.0pt;font-family:"-webkit-standard",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:black">60 Garden Street | MS 81 | Cambridge, MA 02138</span><span style="font-size:9.0pt;font-family:"-webkit-standard",serif;color:black"><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><img border="0" width="263" height="2" style="width:2.7395in;height:.0208in" id="_x0000_i1026" src="cid:image002.png@01DCB85C.70866470"></span><span style="font-size:9.0pt;font-family:Monaco;color:black"><br>
<br>
</span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:9.0pt;font-family:Monaco;color:black"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"><img border="0" width="111" height="49" style="width:1.1562in;height:.5104in" id="_x0000_i1025" src="cid:image003.png@01DCB85C.70866470"></span><u><span lang="EN" style="font-family:"Arial",sans-serif;color:black"><a href="http://cfa.harvard.edu/" target="_blank">cfa.harvard.edu</a></span></u><span lang="EN" style="font-family:"Arial",sans-serif;color:black"> | <u><a href="http://cfa.harvard.edu/facebook" target="_blank">Facebook</a></u> | <u><a href="http://cfa.harvard.edu/twitter" target="_blank">Twitter</a></u> | <u><a href="http://cfa.harvard.edu/youtube" target="_blank">YouTube</a></u> | <u><a href="http://cfa.harvard.edu/newsletter" target="_blank">Newsletter</a></u></span><span style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
</div>
</blockquote>
<p style="margin-left:.5in"><span style="font-family:"Arial",sans-serif;color:black"> <o:p></o:p></span></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>