<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>I understand what is being said about SODA being able to emit a datalink service descriptor, but let's remember the archietcture diagra, from the roadmap after the Hawaii interop, here:<br><br><a href="http://wiki.ivoa.net/twiki/bin/view/IVOA/2013BRoadmap#Data_Access_Layer">http://wiki.ivoa.net/twiki/bin/view/IVOA/2013BRoadmap#Data_Access_Layer</a><br><br></div>We have renamed some items in there but the landscape is basically the same and we are working on the most basic part of SODA (accessData "filter"). The solid lines are show the most general case where a provider has all service capabilities. The dashed lines show possible optimisations with one being relevant to the current discussion:<br><br></div>*directly go from query to access*: the spec that provides the ability to do this is the DataLink service descriptor; providers can include SODA descriptors directly in the output of the data discovery *if* they can provide ID values in that output that can be used with their SODA implementation (note: we cannot due to a 1-n relation between publisher_did and files)<br><br><br></div>So, you do not need to implement DataLink at all! With a simple collection, one can have just SIA-query and SODA and satisfy the use cases.<br><br></div><br></div>As for the a SODA service being able to emit a service descriptor, the DataLink spec does make a comment about this (service descriptors with ID="this"). The issue is that SODA services by-and-large will not be returning VOTable, so such a request would have to be <br><br>ID=<publisher_did><br>RESPONSEFORMAT=application/x-votable+xml<br><br></div>I don't think the "content=datalink" would be appropriate because that says here is a table of links. So, is it a good idea to specify a VOTable output format for SODA services? Will it be confusing when we try to use SODA for spectra (timeseries, eventlist) and VOTable is a valid data format?<br><br></div>Is adding a separate endpoint (new capability, new standardID) better?<br><br></div>This sounds somewhat like the metadata capability that we postponed until after the dot-0 versions of the minimal specs. It seems to me like an increase in scope and there is too much uncertainty here... so IMO we should be OK with TAP|SIA -> DataLink -> SODA or the optimised TAP|SIA -> SODA. If a provider can't do the latter, it is only because you already need a DataLink service.<br><br></div>my 2c,<br><br></div>Pat<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 March 2016 at 07:38, François Bonnarel <span dir="ltr"><<a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi again,<div><div class="h5"><br>
<br>
On 03/03/2016 09:03, Markus Demleitner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Laurent,<br>
<br>
On Wed, Mar 02, 2016 at 05:20:37PM +0100, Laurent Michel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Markus<br>
<br>
Let's "try again with an explanation":<br>
<br>
Imagine the following fields in your DAL response (SIAV2 e.g.)<br>
<br>
access_type=application/xml+votable;content=soda<br>
access_url=<a href="http://my.soda?ID=xyz" rel="noreferrer" target="_blank">http://my.soda?ID=xyz</a><br>
<br>
These 2 values are enough to run SODA with the common parameters (POS,TIME..).<br>
The relevant parameter ranges can likely be found within the<br>
current VOTable. No need to any explicit reference to any DM for<br>
this.<br>
If you want to refine the SODA description, just run<br>
<a href="http://my.soda?ID=xyz" rel="noreferrer" target="_blank">http://my.soda?ID=xyz</a> and get a classical service descriptor.<br>
</blockquote>
Ah -- but note that the difference between this and a normal datalink<br>
endpoint is very small. This SODA endpoint would return documents of<br>
the structure<br>
<br>
<VOTABLE><br>
<RESOURCE type="meta" utype="adhoc:service" ID="svc"><br>
[Service descriptor content]<br>
</RESOURCE><br>
</VOTABLE><br>
<br>
whereas if we just re-used datalink as-is, the structure would be:<br>
<br>
<VOTABLE><br>
<RESOURCE type="results"><br>
[Data links]<br>
</RESOURCE><br>
<RESOURCE type="meta" utype="adhoc:service" ID="svc"><br>
[Service descriptor content]<br>
</RESOURCE><br>
</VOTABLE><br>
<br>
If a service really does not have any data links, the [Data links]<br>
thing above is very stereotypical; it's just a link with the<br>
dataset's pubdid, a #proc semantics and a pointer to svc. With a bit<br>
of organisation, you could have the entire results RESOURCE in a<br>
fixed string.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To me, the gain is 2 folds: 1) No need operate a Datalink service to run a<br>
SODA service 2) Applying this scheme to DataLink response could (or not - up<br>
to you) save the duplication of the SODA service descriptor for each link.<br>
The (low) cost: pushing the parameter description from the Datalink service to this new and simple SODA capability .<br>
</blockquote>
So, ad (1): Saving the stereotypical results RESOURCE on the service<br>
side seems a neglible benefit to me, in particular considering the<br>
cost that we'd still have to define a new service interface (which<br>
furthermore happens to be almost identical to datalink, except<br>
perhaps that ID would be fixed to single-value from the start), a new<br>
media type, and that the clients have to deal with two different<br>
but very similar formats.<br>
</blockquote></div></div>
I support Laurent's proposal which recall me what we had in SIAV1.0 and SSA under the "FORMAT=METADATA" query. This was answering by describing the input parameters of the service in a way which looks a lot like a modern service descriptor (apart some archaisms)<br>
<br>
The main limitation was that format = metadata could not be attached to a specific dataset and provide metadata valid only for it.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ad (2): I cannot see a benefit in taking the service blocks out of<br>
the datalink response proper -- you have to generate them in your<br>
scheme, too; and why should it be preferable to serve them from an<br>
extra endpoint than to just embed them into the main datalink<br>
response?<br>
</blockquote></span>
The benefit will be to enlight the fact that DataLink is not done only for exposing SODA services or dynamical standard services but also custom services and static links. service description the DataLink response is fine for custom services wher we have absolutly no control on the way they can answer to an autodescription query. In the case of standard services we currently define like we do for SODA, we can still fine tune this in the SODA service itself.<br>
<br>
DataLink Table is a little bit of "glue" (with little description of the links) between datasets and resources. "cutout" is only ONE among SIXTEEN semantical possibilities on the nature of the links. See <a href="http://www.ivoa.net/rdf/datalink/core/2014-10-30/datalink-core-2014-10-30.html" rel="noreferrer" target="_blank">http://www.ivoa.net/rdf/datalink/core/2014-10-30/datalink-core-2014-10-30.html</a><br>
<br>
We should avoid too much overloading of DataLink responses by cutout details<br>
<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
François</font></span><div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I totally give you it is unfortunate that the datalink interface<br>
leads clients to expect they can request multiple IDs, and you'd have<br>
my vote to remove that any day. But as Pat says, even with the<br>
current spec you're allowed to discard extra IDs (at the expense of<br>
having to give an overflow indicator, which may be a bit annoying but<br>
is not dramatic). Plus I expect clients won't use the multi-ID thing<br>
anyway.<br>
<br>
And the multiple service blocks aren't horrible on the serice side<br>
anyway. On the client side -- well, that's another matter, but I've<br>
not formed an opinion there yet.<br>
<br>
So -- I'd still maintain we shouldn't increase the number of<br>
endpoints. And rather write clients.<br>
<br>
On that very matter of clients (or makeshift clients), I mention in<br>
passing that I've extended my XSLT-to-datalink stylesheet to do basic<br>
UI generation from service descriptors, including intervals. You can<br>
see the current state in action from the dlmeta links on<br>
<br>
<a href="http://dc.zah.uni-heidelberg.de/califa/q2/cubesearch/form?__nevow_form__=genForm&_DBOPTIONS_ORDER=&MAXREC=100&_FORMAT=HTML&submit=Go" rel="noreferrer" target="_blank">http://dc.zah.uni-heidelberg.de/califa/q2/cubesearch/form?__nevow_form__=genForm&_DBOPTIONS_ORDER=&MAXREC=100&_FORMAT=HTML&submit=Go</a><br>
<br>
(and I'm sure you can break the xtype=interval params in the current<br>
implementation, which at this point are at the proof-of-concept<br>
level; also, the port from atomic to interval parameters isn't quite<br>
done everywhere yet).<br>
<br>
Implementors are welcome to use (and improve!) the stylesheet at<br>
<br>
<a href="https://github.com/msdemlei/datalink-xslt.git" rel="noreferrer" target="_blank">https://github.com/msdemlei/datalink-xslt.git</a><br>
<br>
My next plan with this would be to use three-factor-semantics to<br>
provide a cutout over a sky image when RA and DEC are present (if<br>
someone has some javascript for that already, I'd be highly<br>
interested) and to put in sliders where appropriate when the client<br>
knows enough javascript to have "two-nosed" (lower and upper limit)<br>
sliders with editable input boxes. Again, contributions are highly<br>
welcome -- I'm sure this kind of thing has been written many times<br>
before.<br>
<br>
Cheers,<br>
<br>
Markus<br>
</blockquote>
<br>
<br></div></div><div class="HOEnZb"><div class="h5">
-- <br>
=====================================================================<br>
François Bonnarel Observatoire Astronomique de Strasbourg<br>
CDS (Centre de données UMR 7550 CNRS / Université de Strasbourg<br>
astronomiques de Strasbourg) 11, rue de l'Université<br>
F--67000 Strasbourg (France)<br>
Tel: <a href="tel:%2B33-%280%293%2068%2085%2024%2011" value="+33368852411" target="_blank">+33-(0)3 68 85 24 11</a> WWW: <a href="http://cdsweb.u-strasbg.fr/people/fb.html" rel="noreferrer" target="_blank">http://cdsweb.u-strasbg.fr/people/fb.html</a><br>
Fax: <a href="tel:%2B33-%280%293%2068%2085%2024%2025" value="+33368852425" target="_blank">+33-(0)3 68 85 24 25</a> E-mail: <a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a><br>
---------------------------------------------------------------------<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div>
</div>