MOC 2.0 WD Feedback

Fri Mar 12 18:13:27 CET 2021

Hi Pierre, et al.,

Thank you for reminding us of how this decision evolved.  Based on your analysis and the other comments so far, I am also in favor of trying to reintroduce the ASCII serialization or TMOCs and STMOCs.

Best,
Tom

From: <apps-bounces at ivoa.net> on behalf of Pierre Fernique <Pierre.Fernique at astro.unistra.fr>
Date: Friday, March 12, 2021 at 11:06 AM
To: Mark Taylor <m.b.taylor at bristol.ac.uk>, ada nebot <ada.nebot at astro.unistra.fr>
Cc: Applications WG <apps at ivoa.net>
Subject: Re: MOC 2.0 WD Feedback

External Email - Use Caution

Hi Mark et al.,
Le 11/03/2021 à 10:31, Mark Taylor a écrit :

Ada, Francois, et al.,

I'm not necessarily against this, but in order to avoid hitting a

problem that we might have run into before: does anybody know why the

STMOC ASCII serialization was removed from the document in the first

place?  It was present in an internal draft I have dated 2020-09-14,

but not at https://www.ivoa.net/documents/MOC/20201112/index.html

It's possible that I was party to the conversation that resulted in

that change, but if so I don't remember.  Can the authors explain

why STMOC ASCII got removed?

The removal of ASCII serialization for TMOCs and STMOCs in WD 2.0 had been motivated when the authors were considering the complete removal of the temporal MOC hierarchy due to the fact that the syntax was based on this notion of hierarchy (order/npix or order/range...). As we finally decided to keep a hierarchy (factor 2 for time and 4 for space), technically it could be possible to reintegrate this ASCII serialization in the document by just adjusting a little bit the text to take into account the 61 orders of time compared to the 29 of space).

I would be in favor of reintroducing. My current point of view is also motivating by the fact that I'm updating Aladin Desktop to follow the latest WD, and I admit that the removal of ASCII serialization is a concern for me, especially in the script commands (draw MOC ....) that requires an ASCII expression and also to keep a global consistency for the MOCs serializations. Also, I keep in mind the remarks of Gregory Dubois, just after my IVOA presentation which let think me that an ASCII serialization will be really required anymore. François Bonnarel's last mail is also in the same direction.

If there is no strong opposition and the other redactors agree, I think it would make sense to reintroduce this alternative. Ada ? Daniel ?

Cheers
Pierre

Thanks

Mark

On Thu, 11 Mar 2021, ada nebot wrote:

Dear Tom, Francois, and Apps,

Tom, thanks for all your comments, I will take your editorial suggestions into account.

Francois, concerning the ascii serialisation, thanks for pointing that out! I totally agree with you that we should bring back the ascii serialisation to the document.

Best,

Ada

--

Astronome Adjointe

CDS, Observatoire Astronomique de Strasbourg (ObAS)

UMR 7550 Université de Strasbourg

11, rue de l'Université, F-67000 Strasbourg

+33 (0) 3 68 85 24 20

On 10 Mar 2021, at 16:54, BONNAREL FRANCOIS <francois.bonnarel at astro.unistra.fr><mailto:francois.bonnarel at astro.unistra.fr> wrote:

Dear apps, dear MOC2.0 authors

I went to this spec with my DAL point of view.

It's now a couple of monthes (years ?) that the IVOA community point out that it would be good that DAL parameter-based protocols could use MOC as input parameters

There is no reason that this should be restricted to space

One obvious use case is when you get a MOC for some survey, catalog , or whatever from a previous operation in the VO and want to query a parameter-based service (Simple access service or SODA) constraining the service response using this MOC.

Although we could imagine using the binary coding described at page 18/19 as a MOC parameter value, it would be obviously more user friendly to allow ASCII serialization there.

By preparing a github PR for this feature in SODA I realized that Time ascii serialization doesn't exist any more  in the current version of the spec. But it was the case in the preliminary note (https://ivoa.net/documents/stmoc/index.html)

