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

[Mireille LOUYS]

Hi Baptiste ,

If we can extend the notion of what is the object we consider as a 
source, I guess we can accomodate most of the objects of Vespa/EPNTAP 
with the same  catalog definition . After all it seems it deals with 
some quantity of light detected for an object, astronomical object, 
solar regions , asteroids, planet, regions on a planet etc.. ( just a 
global perspective offered here to gather all possible sources) .

"events" however are a special category of Obscore dataproducts, defined 
at the time with the Xray event lists in mind.

      * it requires columns for a time stamp.
      * it is organised as a list of events if necessary
      * It is stored in some formats like VOTable, ascii tables, etc. or
        specific formats as used for planetary data like CDF, FITS, etc.

Do you think we could consider 'event' or 'event list' instead of 
'catalogs of events' in the Planetary domain?

that would help to put vocabularies in sync , as I mentionned in my 
previous emails.

Cheers, Mireille

Le 24/03/2020 à 14:10, Baptiste Cecconi a écrit :
> In VESPA/EPNcore, we use the *Catalog* term with a similar definition, 
> but with a wider scope when it comes to the set of individual objects 
> the catalog is related to. Any type of target (planet, moon, asteroid, 
> sample…), location on target, events.
>
> By the way, our equivalent of *Measurement* would be *Catalog Item*. 
> This means that the primary information is in the current record 
> (i.e., in the current row for a TAP service), instead of relating to 
> an remote URL for the information (i.e. through an access_url column 
> for a TAP service).
>
> Baptiste
>
>> Le 24 mars 2020 à 11:06, Mireille LOUYS <mireille.louys at unistra.fr 
>> <mailto:mireille.louys at unistra.fr>> 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.
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20200324/b726eab9/attachment.html>