<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Brian,<div class=""><br class=""></div><div class="">This is exactly the sort of thing that the VOSpace capabilities was intended for. The few capabilities I’ve implemented tend to follow the:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""> - create container node with the capability "ivo://<a href="http://ivoa.net/vospace/capabilities#KDC" class="">ivoa.net/vospace/capabilities#KDC</a>"<br class=""> - transfer data node(s) to container</div></div></blockquote></div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">pattern. One thing to think about is whether you want the capability permanently on or whether you might want to be able to switch it off - I’ve done this with the presence of a .conf file.</div><div class=""><br class=""></div><div class="">— Matthew </div></div></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 28, 2017, at 1:25 PM, Brian Major <<a href="mailto:major.brian@gmail.com" class="">major.brian@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class="">Hi again,<div class=""><br class=""></div><div class="">After a few discussions, I think my suggestion about using VOSpace capabilities (option (c)) needs some clarification. I'm really just throwing ideas out there at this point though.</div><div class=""><br class=""></div><div class="">VOSpace could be used for the file handling and metadata handling mechanism. So, one could imagine replacing the steps of:</div><div class=""> - mkdir</div><div class=""> - upload file(s)<br class="">with:<br class=""> - create container node with the capability "ivo://<a href="http://ivoa.net/vospace/capabilities#KDC" class="">ivoa.net/vospace/capabilities#KDC</a>"<br class=""> - transfer data node(s) to container</div><div class=""><br class=""></div><div class="">Once in place, the service (to be defined) that supports that capability would use the VOSpace to gather the input parameters. One could imagine the service using UWS support sync and async execution. Results could be referenced by URI in the job which could conceivably point to the same VOSpace.</div><div class=""><br class=""></div><div class="">Comments welcome :)</div><div class=""><br class=""></div><div class="">Brian</div><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Oct 28, 2017 at 11:00 AM, Brian Major <span dir="ltr" class=""><<a href="mailto:major.brian@gmail.com" target="_blank" class="">major.brian@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hi Grid,<br class=""><br class="">I would like to start a discussion on the feasibility of standardizing the service presented by François-Xavier Pineau at this morning KDD/GWS session.<br class=""><br class="">For those of you who were not able to attend, FX's slides can be seen here:<br class=""> <a href="http://wiki.ivoa.net/internal/IVOA/InterOpOct2017KDD/201710_IVOA_KDD_fxp.pdf" target="_blank" class="">http://wiki.ivoa.net/internal/<wbr class="">IVOA/InterOpOct2017KDD/201710_<wbr class="">IVOA_KDD_fxp.pdf</a><br class=""><br class="">In a nutshell, he presented a prototype of a REST service that automated source classification with probabilistic estimates. The estimates of matching are done though direct database catalogue queries. (Please, correct me if I have anything wrong here.)<br class=""><br class="">It occurred to me and to others who were in attendance that this is a good candidate for a service that could be offered by the IVOA. It is much like cutouts--a software function that is common and useful enough to be offered as a service, as opposed to requiring users to code such a mechanism themselves.<br class=""><br class="">But, without any presumptions, here are some questions and possible options:<br class=""><br class="">(1) Does this sound like a good candidate for standardization?<br class=""><br class="">(2) If (1), how can it be offered:<br class=""><br class=""> (a) VO can provide or recommend a library that users can use when they upload code to be executed in a data centre.<br class=""><br class=""> (b) It can be offered as an independent REST service, as shown in the prototype, with possible UWS support.<br class="">
<div class=""><br class=""></div><div class=""> (c) It can be offered as VOSpace standard capability. (If a directory supports the capability, the data nodes in the directory are treated as database tables and the estimation capability could be invoked with the required parameters. -- or something like that.)</div><div class=""><br class=""></div><div class=""> (d) It can be offered as a SODA service</div><div class=""><br class=""></div><div class=""> (e) Others?</div><div class=""><br class=""></div><div class="">Please, if you have an opinion, respond. My quick thoughts:</div><div class=""><br class=""></div><div class="">(1) Yes, it is useful and transferrable to different types of problems users face.</div><div class="">(2)</div><div class=""> (a) Too much effort placed on users</div><div class=""> (b) Not general enough</div><div class=""> (c) A good fit, but a trailblazer for using the VOSpace node capabilities support</div><div class=""> (d) SODA operates on files, not catalogues, so not a good fit.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Brian</div></div>
</blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></div></body></html>