Vocabularising dataproduct_type

[François Bonnarel]

dear Markus, all

The discussion is moving up since that email below.

Anyway I should answer at some point.

Before doing that I need some clarification

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

Does that mean non-image 2D data is the problem you want to solve here, 
or on the contrary that we shoud open a new thread if we wnat to discuss 
that.

The confusion for comes from "at this point". Why point, please ?

Cheers

François

Le 18/03/2020 à 08:42, Markus Demleitner a écrit
> 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
>