SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: | ||||||||
Changed: | ||||||||
< < | http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf | |||||||
> > | http://wiki.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf | |||||||
Review period: 2009 July 21 – 2009 September 15 (Extended!)
July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. Editors' input:Sentence removed and overall paragraph refurbished slightly. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. Editors' input:The research was certainly done. One of the authors, Marie Lise Dubernet, did an extensive survey of relevant standards within the community of Atomic and Molecular Physics, and several of the authors did meet relevant parties on the fields where discussions were celebrated. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. Editors' input:Note taken I approve the document as it stands. -- TomMcGlynn October 8, 2010Data Access LayerIn Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above Editors' input:Example modified to match properly Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. Editors' input:Appendix A exists but it lost its "Heading 1" type, therefore was lost in the TOC. References to the Appendices have been reviewed, and all corrected (as well as anchor links to relevant places within the doc). For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. Editors' input:Links modified to point to the version specified within the reference. Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). Editors' input:Corrected -- PatrickDowler October 14, 2010 Small issues: The text on p 10 (under the IVOA architecture diagram) mentions SpectrumDM when I think it is intended to be SSLDM. The document does not explicitly say this, but I assume that the subsection headings in 3 are (parts of) utypes (and data types) for SSLDM. This is at least implied by the structure of the headings. In some cases one would have to infer the utype where a higher level construct re-uses another. For example, Line.initialLevel is a Level, Level.energy is a PhysicalQuantity and PhysicalQuantity.value is numeric, which implies a utype of Line.initialLevel.energy.value. Is that correct? Should the connection to utypes be stated somewhere, eg at the start of Section 3? Approved -- PatrickDowler October 15, 2010Data ModelingMinor comments:
Grid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistryI approve this document. Thanks for the changes and my deepest regrets for the long delay. -- RayPlante - 03 Nov 2010SemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageI approve this document -- PedroOsuna 15 Oct 2010VOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryApproved. HerveWozniak - 18 October 2010TCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. Editors' input:Sentence removed and overall paragraph refurbished slightly. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. Editors' input:The research was certainly done. One of the authors, Marie Lise Dubernet, did an extensive survey of relevant standards within the community of Atomic and Molecular Physics, and several of the authors did meet relevant parties on the fields where discussions were celebrated. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. Editors' input:Note taken I approve the document as it stands. -- TomMcGlynn October 8, 2010Data Access LayerIn Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above Editors' input:Example modified to match properly Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. Editors' input:Appendix A exists but it lost its "Heading 1" type, therefore was lost in the TOC. References to the Appendices have been reviewed, and all corrected (as well as anchor links to relevant places within the doc). For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. Editors' input:Links modified to point to the version specified within the reference. Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). Editors' input:Corrected -- PatrickDowler October 14, 2010 Small issues: The text on p 10 (under the IVOA architecture diagram) mentions SpectrumDM when I think it is intended to be SSLDM. The document does not explicitly say this, but I assume that the subsection headings in 3 are (parts of) utypes (and data types) for SSLDM. This is at least implied by the structure of the headings. In some cases one would have to infer the utype where a higher level construct re-uses another. For example, Line.initialLevel is a Level, Level.energy is a PhysicalQuantity and PhysicalQuantity.value is numeric, which implies a utype of Line.initialLevel.energy.value. Is that correct? Should the connection to utypes be stated somewhere, eg at the start of Section 3? Approved -- PatrickDowler October 15, 2010Data ModelingMinor comments:
Grid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource Registry | ||||||||
Added: | ||||||||
> > | I approve this document. Thanks for the changes and my deepest regrets for the long delay. -- RayPlante - 03 Nov 2010 | |||||||
SemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageI approve this document -- PedroOsuna 15 Oct 2010VOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryApproved. HerveWozniak - 18 October 2010TCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. Editors' input:Sentence removed and overall paragraph refurbished slightly. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. Editors' input:The research was certainly done. One of the authors, Marie Lise Dubernet, did an extensive survey of relevant standards within the community of Atomic and Molecular Physics, and several of the authors did meet relevant parties on the fields where discussions were celebrated. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. Editors' input:Note taken I approve the document as it stands. -- TomMcGlynn October 8, 2010Data Access LayerIn Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above Editors' input:Example modified to match properly Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. Editors' input:Appendix A exists but it lost its "Heading 1" type, therefore was lost in the TOC. References to the Appendices have been reviewed, and all corrected (as well as anchor links to relevant places within the doc). For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. Editors' input:Links modified to point to the version specified within the reference. Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). Editors' input:Corrected -- PatrickDowler October 14, 2010 Small issues: The text on p 10 (under the IVOA architecture diagram) mentions SpectrumDM when I think it is intended to be SSLDM. The document does not explicitly say this, but I assume that the subsection headings in 3 are (parts of) utypes (and data types) for SSLDM. This is at least implied by the structure of the headings. In some cases one would have to infer the utype where a higher level construct re-uses another. For example, Line.initialLevel is a Level, Level.energy is a PhysicalQuantity and PhysicalQuantity.value is numeric, which implies a utype of Line.initialLevel.energy.value. Is that correct? Should the connection to utypes be stated somewhere, eg at the start of Section 3? Approved -- PatrickDowler October 15, 2010Data ModelingMinor comments:
Grid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageI approve this document -- PedroOsuna 15 Oct 2010VOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010Theory | ||||||||
Added: | ||||||||
> > | Approved. HerveWozniak - 18 October 2010 | |||||||
TCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. Editors' input:Sentence removed and overall paragraph refurbished slightly. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. Editors' input:The research was certainly done. One of the authors, Marie Lise Dubernet, did an extensive survey of relevant standards within the community of Atomic and Molecular Physics, and several of the authors did meet relevant parties on the fields where discussions were celebrated. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. Editors' input:Note taken I approve the document as it stands. -- TomMcGlynn October 8, 2010Data Access LayerIn Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above Editors' input:Example modified to match properly Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. Editors' input:Appendix A exists but it lost its "Heading 1" type, therefore was lost in the TOC. References to the Appendices have been reviewed, and all corrected (as well as anchor links to relevant places within the doc). For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. Editors' input:Links modified to point to the version specified within the reference. Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). Editors' input:Corrected -- PatrickDowler October 14, 2010 | ||||||||
Added: | ||||||||
> > | Small issues: The text on p 10 (under the IVOA architecture diagram) mentions SpectrumDM when I think it is intended to be SSLDM. The document does not explicitly say this, but I assume that the subsection headings in 3 are (parts of) utypes (and data types) for SSLDM. This is at least implied by the structure of the headings. In some cases one would have to infer the utype where a higher level construct re-uses another. For example, Line.initialLevel is a Level, Level.energy is a PhysicalQuantity and PhysicalQuantity.value is numeric, which implies a utype of Line.initialLevel.energy.value. Is that correct? Should the connection to utypes be stated somewhere, eg at the start of Section 3? Approved -- PatrickDowler October 15, 2010 | |||||||
Data ModelingMinor comments:
Grid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageI approve this document -- PedroOsuna 15 Oct 2010VOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: | ||||||||
Changed: | ||||||||
< < | http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf | |||||||
> > | http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101015.pdf | |||||||
Review period: 2009 July 21 – 2009 September 15 (Extended!)
July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. | ||||||||
Added: | ||||||||
> > | Editors' input:Sentence removed and overall paragraph refurbished slightly. | |||||||
One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. | ||||||||
Added: | ||||||||
> > | Editors' input:The research was certainly done. One of the authors, Marie Lise Dubernet, did an extensive survey of relevant standards within the community of Atomic and Molecular Physics, and several of the authors did meet relevant parties on the fields where discussions were celebrated. | |||||||
I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. | ||||||||
Added: | ||||||||
> > | Editors' input:Note taken | |||||||
I approve the document as it stands.
-- TomMcGlynn October 8, 2010
Data Access LayerIn Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above | ||||||||
Added: | ||||||||
> > | Editors' input:Example modified to match properly | |||||||
Added: | ||||||||
> > | ||||||||
Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. | ||||||||
Added: | ||||||||
> > | Editors' input:Appendix A exists but it lost its "Heading 1" type, therefore was lost in the TOC. References to the Appendices have been reviewed, and all corrected (as well as anchor links to relevant places within the doc). | |||||||
For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. | ||||||||
Added: | ||||||||
> > | Editors' input:Links modified to point to the version specified within the reference. | |||||||
Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). | ||||||||
Added: | ||||||||
> > | Editors' input:Corrected | |||||||
-- PatrickDowler October 14, 2010
Data ModelingMinor comments:
| ||||||||
Added: | ||||||||
> > | Editors' input:Energy added. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Corrected. | |||||||
I approve this document and agree for the next step :IVOA recommendation.
-- MireilleLouys October 15, 2010
Grid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query Language | ||||||||
Added: | ||||||||
> > | I approve this document -- PedroOsuna 15 Oct 2010 | |||||||
VOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. I approve the document as it stands. -- TomMcGlynn October 8, 2010Data Access LayerIn Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). -- PatrickDowler October 14, 2010Data Modeling | ||||||||
Added: | ||||||||
> > | Minor comments:
| |||||||
Grid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsOne tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. I approve the document as it stands. -- TomMcGlynn October 8, 2010Data Access Layer | ||||||||
Added: | ||||||||
> > | In Sec 3.2.3 (p. 15), the example of PhysicalQuantity for 3500 Jansky has values from Angstrom example above Section 8 is titled "Appendix B: ...", but there is no Appendix A in the ToC. There are references to "Appendix A" (3.4.1) and "Appendix C" (3.5.3, 3.6.3). Also, some places just refer to "see appendix" (3.5.1). There is some plain text on p 68 that seems to be the start of Appendix A, buried in the middle of section 7. There is no Appendix C. For references 13, 14, and 15 (to other IVOA documents) the reference seems to be (safely) to a specific existing version, but the links are to the latest versions, which may change in the future. It may be better to link to specific versions of the standards, at least in cases where the other standard is used rather than just informative. Small note: the link in reference [14] has the final "l" in "html" outside the anchor (at least, it is displayed black instead of blue for me). -- PatrickDowler October 14, 2010 | |||||||
Data ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.Applications | ||||||||
Added: | ||||||||
> > | One tiny nit. In section 3.1 there is a reference to "per the DM dicussion". RFC documents should not reference DM (or any other) discussions: these are standards documents and stand on their own or reference other documents of equivalent permanence. So this should reference the appropriate standard, or if there is no such standard, it should simply be presented as a non-normative element of this standard. One larger concern: This document defines a standard which goes beyond the ambit of astronomy into physics and chemistry. Some discussion of the existence of relevant standards from those communities might have been desirable. I raise these issues more for discussion in the future in potential revisions to this document and other standards rather than suggesting a change need be made in the current version or this standard. I approve the document as it stands. -- TomMcGlynn October 8, 2010 | |||||||
Data Access LayerData ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
| ||||||||
Added: | ||||||||
> > | Thanks to Pedro for all these corrections. As said before, I approve the document ChristopheArviset - 06 September 2010 | |||||||
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 | ||||||||
Added: | ||||||||
> > | I appreciate the effort put in by Pedro to fix the many formatting problems and equations. I endorse going forward at this point. BobHanisch 7 October 2010 | |||||||
TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: | ||||||||
Changed: | ||||||||
< < | http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101004.pdf | |||||||
> > | http://www.ivoa.net/Documents/SSLDM/20101004/PR-SSLDM-1.0-20101004.pdf | |||||||
Review period: 2009 July 21 – 2009 September 15 (Extended!)
July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: | ||||||||
Changed: | ||||||||
< < | http://www.ivoa.net/Documents/SSLDM/20100506/ | |||||||
> > | http://www.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20101004.pdf | |||||||
Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. | ||||||||
Deleted: | ||||||||
< < | See http://www.ivoa.net/Documents/SSLDM/20090714/ | |||||||
Added: | ||||||||
> > | ||||||||
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web Services | ||||||||
Changed: | ||||||||
< < | The formatting seems to be a bit of an issue and it would be useful to see some XML serialization, for example, those of the JSON representations; otherwise I approve this document. | |||||||
> > | The formatting seems to be a bit of an issue | |||||||
Added: | ||||||||
> > | Editors' input:See editor comment's below (on Data Curation and Preservation section). and it would be useful to see some XML serialization, for example, those of the JSON representations; Editors' input:Serialisations could be added in a further version or as a support document. otherwise I approve this document. | |||||||
--IVOA.MatthewGraham - 16 Jul 2010
Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. Editors' input:Change log with changes after TCG comments on RFC has been added. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. Editors' input:Section numbering reviewed. 4th level hierarchy removed. In the Abstract, the reference to the SLAP document is missing. Editors' input:Reference to SLAP added. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. Editors' input:Equations rewritten where necessary to avoid floating issue. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. Editors' input:TOC changed to include section numbers. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. A few other minor comments:
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue and it would be useful to see some XML serialization, for example, those of the JSON representations; otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO EventApproved -- RobSeaman - 9 Sep 2010VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. | ||||||||
Added: | ||||||||
> > | Editors' input:Change log with changes after TCG comments on RFC has been added. | |||||||
The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. | ||||||||
Added: | ||||||||
> > | Editors' input:Section numbering reviewed. 4th level hierarchy removed. | |||||||
In the Abstract, the reference to the SLAP document is missing. | ||||||||
Added: | ||||||||
> > | Editors' input:Reference to SLAP added. | |||||||
There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. | ||||||||
Added: | ||||||||
> > | Editors' input:Equations rewritten where necessary to avoid floating issue. | |||||||
The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. | ||||||||
Added: | ||||||||
> > | Editors' input:TOC changed to include section numbers. | |||||||
The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. | ||||||||
Added: | ||||||||
> > | Editors' input:Font changed from Arial to times New Roman everywhere to solve issue. | |||||||
I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me.
BobHanisch 28 May 2010
TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. | ||||||||
Added: | ||||||||
> > | Editors' input:See above. Change log included, to be removed when final Recommendation is agreed. | |||||||
A few other minor comments:
| ||||||||
Added: | ||||||||
> > | Editors' input:Architecture added in Introduction rather than in summary to avoid conflicts with future abstract display (e.g., in ADS). | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Modified. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Modified. | |||||||
Assuming these points will be addressed for the final version, I approve the document.
ChristopheArviset - 25 june 2010
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesThe formatting seems to be a bit of an issue and it would be useful to see some XML serialization, for example, those of the JSON representations; otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010Resource RegistrySemanticsI approve this document. SD.VO Event | ||||||||
Added: | ||||||||
> > | Approved -- RobSeaman - 9 Sep 2010 | |||||||
VO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web Services | ||||||||
Added: | ||||||||
> > | The formatting seems to be a bit of an issue and it would be useful to see some XML serialization, for example, those of the JSON representations; otherwise I approve this document. --IVOA.MatthewGraham - 16 Jul 2010 | |||||||
Resource RegistrySemanticsI approve this document. SD.VO EventVO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemantics | ||||||||
Added: | ||||||||
> > | I approve this document. SD. | |||||||
VO EventVO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010TheoryTCGThe document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples. I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers). Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version. But I believe that for the final REC version, the change log should be removed. A few other minor comments:
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010TheoryTCG | ||||||||
Added: | ||||||||
> > | The document is well structured, the models are clear with good reference to other existing (or ongoing) IVOA models. It is also useful to have the working examples.
I share Bob's comments about the sections numbering and the formatting of the Table of Contents (which should have sections numbers).
Indeed, a global change log would be useful to see how all the comments from the RFC have been taken into account in this new version.
But I believe that for the final REC version, the change log should be removed.
A few other minor comments:
| |||||||
<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationI was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 | ||||||||
Deleted: | ||||||||
< < |
OGF Astro-RG | |||||||
TheoryTCG<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & Preservation | ||||||||
Changed: | ||||||||
< < | I was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. | |||||||
> > | I was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. | |||||||
The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. | ||||||||
Changed: | ||||||||
< < | There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. | |||||||
> > | There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. I believe that Word's own symbol set could be used to create all of these symbols in line, and this would avoid the alignment problems. | |||||||
Changed: | ||||||||
< < | The Table of Contents does not include section numbers, only section headings. | |||||||
> > | The Table of Contents does not include section numbers, only section headings, and the formatting is very strange in the PDF version. In the Word version I can see the page numbers on screen, but they get truncated when printed which suggests a problem with the margin setting. | |||||||
Added: | ||||||||
> > | The use of a sans serif font causes confusion in some sections, such as 4.3.x. An uppercase I and a lowercase l are indistinguishable. With the context of the math symbols one can figure out that an uppercase I is the intention, but given that all of the math symbols appear in what looks like Times italics, it might be much clearer if the font of the entire document were changed to Times. I have no comments on the correctness or not of the atomic physics. It is mainly the presentation and the traceability back to earlier versions that concern me. BobHanisch 28 May 2010 | |||||||
OGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionTCG Review period: 12th May - 11th June See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ Review period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & Preservation | ||||||||
Added: | ||||||||
> > | I was trying to determine how the authors responded to the detailed comments from Ray Plante, and this turns out to be quite difficult. First, there is no change log in the document, something that by example, at least, I thought was a requirement on all IVOA documents. This is something we will have to make explicit in the next version of the DocStds document. The entire section numbering of Section 2.1 in the previous version has changed to Section 3... in the new version. But now the numbering hierarchy is wrong, jumping from 3 to 3.1.1. The 4th level of the hierarchy is not required and makes referencing the document unnecessarily complicated. The 4th level subsection headings are indented a huge amount -- probably an error in the style settings -- but presumably this would be fixed by restructuring this section to the just necessary three levels. In the Abstract, the reference to the SLAP document is missing. There is something odd in the typography of the math symbols. For example, in 3.1.3.10 in in-line symbols all float above the baseline like superscripts. I'm not sure what tool was used to create the symbols, but this problem with vertical alignment could lead to some misunderstandings. The Table of Contents does not include section numbers, only section headings. | |||||||
OGF Astro-RGTheoryTCG<--
|
SSLDM RFC Discussion | ||||||||
Added: | ||||||||
> > | TCG Review period: 12th May - 11th June | |||||||
Added: | ||||||||
> > | See the PR latest revised version at: http://www.ivoa.net/Documents/SSLDM/20100506/ | |||||||
Review period: 2009 July 21 – 2009 September 15 (Extended!)
July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.
See http://www.ivoa.net/Documents/SSLDM/20090714/
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsTCG Review period: 12th May - 11th June Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale.Editors' input:Done.
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest Groups | ||||||||
Added: | ||||||||
> > | TCG Review period: 12th May - 11th June | |||||||
Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.
ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
| ||||||||
Added: | ||||||||
> > | Editors' input:Definitions have been included in those places where there was no explanation, and components of the formulae have been described (except for common ones like c,h, etc.). Environment variables, being such common definitions (temperature, pressure, mass, etc.) have not been included explicitly though. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:A note has been included at the introduction on Quantum numbers. Quantum Numbers have been moved from an appendix to a chapter (chapter 4) and cross-references to the relevant item numbers for the most commonly used Quantum Numbers have been added there. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:All data types have been included in each of the attributes following them with a colon. A specific summary table has also been created for ease of reference. | |||||||
And now for the some specific notes...
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Removed. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. "Sustracted" removed. Whole point clarified. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:As said before, all attributes' definitions include now their type. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. Model attributes referenced have been highlighted in Courier font to represent attribute within the model. | |||||||
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale. | ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done (see before) | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Lifetime is a very general concept, and when it comes to definitions it can be described in several ways. E-folding time is one, another one is related to the inverse of all the transition probabilities of all levels of energy lower than a given one (Einstein coeffs.). Therefore, it looks better to not to restrict the definition despite the risk of comparing different theoretical concepts. It however looks reasonable to consider that however they are measured, lifeTimes described here should be somehow comparable. This could be discussed further but for this version has not been included. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Done. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Double removed. Not anymore relevant. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Not anymore relevant. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:To be discussed with Arnold and in a wider level at IVOA. Probably should not mean a showstopper for this release. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Sections have been reshuffled for ease of reading. Probably not relevant anymore. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Probably not relevant anymore. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Changed to Chapter 4. | |||||||
| ||||||||
Added: | ||||||||
> > | Editors' input:Numbers removed. | |||||||
-- RayPlante - 16 Sep 2009
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). | ||||||||
Added: | ||||||||
> > | Editors' input:Quantum states for NH3 hyperfine inversion structure are represented by concrete quantum numbers. It can be seen, for instance in "Good, Phys. Rev. 70, 3-4, 1946, pages 213-218" that the inverse spectrum for ammonia can be described as transitions between states represented by different J and K quantum numbers. In this paper it can be seen how the line wavelengths are calculated as a combination in powers of one and two of the corresponding J and K numbers, but this is not relevant to the problem at hand. Molecular databases do give catalogue numbers for inversion lines, and all of them are represented by concrete quantum numbers, so we believe this model can describe those. To look for examples, please visit the JPL molecular Database and the CDMS at Cologne. Links are given here for reference: http://spec.jpl.nasa.gov/ftp/pub/catalog/catform.html http://www.astro.uni-koeln.de/cdms/catalog | |||||||
-- MasatoshiOhishi
TheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
| ||||||||
Changed: | ||||||||
< < | There are places where this is done perfectly (2.1.5.3); other places seem to assume a standard knowledge (2.1.3.19). In this latter case, it may be distracting to spell out the entire formula, particularly when certain ones would be obvious to anyone whose taken a physics class (e.g. ''c'', ''h''), so simply giving a reference should be sufficient. The references (with Rybicki and Lightman, Drake, and Condon/Shortly) seem sufficient to do this. Such references will provide a means for working out ambiguities that we or users may discover later. | |||||||
> > | There are places where this is done perfectly (2.1.5.3); other places seem to assume a standard knowledge (2.1.3.19). In this latter case, it may be distracting too spell out the entire formula, particularly when certain ones would be obvious to anyone whose taken a physics class (e.g. ''c'', ''h''), so simply giving a reference should be sufficient. The references (with Rybicki and Lightman, Drake, and Condon/Shortly) seem sufficient to do this. Such references will provide a means for working out ambiguities that we or users may discover later. | |||||||
| ||||||||
Changed: | ||||||||
< < | In the absence such a paragraph, one can merely provide an explicit explanation of a variable's use (e.g. "where J is the angular momentum quantum number (sect. 6.4.11.)") | |||||||
> > | In the absence such a paragraph, one can merely provide an explicit explanation every place the variable is used (e.g. "where J is the angular momentum quantum number (sect. 6.4.11.)") | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale. | ||||||||
Added: | ||||||||
> > |
| |||||||
-- RayPlante - 16 Sep 2009
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
| ||||||||
Added: | ||||||||
> > |
When an instance of the model includes multiple "Line.intensity" values, all must have the same scale. | |||||||
-- RayPlante - 16 Sep 2009
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments: | ||||||||
Added: | ||||||||
> > |
Ray PlanteIn general, I feel this data model is fairly complete (and fun to read). My comments are mainly about presentation. There several things in the definitions that were unclear or ambiguous that I could figure out by looking at the examples. Given that we don't want a standard defined by its examples, we just need put that clarity into the definitions. To start with, here are some general comments:
| |||||||
RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 September 15 (Extended!) July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. See http://www.ivoa.net/Documents/SSLDM/20090714/SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGQuestion translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). -- MasatoshiOhishiTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC Discussion | ||||||||
Changed: | ||||||||
< < | Review period: 2009 July 21 – 2009 August 30 | |||||||
> > | Review period: 2009 July 21 – 2009 September 15 (Extended!) | |||||||
July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process.
See http://www.ivoa.net/Documents/SSLDM/20090714/
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RG | ||||||||
Added: | ||||||||
> > | Question translated from SLAP RFC pages: (4) Page 16 (SLAP document), expression of the quantum states; it is unclear to me how this document is going to express the quantum states for the inversion lines (e.g., NH3) or molecules with internal rotation (e.g., CH3OH, (CH3)2O). -- MasatoshiOhishi | |||||||
TheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionReview period: 2009 July 21 – 2009 August 30 July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. | ||||||||
Changed: | ||||||||
< < | See attachment https://wiki.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20090714.pdf | |||||||
> > | See http://www.ivoa.net/Documents/SSLDM/20090714/ | |||||||
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
SSLDM RFC Discussion | ||||||||
Changed: | ||||||||
< < | Review period: 2009 July 21 – 2009 August 18 | |||||||
> > | Review period: 2009 July 21 – 2009 August 30 | |||||||
Changed: | ||||||||
< < | July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process | |||||||
> > | July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process. | |||||||
Added: | ||||||||
> > | See attachment https://wiki.ivoa.net/internal/IVOA/SimpleSpectrumLineDMRFC/PR-SSLDM-1.0-20090714.pdf | |||||||
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC Discussion | ||||||||
Added: | ||||||||
> > | Review period: 2009 July 21 – 2009 August 18 | |||||||
July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC DiscussionJuly 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC processSSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest Groups | ||||||||
Changed: | ||||||||
< < | Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads. I [TAM] have noted cases where the RFC comments seemed to indicate an approval in the RFC period but the appropriate chairs should review this final draft. | |||||||
> > | Note that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads. | |||||||
Deleted: | ||||||||
< < | ||||||||
ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC Discussion | ||||||||
Changed: | ||||||||
< < | July 14, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process | |||||||
> > | July 20, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process | |||||||
SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads. I [TAM] have noted cases where the RFC comments seemed to indicate an approval in the RFC period but the appropriate chairs should review this final draft.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|
SSLDM RFC Discussion | ||||||||
Changed: | ||||||||
< < | June 22, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process | |||||||
> > | July 14, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC process | |||||||
Added: | ||||||||
> > | SSLDM Use Case:The main use of the SSLDM is to provide data model support to the Simple Line Access Protocol, so to allow the comsuption of Spectral Line List databases using a common/standard interface.SSLDM"> SLAP Implementations using SSLDM:
SLAP-like Implementations using SSLDM:
| |||||||
Comments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads. I [TAM] have noted cases where the RFC comments seemed to indicate an approval in the RFC period but the appropriate chairs should review this final draft.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
SSLDM RFC DiscussionJune 22, 2009 Page created to encapsulate the discussion of the Simple Spectrum Line DM RFC processComments:RFC period comments from Working and Interest GroupsApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCGTCG Review: Working and Interest GroupsNote that the space for RFC comments from the working groups was intended to spur early review of the document. A formal approval is still requested from each of the WG and IG heads. I [TAM] have noted cases where the RFC comments seemed to indicate an approval in the RFC period but the appropriate chairs should review this final draft.ApplicationsData Access LayerData ModelingGrid & Web ServicesResource RegistrySemanticsVO EventVO Query LanguageVOTableData Curation & PreservationOGF Astro-RGTheoryTCG<--
|