SIAP Document from SAO/CfA

[Niall Gaffney]

Steve,

Four comments on the first read through.

1> At this point I think we should call this thing something different.  
First off...its not Simple to me anymore.  Its becoming very general 
actually.  Also its no longer limited to Images, but to astronomical 
data in general.  So isn't this now a Data Access Protocol?  I know this 
may be nit picking but as I was reading this I had to remind myself over 
and over that this is not simple and is for more than images. With that 
behind me things were easier to contemplate.

2> With acceptance of the fact that this is no longer Simple, we need to 
add to the list of Principal Ideas: Error/Exception Reporting.  With SIA 
1.0 an error was either that you didn't format something the way I 
wanted it or I dont have what you need for other reasons (e.g. you got 
an http error 500 as the script you were running crashed).  With all of 
these capabilites must come some consistant error reporting methods.  
This has to be defined in the protocol and should be made in parallel as 
we expand this protocol, not patched on at the end. 

3> One challenge I saw from 6.3 Coordinate for data products is there is 
no mention of 2d long slit spectra. This is when spectra differ the most 
from images in their metadata as orientation is a very big deal. In 
UV/Optical/IR data, this is the typical mode of a pointed spectrometer.  
Do we need more in our ROI_COORDS to cover this (say a position angle 
and spatial length) and/or is there an orient and shape to describe the 
returned data's slit orientation on the sky? 

4>  I really like the structure proposed in 6.6.  We got into a 
discussion in the context of the Registry when we were trying to look at 
some "isA" relationships for services.  Here this sort of breaks things 
down well, so it is simple from the responce for the metadata for a 
query service to tell if it can be queried on parameters that are the 
same as that of others simply by looking at the ROI_QUANTITIES.  The 
ROI_COORDSYS tells you when you will have to do nonliner transformations 
of query data to make it match what you want (FK5->FK4 or lambda to 
frequency) and units are the simplest translations (appart from mJy to 
magnetudes).  It makes it clear to the querier what level of comitment 
will be needed to make things work together and allows them to set the 
bar as high or low as they want without writing a complex parser/comparitor.

And one last thing is something I can see coming back to haunt some 
users.  We use commas to delineate things in the ROI_* in 6.6.  We also 
use it in the coordinate where it joins a pair of paremeters into a set 
for one entity.  This symbol overloading makes perfect sence to those 
who know mathematics, but to poorly instructed string parsing code, 
ROI_QUANTITIES And ROI_COORDSYS have 2 data entitites and the RIO_UNITS 
has three (if you are not clever and do something about the 
paretheses).  Can we pick a different symbol for one of these (say , are 
for grouping numbers into sets like coordinates and ; are the other 
delineator)? 

Niall

Steve Lowe wrote:

> Hi All,
>
> I have uploaded a document on extending SIAP to the US-VO Publications 
> Repository. The URL is:
>    
> http://bill.cacr.caltech.edu/cfdocs/usvo-pubs/files/SIAPSpec_Part1_v1_0.pdf 
>
>
> As I say in the report, it is a combination of a Request for Comments 
> and a partial Specification that reflects the ideas we are kicking 
> around here at CfA. The release of Arnold's requirements document 
> about the time of the Pasadena meeting stirred up a lot of discussion, 
> and I hope that this new report will do likewise.
>
> Steve
>