*ObsCore extension  for radio data 
Present: Francois Bonnarel, Mark Kettenis, Marco Molinaro, JJ Kavelaars, Mireille Louys, Mathieu Servillat, Mark Lacy, Allessandra Zanichelli, Vicenzo, Mattia Manchini, James Dempsey, Catherine Boisson, Laurent Michel, Peter Teuben, Alberto Micol

github : https://github.com/ivoa-std/ObsCoreExtensionForRadioData/
ivoa working draft : https://ivoa.net/documents/ObsCoreExtensionForRadioData/20230512/index.html
IVOA Radio IG discussion page : https://wiki.ivoa.net/twiki/bin/view/IVOA/ObsCoreExtensionForRadioData

Except for some very recent comments, github issues and Radio IG discussion page should be in sync

Bonnarel: Goal is to define an obscore extension for radio data. Main recent change is extension from visibility data to other types of radio data.

 The dataproduct_type is not sufficient for (especially) single dish data; discussions about extending vocabulary in semantics WG.

Points to discuss :

dataproduct_type  : new terms to discuss (see Alessandra/Vincenzo proposal : https://docs.google.com/document/d/1AMfjagQn84GhJ7dGkNmoMP350pQnsbXn27LFwV-pO3k/edit#heading=h.hw7krw7egv4e)
       new terms : spatial_profile, map (issue : is map different from image ?)
       question for cube : is that OK for "on-the-fly cross scan spectral" result
       question for measurements : is taht only for ON total power and ON OFF total power ?
       new dataproduct_type vocabulary proposal : https://www.ivoa.net/rdf/product-type/2023-06-26/product-type.html
(sky_)scan_mode : see figure 1 in the draft and  Alessandra/Vincenzo proposal)

Bonnarel: Main question is whether some of the single dish data types require new product types. For example "image" is defined very general and could cover map.
Alessandra: Standard slit spectrum in optical is fixed on a fixed position on the sky; cross scan spectral is sigificantly different.
Bonnarel: we can discuss here, but decisions will probably be taken in semantics WG. Unfortunately Baptiste can't attend the meeting.
JJ: We don't use slit-spectrum, just describe spatial and spectral axes separately.
Bonnarel: slit-spectrum is not a cube since only one spatial dimenstion.

Bonnarel: (sky_)_scan_mode
Allessandra: Single or different attributes for spectral and spatial scanning strategy?
Bonnarel: Can one term cover both? More efficient.
Allessandra: That would be ok.
Bonnarel: Also important for high-energy observations
Dempsey: Drift scans with parkes and will want to identify them as a different type to other visibilities/raw data
(Kettenis: I'm a bit lost, not an expert on the subtleties here)

Alessandra: as for scan_mode, if one parameter is used for both spatial and frequency scanning we have to find suitable values to express their possible combination in one observation. For instance: one observation can be performed with frequency switching AND on the-fly-spatial scanning.


instrument type + mode ? interferometer, single dish, beam forming, etc ...

Kettenis: interferometer vs. single dish can be inferred from dataproduct_type?
Dempsey: image could come from both
Bonnarel: also cubes; agree with Dempsey

tracking mode ? 
     discussed in the context of High energy data discovery.
     slew, drift, pointed ?
     Is that useful for radio astronomy ?

s_region (support) modification  or addition of multi axis support --->
expressed by  moc, stmoc, ste-moc beside stc-s 

Bonnarel: Cannot remove stc-s but could add MOC as special x-type
Or add a new multi-axis support column that would contain stmoc or ste-moc.
Can already have stmoc., not yet ste-moc.

Michel: How to handle different MOCs?
Bonnarel: Recognize from ASCIII representation?
Kettenis: This would not really be radio-specific; would have to be handled in obscore itself.
Bonnarel: Agree, but it it is not clear when ObsCore will be updated.

Louys: Multi-axis support would have to be done in a new column; not in s_region.

Micol: MOC discussion should probably be done outside radio extension since it is more general.

f_min / f_max : 
    new stored attributes or UDF instead ?
    --> issue of response
    --> issue of parameter based interface (SIA/DAP)

Bonnarel: Argument for UDF is the fear that there will be inconsistencies.
Lacy: If data providers provide f_min/f_max there should be no issues with units.
Kettenis: But there should be no issue.
Kettenis: Not in favour of duplicating information, but are UDFs user-friendly enough?
Dempsey: UDF should work.
Bonnarel: Do we need to define column names?
Kettenis: The real issue with spectral resolution, where a fixed spectral resolution in wavelength is variable in frequency....
Bonnarel: Is resolving power used in Radio?
Allessandro, Micol: Not aware; not widely used at least.

Bonnarel: If we have f_min/f_max we could also have f_resolution.

s_fov, s_fov_min, s_fov_max,
    s_fov : mid value ? typical value ? choice by dataprovider ?
s_resolution, s_resolution_min, s_resolution_max :
   s_resolution : mid value ? typical value ?

Bonnarel: Values can vary significantly.
Kettenis: Correlation parameters also affect s_fov; doesn't really affect the discussion about _min/_max.
Allessandra: Raw data lamba/D; more advanced data products it is more subtle and mid/typical value may make more sense.
Bonnarel: So the description needs to be rephrased.

o_ucd  for raw ADU ?
    is there an UCD VEP for that ?

Bonnare: Is there actually a VEP for UCD.
Louys: Discussion about voltage data, but no VEP. Not really certain if it is possible to have an UCD for a generic concept. Discussion ongoing.
Micol: Would be useful to have an UCD for the concept.
Bonnarel: Work for the UCD/semantics group.

uv_distance_min, uv_distance_max
    issue of estimation , absolute ? some  percentile of distribution ?

Bonnarel: Introduced because were looking at first note writen by Anita Richards in ~2010.
Kettenis: Think this needs a prototype implementation and let users see if these are really useful for selecting observations.
Micol: We can characterize many things; but is it useful? When starting obscore we looked at "queries" used by astronomers to understand what is really needed. The extension of this model should use the same methodoligy; define use cases and describe them in terms of extension parameters.
Bonnarel: We started from use cases.
Micol: But we should ask what the queries are what the scientists want to do.
Kavelaars: ALMA already implented UV-coverage with percentiles; based on feedback from ALMA science committe? Are those used (based on the stats they collect)?
Vincenzo: Angular scales are important. But users may be more interested in distribution for imaging. But users don't necessary do imaging but also modelling.
Micol: But having user queries really helped focus on the details.
Allesandra: We didn't write down the use cases in the document; we probably should do that.
Bonnarel: We have to create appendix with use cases.

uv_distributiion_ecc
uv_distribution_fill
estimation  as in the draft.
global or by spectral channel ?

See above.

coverage maps, dirty beam : (actually links (URL° to these data): 
    do we need ObsCore fields (with standard name/utype) 
    or is DataLink (with semantics, content_type, local_semantics, content_qualifier enough ?)

Bonnarel: content_qualifier describes the content as a dataproduct_type. Beam maps and UV coverage are not covered. local_semantics are not a (closed) vocabulary. If we add obscore extension column we can define what it contains. DataLink needs more work.
Kavelaars: These are all different manifestations of the same observation. With DataLink observatories can provide whatever they want.
Bonnarel: Several comments that DataLink would be enough.
Kavelaars: Do users want to select that on whether there is a coverage map available for it?
Bonnarel: Probably use DataLink for this.


Is the extension a set of new attributes in the same table or a secondary table
     consequences ?

Bonnarel: Pat was in favour of single table. Other people have suggested separate table with some sort of natural join. Can't remember why Pat was in favour in a single table.
Kavelaar: What is the benefit of second table.
Molinaro: Adding additional columns on the table increases the column numbers which may make queries a lot more expensive if only small number of observations provide the extra radio parameters.
Kavelaars: Really a technical interface.
Molinaro: Other issue is the field on which to do the join.


How to declare the service with the extension in the registry : 
    MODEL element as for basic ObsCore ? 
    or utype on the table  

Bonnarel: New way of doing things is utype on tables, but ObsCore doesn't do it this way.
Molinaro: ObsLocTAP has utype on the table as well.
Bonnarel: Can't have two utypes on the table.

Bonnarel: Reviewed PR from Allessandra and Vicenzo. Please adjust PR according to my comments.