I don't know the very technical reasons for this change but I think it would be useful to provide back an ASCII TMOC serialization at least to serve the extension of MOC usage to DAL protocols.

Cheers

François

Le 09/03/2021 à 00:42, Tom Donaldson a écrit :

Dear Pierre, et al.,

I spent a little time reviewing the MOC 2.0 working draft (https://www.ivoa.net/documents/MOC/20201112/WD-MOC-2.0-20201112.pdf)

and have some feedback.

First,  thank you to all the authors.  I found the document well written, clearly explaining both the motivation

and required details.  This functionality seems very worthwhile, and the technique well-studied and effective.

I don't have any major concerns with the content.

I could imagine some discussion about generalizing the technique further to incorporate other dimensions

such as spectral coverage.  However, I note that the space and time representations are customized based on

the specific characteristics of those values, so other dimensions may need other customizations.  Without

studying the use cases and values for at least one other dimension at the same level of detail as

space and time, generalizing the customizations seems premature.

I do have a few editorial suggestions:

Table of Contents

- starts with a "Todo list" referring to page 4, but there is no Todo list on that or other pages.

- does not include the Acknowledgements or Conformance-related definitions from page 5

Introduction

- Should the reference to be to MOC 1.1 instead of MOC 1.0?

Section 2.3, p14

- in "more than 73000 years at 1μ resolution", "1μ" should be "1μs".

Section 3.3

- comma unnecessary after "(coded according to the TMOC convention)".  Possible alternate wording to make it a little smoother:

    "by associating each time period (coded according to the TMOC convention) with its spatial region

     (coded according to the SMOC convention)."

Section 4.2

- "about 1000 seconds (see Table 1)" should instead refer to Table 2 for the time resolutions.

Section 4.2.1

- awkward phrasing in, "The numbering scheme used in TMOC for specifying the time cell indices must reuse a similar hierarchical

  principle as for the SMOC with the difference that the time line has only one dimension, and there is no need to use an HEALPix

  mapping in addition of a progression of a factor of 2 instead of 4."

  Suggest maybe:

  "The numbering scheme used in TMOC for specifying the time cell indices must reuse a similar hierarchical principle as for the

  SMOC with the difference that the time line has only one dimension, so the hierarchical progression uses a factor of 2 instead of 4,

  and there is no need to use a HEALPix mapping."

Section 4.3.1

- in Backward compatibility, "existing library" should probably be "existing libraries".

Section 4.3.2

- The EBNF does not seem to allow the final index-free order (the example ends with "8/" to indicate an order of 8.)  Maybe update to:

   moc ::= ordpix (sep+ ordpix)* [sep+ order]

   ordpix ::= order sep* pixs

   order ::= int ’/’

   pixs ::= pix (sep+ pix)*

   pix ::= int? | (int ’-’ int)

   sep ::= [ \n\r]

   int ::= [0-9]+

Section 5.1

- This sentence equates forcing the 64th bit to 1 with negating the integer:

     "To distinguish time and space indices, the time indices must have the 64th bits forced to 1 - i. e. represented

     as a negative integer."

  Should we clarify that the time indices must be the twos complement negative of the actual value?  This would prevent

  any possible confusion between that and just masking that last bit to 1 without changing the other bits.  I believe the

  FITS standard uses twos complement for signed ints, but it can't hurt to be explicit.

References

- I'm not sure whether it's important for references to include URLs, or what the best links are (DOIs, etc.), but some

  reference have a URL and some don't, so maybe some more consistency could be achieved?

- The MOC 1.0 reference describes it as Working Draft (it is REC) and links to the most recent version (1.1) instead of 1.0.

Best regards,

Tom

--

Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK

m.b.taylor at bristol.ac.uk<mailto:m.b.taylor at bristol.ac.uk>          http://www.star.bristol.ac.uk/~mbt/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20210312/289cf8aa/attachment-0001.html>