<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Dear all,</div>
    <div class="moz-cite-prefix">Just to advise you I raised a PR with
      some changes/addition on use case 1.4 and 1.6 of the
      HighEnergyObsCoreExt note.<br>
    </div>
    <div class="moz-cite-prefix">For some reasons the build workflow 
      was not run on it, so you are probably not made aware of this by
      github</div>
    <div class="moz-cite-prefix">I also plan to write an issue on use
      case 1.3 and 1.9 in the coming hours/days</div>
    <div class="moz-cite-prefix">An issue because the changes there
      would need more discussion than on 1.4 and 1.6</div>
    <div class="moz-cite-prefix">Cheers</div>
    <div class="moz-cite-prefix">François<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Le 27/01/2026 à 15:52, BONNAREL
      FRANCOIS gmail a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:a220c02b-5396-4ccb-9715-9bf408b1effc@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <p>Dear all,</p>
      <p>After the meeting last week, I was still thinking about what
        the Chandra prototype could look like</p>
      <p>For the Paris HESS prototype, I get the idea since a couple of
        years now. <br>
      </p>
      <p>Trying to understand what the CSC data products could be I came
        back to Ian's Malta interop presentation.</p>
      <p>I copy/paste here one of the slides where some of these
        products are described.</p>
      <p>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>an ObsTAP service.</p>
      <p>For example background images, psf, pixel mask, bad pixel
        regions, ARF belong to the "response functions" category if I'm
        not mistaking. <br>
      </p>
      <p>They probably are attached to a photon event list or an image
        or ....</p>
      <p>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>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>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>    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>   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>   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>  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>      - time range to a psf or</p>
      <p>      - specific release date and description to an arf or a
        bad pixel map</p>
      <p>      -.... <br>
      </p>
      <p>      Natural join on obs_publisher_did in both tables will
        allow to query those table at the same time with selection
        criteria from both.<br>
      </p>
      <p>   Cheers</p>
      <p>François<br>
      </p>
      <p>  <br>
      </p>
      <p><br>
      </p>
      <p><br>
      </p>
      <p><img src="cid:part1.0ENWG3eP.LZvLqI4b@gmail.com" alt=""
          class=""></p>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>