Vocabularising dataproduct_type

[Markus Demleitner]

Dear François,

On Tue, Mar 17, 2020 at 09:41:42PM +0100, François Bonnarel wrote:
>      ObsCore/ObsTAP is for discovery of datasets which have time, spatial,
> spectral and polarisation axes. Selection on the ObsCore parameters is not
> sufficient for catalogs with plenty of other parameters which are directly
> queried via TAP (or even in the registry). So we had to find another word
> for these specific tables extracted from the datasets in order to not let
> beleive that ObsCore is a discovery model for any kind of catalog. Hence
> "measurements"

That reconfirms that the actual question is: What kind of catalog (or
whatever) would you include into the concept "Measurement", and what
would be out?

>      So I think we should keep "measurements" but not with the negative
> definition "Generic tabular data not fitting any of the other terms. 
> Because
>   of its lack of specificity, this term should generally be avoided,  and
> new, more precise terms should be introduced instead" any of the others will
> fit I think and yes we have to keep ascendant compatibility with obsCore.

We'll still need to have a definition; while the term is just a label
and doesn't really matter, the definition delineates the concept, and
while it can later be adjusted to better fit the actual use, it needs
to say what entity is and, in particular, is not part of the concept.

Hence "Generic tabular data" is not a good definition, in particular
because at least spectra, time series, and events arguably are
tabular data and thus ought to be children of measurements.  But
that, I'm sure, is not useful for what Measurements was introduced
for.

That's why I'm proposing this hedging language.  Once we see what
people actually want to use this for (and why they want it), I'd
expect we can come up with a useful concept to slap the term
"Measurements" on.

On the other hand, if someone proposes a description that

* says something like "it's tabular data",
* keeps spectra, time series, and events out of the concept
* and still has a plausible, useful extension (i.e., there are
  actually datasets that people will want to look for that are part
  of the concept)

(are we agreed on something like these criteria?) I'll happily put it
in, of course.

>         We may imagine have "spectrochronogram" and "sed" as children
> elements of spectrum. "timecube" or "spectralcube" as children from cubes.
> 
>         This will be clear in the vocabulary page but ObsCore will manage
> that at the same level in dataproduct_type (exactly like we already have sed
> and spectrum in parallel today)
> 
>        Thoughts ?

The nice thing is that, if Vocabularies 2 pans out the way I hope it
will, we don't have to think about that now.  As clients come along
that will want this kind of distinction, we can figure out what
structure best covers their needs.

Meanwhile, the vocabulary is clear that anything with 3 or more axes
is a cube, and clients looking for data with special axes ("time
cube", "spectral cube") can use the *xel columns.  Whether other uses
will make futher distinctions in the vocabulary desirable we can, I
claim, confidently leave to the future.

The problem at this point is non-image 2D data.  If that's itching
someone *now*, let's have a separate thread.

> C ) Miscelaneous.
> 
>       If this vocabulary is to be used in various contexts (and indeed it
> is) why do we link it to SimpleDALRegExt ? Vocabularies 2.0 is proposing to
> manage vocabularies as endorsed notes. Why don't we do it this way and refer
> it from  SimpleDAL, ObsCore, DataLink, etc ...

The reason I'd like to link vocabularies to a concrete REC is that
there should be some sort of RFC for them.  It's conceivable to have
this RFC as part of an EN, and that might be what it takes of,
perhaps, the UAT or the object types.

But an extra document always is a liability (who maintains it?  who
should read it?  what, indeed, would it say in this case?).  If we
can avoid it, we should.  

As to citing a vocabulary later, I'm sure you only should say "The
vocabulary \url{http://www.ivoa.net/rdf/product-type}" or, if you're
against URLs in running text "The IVOA dataproduct type
vocabulary\footnote{\url{http://www.ivoa.net/rdf/product-type}}".
Which is a good point -- I'll add that to the Voc2 WD.


         -- Markus