(r14) ObsCoreRFC < IVOA

IVOA Web>IvoaDataModel>ObsDMCoreComponents>ObsCoreRFC (revision 14) (raw view)~~EditAttach~~
---+ Observation Data model Core Components and !ObsTAP implementation:  

   + Request for Comments

This wiki page document will act as RFC center for the 
Proposed Recommendation entitled " *Observation Data Model Core Components and its Implementation in the Table Access Protocol, version 1.0* ". 
 
The specification can be found below as attached files and on the IVOA Document page:
http://www.ivoa.net/Documents/index.html

   + Review period:  03 May 2011 to %RED%03 June 2011*%ENDCOLOR% %BR% 

In 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 <nop>WikiName so 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.

Additional discussion about any of the comments or responses can be conducted on the Data Model and Dal mailing list.
  However, please be sure to enter your initial comments here for full consideration in any future revisions of this document.

---+ Comments
An Implementation Note is currently in preparation to list and illustrate how an !ObsTAP service can be set up based on the current !ObsCore/TAP specification described in this proposed specification .

-- IVOA.MireilleLouys - 04 May 2011

Thank for adding your comments below... 

-----------

(1) In Figure 1, shouldn't SimpleDALRegExt rather be TAPRegExt?

(2) For Section 5, I'd suggest the following wording:
<blockquote>
  The standard URI of !ObsCore is ivo://ivoa.net/std/ObsCore-1.0.  Thus,
  to declare that a TAP service implements the !ObsCore model, include

  <verbatim>
  <dataModel ivo-id="ivo://ivoa.net/std/ObsCore-1.0">ObsCore 1.0</dataModel>
  </verbatim>

  in the service's capabilities element as included in the registry
  record and available on the service's capabilities endpoint.  The
  details are discussed in [TAPRegExt].

  To accommodate naive user queries, it is recommended that TAP services
  implementing the !ObsCore model give ``ObsCore'' as a subject in the
  registry record.  
</blockquote>

Rationale: TAP services must be registered anyway (so "should be registered" is in conflict with the TAP REC).  The !ObsCore "keyword" is a nice and lightweight idea, but in registry language "keyword" is "subject".  

(3) For Section 6 -- in case it matters for the note, I have !ObsCore support in my data center software [[http://soft.g-vo.org/dachs][DaCHS]], and it's live on http://dc.g-vo.org/tap.  For the record, I think reference implementations (and, if at all possible, validators) should be part of the REC rather than being deferred to a note.

-- IVOA.MarkusDemleitner - 06 May 2011

----------------------------------------------------------------------
Comment: Please make the pol_states keyword mandatory

Reason: There are four types of information an electro-magnetic wave can
be described with but only three of them are mapped into !ObsCore. Section B.6.6. already describes how polarization can be mapped in detail. In my opinion this information should be mandatory to 
   (1) make the description of the measurements complete and to 
   (2) render all !ObsTAP services symmetric.

It is important to note, that this request will *not* put any additional burden on service providers of standard imaging or spectral products as for these the pol_states value will always be constant: "I". In any reference implementation this could be the default value resulting thus in no additional work whatsoever for these providers.

-- FelixStoehr 2011, May 23

%BLUE%----------------------------------------------------------------------%ENDCOLOR%

--Response MireilleLouys 2011,May 30

Whether a data set contains or nor polarised data is expressed in the mandatory field : _o_ucd_ .
If this string field contains 'polarization' then we know polarised data is present.
If not , then it is not necessary to consider this data set in a search for polarised data.
By this way , we think we use less metadata to describe observations recording one type of flux .
_pol_states_ is useful in the specific use-cases where we search which kind of polarisation is present after _o_ucd_ has been checked.



----------------------------------------------------------------------
Comment: typos and clarification on cresolution

1) table 6 typos: for em_min and em_max utypes I assume the last terms
should be LoLim,HiLim, not LoLlim and HiLlim.

2) The s_resolution is listed as
Char.SpatialAxis.Resolution.refval.cresolution
What does the "cresolution" refer to?  Also the
resolving power is Char.Spectralaxis.Resolution.resolpower.refval.
Should it be refval.resolpower to be consistent?

-- Randy Thompson 2011, Jun 02

----------------------------------------------------------------------
A lot of typos found:
I am referring to pdf version so some objections given below may be valid only for this - but it has to be chcekd anyway


1. Introduction last sentence - the global data discoverability and accessibility is in very strange hand-written font. Similar but different font in Section 2, 2nd sentence

