Call for proposals for SIAP Version 2

[John Good]

Steve -

> Perhaps we are not so much in disagreement. In our group we started out
> just wanting to be able to ask for a data product that looked like a
> spectrum, that is, something with data values (fluxes) measured at a
> range values of frequency/wavelength, just as an image has flux measured
> at a range of spatial positions.

While this might belong in the same "family" of services, I think it
muddies the waters to try and fold it and the SIA together operationally.
A positional constraint on the sky, whether for SIA or a Catalog Search
replacement for the Cone Search, is pretty fundemental and (in various
forms) already used extensively.  I think it makes more sense to keep
it separate from frequency/wavelength/etc. issues.


>                                             That parallel suggested that the
> Region
> of Interest should be able to indicate a frequency band in addition to
> sky position; indeed, this capability would be useful for traditional
> images, for example to request only, say, radio images. We didn't want
> to just patch in spectra, so we thought about how the query might
> indicate the physical properties it was interested in, the ranges of
> values for those quantities that are of interest, and the types of data
> the client wants to get back. It is anticipated that other disciplines
> might propose adding additional properties, such as time or polarization
> state, so we sought a somewhat extensible framework. In this framework
> the client has to indicate which physical concepts appear in the query,
> and so allowing coordinate systems to be specified as well seemed a
> natural extension, especially for a field like spectroscopy for which
> the sub-disciplines strongly favor different systems (frequency,
> wavelength, energy).

The "axes" in parameter space exist in pretty  orthogonal groups
(sky coordinates, photometry/polarization, temporal, etc.), so while
I agree that a common approach to setting constraints makes sense,
I don't see too much to be gained by trying to shoehorn everything into
a single query clause or even detailed syntax.


> So that's my recollection of how coordinate systems got into the act. I
> favor providing the mechanism for client/service negotiation on
> coordinate systems, even if most "good" services accept everything.
>
> But the main point, I think, is to expand the types of measurements that
> can be queried.

Sky coordinates, because they are two dimensional on a sphere, have to be
queried differently from typical relational constraints.  In our services,
everything else is handled by simply allowing fragments of SQL syntax
(e.g. "date between 10 and 20 or J_magnitude < 8.").  I can *imagine* needing
more complex constructs in other subspaces but we've never encountered
that need in practice.  Do you have instances of specific constraints that
don't work with fairly the simple SQL WHERE-clause construct?

- John