Space-Time Coordinate Metadata RFC

This document will act as RFC centre for the Space-Time Metadata V1.21 Proposed Recommendation.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted on the data model mailing list, dm@ivoa.net.

Comments

• (1) The following comments affecting the document came from the VOEvent workshop:
  • Can Name in Coordinate be made optional?
  • What Frames should really be required in AstroCoordSystem?
  • Can the duplication of TimeScale in AstroCoordSystem and AstronTime be avoided?
  • XInclude examples in Appendix C?

-- ArnoldRots - 16 May 2005

• (2) The following comments affecting the STC-X (schema) implementation came from the VOEvent workshop:
  • Can Observatory and Observation Locations be uncoupled?
  • Can multiple Observations and multiple coordinates be accommodated in ObsDataLocation?
  • Can AstroCoordArea be made optional in ObservationLocation?
  • Can there be an simpler description for error circles in the case of 2-D spatial coordinate systems?

-- ArnoldRots - 16 May 2005

• (3) I'm concerned about the amount of "implementation" that has been done to date. Could we have a definitive statement of what is serving as our 2 implementations?
  I don't think having some example XML instance documents is sufficient for serving as an "implementation". We need actual software that actually does something with it. Use of STC in SkyNode does qualify; however, I think it is fair to say that this is only partial use. Something like the footprint service would perhaps provide more coverage of the schema. A stylesheet that converts STC into an astronomer-friendly description of a coordinate system, region, etc. would also be useful. It's not until a developer (because users are going to look at this stuff) actually sits down with STC and tries to use it will we understand if the schema does the job.

-- RayPlante - 16 May 2005

• (4) From the VOTable discussion came the following comments:
  • Epoch is needed, especially for positions corrected for proper motion to a date other than the observing date.
  • Would it be possible to link from the table to the STC element(s), rather than the other way around?
  • Can we leave metadata out if they're not relevant or unknown?

-- ArnoldRots - 17 May 2005

• (5) Inheritance of Ellipse from Circle: As you note in the document, one might think the inheritance relation should go the other way. I'm nervous about Ellipse inheriting from Circle, since it is not true that an Ellipse is-a Circle. If you are implementing STC in an object-oriented programming language in a way which mirrors the inheritances in the STC UML then you could end up with an object which is an instance of the class Circle, but which does not obey the invariants one would expect for a Circle (if it's not clear why this is a Bad Thing I can try to come up with an example on request). Your point about keeping Circle simple is a reasonable one however. Can I suggest that Circle and Ellipse are simply both subclasses of Region with no additional inheritance relation?

- MarkTaylor - 26 May 2005

• (6) XInclude: It is clearly a good idea to have a library of commonly-used snippets of XML for inclusion in STC documents to make life easier for their authors. However, XInclude support is not ubiquitous. In particular I don't think that Crimson, which is the XML parser that comes with Sun's Java J2SE1.4 runtime, can understand it - certainly it doesn't perform XInclude processing by default and there is no standard way in the API to make it do so. J2SE1.5 does provide XInclude facilities, but I'd say that most people are not currently using 1.5. Supporting the XInclude mechanism could thus represent a significant (though not insurmountable) extra burden for people writing STC processing software in Java. I don't know what the situation is in other languages.

There is an alternative inclusion mechanism, external parsed entities, which is part of the XML 1.0 recommendation itself, and thus more widely supported by XML parsers (technically only validating parsers are required to include the referenced content, but I think in most cases non-validating ones will be able to do so as well). Instead of writing

  <?xml version="1.0"?>
  <stc xmlns:xi="http://www.w3.org/2001/XInclude">
    <xi:include href="http://www.ivoa.net/xml/STC/ICRS-TT-TOPO.xml"/>
  </stc>

