comments on the ObsTAP-2011-02-27 draft

[Igor Chilingarian]

Hi all,

I decided finally to put my comments on the draft on the mailing list instead 
of discussing them privately among the authors. If there is any volunteer to 
put them on the Twiki page, please do it.

These apply to the 2011-02-27 version of the draft. They were made on Mar/1, 
and Mireille has already taken into account cosmetic changes in the document 
(typos etc.) So, here I will list more serious points and will omit all those 
ubiquitous typos (hundreds!!!) in the examples originated from the usage of MS 
Word with the "auto-replace" feature turned on by one of the authors.


Page 14. Section 3.2, paragraph 2 (or table caption -- unclear?)
add "in some cases" after "though it could be nillable"

Page 14. Table 1 
Among all the listed columns, there is only one which must be unique, it is 
"obs_publisher_did". So, I would recommend to highlight it somehow in the 
table and mention that it can serve as a primary key.

Personally, I'm not happy with some column names, in particular with the fact 
that "spatial" starts with s_, the same letter as "spectral". I know that this 
has been discussed for years and some of us are already used to these column 
names, but still I would suggest to use the top-level UCD in column names 
instead of a single character, like it is done for the spectral axis ("em").
I mean: "pos_ra" "pos_dec", ...; "time_min", "time_max".

All Section 3.3. I think we should explicitly mention whether it is mandatory 
to fill every given DM element (i.e. if it is "nillable" in the 
SQL-serialization). Although this information is provided below, I think it 
would be important to mention this in every 3.3.x section.

Page 15. Section 3.3.1 What data product type will be appropriate to describe 
multi-object spectroscopy? Presently, a large fraction of all spectra provided 
by modern facilities come as multi-object (or multi-slit). Well, when the 
calib_level=2, normally one would expect the spectra to be extracted from the 
dataset and published one-by-one, then the "spectrum" is fine (we have to 
think what Observation ID to attach). But in case of lower calib_level values, 
the reduced spectra obtained during the same exposure are often presented in 
some specific formats (e.g. Euro3D, ESO FLAMES) just like "all in one". I 
would definitely disagree to call it "other". Juan De is proposing to use a 
fine-grained data product type, but this we have to discuss in more detail

Page 17. Section 3.3.3, par.2
We should again mention that only obs_publisher_did is unique.

Page 18. Section 3.3.4, par.1
"A spectrum could be represented in the VO-compliant Spectrum format or in 
some instrument-specific FITS binary table format".
"FITS binary table" should be dropped. Because this way we reject all the 
spectra in the "standard" IRAF-reduced format, i.e. 1D-image; we 
possibly reject Euro3D, and other instrument-specific file types (ESO FLAMES)

Page 21. Section 4.5.
We should *highlight* that DID is unique and say explicitly that it should be 
used as a primary key.

Page 21. Section 4.6.
The last paragraph (Access URLs...) is too vague. It doesn't bring any 
useful information, only frightens developers. Has to be clarified.

Page 21. Section 4.8.
How to put "unknown" access_estsize? As NULL? Has to be specified

Page 23. Section 4.15
The statement that "In all cases, t_exptime is generally used as an indicator 
of the relative sensitivity (depth) within a single data collection" is not 
true. In case of multiple targeted observations (e.g. a survey of stars of 
certain types) the exposure time is usually selected on the case-by-case basis 
in order to achieve more or less the same signal-to-noise ratios for every 
target of interest.

Page 23. Section 4.16
"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



Page 29. Use case 1.6
I have serious doubts that this query will work. "|" should be replaced with 
"abs", but "abs" does not exist for the "timestamp" datatype (although MJD 
can be treated as "double precision". This is an example to discuss and check.

Pages 37-38. Section B1.2. Calibration level.
The first paragraph states about "80%" of data collections, while the last one 
is more optimistic saying "simple enough to cover all regimes".

Page 39. Section B3.3.
"HI cube" or "CO cube" is not a title, it's more a data type. The title would 
be something like "NGC224 HI cube 01"

Page 41. Section B5.2
Some examples are quite bad, in particular, "VOTable". I think we should be 
more explicit about this. MIME types should be indicated as preferred, then 
VOTable will become text/xml or whatever like this.

Page 45. Section B7.1
Example is needed. What about "Telescope" or "Facility"? To me it looks quite 
strange if we give the instrument name, but do not identify the telescope it 
is operated at.

Page 47. Table 6.
Identify obs_publisher_did as a primary key, highlight all mandatory elements 
(by colour??)

Page 51. Section C.2
My suggestion would be to put the *tested and working* bunch of SQL scripts in 
order to create and fill the database schema. This will facilitate the life of 
people implementing the service. I believe, Mireille has already put this 
point on the Twiki somewhere.


With best regards,
 						Igor