VO registry in practice- we have another small problem

[Markus Demleitner]

Hi Apps, Hi Registry,

[Again, I'd suggest to direct further discussion to
registry at ivoa.net]

On Thu, May 18, 2017 at 08:58:26AM +0200, Pierre Fernique wrote:
> Still related to the Aladin v10 developement, another point that I would
> like emphasize concerns *the current impossibility to declare a table
> coverage in the VO registry*. Presently one can define a unique coverage at
> catalog level, but not for individual table.

Well, the Registry is talking about "resources", but I'll give you
our standards don't really help you figure out what a resource is
supposed to be, in particular when matters become a bit gray.

To have a brief illustruation, suppose you're building the archive of
an observatory.  You could:

(1) lump together everything into a single obscore table, registering
it as "My obs archive"

(2) Put all spectra in an SSA service ("My obs spectra"), all images
in SIA service(s).  If you have further products (e.g., extracted
sources or line lists), you could datalink these to their source
images.

(3) Have separate services for each observation programme ("Minor
planet watch at My Obs"), and perhaps have extra SCS services per
publication ("LBVs observed at My Obs, 1967-2017").

(4) As (3), but perhaps some of the publications have several
"tables" that have significantly different properties ("Extension to
My Obs LBV monitoring, south part, taken at the ESO Icelandic
Telescope").

All of these strategies can be justified, possibly in parallel; and
that not only depends on "the VO" but also on the nature of your
data.

As a working proposal for a guideline to "What's a resource" I'd say

  "A VO Resource is a data collection (including its data access
  services) that has homogeneous metadata for discovery purposes
  (title, authors, publishers, ...; for STC coverage, the registry
  resolution should be assumed to be about a degree in space, a day
  in time, and 100 in spectral).

-- where I just pulled those numbers out of thin air, so protest if
you disagree.

> However, a lot of catalogs are splitted in various tables which have their
> own coverage. For instance I show below the Gaia DR1 catalog, and its 6
> tables with the associated MOCs.

Because authors (and other metadata) differ greatly between these six
tables, I'd say they should be registered separately in the first
place; there's a clear discovery use case that you would, for
instance, expect the Cepheid data to come up when you look for
variable stars, but DR1 clearly not.

There's nothing wrong with having a Gaia DR1 data record (perhaps
with a table schema comprising all tables and an auxiliary TAP
capability), which is then linked with HasPart relationships to the
individual resources.  But that should, at least by the discovery
scenario test, not be the primary means of discovery.

        -- Markus

[I mention in passing that at least the GAVO DC has been registering
the DR1 tables we carry in this way from the start:

TGAS has a record at
http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/tgas/q/main
(with an AllSky coverage), the source catalog is
http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/gaia/q/dr1
(and AllSky, too, so it's a bit boring; not sure why I didn't give
temporal coverage at the time).]