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

[Douglas Tody]

Hi Mireille -

I completed one pass through the revised version.  Will go though it
more carefully but the main thing I noticed was that we did not yet
replace the use of "/" in pol_states with our standard list delimiter
(comma) as was agreed in the telcon.  Has a reason to use "/" (which is
inconsistent) been identified, or is this just an oversight?

 	- Doug



On Fri, 8 Jul 2011, Mireille Louys wrote:

> 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
>
>