Call for proposals for SIAP Version 2

[John Good]

Steve -

> Coordinate transforms are not difficult, but they're not trivial to get
> right either. This is especially so if we depart from the "distant" sky
> and try to specify more local observations for which the observing
> position is important.
>
> While I generally agree with the philosophy of providing know-how rather
> than software, I think realistically it will be beneficial to keep the
> buy-in cost low as Roy suggests. Consider that the user receives the
> direct benefit in acquiring data from a provider. The provider's
> benefit, if any, may be more indirect, such as community publicity or
> favor of the funding agencies. This is an argument for making life as
> easy as possible for the provider.
>
> I don't think portable code snippets will do, I think you'd need a
> supported software library.

I agree and there are at least a couple of coordinate transform libraries
already.  The code snippets I was referring to would be examples of
how to do the polygon, etc. constraint filtering.


> Whatever the ultimate decision on whether clients or providers have to
> support multiple coordinate systems, for now this capability can be used
> as a model to examine client-provider negotiation.

Since providers can be readily taught how to provide more complete
spatial filtering, I think this is the wrong place to experiment on
negotiation (at least until we get to more complex regions).

I would say a more relevant area for negotiation would be related
to query engine capabilities, particularly regarding the ability to place
additional relational constraints on metadata that passes the
positional filter.

For instance, our "Cone Search" service already allows for the full
range of positional constraints I described (and which I think can be
implemented universally).  It also allows for generic SQL constraints
("WHERE" clauses) on any of the fields in the table.  Now, for those
implementations which are not build on top of DBMS technology,
I can see that this ability could be difficult.  They might have no
such filtering or might only be able to filter on something like magnitude
ranges for a specific field.

I would like to see this ability called out as a part of both a more general
catalog search (superceding the Cone Search) and as an extension of the
SIA protocol.  Here there is  definitely a need for client-provider
negotiation, not just on whether this capability exists but then on the
"data dictionary" associated  with the fields that can be constrained
(or "SELECT"ed for that matter).

We provide the data dictionary information as a separate XML
service but it be envisioned as part of the same protocol suite.

- John