ivoa-std / ObsCoreExtensionForRadioData

ObsCore model extension for radio data
Creative Commons Attribution Share Alike 4.0 International
0 stars 6 forks source link

Comments on other ObsCore parameters : Facility_name and instrument (from Alessandra, Vincenzo and Marco) #10

Open Bonnarel opened 1 year ago

Bonnarel commented 1 year ago

From Alessandra Zanichelli, Vincenzo Galluzi and Marco Molinaro

Comments on other ObsCore parameters We collected two examples of ObsCore fields whose interpretation appears to be different from the original IVOA prescriptions. Facility_name and instrument These parameters in our view should have the same meaning irrespectively if they are referred to space- atmosphere- or ground-based instrumentation. Typically a spacecraft hosts a number of different instruments similarly to what happens with ground-based telescopes. The same applies to modern balloon-borne experiments. Facilities like the ISS can be seen as equivalent to ground-based Observatories in the sense that they host different telescopes/experiments. We propose that facility_name identifies the (observatory + telescope) hosting the instrument used to acquire the dataset, while instrument describes the acquisition system used among all those available on that telescope. For instance: facility_name=ESO-VISTA, instrument=VIRCAM For the radio domain, generally speaking an instrument would be composed by a number of tokens, e.g. specific filters between the frontend and the backend, the frontend and backend themselves, as well as the beamformer/correlator used.

For single dish data we are currently describing the acquisition system with the combination frontend+backend.

Bonnarel commented 1 year ago

From Alessandra Zanichelli, Vincenzo Galluzi and Marco Molinaro

Comments on other ObsCore parameters We collected two examples of ObsCore fields whose interpretation appears to be different from the original IVOA prescriptions. Facility_name and instrument These parameters in our view should have the same meaning irrespectively if they are referred to space- atmosphere- or ground-based instrumentation. Typically a spacecraft hosts a number of different instruments similarly to what happens with ground-based telescopes. The same applies to modern balloon-borne experiments. Facilities like the ISS can be seen as equivalent to ground-based Observatories in the sense that they host different telescopes/experiments. We propose that facility_name identifies the (observatory + telescope) hosting the instrument used to acquire the dataset, while instrument describes the acquisition system used among all those available on that telescope. For instance: facility_name=ESO-VISTA, instrument=VIRCAM For the radio domain, generally speaking an instrument would be composed by a number of tokens, e.g. specific filters between the frontend and the backend, the frontend and backend themselves, as well as the beamformer/correlator used.

For single dish data we are currently describing the acquisition system with the combination frontend+backend.

From François Bonnarel :

I think we have to follow what you recommend here;

Bonnarel commented 4 months ago

Your definition of facility and instrument resusing frontend and backend sounds good. We need to add this interpretation of these two ObsCore attributes in section 3.