MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140512
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Approved.Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )The Grid and Web Services WG approves this document.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )I appreciate the effort to continue to work with Healpix and to describe the use of Healpix as a coverage map. My main concern is that the IVOA is proposing a standard that is promoting 1 spherical geometric algorithm and implementation and this is not representative of other key large datasets in the community (at least the originating source data provider version, i'm not referring to cloned datasets that have been tesselated to support a MOC infrastructure. The paper has all the correct elements for description of MOC and is nicely structured and could be used a a more general format for standard for other data systems. The most obvious is HTM. The MOC standard could be generically described for more than 1 spherically geometry and perhaps STC providing footprint coverage standardization across more astronomical data providers. I do not want to prevent the document for moving forward, yet encourage to give some thought to a more generic MOC is multi order coverage standard with Healpix as one form of geometric representation. I did not see an example how the MOC would be captured in the registry metadata for discovery as we had discussed at the Heidelberg meeting, my understanding as that we could use the existing footprint metadata as initial placement. Naming conventions for MOC? It is good to express the limitations of MOC, so that i appreciate the explanation included in the document. What i would like to encourage us to do is to define a footprint standard that can provide coverage in more representation that 1 tesselation scheme to represent a region on the sky. Region intersection and union operations should be implementation agnostic. Registry Working Group approves this document yet requests consideration of the comments in support of generic MOC representations and data discovery in the registry. GretchenGreene 05/12/2014 Gretchen, thank you for your approval. To respond briefly to your concerns and clarify the intent of this document: the document is simply a definition of the HEALPix-based MOC format. It does not aspire to be the VO's one-size-fits-all response to the question of how to characterise sky coverage. It also deliberately does not address the question of whether or how MOCs might be used in conjunction with the registry. The question of how best to characterise sky coverage in the registry is an important one, and MOC may have a part to play, but that's a matter for future discussion within the Registry WG. -- MarkTaylor - 2014-05-14Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140512
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham ) | ||||||||
Added: | ||||||||
> > | Approved. | |||||||
Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )The Grid and Web Services WG approves this document.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )I appreciate the effort to continue to work with Healpix and to describe the use of Healpix as a coverage map. My main concern is that the IVOA is proposing a standard that is promoting 1 spherical geometric algorithm and implementation and this is not representative of other key large datasets in the community (at least the originating source data provider version, i'm not referring to cloned datasets that have been tesselated to support a MOC infrastructure. The paper has all the correct elements for description of MOC and is nicely structured and could be used a a more general format for standard for other data systems. The most obvious is HTM. The MOC standard could be generically described for more than 1 spherically geometry and perhaps STC providing footprint coverage standardization across more astronomical data providers. I do not want to prevent the document for moving forward, yet encourage to give some thought to a more generic MOC is multi order coverage standard with Healpix as one form of geometric representation. I did not see an example how the MOC would be captured in the registry metadata for discovery as we had discussed at the Heidelberg meeting, my understanding as that we could use the existing footprint metadata as initial placement. Naming conventions for MOC? It is good to express the limitations of MOC, so that i appreciate the explanation included in the document. What i would like to encourage us to do is to define a footprint standard that can provide coverage in more representation that 1 tesselation scheme to represent a region on the sky. Region intersection and union operations should be implementation agnostic. Registry Working Group approves this document yet requests consideration of the comments in support of generic MOC representations and data discovery in the registry. GretchenGreene 05/12/2014 Gretchen, thank you for your approval. To respond briefly to your concerns and clarify the intent of this document: the document is simply a definition of the HEALPix-based MOC format. It does not aspire to be the VO's one-size-fits-all response to the question of how to characterise sky coverage. It also deliberately does not address the question of whether or how MOCs might be used in conjunction with the registry. The question of how best to characterise sky coverage in the registry is an important one, and MOC may have a part to play, but that's a matter for future discussion within the Registry WG. -- MarkTaylor - 2014-05-14Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for Comments | ||||||||
Changed: | ||||||||
< < | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140422 | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140512 | |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )The Grid and Web Services WG approves this document.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )I appreciate the effort to continue to work with Healpix and to describe the use of Healpix as a coverage map. My main concern is that the IVOA is proposing a standard that is promoting 1 spherical geometric algorithm and implementation and this is not representative of other key large datasets in the community (at least the originating source data provider version, i'm not referring to cloned datasets that have been tesselated to support a MOC infrastructure. The paper has all the correct elements for description of MOC and is nicely structured and could be used a a more general format for standard for other data systems. The most obvious is HTM. The MOC standard could be generically described for more than 1 spherically geometry and perhaps STC providing footprint coverage standardization across more astronomical data providers. I do not want to prevent the document for moving forward, yet encourage to give some thought to a more generic MOC is multi order coverage standard with Healpix as one form of geometric representation. I did not see an example how the MOC would be captured in the registry metadata for discovery as we had discussed at the Heidelberg meeting, my understanding as that we could use the existing footprint metadata as initial placement. Naming conventions for MOC? It is good to express the limitations of MOC, so that i appreciate the explanation included in the document. What i would like to encourage us to do is to define a footprint standard that can provide coverage in more representation that 1 tesselation scheme to represent a region on the sky. Region intersection and union operations should be implementation agnostic. Registry Working Group approves this document yet requests consideration of the comments in support of generic MOC representations and data discovery in the registry. GretchenGreene 05/12/2014 Gretchen, thank you for your approval. To respond briefly to your concerns and clarify the intent of this document: the document is simply a definition of the HEALPix-based MOC format. It does not aspire to be the VO's one-size-fits-all response to the question of how to characterise sky coverage. It also deliberately does not address the question of whether or how MOCs might be used in conjunction with the registry. The question of how best to characterise sky coverage in the registry is an important one, and MOC may have a part to play, but that's a matter for future discussion within the Registry WG. -- MarkTaylor - 2014-05-14Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140422
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )The Grid and Web Services WG approves this document.Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )I appreciate the effort to continue to work with Healpix and to describe the use of Healpix as a coverage map. My main concern is that the IVOA is proposing a standard that is promoting 1 spherical geometric algorithm and implementation and this is not representative of other key large datasets in the community (at least the originating source data provider version, i'm not referring to cloned datasets that have been tesselated to support a MOC infrastructure. The paper has all the correct elements for description of MOC and is nicely structured and could be used a a more general format for standard for other data systems. The most obvious is HTM. The MOC standard could be generically described for more than 1 spherically geometry and perhaps STC providing footprint coverage standardization across more astronomical data providers. I do not want to prevent the document for moving forward, yet encourage to give some thought to a more generic MOC is multi order coverage standard with Healpix as one form of geometric representation. I did not see an example how the MOC would be captured in the registry metadata for discovery as we had discussed at the Heidelberg meeting, my understanding as that we could use the existing footprint metadata as initial placement. Naming conventions for MOC? It is good to express the limitations of MOC, so that i appreciate the explanation included in the document. What i would like to encourage us to do is to define a footprint standard that can provide coverage in more representation that 1 tesselation scheme to represent a region on the sky. Region intersection and union operations should be implementation agnostic. Registry Working Group approves this document yet requests consideration of the comments in support of generic MOC representations and data discovery in the registry. GretchenGreene 05/12/2014 | ||||||||
Added: | ||||||||
> > | Gretchen, thank you for your approval. To respond briefly to your concerns and clarify the intent of this document: the document is simply a definition of the HEALPix-based MOC format. It does not aspire to be the VO's one-size-fits-all response to the question of how to characterise sky coverage. It also deliberately does not address the question of whether or how MOCs might be used in conjunction with the registry. The question of how best to characterise sky coverage in the registry is an important one, and MOC may have a part to play, but that's a matter for future discussion within the Registry WG. -- MarkTaylor - 2014-05-14 | |||||||
Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140422
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec ) | ||||||||
Added: | ||||||||
> > | ||||||||
The Grid and Web Services WG approves this document.
Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner ) | ||||||||
Added: | ||||||||
> > | I appreciate the effort to continue to work with Healpix and to describe the use of Healpix as a coverage map. My main concern is that the IVOA is proposing a standard that is promoting 1 spherical geometric algorithm and implementation and this is not representative of other key large datasets in the community (at least the originating source data provider version, i'm not referring to cloned datasets that have been tesselated to support a MOC infrastructure. The paper has all the correct elements for description of MOC and is nicely structured and could be used a a more general format for standard for other data systems. The most obvious is HTM. The MOC standard could be generically described for more than 1 spherically geometry and perhaps STC providing footprint coverage standardization across more astronomical data providers. I do not want to prevent the document for moving forward, yet encourage to give some thought to a more generic MOC is multi order coverage standard with Healpix as one form of geometric representation. I did not see an example how the MOC would be captured in the registry metadata for discovery as we had discussed at the Heidelberg meeting, my understanding as that we could use the existing footprint metadata as initial placement. Naming conventions for MOC? It is good to express the limitations of MOC, so that i appreciate the explanation included in the document. What i would like to encourage us to do is to define a footprint standard that can provide coverage in more representation that 1 tesselation scheme to represent a region on the sky. Region intersection and union operations should be implementation agnostic. Registry Working Group approves this document yet requests consideration of the comments in support of generic MOC representations and data discovery in the registry. GretchenGreene 05/12/2014 | |||||||
Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for Comments | ||||||||
Changed: | ||||||||
< < | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-1.0-20140422 | |||||||
Deleted: | ||||||||
< < | PR-MOC-1.0-20140422 | |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec ) | ||||||||
Added: | ||||||||
> > | The Grid and Web Services WG approves this document. | |||||||
Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for Comments | ||||||||
Changed: | ||||||||
< < | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310 | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version | |||||||
Added: | ||||||||
> > | PR-MOC-1.0-20140422 | |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310 | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
| ||||||||
Deleted: | ||||||||
< < | ||||||||
-- FrancoisBonnarel - 2014-04-25
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 | ||||||||
Added: | ||||||||
> > | The new version is a lot more clearer. DM recommend this spec for acceptance. -- JesusSalgado - 2014-05-12 | |||||||
Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
| ||||||||
Changed: | ||||||||
< < | Norman, thank you for these useful comments. We have added a new "worked" example section 1.2 and slightly reorganised section 2.3, along with one or two more minor changes. We hope this does a better job of introducing the concepts and explaining what a MOC is early in the document, and reduces confusion about how the different concepts fit together. An intermediate draft incorporating these changes is PR-MOC-1.0-20140422 (also linked at the top of this page). | |||||||
> > | Norman, thank you for these useful comments. We have added a new "worked" example section 1.2 and slightly reorganised section 2.3, along with one or two more minor changes. We hope this does a better job of introducing the concepts and explaining what a MOC is early in the document, and reduces confusion about how the different concepts fit together. An intermediate draft incorporating these changes is PR-MOC-1.0-20140422 (also linked at the top of this page). | |||||||
-- MarkTaylor, PierreFernique - 2014-05-06 | ||||||||
Changed: | ||||||||
< < | This amended version looks great to me -- the result is much clearer, and I believe that if I were trying to implement this, based only on this document, I could do that. I have separately passed to the authors a set of minor typographical fixes. I approve this version (or minor edits thereof) on behalf of the Semantics WG. | |||||||
> > | This amended version looks great to me -- the result is much clearer, and I believe that if I were trying to implement this, based only on this document, I could do that. I have separately passed to the authors a set of minor typographical fixes. I approve this version (or minor edits thereof) on behalf of the Semantics WG. | |||||||
-- NormanGray - 2014-05-10
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
| ||||||||
Added: | ||||||||
> > | This amended version looks great to me -- the result is much clearer, and I believe that if I were trying to implement this, based only on this document, I could do that. I have separately passed to the authors a set of minor typographical fixes. I approve this version (or minor edits thereof) on behalf of the Semantics WG. -- NormanGray - 2014-05-10 | |||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310 | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below
Data Model Working Group ( _Jesus Salgado, Omar Laurino )MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
| ||||||||
Added: | ||||||||
> > | Norman, thank you for these useful comments. We have added a new "worked" example section 1.2 and slightly reorganised section 2.3, along with one or two more minor changes. We hope this does a better job of introducing the concepts and explaining what a MOC is early in the document, and reduces confusion about how the different concepts fit together. An intermediate draft incorporating these changes is PR-MOC-1.0-20140422 (also linked at the top of this page). -- MarkTaylor, PierreFernique - 2014-05-06 | |||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
MOC v1.0: Proposed Recommendation: Request for Comments | ||||||||
Changed: | ||||||||
< < | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310 | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310 | |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < | Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. | |||||||
> > | Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. | |||||||
-- MarkTaylor - 2014-03-10
Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique ) | ||||||||
Changed: | ||||||||
< < | Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10 | |||||||
> > | Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10 | |||||||
Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )I propose to validate the standard from the DAL WG point of vue. Some remarks below | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
-- FrancoisBonnarel - 2014-04-25
Data Model Working Group ( _Jesus Salgado, Omar Laurino ) | ||||||||
Added: | ||||||||
> > | MOC is a very clever idea and it can be used on different IVOA contexts (fast querying, overall description, mission coverage description, prevent null queries,... etc). I have tested and used it in different contexts and VO applications and it has been proved as a very useful format. I also miss, as pointed by Norman, a clear definition of what is a MOC in the text. Is is assumed that MOC is a serialized way (in different formats) of npix HEALPix indexes at different orders that characterize the coverage of a certain dataset (mission, catalogue, etc) and it would be useful to have this defintion in the text written by the experts. Some other clarifications pointed by Norman comments will allow external developers to fully understand the format. If a new version is going to be created following some of this clarifications, I will wait for it before to provide the official approval. -- JesusSalgado - 2014-04-25 | |||||||
Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes | ||||||||
Changed: | ||||||||
< < | The idea of a MOC is clearly a useful one, and there is no intersection that I | |||||||
> > | The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. | |||||||
Deleted: | ||||||||
< < | can see between the Proposed Recommendation and current Semantics WG work. | |||||||
Changed: | ||||||||
< < | However I think this document may need a little work. It doesn't needs | |||||||
> > | However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. | |||||||
Deleted: | ||||||||
< < | rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. | |||||||
Changed: | ||||||||
< < | I'm reasonably confident I understand what MOC is, after reading the | |||||||
> > | I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. | |||||||
Deleted: | ||||||||
< < | document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. | |||||||
Changed: | ||||||||
< < | Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any | |||||||
> > | Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. | |||||||
Deleted: | ||||||||
< < | explanation of what they are. | |||||||
Changed: | ||||||||
< < | From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the | |||||||
> > | From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. | |||||||
Deleted: | ||||||||
< < | cells are numbered in some way yet to be explained; an example would be useful here. | |||||||
Changed: | ||||||||
< < | Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to | |||||||
> > | Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? | |||||||
Deleted: | ||||||||
< < | indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? | |||||||
Changed: | ||||||||
< < | Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea | |||||||
> > | Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. | |||||||
Deleted: | ||||||||
< < | that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. | |||||||
Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. | ||||||||
Changed: | ||||||||
< < | It might be useful to say explicitly, in Sect. 1.1, that a MOC is | |||||||
> > | It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. | |||||||
Deleted: | ||||||||
< < | a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. | |||||||
Exposition: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | illustrating, nor how the image and the MOC map relate to each other. | |||||||
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | understand the 'nested' encoding. It would probably be best to refer the reader to [1, Sect. 4.2] for the explanation. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | explanation here is too compact to be intelligible. Is the 'single binary table' a single-column table? Given that the document has previously explained the 'nested' and insisted that "MOC must use the NESTED numbering scheme only", it would be useful to explain here why the document is apparently switching to the 'nuniq' numbering scheme. Again, an example would be useful, of the encoded MOC, rather than just of the FITS headers. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | values must be fully sorted" -- I presume this means that the cell numbers within a MOC should be sorted in order of increasing 'uniq' number, since nowhere else is the sort order defined. If this is indeed the intended order for a MOC list in whatever representation, then this should perhaps be made clear earlier -- in this location it appears to be simply a detail of the storage of a MOC within a FITS file. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | adjacent cells”' It is not clear what the quoted phrase means. | |||||||
-- NormanGray - 2014-04-07
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova) | ||||||||
Deleted: | ||||||||
< < | ||||||||
<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel ) | ||||||||
Added: | ||||||||
> > |
I propose to validate the standard from the DAL WG point of vue. Some remarks below
| |||||||
Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )MOC notes The idea of a MOC is clearly a useful one, and there is no intersection that I can see between the Proposed Recommendation and current Semantics WG work. However I think this document may need a little work. It doesn't needs rewritten (fear not!), but although each section of the document is reasonably clear, it could do with some reordering of the text. I'm reasonably confident I understand what MOC is, after reading the document one and a half times, but I still have significant uncertainties (for example 'nested' vs 'nuniq', as discussed below), and it took rather more effort than it perhaps should have done. Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any explanation of what they are. From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the cells are numbered in some way yet to be explained; an example would be useful here. Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"? Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea that "it is not allowed to encode 4 sibling cells instead of their parent"? Does this mean that {0, 1, 2, 3, 12}, above, would be invalid? Again, an example would be useful. Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs! This puzzlement is probably rather easy to fix. It might be useful to say explicitly, in Sect. 1.1, that a MOC is a list of HEALPix cells, and to give one or more examples promptly. The remark in paragraph 3 of this section, that "So any regions of the sky can be defined by the list of the diamond numbers involved to define the region" is clearly true, but it's not clear, until after one has read the document, and started again from the beginning, that this is in fact the definition of a MOC, and that the point of the current document is simply to describe how this list is to be encoded within IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme, stored in ascending order of the 'nuniq' number That is, it is only clear in retrospect that the MOC concept is pleasingly straightforward. Exposition:
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys ) | ||||||||
Added: | ||||||||
> > |
MOC notes
The idea of a MOC is clearly a useful one, and there is no intersection that I
can see between the Proposed Recommendation and current Semantics WG work.
However I think this document may need a little work. It doesn't needs
rewritten (fear not!), but although each section of the document is reasonably
clear, it could do with some reordering of the text.
I'm reasonably confident I understand what MOC is, after reading the
document one and a half times, but I still have significant uncertainties
(for example 'nested' vs 'nuniq', as discussed below), and it took rather
more effort than it perhaps should have done.
Before Sect. 1.5.3, MOCs are repeatedly referred to without there being any
explanation of what they are.
From Sect. 1.5.3 I understand it is a list of HEALPix cells, where the
cells are numbered in some way yet to be explained; an example would be
useful here.
Sect. 2.2.2 describes a numbering scheme, but how do I use it? If I wanted to
indicate the five cells {0, 1, 2, 3, 12} in the diagram in this section, would I
give that list as a MOC? Or would it be "level 1: 0, plus level 2, 12"?
Sect. 2.2.3 describes "the hierarchical encoding principle" -- is this the idea
that "it is not allowed to encode 4 sibling cells instead of their parent"?
Does this mean that {0, 1, 2, 3, 12}, above, would be invalid?
Again, an example would be useful.
Aha, Sects. 3.1.1 and 3.1.2 illustrate some MOCs!
This puzzlement is probably rather easy to fix.
It might be useful to say explicitly, in Sect. 1.1, that a MOC is
a list of HEALPix cells, and to give one or more examples promptly.
The remark in paragraph 3 of this section, that "So any regions of
the sky can be defined by the list of the diamond numbers involved to
define the region" is clearly true, but it's not clear, until after one
has read the document, and started again from the beginning, that this
is in fact the definition of a MOC, and that the point of the current
document is simply to describe how this list is to be encoded within
IVOA applications: namely in the 'nested' (or the 'nuniq'?) scheme,
stored in ascending order of the 'nuniq' number
That is, it is only clear in
retrospect that the MOC concept is pleasingly straightforward.
Exposition:
| |||||||
Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique ) | ||||||||
Added: | ||||||||
> > | Applications WG recommends acceptance. -- MarkTaylor - 2014-03-10 | |||||||
Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|
MOC v1.0: Proposed Recommendation: Request for Comments | ||||||||
Changed: | ||||||||
< < | This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014. | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation; latest version PR-MOC-20140310 | |||||||
Changed: | ||||||||
< < | Latest version of MOC v1.0 can be found at: | |||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
| ||||||||
Changed: | ||||||||
< < | Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20120106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. | |||||||
> > | Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20140106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. | |||||||
-- MarkTaylor - 2014-03-10
| ||||||||
Added: | ||||||||
> > |
Comments from TCG member during the TCG Review Period: 11 March 2014 - 8 April 2014WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, although their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova) | |||||||
<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014. Latest version of MOC v1.0 can be found at:Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
| ||||||||
Added: | ||||||||
> > |
Following Enrique's comments, we have decided it's best not to list any MOC-producing services or applications in the standard text, so sections 3.1, 3.2 and 3.3 of the 20120106 version have been removed. The items from here (including VizieR MOCs) are now listed instead, alongside the SVO MOC-producing services, on the MocInfo wiki page. The resulting version (no other changes) is PR-MOC-1.0-20140310. -- MarkTaylor - 2014-03-10 | |||||||
<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014. Latest version of MOC v1.0 can be found at:Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014. Latest version of MOC v1.0 can be found at:Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
Added: | ||||||||
> > |
| |||||||
<--
|
MOC v1.0: Proposed Recommendation: Request for CommentsThis page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014. Latest version of MOC v1.0 can be found at:Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items :
| ||||||||
Changed: | ||||||||
< < | RFC Review Period: RFC_start_date - RFC_end_dateComments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014 | |||||||
> > |
Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014 | |||||||
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.
Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
<--
|
MOC v1.0: Proposed Recommendation: Request for Comments | ||||||||
Changed: | ||||||||
< < | This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on XX January 2014 and will run until XX February 2014. | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on 7 February 2014 and will run until 7 March 2014. | |||||||
Latest version of MOC v1.0 can be found at: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > | ||||||||
Reference Interoperable ImplementationsMOC 1.0 has been implemented in the following software items : | ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| |||||||
Deleted: | ||||||||
< < | -- PierreFernique - 2014-01-14 | |||||||
RFC Review Period: RFC_start_date - RFC_end_date | ||||||||
Changed: | ||||||||
< < | Comments from the IVOA Community during RFC period: RFC_start_date - RFC_end_date | |||||||
> > | Comments from the IVOA Community during RFC period: 7 February 2014 - 7 March 2014 | |||||||
In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.
Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document
<--
|
| ||||||||
Changed: | ||||||||
< < | IVOASTANDARD Proposed Recommendation: Request for Comments | |||||||
> > | MOC v1.0: Proposed Recommendation: Request for Comments | |||||||
Changed: | ||||||||
< < | Feel free to include here an introductory paragraph describing the IVOASTANDARD being addressed here | |||||||
> > | This page contains public discussion of the MOC v1.0 Proposed Recommendation. The RFC is announced on XX January 2014 and will run until XX February 2014. | |||||||
Changed: | ||||||||
< < | Latest version of IVOASTANDARD can be found at: | |||||||
> > | Latest version of MOC v1.0 can be found at: | |||||||
Reference Interoperable Implementations | ||||||||
Changed: | ||||||||
< < | (Indicate here the links to at least two Reference Interoperable Implementations)
Implementations Validators(If any, indicate here the links to Implementations Validators) | |||||||
> > | MOC 1.0 has been implemented in the following software items : -- PierreFernique - 2014-01-14 | |||||||
Deleted: | ||||||||
< < | ||||||||
RFC Review Period: RFC_start_date - RFC_end_date | ||||||||
Deleted: | ||||||||
< < | TCG Review Period: TCG_start_date - TCG_end_date | |||||||
Comments from the IVOA Community during RFC period: RFC_start_date - RFC_end_dateIn order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document | ||||||||
Deleted: | ||||||||
< < | ||||||||
Changed: | ||||||||
< < | Comments from TCG member during the TCG Review Period: TCG_start_date - TCG_end_date | |||||||
> > |
IVOASTANDARD Proposed Recommendation: Request for CommentsFeel free to include here an introductory paragraph describing the IVOASTANDARD being addressed here Latest version of IVOASTANDARD can be found at:
Reference Interoperable Implementations(Indicate here the links to at least two Reference Interoperable Implementations)Implementations Validators(If any, indicate here the links to Implementations Validators)RFC Review Period: RFC_start_date - RFC_end_dateTCG Review Period: TCG_start_date - TCG_end_dateComments from the IVOA Community during RFC period: RFC_start_date - RFC_end_dateIn order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this documentComments from TCG member during the TCG Review Period: TCG_start_date - TCG_end_date!!! SECTION TO BE ADDED ONLY ONCE THE TCG REVIEW PERIOD HAS STARTED !!! WG chairs or vice chairs must read the Document, provide comments if any and formally indicate if they approve or not the Standard. IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.TCG Chair & Vice Chair ( _Séverin Gaudet, Matthew Graham )Applications Working Group ( _Mark Taylor, Pierre Fernique )Data Access Layer Working Group ( Patrick Dowler, François Bonnarel )Data Model Working Group ( _Jesus Salgado, Omar Laurino )Grid & Web Services Working Group ( André Schaaff, Andreas Wicenec )Registry Working Group ( _Gretchen Greene, Pierre Le Sidaner )Semantics Working Group ( _Norman Gray, Mireille Louys )Education Interest Group ( _Massimo Ramella, Sudhanshu Barway )Time Domain Interest Group ( _John Swinbank, Mike Fitzpatrick )Data Curation & Preservation Interest Group ( Alberto Accomazzi, Françoise Genova )Knowledge Discovery in Databases Interest Group ( George Djorgovski )Theory Interest Group ( _Franck Le Petit, Rick Wagner )Standards and Processes Committee ( Françoise Genova)<--
|