4.12 4th paragraph 1st sentence - redundant "the" in "of the observed the region"

Sec.5 at the end [REF] - probably the reference is expected 

Sec. 6. - comment [add url] twice - should be filled. The question mark to be removed.

Appendix A.1.2 Use case 1.2
What does it mean LIST=SERVICE REQ and AND=SERVREQ 
Explanation needed.

In addition in use case III - bad range 5000-9000 (missing zero)

A.1.3 in listing:

3rd line - AND s_resolution< 0.3 (missing underscore)

A.1.4. 
III  Spatial Resolution < 0.7 arcseconds   (double dot instead of period 0:7)
A1.5 
III - again strange comment SERVIC REQ + NEEDS ANOTHER SERVICE (CATALOGUE)  and missing right parenthesis 

A1.6. 
LIST=SERVREQ

and in last line - is the absolute value really called by vertical line in TAP query ?

A.2.3

SERVICEREQ+NEEDS ANOTHER SERVICE

A.3.3 listing 
AND t_exptime> 3600 ?    (redundant question mark)

A.5.2  listing last line
s_region (missing underscore)

A.6.2  sentence For the quasars, give me high resolution (<0.5") 
the double dot in 0:5

In general - in appendix the capitalizaed comments like SERVICE REQ are cryptic and inconsistently written (although I understand they were copied from some notes - however document like ObsCore should be 
precise even here ... (the missing underscores may confuse people i f they try to call service using the cut and paste (in the future).

B.2.1 in sentence "So the users could be warned"
(it is only "be warn")

B.4.1  The last sentence begins in different font (The same dataset - it is smaller - is it an intention ?

B.4.4 - defines rights "proprietary"  but in B4.5 last sentence
An observation with a NULL value in the releaseDate attribute is private by definition.

Is it meant the "proprietary" as a reference to B.4.4 rights ??

B.6.1.1. last sentence   strange reference to STC 
verbosely "CITATION STC \I 1036" - probably some remnant of citation tool


B.6.2 last sentence - again strange citation remnant

B.6.2.3.  after the case a)
(FWHM of the LSF) -- is it the Line Spread Function ? (probably not so commonly known abbreviation to anybody ...) 

after case b)
 ... resolution power stored as   - there is period power.stored

after case c) 
Char.spectralAxis.Resolution.resolPower LoLim
seems to be the white space before .LoLim

B.6.3.1
strange reference

B.6.5.1 
... more complex combinations such as:
phot.flux.density;phys.polarization.stokes.I 

is it correct  the stokes.I ? (or Stokes.I ?)

last sentence
should be probably parentheses (See examples in the table) 

B.6.5.2
strange citation

B6.6.

2nd paragraph  
phot.flux.density;phys.polarisation.Stokes.I   (written Stockes) and missing period - is it OK ?


Tables 6 and 7:
What does mean principal, Index and Std ?
The index TBD - or zero - - what is a meaning of it?
and what sometimes there are question mark ? It is a standard and everything should be clear to the reader ;-)

In addition to the typos and clarification needed:
There is a lot of places referring to SDM or SSAP in obsolete versions.
I suppose the SSA 1.0 et least (or 1.1.) should be referred to 
(in 3.3, B.4.3, B.5, B.6.5.2, ) and SDM probably the 1.1
(in 3., B.3.7, B.6.2, )

One inconsistency in table 5:

there is no the em_calib_status in the table, but in B.6.2.1 it is defined. as calibrated,uncalibrated,relative and normalized.

I think it should be the level of wavelength calibration (not flux)
so the usage of "normalized" is questionable  (in SSA we have normalized only for fluxcalib).

However, I think, the introduction of observable axis o_calib_status in B.6.5.2 is the correct place but it is {absolute,relative,normalized, any}

it is referred to SSA (but in SDM is "uncalibrated" instead of "any"

I am confused about this - is it a inconsistency between SDM, SSA and CharDM or I do not recognize something important?




-- PetrSkoda 2011, Jun 03

<br/>
<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
docx	PR-ObsCore-v1.0-20110502.docx	r1	manage	323.5 K	2011-05-03 - 10:49	MireilleLouys	ObscoreDM Proposed recommendation
pdf	PR-ObsCore-v1.0-20110502.pdf	r1	manage	1886.5 K	2011-05-03 - 10:50	MireilleLouys	ObscoreDM Proposed recommendation (pdf)
Topic revision: r14 - 2011-06-03 - PetrSkoda
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema