A few comments on the draft

[Bonnarel]

section 4.5 : The section chooses the term "obs_mode" to describe how the sky is scanned around a source ( in the text in one single spatial direction). This looks very similar to the ObsCoreExtensionForRadioData scan_mode term. If this is true I think it should be good to call the section (and the term) scan_mode too.

section 4.6 : tracking_mode: definitely this is the same concept to what ObsLocTAP calls tracking_type. A reference to this spec would be good there and changing the term too. Note that the ObsCoreExtensionForRadioData PR recently proceeded to this change

section 5.1.2 : response functions

  I have three concerns there which I share with some of you (Mireille for example)

    +  up to now dataproduct_type was a vocabulary giving names to express the way various physical axes were spanned   and which observable was tackled. The list in this section differs significantly from this. Of course edisp and arf are close to spectra ( with the observable being an "effective area" or a probability. But it's more difficult for matrices such as rmf (two different "energy" axes ?)  or psf (delocalised)

    + the definition of   the terms in this subsections obviously mixes some aspects related to axes and observables and the role of the response function in the analysis or calibration process. This is obvious bkgrate which looks simlar to an event list (to be substracted to the total sky event list if I understand well.

    + the inclusion of these datasets in Obscore will face the issue that some of the other parameters (location/bounds parameters) will not be filled which will be a real pity for interoperability. 

With all this I think the description access mode of reponse functions should be revisited. Specific modeling and specific tables may be interesting and bi-directional DataLink tables could be used to link datasets to relevant responses and responses to reelvant datasets     

[iannevans]

section 4.5 : The section chooses the term "obs_mode" to describe how the sky is scanned around a source ( in the text in one single spatial direction). This looks very similar to the ObsCoreExtensionForRadioData scan_mode term. If this is true I think it should be good to call the section (and the term) scan_mode too.

I agree with you. scan_mode was present in the original draft and identified as similar to the radio extension scan_mode (likely a superset of the proposed radio values, to account for scanning functionality of satellite-based observatories). obs_mode is something different. These definitions got munged in the latest draft update. I identified that these need to be resolved in a previous comment.

section 4.6 : tracking_mode: definitely this is the same concept to what ObsLocTAP calls tracking_type. A reference to this spec would be good there and changing the term too. Note that the ObsCoreExtensionForRadioData PR recently proceeded to this change

We want to be consistent with the radio extension here (to avoid what would otherwise be ugly constructs when doing cross-waveband queries), but the latest version of the radio extension that I have seen still uses tracking_mode. If the radio extension is switching to tracking_type then we should as well.

At the same time, I don't think this change is optimal. Using tracking_mode we would have queries by scan_mode, obs_mode, analysis_mode, and tracking_mode. Change to tracking_type and one has to remember this one is special and isn't a "mode". It doesn't matter particularly from the data provider perspective, but from the user perspective it's just another thing the user has to remember. In my view, we should be doing everything in our power to make life as simple and easy as possible for the user, and this is a change that makes the user's life harder, not easier.

section 5.1.2 : response functions

  I have three concerns there which I share with some of you (Mireille for example)

    +  up to now dataproduct_type was a vocabulary giving names to express the way various physical axes were spanned   and which observable was tackled. The list in this section differs significantly from this. Of course edisp and arf are close to spectra ( with the observable being an "effective area" or a probability. But it's more difficult for matrices such as rmf (two different "energy" axes ?)  or psf (delocalised)

Well that's already not true. dataproduct_type includes both "spectrum" and "sed", which have the same physical axes. But "sed" is a distinct dataproduct_type from "spectrum" because the content of the files is different. In my opinion this is a good thing. Anything we can do to make data discovery easier for the user we should do. It’s easy when you archive only includes images and spectra to say "just query the ra and dec you’re interested in and get back the images or spectra you’re interested in." It’s way harder for the archival user when the archive includes 50 different types of data products and the only things you can query for are images and spectra. And that is the situation we are currently in.

+ the definition of   the terms in this subsections obviously mixes some aspects related to axes and observables and the role of the response function in the analysis or calibration process. This is obvious bkgrate which looks simlar to an event list (to be substracted to the total sky event list if I understand well.

I think the real issue here is that ObsCore confuses "observables" with "physical axes". In a CCD image or spectrum for example, the observables are actually the pixel positions on the detector and the DN recorded in each pixel. And there is typically a representation of an exposure start/stop time that is really a recorded observable value that may/may directly correspond to the actual time of the exposure in any physical time system.

To translate these to physical spatial, spectral, and temporal axes a (possibly complex) set of calibrations must be applied that map the observables to physical quantities that are aligned along the physical axes. ObsCore seems to implicitly assume that that such a mapping is monotonic and a single observable axis maps to a single physical axis (allowing for rotation of bases) and further assumes that these mappings can be established prior to user data analysis (i.e., the calibrations necessary to derive the mappings can be determined a priori). On the basis of the assumption ObsCore treats observable and physical axes similarly. However, while this assumption is typically valid for simple optical images and spectra (at least for modern instrumentation) it is not necessarily valid. A single axis of a raw (uncalibrated) dataset may or may not map monotonically to a single physical spatial/spectral/temporal axes, and the mappings from observables to physical axes may not be determined a priori (in fact they may not be determinable at all in the extreme Poisson regime - see my previous comments elsewhere regarding response functions being "decalibrations" rather than "calibrations"). High-Energy Astrophysics is one waveband where the distinction between observable quantities and physical quantities really matters.

+ the inclusion of these datasets in Obscore will face the issue that some of the other parameters (location/bounds parameters) will not be filled which will be a real pity for interoperability. 

I'm not sure why you conclude this. If you look at the use case examples in Appendix A, all of the queries for these types of datasets are spatially, spectrally, and/or temporally constrained. The example ObsCore table entry for a PSF that I distributed in May included fully populated location and bounds parameters (although some mandatory parameters such as t_resolution and some optional parameters were set to NULL). Of course, no one can guarantee that all data providers will fully populate these parameters but they are the most important parameters for data discovery.

With all this I think the description access mode of reponse functions should be revisited. Specific modeling and specific tables may be interesting and bi-directional DataLink tables could be used to link datasets to relevant responses and responses to reelvant datasets

Once again, datalink may be fine for those cases where the data products should be linked to the progenitor observations (i.e., event-bundles), but many of our use cases illustrate that the user is not interested in retrieving the progenitor observation event-lists (which for some queries could be thousands of unwanted data products totaling hundreds of GB).

[Bonnarel]

Partial answer, Ian

section 4.6 : tracking_mode: definitely this is the same concept to what ObsLocTAP calls tracking_type. A reference to this spec would be good there and changing the term too. Note that the ObsCoreExtensionForRadioData PR recently proceeded to this change

We want to be consistent with the radio extension here (to avoid what would otherwise be ugly constructs when doing cross-waveband queries), but the latest version of the radio extension that I have seen still uses tracking_mode. If the radio extension is switching to tracking_type then we should as well.

At the same time, I don't think this change is optimal. Using tracking_mode we would have queries by scan_mode, obs_mode, analysis_mode, and tracking_mode. Change to tracking_type and one has to remember this one is special and isn't a "mode". It doesn't matter particularly from the data provider perspective, but from the user perspective it's just another thing the user has to remember. In my view, we should be doing everything in our power to make life as simple and easy as possible for the user, and this is a change that makes the user's life harder, not easier.

The last version for Radio extension on github is there : https://camo.githubusercontent.com/0100ff5b41e2f372e28a83ca08b9f99149521562dd0270650c64f93482a50979/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f507265766965772d5044462d626c7565

and reads "tracking_type". The reason for the change was simple. ObsLocTAP was a REC well before us. And they choosed tracking_type. And obviously it was the same concept (and even the same terms could be adopted) . So we had to move to be compliant.

[Bonnarel]

New partial answer

section 5.1.2 : response functions

  I have three concerns there which I share with some of you (Mireille for example)

    +  up to now dataproduct_type was a vocabulary giving names to express the way various physical axes were spanned   and which observable was tackled. The list in this section differs significantly from this. Of course edisp and arf are close to spectra ( with the observable being an "effective area" or a probability. But it's more difficult for matrices such as rmf (two different "energy" axes ?)  or psf (delocalised)

Well that's already not true. dataproduct_type includes both "spectrum" and "sed", which have the same physical axes. But "sed" is a distinct dataproduct_type from "spectrum" because the content of the files is different. In my opinion this is a good thing. Anything we can do to make data discovery easier for the user we should do. It’s easy when you archive only includes images and spectra to say "just query the ra and dec you’re interested in and get back the images or spectra you’re interested in." It’s way harder for the archival user when the archive includes 50 different types of data products and the only things you can query for are images and spectra. And that is the situation we are currently in.

sed and spectra differ by the way the spectral axis is spanned (regular/irregular) and y the resolution of the individual samples. So I think this kind of distinction is included in the phrase "the way various physical axes were spanned"

[bkhelifi]

the definition of the terms in this subsections obviously mixes some aspects related to axes and observables and the role of the response function in the analysis or calibration process. This is obvious bkgrate which looks simlar to an event list (to be substracted to the total sky event list if I understand well.

In fact, not! First the unit (rate in Hz, whereas an event list has many parameters)... bkgrate has one value per bin, the event list has many entries per row...

the inclusion of these datasets in Obscore will face the issue that some of the other parameters (location/bounds parameters) will not be filled which will be a real pity for interoperability.

No choice, except if we change the whole ObsCore. And this is not what we all wish. Even for the event_list, we will have null entries, or entries with some numbers that are not of interest of many (VHE) users. We are not working like in optical! Just an example: when the PSF can vary from 10 degrees down to 0.1d for a given observation depending on the event energy, the ObsCore field s_resolution has just no meaning... even given at a reference energy and at a reference instrument position. So, as data provider, why adding a value in s_resolution column? For a user, why making a query on this field?
PS: I do not see the issue of interoperability (on the software making the ObsCore DB query??)
They will be NULL values in several columns, it is expected for sure. And, the existence of an extension will not change this matter of fact, the extension providing a way to render some ObsCore fields a bit meaningful. So, either HEA is using IVOA Obscore with null values, or not at all. Between X-ray missions, MeV missions, GeV detectors, Water Cherenkov Detectors, Cherenkov Telescopes, Cosmic-ray detectors, the variety of instrumental techniques is so large that we will always have NULL values.

up to now dataproduct_type was a vocabulary giving names to express the way various physical axes were spanned and which observable was tackled. The list in this section differs significantly from this. Of course edisp and arf are close to spectra ( with the observable being an "effective area" or a probability. But it's more difficult for matrices such as rmf (two different "energy" axes ?) or psf (delocalised)

IVOA should accept statistical results, because the analysis are progressing well. Do you think that IVOA should not be able to disseminate statistical results on the Hubble constant measurement? or a statistical result on a fitted source position? I think that there is no doubt that we want all that... So, probability distribution functions should be properly defined, and then products like edisp or a psf will naturally enter in this category.

[Bonnarel]

Another partial answer
``

• the definition of the terms in this subsections obviously mixes some aspects related to axes and observables and the role of the response function in the analysis or calibration process. This is obvious bkgrate which looks simlar to an event list (to be substracted to the total sky event list if I understand well.

I think the real issue here is that ObsCore confuses "observables" with "physical axes". In a CCD image or spectrum for example, the observables are actually the pixel positions on the detector and the DN recorded in each pixel. And there is typically a representation of an exposure start/stop time that is really a recorded observable value that may/may directly correspond to the actual time of the exposure in any physical time system.

I think in the "IVOA characterization" vocabulary "observable" is another word for "dependent variable". This is obvious if we look at the "abstract characterization datamodel"
(https://www.ivoa.net/documents/REC/DM/CharacterisationDM-20080325.pdf) on which the characterization class in Obscore is based. Most of the concepts there were proposed by Jonathan McDowell, a Chandra astronomer.

To translate these to physical spatial, spectral, and temporal axes a (possibly complex) set of calibrations must be applied that map the observables to physical quantities that are aligned along the physical axes. ObsCore seems to implicitly assume that that such a mapping is monotonic and a single observable axis maps to a single physical axis (allowing for rotation of bases) and further assumes that these mappings can be established prior to user data analysis (i.e., the calibrations necessary to derive the mappings can be determined a priori). On the basis of the assumption ObsCore treats observable and physical axes similarly. However, while this assumption is typically valid for simple optical images and spectra (at least for modern instrumentation) it is not necessarily valid. A single axis of a raw (uncalibrated) dataset may or may not map monotonically to a single physical spatial/spectral/temporal axes, and the mappings from observables to physical axes may not be determined a priori (in fact they may not be determinable at all in the extreme Poisson regime - see my previous comments elsewhere regarding response functions being "decalibrations" rather than "calibrations"). High-Energy Astrophysics is one waveband where the distinction between observable quantities and physical quantities really matters.

I think you distinguish there direct method and inverse method for calibration. Fine. Maybe we could refine the datalink semantics calibration to distinguish those tow subcases.

Fir the independant variables, the abstract char data model had a calibration tag for each specific axis. maybe it could be useful to add this in ObsCore. (s_calib, em_calib, t_calib, etc...) ????

[Bonnarel]

Hi Bruno,

the definition of the terms in this subsections obviously mixes some aspects related to axes and observables and the role of the response function in the analysis or calibration process. This is obvious bkgrate which looks simlar to an event list (to be substracted to the total sky event list if I understand well.

In fact, not! First the unit (rate in Hz, whereas an event list has many parameters)... bkgrate has one value per bin, the event list has many entries per row...

Thanks for clarifying my misunderstanding. Sorry about that.

the inclusion of these datasets in Obscore will face the issue that some of the other parameters (location/bounds parameters) will not be filled which will be a real pity for interoperability.

No choice, except if we change the whole ObsCore. And this is not what we all wish. Even for the event_list, we will have null entries, or entries with some numbers that are not of interest of many (VHE) users. We are not working like in optical! Just an example: when the PSF can vary from 10 degrees down to 0.1d for a given observation depending on the event energy, the ObsCore field s_resolution has just no meaning...

That's why we introduced s_resolution_min, s_resolution_max. For discovery isn't that enough ?

even given at a reference energy and at a reference instrument position. So, as data provider, why adding a value in s_resolution column? For a user, why making a query on this field? PS: I do not see the issue of interoperability (on the software making the ObsCore DB query??)

If s_ra, s_dec may be empty I think it's a real issue.

They will be NULL values in several columns, it is expected for sure. And, the existence of an extension will not change this matter of fact, the extension providing a way to render some ObsCore fields a bit meaningful. So, either HEA is using IVOA Obscore with null values, or not at all. Between X-ray missions, MeV missions, GeV detectors, Water Cherenkov Detectors, Cherenkov Telescopes, Cosmic-ray detectors, the variety of instrumental techniques is so large that we will always have NULL values.

up to now dataproduct_type was a vocabulary giving names to express the way various physical axes were spanned and which observable was tackled. The list in this section differs significantly from this. Of course edisp and arf are close to spectra ( with the observable being an "effective area" or a probability. But it's more difficult for matrices such as rmf (two different "energy" axes ?) or psf (delocalised)

IVOA should accept statistical results, because the analysis are progressing well. Do you think that IVOA should not be able to disseminate statistical results on the Hubble constant measurement? or a statistical result on a fitted source position? I think that there is no doubt that we want all that... So, probability distribution functions should be properly defined, and then products like edisp or a psf will naturally enter in this category.

I think these are linked to an observation of the sky. (event list or whatever). So is that necessary to describe them in Obscore at the same level ? Again to go back to the origina characterization (see my previous answer to ian) these statistical responses match the concept of level 4 characterisation (which is functional). In the use cases section I have not seen anything showing that you want to discover response function independently from an observation of the sky. So either we access them through Datalink or we describe them in a TAP table with specific characterisation items (different form the observation) and are able to join that with the ObsCore table using the obs_publisher_did.