Difference: Dec2013VOUnitsRFC (1 vs. 18)

Revision 182014-05-17 - PierreLeSidaner

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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-20140513)

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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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, although their inputs are not compulsory.

Approved.

Applications WG (MarkTaylor, PierreFernique)

The Applications WG is pleased to recommend this carefully researched and well-written document for acceptance.

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)

Gratulations for this well written and very complete document.

Actually DAL protocols have little explicit dependency on the way units are written.

This is well stated in 1.1. Queries (PQL or ADQL) are made assuming consistency with some implicit unit rule defined in the protocols and responses are generally in VOTABLE or FITS where VOunit definitions can perfectly apply.

Other formats for responses or retrieval (native xml) could easilly be made consistent with the unit specification.

I personally recommend this specification for recommendation.

-- FrancoisBonnarel - 2014-04-28

Data Model WG (JesusSalgado, OmarLaurino)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).


Thanks for the clarification in the text. My main point was that I see clearly the benefict of the scaling factor (to have a more flexible definition of units). I do not consider so strong the disadvantages to have so relevant space in the text as are, in my view, minimal. I do not think there is something obscure using a scaling factor as if you are using it it will be, in 99% of the cases, because your units are not in the predefined list. After the clarification added in the text, it is clear that there is always some ambiguity when you use units (obviously greater if you need to use units not clearly defined in the spec) so it is OK for me.

As said, DM approves the document.

-- JesusSalgado - 2014-04-23

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

Added:
>
>
 The Grid and Web Services Working Group approves the document.

Registry WG (GretchenGreene, PierreLeSidaner)

Added:
>
>
The registry WG approves this version.
 

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)

The proposal answers to many needs about Units in the VO. It is quite comprehensive.

The Theory Interest Group approve the document as it is.

Time Domain IG (JohnSwinbank, MikeFitzpatrick)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 172014-05-17 - SeverinGaudet

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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.

Changed:
<
<
The most recent version is http://www.ivoa.net/documents/VOUnits/ (version 1.0-20140226)
>
>
The most recent version is http://www.ivoa.net/documents/VOUnits/ (version 1.0-20140513)
  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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments from TCG (WG and IG chairs)

Changed:
<
<
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.
>
>
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, although their inputs are not compulsory.
Added:
>
>
Approved.
 

Applications WG (MarkTaylor, PierreFernique)

The Applications WG is pleased to recommend this carefully researched and well-written document for acceptance.

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)

Gratulations for this well written and very complete document.

Actually DAL protocols have little explicit dependency on the way units are written.

This is well stated in 1.1. Queries (PQL or ADQL) are made assuming consistency with some implicit unit rule defined in the protocols and responses are generally in VOTABLE or FITS where VOunit definitions can perfectly apply.

Other formats for responses or retrieval (native xml) could easilly be made consistent with the unit specification.

I personally recommend this specification for recommendation.

-- FrancoisBonnarel - 2014-04-28

Data Model WG (JesusSalgado, OmarLaurino)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).


Thanks for the clarification in the text. My main point was that I see clearly the benefict of the scaling factor (to have a more flexible definition of units). I do not consider so strong the disadvantages to have so relevant space in the text as are, in my view, minimal. I do not think there is something obscure using a scaling factor as if you are using it it will be, in 99% of the cases, because your units are not in the predefined list. After the clarification added in the text, it is clear that there is always some ambiguity when you use units (obviously greater if you need to use units not clearly defined in the spec) so it is OK for me.

As said, DM approves the document.

-- JesusSalgado - 2014-04-23

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

The Grid and Web Services Working Group approves the document.

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)

The proposal answers to many needs about Units in the VO. It is quite comprehensive.

The Theory Interest Group approve the document as it is.

Time Domain IG (JohnSwinbank, MikeFitzpatrick)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 162014-05-11 - AndreSchaaff

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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.

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)

Gratulations for this well written and very complete document.

Changed:
<
<
Actually DAL protocols have little explicit dependency on the way units are written.
>
>
Actually DAL protocols have little explicit dependency on the way units are written.
  This is well stated in 1.1. Queries (PQL or ADQL) are made assuming consistency with some implicit unit rule defined in the protocols and responses are generally in VOTABLE or FITS where VOunit definitions can perfectly apply.

Other formats for responses or retrieval (native xml) could easilly be made consistent with the unit specification.

I personally recommend this specification for recommendation.

-- FrancoisBonnarel - 2014-04-28

Changed:
<
<
>
>
 

Data Model WG (JesusSalgado, OmarLaurino)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).

