Draft note on STC in the Registry

[Markus Demleitner]

Hi

[Keeping the wide crosspost because the point below is actually
distinct from STC and has links to the other WGs; more specific
followup (DM or Registry as applicable, I'd say) still suggested]

On Thu, Feb 01, 2018 at 03:28:34PM -0500, Arnold Rots wrote:
> On Wed, Jan 31, 2018 at 7:06 AM, Markus Demleitner <
> msdemlei at ari.uni-heidelberg.de> wrote:
> > If we wanted to have more wide-reaching requirements, I'd say we
> > first need credible use cases from which to derive them.  If you have
> > some, this would be the perfect time to bring them up and add them to
> > the Note's introduction (which, of course, applies to everyone).
> 
> No need for a snarky reply here: I was just saying that if we agree that

This wasn't meant to be snarky -- sorry if it sounded as if it were.
I'm serious: please contribute as many use cases for the next
VODataService version as you have.  The safest way to get a good
standard is to start from a comprehensive set of use cases and then
make an informed choice on where to find the optimal compromise
between power and simplicity.

> > > 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.
> >
> > Could you provide a use case for that?
> >
> 
> For one thing, someone who is interested in, let's say, 3-D cubes
> with Doppler velocity as one of its axes should be able to find out
> from the registry whether a particualr resource is able to deliver
> such data. And this is very distinct from the interest of users who
> are interested in spectral information, either of the kind of SEDs,
> or in line equivalent widths.

For catalogs, VODataService's tableset does this kind of thing.  The
"catalogs with redshift" use case indeed has been one of the example
queries in the RegTAP standard[1], and I've recently blogged a
somewhat more advanced example using this facility for discovering
resources on Teffs in multiple star systems[2].

Trouble is: we don't have the equivalent of tableset for services
producing datasets.  I'd say the *content* of obscore services would
be a good target for a content model (SIAP and SSAP would probably be
easy to derive from that, once that exists).  Essentially, it would
have to characterise the datatype(s) available from the service.

It would be great if people could brainstorm a bit on how to (if to?)
teach the registry to speak about datasets in services (that's
certainly related but not identical to the Cube DM).  Again, the
important thing would be to collect use cases.  Arnold's use case,
for instance, would already be coverable if we had an element like

<instanceData>
  <axisUCD>pos.eq.ra</axisUCD>
  <axisUCD>pos.eq.dec</axisUCD>  (where we'd probably need to be more
    general for spatial axes)
  <axisUCD>em.wl</axisUCD>
  <observableUCD>phot.flux.density;em.wl</observableUCD>
  <observableUCD>stat.error;phot.flux.density;em.wl</observableUCD>
</instanceData>

(for a service that spits out spectral cubes with flux errors).

What this wouldn't cover, for instance, is "find spectral cubes with
a spectral resolution larger than 2000".  Should the registry be able
to do this?  Is it ok to leave that to the data discovery protocols?

If you're interested in coming up with another VODataService
1.2 preparatory note discussing this kind of thing: I'd be in, though
perferably not as editor.

        -- Markus

[1] http://ivoa.net/documents/RegTAP/20141208/REC-RegTAP-1.0.html#tth_sEc10.4
[2] https://blog.g-vo.org/say-hello-to-regtap/