Obstap / fixed
Francois Bonnarel
francois.bonnarel at astro.unistra.fr
Wed Mar 16 01:39:50 PDT 2011
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
---------------------------------------------------------------------
More information about the dal
mailing list