Call for proposals for SIAP Version 2

[Steve Lowe]

Hi John,

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. 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).

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.

Steve

John Good wrote:

>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
>
>
>  
>


-- 
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe at cfa.harvard.edu
1-617-496-1661