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

[François Bonnarel]

Hi Mireille
there are till a few things in the tables
Comparing table 1 of main text and table 1 in Appendix B
  dataproduct_type: Type string versus enum
access_url: string versus "no type"

Additional comment for table 1 in appendix B:
"Description" of s_dec is missing..
utypes: can we split the lines after dot instead of the
middle of a term (examples such as .... Bounds Extent.diameter
or SpatialAxis.calibStatus or SpatialAxis.Accuracy.staError etc ...°

Little discripancy between the utypes table 1 appendix B and table 7
appendix C
Curation .Rights versus Curation.rights
Curation.Reference versus Curation.reference

em_calib_status is missing in table 1 Appendix B

that's it for now ....
Cheers
François

Le 08/07/2011 13:21, Mireille Louys a écrit :
> Dear Arnold, Dear all,
>
> Thanks very much for reporting these typos and inconsistencies.
> I produced a new document with corrections suggested from you and the 
> RFC page inputs. They appear highlighted as modification follow up in 
> the .docx file attached below. This is just to help contributors to 
> follow the changes.
>
> You can provide comments till Monday, then I will integrate the final 
> changes in order to proceed for TCG review.
>
> See my comments inserted in the text below.
>
> Best regards , Mireille
>
> Arnold Rots <arots at head.cfa.harvard.edu> a écrit :
>
>> Aside from what I reported in a previous message, quoted below, there
>> are more discrepancies between Table 5 and Tables 6 and 7:
>>
>> obs_creator_did is missing from Table 7
>> o_units in Table 5 should be o_unit
>> pol_states is missing from Table 6
>> facility_name and instrument_name are spelled differently;
>>   even though required, they show up in Table 7, rather than 6
>> em_unit is missing from Table 5
>> o_stat_error is missing from Table 7
>>
>
> *included and corrected*
>
>> Also, note the comment I made on MJD in use case 1.6
>> and on the uselessness of bib_reference because of its murky
>> definition
> *MJD done*
> bib-reference is an optional field that a data provider may use to 
> flag some data sets as the ones used and published together with a 
> scientific paper.
> This is not meant to behave like a citation index and point to all 
> papers mentioning this data set.
>
>> I still lament the fact that the data access functionality is
>> compromising the self-consistency and usefulness of the data discovery
>> function, but decided for our tarred packages to use:
>>   dataproduct_type = NULL
>>   dataproduct_subtype = package:event,image
>>   access_format = application/x-tar
>> As far as I can tell, this is within the specifications.
>>
> This seems a proper use of the Obs/TAP specification to expose your data.
> "dataproduct_subtype" is an optional field that the data provider can 
> define.
> Possible values for this field should be clearly documented by the 
> service.
>
>> o_stat_error is an interesting case. Since our unit is counts, the
>> proper value would be "POISSON"; I realize that that is not a double,
>> but what else can we give as a value?
>>
> This was meant only for quantitative estimation of the error and does 
> not cover the statistical properties of the signal.
>
>> Please do not consider this list of corrections to be exhaustive.
>>
>> Cheers,
>>
>>   - Arnold
>>
>> Arnold Rots wrote:
>>> Mireille,
>>>
>>> Here are some items.
>>>
>>> Ian Evans noticed the inconsistency in units for spatial resolution
>>> between the Tables 1, 4, 5, and 6 (arcsec vs. deg); what should it be?
>>> I assume deg?
>>> See also s_stat_error in Table 5.
>>>
> We agreed in previous iterations to have resolution and errors in a 
> convenient and handy unit: arcsec for space and s for time , for 
> instance because they are usually given that way in instrument 
> descriptions and scientific papers.
>
>>> In addition, I noticed that Table 5 contained unit "day" that should
>>> be "d", Table 7 has erroneous unit "d" for data rights and is missing
>>> most units.
>>>
> *updated*
>>> The section on obs_publisher_did is a bit murky and not quite
>>> consistent with the definition in the spectral data model where it
>>> expresses a strong preference for using the same DIDs as are being
>>> used in the journals.
>>> That implies that the data product the query result refers to may be a
>>> subset of what the DID stands for, as the current spectral draft
>>> affirms.
>>> On the other hand, I don't think the spectrum DM and the SSA DAL are
>>> quite consistent in this respect. It might be good to have a more
>>> thorough discussion on these DIDs and consistency between all PRs.
>>>
> This is identified as a work to do , in compatibility with undergoing 
> effort on IVOA identifiers definitions .
> We agreed during the last telecon to reconsider it for a future 
> version of Obs/Tap.
>>> It also brings me back to the issue I have been harping on: what to
>>> do with packages of products pertaining to a single observation;
>>> I will not repeat that here.
>>>
>>> However, there is also the reverse problem: what do we do with data
>>> products based on multiple observations? Do we allow ObsId to be a
>>> list of ObsIds?
>>>
>>> I still find the bibcodes a bit problematic. The SSA DAL doc calls it
>>> a "curation reference", but in the text seesm to imply that any
>>> publication mentioning the data is fair game. Is this really meant to
>>> be a reference to the data, or is it to be any paper that references
>>> the data? There is a difference between these two...
>>> I realize, though, that this is primarily an issue for the SSA DAL doc.
>>> But it has repercussions for this document as well.
>>>
>>> Cheers,
>>>
>>>   - Arnold
>
>