SimpleDALRegExt 1.2 WD

[Margarida Castro Neves]

Hi all,



> On 13. Mar 2020, at 10:13, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Hi Registry,
> 
> 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.
> 


I’ve implemented this in SPLAT, so that when querying registries, SPLAT can classify the services as spectrum or time series services.

A preliminary version can be found here:  http://soft.g-vo.org/splat-beta/splat-vo-3.15_2beta.jar <http://soft.g-vo.org/splat-beta/splat-vo-3.15_2beta.jar>


Margarida




> 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

—

Margarida Castro Neves

German Astrophysical Virtual Observatory (GAVO)
Astronomisches Rechen-Institut (ARI)
Zentrum für Astronomie, Universität Heidelberg  (ZAH)
Mönchhofstr. 12 - 14, 69120 Heidelberg
phone +49-6221-54-1891   fax +49-6221-54-1888
mcneves at ari.uni-heidelberg.de
http://www.ari.uni-heidelberg.de






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20200422/e68736d9/attachment.html>