[ Re: Vocabularising dataproduct_type] an attempt for definitions for catalog and source list

[Stéphane Erard]

Dear Mireille

> Le 24 mars 2020 à 17:43, Laurent MICHEL <laurent.michel at astro.unistra.fr> a écrit :
> 
> Mireille
> 
> I agree with your definitions except for one item (see below)
> 
> Le 24/03/2020 à 11:06, Mireille LOUYS a écrit :
>> hi all,
>> here is my suggestion for the term */catalog/* as it has been used so far in the VO
>> /catalog/:
>> a set of physical quantities recorded from an observing/simulation process and measured/computed for a set of individual astronomical objects (sources).
>> Each catalog entry corresponds to one individual source object.
> A catalog has no necessary one individual source per row.
> - XMM provides a catalog of detections, thus sources that have been detected several times are duplicated in the catalogue (likely with different parameters).
> 
> To me the concept of catalog is related to something that has been compiled from different progenitor datasets. *Data compilation* is the key of the catalog definition.


It may be that « Each catalog entry corresponds to one individual source object » is ambiguous, as it suggests strict correspondance between entries and objects.
Maybe  « Each catalog entry corresponds to a single source object » is more explicit. 

But I have two reservations:
- the same as Baptiste: in EPN-TAP we have catalogues not only of measurements, but also of craters, linear features on planets, geologic boundaries, features automatically extracted from images, etc (and in fact events). I’m not sure those would fall in a more global definition of « source ». 
- We use catalogue to handle datasets, really. A typical example are the VizieR catalogues which we link by describing the subject, not the detailed content. In this case, entries can be different products, e.g. spectra and images, and I’m pretty sure they can be tables of many sources.

+ We recognized with the interface to VizieR the need to specify the type of catalogue elements in the same dataproduct_type (e.g. catalogues of spectra would be described as ca#sp) - this is the only simple way to find spectra which are distributed inside catalogues.

Finally, the usual ambiguity is present in many recent mails on the subject - catalog vs catalogue. I’ve stuck to catalogue for EPNCore, although we’re using a code (ca) in practice. It may be more important in other contexts.

Cheers
Stéphane

> 
> LM
> 
>> The usual representation is a table with columns figuring the quantities and rows representing an entry.
>> /source list:/
>> a catalog where entries are derived from one or a restricted set or data products : single image, multiband image, radio or hyperspectral cube, eventlist for instance.
>> Typically, ObsTAP can handle source list as dataproducts, with coverage inherited from the progenitor dataset.
>> On the contrary very large catalogs like survey, hips catalogs with coverage='allsky' are managed within archives/datacenters and searched on with keywords from the astronomical semantics, like type of objects, regime, instrument types, survey name, etc.
>> Here is an interface example: http://cdsarc.unistra.fr/viz-bin/cat
>> Are there server applications distributing such all sky catalogs with Obscore as one single dataproduct?
>> best , Mireille
>> -- 
>> --
>> Mireille Louys,  MCF (Associate Professor)
>> CDS				IPSEO, Images, Laboratoire Icube
>> Observatoire de Strasbourg	Telecom Physique Strasbourg
>> 11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
>> F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
>> Tel: +33 3 68 85 24 34
> 
> -- 
> ---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
>     Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
>     11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
>     67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
> ---