Obstap / fixed

[Francois Bonnarel]

My email was apparently unreadable
Hi All,
   I upgraded the wiki page by doing the following
    - adding a topic on use cases with constraints on "radial velocities".
    - integrating emails by Anita, Pat, Doug and Igor, hopefully at the 
right
*place.
    - adding my own answers to different topics:
find below a copy of theses answers:

------------------------------------------------------------------------------------------
On the data product discussion:
------------------------------------------------------

/It is important to distinguish the data product type (spectrum, image, 
etc..) and the format (fits, mef, etc ...).


I think allowing NULL for dataproduct_type solves the "other" issue.
I am also in favor of an optional subtype field which will allow to
specify both the typology of these undiscribed dataproducts as well as 
specifying details such as "multiple" for spectrum or "multi-wavelenght" 
for a data cube. /

----------------------------------------------------
On the Utype discussion:
-------------------------------------------

/I follow all people telling that the query must be case insensitive. 
But if you store the utypes in small letters in the TAP schema what 
about the query RESPONSE ? Wherefrom does the system know the correct 
syntax for further interoperability ?
/

____________________________________________________________
On the obs_title discussion:
-----------------------------------------------

/As far as I understand obs_title is a free text description. Maybe 
usefull but the field name is confusing I think. Nothing to do with an ID./

------------------------------------------------------------
On the access_format discussion :
---------------------------------------------------------

/I think using mime types from start is required and will be very 
usefull. Complements (starting by a dot or whatever) may be defined 
later and keep consistent with previous version (use of wild cards) /

--------------------------------------------------------
On the obs_publisher_did :
---------------------------------------------

/Well I follow Doug there. It could be very usefull to get the whole 
standard description by querying on obs_publisher_did. /

--------------------------------------------------------
On the polarization use case
--------------------------------------------------


/I fully agree with Juan De and Anita there.  But if we don't want this
pol_staes parameter to be mandatory we will convey minimal information 
with the o_ucd field. this one doesn't allow to give the list however, 
only the polarization "style".
/

-------------------------------------------------------------------------
On miscelaneous changes in the document:
------------------------------------------------------------------------

/ I only comment this statement from Igor "For products with no sampling 
along the time axis, the "t_resolution could be set to the exposure 
time." This is inconsistent with the Characterisation DM. I would recall 
on a long discussion during the CharDM  (v.1) development a few years 
ago regarding the "resolution" value in case then a given "axis" 
contains only one point. I tried to argue for putting some resolution 
RefVal (i.e. lambda/dlambda for a broadband filter), but this idea met 
strong objections, in particular by Alberto, so finally we decided to 
put "N/A" or "NULL". I am not sure whether it was a right decision, but 
now we *must comply* to what is already done. In this case, the query to 
discover the time-resolved observations will be: WHERE t_resolution IS 
NOT NULL" /

/ I think we had an inconsistency in version 1.0 of CharDM  there. I 
would be personnally in favor of changing this in version 2.0 for the 
reasons exposed by Igor. /

/ and this one from Anita/Doug: "Does 'data product' include 
metadata-only responses?
ObsTAP  does not address these more complex access use cases. More 
generally, ObsTAP  does not do virtual data. This is reserved to the 
typed interfaces such as SIAV2. " /

/I fully agree. Availability of descriptions consistent with full 
observation data model or Provenance or whatever is only possible via 
the typed DAL interfaces and is a growing up use case./




-- 
=====================================================================
François   Bonnarel           Observatoire Astronomique de Strasbourg
CDS (Centre de données        11, rue de l'Université
astronomiques de Strasbourg)  F--67000 Strasbourg (France)

Tel: +33-(0)3 68 85 24 11     WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 68 85 24 25     E-mail: francois.bonnarel at astro.unistra.fr
---------------------------------------------------------------------