<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I tend to say that stat.distribution would be a better option than stat.probability or stat.likelihood. <div class=""><br class=""></div><div class="">Markus, please send a request to the UCD working group, as described here: <a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaSemantics#UCD_list_update" class="">http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaSemantics#UCD_list_update</a></div><div class="">(it will be good opportunity to check the process… :-)</div><div class=""><br class=""></div><div class="">Baptiste</div><div class=""><br class=""><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 7 mai 2018 à 10:17, Frederic V. Hessman <<a href="mailto:hessman@astro.physik.uni-goettingen.de" class="">hessman@astro.physik.uni-goettingen.de</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">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.<br class=""><br class="">Rick<br class=""><br class=""><blockquote type="cite" class="">On 4 May 2018, at 19:40, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br class=""><br class="">Dear Semantics,<br class=""><br class="">I'm having more and more array-valued columns in my TAP service.<br class="">Examples include:<br class=""><br class="">* photometry points from Gaia DR2 (see the gaia.dr2epochflux table on<br class=""> <a href="http://dc.g-vo.org/tap" class="">http://dc.g-vo.org/tap</a>)<br class="">* the gavo_histogram aggregate function, again on <a href="http://dc.g-vo.org/tap" class="">http://dc.g-vo.org/tap</a> <br class=""> (cf. capabilities there), which computes, well, a histogram over a<br class=""> column.<br class=""><br class="">The question is: What should happen to the UCDs of such columns? For<br class="">instance, in gaia.dr2epochflux, there are the columns rp_flux<br class="">(current UCD: phot.flux;em.opt.R -- yeah, we could quarrel whether<br class="">the R is a good choice here, but that's not my point now) and<br class="">rp_obs_time (current UCD: time.epoch).<br class=""><br class="">I feel that's not quite right -- there's not *a* flux in rp_flux,<br class="">there's a *collection* of fluxes. You could, of course, say that<br class="">clients can work out that it's a collection by inspecting the type,<br class="">and I'd not be disinclined to agree. Does anyone disagree? If you<br class="">disagree: What else should I put into the UCD attribute there?<br class=""><br class="">The second case is, I think, even trickier. Consider:<br class=""><br class=""> with sample as (<br class=""> select top 200000 * <br class=""> from gaia.dr2light where parallax is not null) <br class=""> select gavo_histogram(round(parallax), 0, 200, 20) as hist<br class=""> from sample<br class=""><br class="">I guess I *should* have some UCD on the hist column ("this is a<br class="">distribution or parallaxes"). I don't right now (there's no UCD at<br class="">all). pos.parallax certainly would be wrong.<br class=""><br class="">However, there's already stat.min and stat.max (which are required<br class="">secondary, which makes perfect sense, since a minimal parallax<br class="">still is a parallax), and there's stat.error (which is required<br class="">primary, which again makes sense since the error on a parallax isn't<br class="">a parallax).<br class=""><br class="">Now, I wonder: Could we have a stat.distribution (or something like<br class="">this) atom that would be mandatory primary (since a distribution of<br class="">parallaxes really can't be interpreted as a parallax)? Would anyone<br class="">support such a proposal? Would anyone object to it?<br class=""><br class=""> -- Markus<br class=""><br class=""><br class=""><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>