Changed:
<
<

>
>

  Thanks for the clarification in the text. My main point was that I see clearly the benefict of the scaling factor (to have a more flexible definition of units). I do not consider so strong the disadvantages to have so relevant space in the text as are, in my view, minimal. I do not think there is something obscure using a scaling factor as if you are using it it will be, in 99% of the cases, because your units are not in the predefined list. After the clarification added in the text, it is clear that there is always some ambiguity when you use units (obviously greater if you need to use units not clearly defined in the spec) so it is OK for me.

As said, DM approves the document.

-- JesusSalgado - 2014-04-23

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

Added:
>
>
The Grid and Web Services Working Group approves the document.
 

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)

The proposal answers to many needs about Units in the VO. It is quite comprehensive.

The Theory Interest Group approve the document as it is.

Time Domain IG (JohnSwinbank, MikeFitzpatrick)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 152014-04-28 - FrancoisBonnarel

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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.

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)

Added:
>
>
Gratulations for this well written and very complete document.

Actually DAL protocols have little explicit dependency on the way units are written.

This is well stated in 1.1. Queries (PQL or ADQL) are made assuming consistency with some implicit unit rule defined in the protocols and responses are generally in VOTABLE or FITS where VOunit definitions can perfectly apply.

Other formats for responses or retrieval (native xml) could easilly be made consistent with the unit specification.

I personally recommend this specification for recommendation.

-- FrancoisBonnarel - 2014-04-28

 

Data Model WG (JesusSalgado, OmarLaurino)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).


Thanks for the clarification in the text. My main point was that I see clearly the benefict of the scaling factor (to have a more flexible definition of units). I do not consider so strong the disadvantages to have so relevant space in the text as are, in my view, minimal. I do not think there is something obscure using a scaling factor as if you are using it it will be, in 99% of the cases, because your units are not in the predefined list. After the clarification added in the text, it is clear that there is always some ambiguity when you use units (obviously greater if you need to use units not clearly defined in the spec) so it is OK for me.

As said, DM approves the document.

-- JesusSalgado - 2014-04-23

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)

The proposal answers to many needs about Units in the VO. It is quite comprehensive.

The Theory Interest Group approve the document as it is.

Time Domain IG (JohnSwinbank, MikeFitzpatrick)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 142014-04-23 - JesusSalgado

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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.

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)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).

Added:
>
>

Thanks for the clarification in the text. My main point was that I see clearly the benefict of the scaling factor (to have a more flexible definition of units). I do not consider so strong the disadvantages to have so relevant space in the text as are, in my view, minimal. I do not think there is something obscure using a scaling factor as if you are using it it will be, in 99% of the cases, because your units are not in the predefined list. After the clarification added in the text, it is clear that there is always some ambiguity when you use units (obviously greater if you need to use units not clearly defined in the spec) so it is OK for me.

As said, DM approves the document.

-- JesusSalgado - 2014-04-23

 

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)

Changed:
<
<
The proposal answers to many needs about Units in the VO. It is quite comprehensive.
>
>
The proposal answers to many needs about Units in the VO. It is quite comprehensive.
 
Changed:
<
<
The Theory Interest Group approve the document as it is.
>
>
The Theory Interest Group approve the document as it is.
 

Time Domain IG (JohnSwinbank, MikeFitzpatrick)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 132014-04-17 - FranckLePetit

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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.

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)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Changed:
<
<
Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).
>
>
Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).
 

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)

Added:
>
>
The proposal answers to many needs about Units in the VO. It is quite comprehensive.

The Theory Interest Group approve the document as it is.

 

Time Domain IG (JohnSwinbank, MikeFitzpatrick)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 122014-04-11 - NormanGray

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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.

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)

The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.

However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:

"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)? e.g. solMass 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

Added:
>
>
Thanks for these observations, Jesus. There are indeed many subtleties involved in this, and this general question was discussed at some length (on the semantics list, only) without coming to a clear conclusion. Our intention as authors was to avoid the question (in fact the multiple questions) 'what does jupMass mean?' because, as you illustrate, it's a complicated question. Instead, we decided to focus purely on the unit-string syntax, requiring such semantic subtleties to be communicated through some other channel. The prompt for that discussion was whether 'unknown' units should be completely forbidden, on the grounds that they could all in principle be substituted by a scalefactor+'known unit'; we decided that was going too far. Is there a particular point we should clarify? I take the point about this not being just about jupiter masses: I've adjusted the text to try to make this clearer (cf repo).
 

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)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 112014-03-31 - JesusSalgado

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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.

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)

