Vocabularising dataproduct_type

[Markus Demleitner]

Dear Mireille,

On Tue, Mar 24, 2020 at 11:04:24AM +0100, Mireille LOUYS wrote:
> I have read again the various inputs along this thread.
> I would like to summarize a bit and propose a way to harmonize the various
> existing sets of terms into the new vocabulary and help for backward
> compatibility.
> 
> Sorry if this is a bit long. Just to recap.
> I understand there are various uses cases:

Thank you for this nice summary.  Just one correction:

> *2- **Specifying dataproduct types managed by services*
> Registry entries for DAL services need to expose the type of data products
> used or generated by a service.
> One example of service described in Registry is SPLAT, a VO tool which can
> visualize curves as one or several functions from a 1D Vector holding
> time or spectral coordinates: freq, wavelength, energy.
> For this Obscore dataproduct_type labels can be reused:
> sed, spectrum, timeseries.
> 
> A registry entry (service) dealing with catalogs (all sky)
> needs the "catalog" term.

No, I cannot see any use case for having something in the Registry
that would discover a (DAL) service returning catalogues, and if
there were one, I would probably look closely at what is going on.

>From the point of view of the Registry, catalogues are resources with
a Registry record of their own.  Changing this would need a strong
agenda.

That's not arguing against having a term #catalog in
dataproduct_types; not all terms in a vocabulary need to meaningful
in all contexts (e.g., relationship_type#IsServedBy has no sense when
we'd use relationship_type in a bibliography).  It's just that this
term is not needed by the use cases in SimpleDALRegExt (which
admittedly can be different for HiPS; but then at least right now I'm
rather convinced that eventually, non-ephemeral HiPSes should
have Registry records or at least capabilities of other Registry
records of their own).

> I propose this suggestion :
> lets define
> - /'source list'/ for gathering sources extracted from one or a small set of
> observations, like multiband images restricted to a region, a radio cube, an
>  event list, etc.
> - /'catalog'/  for allsky or multi regions source lists
> This is already the term used at CADC, as Pat mentionned.
> We can derive these terms from 'measurements' in ObsCore for compatibility.

First: I'd suggest to first pass the vocabulary with the terms
defined by obscore; this is so later changes are properly tracked,
and also to avoid encumbering the review process with discussions on
new terms.  Of course, getting the definitions of the existing terms
as precise as possible ought to be part of the review.

Then, further terms can then be added by VEPs, and there's nothing
wrong with writing these VPEs up now.  Using the VEP process will
help us honing the terms so that later uncertainties -- as with
#measurements now -- will become less likely.


While I'd like to keep the discussion on new terms out of this
thread, let me note that my first question about a VEP proposing both
#source-list and #catalog would be why there should be two different
terms for tables of objects, i.e., what the use case is that needs to
tell, if I understand your intention correctly, "single field" and
"multiple fields" apart -- perhaps you could already discuss that in
the VEP's rationale?

Thanks,

         Markus