<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Mireille and all, <div class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 24 mars 2020 à 15:58, Mireille LOUYS <<a href="mailto:mireille.louys@unistra.fr" class="">mireille.louys@unistra.fr</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Hi Baptiste , <br class="">
</p><p class="">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) . <br class=""></p></div></div></blockquote><div>If you remove the "some quantity of light detected" part, yes, we could probably agree on some definition. In solar and planetary sciences, we don't do only "light", we also measure particles or more generically matter (mass spectrometer detectors, drilling on martian rocks, physical samples from meteorites, or from sample return space missions, in-situ meteorological parameters in the atmosphere of a planet or a moon…). </div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">"events" however are a special category of Obscore dataproducts,
defined at the time with the Xray event lists in mind. <br class="">
</p>
<blockquote class="">
<ul class="">
<li class="">it requires columns for a time stamp. </li>
<li class="">it is organised as a list of events if necessary</li>
<li class="">It is stored in some formats like VOTable, ascii tables,
etc. or specific formats as used for planetary data like CDF,
FITS, etc. </li>
</ul>
</blockquote><p class="">Do you think we could consider 'event' or 'event list' instead of
'catalogs of events' in the Planetary domain? <br class=""></p></div></div></blockquote>The types "event" and "event list" are two different things, since in the first case, the object is a single event instance, where in the second case, the object is composed of several events. We already have "event", for distributing events (one at a time). When we specify both dataproduct types (Catalog+Event), then it means that we have what you propose to name an "event list". </div><div><br class=""></div><div>This brings me to this question: what is the intrinsic difference between a "catalog" and a "list" in the current context of IVOA dataproduct_types ? </div><div><br class=""></div><div>Cheers,</div><div>Baptiste</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">that would help to put vocabularies in sync , as I mentionned in
my previous emails.<br class="">
</p><p class="">Cheers, Mireille<br class="">
</p>
<div class="moz-cite-prefix">Le 24/03/2020 à 14:10, Baptiste Cecconi
a écrit :<br class="">
</div>
<blockquote type="cite" cite="mid:0C9030C0-9A48-4B21-85CF-22ED1B360961@obspm.fr" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
In VESPA/EPNcore, we use the <b class="">Catalog</b> 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.
<div class=""><br class="">
</div>
<div class="">By the way, our equivalent of <b class="">Measurement</b>
would be <b class="">Catalog Item</b>. 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). </div>
<div class=""><br class="">
</div>
<div class="">Baptiste<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">Le 24 mars 2020 à 11:06, Mireille LOUYS <<a href="mailto:mireille.louys@unistra.fr" class="" moz-do-not-send="true">mireille.louys@unistra.fr</a>>
a écrit :</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8" class="">
<div class=""><p class="">hi all, <br class="">
</p><p class="">here is my suggestion for the term <b class=""><i class="">catalog</i></b> as it has been
used so far in the VO</p><p class=""><i class="">catalog</i>:<br class="">
</p><p class="">a set of physical quantities recorded from
an observing/simulation process and measured/computed
for a set of individual astronomical objects
(sources).<br class="">
Each catalog entry corresponds to one individual
source object. <br class="">
The usual representation is a table with columns
figuring the quantities and rows representing an
entry.</p><p class=""><i class="">source list:</i></p><p class="">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. <br class="">
</p><p class="">Typically, ObsTAP can handle source list as
dataproducts, with coverage inherited from the
progenitor dataset.</p><p class="">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.</p><p class="">Here is an interface example: <a moz-do-not-send="true" href="http://cdsarc.unistra.fr/viz-bin/cat" class="">http://cdsarc.unistra.fr/viz-bin/cat</a><br class="">
</p><p class="">Are there server applications distributing
such all sky catalogs with Obscore as one single
dataproduct? <br class="">
</p><p class="">best , Mireille<br class="">
</p>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
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</pre>
</div>
</div></blockquote></div><br class=""></div></body></html>