SimpleDALRegExt 1.2 WD
Margarida Castro Neves
mcneves at ari.uni-heidelberg.de
Mon Feb 24 13:43:17 CET 2020
Hi all,
> On 19. Feb 2020, at 14:44, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>
> 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.
This is one of the issues I’ve addressed at my talk about TimeSeries at the Paris Interop.
It would make the time series discovery in SSAP much easier.
>
>> 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&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 adding DataproductType as metadata to SSA capability would indeed make things easier, and I would implement it in SPLAT.
But later on it would be good to be able to query services for other protocols for the data product type.
>
> 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
Margarida
—
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/20200224/bbcf486d/attachment.html>
More information about the registry
mailing list