Into the VO: Probabilistic Kernel Density Classification?

[Matthew Graham]

Hi Brian,

This is exactly the sort of thing that the VOSpace capabilities was intended for. The few capabilities I’ve implemented tend to follow the:

>    - create container node with the capability "ivo://ivoa.net/vospace/capabilities#KDC <http://ivoa.net/vospace/capabilities#KDC>"
>    - transfer data node(s) to container


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.

— Matthew 

> On Oct 28, 2017, at 1:25 PM, Brian Major <major.brian at gmail.com> wrote:
> 
> 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 <http://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 <mailto: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 <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/20171029/232f162f/attachment-0001.html>