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

[Mireille Louys]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PR-ObsCore-v1.0-20110807.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 363043 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20110708/565b7145/attachment-0001.bin>