DiscussionOnVOUnits < IVOA

IVOA Web>IvoaDataModel>UnitsDesc>DiscussionOnVOUnits (2014-10-27, NormanGray) (raw view)
<span style="color: orangered;">The VOUnits document is now an [[http://www.ivoa.net/documents/VOUnits/index.html][IVOA REC]]; please do not edit this page</span>

---+ Discussion on <nop>VOUnits

This page is created to discuss the [[http://wiki.ivoa.net/internal/IVOA/UnitsDesc/WD-VOUnits-1.0-20111216.pdf][VOUnits 1.0 document]], and to find a consensus on undecided issues, by listing pros and cons on each item. For each item on the page, various options are presented, and the community is encouraged to express opinions in order to reach a consensus, by appending your wikiname to the preferred option, and/or commenting.

See [[http://www.astro.gla.ac.uk/users/norman/ivoa/unity/][Unity library notes]].

---++ What is the goal of the 'new' VOUnits unit syntax?  

One possibility is that we should aim for a minimal grammar (in which case the CDS grammar is probably the most nearly minimal of the three), or a lenient but still well-defined one (in which case the FITS covers almost all bases, even though it's not a strict superset of the others).  I'd push for the latter: it's well-defined, but most nearly compatible with everyone, plus it's flexible enough that people don't have to try to memorise what is and isn't permitted (principle of least surprise).

In case you're interested, the only thing stopping the FITS grammar being a superset of the others is that the CDS and OGIP grammars both permit multiple solidi in an expression (=W/Hz/m**2=), and the FITS grammar doesn't (good for FITS!).

*Proposal:*  I think we should simply adopt the FITS specification, possibly after tidying it up by formalising the grammar.  At least, we should take this as a starting point, and aim to make minimal deltas to that. -- IVOA.NormanGray - 09 Jan 2012

Hm -- I've seen the VOUnits as a companion to the VOTable spec so
far, in the sense of "this is what you have to understand in the unit
attribute".  The typical use case is: you have two VOTables from two
different services; join them as good as you can.  Utypes are one part
of this, UCDs maybe another, but giving machines a chance to bring
together data in different units is probably the lowest hanging fruit.

So, parsing the things is only a start point; you need to do something
with the parse trees and with whatever is in the nodes of the tree.
Therefore, I'd say let's keep the number of things that can be in
there at the minimum absolutely necessary for what we're trying to do.
Every little decoration, every baroque variation, will somehow have to be reflected in lots of VOTable clients.

And the other side of the equation is: What for?  If people actually
fear moving their "old" unit strings to the "new" syntax is too much
work -- well, Norman's software probably covers 90% of what an automatic
translator could do (where I'd expect 95% is the best machines
could achieve given the mess that's lurking in the unit strings out
there in the wild).  -- IVOA.MarkusDemleitner 

I'm doing some work for ROE right now, looking at assigning UCDs to database schemas, and (opportunely) the unity library is helping here, by doing what Markus suggests, and spotting commonalities in unit dimensions.  I expect to add to that, and incorporate material from [[http://qudt.org][the QUDT units ontology]], in the near future.

As part of that, the process very quickly spots unit strings which don't parse, and it's very easy to include a lookup of mappings "mags per square Arcseconds" -> "mag/arcsec^2" which can be incorporated into files with quite manageable labour.

As to how to use the grammars, I certainly don't expect users to deal with parse trees.  The API documentation shows [[http://www.astro.gla.ac.uk/users/norman/ivoa/unity/javadocs/index.html][Java]] and [[http://www.astro.gla.ac.uk/users/norman/ivoa/unity/c-docs/html/index.html][C]] interfaces.  These are intended to free users from having to care much about the actual structure of the units.  In consequence, it doesn't much matter if we have a reasonably sophisticated units grammar: as long as it's well-enough defined that the library can parse it, the users don't have to care.  We can therefore go for a fairly big grammar (such as the FITS) one, on the grounds that this means that a larger fraction of what users _guess_ will work, will work in fact.
-- IVOA.NormanGray - 27 Jan 2012 

Addendum to that: on examination, it turns out that the FITS grammar isn't any more complicated than the others (all three are around 25 lines of YACC).  It ends up being a near-superset of the other two simply because it allow more alternatives, such as allowing both ** and ^ for exponentiation.  Whether you call that 'lenient' or 'flexible' is your own taste. -- IVOA.NormanGray - 28 Feb 2012 

---++ Possible outcomes
There appears to be a limited number of likely outcomes from this work (the following are in some cases only marginally different from each other):

   1. Use CDS (as VOTable does)
   2. Use FITS (in the form of the disambiguated grammar, rather than just the FITS specification's text)
   3. Allow any of the three grammars (FITS/OGIP/CDS), to avoid retrospective problems with VOTable, but declare that future IVOA standards should (in the RFC 2119 sense) use, say, FITS.
   4. Invent something new (does a disambiguated FITS grammar count as a new one?)
   5. Specify nothing, but publish the grammars for information.

Have I missed any options?

I suspect that in practice most implementers will be lenient in what they parse, whether they do it with a formal parser of a collection of regexps.

---++ Symbols

---+++ Electric resistance 
The IAU recommends to use the upper-case greek letter Omega, but this is not allowed with the adopted character set for VOUnits. OGIP uses ohm (lower-case o), while <nop>StdCats and FITS recommend Ohm (upper-case o).

The upper-case version seems more appropriate (refers to the name of Georg Simon Ohm).

Options for VOUnits :
   1. Accept both ohm and Ohm. pro: remains compatible with all current use. con: adds complexity to parsing.
   1. Only allow Ohm. pro: easier parsing. con: translation needed for OGIP (but is this unit really used in astronomy?). 

*Discussion:*

Only Ohm; we have too many ambiguities already, and I doubt anyone cares
enough to quarrel right now -- IVOA.MarkusDemleitner - 02 Jan 2012 


---+++ Micro-arcseconds
This is not yet widely used, but it will probably be the case
with future astrometric missions like GAIA.
We have arcsec, and mas (while IAU recommends nanoradians nrad). 
Options for VOUnits :
   1. Follow only IAU style: nrad, prad...
   1. uas
   1. uarcsec

*Discussion:*

uarcsec; there's a chance parsers can get by without a special case then.  mas is a lost case anyway -- IVOA.MarkusDemleitner - 02 Jan 2012 

---+++ Celsius
Do we keep a degC symbol?

*Discussion:*

---+++ Dropped deprecated symbols (Table 5)
Any objections to removing these from the standard ?
dyn, cal, bar, atm, Gal, eotvos, gamma, oersted

*Discussion:*

---+++ Other symbols (Table 6)
Is it OK to reuse the FITS 2010 notations? (FITS v3.0, section 4.3, W.D. Pence et al., A&amp;A 524, A42, 2010.   doi:10.1051/0004-6361/201015362)

*Discussion:* I think we should more-or-less adopt the FITS specification, clarified where appropriate, and adjusted where necessary. -- IVOA.NormanGray

---+++ More than one solidus

The FITS specification, and the draft VOUnit specification both say "The IAU style manual forbids the use of more than one slash (/) character in a units string. However, since normal mathematical precedence rules apply in this context, more than one slash may be used but is discouraged."  There's no way of expressing 'discouraged' in a grammar -- something either is a valid string or it isn't.  I suggest that the VOUnit grammar simply forbid multiple solidi.  -- IVOA.NormanGray - 20 Dec 2011 

*Discussion:*

---+++ Fractional powers and brackets

I wasn't able to deduce from the FITS spec whether m^1.5 was legal or not, because the power is not surrounded by brackets.  I think it's meant to be illegal (and the grammar in the Unity library reflects this), but the VOUnit spec should be more precise here.  I don't think it much matters which way we decide.  -- IVOA.NormanGray - 20 Dec 2011 

*Discussion:*

-----

---++ Special cases

---+++ Quantity with no unit

For example a character string or a dimensionless ratio.
We suggest to use an empty string. Other possibilities are
one or 3 dashes, or blanks.

*Discussion:*

I'd definitely go for an empty string; the only other interpretation
for an empty string could be a null value, and that's far less useful. -- IVOA.MarkusDemleitner - 02 Jan 2012

---+++ Percent
This means a factor 0.01, with no unit. Do we allow "%"?

*Discussion:*

---+++ Unknown unit
What to do when we know the unit is not known? 
   1. Use a question mark: ?
   1. Use an empty string
   1. Other notation?

*Discussion:*

Does this have to be specified in the VOUnit document?  I don't think so, and believe it can be a library matter.

I suggest we simply define three conformance levels: that a unit string is 'as recommended', 'is acceptable' (meaning that it uses only recognised but not necessarily recommended units), and 'is parseable' (meaning that it conforms to the grammar, but that there are either unrecognised units or units used in an disrecommended way, such as with inappropriate SI prefixes).  Since the document is defining a grammar rather than an API, it's not reasonable for it to define error behaviour. -- IVOA.NormanGray - 20 Dec 2011

Well, to me that's basically a NULL unit.  I'd go with Norman in
suggesting to communicate null values "out of band", i.e., by deferring
to the container format or an API.  If it turns out need in-band
signalling of this after all, I'd go for the question mark; I cannot see
this notation colliding with anything useful, and it's clear enough --
IVOA.MarkusDemleitner - 02 Jan 2012

-----

---++ Mathematic expressions

Any objections to following the FITS guidelines?

Regrets that VOUnits don't include trigonometric functions?

*Discussion:*

Is there any chance we can agree on one and only one notation for a
given operator?  I'd say, let's have one multiplication operator (my
order of preference: blank, asterisk, dot) and in particular one
exponentiation operator (** only if the * is not used for
multiplication, and I'd say joining the strings is out, at least if
"expr" (whatever that is) rather than exclusively an integer is allowed in the exponent) -- IVOA.MarkusDemleitner - 02 Jan 2012 

That depends on what the goal of the exercise is.  As above, I suggest simply adopting a cleaned-up FITS spec.

'expr' is only implicitly defined in the FITS spec, but [[http://www.astro.gla.ac.uk/users/norman/ivoa/unity/grammar/unity-fits.txt][I've taken it to be]]
<verbatim>
numeric_power:    INTEGER 
                | OPEN_P INTEGER CLOSE_P 
                | OPEN_P FLOAT CLOSE_P 
                | OPEN_P INTEGER DIVISION INTEGER CLOSE_P 
                ;
</verbatim>
...which seems reasonable.    -- IVOA.NormanGray - 09 Jan 2012
-----

---++ AOB ?








<br/>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->
Topic revision: r11 - 2014-10-27 - NormanGray
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema