+Discussion on the IVOA WD on ObsTAP and the ObsCore data model

  • List of current releases during the WG review

    • release v1.0-20110228:
docx pdf Current draft with pointers to topics to discuss

The authors could not agree on some important points; others were still being worked on at the time the current draft of the specification was released. It was therefore decided to post them on the twiki (see pages below) for an open discussion. We need to finalize these soon and we ask for your help. Please find below the list of topics with indicated the two different perspectives among the co-authors.

Please provide your comments not in this page, but in each of the topic pages listed below:

  1. dataproduct_type: 'other' and subtype. Click here for the discussion page
    • Option 1.A: dataproduct_type should allow 7 well-defined types (see list below) plus 'other' to allow extensibility, with an additional and optional subtype to let the data provider specify what that is (subtype should be free format):
      • image
      • spectrum
      • cube
      • sed
      • event
      • timeseries
      • visibility
      • other
    • Option 1.B: It shall contain the first 7 types, but shall not contain 'other' nor a free format subtype because (1) this was not part of the requirements for ObsTAP (not a single use case covered this) (2) 'other' -along with a free format subtype- would open up the possibility for data providers to come up with their own schemas, therefore defeating the main idea of ObsTAP, that is, the possibility to send one-and-the-same-query to all obstap services. 'other' would correspond to different types in different archive implementations. If other types are needed we could amend the document and extend this list without breaking existing services.
  2. Best UTYPE string-format: for humans (camelCase), for DB systems (lowercase) Click here for the discussion page
    • Option 2.A: UTYPEs shall be treated as case-insensitive strings, favouring camelCase for readibility
    • Option 2.B: UTYPEs shall be lowercase to avoid confusion, to avoid extra code to handle all possible cases in clients, DBMSes, etc.. A case-insensitive string cannot be searched efficiently in all DBMSes. E.g. the clause WHERE LOWER(utype)='abc.def' forces a table scan (no index can generally be used).
  3. obs_title data model field: free format? Click here for the discussion page
    • Option 3.A: obs_title shall be a mandatory field, a free format string that allows data providers to describe any given dataset in more details than otherwise possible, e.g.:
      • dataproduct_type='cube'
      • obs_title='HI  cube'
    • Option 3.B: Not clear what the requirements are, and a completely free format field could be an issue. There is no time now to study this. Let's leave it optional until we clarify requirements and usage.
  4. access_format Click here for the discussion page
  5. Usage of obs_publisher_did Click here for the discussion page

and feel free to add a new item when needed. Thanks.


Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdocx WD-ObsCore-v1.0-20110228-1pdf.docx r1 manage 348.2 K 2011-02-28 - 20:28 MireilleLouys ObsTAP draft current version
PDFpdf WD-ObsCore-v1.0-20110228-1pdf.pdf r1 manage 1716.2 K 2011-02-28 - 20:29 MireilleLouys pdf version
Edit | Attach | Watch | Print version | History: r21 | r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2011-03-03 - DougTody
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback