[Heig] vocabulary update: proposal for dataproduct_type update for high energy data : event-list definition and event-bundle

[Markus Demleitner]

Hi Bruno,

On Tue, Apr 29, 2025 at 03:27:35PM +0200, Bruno Khelifi via semantics wrote:
> Le 25/04/2025 à 09:29, Markus Demleitner via heig a écrit :
> > (1) used-in: I really, *really* would like to see actual, published
> > data here (always, in all VEPs; it's a pain if we go into all the
[...]
> >    used-in: dataset ivo://csc.harvard.edu/scsr2?some-obs-id onhttp://cda.cfa.harvard.edu/csctap
> >
> In the VHE domain, CTAO, KM3NeT, SWGO wish to publish their current and
> future data in VO. The current running experiments MAGIC and HESS are
> working toward the publication of their legacy data into the VO.
> And this is also in this context that such extensions are of interest for
> us.

Is anything already online in obscore or via datalink?  It would
really be great if there was something out there when the VEP
officially goes up?

> > (2) Relationship: That's an operational field, i.e., I need to create
[...]
> > user side: If I'm looking for #event-bundle, do I want to see
> > #event-list, too?  If I'm looking for #event-list, do I want to see
> > #event-bundle, too?  Whatever ought to encompass the other is the
> > wider term.
> event-bundle is e.g. event-list + response (a set of IRFs)
> (+provenance+readme+etc)
> In this context, one would need to use DataLink to access to all files

Well... but does

#event-list #skos:broader #event-bundle

hold or is it the other way round?

> First, our IRFs are not just accessory, they are mandatory for HE (photons
> and neutrinos) to make physics (for data analysis specialists:

I don't doubt this, I was just wondering if, from a *product-type*
point of view there is a sufficient point in telling #event-bundle
and #event-list apart: Do you ever want to discover one or the other?
Would it perhaps be necessary to tell the two apart for the purpose
of choosing an appropriate SAMP client?

A good answer to that would also help answering the relationship
question.

> In addition, one has use cases where these IRFs can be used without
> event-list: the case of simulations. Also, one can have one set of IRFs for
> many observations. So a data producer could use a dedicated entry in ObsCore
> for that.

Ah-ha!  But this would mean that you would need IRFs as an
independent product type, no?  How else would you annotate these
stand-alone IRFs?

If that's solid reasoning (and frankly, I only have a fairly vague
idea of what I'm talking about here), then we could introduce some
concept of *#ancillary into product-type (which feels a bit wrong
because we have that concept in datalink/core, too, but I think it's
justifiable), and then *#irf as a narrower term.  #event-bundle would
then be narrower than both #irf and #event-list.

The consequence would be that searches for #event-list yield
#event-bundle, too, but searches for #event-bundle wouldn't.  Does
that sound right to you?  If so, could you try to write a definition
for *#irf (and perhaps come up with a less cryptic label)?  I think
we should amend the #event-bundle VEP with that on top, if this is
what we're going to do.

Thanks,

           Markus