UCDs and arrays

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri May 4 19:40:49 CEST 2018


Dear Semantics,

I'm having more and more array-valued columns in my TAP service.
Examples include:

* photometry points from Gaia DR2 (see the gaia.dr2epochflux table on
  http://dc.g-vo.org/tap)
* the gavo_histogram aggregate function, again on http://dc.g-vo.org/tap 
  (cf.  capabilities there), which computes, well, a histogram over a
  column.

The question is: What should happen to the UCDs of such columns?  For
instance, in gaia.dr2epochflux, there are the columns rp_flux
(current UCD: phot.flux;em.opt.R -- yeah, we could quarrel whether
the R is a good choice here, but that's not my point now) and
rp_obs_time (current UCD: time.epoch).

I feel that's not quite right -- there's not *a* flux in rp_flux,
there's a *collection* of fluxes.  You could, of course, say that
clients can work out that it's a collection by inspecting the type,
and I'd not be disinclined to agree.  Does anyone disagree?  If you
disagree: What else should I put into the UCD attribute there?

The second case is, I think, even trickier.  Consider:

  with sample as (
    select top 200000 * 
    from gaia.dr2light where parallax is not null) 
  select gavo_histogram(round(parallax), 0, 200, 20) as hist
  from sample

I guess I *should* have some UCD on the hist column ("this is a
distribution or parallaxes").  I don't right now (there's no UCD at
all).  pos.parallax certainly would be wrong.

However, there's already stat.min and stat.max (which are required
secondary, which makes perfect sense, since a minimal parallax
still is a parallax), and there's stat.error (which is required
primary, which again makes sense since the error on a parallax isn't
a parallax).

Now, I wonder: Could we have a stat.distribution (or something like
this) atom that would be mandatory primary (since a distribution of
parallaxes really can't be interpreted as a parallax)?  Would anyone
support such a proposal?  Would anyone object to it?

        -- Markus





More information about the semantics mailing list