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
Received on 2005-12-14Z17:47:58