The product-type vocabulary

[Markus Demleitner]

Hi Dave,

On Thu, Dec 16, 2021 at 01:49:09PM +0000, Dave Morris wrote:
> Why treat events differently to spectra and images ?

Well, as I'm usually preaching: the identifier is just a mnemonic,
and the label not much more than a hint -- the same word means
different things to different people.  What a concept *really* is in
a given vocabulary is in its description (that therefore requires
extra care).  For #event, that currently is:

  "A collection of some sort of observed events, such as high-energy
  particles observed. An event is typically characterised by spatial,
  spectral, and time information."

(and since that comes from obscore, I'd be very reluctant to change
the extension, though the wording of course is open to improvement).
You could call a spectrum a spectral-point-collection and deal with
it in analogy, but we already have the term spectrum for that.
"Eventum", on the other hand, doesn't exist (yet?).

This also strongly suggests that a single VOEvent (which, I think, is
what concerns you) is not covered by obscore's (and hence
product-type's) #event concept; a single thing is really distinct
from a one-element collection in most cases. 

Or, viewed through the use case angle: I suspect that VOEvents and
#event instances are processed by different clients, and also that
there are almost no overlapping discovery cases.

> On 2021-12-16 13:18, Markus Demleitner wrote:
> > In that vein, "event"
> > (that I'm rather sure would in general refer to files containing
> > quite a few event*s*) probably should have been called
> > event-collection in obscore.
> 
> If we follow that pattern then we should register SIAP and SSAP as
> 'image-collection' and 'spectrum-collection' ?

Uh, this vocabulary is *not* one that will directly label services or
data collections.  Registry records might one day say "I'm serving
product-type X" or "I'm a collection of product-type X-s", but you
see that the plurality would be in the predicate of the RDF triples.

The thing that motivates the current vocabulary, however, is
datalink, and there we're labelling individual datasets.

> The vocabularies should be consistent. The easiest (and most portable) is to
> base everything on the singular not plural form.

That's a good point, and as it happens RDF makes it reasonably easy
to figure out what "consistency".  The way we're currently building
our vocabularies, we expect that the resources contained in there
always fit into well-defined template triple(s).  For datalink/core,
that would be

  (this-dataset, <datalink-property>, link-in-row)

For product-type, this would be

  (link-in-row, is-of-type, <product-type-concept>)

or, hopefully at the same time and one day,

  (registry-resource, contains-or-serves, <product-type-concept>):

In structural linguistic terms, one could say: "An IVOA vocabulary is
a paradigm" (cf.
<https://en.wikipedia.org/wiki/Structural_linguistics>, and don't be
confused by the morphological paradigm, which is related but
different).

Using this check, you can easily see that, indeed, there would be a
place for both *#voevent (a single event described in the VOEvent
schema) and *#event-collection (e.g., "gamma photons received from
blazar X in the 2010s"): Both would perfectly work in a triple

  (my-magic-file.dat, is-of-type, X).

-- and as I've tried to show above, there are probably valid use
cases for both.

That doesn't mean I'm arguing we should add *#voevent (or a similar
concept) right now.  We should do that once someone actually needs
it, because then the use case no longer is speculative.

> To be consistent, should the description of the others also be updated to
> "collection of images" and "collection of spectra" ?

If that's what they are, yes. #dynamic-spectrum is a first example
for such a collection of spectra, additionally giving the reason the
spectra are collected (in this case: they are taken in the same way
but at different times).

         -- Markus