[VEP-008] new term in product-type: #dynamic-spectrum

[BONNAREL FRANCOIS]

Hi Markus,
Hi Yan and Baptiste,
Hi all,
Le 17/06/2021 à 12:28, Markus Demleitner a écrit :
> Hi,
>
> On Wed, Jun 16, 2021 at 02:30:01PM +0200, Baptiste Cecconi wrote:
>> Dear colleagues,
>>
>> here is another VEP for the product-type vocabulary.
>>
>> We propose a new term: #dynamic-spectrum
>>
>> See here for details:
>> http://volute.g-vo.org/svn/trunk/projects/semantics/veps/VEP-008.txt
> Thanks for preparing that, but since product-type is preliminary as a
> whole right now, there's no need for VEPs -- we can just edit the
> vocabulary at this point.
>
> François has volunteered to serve as an editor of the vocabulary for
> now, so unless he has major qualms, I'd let him add the term and then
> poke me to re-build the published vocabulary.  Me, I'm fairly happy
> with the concept, the identifier, the label and the definition, so
> you'd get my go-ahead.
>
> I'd probably add it as a top-level term at this point.  I'm getting
> more and more convinced that the introduction of the top-level array
> classes was not a good idea (nobody is going to look for "2 d
> arrays", and the original idea -- constraining to datasets that a
> given client will be able to process -- probably is something we
> can't do anyway), so there's no point in wasting brain cycles on that
> sort of hierarchy at this point.
see below
>
> François, feel free to poke me if you'd

> like me to go through the
> technical motions.

Well I had to remind how it worked with svn and volute because I am now 
more used to github.

And find out my volute credentials !!!

But apparently the source is now updated. Doens't seem to be on the 
vocab list yet however

Does that require a specific action by me, or Markus  ?

>   
>
> Once it's in, let's move VEP-008 to Abandoned with a comment it just
> went in since the vocabulary was still preliminary; not pretty, but
> better than potentially have two VEP-008s later, or to make it seem
> as if VEP-008 went through a normal VEP procedure.
>
> Thanks,
>
>          Markus

Classification of dataproducts seem to be very difficult. I don't think 
a tree-like vision is possible (except if we exclude all but one of 
following criteria). Nodes in a matrix maybe.

      How can we characterize dataproducts. data products are set of 
points in a parameter space, obtained from an observation or a simulation.

           I see at least and at first sight 4 different criteria

           1 )   independence/dependence of parameters (= axes)

               a )   if all are independent we are facing an event list

               b )  if all but one are dependent of the latter, we are 
facing a scalar function

                c )   if a group of axes are independent each from 
others and the others depends of them we have a (multi)variate function 
of several variables or something like that

            2 ) second criterion : nature of the independent or 
dependent axes (= observables)

                    this looks like a secondary criterion refining 1 )

                          for example 1 b ) with dependent axis = mag or 
flux and independent axis = time is a lightcurve.

                                              and with independent axis 
= spectral axis  we have a spectrum or a sed.

            3 ) third criterion  : quality of sampling.

                     We will distinguish well sampled axes from 
under-sampled axes. the latter we will call spares axes.

                     Which axes are sparse and which are not this will 
give us a wide variety of products. For example a scalar function 
flux(spectral coordinate) regularly sample is spectrum while the sparse 
one is a sed ?

                     Well sampled data are generally regularly sampled 
(constant sampling/resolution ratio) while for sparse data we don't 
really care if they are regular or irregular?

            4 ) fourth criterium : organization . We have basically 
matrices (bitmaps) and tables.

                      If we have several independent axes regularly 
sampled  the matricial (=bitmap) organization is probably the best 
choice. But the reverse is not true. because any matrix axis needs a 
mapping from the world axis to the matrix index (pixel number). And this 
mapping can be very far from linear !!! Think to "lookup functions" in WCS.

                      In  addition we can combine both organizations . I 
don't see example of matrices where the matrix cells are tables, but I 
do know tables where the table cells are matrices !

                      Think to a visibility dataset. it's irregularly 
sampled on u and v axes. Probably a table will be created for that. But 
each u,v cell will contain a time/frequency(independent)-complex 
visibility (dependent) multivariate function well organized as a matrix

              All these criteria  will build a complex mesh. Can we 
simplify  that and have a tree ? Not sure !!!

              It's probably better to identify product types obviously 
different  according to the practice and see if some of them may be 
unambiguously considered as children of others

                 ( light curve < timeseries ? )

Cheers

François