<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi all,<br>
<br>
First of all, thanks Markus for this note
(<a class="moz-txt-link-freetext" href="http://docs.g-vo.org/regstcnote.pdf">http://docs.g-vo.org/regstcnote.pdf</a>). On my point of view it is a
pragmatic approach of coverage manipulation challenge which has a
good chance to be implemented and used. I agree for most of the
suggestions. I just highlight these points :<br>
<ol>
<li><b>"double precision"</b> : Our experience on MOCs has shown
us that the coverage is never enough accurate for the users.
The approach to have two levels of precision - a low precision
coverage inside registry, and possibly a high one outside via
URL - is certainly a very good thing.<br>
My question : I imagine that we could have the same need for
time coverage, and may be for energy coverage. See point 5<br>
</li>
<li><b>T</b><b>able or catalog coverage ?</b> Presently, the
"FOOTPRINT" element (cf end of the section 2.2) is dedicated
to the global resource. The problem: for catalogs containing
several tables it is actually not possible to know each
individual table coverage. I would suggest that this IVOA note
will propose something to fix this issue.<br>
</li>
<li><b>MOC frame</b> (related to section 4.1-b) IVOA provides
now several data collection (tables or HiPS) dedicated to
planets. In the case of HiPS, we have had already to introduce
new reference coordinate system as a list of planet names
(hips_frame=mercury, venus, moon, mars, mimas, etc...). This
solution works fine for HiPS, but as a HiPS is distributed
with its associated MOC, it means that these associated MOCs
are not celestial, but planet dependent. It could be a good
thing if we use the same controlled vocabulary for HiPS, MOCs
and registry.<br>
</li>
<li><b>MOC ASCII</b> => see my previous mail concerning the
MOC ASCII serialization.<br>
<br>
</li>
<li><b>Temporal MOC</b>. We are starting to explore the idea of
a temporal MOC. In one word - but probably more at the next
IVOA meeting - it would be the same logic of a spatial MOC but
for time based, not HEALPix dependent, but based on a fix
reference time system and unit (JD - barycenter - in fact
identical to 2.1 definition). Having a list of MJD ranges as
internal registry coverage will immediately allow us to build
corresponding "TMOC" (and may be later and extension of the
MOCserver also time oriented). So I would applause the usage
of collections of MJD ranges for describing time coverage.</li>
</ol>
Cheers<br>
Pierre<br>
<br>
Le 17/01/2018 à 10:58, Markus Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20180117095842.r3tyz6wfs2cvxctu@victor">
<pre wrap="">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 --
<a class="moz-txt-link-freetext" href="http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-Reg/reg-stc.pdf">http://wiki.ivoa.net/internal/IVOA/InterOpMay2017-Reg/reg-stc.pdf</a>
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
<a class="moz-txt-link-freetext" href="http://docs.g-vo.org/regstcnote.pdf">http://docs.g-vo.org/regstcnote.pdf</a>, the sources (that you're welcome
to work on) are in volute at
<a class="moz-txt-link-freetext" href="https://volute.g-vo.org/svn/trunk/projects/registry/regstcnote">https://volute.g-vo.org/svn/trunk/projects/registry/regstcnote</a>
-- 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
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>