SimpleDALRegExt 1.2 WD

[Markus Demleitner]

Hi Ada,

On Tue, Feb 18, 2020 at 02:49:01PM +0100, ada nebot wrote:
> I was wondering, would this also be the place for describing
> services providing timeseries ? 

Where these services are SSAP services, definitely yes.  Obscore is a
different matter (I'd say one for VODataService).

> Since there are a number of services distributing those it would be
> great to be able to discover them as such… 

Definitely.

> What would we need to add / change for that? 

Well, essentially some piece of metadata that lets a client like
SPLAT work out that the service won't give it spectra but time
series.  That way, it could have a selector like

  () Observational Spectra
  () Theoretical Spectra
  () Time Series

in the SSA search dialogue (that currently only has the first two).
I'm less sure how this would look like in pyVO's regsearch function.
I don't think we want to fold this into servicetype, and another
keyword argument is probably too confusing.  Perhaps we'll get by
just exposing a dataproduct_type attribute on the registry record
returned and let programs filter themselves?

If we roughly agree on that (Do we?  Client authors, do you expect
that'll work for your users?), the question is how we do it.

Splat's current dialogues are fed from two pieces of SimpleDALRegExt
SSA metadata[1]:

* DataSource (with values "survey" | "pointed" | "custom" | "theory"
  | "artificial")
* CreationType (with values "archival" | "cutout" | "filtered" |
  "mosaic" | "projection" | "spectralExtraction" | "catalogExtraction")

Both seem to be orthogonal to whether or not something is a time
series or a spectrum.

Given that, I believe the way of least specification effort would be
to add an optional dataproductType element that takes values as
dataproduct_type in obscore (and would, I'm afraid, have to be
repeatable).  If not given, clients should assume spectrum (for
backwards compatibility).  So, for instance the K2C9 followup service
(http://dc.zah.uni-heidelberg.de/k2c9vst/q/ssa/info) would declare
its capability like

  <capability standardID="ivo://ivoa.net/std/SSA" xsi:type="ssap:SimpleSpectralAccess">
    <interface role="std" xsi:type="vs:ParamHTTP">
      <accessURL use="base">http://dc.g-vo.org/k2c9vst/q/ssa/ssap.xml?</accessURL>
      <mirrorURL>https://dc.g-vo.org/k2c9vst/q/ssa/ssap.xml?</mirrorURL>
      <queryType>GET</queryType>
      <resultType>application/x-votable+xml</resultType>
      <param std="true">
        <name>TIME</name>
        <description>Time interval(s) of interest, in MJD.</description>
        <unit>d</unit>
        <dataType arraysize="*">char</dataType>
      </param>
      [and a zillion more of these]
    </interface>
    <complianceLevel>query</complianceLevel>
    <dataSource>pointed</dataSource>
    <creationType>archival</creationType>
    <supportedFrame>ICRS</supportedFrame>
    <maxSearchRadius>180</maxSearchRadius>
    <maxRecords>1000000</maxRecords>
    <defaultMaxRecords>10000</defaultMaxRecords>
    <maxAperture>180</maxAperture>

<!-- this is the new thing -->
    <dataproductType>timeseries</dataproductType> 

    <testQuery>
      <queryDataCmd>MAXREC=1&amp;REQUEST=queryData</queryDataCmd>
    </testQuery>
  </capability>

I think the RegTAP query that will pick these out is still
reasonable even if that just ends up in res_detail [though I notice
that having COLLATE in ADQL would again help].

What I particularly like about this with my Semantics hat on is that
this gives us a welcome excuse to finally put the list of terms
from Obscore p. 17 into a proper vocabulary...


There is an alternative proposition: We also still have VODataService
open.  And you might argue that clients for other protocols than SSAP
might also be interested in the type of data product returned.  So...
What if we added something like dataproductType to vs:DataResource?
I'd be severely tempted, because the type of data returned *should*
(by caproles-strong) not depend on the capability but is a property
of the data collection.

And once we are there, we might remember Pat's proposal
http://mail.ivoa.net/pipermail/dal/2019-December/008252.html
and perhaps even cover file formats so you could discover up front if
a service has FITSes or something else; that could then look like
this:

  <mediaType>application/fits;content=cube</metaType>
  <mediaType>application/x-hdf5;content=cube</metaType>

for a service that has cubes in both FITS and HDF5.

Opinions, preferences?  Counter-proposals?

I think the SSAP time series thing is fairly important at this point,
and so unless someone speaks up for a more comprehensive solution, as
a minimal default I'll put into SimpleDALRegExt
capability/dataproductType and ask the SPLAT folks to try if it works
for them.

      -- Markus


[1] Here's the current metadata model for SSA capabilities from
SimpleDALRegExt 1.1:
http://docs.g-vo.org/schemadoc/schemas/SSA-v1_1_xsd/complexTypes/SimpleSpectralAccess.html