you would write

  <?xml version="1.0"?>
  <!DOCTYPE stc [
    <!ENTITY icrs-tt-topo
             SYSTEM "http://www.ivoa.net/xml/STC/ICRS-TT-TOPO.xml">
  ]>
  <stc>
    &icrs-tt-topo;
  </stc>

What the application software sees as the document's content is the same in both cases.

There is some discussion of the relationship between XInclude and external entities in the XInclude standard, including some points which you might see as advantages of XInclude over entities. Possibly XInclude is the better way of doing this, but I think the matter deserves some explicit thought.

As far as the STC [proposed] recommendation goes, it may be best to sidestep this question by just avoiding mention of XInclude in the document and talking about an unspecified inclusion mechanism. It's then up to STC document authors how they do it. The content of the library XML snippets can be the same in either case. -- MarkTaylor - 26 May 2005

• (7) sufficient and necessary: I'm sure it's only my dim-wittedness, but it's not clear to me from the introductory comments in section 3 what the information provided by the metadata is supposed to be sufficent and necessary for. Can you add a bit more explanation for aid of the dim-wittted?

-- MarkTaylor - 27 May 2005

• (8) Position angle: Could you please add an example using position angles? I am interested in describing a complex polygon (instrument field of view) rotated by a given angle.

-- FrancescoPierfederici - 30 May 2005

• (9) 4.5.4.2 DopplerDefinition I do not think that the concepts of RADIO and OPTICAL are useful or necessary. There should be no difference in the velocity depending whether you use frequency or wavelength. Why stop there; X-ray astronomers use energy e.g. KeV and you could define an X-ray velocity. You could define a non-relativistic velocity maybe. Also, technically you have blueshifts as well. Another issue is that redshifts in distant objects are not doppler shifts. They are caused by the expansion of the Universe which technically is not velocity i.e. objects with redshifts of 6 are not moving at their "doppler velocities".

-- RichardMcMahon - 30 May 2005

• (10) The document for which comments are requested contains text and UML-like diagrams. But it also has in section 7 a link to a document containing an XML schema for STC in XMLSpy format. It seems that there are significant discrepancies between the two different models, the one in XML schema and the UML. In particular it seems that the XML schema is much more detailed, look for example to Referenceposition.

My question is how to evaluate the RFC. Should the XML schema document be considered part of the RFC, in the sense that it is proposed as a standard as well ? Or is it supposed to be an implementation as Jonathan suggested in Kyoto. But in that case are we allowed/assumed to comment on the proposed implementation and its compatibility if not equivalence to the UML in the main document ?

-- GerardLemson - 9 June 2005

• (11) Rotations: Forgive me for being dense here, but how would one describe an arbitrary polygon rotated by an arbitrary angle? Similarly, how would one describe, say, a triangle?

-- FrancescoPierfederici - 10 June 2005

• (12) ReferencePosition: I think it would be usefull to extend the list of standard origins to the barycenter of the planetary systems (Jupiter, Saturn, Uranus and Neptune) because the planetary theories DExxx (JPL) and VSOPxx (IMCCE/BDL) provide, by default, the position of the barycenter of the planetary systems. In this way, it will be possible to define the origin of the spatial coordinate system of the natural satellites theories of motion relatively to the barycenter or the center of mass.

Moreover, it should be usefull to define generic barycenter and center of mass origins to allow the definition of the origin of the spatial coordinate system for any planetary system. It is necessary, for example, to provide the ephemeris of natural satellites of asteroids.

-- JeromeBerthier - 13 Jun 2005

• (13) SpaceRefFrame: In order to be coherent with other definitions, and because it will be usefull for physical ephemerides, I propose to define BODY_C (Generic planetocentric "BODY" coordinates) and BODY_G (Generic planetographic "BODY" coordinates) instead of only BODY.

-- JeromeBerthier - 13 Jun 2005

• (14) TT and LST Timescales:

