[Semantics] Re: UCDs and arrays : histogram case

Mireille Louys mireille.louys at unistra.fr
Mon May 21 21:19:19 CEST 2018


Hi Markus, hi all,


Le 21/05/2018 à 14:31, Markus Demleitner a écrit :
> Hi Mireille,
>
> On Sun, May 20, 2018 at 10:15:47PM +0200, Mireille Louys wrote:
>> I did not succeed in visualising the table example you mentionned . I there
>> a special way to find it  via taphandle , and or topcat?
> Just enter the TAP service URL (or select "GAVO DC TAP" from the
> given list of services) in your client and execute the query
> -- did this not work for you?
Sorry , Markus. I first tried to look via Taphandle and gaiadr2 and lost 
my way.
The query example as you recommended in the RFM page works fine . Thanks
>> for the choice of the ucd label, I vote for "stat.histogram" , but I suppose
>> it makes sense to bind it to the measure it has been collecting .
> Certainly stat.histogram would need to admit declaring what has been
> aggregated.  However, I'm pretty sure stat.histogram still needs to
> be P.  Consider the existing term stat.error, which is P because an
> <error of X> is *not* somehow a subclass of <X> (contrary to, say,
> stat.max, which consequently already is Q).
>
> Analogously, a <histogram of X> is a different beast from <X>, and
> clients that, for instance, cut off trailing atoms to figure out
> roughly what something is would be completely mislead.
yes you are right , the context to interpret the aggregated measure is 
needed .
I had in mind we might want to trace the histogram of an error  ( very 
usual requirement)
then if stat.error and stat histogram are both P,  we cannot choose :

stat.error;phot.mag.V  is the error on a magnitude , and if I want to 
give the UCD label for the histogram of this quantity, I would like to have
stat.error;phot.mag.V;stat.histogram

One could even decide stat.histogram can only be suffix , because we 
will interprete the meaning of the aggregated measure first.

I agree it is tricky to put combination rule in this case .

What are the other use-cases where we would have to use stat.histogram 
for the content of a column? .
Tap 1.1 allows that but do we want to encourage multiple values inside a 
column ?
I assume if this would be generalized,  the risk to break the ucd 
labeling  consistency  is not null.

Many thanks for your feedback on this.
Mireille
> So, in the example, the UCD of the dist column should be
>
> stat.histogram;phot.mag.V
>
> (it's not yet, but based on your feedback I'll put it in soon as a
> prototype).
>
>         -- Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20180521/c27f3c55/attachment.html>


More information about the semantics mailing list