UCDs and arrays

[Frederic V. Hessman]

In a pinch one could use stat.likelihood (stat.distribution would be sort of the same), especially since one already has stat.probability (which I would use over stat.likelihood for simple single probabilities), but a stat.distribution would be a much cleaner solution.

Rick

> On 4 May 2018, at 19:40, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> 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
> 
> 
>