Here are two comments related to solar system bodies explored by space experiments or/and for simulations. a) Comments on LST, Table2 should be extended to in-situ space experiments on surfaces of solar system bodies. Here we understand ground-based as "ground-based on Earth". b) TT can also be used in this case, but units of TT (TimeCoord) are related to Earth only. The possibility to have an extension to body-related TimeCoord can be achieve using LOCAL Timescale, but extended to "not only simulation". The use of a day related to the body in TimeCoord is then needed. Eventually "year" also, but not necessary "second".

-- AlainSARKISSIAN - 14 Jun 2005

Additional comments about STC, mostly originated from trials to connect VOTable to STC

• (15) The Various Spherical Coordinates (2D and 3D)

In the "CoordFlavor" element concerning spherical and unitsphere: different conventions are in use for the 2nd angle (latitude). The latitude convention measures this second angle from the equatorial plane, but other conventions measure this second angle angle from one of the poles (as "north polar distance" or "south polar distance").

• (16) The Question of Epoch (Question (4) of the RFC page)

The epoch of a coordinate system represents the date to which the spherical coordinates are reduced. After reflexion, it looks more logical to attach the Epoch to the AstroCoords structure (section 4.6)

• (17) The Question of Units

The STC defines the units as an attribute to the AstroCoords elements. When used in the VOTable context, a conflict may (and frequently does) arise between the units defined at the STC/AstroCoords and the units defined in the VOTable(s). One solution could be that STC defines only default (suggested) units.

Related questions: (a) heterogeneous units like "deg deg m" have no physical meaning, and are a source of problems for unit interpretors and (b) units may differ between value, errors and sizes.

• (18) Question about Velocity Units

The schema contains strange definitions for the units defined for velocities with 2 attributes "unit" and "vel_time_unit", why can't there be a single "unit" attribute taking the values "km/s" or "arcsec/yr" ?

• (19) Format of the angular/time values

For time it is possible to use a large variety of formats, but for angles the sexagesimal is not allowed?

• (20) Separation of Axes

In the VOTable context, we need to be able to refer to one axis of the coordinate frame, and it is currently not possible to do so via XPath or "utype" mechanism. Several possibilities of adding this possibility can be imagined (more on the discussion list).

-- FrancoisOchsenbein - 16 Jun 2005

• (21) Resolution, Size and PixSize status

Many people would like to use STC as an abstract model for Coordinates to be reused in various more practical contexts. According to that it would be nice to have independant definitions for "CoordResolution" "CoordSize" and "CoordPixSize" independant from Coordinates. Actually this is already the case in the xml schema but not in the document. Paragraphs 4.3.1.4, 4.3.1.5, 4.3.1.6 should be "upgraded" to the status of 4.4, 4.5, 4.6 to describe these concepts as independant features and just referred to in 4.3.1. By the way, as mentionned in the draft (4.3.1.5) CoordSize clearly depends on the context which means it is more related to the process of observation/simulation than to the abstract definition of Coordinates. This would also emphasize the need of the redefinition of Size outside Coords.

-- FrancoisBonnarel 17 Jun 2005

• (22) Resolution, pixelsize and size (section 4.3.1)

In the usage we want to make of STC in other modeling efforts, namely Observation and Characterisation data models, we also pointed out the concepts of Resolution (CoordResolution in STC) and Sampling(Precision) (CoordPixSize in STC) as properties of a single observation or a data collection (surveys, for instance). Each concept is described on each axis: spatial, temporal, spectral, and with several possible layers of description. The fact that Resolution is embedded below Coordinates in the UML diagram, makes it more difficult to re-use STC classes in the Characterisation UML diagram itself.

Concerning units used for Resolution or PixSize, astronomers may use different units from what is used in Coordinates. For instance, positions may be given in degrees and Resolution (spatial) in arcseconds instead. Pixsize for the time coordinates may be given as seconds and not hhmnss as the time coos. It seems important to allow these concepts to have their own units redefined with their value (as any quantity); if no units attribute is redefined, the Coordinates units could be used as default.

