<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>I have a few comments.<br><br></div>First, I think we need to define the role of the coverage information<br>in the registry, and specify the requirements.<br></div>If the spatial coverage is supposed to provide a rough estimate,<br></div>of the order of 1 deg and not provide an authoritative answer to<br></div>whether any particular position is included, then a low-order MOC,<br></div>as proposed by Markus, is perfectly acceptable.<br></div>But it should be absolutely clear that any queries against it do not<br></div>guarantee an accurate answer.<br></div>It seems to me that any resource should be able to provide an<br></div>authoritative answer, as a follow-up to the information provided<br></div>by the registry. And, frankly, and STC-S (not STC-X) string is, so<br></div>far, the only mechanism that can deliver. And there is no reason<br></div>not to restrict the options that can be used - in ADQL the shapes<br></div>have been limited to circle and polygon, for instance.<br></div>We did come quite a way to a Working Draft - until one of the<br></div>authors decided to drop the idea, so it could be taken up again,<br></div><div>with a specification of multiple layers of completeness in<br></div><div>implementation.<br></div>Using a MOC for high precision coverage applications is problematic<br></div>because it means that the server has to anticipate the client's<br></div>requirements in this area. Another issue is that MOCs generated<br></div>for catalogs generally reflect the distribution of the catalog's<br></div>records, not the true coverage of the catalog.<br><br></div>One more item about spatial coverage: we need to make sure<br></div>that we are not painting ourselves into a corner, restricting the<br></div>coordinates to ICRS. Galactic will come and if we want to have<br></div>appeal to the solar system community, that will require more<br></div>flexibility - which means that a reference position is needed, too,<br></div><div>but possibly only for solar system frames.<br></div><div><br></div>As to time, MJD is fine, but the combination of BARYCENTER and<br></div>TT is an oxymoron. I would advocate BARYCENTER-TDB,<br></div>GEOCENTER-TT and TOPOCENTER-TT. I will grant you that<br></div>the difference is minimal if one is using one-day precision, but<br></div>anything adopted here is going to creep into other systems that<br></div>require higher time precision and there we would end up with<br></div>what is essentially a defective standard.<br><br></div>I still regret the use of wavelength as the spectral coordinate.<br></div>Either frequency or energy have solid physical meaning and<br></div>do not require the extra caveat "in vacuo".<br><br></div>Yes, there is redshift, or Doppler velocity, and it is neither a<br>true geometric distance, nor a tru space velocity, nor a<br>spectral coordinate.<br></div></div>I know that some people look at me like I have two heads,<br></div>or something, when I say that, but I am hardly alone in this.<br></div>Cf., A&A 401,1185 (2003).<br></div>This is a legitimate type of coordinate and even though the<br></div>range may not be the most important piece of information,<br></div><div>the resolution certainly is: a segment of the user community<br></div><div>has a very good reason wanting to know whether Doppler<br></div><div>velocity information is available in a resource and at what<br></div><div>resolution.<br><br></div><div>I will leave it at that, for now.<br></div><div><br></div><div>Cheers,<br><br></div><div> - Arnold<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 29, 2018 at 10:51 AM, Ada Nebot <span dir="ltr"><<a href="mailto:ada.nebot@astro.unistra.fr" target="_blank">ada.nebot@astro.unistra.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Markus, <div><br></div><div>Thanks a lot for this Note! </div><div>I forward your email to the TDIG for comments since I think it is of interest to the Time Domain community. </div><div><br></div><div>I can see that the idea is to combine spatial, wavelength and temporal coverages to discover data. </div><div>In general, I like the idea and looks like a simple approach. I agree with the chosen time references as MJD, TT, barycentre of the solar system. </div><div><br></div><div>I would like to be sure that discovery for the temporal axes is not limited to day but that there will be the possibility of making a finer query, say down to the hour or the minute. </div><div><br></div><div><div>Section 4</div><div>Further axes? As you mention one could add more axes, but something like redshift would already impose questions like: how was it calculated? Photometrically or spectroscopically? Personally I think this might complicated things. </div><div><br></div><div>Other ref. systems? Indeed for SSO or moving objects it might not be enough. As minimal requirements for time series data we included a target name field. For SSOs we should follow the IAU convention, I found this <a href="https://www.iau.org/public/themes/naming/#inss" target="_blank">https://www.iau.org/<wbr>public/themes/naming/#inss</a> </div><div><br></div><div>Non electromagnetic coverage? Again, we thought about this in the time domain context and it might be useful to add Neutrino and GWs. </div><div><br></div><div>Thanks,</div><div>Ada</div><div><br></div><div><br><blockquote type="cite"><div>On 17 Jan 2018, at 10:58, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.<wbr>de</a>> wrote:</div><br class="m_-8036725048138865032Apple-interchange-newline"><div><div>Dear colleagues,<br><br>Those who attended our session in Shanghai may remember my talk on<br>how we can finally get proper STC queries against the Registry -- <br><a href="http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-Reg/reg-stc.pdf" target="_blank">http://wiki.ivoa.net/internal/<wbr>IVOA/InterOpMay2017-Reg/reg-<wbr>stc.pdf</a><br><br>I've finally done the various implementation parts to try everything<br>out in DaCHS and the relational registry (at this point, it's only on<br>the Heidelberg mirror, since harvesting the MOCs is quite a bit of<br>pain).<br><br>Based on that experience, I'd now propose a roadmap for how we could<br>move towards more-or-less universal declaration of coverages in<br>space, time, and spectrum for the VO Registry. I've drafted<br>a Note that I'd like to upload to the document repository -- probably<br>some time next week unless you want more time for discussions.<br><br>A draft of the note is available from<br><a href="http://docs.g-vo.org/regstcnote.pdf" target="_blank">http://docs.g-vo.org/<wbr>regstcnote.pdf</a>, the sources (that you're welcome<br>to work on) are in volute at <br><a href="https://volute.g-vo.org/svn/trunk/projects/registry/regstcnote" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/registry/<wbr>regstcnote</a><br>-- this includes a copy of the modified VODataService schema that<br>will later be part of the upload.<br><br>After this, I'd be grateful if you (yes, you!) could<br><br>(a) briefly review the thing to and protest quickly if you strongly<br>disagree with the main points of the note? Ideally, I'd like the<br>note to represent the "rough consensus" that's traditionally half of<br>the RFC process (the other part being "running code").<br><br>(b) perhaps look a bit deeper at the stuff if you're interested a bit<br>more in the registry/STC borderline. If you still feel comfortable<br>with the note then, I'd be happy to include you on the author list.<br>I feel a bit odd being the only author on something fairly<br>wide-reaching, and certainly some of you out there had important<br>roles in shaping what's written there during the past six years or so<br>(yeah: according to RegTAP WD-20121112, it removed a first version of<br>this...). So: If you can see your name on this note, just drop me a<br>note, and don't be shy or overly modest.<br><br>Thanks,<br><br> Markus<br></div></div></blockquote></div><br></div></div></blockquote></div><br></div>