Vocabularising dataproduct_type

[Markus Demleitner]

Hi, 

[restricting to DAL as requested in the original mail]

On Tue, Mar 10, 2020 at 11:56:36AM +0100, Molinaro, Marco wrote:
> I'm happy with the proposal, also in trying to merge the EPN terms
> if feasible.

Their definitions seem stricter than the ones in Obscore, and so it
seems a worthwhile effort to merge them in.

As to introducing new terms on top of what obscore has... well, I'd
like to keep that first step as simple as possible, and adding terms
later is (hopefully) cheap.  Hence, unless someone wants one of these
new things *now*, I'd start with the obscore list.

> I'm not sure about reviewing it within SimpleDALRegExt, if it has
> to be an independent re-usable vocabulary.

Well, the plan in Vocabularies 2 is that new vocabularies are
usually born with a specific REC, and that they're receiving a review
as part of that.  And I'd dearly like to avoid defining an extra RFC
process for whole vocabularies.

Since it's SimpleDALRegExt that needs the vocabulary at this point, I
guess it's a reasonable place to have the RFC for this.

> I wonder also if some thoughts on the usage of the term "cube" applies
> here, because in my mind using "cube" alongside (e.g.) "image" at the
> same level in a vocabulary mixes up format and content concepts (I know
> this already works in obscore).

Yes -- while I think honing the definitions is a good idea, I guess
we should try to keep the concepts (as in: the set of real-world
things ["the extension"]) as they are actually being used.

Saying that a cube is three or more dimensions may be a bit
arbitrary, but I'd argue it's a suitable reflection of the use of
that term in the community -- and then it's, indeed, a thing roughly
on the same level as an image.

But you're right, we are mixing dimensionality (cube) with properties
of the observable (image) with properties of the axes (time series,
spectrum).  In an ideal world, these would be considered separately.
But that's not how people right now think about data sets, and I'm
not sure I can see a major problem with this.

And, also from this thread, Laurent's point: 

On Tue, 10 Mar 2020 11:47:48 +0100, Laurent MICHEL wrote:
> I'm not sure that catalog data sets fit well within the definition
> of the measurements.  A catalog is not necessarily derived from a
> dataset (Obcore P29 makes that distinction)

So... what do you suggest to fix this?  The definition I'm currently
proposing is

  A set of derived measurements obtained from a particular original
  dataset.  The prototypical example would be a list of sources
  extracted from an image.

What would you like to see changed?

         -- Markus