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