Beijing discussions
Rob Seaman
seaman at noao.edu
Mon May 14 11:18:23 PDT 2007
I gather there will be a discussion in Beijing of how to represent
STC in a VOTable. Comments on how and/or whether this has
implications for VOEvent? It seems to me that the described use of
groups, params and fields is...how shall I say? ..."idiosyncratic"
for XML.
My issue with STC and VOEvent continues to be whether the supplied
coordinates should be taken to describe those of the pertaining
observation(s), including the explicit observatory(ies) location(s),
or rather generic targeting coordinates for subsequent follow-up
observations. I think we want to say "look here", more than, "I
looked there".
Implications for the STC standard would be a section 7.2.5 "Target
coordinates", similar to 7.2.4 "Observational Data" but with either
no ObservatoryLocation or with some general purpose construct.
Rob Seaman
NOAO
------
Begin forwarded message:
> From: Mark Taylor <m.b.taylor at bristol.ac.uk>
> Date: May 14, 2007 6:05:29 AM MST
> To: VOTable mailing list <votable at ivoa.net>
> Subject: Re: Beijing discussions
> Reply-To: Mark Taylor <m.b.taylor at bristol.ac.uk>
>
> 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 at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/
> ~mbt/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20070514/7862c443/attachment-0003.html>
More information about the voevent
mailing list