VOUnits RFC

[Marco Molinaro]

Hi Norman,
hi all,
thanks for the re-explanation & use-cases + alternatives to address them.

My preference goes for alt.(2) but I think we need a solution to get
MyWeight in both a machine- and human-readable form to be understood at
client level.
I suppose that the variability/calibration issue from Rob and the Arnold's
which-MyWeight and courtesy-units definition can be solved if we find it.

For example, in VOTable, using the LINK with a VO-Units specific
content-role, we can allow data publishers set a unit="myUnit" in
FIELDs/PARAMs/INFOs with direct LINK expanding the non standard unit. Best
practices or normative ways to state what response a call to this LINK
should have can find place in the VO-Units spec or somewhere else. I don't
go into more details because this is only one possible solution. I'm sure
there are other solutions to address this ["variable"-userdef-nonStd
myUnit] drawback of option 2.

I'm troubled however such a solution may rise more concerns:
- VOTable units no more only CDSunits (but non standard units will break it
anyway)
- flooding of custom units that are not easily contained by best practices
(please use custom units only if strictly necessary...will it work?)
- maintenance of the LINK (or other solution) support to custom units (but,
if I decide for a custom units I think I'm requested to maintain its
definition if I want my data to be understood)

Cheers,
    Marco




2013/7/29 Arnold Rots <arots at cfa.harvard.edu>

> I was pondering this question from its flipside:
> If Norman introduces MyWeight, how does the user know what value
> Norman actually used?
> Some canonical value? his preferred weight? his weight of the day?
> Is that value (whatever it is) published anywhere?
> The tropical year is another example.
>
> I shudder a bit when I imagine the confusion that may arise.
> Nevertheless, I agree that option 2 is probably the lesser of many evils
> - though it would be good if authors would have a mechanism to define
> their cutesy units.
>
>   - Arnold
>
>
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray
> Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496
> 7701
> 60 Garden Street, MS 67                                      fax:  +1 617
> 495 7356
> Cambridge, MA 02138
> arots at cfa.harvard.edu
> USA
> http://hea-www.harvard.edu/~arots/
>
> --------------------------------------------------------------------------------------------------------------
>
>
>
> On Mon, Jul 29, 2013 at 4:38 PM, Rob Seaman <seaman at noao.edu> wrote:
>
>> Hi Norman,
>>
>> I must admit to not having had the chance yet to review the current
>> version of the document, so perhaps this is addressed.
>>
>> > I think 2 is a problem, but I don't think it's a bad problem.  That is,
>> I more and more confidently agree with Rick in his message of this morning,
>> that you've lost meaning that might be important down the line, if you lose
>> the link between this unit and the mass of jupiter.  OK, there's a problem
>> if the receiver doesn't recognise 'jupMass', but there are mitigation
>> strategies (some listed by Rick), one of which is to look at the
>> documentation, and discover "ah, _this_ exoplanet database recognises the
>> non-standard unit 'jupMass', so I can use that in my requests to it".
>>
>> A more fundamental issue is that often measurements are calibrated in
>> terms of other measurements.  Quoting something as 1.5 jupMass might not
>> just be a handy way to provide a sense of scale, but it might be that as
>> measurements are refined of what the mass of Jupiter actually is, that the
>> number quoted (in the table or what have you) ought be adjusted to suit.
>>  Examples abound such as the Hubble constant, etc.
>>
>> Rob
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20130730/e78c0978/attachment.html>