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