SIAP Document from SAO/CfA

[Steve Lowe]

Niall Gaffney wrote:

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

We were thinking of, perhaps, Data Product Access Protocol, but your 
suggestion of Data Access Protocol would also be good. As to, the 
simplicity, well, we're trying to not make it any more complicated than 
we have too.

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

I agree, and we haven't done too much with this other than to 
acknowledge that it needs to be there.

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

Absolutely! This has been a concern of ours that we've been working on, 
but are still not sure of the best approach and will discuss it in the 
next Part of this report. We went ahead and distributed "Part 1" because 
we wanted to get some discussion going on the whole idea of introducing 
other coordinates and how to do that.
Perhaps the simplest thing to do for slit spectra is to introduce a 
property SKY:DIST:SUBSPC1 that can be used as an AXIS coordinate to 
request a data product which is a one-dimensional subspace of the 2-D 
SKY:DIST space. (I could have used "SLIT", instead of "SUBSPC1", but we 
want this to be general, no?) But, suppose you were only interested in a 
specified slit orientation, e.g., along the (apparent) long axis of a 
particular galaxy you are studying. Now you need an input parameters to 
indicate the orientation of the slit (actually, an acceptable range for 
the orientation). But then we have to decide how to add this extra 
parameter to the protocol in a general way. One way would be to tack the 
parameter on as an argument, e.g., the service coordinate list could 
have an entry
    AXIS    SKY:DIST:SUBSPC1(ANGLE)
to indicate that a request can be made for a 1-D piece of the sky at a 
specified angle ANGLE.
But the angle has to have units! So, now the entry has to be something like
    AXIS    SKY:DIST:SUBSPC1(ANGLE:DEG)
So, it get's a little complicated, and we wanted to get it refined a 
little more in our own minds before sending it out. Also, this matter of 
continuously parameterized families of coordinate systems turns up 
elsewhere, for example if you're thinking of nearby objects and have to 
worry about where the telescope is located---i.e., dealing with other 
projections of the sky than the "distant" idealization. The DIST in 
SKY:DIST has an ominous future ahead.

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

I'm glad to hear that you like the property/coordsys/units breakdown 
presented in 6.6. Building that factorization into the protocol may 
indeed be the right way to go, we're not sure yet. Your vote is 
registered! The reason for proposing the unstructured strings was the 
thought that some elements will expand into subelements, as with 
SKY:DIST:SUBSPC1 above, or for example that the common non-ICRS 
equatorial systems require a couple of defining values instead of just 
one, i.e., EQUAT:ICRS but EQUAT:J2000:FK5 or EQUAT:B1950:FK4. Then one 
starts to ask whether some users would find it useful if these elements 
were broken out as well. What is the right breakdown? 
Property/coordsys/units does seem intuitive, but it may be that, for a 
machine-to-machine protocol (as opposed to a human-usage oriented 
protocol), we can just punt the whole question by not building any 
structure at all into the protocol, and just have the factorization 
implied by common usage.

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

Ah, the intention was that the parentheses in 
ROI_UNITS=(DEG,DEG),ANGSTROM would be parsed. I see your point, you 
can't just break it up with split(","). We'll give it some thought.

Regards,
Steve

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