<div dir="ltr"><div><div>With respect to SSA vs SODA, I did not show it but if you find a the ID of a spectrum in our TAP service (via obscore or our own DM) you get a datalink service descriptor and from datalink you get SODA service descriptors with the relevant BAND parameters and you can call the SODA service to do cutouts in that spectrum. I didn't provide such an example ID because we're talking about the CSP goals here *but* this essentially fell out for free and *just works* exactly as expected... and it works right now.<br><br></div>So, I agree with Markus' that SODA completely replaces any form of "access data" in SSA.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 March 2016 at 08:01, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Francois,<br>
<span class=""><br>
On Thu, Mar 03, 2016 at 04:19:06PM +0100, François Bonnarel wrote:<br>
> Hi all,<br>
> A partial answer:<br>
> On 01/03/2016 12:02, Markus Demleitner wrote:<br>
> >> - Last but not least. SODA is very close to ObsTAP and<br>
> >> to SIAV2. It should have been a simple methos of SIAV2.<br>
> >No, most definitely not. All other protocols offering access to<br>
> >datasets require it as well, and historically, the first protocol it<br>
> >(or its predecessor, which still is very close to it) was used<br>
> >together with was SSA.<br>
> SSA has it own embedded AccessData Functionality. And as for the "GetData"<br>
<br>
</span>It does not -- is has been mentioned as something specified in the<br>
future, but it fortunately has never been specified.<br>
<br>
Fortunately, because we already have too many standards, and it'd be<br>
terrible if there were different VO protocols for slicing and<br>
processing 1D spectra and slicing and processing 2D or 3D spectra.<br>
Can we agree we have to avoid that?<br>
<span class=""><br>
> service you have been developping at GAVO<br>
> (<a href="http://docs.g-vo.org/talks/2012-urbana-ssaevo.pdf" rel="noreferrer" target="_blank">http://docs.g-vo.org/talks/2012-urbana-ssaevo.pdf</a> and<br>
> <a href="http://www.g-vo.org/pmwiki/uploads/Documentation/splat_interop_HD.pdf" rel="noreferrer" target="_blank">http://www.g-vo.org/pmwiki/uploads/Documentation/splat_interop_HD.pdf</a>),<br>
> which offer more to the users, It is allready fully integrable in the VO as<br>
<br>
</span>If you look, this stuff is pretty much what is now called SODA. And<br>
it has worked for slicing-and-dicing cubes back then, too, as it does<br>
now (see the Califa thing I sent around earlier today). And there's<br>
proven client support over several services (although only for<br>
spectra, but that's not a matter of principle).<br>
<span class=""><br>
> a CUSTOM SERVICE with help of the standard DataLink functionalities. But<br>
> Having GetData (or its successor) as the standard for cubes is another<br>
> story. See below.<br>
<br>
</span>I'm getting a bit tired of repeating this, but: I'm not interested in<br>
custom services; I could just as well write web pages for that.<br>
<br>
I'm after clear specs against which authors of clients can work (and<br>
also authors of services, but that's traditionally been less of a<br>
problem within the VO). It would totally against what I think the VO<br>
should be if clients needed to implement different rules for<br>
different services.<br>
<br>
In case you really want to keep up that custom service argument: I<br>
think we agree that custom services are bad in principle. So, why<br>
should we accept them when it's completely straightforward and free<br>
to define these kinds of services interoperably? Or in which way is<br>
it not free? Or not straightforward?<br>
<span class=""><br>
> SODA functionality has been "extracted" from SIAV2 initial project for one<br>
> single reason : The same functionality had to be accessible frm DIAV2 or<br>
> from ObtAP query phases indifferently. But we cannot do as if there is no<br>
<br>
</span>But ObsTAP contains spectra, too, no? And time series? And lots of<br>
other kinds of data?<br>
<span class=""><br>
> ><br>
> >> It shares the same syntax as SIAV2 and the same model<br>
> >> as ObsTAP and SIAV2. We are defining SODA now so we can<br>
> >No, it does not, at least as far as the model is concerned. SODA, to<br>
> >be useful, needs to be model-free[1],<br>
><br>
> Ah !!! This is the point where we really differ, Markus. Currently SODA<br>
> doesn't have to be model-free it has to be adapted to ND-Cubes and we have a<br>
> simple model for that which is Obscore and we will have a full one, CubeDM<br>
> (in a near future because it's allreday in good shape)<br>
<br>
</span>Again I'm getting a bit tired of repeating this, but CubeDM doesn't<br>
really enter into it. We're talking about SODA *services* here, and<br>
going from a data model description to inferring a service interface<br>
is really involved. I'll believe that it can be done when I see a<br>
good plan how to do that and a client implmenting it working with two<br>
different services.<br>
<br>
I don't believe we'll see any of this any time soon.<br>
<br>
So -- before we talk on here -- couldn't you just try it?<br>
Service-side and within Aladin? I'm pretty sure you'll notice that<br>
datalink-embedded per-dataset SODA descriptors are simple,<br>
straightforward and really what you want to have, whereas everything<br>
else is a minefield of complications (unless you put in a lot of<br>
assumptions that will severely restrict the kind of data you can<br>
process, which would be a pity).<br>
<span class=""><br>
<br>
> I think it would be a pity not to benefit from the clean description the<br>
> data model provides for cubes. SODA standard parameetrs are really funded on<br>
> the model so far.<br>
<br>
</span>What benefits would that be, by the way? What is it that you're<br>
after that cannot be done by proper parameter description?<br>
<br>
You see, I'm getting a bit exasperated because I believe we have a<br>
simple, well-understood, and easy way that I believe does everything<br>
the CSP has asked us to do and more.<br>
<br>
On the other side there's a plan building on a data model that's been<br>
in the works for years already. That DM would be used through an as-yet<br>
undefined service interface ("get-gory-details"). To infer the<br>
service interface for those gory details beyond some basics[1]<br>
is too complicated at least for me to imagine.<br>
<br>
I am particularly exasperated because we don't have too many chances<br>
to get this right. I think we only have this one. Make SODA<br>
incapable or incredibly complicated and the VO is out for something<br>
that could be actual inroads into the community. People are writing<br>
web pages for data access left and right while we discuss here.<br>
<span class=""><br>
> The mandate we have as DAL WG is to fulfill the CSP priorities for cubes,<br>
> and allow archives who have cubes to provide simple cutout facilities. We<br>
> don't have to disperse into a generic and then more complex thing.<br>
<br>
</span>SODA with proper declarations+Datalink satisfy those requirements<br>
*right now*, without anything we don't understand well. Ok, you'll<br>
need to add RA and DEC as parameters, but that's straightforward. It<br>
exists and works.<br>
<br>
Are you sure you can't agree to accepting this as something that<br>
works *right now* and delay all further complications with tech we<br>
don't really have (or fully understand) at this point until further<br>
versions when perhaps there's implementation experience with this?<br>
<br>
Cheers,<br>
<br>
Markus<br>
<br>
[1] And we already know that data providers will want a lot more and<br>
complain that our protocols (and in particular, clients) can't do it.<br>
And then they'll write web pages instead of interoperable services.<br>
<br>
</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>