-- MireilleLouys 20 Jun 2005

• (23) Position Angle and implications of metric (section 4.5.2.5)

The notion of Position Angle raises questions of whether this can be appropriate in all circumstances or whether it needs to be restricted to use in cases where the coordinate system has a well-defined Euclidean metric. (more on the dm discussion list)

-- SteveAllen 2005-06-21

---

Responses

• (1) The four requests from VOEvent affecting the document are reasonable and I will amend the document accordingly. The corresponding modifications to the schema implementation are minor and do not affect the validity of existing documents.

Specifically:

• • CoordName in Section 4.3.1 will be made optional.
  • SpectralFrame will be dropped from the list of required frames for AstroCoordSystem in Section 4.5.
  • TimeScale will be made optional in AstronTime in Section 4.6.1.1, though it will be stressed that it should only be omitted if that element is associated with and AstroCoordSystem.
  • I will suggest a standard naming of XInclude files and the IDs they contain, to reflect their contents and provide examples for ICRS-TT-TOPO and FK5-UTC-TOPO as representing commonly used cases.

-- ArnoldRots - 16 May 2005

• (2) As to the four comments from VOEvent on the schema implementation: the last two are minor and will be implemented, while the first two need additional study; none of them affect the PR or existing documents based on the schemata.
  

-- ArnoldRots - 16 May 2005

• A few typos were pointed out and a suggestion for improvement (use of different units) was made for the example in Appendix B.4: The coord_system_id should be "ICRS-TT-TOPO", the wavelength units might be changed to "nm", the Start and Stop Times need to be corrected, and the pixel number upper limits need to be corrected. These changes will be made.
  

-- ArnoldRots - 16 May 2005

• A query from the Catalog group made me realize that 3-D spherical coordinates need to be extended to allow "deg deg Mpc" as units in Section 4.5.2.2; this will be accommodated.
  

-- ArnoldRots - 16 May 2005

• (3) There are two applications that I am currently aware of: David Berry has built STC support into AST and there is a partial implementation in SkyNode, as RayPlante pointed out.

-- ArnoldRots - 17 May 2005

• (4) The need for an epoch is acknowledged and will be added in Section 4.5.2.3.
  The direction of the linking is only an issue in the schema, not the document. The reverse linking will be accommodated by providing the "leaves" of the coordinate element with ID attributes and making them nillable. My main concern is whether a document with reverse linking is robust in terms of ensuring sufficient (and consistent) information to allow execution of coordinate transformations.
  It is dangerous for a service provider to claim being able to fathom all the needs of all potential users, deciding what metadata they do need and what they don't. It may be correct in many cases, but there are also many in the grey area where the research interests of data providers may color their perception of their users' needs. It is far better to provide a complete set of metadata in all situations. And STC provides for UNKNOWN as a legitimate value in those cases where it is appropriate.

-- ArnoldRots - 17 May 2005

• (5) As indicated in the document, I agree that the direction of inheritance is the reverse of what it should be. My overriding concern was, as you point out, to allow the circle to be specified in as simple a way as possible. And, as we discussed in Kyoto, the better solution is indeed what you suggest: make Circle and Ellipse separate Shapes.

-- ArnoldRots - 30 May 2005

• (6) Thank you for the lucid comparison. Your suggestion is a good one: to leave the inclusion mechanism up to the users or some other authority (although that in itself does not solve the issue of support for XInclude), especially since it does not affect either the schema or the library.

-- ArnoldRots - 30 May 2005

• (7) Sufficient and necessary for knowing precisely what is meant and to perform coordinate transformations. I will try to elucidate this.

-- ArnoldRots - 30 May 2005

• (8) I will be happy to include an example of a Position Angle, but note that position angles only apply to ellipses (including error and size ellipses) and sectors, not to polygons.

-- ArnoldRots - 30 May 2005

• (9) I think this comment is based on a misconception. The document states clearly that Doppler velocities are defined by a formalism and are not (necessarily) physical velocities. The terms "optical" and "radio" definition have been in common use for more than three decades and it is at least known what is meant by them. The practice resulted from a regrettable disconnect between radio and optical astronomers dating back five decades, but we will have to live with it. The suggested X-ray definition, by the way, would be the same as the radio definition: keV runs the same way as Hz; fortunately X-ray astronomers resisted the temptation. For a more exhaustive treatment, see the third FITS WCS paper that is currently in voting stage.

-- ArnoldRots - 30 May 2005

• (10) After various discussions with Jonathan, it was decided that it seems most appropriate to consider the schemata part of the proposed recommendation.

-- ArnoldRots - 28 Jun 2005

• (11) (This is a follow-up on issue 8) Polygons are specified by the positions of their vertices. If one rotates a polygon, the vertex coordinates change. Position or rotation angles are not part of the specification of polygons.

-- ArnoldRots - 28 Jun 2005

• (12,13) These are reasonable requests and we will add them. Note that the design of the schemata is such that the lists of reference positions and frames are extendable through additional schema files.

-- ArnoldRots - 28 Jun 2005

• (14) These are valid comments, but I would prefer to leave them for a later version since they require careful consideration of the conventions while their practical application is not imminent. If desparately needed, they can be provided through an extension schema.

-- ArnoldRots - 28 Jun 2005

• (15) A spherical coordinate system centered on the north pole is already provided ("POLAR"). We will add a second one, "SOUTHPOLAR".

-- ArnoldRots - 28 Jun 2005

• (16) Yes, private communication with David Berry had convinced us that this is the correct thing to do; an Epoch will be added to the coodinates and to regions.

-- ArnoldRots - 28 Jun 2005

• (17) We will add an optional unit attribute to the individual components of the astroCoordsType; that should take care of the issue of mixed units. As to "deg deg m": it is not elegant, but it will not confuse parsers since all allowable units are enumerated; and there is symmetry in it, in the sense that the units of a list of doubles are specified through a list of strings.

-- ArnoldRots - 28 Jun 2005

• (18) It was a matter of efficiency: there are currently 13 recognized units of length and 6 units of time; the current construct obviates the need for 78 additional enumerations and means that newly defined units, either in space or time, only need to be enumerated once.

-- ArnoldRots - 28 Jun 2005

• (19) After discussions in the WG, it was decided to drop support for sexagesimal coordinates since it complicated the schema considerably. After all, it's primarily software that is supposed to be able to deal with these documents; no doubt someone can easily put a style sheet together that will take care of this. Nor is this situation unique: FITS does not support sexagesimal, either.

-- ArnoldRots - 28 Jun 2005

• (20) This issue was carefully considered in the WG and it was decided that spatial axes need to be considered as a vector. I don't know what is the status of XPath 2.0, but it is supposed to handle lists. It seems to me that these vectors can be adequately handled through the VOTable group element type.

-- ArnoldRots - 28 Jun 2005

• (21) Although there are arguments in favor of Francois' position, in the context of the coordinate metadata it makes more sense to treat the properties of each coordinate axis as a compound object. For instance, in a situation where one is providing just a simple position, the full information is contained in coordinate value, error, and resolution. A coordinate is more than just a single value, though the composition of the compound object depends on the context. Not all components are needed in all circumstances.

-- ArnoldRots - 28 Jun 2005

• (22) As argued under issue 21, there are good reasons to keep these properties as part of a compound coordinate object. I think the issues raised here can be addressed by the addition of ID tags (see response to issue 4) and by allowing optional unit attributes (see response to issue 17).

-- ArnoldRots - 28 Jun 2005

• (23) I will add text that explicitly states that pixel coordinates will by convention be considered flat Cartesian axes, as well as some caveats concerning the applicability of the concept of position angles, as suggested by David Berry.

-- ArnoldRots - 28 Jun 2005

---