[obs-tap]:updates on the Proposed recommendation

[Douglas Tody]

More precisely what you might have is something like (display in a wide view):

     ObsId     Type     Subtype               Level     Format                         Title
     ----------------------------------------------------------------------------------------------------------
     123      event    chandra.hrc.pkg         1      application/x-tar-gzip   Chandra ACS-XYZ observation package (event,refimage)
     123      image    chandra.hrc.refimage    2      image/fits               Chandra ACS-XYZ reference image
     123      image    chandra.hrc.preview     2      image/jpeg               Chandra ACS-XYZ preview image
     345      event    rosat.foo.pkg           1      application/x-tar-gzip   ROSAT whatever observation package (xxx)

and so forth.  The subtype could in principle be more generic but will
likely be instrument-specific for a level 1 observation.

The Title should concisely describe the data product, e.g., origin,
instrument, ID, what it is (observation package, calibration, standard
view, etc.).  The title string is what one normally wants to output on a
displayed image or plot to identify to a human the data being shown.
You can put whatever you want in there to describe the data product so
long as it is concise (one line of text).

         - Doug




On Mon, 11 Jul 2011, Douglas Tody wrote:

> On Thu, 7 Jul 2011, Arnold Rots wrote:
>
>> 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.
>
> Well we don't specify what the subtypes you provide for your archive
> should be so I suppose you could get away with this, but this example is
> not at all what we had in mind.  The subtype should be the science type
> of the specific data product, *not* details about the content of the
> data product.  I would expect the type to be "event" (meaning "event
> data" not "event list") and the subtype to be something more like
> "chandra.hrc.package", "chandra.hrc.refimage (or "rosat.XX" etc.).
>
> Note subtypes are supposed to be fixed strings so that one can search
> the local archive for a particular type of data product; if you try to
> describe what is included in a particular data product then such
> selection won't be possible.  So for example a client will do a generic
> query to see what subtypes Chandra defines, and then they can pose a
> more specific query to get a certain type of Chandra-specific data
> product.  Likewise for ALMA etc.
>
> Note you also have obs.title where you can provide a short description
> of the data product and for this you can provide whatever you want.
>
>       - Doug
>