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

[Markus Demleitner]

Dear François,

On Fri, Jun 18, 2021 at 04:16:44PM +0200, BONNAREL FRANCOIS wrote:
> Le 17/06/2021 à 12:28, Markus Demleitner a écrit :
> 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  ?

Yes -- publishing updates to the official vocabulary repo is
non-automatic by design.  If you're curious, see 
https://volute.g-vo.org/svn/trunk/projects/semantics/voc-source/README
for the current procedure (which I may automate *just a bit* as we
gain more experience), but I'm really sure there always needs to be a
review step between the VCS and the ivoa.net repo.

Your change is in, however.

> 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.

Well, as usual I'm advocating being guided by pragmatics: What
should clients do?

The two use cases, again, are:

* "as a researcher, I want to discover spectrally (spatially,
  temporally...) resolved data" ("obscore use case")
* "as a client author, I want to be able to have a reasonable guess
  which SAMP client I can send a dataset to and hope it'll be
  understood" ("datalink use case")

I'd be very reluctant to add others, as satisfying these two is
already hard enough.

>           I see at least and at first sight 4 different criteria

That's another way to look at things, and I think it's useful to
have close look at these criteria to find out which are relevant to
product-type (with these use cases) and which perhaps are not; for
instance, I doubt that your criterion (3):

>            3 ) third criterion  : quality of sampling.
> 
>                     We will distinguish well sampled axes from
> under-sampled axes. the latter we will call spares axes.

will actually make a practical difference to either use case.

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

I suspect that even if we somehow trick things so that we'll have a
tree, that tree won't be useful for either use case.

So, I've come to the conclusion that the #array* concepts were a
mistake, inspired by a misguided desire to somehow give #cube an
operational meaning.  I'd drop them now (François, if you agree,
either do it yourself or poke me).

As to how to go on, I suspect perhaps we should go for SKOS rather
than one of our strict, tree like, vocabulary formalisms.

In SKOS, there's no reason to have a tree; the narrower relationship
is a lot looser there (and not transitive for a reason).  For
instance, we could have #spectrum, #timeseries, and
#dynamic-spectrum, and #dynamic-spectrum could be narrower than
#spectrum and #time-series.  With such a thing, you can still run
something like

1=gavo_vocmatch(dataproduct_type, 'product-type', 'spectrum')

and match dynamic spectra.

This needs a lot more thought (in particular as regards what's
"narrower" and what's "wider" in such a graph), but I suspect using
SKOS and loose semantics would require a lot fewer contortions while
covering the use cases (if possibly just marginally).

          -- Markus