Draft note on STC in the Registry

[Markus Demleitner]

Hi Pierre,

On Mon, Jan 29, 2018 at 04:50:04PM +0100, Pierre Fernique wrote:
> 1. *"double precision"* : 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.
>    My question : I imagine that we could have the same need for time
>    coverage, and may be for energy coverage. See point 5

I'll publicly state that I'm unconvinced that there are compelling
discovery use cases in which that precision actually is required --
after all, this is just a first step to weed out services obviously
not worth querying.  The actual dataset discovery is a second step,
and IMHO it's fine if quite a few of the services discovered in the
first step still return empty results.

But yeah, there are other uses for spatial coverage, and although I'd
like do away with the current coverage/footprint special case on the
long run and just use a capability (like /tables, /sync, or whatever)
for what it currently does, I don't dispute separate MOC endpoints
will have a place even after we will have inline coverage.

> 2. *T**able or catalog coverage ?* 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.

I'd still say that when tables have different coverages (in a
discovery sense[1]), they are different resources and thus have full
resource metadata of their own -- at least that's what our data model
right now, in effect, is.

We *could* add ranges and coverage-like information to tables (this
would be great for cross-service query planning in federated TAP
services, for instance) when revising VODataService.  But that goes
far beyond the scope of this note, and is, I'd claim, a different use
case.

If someone is interested in producing a note on that to topic in
preparation of VODataService 1.2 ("Improving column metadata in the
registry and in VOSI tables", say): Count me in (but this is too
little of an itch for me to make me an editor for such a note).


> 3. *MOC frame* (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.

Absolutely.  After Ada's mail, I've now put in ref_system_name
(Volute rev. 4729) in the Note and in reg.g-vo.org/tap.  Right now,
I'm saying "it's always NULL".  If we can already put in an initial
vocabulary, excellent.  We should, however, make sure that that
vocabulary is ok with whoever is working on our STC DM, too.


> 4. *MOC ASCII* => see my previous mail concerning the MOC ASCII
>    serialization.

Noted with gratitude (because I'm leaning towards ASCII MOCs, too);
given several voices leaning the other way, I'm leaving this in the
note as an open question.

> 5. *Temporal MOC*. 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.

Interesting idea.  Again I'd say these would simply be additional
capabilities: you'll define a standard for these, and that standard
would say: 

  If you have a TMOC associated with a resource, add an element like

    <capability standardId="ivo://ivoa.net/std/tmoc#negoatiated">
      <interface xsi:type="vs:WebBrowser">
        <accessURL>http://example.org/myarchive/access/tmoc</accessURL>
      </interface>
    </capability>


As far as RegTAP is concerned -- well, I'd again plead TMOCs probably
are too much for discovery (on the other hand: perhaps we should say
something about at how many intervals registry operators are entitled
to get upset?)  But it's certainly a very interesting idea once we
start thinking about a more general interval datatype in the VO.

Thanks for your input,

        Markus


[1] For instance: at a suffiently fine resolution a quasar catalog
with tables for "radio-quiet" and "radio-loud" will certainly have
different coverages, but when I want to learn about "quasars in my
field" I'm really interested in "have they looked for quasars here?"
and thus the common footprint is what I'm really interested in.