<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 31, 2018 at 7:06 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Apologies for the wide cross-post; I'd invite follow-ups to<br>
Registry; for those that don't know what this is about: discussion<br>
started at <a href="http://mail.ivoa.net/pipermail/registry/2018-January/005226.html" rel="noreferrer" target="_blank">http://mail.ivoa.net/<wbr>pipermail/registry/2018-<wbr>January/005226.html</a>]<br>
<br>
Hi Arnold,<br>
<span class=""><br>
On Tue, Jan 30, 2018 at 02:13:36PM -0500, Arnold Rots wrote:<br>
> First, I think we need to define the role of the coverage information<br>
> in the registry, and specify the requirements.<br>
<br>
</span>Exactly. Now, since the way from the use cases in the Note's<br>
introduction to the actual features isn't that long, I've skipped<br>
writing out requirements explitly.<br>
<br>
If we wanted to have more wide-reaching requirements, I'd say we<br>
first need credible use cases from which to derive them. If you have<br>
some, this would be the perfect time to bring them up and add them to<br>
the Note's introduction (which, of course, applies to everyone).<br></blockquote><div><br></div><div>No need for a snarky reply here: I was just saying that if we agree that<br></div><div>the registry provides a rough non-authoritative answer to a coverage<br></div><div>query, your low order MOC is the right mechanism<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> It seems to me that any resource should be able to provide an<br>
> authoritative answer, as a follow-up to the information provided<br>
> by the registry. And, frankly, and STC-S (not STC-X) string is, so<br>
<br>
</span>Well, that's the actual data query, via SIAP, TAP, or whatever, no?<br>
Or do you see a need for a third layer between service discovery and<br>
dataset discovery?<br></blockquote><div><br></div><div>Well, no. I am talking here about a high-fidelity coverage query which<br></div><div>is not explicitly provided in the IVOA arsenal, but a very common<br></div><div>query for archives. Sure, that's not a registry question, but closely<br></div><div>related.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Using a MOC for high precision coverage applications is problematic<br>
> because it means that the server has to anticipate the client's<br>
<br>
</span>The question of general spatial representation(s) in VOTables or<br>
other places is distinct from what we're dealing with here. I'd like<br>
to avoid burdening the question of STC-capable registries with any<br>
wider-reaching STC discussion (except we need to make sure we're<br>
roughly in line). If we agree that MOCs in VOTable cells are a good<br>
idea, let's move along with them. Of course, if people see problems<br>
with *that* particular aspect, now is when we should discuss it.<br>
<span class=""><br>
> One more item about spatial coverage: we need to make sure<br>
> that we are not painting ourselves into a corner, restricting the<br>
> coordinates to ICRS. Galactic will come and if we want to have<br>
<br>
</span>As I'm writing in the note:<br>
<br>
On the side of registries trying to process VODataService~1.1<br>
coverage information, dealing with the STC-X embedded within the<br>
resource records was made difficult by the large feature set of<br>
STC-X, where coverages could be provided in a myriad of reference<br>
frames and shapes that needed to be unified to standard systems<br>
before they could meaningfully be searched.<br>
<br>
-- now, true, it's trivial to convert Galactic to ICRS, but then<br>
there's really no reason to put that burden on the Registries. For<br>
almost all other frames, the authors of the registry record are in a<br>
much better position to convert whatever celestial reference frames<br>
they use to ICRS then a harvesting registry is.<br>
<br>
In actual usage, we'll need a uniform frame anyway -- have a look at<br>
the example queries and try to imagine what they'd look like if we<br>
let in other celestial frames (even if it were just Galactic and<br>
ICRS). Note that the "magic" conforming (as in<br>
CONTAINS(POINT('ICRS'), CIRCLE('GALACTIC'))) forseen in ADQL 2.0 was<br>
identified a pain in implementation and a trap for users, so it's no<br>
longer part of ADQL 2.1.<br>
<span class=""><br>
> appeal to the solar system community, that will require more<br>
> flexibility - which means that a reference position is needed, too,<br>
> but possibly only for solar system frames.<br>
<br>
</span>That's a different issue -- as planned in the parent message, I'm now<br>
proposing to reserve an extra column for such non-celestial use<br>
(Volute rev. 4729). The corresponding open question is now:<br>
<br>
\paragraph{Other reference systems?} We currently require all<br>
spatial coordinates to be in the ICRS. This obviously is not enough<br>
whenever objects move fast against the ICRS, as for instance for solar<br>
system objects and, in particular, their surface features and the like. To<br>
enable future extensions to cover these domains, a column<br>
\verb|ref_system_name| must currently always be filled with<br>
\texttt{NULL} on the service side, and clients must always constrain<br>
coverage queries with a \verb|ref_system_name IS NULL| condition.<br>
<br>
Is this enough to cover forseeable and plausible use cases? Should we<br>
write \verb|'ICRS'| rather than \texttt{NULL} already, and then perhaps<br>
already define some system names we already have resources for? Given<br>
it will be present in almost all STC queries, should we have a less<br>
verbose name than \verb|ref_system_name|?<br>
<br>
Comments on this are highly welcome.<br></blockquote><div><br></div><div>I would prefer to be explicit about this. One of my concerns is that<br></div><div>practices that are perfectly acceptable for registry usage may (or will)<br></div><div>be carried over to other interfaces where they are not acceptable.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> As to time, MJD is fine, but the combination of BARYCENTER and<br>
> TT is an oxymoron. I would advocate BARYCENTER-TDB,<br>
<br>
</span>Well, BARYCENTER-TT is straightforward to define and compute, which is<br>
why it was my first choice. But I won't quarrel about split seconds,<br>
and I see that we might be setting an unfortunate precedent here, so<br>
I've changed TT to TDB in the document.<br>
<span class=""><br>
> GEOCENTER-TT and TOPOCENTER-TT. I will grant you that<br>
<br>
</span>Again, we have to use a uniform system if we want to enable global<br>
discovery, and again the harvesting registries are in a much worse<br>
position than the record record authors to perform the<br>
transformation(s) -- actually, they can't do them at all most of the<br>
time.<br>
<br>
So, for Registry purposes we'll have to choose one. From what I've<br>
seen, people who care about reference positions in their temporal<br>
metadata at all tend to choose BARYCENTER and then whatever time<br>
scale their instruments happen to use. Making things easy for them<br>
will -- I hope -- increase the chances we'll actually see such<br>
metadata in the Registry (which we currently don't).<br></blockquote><div><br></div><div>I am not convinced that people will actually perform a proper<br></div><div>transformation and I agree that for most registry records it does<br></div><div>not matter one bit. However, what would be useful (I think) in the<br></div><div>registry is information on the resource's native system: it will tell<br></div><div>the user (if interested in high-precision timing) how to query the<br></div><div>specific resource. That would really be a useful piece of information.<br></div><div>And one might argue that the same would apply to spatial<br></div><div>coordinates - provide the native reference frame and reference<br>position to tell the user hwat's the best way to approach the resource.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I still regret the use of wavelength as the spectral coordinate.<br>
> Either frequency or energy have solid physical meaning and<br>
> do not require the extra caveat "in vacuo".<br>
<br>
</span>So do I. But unless many more people speak up that it's time to fix<br>
that wart in the VO and promise to help out, switching to energy<br>
would be little more than the first step in an XKCD 927 process:<br>
<a href="https://xkcd.com/927/" rel="noreferrer" target="_blank">https://xkcd.com/927/</a><br>
<span class=""><br>
> the resolution certainly is: a segment of the user community<br>
> has a very good reason wanting to know whether Doppler<br>
> velocity information is available in a resource and at what<br>
> resolution.<br>
<br>
</span>Could you provide a use case for that?<br></blockquote><div><br></div><div>For one thing, someone who is interested in, let's say, 3-D cubes<br></div><div>with Doppler velocity as one of its axes should be able to find out<br></div><div>from the registry whether a particualr resource is able to deliver<br></div><div>such data. And this is very distinct from the interest of users who<br></div><div>are interested in spectral information, either of the kind of SEDs,<br></div><div>or in line equivalent widths.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is this comparable to the role resolution plays in spectra discovery?<br>
There, we've so far relied on the dataset discovery (i.e., SSAP and<br>
Obscore) protocols to let people constrain resolutions. I *suspect*<br>
that's right at least in this case, as the resolutions of spectra<br>
within a single service (which for now can stand for "resource") can<br>
be so dramatically different that "spectral resolution" isn't a<br>
meaningful concept on the resource level, and "range of spectral<br>
resolutions" is too large to be useful.<br>
<br>
On the other hand, there aren't many discovery cases that do not, in<br>
some sense, involve quality measures (limiting magnitude, SNR,<br>
resolution). The Registry so far doesn't really talk about these,<br>
even where (as for limiting magnitude) they are clearly properties<br>
on the resource level at least for some resources (e.g., many<br>
catalogs).<br>
<br>
I can't honestly say I'll try to do something about such quality<br>
measures, but I'd consider them to be roughly in scope for this note.<br>
If anyone wanted to contribute text for them: The SVN is at<br>
<a href="https://volute.g-vo.org/svn/trunk/projects/registry/regstcnote" rel="noreferrer" target="_blank">https://volute.g-vo.org/svn/<wbr>trunk/projects/registry/<wbr>regstcnote</a><br>
(feel free to commit to trunk, but if you prefer to branch, do that).<br>
<br>
Meanwhile, an updated build of the draft Note with the changes coming<br>
out of the recent discussions (thanks to all participants!) is at<br>
<a href="http://docs.g-vo.org/regstcnote.pdf" rel="noreferrer" target="_blank">http://docs.g-vo.org/<wbr>regstcnote.pdf</a>. I'll postpone publishing it to<br>
the document repo as long as there's still discussion going on.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br></div></div>