Difference: STCMetadataRFC1dot21 (12 vs. 13)

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?

• (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?

• (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.

• (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?

• (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?

• (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>

  <?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>

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?

• (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.

• (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

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.

• • 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.

• (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.
  

• 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.
  

• 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.
  

• (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.

• (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.

• (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.

• (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.

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

• (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.

• (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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->