VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31The VOUnits Proposed Recommendation is now in its TCG review period. The last VOUnits RFC implied a small collection of document and implementation changes which, it turned out, had consequences more far-reaching than was immediately apparent. As well, some new participants appeared in the discussion at this point. The result is a set of document and syntax changes which, it has been decided, are substantial enough to warrant a new RFC. The most recent version is http://www.ivoa.net/documents/VOUnits/ (version 1.0-20140226) The differences between version 1.0-20131224 and 1.0-20140226 are minor wording and layout changes. There are a few subsequent typo-level changes which can be found in the repository version, and which will be included in the next published release (after TCG review). The main visible changes in version 1.0-20131224 are
Comments from the VO community* version 1.0-20131224: RFC and similar comments mostly received on-list. * version 1.0-20140226: Typos and synchronisation of tables and text pointed by B. Hanisch. Changes and corrections available at : https://code.google.com/p/volute/source/browse/trunk/projects/std-vounits/VOUnits.tex -- MireilleLouys - 2014-03-09Comments from TCG (WG and IG chairs)WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.Applications WG (MarkTaylor, PierreFernique)The Applications WG is pleased to recommend this carefully researched and well-written document for acceptance. | ||||||||
Changed: | ||||||||
< < | One minor point: Table 15, unlike the other tables in Appendix B, lacks a VOUnits column. Should it have one? | |||||||
> > | One minor point: Table 15, unlike the other tables in Appendix B, lacks a VOUnits column. Should it have one? | |||||||
-- MarkTaylor - 2014-03-14
Data Access Layer WG (PatrickDowler, FrancoisBonnarel)Data Model WG (JesusSalgado, OmarLaurino) | ||||||||
Added: | ||||||||
> > |
The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have prefered to split units as numerical and base units as two elements in a DM (so the software does not need to parse strings) but, including this section, the spec is a lot more useful, in my view, than previous version.
However, it is not clear for me the need of so many warnings about the use of the scaling.
"The advantage of doing so is that the data consumer can translate the column data into well-known physical units without further information, and the data source is thus self-contained. The disadvantage of doing so is (i) that the intention might be obscured (this is a type of provenance information); and (ii) that the measurements may be relative to the actual jupiter mass rather than merely expressed in those terms, so that they should change if the actual mass were to be refined as a result of a recalibration." Why does this affect only to the example (jupiterMass)?... solarMass is also an accepted unit and it is not clear if this is the current Solar Mass or after "recalibration". Another accepted unit is Crab, that it is time varying (and it also depends on the spectral coordinate) so we could ask if the data provider is using Crab as the Crab emission at the time of creating the measurement or now. And, using which calibration for the Crab emission? Similar arguments can be done to many of the accepted units. As we are accepting scale factors, it would be simpler to say: "Data consumer can translate the column data into well-known physical units without further information and the data source is thus self-contained" or, but this is cumbersome, we should add similar warnings on the rest of "problematic" accepted units. Apart from this and as I said to previous version, the document is well written and clear. I approve it. -- JesusSalgado - 2014-03-31 | |||||||
Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)Registry WG (GretchenGreene, PierreLeSidaner)Semantics WG (NormanGray, MireilleLouys)The Semantics WG approves this version.Data Curation & Preservation IG (AlbertoAccomazzi, FrancoiseGenova)Education IG (MassimoRamella, SudhanshuBarway)Knowledge Discovery in Databases IG (GeorgeDjorgovski)Theory IG (FranckLePetit, RickWagner)Time Domain IG (JohnSwinbank, MikeFitzpatrick)<--
|