Mark Kettenis, François Bonnarel, Alessandra Zanichelli, Vincenzo Galluzzi, Mark Lacy, Mark Allen, Pat Dowler, Jesus Salgado, Ricardo Rizzo, Renaud Savalle, Mathieu Servillat ... 

* JIVE prototype 

- EVN : European VLBI network, heterogeneaous array
- JIVE : support institute for the EVN / coorelator and EVN data archive

- uv characterization is the most interesting for EVN

    + extraction of uvw coordinates from  FITS-IDI file

    + code uses PCA (Mattia Mancini)

- Spatial Char 
    + s_fov_min, s_fov_max
    + s_resolution_mi, s_resolution_max
    + s_maximum_angular_scale
    + all easy to compute and useful
- Frequency/Time    
    + f_min, f_max , f_resolution provided directly in FITS-IDI files
    + t_exp_min; t_exp_max -> wrong names : resolution ... variation not meaningful

- instrument parameters
    + some cannot be given (heterogenoeus) 
    +  some not useful for VLBI ....
    + Question : Antenna diameter ? -> can still be useful for sensitivity
- VO service    

    + operated with dachs 
    + FITSscrawler from FITS-IDI produces csv file ...
    + obs_radio mixin --> two tables
    + Natural joins ... 

- Interferometry Use cases ...
    + high resolutuion data within one arcsec of an FRB
    + "good" uv coverage charac data with sufficient maximum angular scale around a source
    + question : add usse case to github as PR or issue
- Question : Single spectral channel coordinate uv coverage charac (J.Tobin) ? --> full coverage makes some sense in some contexts ..


* CDS prototype

- Extension added to a clone of  SKA RC network  discovery service.

- Small prototype 15 datasets
- some parameters added in a single "rucio.obscore" table that is combination of obscore + extension

- example; s_resolution < value doesn't give results but s_resolution_min < value does provides results

- similar example for s_fov > value vs s_fov_min > value

- official SRC prototype will not include extension at the moment (Jesus)



* Controversy points

- f_min/f_max controversy; 
    + user-friendly but dangerous because  Duplicates em_min/em_max ? -> udf ?
    + FB: user defined functions only used for TAP (not for SIA/DAP interface)
    + Should we vote ?
    + PD: vote isn't a great solution but neither is running around in circles.
    + PD will check what happened in the past
    + FB: Similar discussion occurs for high-energy for "photon energy"
- registration and how to expose the tables.
    + Separate tables (Markus + ... ) vs. single table (François + ...).  
    + tables identified by standardID set via utype on the table in the registry --> standardIF for the extenSION table or for the extenDED table ?  
    + Combining multiple extensions (time+radio) in the same tables becomes painful.
    + on the other side querying only the extension table makes no sense so why imposing a join to users ?   
    + the issue has Two aspects; queries and discovery of the tables.
    + WHICH utype for extended tables : one ad hoc utype (standardID) per extended table or multiple utypes on the same extended single table
    + PD: if your database is natively  standards compliant the join approach is more normalized and makes sense.
    + But other implementations implement obscore as a view on an existing database and making a complete view would be better.  Joining
    views is going to be cumbersome.  Joining two views that are views on the same underlying table is strange and would require implementers to
    remove the join.
    + in the current draft there are the two versions (single table appears in pdf, two tables is there but commented in latex)
    
- characterization about time ...
    + t_exp_min and t_exp_max are supposed to be sampling
    + In characterisation : sampling period is different than sampling extent
    + t_exp_min/max supposed to be extend (according to epntap)
    + MK+VG : users don't care about min/max only about integration time in the samples (low variability)
    + --> this tends to be converging with time_resolution
    + Go to there unless Baptiste/Nançay objects
- instrumental parameters and observation modes:
    + MK: useful but mostly in the context of a specific instrument.
    + VG: Diameters in the ALMA case to distinguish main array and small dish array.
    + Riccardo : diameter valid  for compact array ?
    + MK : diameter my be useful for sensitivity of the  observation
    + tracking mode, scan mode:
       x FB: ObsLocTAP introduces tracking modes. tracking point is about how we are pointing (sidereal, azimut/elevation, wobble, multi-target, planet follow-up, etc... scan mode is about how we scan the field around the pointing)
       x AZ: only need scan mode.
       x RR: Are we forgetting the scanning mode for continuum camera?
       x FB: will contact Baptiste C for use cases he can have for trackng types.
    + AZ: scan the sky and scan the spectral axis -->  proposal for a vocabulary with a single parameter for both.
       x FB: UCDs work this way, main UCD + additional UCD that clarifies.   
    + important to define use cases for all these intrumental/observation modes