<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div>Hi all,<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 19. Feb 2020, at 14:44, Markus Demleitner <<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Ada,<br class=""><br class="">On Tue, Feb 18, 2020 at 02:49:01PM +0100, ada nebot wrote:<br class=""><blockquote type="cite" class="">I was wondering, would this also be the place for describing<br class="">services providing timeseries ? <br class=""></blockquote><br class="">Where these services are SSAP services, definitely yes. Obscore is a<br class="">different matter (I'd say one for VODataService).<br class=""><br class=""><blockquote type="cite" class="">Since there are a number of services distributing those it would be<br class="">great to be able to discover them as such… <br class=""></blockquote><br class="">Definitely.<br class=""></div></div></blockquote><div><br class=""></div>This is one of the issues I’ve addressed at my talk about TimeSeries at the Paris Interop. </div><div>It would make the time series discovery in SSAP much easier.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">What would we need to add / change for that? <br class=""></blockquote><br class="">Well, essentially some piece of metadata that lets a client like<br class="">SPLAT work out that the service won't give it spectra but time<br class="">series. That way, it could have a selector like<br class=""><br class=""> () Observational Spectra<br class=""> () Theoretical Spectra<br class=""> () Time Series<br class=""><br class="">in the SSA search dialogue (that currently only has the first two).<br class="">I'm less sure how this would look like in pyVO's regsearch function.<br class="">I don't think we want to fold this into servicetype, and another<br class="">keyword argument is probably too confusing. Perhaps we'll get by<br class="">just exposing a dataproduct_type attribute on the registry record<br class="">returned and let programs filter themselves?<br class=""><br class="">If we roughly agree on that (Do we? Client authors, do you expect<br class="">that'll work for your users?), the question is how we do it.<br class=""></div></div></blockquote><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Splat's current dialogues are fed from two pieces of SimpleDALRegExt<br class="">SSA metadata[1]:<br class=""><br class="">* DataSource (with values "survey" | "pointed" | "custom" | "theory"<br class=""> | "artificial")<br class="">* CreationType (with values "archival" | "cutout" | "filtered" |<br class=""> "mosaic" | "projection" | "spectralExtraction" | "catalogExtraction")<br class=""><br class="">Both seem to be orthogonal to whether or not something is a time<br class="">series or a spectrum.<br class=""><br class="">Given that, I believe the way of least specification effort would be<br class="">to add an optional dataproductType element that takes values as<br class="">dataproduct_type in obscore (and would, I'm afraid, have to be<br class="">repeatable). If not given, clients should assume spectrum (for<br class="">backwards compatibility). So, for instance the K2C9 followup service<br class="">(<a href="http://dc.zah.uni-heidelberg.de/k2c9vst/q/ssa/info" class="">http://dc.zah.uni-heidelberg.de/k2c9vst/q/ssa/info</a>) would declare<br class="">its capability like<br class=""><br class=""> <capability standardID="<a href="ivo://ivoa.net/std/SSA" class="">ivo://ivoa.net/std/SSA</a>" xsi:type="ssap:SimpleSpectralAccess"><br class=""> <interface role="std" xsi:type="vs:ParamHTTP"><br class=""> <accessURL use="base"><a href="http://dc.g-vo.org/k2c9vst/q/ssa/ssap.xml?</accessURL>" class="">http://dc.g-vo.org/k2c9vst/q/ssa/ssap.xml?</accessURL></a><br class=""> <mirrorURL><a href="https://dc.g-vo.org/k2c9vst/q/ssa/ssap.xml?</mirrorURL>" class="">https://dc.g-vo.org/k2c9vst/q/ssa/ssap.xml?</mirrorURL></a><br class=""> <queryType>GET</queryType><br class=""> <resultType>application/x-votable+xml</resultType><br class=""> <param std="true"><br class=""> <name>TIME</name><br class=""> <description>Time interval(s) of interest, in MJD.</description><br class=""> <unit>d</unit><br class=""> <dataType arraysize="*">char</dataType><br class=""> </param><br class=""> [and a zillion more of these]<br class=""> </interface><br class=""> <complianceLevel>query</complianceLevel><br class=""> <dataSource>pointed</dataSource><br class=""> <creationType>archival</creationType><br class=""> <supportedFrame>ICRS</supportedFrame><br class=""> <maxSearchRadius>180</maxSearchRadius><br class=""> <maxRecords>1000000</maxRecords><br class=""> <defaultMaxRecords>10000</defaultMaxRecords><br class=""> <maxAperture>180</maxAperture><br class=""><br class=""><!-- this is the new thing --><br class=""> <dataproductType>timeseries</dataproductType> <br class=""><br class=""> <testQuery><br class=""> <queryDataCmd>MAXREC=1&amp;REQUEST=queryData</queryDataCmd><br class=""> </testQuery><br class=""> </capability><br class=""><br class="">I think the RegTAP query that will pick these out is still<br class="">reasonable even if that just ends up in res_detail [though I notice<br class="">that having COLLATE in ADQL would again help].</div></div></blockquote></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">What I particularly like about this with my Semantics hat on is that<br class="">this gives us a welcome excuse to finally put the list of terms<br class="">from Obscore p. 17 into a proper vocabulary...<br class=""><br class=""><br class="">There is an alternative proposition: We also still have VODataService<br class="">open. And you might argue that clients for other protocols than SSAP<br class="">might also be interested in the type of data product returned. So...<br class="">What if we added something like dataproductType to vs:DataResource?<br class="">I'd be severely tempted, because the type of data returned *should*<br class="">(by caproles-strong) not depend on the capability but is a property<br class="">of the data collection.<br class=""><br class="">And once we are there, we might remember Pat's proposal<br class=""><a href="http://mail.ivoa.net/pipermail/dal/2019-December/008252.html" class="">http://mail.ivoa.net/pipermail/dal/2019-December/008252.html</a><br class="">and perhaps even cover file formats so you could discover up front if<br class="">a service has FITSes or something else; that could then look like<br class="">this:<br class=""><br class=""> <mediaType>application/fits;content=cube</metaType><br class=""> <mediaType>application/x-hdf5;content=cube</metaType><br class=""><br class="">for a service that has cubes in both FITS and HDF5.<br class=""><br class="">Opinions, preferences? Counter-proposals?<br class=""></div></div></blockquote><div><br class=""></div>I think adding DataproductType as metadata to SSA capability would indeed make things easier, and I would implement it in SPLAT.</div><div><br class=""></div><div>But later on it would be good to be able to query services for other protocols for the data product type.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">I think the SSAP time series thing is fairly important at this point,<br class="">and so unless someone speaks up for a more comprehensive solution, as<br class="">a minimal default I'll put into SimpleDALRegExt<br class="">capability/dataproductType and ask the SPLAT folks to try if it works<br class="">for them.<br class=""><br class=""> -- Markus<br class=""><br class=""><br class="">[1] Here's the current metadata model for SSA capabilities from<br class="">SimpleDALRegExt 1.1:<br class=""><a href="http://docs.g-vo.org/schemadoc/schemas/SSA-v1_1_xsd/complexTypes/SimpleSpectralAccess.html" class="">http://docs.g-vo.org/schemadoc/schemas/SSA-v1_1_xsd/complexTypes/SimpleSpectralAccess.html</a><br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class=""><br class=""></div>Margarida</div><div class=""><br class=""><div class="">
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>—</div><div><br class=""></div><div>Margarida Castro Neves<br class=""><br class="">German Astrophysical Virtual Observatory (GAVO)<br class="">Astronomisches Rechen-Institut (ARI)<br class="">Zentrum für Astronomie, Universität Heidelberg (ZAH)<br class="">Mönchhofstr. 12 - 14, 69120 Heidelberg<br class="">phone +49-6221-54-1891 fax +49-6221-54-1888<br class=""><a href="mailto:mcneves@ari.uni-heidelberg.de" class="">mcneves@ari.uni-heidelberg.de</a><br class="">http://www.ari.uni-heidelberg.de</div><div><br class=""></div><div><br class=""></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>