On Tue, 8 May 2007, Francois Ochsenbein wrote:
> Dear VOTablers,
>
> At the forthcoming Beijing meeting, there should be a discussion on
> the best way of referring to external data models within a VOTable.
> The very first target is to be able to specify clearly and unambiguously
> the space and time coordinates (the STC model) which are essential
> components of many many tables accessible in the frame of the VO.
>
> In order to be able to come to a decision, 5 different scenarios
> are included here which represent variations of possible solutions
> for describing a table with a few columns containing positions and
> observation times.
>
> I really hope that we will be able to reach a final conclusion;
> and I would appreciate to get your opinion of the preferred solution,
> including from those who will not attend the VOTable session
> (scheduled on Tuesday morning), between #1, #2, #3, #4, #5 -- hoping
> that the solution will be one of these.
Francois et al.,
sorry to have left this late, but, well, there hasn't been too much time to comment and we're all busy. My poor understanding of STC may mean there are errors in the following analysis - I hope that Arnold is lurking here to point them out.
I may or may not be able to attend part/all of the VOTable session - unfortunately it clashes with Apps1.
What is necssary is to (1) define the coordinate system (a CoordSys; probably but not necessarily an AstroCoordSys) in use and (2) to establish which FIELD/PARAM of the VOTable corresponds to which element of it. I don't believe that it's a good idea to include that link in both directions (I take it this is what is meant by "double referencing"), if only because it leads to the possibility of documents which are inconsistent in this respect and the resulting dilemma/unpredictability of software encountering them. It also makes writing such documents more complicated. Outlawing "double referencing" discounts #1 and #5.
I *think* that it's necessary to have the time and space coordinates (and possibly others such as spectral and redshift) appear as part of the same AstroCoordSys for reasons connected with relativity - Arnold, can you comment? This would discount #2.
Of the presented examples, this leaves #3 and #4, which are similar except that for the following (mutually orthogonal?) points:
(a) they use PARAM elements to reference utypes in different ways:
#3: <PARAM utype="stc:AstroCoordSystem.SpaceFrame.ICRS"
value=""/>
- vs. -
#4: <PARAM utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Type"
value="ICRS"/>
(b) #4 groups the elements hierarchically to reflect the structure of the
STC model while #3 uses a flatter structure.
(c) In #3 the AstroCoordSystem elements are inside an AstroCoords GROUP,
while in #4 they are in an AstroCoordSystem GROUP, but the reference
from the FIELDs is to an AstroCoords representation which references
the AstroCoordSystem an AstroCoordSys[tem].
(d) #4 includes
<PARAM utype="stc:AstroCoordSystem.id" value="TT_ICRS_TOPO"/>,
which I think is redundant.
I prefer the #4 style of PARAM usage in (a) unless someone knows of an STC-specific reason why it's inappropriate.
A point analogous to (b) came up in one of Monday's sessions (DAL1?) and the consensus seemed to be that the hierarchical GROUP elements was unnecessarily complicated (I'm in two minds about whether I agree with that assessment - it depends what you're trying to do).
With regards to (c), I'm not sure that #4's additional level of indirection is required. On the other hand #3's containment of AstroCoordSystem elements in an AstroCoords GROUP looks wrong (typo?).
Which leads me to suggest something like:
<GROUP utype="stc:AstroCoordSystem" ID="CoordsSys1">
<PARAM utype="stc:AstroCoordSystem.TimeFrame.TimeScale"
value="TT" />
<PARAM utype="stc:AstroCoordSystem.TimeFrame.ReferencePosition.Type"
value="TOPOCENTER" />
<PARAM utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Type"
value="ICRS" />
<PARAM utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition.Type"
value="TOPOCENTER" />
<PARAM utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor.Type"
value="SPHERICAL" />
</GROUP>
<FIELD utype="stc:AstroCoords.Time.TimeInstant.ISOTime" ref="CoordSys1" />
<FIELD utype="stc:AstroCoords.Position2D.Value2.C1" ref="CoordSys1" />
<FIELD utype="stc:AstroCoords.Coord.Value2.C2" ref="CoordSys1" />
<FIELD utype="stc:AstroCoords.Coord.Error.Value.C1" ref="CoordSys1" />
<FIELD utype="stc:AstroCoords.Coord.Error.Value.C2" ref="CoordSys1" />
(in this example I have only included the attributes relevant to this discussion, which makes all the examples quite a bit easier to read). This looks to me about as simple as one can get it which is (I contend) a Good Thing.
Note that if one uses the "Standard Libraries" in STC Appendix C and associates the stc:AstroCoordSystem utype with the relevant coordinate system, one could dispense with the GROUP element in the above, leading to something like:
<PARAM utype="stc:AstroCoordSystem" ID="CoordSys2"
xlink:type="simple" xlink:href="ivo://STClib/CoordSys#TT_ICRS_TOPO"
value=""/>
<FIELD utype="stc:AstroCoords.Time.TimeInstant.ISOTime" ref="CoordSys2" />
<FIELD utype="stc:AstroCoords.Position2D.Value2.C1" ref="CoordSys2" />
<FIELD utype="stc:AstroCoords.Coord.Value2.C2" ref="CoordSys2" />
<FIELD utype="stc:AstroCoords.Coord.Error.Value.C1" ref="CoordSys2" />
<FIELD utype="stc:AstroCoords.Coord.Error.Value.C2" ref="CoordSys2" />
Possibly a LINK would be a better choice than a PARAM here, but LINK does not at present contain a utype attribute.
I'm not sure where the utype syntax has come from in the given proposals: I can see roughly how a string like "stc:AstroCoords.Time.TimeInstant.ISOTime" maps to a chapter of the STC document, but then I'm a human - I have some concerns about attempting to do automatic interpretation of this kind of thing. utype syntax is one of the issues raised in Roy's draft roadmap, so this issue is not specific to VOTable.
Mark
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2007-05-14Z15:06:01