<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="">Hi all,<div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 13. Mar 2020, at 10:13, 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 Registry,<br class=""><br class="">So, I've now added a productType element to the SSA capability. I've<br class="">not yet updated the WD on the doc repo, but you can check out <br class=""><a href="http://docs.g-vo.org/SimpleDALRegExt.pdf" class="">http://docs.g-vo.org/SimpleDALRegExt.pdf</a>, on page 20, or the schema<br class="">at<br class=""><a href="https://volute.g-vo.org/svn/trunk/projects/registry/SimpleDALRegExt/SSA-v1.3.xsd" class="">https://volute.g-vo.org/svn/trunk/projects/registry/SimpleDALRegExt/SSA-v1.3.xsd</a>.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>I’ve implemented this in SPLAT, so that when querying registries, SPLAT can classify the services as spectrum or time series services.</div><div><br class=""></div><div>A preliminary version can be found here: <a href="http://soft.g-vo.org/splat-beta/splat-vo-3.15_2beta.jar" class="">http://soft.g-vo.org/splat-beta/splat-vo-3.15_2beta.jar</a></div><div><br class=""></div><div><br class=""></div><div>Margarida</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The net effect is that you can write one or more productType elements<br class="">in the SSA capability, as in <br class=""><br class=""> <capability standardID="<a href="ivo://ivoa.net/std/SSA" class="">ivo://ivoa.net/std/SSA</a>" <br class=""> xsi:type="ssap:SimpleSpectralAccess"><br class=""> <interface role="std" xsi:type="vs:ParamHTTP"><br class=""> <accessURL use="base"<br class=""><blockquote type="cite" class=""><a href="http://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?</accessURL>" class="">http://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?</accessURL></a><br class=""></blockquote> <mirrorURL><br class=""> <a href="https://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?</mirrorURL>" class="">https://dc.zah.uni-heidelberg.de/bgds/l/ssa/ssap.xml?</mirrorURL></a><br class=""> </interface><br class=""> <complianceLevel>query</complianceLevel><br class=""><br class=""> <productType>timeseries</productType> <--- NEW<br class=""><br class=""> <dataSource>survey</dataSource><br class=""> <creationType>archival</creationType><br class=""> <supportedFrame>ICRS</supportedFrame><br class=""> ...<br class=""> </capability><br class=""><br class="">(cf.<br class=""><a href="http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/bgds/l/ssa" class="">http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/bgds/l/ssa</a><br class="">for the full record; you could have multiple productType elements,<br class="">but I've no resource that would need that).<br class=""><br class="">I've already implemented support for this in DaCHS, and I've taught<br class="">the extra feature to the Heidelberg RegTAP service<br class="">(http://dc.g-vo.org/tap). This means that you can search for<br class="">"declared" time series services with something like<br class=""><br class=""> select ivoid from<br class=""> rr.capability<br class=""> natural join (select ivoid from rr.res_detail<br class=""> where <br class=""> detail_xpath='/capability/productType'<br class=""> and detail_value='timeseries') as ts_ssa<br class=""> where<br class=""> standard_id='ivo://ivoa.net/std/ssa'<br class=""><br class="">or, if you're doing a typical "get me all SSA services"-type query,<br class="">enrich your records with product_types information somewhat like this:<br class=""><br class=""> select access_url, product_types, reference_url from<br class=""> rr.capability<br class=""> natural join rr.resource<br class=""> natural join rr.interface<br class=""> natural left outer join (select <br class=""> ivoid, <br class=""> ivo_string_agg(detail_value, '#') as product_types<br class=""> from rr.res_detail<br class=""> where <br class=""> detail_xpath='/capability/productType'<br class=""> group by ivoid) as pt<br class=""> where<br class=""> standard_id='ivo://ivoa.net/std/ssa'<br class=""><br class="">(where you'd do product_types="spectrum" where you get NULL or empty<br class="">strings).<br class=""><br class="">I give you I've seen prettier queries, but I guess one can get used<br class="">to it, and it's really just a homeopathic change to standards<br class="">solving the time series discovery thing, so I'd say let's do it.<br class=""><br class="">If you have an SSA service serving time series, would you just try<br class="">it? You'll stay validatable if you point the schema location for <br class="">http://www.ivoa.net/xml/SSA/v1.1 to<br class="">http://vo.ari.uni-heidelberg.de/docs/schemata/SSA-v1.3.xsd.<br class=""><br class=""><br class="">The one thing I don't particularly like about this proposal: By<br class="">caproles (http://ivoa.net/documents/caproles/ -- and no, I can't post<br class="">to Registry these days without linking to caproles), this is the<br class="">wrong level of modelling. A resource with an SSA capability serving<br class="">time series, really, should serve time series through a TAP or<br class="">Browser capability as well. And hence, productType really should sit<br class="">on the resource rather than than capability level.<br class=""><br class="">So, the real question in my mind is: should we put productType into<br class="">VODataService right away, so it can also be used by obscore, SIAv2,<br class="">whatever services? From a resource record author perspective, the<br class="">change would be that productType moves one XML level up. In the<br class="">RegTAP query, you'd be using '/productType' rather than<br class="">'/capability/productType' -- no big deal on either side.<br class=""><br class="">But: if it's in VODataService, we'd have to comment on what to do<br class="">when it's not there. On SSA capabilities, that's simple: it's a<br class="">spectrum service. On generic resources, its... complicated.<br class=""><br class="">And that last thing -- clearly saying what a missing productType<br class="">means -- is what made me ignore the wisdom of caproles for a<br class="">pragmatic, perhaps-good-enough solution. If you say we'll likely<br class="">regret that gung-ho approach, I'm perfectly willing to move<br class="">productType into VODataService (which hopefully will move into RFC<br class="">rather soon, too).<br class=""><br class=""> -- Markus<br class=""></div></div></blockquote></div><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></div></body></html>