Into the VO: Probabilistic Kernel Density Classification?
Brian Major
major.brian at gmail.com
Sat Oct 28 22:25:18 CEST 2017
Hi again,
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.
VOSpace could be used for the file handling and metadata handling
mechanism. So, one could imagine replacing the steps of:
- mkdir
- upload file(s)
with:
- create container node with the capability "ivo://
ivoa.net/vospace/capabilities#KDC"
- transfer data node(s) to container
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.
Comments welcome :)
Brian
On Sat, Oct 28, 2017 at 11:00 AM, Brian Major <major.brian at gmail.com> wrote:
> Hi Grid,
>
> 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.
>
> For those of you who were not able to attend, FX's slides can be seen here:
> http://wiki.ivoa.net/internal/IVOA/InterOpOct2017KDD/201710_
> IVOA_KDD_fxp.pdf
>
> 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.)
>
> 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.
>
> But, without any presumptions, here are some questions and possible
> options:
>
> (1) Does this sound like a good candidate for standardization?
>
> (2) If (1), how can it be offered:
>
> (a) VO can provide or recommend a library that users can use when
> they upload code to be executed in a data centre.
>
> (b) It can be offered as an independent REST service, as shown in the
> prototype, with possible UWS support.
>
> (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.)
>
> (d) It can be offered as a SODA service
>
> (e) Others?
>
> Please, if you have an opinion, respond. My quick thoughts:
>
> (1) Yes, it is useful and transferrable to different types of problems
> users face.
> (2)
> (a) Too much effort placed on users
> (b) Not general enough
> (c) A good fit, but a trailblazer for using the VOSpace node
> capabilities support
> (d) SODA operates on files, not catalogues, so not a good fit.
>
>
> Regards,
> Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20171028/def8e540/attachment.html>
More information about the grid
mailing list