[Heig] [HEIG -Obscore extension ] Distributing observation data sets together with instrumental response functions

[Laurent Michel]

Dear Ian,


I don't think pushing datasets out of Obscore requires implementing a new access interface as you seem to fear.

Obscore is just one table in a TAP service that can contain hundreds of other tables.
All of these tables are well described in the TAP schema, including how they are joined.
They can be retrieved by exploring that TAP schema.

For instance, we can expose a table for the RMFs in a table named inst_responses.rmf, and we can provide the TAP schema with the 
key to join it with the event list of obcore.

In my opinion, it's better not to mix products with different purposes on the same table (even Obscore).
The purpose of Obscore is to improve interoperability, based on the idea that it makes sense to run the same query on different 
databases because the resulting datasets can be compared with each other in some way.
The instrument responses do not fit with this pattern, which is why I would not put them in Obscore.

Laurent

Le 23/05/2025 à 19:42, Dr. Ian N. Evans via heig a écrit :
> 
>> The response functions belong to the instrumental/calibration information , and probably are stored in Calibration DB .
>> I think this is not homogeneous in content with the observation datasets representing flux variation on the sky,
>> so they should not be considered as Obscore data product type.
>>
> I don't agree with this suggestion.  If only datasets “representing flux variation on the sky” should be included in ObsCore, 
> then that also means that many types of “advanced data products” would also not qualify for inclusion in ObsCore (even if they 
> refer to a constrained spatial/spectral/temporal location such as the region surrounding a detected source).
> 
> I think the IVOA works because it tries to be encompassing.  But from the perspective of a science end-user, why would I want to 
> use IVOA interfaces for data discovery if I know I have to use another interface to ensure I can find all of the data products 
> in the high-energy waveband?  Conversely, from the perspective of a HEA data provider, why would I want to put the effort into 
> supporting an IVOA interface if it can’t serve all of my data products (knowing that I’m going to have to provide a second 
> interface that can)?
> 
> In principle, one could propose an alternative IVOA-supported data discovery interface that doesn’t have the same restrictions 
> that you are suggesting for ObsCore.  But practically, we know how long it takes for anything to become a reality in the IVOA, 
> and so this approach doesn’t seem terribly realistic.  But why would any end-user or data provider want to use two interfaces to 
> circumvent what seems to be an artificial constraint?
> 

--
English version: https: //www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg