Comment on Strasbourg

At the IVOA interop meeting last year, I think we (from Aus-VO) who were there were seriously unhappy with the thought of a lot of software already in existence being re-created for VO. I was rather confused also as to what environment such software would be written in. Who would be implementing all of the infrastructure that would be needed to generate applications for VO ? I was further alarmed at one of the working group meetings with people apparently starting to build Coordinates class designs (where would this be implemented I wondered).

So David your appraisal makes some sense to me. I.e. the idea that VO fundamentally is providing a data stream, but not the analysis software. This has the advantage of being tractable.

For Aus-VO's role. You have suggested 1) standards, 2) data publishing, 3) using VO data, 4) external services

Related to 4) are services that are provided as an external web-service but in fact depend upon the infrastructure of an existing package. A good example of this is the Quanta and Measures web service ATNF will provide in the coming months. These will use aips++ infrastructure to deliver astronomer useful services.

One of the two VO positions we have just advertised (see has a component to start implementing current VO data access protocols and we can explore the concept of consuming things like SIA in aips++ as well as providing image archives that can respond to SIA queries.

Another example of a service related to 4) is an application like the Remote Visualization Server (which depends upon aips++ Visualization infrastructure). In the coming year we will start deploying RVS to existing image archives here at the ATNF. However, a longer term goal is for other people to install an RVS server at their own image archive so we will have to learn how to package it for end-users, including all of the dependency horror...

So I continue to see a good niche for us in providing useful end-user services packaged around existing infrastructure.