Comments on SSAP V0.95, UCDs

[Gretchen Greene]

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
>
>
> On Tue, 27 Jun 2006, Gretchen Greene wrote:
>
>> Doug,
>> 
>> Let me get this clear,  to specify ra, dec you are seriously 
>> considering something to level 4 hierarchy?
>> 
>> -Gretchen
>> 
>> -----Original Message-----
>> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Doug 
>> Tody
>> Sent: Tuesday, June 27, 2006 2:01 PM
>> To: Randall Thompson
>> Cc: dal at ivoa.net; Inga Kamp; Myron Smith
>> Subject: Re: Comments on SSAP V0.95, UCDs
>> 
>> 
>> On Tue, 27 Jun 2006, Randall Thompson wrote:
>>
>>>   What I was hoping for was something equivalent to the UCDs 
>>> POS_EQ_RA_MAIN and POS_EQ_DEC_MAIN defining the "primary" 
>>> coordinates for a given observation, that would be included in the 
>>> query results returned for any protocol. Will there be
>> 
>>> a single equivalent UTYPE I can use instead?
>>>   Randy
>> 
>> Yes - Assuming we still try to use characterization for this, 
>> probably it will be provided by something like 
>> SpatialAxis.Coverage.Location.whatever.
>> If that proves too complex for something this fundamental (we still 
>> don't know how to specify a coordinate at this level), we will define

>> a special field for this purpose with a fixed coordinate system 
>> reference frame, as in the past.  Whatever is decided, it will be a 
>> well defined interface element with a fixed UTYPE so that you can 
>> just look up the position by its UTYPE string.
>>
>> 	- Doug
>> 
>> 
>> 
>