<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Tess, all</p>
    <p><br>
    </p>
    <p>to illustrate number 3 I created a github issue on the document,
      rephrasing two of the use cases (A.1.3 and A.1.)<br>
    </p>
    <p><br>
    </p>
    <p><a class="moz-txt-link-freetext" href="https://github.com/ivoa/HighEnergyObsCoreExt/issues/36">https://github.com/ivoa/HighEnergyObsCoreExt/issues/36</a></p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 27/01/2026 à 18:16, Jaffe, Tess
      (GSFC-6601) a écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:MN2PR09MB54998E85FF7C5B40DA395727E690A@MN2PR09MB5499.namprd09.prod.outlook.com">
      <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>
      <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>
    </blockquote>
    <p>Yes in that case you can select on datalink.response.content_type
      in the JOIN table</p>
    <p><br>
    </p>
    <p>Cheers</p>
    <p>François<br>
    </p>
    <blockquote type="cite"
cite="mid:MN2PR09MB54998E85FF7C5B40DA395727E690A@MN2PR09MB5499.namprd09.prod.outlook.com">
      <div
style="font-family: Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"
        class="elementToProof">
      </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:part1.nxPzNHU7.cGhZJ3Oo@gmail.com" class=""> </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 <a class="moz-txt-link-rfc2396E" href="mailto:heig-bounces@ivoa.net"><heig-bounces@ivoa.net></a> on behalf of
          BONNAREL FRANCOIS gmail via heig <a class="moz-txt-link-rfc2396E" href="mailto:heig@ivoa.net"><heig@ivoa.net></a><br>
          <b>Sent:</b> Tuesday, January 27, 2026 9:52 AM<br>
          <b>To:</b> Janet Evans via heig <a class="moz-txt-link-rfc2396E" href="mailto:heig@ivoa.net"><heig@ivoa.net></a><br>
          <b>Subject:</b> [EXTERNAL] [BULK] [Heig] Post running meeting
          thoughts</div>
        <div style="direction: ltr;"> </div>
      </div>
      <table
style="border-width: 2px; border-style: solid; border-color: black;"
        cellspacing="0" align="left">
        <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:part2.MziVln0I.qRKuHXTo@gmail.com" class=""></p>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>