[ObsCore 1.1] requirements for a new dataproduct_type value for source list / catalog

[Laurent Michel]

Dear Pat.

We are sorry, but we still do not agree with your "catalog". If you say a catalog is "table of something" then event lists or 
spectra are catalogs as well. In this case, the data product types overlap with each other.
we remain convinced that ObsCore data types must refer to data products resulting from an observation. We are continuing to 
promote our "source list" type.

Le 03/06/2016 19:47, Patrick Dowler a écrit :
> The usage that we (CADC) have in mind is that there is a catalogue
> data product (a file) that users can find and download. I would like
> to assign it metadata like calib_level = ?* and dataproduct_type =
> catalog (eg). I don't think this overlaps with Source DM because this
> is just describing the whole catalogue while Souce DM describes the
> content of the catalogue.
>
>  From the various terms that have been discussed, I still don't see any
> as better than "catalog" (yeah, American spelling). "catalog" just
> says that you will get back a list or table of something but not what
> the items/rows are. I think that is the correct level of detail for
> dataproduct_type. This seems consistent with the level of detail
> expressed by "cube" or "timeseries" (time-dependent measurements of
> something)
>
> Additional detail about what the items are could go into subtype or as
> more specific child terms if we go in the vocabulary direction. I
> guess one could also feasibly use o_ucd to specify what the observable
> (items) are...
>
> * side issue: I always considered the fact that calib_level was an
> integer (vs vocab) to imply that values larger than 3 were allowed but
> the meaning is not specified other than it meant "more processing
> applied". I think ObsCore-1.1 may need to be more explicit that this
> is allowed but that future versions may define what 4, 5, etc mean...
> I could conceive of more calib_levels that were really calibration and
> after that analysis can't really be ranked so maybe at some point we
> would define a single value to be "analysis result" (calib_level =
> 10?). Thoughts?
 From our point of view, calib level 0 to 3 are roughly common for most of the reduction pipeline.
we fear that further levels (4 and more) would become too specific to a particular data provider and not suitable for an all 
purpose data discovery (Obscore)

Cheers
LM and ML
>
> Pat
>
> On 3 June 2016 at 08:23, Mireille Louys <mireille.louys at unistra.fr> wrote:
>> Dear DMers ,
>>
>> There was a suggestion on the DM list and Obscore1.1 RFC page to use ObsCore
>> serialisations to expose lists of detections.
>>
>> I would like to know your opinion about :
>>
>> - How does the TAP Schema proposed in ObsTap fits the needs for describing
>> such lists
>>
>> - Is it adequate to include it ObsCore , and the ObsTAP TAP Schema or rather
>> include it in Dataset Metadata DM?
>>
>> - Is there an overlap with what the Source DM currently describes ?
>>
>>
>> This would help to solve the pending question of the addition of this new
>> term in ObsCore 1.1
>>
>> Many thanks for providing pros and cons and real data set examples ,
>>
>> Best wishes , Mireille Louys
>
>
>

-- 
jesuischarlie/Tunis/Paris/Bruxelles

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34