SIA-2.0 constants (coord sys, reference positions, time scales, etc)

[Patrick Dowler]

As mentioned at the interp, I said I'd look into how planetary use cases 
could be supported in SIA-2.0 ... here are some thoughts.


It has been standard practice to fix the coordinate system, reference 
positions, time scales, etc in simple DAL potocols in order to simplify 
the protocols for > 90% of the use (ICRS). The main side effect is that 
the protocol becomes immediately unusable when the metadata is not 
characterising position/energy/time in the universe and on the sky -- 
planetary data, theoretical data, maybe solar system data -- where some 
other system of coordinates is required.

I can see a few ways we could make the SIA-2.0 query spec more flexible 
so it could be used for these other classes of use cases.

1. Add optional parameter(s) where the caller can specify the coordinate 
system describing other parameter values. For example, POS_SYS=GAL would 
say that POS values are in GAL(actic). This opens up a mess of clients 
needing to find out what the service supports, digging through the 
registry for services they can use, possible need for registry 
extension, possible need for a vocabulary for that _SYS param, etc. And 
more ways for requests to fail.

2. A service specifies (registry record, VOSI-capabilities, DALI service 
descriptor) which system they work in and clients do the transformation 
work before calling each one. That definitely pushes the limits of 
calling this a Simple DAL service. It is at least as bad as #1 for 
clients and maybe worse because services could not shoulder some of the 
burden by supporting both ICRS and GAL without deploying multiple services.

3. Consider the base SIA-2.0 query with all it's constants (and 
standardID) as defining the normal "search for telescope data". Write a 
new spec for planetary use cases that at a minimum redefines the 
constants and specified a new standardID for registering services. The 
planetary spec could define additional parameters (if necessary), it 
could change any *must* to *should* (or vice versa), and it could alter 
the parameter units and output to conform to a different data model*... 
but mostly rely on the base SIA parameters.

#3 is the same concept that was adopted for re-using SSA-1.1 for a 
simple time series service. Clients would simply search based on 
standardID for services they want to use and the effort to write that 3 
page spec and define a new standardID would be sufficient to keep us to 
a small number (2-3?) well defined variants of the SIA query capability.

It would be interesting to hear from the planetary people who know 
EpnTAP inside and out if this would work for them and how much would 
have to be redefined.

my 2c,

Pat


* right now, WD-IA-2.0 specifies vanilla ObsCore-1.0 and there is work 
to define an image extension to add some output columns; a planetary SIA 
would want to use a model consistent with EpnTAP; if that is a variant 
of ObsCore with (again) different constants then this would probably 
work ok... if that is an entirely different model then the query params, 
defined in terms of ObsCore fields, may not fit so well.

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)