Call for proposals for SIAP Version 2

[Doug Tody]

Hi Steve -

Part of the concept of SIA (or cone search) is that a client can send
the same basic query to a range of services and expect to get something
reasonable back.  The more advanced query features, e.g., the image
generation parameters, may not be supported by all services, and this can
be specified in the service metadata, queried in registries, and so forth.
But things like POS,SIZE,FORMAT are part of the most basic query and
anything we put in there should be supported (or at least accepted)
by all conformant services.

We can consider extending POS,SIZE further though.  Part of the reason
for making POS a string was to make it easier to do this sort of thing in
the future.  Galactic coordinates are pretty important and adding support
for these to POS is a reasonable thing to consider.  The broader question
is do we want to generalize the query region specification, and if so
what are the most important features to add?  ASU for example specifies
a more general syntax, see http://vizier.u-strasbg.fr/doc/asu.html.

With VO a question one always has to ask is if we are defining a user
interface or an internal Grid infrastructure interface.  If it is a user
interface we might want to load it up with lots of features to make it
as easy as possible for the user (or client program etc.).  If we are
doing this for one or a few sites and control the implementation it is
easy to do so.  If it is an internal service interface it is generally
simpler to include only what is needed for functional reasons, leaving
it up to clients to build the feature-rich user interface.  I think the
VO services are infrastructure, not user interfaces.

With that said, POS is very limited at present, to the point where there
are some functional limitations, and we could consider some enhancements.

Cheers,

	- Doug


On Wed, 2 Apr 2003, Steve Lowe wrote:
> Doug Tody wrote:
> 
> >It is easy to come up with a list of features far longer than we can expect
> >to agree upon in the near future, or get service providers to implement. 
> >
> ...
> 
> >It must remain easy for a service provider to put up a basic SIA service.
> >  
> >
> I think part of the idea is to say how some of these concepts can be 
> specified, but without requiring that all service providers implement 
> all elements. This could actually make buy-in easier. For example, a 
> service that has all its data and catalogs in galactic coordinates would 
> not have to convert query arguments from ICRS if it didn't want to. This 
> sort of capability in prototypes might provide a model for client 
> software negotiating with archives that provide different types of data 
> and that place different constraints on queries.
> 
> A key requirement for this to work is that the service provider be able 
> to communicate to the client which query elements it can accept. This 
> will be part of the metadata service request (FORMAT=METADATA).
> 
> Steve