Changed:
<
<
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.
>
>
The inclusion of section: "2.10 The numeric scale factor", opens a door to many different use cases. I would have preferred to split units as scaling factor and base units (equivalent to a dimensional equation) 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. Also, there are some libraries to parse units strings.
 
Changed:
<
<
However, it is not clear for me the need of so many warnings about the use of the scaling.
>
>
However, it is not clear to me the need of so many warnings about the use of the scaling. As said in the text:
  "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."
Changed:
<
<
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.
>
>
Why does this affect only to the example (jupiterMass)? e.g. solMass 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)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 102014-03-31 - JesusSalgado

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 92014-03-14 - MarkTaylor

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

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-09

Comments 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)

Added:
>
>
The Applications WG is pleased to recommend this carefully researched and well-written document for acceptance.

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)

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)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 82014-03-09 - MireilleLouys

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

The VOUnits Proposed Recommendation is now in its TCG review period.

Changed:
<
<
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 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)
Changed:
<
<
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 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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.
Added:
>
>
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.
 
Deleted:
<
<
The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.
 We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

All previous versions are available on the IVOA documents page.

#All WG Review

Changed:
<
<

Comments

>
>

Comments from the VO community

 
Added:
>
>
* version 1.0-20131224:
 RFC and similar comments mostly received on-list.
Added:
>
>
* 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-09

 

Comments from TCG (WG and IG chairs)

Changed:
<
<
WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard.
>
>
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.
Deleted:
<
<
IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.
 

Applications WG (MarkTaylor, PierreFernique)

Data Access Layer WG (PatrickDowler, FrancoisBonnarel)

Data Model WG (JesusSalgado, OmarLaurino)

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)

Deleted:
<
<
 
<--  
-->
Deleted:
<
<
 
Changed:
<
<
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"
>
>
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="h" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"
 

Revision 72014-03-06 - NormanGray

 
META TOPICPARENT name="VOUnitsRFC"
Changed:
<
<

VOUnits 1.0 RFC: 2014 January 7 to 2014 February 4

>
>

VOUnits 1.0 TCG Review: 2014 March 1 to 2014 March 31

 
Added:
>
>
The 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)

Changed:
<
<
The differences between version 1.0-20131224 and 1.0-20140226 are minor wording and layout changes. There are a few further very minor changes which can be found in the repository version, and which will be included in the next published release (after TCG review).
>
>
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

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.

The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

Changed:
<
<
Comments from all working groups members are welcome. Comments should be on this page; discussion should be on the semantics@ivoa.net list.
>
>
All previous versions are available on the IVOA documents page.
 
Deleted:
<
<
For comparison, and as a reminder, all comments from the previous iteration are available on the former VOUnitsRFC page. The previous PR document was 1.0-20130724 (there was also a distributed version PR-1.0.20130922, and an intermediate Working Group draft, 1.0-20131025, which is attached to this page). All previous versions are available on the IVOA documents page.
 #All WG Review

Comments

Added:
>
>
RFC and similar comments mostly received on-list.

Comments 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)

Data Access Layer WG (PatrickDowler, FrancoisBonnarel)

Data Model WG (JesusSalgado, OmarLaurino)

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)

Deleted:
<
<

Comments from TCG (WG and IG chairs)

 
<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 62014-03-05 - NormanGray

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 RFC: 2014 January 7 to 2014 February 4

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.

Changed:
<
<
The new version is http://www.ivoa.net/documents/VOUnits/20131224/
>
>
The most recent version is http://www.ivoa.net/documents/VOUnits/ (version 1.0-20140226)
 
Changed:
<
<
The main visible changes in the new version are
>
>
The differences between version 1.0-20131224 and 1.0-20140226 are minor wording and layout changes. There are a few further very minor changes which can be found in the repository version, and which will be included in the next published release (after TCG review).
 
Added:
>
>
The main visible changes in version 1.0-20131224 are
 
  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.

The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

Comments from all working groups members are welcome. Comments should be on this page; discussion should be on the semantics@ivoa.net list.

For comparison, and as a reminder, all comments from the previous iteration are available on the former VOUnitsRFC page. The previous PR document was 1.0-20130724 (there was also a distributed version PR-1.0.20130922, and an intermediate Working Group draft, 1.0-20131025, which is attached to this page). All previous versions are available on the IVOA documents page.

#All WG Review

Comments

Applications WG (MarkTaylor, PierreFernique)

Data Access Layer WG (PatrickDowler, FrancoisBonnarel)

