Minutes of the Telecon on "Last comments on the ObscoreDM document"
Monday June 6 :  18:00 European (Paris, Muenchen ), 9:00 (Victoria) 

Participants:
DD:Daniel Durand 			MA: Maria Arevalo 
DT:Doug Tody			IC: Igor Chilingarian
AM: Alberto Michol		PD: Pat Dowler
FB : Francois Bonnarel		ML: Mireille Louys
JS: Jesus Salgado

Few comments on the RFC page.
Rich and long list of comments before RFC on the ObsTAPdiscussion page during the WG discussion. 

Points discussed: 

1 - obs_collection and connections with telescope, instrument names
The name of a data collection is often bounds to telescope name and instrument name.
Examples of multiple-instruments data collections like GOODS
agreed on : 
* free format string 
* A meaningful and discriminative string to be relevant to astronomers.
* keep the name as it is : no collision with other item.
Related topic: 
Facility name and Instrument name to be mandatory  --> all approved.
Change text to have facility_name and  instrument_name as column names.
Allow for future extension of other facility/instrument attributes when the Provenance DM will be developped.
For observations stemming from multiple instruments: allow instrument_name to contain a list of comma separated strings ; if too long use "Many" as defined in the VODataservice specification . 
same for Facility_name.

2 - pol_states mandatory or not
Polarisation data to be distributed by ALMA and radio projects.
If pol_states is not mandatory, many queries with 
o_ucd = "polarisation" and pol_states='Y' could run in error because the pol_states field is not defined.( depends on query compiler)
agreed on : 
* pol_states mandatory 
* can be NULL when not applicable
* contains a list of polarisation states as defined in the FITS paper spec. and in the same order.

3- Examples 
In the use-cases Appendix , some query examples are included.
Some of them fail; still typos to be corrected.
Do we want to keep them in the document or simply point to a web page where the examples could be tried.
agreed: keep only simple queries examples. Enrich the example web page.
action DD: check and suppress some of the examples in Appendix A.

Interest for scripts in adql to define Ivoa.ObsCore tables.
to be added on the example web page (action Pat) 

4- Section 5 : registering an Obstap service
Need to qualify the data model used by a standardised uri.
action Pat: rewrite a paragraph to describe how to register a service using the TAPRegExt specification.

5- Identifiers
Different identifiers mentionned : obs_id, obs_publisher_did, etc...
Do we need creator_did, dataset_id as in the SSA utypes ? 
The text of the draft could be clearer about unicity and persistence of these identifiers.
Should be read again and eventually have small changes.
(action :??Doug? sorry missed this one ) 
Full re-definition of this section postponed to ObsCore 1.1 and waiting for IVOA standard on persistent IDs.

action Mireille: include corrections of typos and changes provided by participants by end of this week (June 10).