Expressing 2- and 3-D coordinates

[Alberto Micol]

At the cost of being trivial:
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.

Of course, on the other hand, I'm quite will aware that the
Object Database Management System, which should have solved all our  
problems,
succumbed in favour of the already consolidated RDBMS model.

The pros are quite clear, as per Arnold's email.
But the cons?
Let me ask some question that would help me understand better.

- Would it be so difficult to modify the VOTable schema to allow arrays
within a tabular cell?

- How difficult would it be for the average XML parser to understand it?

- And would the accompanying UCD be able to explain the vectorial nature
   of the interested FIELD? (Is it up to the UCD to do so?)

- What other disadvantages are behind the corner that I can't see from  
here?

Thanks,

Alberto


On Dec 13, 2005, at 15:22, Arnold Rots wrote:

> A question has come up on expressing multi-dimensional STC coordinates
> in the context of VOEvent that I would like to put to the DM forum.
>
> In the STC schemata I have implemented coordinate vectors and error
> matrices for 2-D and 3-D spatial coordinates as lists of 2, 3, 4, or 9
> doubles - the equivalent of arrays of specific length.
> It is perfectly clear and unambiguous XML and it leads to something
> like:
>
> <Position2D>
>   <Value2>140 69</Value2>
>   <Error2Matrix>0.05 0.0 0.0 0.05</Error2Matrix>
> </Position2D>
>
> 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.  We have always argued that these coordinates need to be
> considered as a vector and should not be treated as separate items -
> for one thing, errors, sizes, and regions are functions of the vectors
> in non-separable form.
>
> Now an old proposal has been presented again (I believe it was
> considered and rejected before) and we need to think about it.
> It is to make the individual vector components separate elements
> within a vector element, resulting in:
>
> <Position2D>
>   <Value2>
>     <Coord1>140</Coord1>
>     <Coord2>69</Coord2>
>   </Value2>
>   <Error2Matrix>
>     <M11>0.05</M11>
>     <M12>0.0</M12>
>     <M21>0.0</M21>
>     <M22>0.05</M22>
>   </Error2Matrix>
> </Position2D>
>
> Of course, the same nesting would apply to all other appearances of
> multi-dimensional coordinates, e.g., in regions.  And the referencing
> mechanism would have to be propagated through all nesting levels.
>
> The impetus for this is a desire to appease VOEvent articipants who
> have complained that parsers have trouble parsing the lists of doubles.
> I believe this is a valid issue since XPath1 does not handle
> individual elements in lists; XPath2 is supposed to but there are
> rumors that it might not.  On the other hand, one might argue, of
> course, that one should always retrieve the entire vector.
>
> The problem, of course, is that it seems a rather laborious way to
> describe something that is available and supported by XML Schema (list
> types) and it makes the documents even more verbose.
> On the other hand, it would also resolve one of the issues that
> VOTable has with STC.  Although in that case use of groups (to mimic
> the lists) are also an appropriate solution.
>
> VOEvent has been told that this had to be run by DM - like STCLite -
> and might be rejected on solid grounds.  Here I don't quite see the
> problems that STCLite had but I'd welcome any thoughts and wisdoms you
> may have on this issue.
>
> Cheers,
>
>   - Arnold
>
>
> ----------------------------------------------------------------------- 
> ---
> Arnold H. Rots                                Chandra X-ray Science  
> Center
> Smithsonian Astrophysical Observatory                tel:  +1 617 496  
> 7701
> 60 Garden Street, MS 67                              fax:  +1 617 495  
> 7356
> Cambridge, MA 02138                              
> arots at head.cfa.harvard.edu
> USA                                      
> http://hea-www.harvard.edu/~arots/
> ----------------------------------------------------------------------- 
> ---
>
Alberto Micol
ST-ECF HST Archive Scientist