HEIG Note discussion: Obscore and dataproduct_type and various classes of datasets in High energy data

[Markus Demleitner]

Dear DM list,

On Wed, Sep 03, 2025 at 01:10:34PM -0400, Igor Chilingarian via dm wrote:
> I've looked at the attached diagram. The main issue I see here is that a
> typical X-ray dataset (from Chandra and XMM-Newton) being an "event-list"
> can in fact be considered as image, datacube, spectrum, and time-series all
> at the same time. And there was a disperser (e.g. grating) involved, it
> will make it even more complex. Therefore, I don't really understand how
> you can build any kind of hierarchical relationship between a high-energy
> dataset and existing types of a dataset in the model. Any ideas?

Disclaimer: I am somewhat jumping into this discussion and doubt that
I understand what it actually about.  It *sounds* as if the following
might be pertinent, though, so indulge me:

The way http://www.ivoa.net/rdf/product-type is built ("SKOS"), a
concept can have multiple "wider" terms (which is, here, an
approximate is-a relationship).  In that sense, we *could* make an
event-list narrower than image, datacube, spectrum or whatever.

Whether we *should* do that is another matter, and for now I doubt
it.

The way to approach this is the consideration: "If someone looks for
images (specifically), would they want to find the dataset in
question?", and I am rather sure that for an event list, that's always
a no, even though you can generate an image from it.

There are the generic concepts *-resolved-dataset in
<https://www.ivoa.net/rdf/product-type/>, and these could be used to
derive more specific sorts of event lists.  For instance, we *could*
have event-list-with-positions, which would be narrower than both
#spectrally-resolved-dataset and #temporally-resolved-dataset (and
#event-list, of course).  But again, I have doubts we should do that.

For one, you'd have to convince me that there is a strong discovery
case here as long as we don't have hundreds of different event-list
collections.  And the combinatorial explosion of potentially ending
up with concepts like event-list-with-positions-and-polarization
scares me, too.

So, my hunch is that if we need this sort information in discovery,
we ought to touch the obscore schema rather than the vocabulary.  For
array-like-data, we have the _xel columns that (mainly) address this
use case.  They won't work for event lists because they don't have
discrete values on their axes.  But we could have a columns with a
list of UCDs of the columns of the dependent axes in the event list,
say.

Again apologies if all this misses the point.

        -- Markus