[obs-tap]:updates on the Proposed recommendation + new document

[Patrick Dowler]

On 2011-07-12 06:40:51 Arnold Rots wrote:
> So, which of the three options should I choose for o_stat_error:
> 
> 1. Return "POISSON"
> 2. Return -1 (or some other negative value) that by convention will
>    mean "POISSON"
> 3. Do not return o_stat_error (i.e., don't provide any information on
>    it)

o_stat_err has a data type of double, so option #1 is not legal.

The optional columns are going to provide minimal value to users since, well, 
they are optional and therefore only some sites are going to have them. So 
first of all I would not expect the ObsCore model to satisfy all the detailed 
use cases of Chandra users because that it not the purpose for which it is 
designed. You can and probably should extend the model with site-specific 
columns to make your extra details unambiguously clear to your users. 

Since the utype of this field is:

        Char.ObservableAxis.accuracy.statError.refVal.value

the supposed ambiguity of the meaning of o_stat_err is something to be 
resolved in the CharDM. I would look there, expect to find another field in the 
model that said what kind of statError this was, and add an extra column with 
a utype from CharDM for the type of error. Since ObsCore does not specify it, 
I would make up a column name, but try to stick to the style of ObsCore. Then 
in ObsCore-1.1 maybe it would become part of the standard. This is a perfectly 
acceptable use of ObsCore and TAP.

If CharDM was completely lacking, I would probably chose option #3 as I would 
judge the concept here not usable at this time. I would not use some arbitrary 
convention involving negative values (option #2).

my 2c,



-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7