Services supporting the ObsCore model should advertize this fact usingI don't feel strongly about either standardID or ivo-id. If you have strong feelings either way, please vent them over at TAPRegExt. The same goes for the element content (which is supposed to be a freetext label possibly for human consumption). -- MarkusDemleitner - 11 Mar 2011 + Some proposals of changes in the document (by Igor Chilingarian 2011/03/08) 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 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. Igor + Points discussed by A.Richards 2011/03/09 Here are some comments - mostly minor: 4.4 Unique identifier - does this mean unique within the Collection Name? I am not sure that a combination of real observations is a 'software' observation - I would reserve that term for simulated or model data. Back to real combinations, surely it is up to the provide whether it gets a new ID, but if the purpose of the ID is to allow tracing the observational history this seems counter-productive. Omit this para? 4.6 Does 'data product' include metadata-only responses, e.g. when the product is very large and the user should be warned or the data need staging or user registration at a web form or whatever? (the Introduction does mention 'retrieving or otherwise accessing') 4.12 ICRs only - see my first comment about the need to allow for SOlar System sources. Thanks very much Anita -- DougTody > I am not sure that a combination of real observations is a 'software' observation - I would reserve that term for simulated or model data. Back to real combinations, surely it is up to the provide whether it gets a new ID, but if the purpose of the ID is to allow tracing the observational history this seems counter-productive. Omit this para?<dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore 1.0</dataModel>as explained in the TAP registry extension document (Demleitner et al, 2011). The point was that we talk about "observation", but a composite of multiple actual observations is a more complex derived product, and we want to describe that here too. Perhaps the wording could be improved; we will revisit it in light of your comments. > 4.6 Does 'data product' include metadata-only responses, e.g. when the product is very large and the user should be warned or the data need staging or user registration at a web form or whatever? (the Introduction does mention 'retrieving or otherwise accessing') 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. ObsTAP describes only "archival" (actual) data products in an archive. These can be directly retrieved as files, but to do anything more complex the typed DAL interfaces must be used. - Doug -- FrancoisBonnarel 15 Mar 2011 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. | ||||||||
Added: | ||||||||
> > | + UCDs for STC limits Table 6 in the 20110305 draft lists utypes and, for em_min and em_max, suggests char.spectralaxis.coverage.bounds.limits.interval.lolim and char.spectralaxis.bounds.limits.interval.hiLim. For compatibility with STC(-X), I'd suggest these should be lolimit and hilimit, respectively. -- MarkusDemleitner - 28 Mar 2011 | |||||||
<--
|