SimpleDALRegExt and product-type

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri Sep 24 09:07:56 CEST 2021


Dear Registry, dear Semantics,

As VODataService takes the last hurdles to becoming a REC, there should
now be a bit brainpower left for the SimpleDALRegExt 1.2 RFC that's been
slumbering since March:
https://wiki.ivoa.net/twiki/bin/view/IVOA/SimpleDALRegExtV12RFC

The actual changes are rather minor, but there is one big stumbling
block: the new productType child for SSAP capabilities, which would have
sanctioned the (reasonably widespread) use of SSAP to publish time
series.  This, in turn, was built on a proposed vocabulary of product
types.  I had hoped that just re-using what Obscore already
prescribes with a few extensions might do the trick.

I had talked about that vocabulary
(http://www.ivoa.net/rdf/product-type) at the last Interop
(https://wiki.ivoa.net/internal/IVOA/InterOpMay2021Semantics/product-type.pdf)
and received quite a bit of pushback.  That at least in part was
justified: the strict distinction between relational and array data
probably doesn't have an actual use case, as at least users really don't
care whether, say, spectra are in FITS images (arrays) or FITS or
VOTable tables (relational data).  True, TOPCAT (as an example) can
open the latter but not the former, but that's probably not enough of
a justification for making such a fundamental distinction that would
tear the spectrum concept in two:  Quite clearly, people doing
spectra discovery will still want to see the data sets, even if they
can't open them with their current tool.  That's what we have SAMP
for.

Be that as it may: Clearly, product-type needs more thought and work.
Given that the various VEPs were a *lot* more work than I had hoped
they would be, I did not put that thought and work into product-type,
and for all I know nobody else did, either.

Hence, I believe we will not see a usable product-type vocabulary any
time soon, and with that, we could either add productType with a
custom (i.e., in-schema) constraint or just drop it.

My vote by now would be to drop it; while there as been some takeup, it
took a lot more nagging than I'd expect for something that'll go
anywhere, and enthusiasm on the side of the TDIG was very limited, too.

So: Does anyone want to come out strongly in favour if keeping
productType on SSAP capabilities?

If not, I'll drop it, publish another PR, and start nagging the other WG
chairs for reviews.

              -- Markus


More information about the registry mailing list