Data Model WG (JesusSalgado, OmarLaurino)

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

Registry WG (GretchenGreene, PierreLeSidaner)

Semantics WG (NormanGray, MireilleLouys)

Added:
>
>
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)

Comments from TCG (WG and IG chairs)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 52014-01-07 - SarahEmeryBunn

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 RFC: 2014 January 7 to 2014 February 4

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 new version is http://www.ivoa.net/documents/VOUnits/20131224/

The main visible changes in the new version are

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various textual clarifications to the document.

The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changes are reported in Appendix D of the new version of this proposed recommendation, available below.

Comments from all working groups members are welcome. Comments should be on this page; discussion should be on the semantics@ivoa.net list.

For comparison, and as a reminder, all comments from the previous iteration are available on the former VOUnitsRFC page. The previous PR document was 1.0-20130724 (there was also a distributed version PR-1.0.20130922, and an intermediate Working Group draft, 1.0-20131025, which is attached to this page). All previous versions are available on the IVOA documents page.

#All WG Review

Comments

Applications WG (MarkTaylor, PierreFernique)

Data Access Layer WG (PatrickDowler, FrancoisBonnarel)

Data Model WG (JesusSalgado, OmarLaurino)

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

Registry WG (GretchenGreene, PierreLeSidaner)

Semantics WG (NormanGray, MireilleLouys)

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)

Comments from TCG (WG and IG chairs)

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"
Deleted:
<
<
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131224.pdf" attr="" comment="PR 1.0-20131224" date="1387909774" name="PR-VOUnits-1.0-20131224.pdf" path="PR-VOUnits-1.0-20131224.pdf" size="966859" user="NormanGray" version="1"
 

Revision 42014-01-07 - NormanGray

 
META TOPICPARENT name="VOUnitsRFC"
Changed:
<
<

VOUnits 1.0 RFC - EXTENSION 2013 December 24 -- 2014 January 31 (dates TBC)

>
>

VOUnits 1.0 RFC: 2014 January 7 to 2014 February 4

 
Changed:
<
<
The last VOUnits RFC implied a small collection of document and implementation changes which, it turned out, were 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 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.
 
Added:
>
>
The new version is http://www.ivoa.net/documents/VOUnits/20131224/
 The main visible changes in the new version are

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
Changed:
<
<
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA
>
>
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA; this is explicitly permitted by the standard, though a parser should make available the information that the function is not a recognised one
 
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
Changed:
<
<
  • various document clarifications
>
>
  • various textual clarifications to the document.
  The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

Changed:
<
<
Changes are reported in the appendix Update sections of the new version of this proposed recommendation, available below.
>
>
Changes are reported in Appendix D of the new version of this proposed recommendation, available below.
 
Changed:
<
<
Comments from all working groups members are welcome. The review will run for (a little more than) four weeks, to 2014 January 31.
>
>
Comments from all working groups members are welcome. Comments should be on this page; discussion should be on the semantics@ivoa.net list.
 
Changed:
<
<
For comparison and reminder, all comments from the previous iteration are available on the former VOUnitsRFC page.
>
>
For comparison, and as a reminder, all comments from the previous iteration are available on the former VOUnitsRFC page. The previous PR document was 1.0-20130724 (there was also a distributed version PR-1.0.20130922, and an intermediate Working Group draft, 1.0-20131025, which is attached to this page). All previous versions are available on the IVOA documents page.
  #All WG Review

Comments

Applications WG (MarkTaylor, PierreFernique)

Data Access Layer WG (PatrickDowler, FrancoisBonnarel)

Data Model WG (JesusSalgado, OmarLaurino)

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

Registry WG (GretchenGreene, PierreLeSidaner)

Semantics WG (NormanGray, MireilleLouys)

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)

Comments from TCG (WG and IG chairs)

<--  
-->
Deleted:
<
<
 
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131224.pdf" attr="" comment="PR 1.0-20131224" date="1387909774" name="PR-VOUnits-1.0-20131224.pdf" path="PR-VOUnits-1.0-20131224.pdf" size="966859" user="NormanGray" version="1"

Revision 32013-12-24 - NormanGray

 
META TOPICPARENT name="VOUnitsRFC"
Changed:
<
<

VOUnits 1.0 RFC - EXTENSION 12/10/2013 --- 01/10/2014

>
>

VOUnits 1.0 RFC - EXTENSION 2013 December 24 -- 2014 January 31 (dates TBC)

 
Changed:
<
<
Due to implementation requirements the previous PR document : VOUnits 1.0-20130724 and the associated grammar supporting the specification have been updated .
>
>
The last VOUnits RFC implied a small collection of document and implementation changes which, it turned out, were 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.
 
