[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