Expressing 2- and 3-D coordinates

[Rob Seaman]

I sent this earlier, but guess I wasn't previously subscribed to the  
DM forum.  Apologies if you see this message more than once.

Rob Seaman
NOAO
----

From: Rob Seaman <seaman at noao.edu>
Date: December 14, 2005 9:46:10 AM MST
To: IVOA VOTable <votable at ivoa.net>, dm at ivoa.net
Subject: Re: Expressing 2- and 3-D coordinates

Note that I am NOT copying the VOEvent list at the moment - no need  
to make waves.  However...

Arnold says:
> As you may be aware, there have been complaints about this, not  
> only from people in VOEvent but also in VOTable, who want to  
> separate the coordinates.
I hadn't previously heard that there were concerns other than from  
the raging pragmatists of VOEvent.

> The impetus for this is a desire to appease VOEvent articipants

(I presume an "articipant" is an "anticipant participant".)

"Appease" is a loaded word.  VOEvent is on the front lines for  
forming a VO-wide consensus on STC.  The best solution in the world  
is pointless if it goes unused.  VOEvent proposes to use STC - big  
time and for mission critical purposes.  Would be a shame if it  
didn't turn out that way.


Alberto Micol writes:

> In the VO, we have to handle physical quantities, which are  
> typically of vectorial nature. It seems hence very trivial to me  
> that any effort in trying to serialise the physical universe should  
> consider the Vector as a prime atomic constituent, and should not  
> try to bend it, squeeze it, or split it into something very unnatural.

My daughter is a HS freshman taking pre-calc and I've been helping  
her with matrices.  I am reminded therefore that there are a variety  
of representations for matrix arithmetic in math and physics.   
Einstein himself took time away from looking at the big picture to  
come up with his summation convention:  "I have made a great  
discovery in mathematics; I have suppressed the summation sign every  
time that the summation must be made over an index which occurs  
twice..." (http://en.wikipedia.org/wiki/Talk:Einstein_notation)

I think VO requirements are broad enough to allow for more than one  
way of representing matrices, especially two element coordinate  
vectors.  If it was good enough for Albert...


Ed Shaya states:

> It makes little difference for Value2. Either way is fine with me.

And so a consensus is formed!

> The chemists realized that arrays are so important that standard  
> XML parsers needed to be enhanced to include them. Now this is no  
> longer necessary.

...or maybe not.

We're looking at two extremes of requirement space.  The  
specification of long lists (or tables) of values clearly can benefit  
from a "power" notation.  But this should not place an undue burden  
on the more frequent need to specify simple coordinate pairs.


Roy and Matthew and Martin Hill assert:

> [A bunch of stuff I pretty much agree with.]


Francois Ochsenbein opines:

> There are two main problems:
>
> -- it happens that only 1 component of the position is present  
> (e.g. meridian   catalogs measure the RA, not the Dec).
>
> -- an array is not just a set of numbers -- in VOTable it's required
>    that all elements are expressed with the same data type (e.g.  
> double)
>    and expressed with the same unit (this makes physical sense, too).
>    It's obviously a problem for the spherical 3D coordinates
>    (2 angles and a distance); errors ellipses are also problematic
>
> One way of resolving this dilemna in VOTable was proposed at the  
> Spanish
> IVOA meeting in last October, [...]
>
> 	FIELD name="pos" type="double" arraysize="2" ucd="pos.eq" unit="rad"
> 	utype="stc:AstroCoords[coord_system_id='J2000-OPTICAL-ET']/ 
> Position2D" >
>
> [...]  This proposal was not accepted at the last IVOA meeting --  
> but I feel it's
> really worth to consider this possibility of bridging the existing  
> data models
> with large data sets expressed as VOTables. Any comments ?

Sorry I missed that discussion in Spain.  My comment is that adopting  
a complicated solution (as the only option) to a recurring  
fundamental problem will drive users away from the VO.  Many  
discussions in the VO pit computer scientists against astronomers.   
This one appears to be pitting computer scientists against each other.

The bottom line is that the VOEvent community is rather feisty and is  
driven not only by VO concerns but also by requirements external to  
the VO.  This could be taken as a description of most users that the  
VO is likely to attract in the future.  Fundamental VO standards like  
STC should be kept as simple and interoperable as practical if  
growing the VO community is a goal.

In particular, the alternative to the adoption of a simple, agile STC  
by VOEvent is the explicit representation of space-time coordinates  
within the VOEvent schema itself.  Such has already been prototyped  
by two groups.  In that case, my own proposal would be to revive the  
STCLite schema as part of VOEvent.  Not my first choice, but might be  
my last choice.

XSLT can hide a multitude of sins.

Rob Seaman
NOAO