<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<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.601HUn9S.HmZf1KQZ@gmail.com" alt=""></p>
</body>
</html>