<div dir="ltr">Dear Jerome, all,<br><div class="gmail_extra"><br><div class="gmail_quote">2017-10-11 0:59 GMT+02:00 JBerthier <span dir="ltr"><<a href="mailto:jerome.berthier@obspm.fr" target="_blank">jerome.berthier@obspm.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear all,<br>
<br>
I understand to not break back-compatibility, but after 10 years waiting for an update of CS, I think we can (must) move forward to open the protocol to time domain applications, such as solar system science. Even if you were thinking to a minor release, I think this should be a 2.0 release to prepare the future (e.g. big data catalogs). Not to change the protocol in depth with theoretical things, but to be pragmatic and just add what is missing to do science with the protocol.<span class=""><br>
<br>
<br>
On 10/10/2017 09:28 AM, Marco Molinaro wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Jerome,<br>
can you expand a bit on this?<br>
<br>
I mean. I know epoch is critical, but having EPOCH<br>
as a query parameter may mean:<br>
<br>
- asking it to be a mandatory one: break back-compatibility<br>
</blockquote>
<br></span>
yes in the framework of a minor release. But is a minor release really useful ? I guess the old CS services didn't wait to be updated to implement modern stuff in order to be usable. Thus actual CS services may already not be fully compliant with the old specification.</blockquote><div><br></div><div>I may be wrong, but I don't remember getting many </div><div>reports on things that needed to be changed in SCS</div><div>before Sydney's interop, when the DALI inconsistency </div><div>was raised.</div><div><br></div><div>Same for additional features.</div><div>That's probably because the mandates in SCS-1.03</div><div>are really a minimal set, so working on optional ones</div><div>is quite easy.</div><div>And this may explain also the compliance issue, </div><div>as far as OPS-WG reports on that.</div><div><br></div><div>So, minor vs. major is a point (even if we're not all</div><div>on the same lines) while I would consider EPOCH</div><div>a valid feature request to be discussed. That's why</div><div>I was asking form more details.</div><div><br></div><div>One point a disagree is that on "CS services didn't </div><div>wait to be updated...". </div><div>We're a community, building interoperable standards.</div><div>We are of course free to work on our custom preferred </div><div>solutions, starting or not from the above standards.</div><div>But then, if we don't report back our needs or work, </div><div>it makes hardly sense to complain the standards </div><div>are old because they don't speak about what we</div><div>didn't ask for.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- letting it be optional: will this be enough for your use cases?<br>
</blockquote>
<br></span>
yes, it's enough. But is it so breaking for an old service to not take care of a new parameter? I think no more than a service that uses an unspecified parameter (e.g. Skybot uses the EPOCH parameter for 10 years and no human complained, just machines ;) )</blockquote><div><br></div><div>I have no way to tell what efforts and resources are needed</div><div>at each data providers' side. That's why there's discussion</div><div>on how to move on and that's why I'm asking for requirements</div><div>and participation in the task.</div><div><br></div><div>As for EPOCH, it's been there 10 years in Skybot ... only(?).</div><div>Having it as an _optional (SHOULD) but standardized query </div><div>parameter_ is different than not having it there at all.</div><div><br></div><div>It's different because it tells service providers to think about it. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">- require service to transform internal epoch to client required one?<br>
</blockquote>
<br></span>
no, the client provide an epoch (ISO format or julian day) to the service which uses it to compute the positions of the celestial objects (planets, stars, ...) in order to select those which actually belong to the FOV, so that the client can cross-match the sources and then identify them. In the output the epoch is just recalled in a param element.<br></blockquote><div><br></div><div>So, I badly explained myself.</div><div>You're really asking that server-side the response positions </div><div>are re-calculated based on the EPOCH value in the query.</div><div>This is the additional effort that would be required to data providers</div><div>if we add and/or mandate this parameter.</div><div><br></div><div>Thanks for the added information!</div><div><br></div><div>Cheers,</div><div> Marco</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
cheers<br>
jerome<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
While, if you simply ask to have epoch information<br>
in the response I thought the VOTable-1.3 erratum 1<br>
went that way, so maybe that's something to<br>
enforce.<br>
<br>
Cheers,<br>
Marco<br>
<br>
<br></span>
2017-10-10 1:41 GMT+02:00 JBerthier <<a href="mailto:jerome.berthier@obspm.fr" target="_blank">jerome.berthier@obspm.fr</a> <mailto:<a href="mailto:jerome.berthier@obspm.fr" target="_blank">jerome.berthier@obspm.<wbr>fr</a>>>:<div><div class="h5"><br>
<br>
Dear all,<br>
<br>
From my point of view of CS provider (Skybot service), the key<br>
point is the addition of the EPOCH parameter. Without this<br>
parameter, a solar system CS service is unusable, as Skybot is in<br>
the next release of Aladin. Moreover, with the coming of big<br>
catalogs such as Gaia, this parameter will become mandatory to query<br>
the sky at a given epoch. One of my ongoing project is to seek for<br>
solar system objects in the "Carte du ciel" plates, thanks to the<br>
Gaia catalog which will allow one to get star positions at the<br>
beginning of the XXth century with an accuracy equivalent to<br>
Hipparcos today. Without the EPOCH parameter it will not be possible<br>
to cross-match stars 100 years back from the reference epoch of the<br>
catalog.<br>
<br>
cheers<br>
jerome<br>
<br>
<br>
<br>
<br>
<br>
On 10/09/2017 02:26 PM, Marco Molinaro wrote:<br>
<br>
Dear all,<br>
at the oncoming Interop in Santiago I will give a quick status<br>
report<br>
on the Simple Cone Search revision task.<br>
<br>
I just fixed a couple of sentences and typos in the internal WD<br>
built<br>
in July and I attach it here for you.<br>
<br>
Discussion points are still the same.<br>
I would say that<br>
1 - ReST vs. query_param access_url<br>
2 - RESOURCE type="results" and multiple RESOURCEs<br>
3 - minor vs. major revision<br>
<br>
are the main ones, while<br>
4 - trying or not to use UCD1+<br>
<br>
can be left out until/if we tackle number 3.<br>
<br>
As for the "§2.3b INFO element error validation" issue, I set up an<br>
Erratum that should take care of it<br>
(<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Err-1" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bi<wbr>n/view/IVOA/SCS-1_03-Err-1</a><br></div></div>
<<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/SCS-1_03-Err-1" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bi<wbr>n/view/IVOA/SCS-1_03-Err-1</a>>).<span class=""><br>
<br>
The full view on Cone Search is available starting at<br>
<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/ConeSearch" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bin<wbr>/view/IVOA/ConeSearch</a><br>
<<a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/ConeSearch" rel="noreferrer" target="_blank">http://wiki.ivoa.net/twiki/bi<wbr>n/view/IVOA/ConeSearch</a>><br>
<br>
Every comment and contribution is welcome and appreciated.<br>
I especially ask cone search providers and apps developers<br>
to join this task to update this block of the DAL landscape.<br>
<br>
Cheers,<br>
Marco<br>
<br>
PS - this is a DAL internal WD, but Apps is alerted for obvious<br>
reasons<br>
PPS - detailed revisions can be followed also on volute<br>
<br>
<br>
-- --- Dr. Jerome Berthier ------------------ Phone: <a href="tel:%2B33%20%280%2914051%202261" value="+33140512261" target="_blank">+33 (0)14051 2261</a><br></span>
<tel:%2B33%20%280%2914051%2022<wbr>61> --<br>
Institut de mecanique celest<br>
<<a href="https://maps.google.com/?q=itut+de+mecanique+celest&entry=gmail&source=g" rel="noreferrer" target="_blank">https://maps.google.com/?q=it<wbr>ut+de+mecanique+celest&entry=<wbr>gmail&source=g</a>>e Fax: <a href="tel:%2B33%20%280%2914633%202834" value="+33146332834" target="_blank">+33 (0)14633 2834</a> <tel:%2B33%20%280%2914633%2028<wbr>34> --<span class=""><br>
77 av. Denfert Rochereau Mailto:<a href="mailto:jerome.berthier@imcce.fr" target="_blank">jerome.berthier@imcce.f<wbr>r</a><br></span>
<mailto:<a href="mailto:jerome.berthier@imcce.fr" target="_blank">jerome.berthier@imcce.<wbr>fr</a>> --<span class=""><br>
--- 75014 Paris - France --------------------- <a href="http://www.imcce.fr/" rel="noreferrer" target="_blank">http://www.imcce.fr/</a> --<br>
<br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
--- Dr. Jerome Berthier ------------------ Phone: <a href="tel:%2B33%20%280%2914051%202261" value="+33140512261" target="_blank">+33 (0)14051 2261</a> --<br>
Institut de mecanique celeste Fax: <a href="tel:%2B33%20%280%2914633%202834" value="+33146332834" target="_blank">+33 (0)14633 2834</a> --<br>
77 av. Denfert Rochereau Mailto:<a href="mailto:jerome.berthier@imcce.fr" target="_blank">jerome.berthier@imcce.f<wbr>r</a> --<br>
--- 75014 Paris - France --------------------- <a href="http://www.imcce.fr/" rel="noreferrer" target="_blank">http://www.imcce.fr/</a> --<br>
</div></div></blockquote></div><br></div></div>