Draft note on STC in the Registry

[Arnold Rots]

I have a few comments.

First, I think we need to define the role of the coverage information
in the registry, and specify the requirements.
If the spatial coverage is supposed to provide a rough estimate,
of the order of 1 deg and not provide an authoritative answer to
whether any particular position is included, then a low-order MOC,
as proposed by Markus, is perfectly acceptable.
But it should be absolutely clear that any queries against it do not
guarantee an accurate answer.
It seems to me that any resource should be able to provide an
authoritative answer, as a follow-up to the information provided
by the registry. And, frankly, and STC-S (not STC-X) string is, so
far, the only mechanism that can deliver. And there is no reason
not to restrict the options that can be used - in ADQL the shapes
have been limited to circle and polygon, for instance.
We did come quite a way to a Working Draft - until one of the
authors decided to drop the idea, so it could be taken up again,
with a specification of multiple layers of completeness in
implementation.
Using a MOC for high precision coverage applications is problematic
because it means that the server has to anticipate the client's
requirements in this area. Another issue is that MOCs generated
for catalogs generally reflect the distribution of the catalog's
records, not the true coverage of the catalog.

One more item about spatial coverage: we need to make sure
that we are not painting ourselves into a corner, restricting the
coordinates to ICRS. Galactic will come and if we want to have
appeal to the solar system community, that will require more
flexibility - which means that a reference position is needed, too,
but possibly only for solar system frames.

As to time, MJD is fine, but the combination of BARYCENTER and
TT is an oxymoron. I would advocate BARYCENTER-TDB,
GEOCENTER-TT and TOPOCENTER-TT. I will grant you that
the difference is minimal if one is using one-day precision, but
anything adopted here is going to creep into other systems that
require higher time precision and there we would end up with
what is essentially a defective standard.

I still regret the use of wavelength as the spectral coordinate.
Either frequency or energy have solid physical meaning and
do not require the extra caveat "in vacuo".

Yes, there is redshift, or Doppler velocity, and it is neither a
true geometric distance, nor a tru space velocity, nor a
spectral coordinate.
I know that some people look at me like I have two heads,
or something, when I say that, but I am hardly alone in this.
Cf., A&A 401,1185 (2003).
This is a legitimate type of coordinate and even though the
range may not be the most important piece of information,
the resolution certainly is: a segment of the user community
has a very good reason wanting to know whether Doppler
velocity information is available in a resource and at what
resolution.

I will leave it at that, for now.

Cheers,

  - Arnold

-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Mon, Jan 29, 2018 at 10:51 AM, Ada Nebot <ada.nebot at astro.unistra.fr>
wrote:

> Hi Markus,
>
> Thanks a lot for this Note!
> I forward your email to the TDIG for comments since I think it is of
> interest to the Time Domain community.
>
> I can see that the idea is to combine spatial, wavelength and temporal
> coverages to discover data.
> 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.
>
> 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.
>
> Section 4
> 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.
>
> 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
> https://www.iau.org/public/themes/naming/#inss
>
> Non electromagnetic coverage? Again, we thought about this in the time
> domain context and it might be useful to add Neutrino and GWs.
>
> Thanks,
> Ada
>
>
> On 17 Jan 2018, at 10:58, Markus Demleitner <msdemlei at ari.uni-heidelberg.
> de> wrote:
>
> Dear colleagues,
>
> Those who attended our session in Shanghai may remember my talk on
> how we can finally get proper STC queries against the Registry --
> http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-Reg/reg-stc.pdf
>
> I've finally done the various implementation parts to try everything
> out in DaCHS and the relational registry (at this point, it's only on
> the Heidelberg mirror, since harvesting the MOCs is quite a bit of
> pain).
>
> Based on that experience, I'd now propose a roadmap for how we could
> move towards more-or-less universal declaration of coverages in
> space, time, and spectrum for the VO Registry.  I've drafted
> a Note that I'd like to upload to the document repository -- probably
> some time next week unless you want more time for discussions.
>
> A draft of the note is available from
> http://docs.g-vo.org/regstcnote.pdf, the sources (that you're welcome
> to work on) are in volute at
> https://volute.g-vo.org/svn/trunk/projects/registry/regstcnote
> -- this includes a copy of the modified VODataService schema that
> will later be part of the upload.
>
> After this, I'd be grateful if you (yes, you!) could
>
> (a) briefly review the thing to and protest quickly if you strongly
> disagree with the main points of the note?  Ideally, I'd like the
> note to represent the "rough consensus" that's traditionally half of
> the RFC process (the other part being "running code").
>
> (b) perhaps look a bit deeper at the stuff if you're interested a bit
> more in the registry/STC borderline.  If you still feel comfortable
> with the note then, I'd be happy to include you on the author list.
> I feel a bit odd being the only author on something fairly
> wide-reaching, and certainly some of you out there had important
> roles in shaping what's written there during the past six years or so
> (yeah: according to RegTAP WD-20121112, it removed a first version of
> this...).  So: If you can see your name on this note, just drop me a
> note, and don't be shy or overly modest.
>
> Thanks,
>
>            Markus
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20180130/f87d9cbc/attachment-0001.html>