TWiki> IVOA Web>IvoaSemantics>VOUnitsRFC (revision 7)EditAttach

VOUnits 1.0 RFC

This is the RFC centre for the IVOA VOUnits 1.0 Proposed Recommendation.

The VOUnits document is intended to describe existing and recommended practice for writing units specifications in IVOA protocols:

  • Abstract: This document describes common practices in manipulating units in astronomical metadata and will define a means of consistent representation within VO services. The core of the document contains the rules for writing string representations of unit labels, called VOUnits.
Existing commentary:

Note on implementations: This document does not define a protocol, but summarises existing practice, and recommends good practice for future IVOA specification. In consequence, the existing software which parses units specifications (summarised in the document) can be regarded as 'implementations' of the document. In addition, the Unity library, which was written in part to validate some of the document's conclusions, can be regarded as an implementation of the standard.


Comments

Please follow roughly the following pattern:

Off-line comments (2012 August)

Norman Gray received some direct comments from Tim Jenness and Markus Demleitner. These were in part typo-level comments, but included some more significant points about the substance of the document. Many thanks to both.

  • Mismatch between table 8 and appendix A.4 (noted: to be fixed in next version)
  • Various style/readability points about included grammars (clarified)
  • Unclear discussion about what units are permitted/recommended/deprecated (included new summary table of unit recommendations)
  • Perhaps mention ISO-80000-13 and IEEE-1541 binary prefixes (kibi-, mibi-, etc) (noted, and text added to the document to confirm that we don't, and don't intend to, talk about these)
  • Discussion of candela vs centi-day and similar (noted, and text possibly clarified; not completely sure what to do here)
  • No discussion of records/arrays of units (noted, and text clarified)
-- NormanGray (2012-09-02)

Additional comments from Markus (2012-09-03)

  • We should at least consider allowing "modern-style" floats (2.2e19 rather than 2.2 10+19); it's still more ambiguity, but in this case it's probably helping a lot towards what people expect.
  • We definitely should allow float mantissas to have no dot at all, i.e., have them match [0-9]+(\.[0-9]*)?. It's the right thing mathematically, and it'll save a world of confusion.
-- MarkusDemleitner - 2012-09-03

Comments from Mark Taylor

Looks good. A couple of very minor things

  • comments on document status in "Status of this document" and "Acknowledgements" sections can probably be adjusted
  • "unit parameter" -> "unit attribute" in sec 1.1?
  • "problem of try to best accomodate" -> "problem of trying to best accommodate" in sec 3.6?
  • some problem with the accents in the BIPM reference in the bibliography
-- MarkTaylor - 2012-09-03


Comments from Matthew Graham / VAO (2012-10-01)

Generally there was a feeling that the language in the specification could be clearer on what the basis of this recommendation is, i.e., it's essentially the FITS units convention. Also:

  • There is no mechanism for identifying which units convention one might be using, especially this one - how can I distinguish between using FITS vs VOUnits in a data set. There should be some way of stating this.
  • A list of approved units is not present in the document. This is primarily for reference or quick lookup and could be included as an appendix, along with some examples of usage.
  • The information about the supporting services and libraries is buried in the document and could be more upfront.
  • What is the policy for existing data sets which use unit conventions that are not compliant with VOUnits?

Some more minor things:

  • Solidus and slash are both used to refer to "/"
  • How should electron (counts) be referred to, e.g., e-/ADU?
  • The units data model expresses relationships between certain units, e.g., degree -> arcmin -> arcsec. A conversion model then needs to be stated so that deg/pixel can be calculated given arcsec (as mentioned). This is not just millisec to sec which can be guessed from the prefix alone.
-- MatthewGraham - 2012-10-01

Response, response, response

[...]

One response (yyyy mm dd)

Response, response, response

[...]


Comments from TCG (WG and IG chairs)

TCG Chair & Vice Chair (Séverin Gaudet and Matthew Graham)

Applications (Mark Taylor and Pierre Fernique)

Data Access Layer (Patrick Dowler and Mike Fitzpatrick)

Data Model (Jesus Salgado and Omar Laurino)

Grid&Web Sevices (Andreas Wicenec and André Schaaff)

Registry (Gretchen Greene and Pierre Le Sidaner)

Semantics (Norman Gray and Mireille Louys)

VOEvent (Matthew Graham and John Swinbank)

Data Curation & Preservation IG (Alberto Accomazzi)

Knowledge Discovery in Databases IG (Giuseppe Longo)

Theory IG (Franck Le Petit and Rick Wagner)


Edit | Attach | Watch | Print version | History: r34 | r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r7 - 2012-10-01 - MatthewGraham
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback