> we need to set an agenda for the discussion at the meeting following ADASS.
> Suggestions are welcomed.
Okay, I'd like to bring up my current pet peeve about the NVO cone search standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it doesn't include either equinox or epoch.
Both of these are vital for people wanting to do real science with the catalogues. If the adopted standard doesn't include these things, people doing galactic work won't use the interface because the retrieved catalogues aren't going to be valid. We can _not_ assume J2000 for both equinox and epoch, it just won't work!
One of the things I'm doing for eSTAR at the moment is a catalogue brokering service...
Have a look at http://www.astro.ex.ac.uk/estar/services/services.html
Basically this is the testbed broker service, there is both a REST and a SOAP interface (and documentation for the same), the REST service isn't currently NVO complient, but I guess I should modify it so it is...
The service does a name resolution, if necessary, initallity using the CDS Sesame SOAP service, but falling back to use CDS SIMBAD if Sesame is unavailable.
It then goes off and tries to retrieve the cone search you specified on whatever catalogue you specified, falling back to alternative sources to retrieve the catalogue if its first choice of 3rd party service is unavailable.
The returned catalogue is parsed and then output in the formatted as per user specifications (currently supported formats are Cluster and JCMT pointing, because the infrastructure was written by myself and Tim Jenness and those are out internal formats!), I'm in the process of adding VOTABLE support now.
At that point any Vizier and SkyCat cvatalogues (and a few others), are available via this service in VOTABLE format irrespective of the original format that the 3rd party service returned, for instance for Vizier this is TST format...!
> My own feeling is that we aren't yet in a position to be drafting actual IVOA
> standards about web-service usage. Rather, we could use the run-up to the
> meeting and the session at the meeting itself to define crisply the areas were
> we actually need standards. I.e., we would be planning documents to be
> debated at the _next_ meeting. Your opinion?
Personally, I'm not sure. One of the problems I'm having now is that I'm actually trying to deploy stuff, and the infrastructure is changing under my feet. This is very frustrating.
I'd really like to emphasise that the returned "result" of a webservice query (be it a VOTABLE, a parsable document, or whatever) is part of the service's API. You can't just go and change it, its not just how the service is called that defines the API.
That said, I take your point.
> I would also like to see a little more debate about how OGSI, OGSA and grid
> services fit into the IVOA architecture. In particular, can we accept OGSI
> services as a critical part of the architecture or is OGSI too new, too raw,
> or just too wierd to live?
I would certainly anticpate a "web service" stage before everyone moves on to full OGSA/OGSI grid services, I mean, alot of what we want to do doesn't need the complications of OGSI. Why make life difficult for people trying to access your service? It would be rather nice if you could talk to a service endpoint using straight SOAP as well as a full OGSI compliant toolkit if persistence isn't needed for your query...
> Finally I'd like to make, and to show at the meeting, head counts of which
> groups use which toolkits, languages, service containers etc for web services.
Perl and SOAP::Lite. V0.6-beta has just gotten released, this plugs alot of holes in the compatibility between SOAP::Lite and other SOAP toolkits such as AXIS, and it looks like active development of the toolkit is again underway (much to everyone's relief!).
See http://www.soaplite.com/beta/ for more information about the new release, the new release also has much expended documentation!
I've been talking to Paul, Randy and Byrne about adding OGSA/OGSI support to the toolkit and it looks like this might be happening on a reasonable timescale.
Cheers,
Al.
--
Dr. A. Allan, School of Physics, University of Exeter
Received on 2003-10-06Z08:43:17