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

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Wed May 28 22:59:13 CEST 2025


Dear Colleagues,

On Wed, May 28, 2025 at 10:24:44PM +0200, BONNAREL FRANCOIS gmail via semantics wrote:
> A query with  a constraint such as "WHERE ivoa_smaller(dataproduct_subtype,https://www.ivoa.net/rdf/responsefunction_type#response-function")
> should validate for #psf, #lsf, #arf, etc....

Let me just mention that if there were such a response-function
vocabulary, you could already write

  WHERE 1=gavo_vocmatch(
    'response-function',   -- the vocabulary name
    'response-function',   -- the concept name
    dataproduct_subtype)   -- the column to match against

on http://dc.g-vo.org/tap (and other DaCHS services) and this would
be true for all terms narrower than that #response-function.  This
isn't actually hard to implement, so I'd be confident we could turn
this into ivo_vocmatch (i.e., an interoperable UDF) rather easily.

If you're looking for something to try it out, try:

SELECT TOP 5 * FROM ivoa.obscore
WHERE
  1=gavo_vocmatch('product-type', 'spectrally-resolved-dataset', dataproduct_type)

on http://dc.g-vo.org/tap.  Ahem. Right now, there's only #spectrum
coming back, but that's only because I'm not yet marking up the
califa cubes as spectral-cubes.  Which I'll do as soon as an obscore
WD is out that sanctions using product-type terms in the
dataproduct_type column.

Anyway, if we decide that we need the narrower terms, I think I'd
prefer to put them into dataproduct-type rather than create an extra
vocabulary.  That's mainly to keep the vocabulary ecosystem as small
as we can; in this new view on the response functions, these *are*
(perhaps somewhat odd) sorts of data products, after all.

Oh, and while I'm talking: Ian's post this morning my time about the
numbers of matches for Chandra's response functions does suggest we
may want the narrower terms (#irf and friends); on the other hand,
the 6'010 rows for #rmf is probably still too much for efficient
discovery and as such not a *tremendous* progress over the 104'740
you'd get for #response-function.

So... What would people do to pick the rmf they actually need from
the obscore result?  Or do they really need them all?  And wouldn't a
possible extra constraint cut down the #response-function result to a
reasonable size, too?

Thanks,

             Markus



More information about the heig mailing list