Added:
>
>
The main visible changes in the new version are

  • the appearance of 'quoted units', thus permitting for example km/'martianDay' (see the document for discussion; this was the principal syntactic change which ended up necessitating the new version)
  • recognition for unknown functions, so that for example dBA(ct/s) includes an unknown function dBA
  • the appearance of binary prefixes (Ki, Mi, ...) on certain units
  • more explicit statements that the indication that units are unknown is the special string unknown, and that the indication that a quantity is dimensionless is that the units string is the empty string
  • various document clarifications

The editors believe we have accommodated or acknowledged each of the concerns on the original RFC page, either in the document or on that page. Please feel free to disagree.

We do not believe these are deep changes in principle, so those WG chairs who were happy with the document in its previous incarnation may not need to examine it too closely this time.

 Changes are reported in the appendix Update sections of the new version of this proposed recommendation, available below.
Changed:
<
<
Comments from all working groups members are welcome. The review will run for four weeks, from December 10th 2013.
>
>
Comments from all working groups members are welcome. The review will run for (a little more than) four weeks, to 2014 January 31.
 
Changed:
<
<
For comparison and reminder all comments from the previous iteration are available on the former VOUnitsRFC page.
>
>
For comparison and reminder, all comments from the previous iteration are available on the former VOUnitsRFC page.
  #All WG Review

Comments

Added:
>
>

Applications WG (MarkTaylor, PierreFernique)

Data Access Layer WG (PatrickDowler, FrancoisBonnarel)

Data Model WG (JesusSalgado, OmarLaurino)

Grid and Web Sevices WG (AndreSchaaff, AndreasWicenec)

Registry WG (GretchenGreene, PierreLeSidaner)

Semantics WG (NormanGray, MireilleLouys)

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)

 

Comments from TCG (WG and IG chairs)

<--  
-->
Added:
>
>
 
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"
Added:
>
>
META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131224.pdf" attr="" comment="PR 1.0-20131224" date="1387909774" name="PR-VOUnits-1.0-20131224.pdf" path="PR-VOUnits-1.0-20131224.pdf" size="966859" user="NormanGray" version="1"
 

Revision 22013-12-10 - MireilleLouys

 
META TOPICPARENT name="VOUnitsRFC"
Changed:
<
<

VOUnits 1.0 RFC - EXTENSION

>
>

VOUnits 1.0 RFC - EXTENSION 12/10/2013 --- 01/10/2014

 
Changed:
<
<
Due to implementation requirements the previous PR document : VOUnits 1.0-20130724 and the associated grammar supporting the specification have been updated .
>
>
Due to implementation requirements the previous PR document : VOUnits 1.0-20130724 and the associated grammar supporting the specification have been updated .
 
Changed:
<
<
Changes are reported in the appendix Update sections of the new version of this proposed recommendation.
>
>
Changes are reported in the appendix Update sections of the new version of this proposed recommendation, available below.
 
Changed:
<
<
Comments from all working groups are welcome. The review will run for four weeks, from December 5th 2013.
>
>
Comments from all working groups members are welcome. The review will run for four weeks, from December 10th 2013.
 
Changed:
<
<
Please check the changes and previous comments made during the former RFC period and available on VOUnitsRFC page.
>
>
For comparison and reminder all comments from the previous iteration are available on the former VOUnitsRFC page.
Added:
>
>
#All WG Review

Comments

Comments from TCG (WG and IG chairs)

 
<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"

Revision 12013-12-05 - MireilleLouys

 
META TOPICPARENT name="VOUnitsRFC"

VOUnits 1.0 RFC - EXTENSION

Due to implementation requirements the previous PR document : VOUnits 1.0-20130724 and the associated grammar supporting the specification have been updated .

Changes are reported in the appendix Update sections of the new version of this proposed recommendation.

Comments from all working groups are welcome. The review will run for four weeks, from December 5th 2013.

Please check the changes and previous comments made during the former RFC period and available on VOUnitsRFC page.

<--  
-->

META FILEATTACHMENT attachment="PR-VOUnits-1.0-20131025.pdf" attr="" comment="Recommendation for Units strings in the virtual Observatory -UPDATE" date="1386262412" name="PR-VOUnits-1.0-20131025.pdf" path="PR-VOUnits-1.0-20131025.pdf" size="963511" user="MireilleLouys" version="1"
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback