ADASS discussions

[Alasdair Allan]

> 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