SimpleDALRegExt 1.2 WD

[Markus Demleitner]

Hi Registry,

On Mon, Feb 24, 2020 at 01:43:17PM +0100, Margarida Castro Neves wrote:
> > On 19. Feb 2020, at 14:44, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> > 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).
[...]
> >> 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).

So, I've now added a productType element to the SSA capability.  I've
not yet updated the WD on the doc repo, but you can check out 
http://docs.g-vo.org/SimpleDALRegExt.pdf, on page 20, or the schema
at
https://volute.g-vo.org/svn/trunk/projects/registry/SimpleDALRegExt/SSA-v1.3.xsd.

The net effect is that you can write one or more productType elements
in the SSA capability, as in 

  <capability standardID="ivo://ivoa.net/std/SSA" 
      xsi:type="ssap:SimpleSpectralAccess">
    <interface role="std" xsi:type="vs:ParamHTTP">
      <accessURL use="base"
        >http://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?</accessURL>
      <mirrorURL>
        https://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?</mirrorURL>
    </interface>
    <complianceLevel>query</complianceLevel>

    <productType>timeseries</productType>         <--- NEW

    <dataSource>survey</dataSource>
    <creationType>archival</creationType>
    <supportedFrame>ICRS</supportedFrame>
    ...
  </capability>

(cf.
http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/bgds/l/ssa
for the full record; you could have multiple productType elements,
but I've no resource that would need that).

I've already implemented support for this in DaCHS, and I've taught
the extra feature to the Heidelberg RegTAP service
(http://dc.g-vo.org/tap).  This means that you can search for
"declared" time series services with something like

   select ivoid from
    rr.capability
    natural join (select ivoid from rr.res_detail
      where 
        detail_xpath='/capability/productType'
        and detail_value='timeseries') as ts_ssa
    where
      standard_id='ivo://ivoa.net/std/ssa'

or, if you're doing a typical "get me all SSA services"-type query,
enrich your records with product_types information somewhat like this:

  select access_url, product_types, reference_url from
  rr.capability
  natural join rr.resource
  natural join rr.interface
  natural left outer join (select 
      ivoid, 
      ivo_string_agg(detail_value, '#') as product_types
    from rr.res_detail
    where 
      detail_xpath='/capability/productType'
    group by ivoid) as pt
  where
    standard_id='ivo://ivoa.net/std/ssa'

(where you'd do product_types="spectrum" where you get NULL or empty
strings).

I give you I've seen prettier queries, but I guess one can get used
to it, and it's really just a homeopathic change to standards
solving the time series discovery thing, so I'd say let's do it.

If you have an SSA service serving time series, would you just try
it?  You'll stay validatable if you point the schema location for 
http://www.ivoa.net/xml/SSA/v1.1 to
http://vo.ari.uni-heidelberg.de/docs/schemata/SSA-v1.3.xsd.


The one thing I don't particularly like about this proposal: By
caproles (http://ivoa.net/documents/caproles/ -- and no, I can't post
to Registry these days without linking to caproles), this is the
wrong level of modelling.  A resource with an SSA capability serving
time series, really, should serve time series through a TAP or
Browser capability as well.  And hence, productType really should sit
on the resource rather than than capability level.

So, the real question in my mind is: should we put productType into
VODataService right away, so it can also be used by obscore, SIAv2,
whatever services?  From a resource record author perspective, the
change would be that productType moves one XML level up.  In the
RegTAP query, you'd be using '/productType' rather than
'/capability/productType' -- no big deal on either side.

But: if it's in VODataService, we'd have to comment on what to do
when it's not there.  On SSA capabilities, that's simple: it's a
spectrum service.  On generic resources, its... complicated.

And that last thing -- clearly saying what a missing productType
means -- is what made me ignore the wisdom of caproles for a
pragmatic, perhaps-good-enough solution.  If you say we'll likely
regret that gung-ho approach, I'm perfectly willing to move
productType into VODataService (which hopefully will move into RFC
rather soon, too).

         -- Markus