[obs-tap]:updates on the Proposed recommendation

[Arnold Rots]

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

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

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.

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?

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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> 
> Mireille Louys wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > Arnold, Daniel,
> > This is a second try . I mixed adresses with a strange copy/paste.
> > Sorry , Mireille.
> > 
> > ------------------------------------------
> > Dear all ,
> > 
> > Here is an updated version of the ObsCore DM document.
> > I tried to correct and modify the text according to:
> > - typos and inconsitencies mentionned by Petr on RFC page
> > - comments given in mails
> > - actions listed during the telco on June 6th
> > 
> > Modifications are highlighted to help you tracking the changes.
> > *check pol_states*
> > I maintained the first proposal of having a list with / , with a  
> > leading / to help
> > distinguish Y from other combinations XY, YY , YX etc..
> > --> Using a leading comma was too strange for me.
> > 
> > table 6 and 7 use TAP defined columns: principal, indexed, standard.
> > I filled them in with my personnal understanding .
> > It would be useful to have data base system managers to check this .
> > 
> > to be inserted : update of section 5 for registering an ObsTAP service.
> > 
> > Thanks for your reading and comments (the very last ones, I hope)
> > Cheers , Mireille
> > 
> 
> [ Attachment, skipping... ]
> --------------------------------------------------------------------------
> Arnold H. Rots                                Chandra X-ray Science Center
> Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
> 60 Garden Street, MS 67                              fax:  +1 617 495 7356
> Cambridge, MA 02138                             arots at head.cfa.harvard.edu
> USA                                     http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------