Comments on SSAP V0.95, UCDs

[Doug Tody]

Hi Gretchen -

The SSA data model and query interface does include some coordinate
system reference frame technology and we are looking into tying this
more directly to STC, however the details have not yet been resolved
(this was discussed extensively before and during the Victoria
interop).  I hesitate to say anything specific since this is still
under discussion, but ultimately this may be something simple like
Whatever.CoordSystemID="UTC-FK5-TOPO" where the thing on the left
is the UTYPE and the right is a key pointing into some external
library of STC-defined coordinate systems, with the standard cases
like the one shown being well known and hopefully usable without a
detailed understanding of STC (VOEvent is taking a similar approach).
We probably want to separate the problems of coordinate instances
and reference frames and merely associate the two in this fashion,
so STC is not needed to specify actual coordinate instances in most
simple cases.

See for example Francois Bonnarel's presentation from the interop:
http://www.ivoa.net/internal/IVOA/InterOpMay2006DAL/utypes.pdf

 	- Doug




On Tue, 27 Jun 2006, Gretchen Greene wrote:

> Hi Doug,
>
> Thanks for explaining.  From the point of view of an implementer,
> specifying utypes is a bit confusing.  My original understanding was
> that it would allow mapping into a data model,  e.g.  STC is one for
> spatial representation correct?,  yet as you stated it also serves a
> more direct method of characterization in the string representation.
> Also it sounds like there are still some fundamental pieces missing for
> SSAP providers in deciding how to handle the basic coord cases.  Why not
> make coordsys required (not to unleash a can of worms here,  I'm
> thinking basic STC.AstroCoordSys.UTC-FK5...)?  Wouldn't that handle it?
> Then you can work a protocol like SIA yet have the more generic
> solution.
>
> -G
>
>
>
>
>
> -----Original Message-----
> From: Doug Tody [mailto:dtody at nrao.edu]
> Sent: Tuesday, June 27, 2006 2:52 PM
> To: Gretchen Greene
> Cc: dal at ivoa.net
> Subject: RE: Comments on SSAP V0.95, UCDs
>
>
> Another point - as I mentioned to Randy earlier, we may want to consider
> treating the observation position as a special case, and giving these
> dedicated fields in the query response rather than digging them out of
> characterization.  Perhaps this is more what you were asking. One would
> like to avoid redundancy, but we already did something similar to this
> in SIA 1.0, where RA/DEC were specified separately from the WCS, which
> includes somewhat redundant positional information and in any case is
> optional.  In either case I think everyone agrees we need to ensure that
> the most fundamental metadata is easily available in a standardized
> fashion.
>
> The real issue with the observation position is coordinate systems. It
> is not clear that we can afford to continue to limit ourselves to a
> fixed equatorial coordinate system for queries.  In this last interop we
> had solar observers starting to use IVOA data access interfaces, and
> there has always been interest in supporting galactic coordinates as
> well as equatorial.  We should consider making more use of the reference
> frame when specifying coordinates; this may be a case of
> making things too simple.   - Doug
>
>
> On Tue, 27 Jun 2006, Doug Tody wrote:
>
>> Hi Gretchen -
>>
>> This is NOT a complex hierarchical interface.  The idea with the query
>
>> response is that it is a flat table; each field has a UTYPE and other
>> tags (name, ucd, etc.).  UTYPE is just a simple fixed string, so to
>> access a field one can just do something like  getField(<utype>).
>> Hence you still have a simple direct reference, although there may
>> also be some logical structure behind what is presented.
>>
>> Another way to look at it is that we have component data models with
>> some limited internal structure, however using the UTYPE mechanism we
>> can map everything to a flat name space, be it a VOTable, a hash
>> table, a parameter file, or whatever.  This makes things referentially
>
>> very simple but still provides some logical structure with reusable
>> components.
>>
>> 	- Doug