ObsCore v1.1: Proposed Recommendation: Request for Comments | |||||||||||||||||||
Changed: | |||||||||||||||||||
< < | This page contains public discussion of the Obscore 1.1 Proposed Recommendation. | ||||||||||||||||||
> > | Errata page ObscoreErrata | ||||||||||||||||||
Changed: | |||||||||||||||||||
< < | Latest version: Proposed Recommendation ObsCore 1.1- new release Oct 12 | ||||||||||||||||||
> > | This page contains former public discussion of the Obscore 1.1 Proposed Recommendation. | ||||||||||||||||||
Added: | |||||||||||||||||||
> > | Latest version for the specification : http://www.ivoa.net/documents/ObsCore/20170509/REC-ObsCore-v1.1-20170509.pdf | ||||||||||||||||||
In order for you to easily check the differences add-ons/changes from previous version , a colored version is provided here
Reference Interoperable ImplementationsTwo ObsTAP services are currently serving ObsTAP 1.1.
ValidatorsSTILTS taplint can validate ObsCore. A version that can validate ObsCore 1.1 is available at ftp://andromeda.star.bris.ac.uk/pub/star/stilts/pre/stilts.jar. Run java -jar stilts.jar taplint tapurl=http://... and look at the results of the OBS stage (you can minimally use stages='CAP TMS OBS' if you don't care about the rest of the validation). (Taplint updated for PR-ObsCore-20160923 -- MarkTaylor - 2016-09-29) Note: At time of writing (18 Apr 2016) the reference implementations listed above do not pass this validation. -- MarkTaylor - 2016-04-18 http://xcatdb.unistra.fr/3xmdr5/tap has been updated to pass the Taplint validation. -- LaurentMichel - 2016-04-27 The CADC implementation has been updated but still has two errors from taplint: 1. s_region has no listed unit; in my opinion this is correct since the VOTable field for this is currently datatype="char" arraysize="*" and units are not appropriate. I think this was a bug in ObsCore-1.0 and ObsCore-1.1 should be fixed to be more careful with s_region. It also has to be more carefully written to permit use of new ADQL xtypes (polygon) which would have a different datatype and units. As an involved party I will submit some new text to the editor. 2. dataproduct_type "catalog" is in use pending a decision on what new value should be added to the list. There are also some warnings about other things the CADC TAP service does that are not ObsCore specific. -- PatrickDowler - 2016-05-18Comments from the IVOA Community during RFC period: 01 April 2016 - 15 May 2016In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.Comments from MarkTaylorThere is a problem with the registration of ObsCore 1.1 services. Section 5 of the PR says this:Since ObsCore-1.1 is a superset of 1.0, TAP services that support ObsCore-1.1 also support ObsCore-1.0 and should include both 'dataModel' elements, e.g.:But since some of the field metadata has been changed between ObsCore 1.0 and 1.1 (by my count: 8 mandatory field Utypes, 1 mandatory field UCD and 8 optional field Utypes), ObsCore 1.1 is not a superset of ObsCore 1.0. Any service attempting to implement both will have to choose which version of the UCDs and Utypes to use (e.g. is the Utype for dataproduct_type "obscore:Obs.dataProductType" or "obscore:ObsDataset.dataProductType"?), it can't comply with both simultaneously. This anomaly has to be resolved in some way in the text. -- Anser by editor This is correct. The text has been changed accordingly and will not allow the two data models tags. ---- MireilleLouys - 2016-06-02 Also some minor comments on the detail:<dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.0">ObsCore-1.0</dataModel> <dataModel ivo-id="ivo://ivoa.net/std/ObsCore/v1.1">ObsCore-1.1</dataModel>
Comments from PatrickDowlerThe CADC implementation of ObsCore-1.1 (referenced above) makes use of a non-standard dataproduct_type value: catalog. I would like to see this value added to the list of allowed values. -- PatrickDowler - 2016-04-15 See author response below -- LaurentMichel - 2016-04-27Comments from JamesDempseyThe CASDA implementation of ObsCore v1.0 includes catalogue data products - the ASKAP processing pipeline will produce one or more catalog files for each image/cube. These currently have a blank dataproduct_type in accordance with the ObsCore spec. We have had numerous questions about this omission in our workshops as there is an expectation that they should have a type value. Thus we would like to see a 'catalog' value added to the allowed types. -- JamesDempsey - 2016-04-15 We replied to this issue on the mailing list. In conclusion, the catalogue in a broad sense can also be an agregation of tables or a compilation of multiple source lists. On the contrary a source list is well identified as a list of sources detected in one observation that fits better your use case. Thus we propose to add sourcelist as a new dataproduct_type. -- LaurentMichel - 2016-04-27 A new dataproduct _type has been added for "analysis data product" and should cover this use-case . Updated in last PR document -- MireilleLouys - 2016-08-26 we finally opted for dataproduct_type='measurements' to cover the case of extraction sources related to another dataset described in Obscore. the general case for catalogs was not planned and is not covered for this specification. -- MireilleLouys - 2016-09-23Comments from TomMcGlynnThese comments are mostly on the understandability of the standard. So this isn't particularly associated with 1.1 versus 1.0 and I doubt that you will wish to address these comments in this version but hope it might have some effect on future versions. These are from my personal perspective of looking at the need to implement this standard in the future and trying to see if I can understand what it implies. If I were (and I will be) trying to implement the protocol, then it takes a while to understand where the pieces of this standard that matter are located. Sections 1 and 2 are the usual filler and can be easily ignored. I think that what I really care about in 3.2, 3.3, 4 and appendix C and these are pretty clear. Part 5 is needed for entry into the registry and I find it confusing, but that's par for the course. I remain deeply baffled by section 3.1. I think it does a brilliant job of obfuscating a simple standard. I remain similarly unclear of what the role Appendix B is. If you want to note that there is something more complex on which this standard is based, do it by reference please rather than importing the complexity into this document. Section 3.1 is the UML description for the model, a requirement for the IVOA data models standards. Details on the way parts of a datamodel are re-used need to be explained carefully. Section 4 describes the TAP implementation of the mandatory data model fields only. Section B describes all data model items including optional ones and provides some usage context and examples. This B Appendix can be considered as a Glossary for all data model items. -- MireilleLouys - 2016-07-09 I would suggest that section 6 be retained at most as an appendix. Agreed, changed -- MireilleLouys - 2016-07-09 Appendix C should be included in the normative text. Appendix A seems fine (though I don't know why it sometimes gives ADQL translations and sometimes not). On a slightly more substantive note, I am not clear what role UCDs play? Since we specify column names and utypes for all columns are UCDs given simply for completeness or do they play some actual role in the way users interact with this table? I.e., what breaks if we were to omit or change a UCD for one of these columns? -- TomMcGlynn - 2016-05-10Late Comments from FrancoisBonnarelHere are some comments and suggestions for typos correction and the like ...
Comments from TCG member during the TCG Review Period: Extended to 18 November 2016WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Matthew Graham, Pat Dowler)Approved. -- PatrickDowler - 2016-11-30Applications Working Group ( _Pierre Fernique, Tom Donaldson )I approve of this document. -- PierreFernique - 2016-12-02Data Access Layer Working Group ( François Bonnarel, Marco Molinaro )Valid and useful for DAL WG. I definitely think that the elements number along each axis and the tackling of velocity cubes is a real progress compared with 1.0 from the DAL perspective (ObsTAP and SIAV2.0 dealing with data cubes), as well as some cleaning in the Relationship to DatasetMetadata and Cube data model. -- FrancoisBonnarel 2016-06-01Data Model Working Group ( _Mark Cresitello Dittmar, Laurent Michel )Approved -- LaurentMichel - 2016-12-06Grid & Web Services Working Group ( Brian Major, Giuliano Taffoni )I approve of this document. -- BrianMajor - 2016-11-21Registry Working Group ( _Markus Demleitner, Theresa Dower )I approve of the Oct 12, 2016 version of the ObsCore 1.1 document. Prior concerns have been addressed and the registry dataModel change is good. -- TheresaDower - 2016-10-12Semantics Working Group ( _Mireille Louys, Alberto Accomazzi )The working group chair and vice-chair approve this document. -- AlbertoAccomazzi - 2016-12-01Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Françoise Genova )Knowledge Discovery in Databases Interest Group ( Kai Lars Polsterer )Theory Interest Group ( _Franck Le Petit )<!--* Set ALLOWTOPICRENAME = TWikiAdminGroup -->
|