From: Arnold Rots Subject: DTD for Space-Time Information (2) To: votable@us-vo.org, metadata@us-vo.org, cfa_nvo@head-cfa.harvard.edu Date: Thu, 11 Apr 2002 15:52:46 -0400 (EDT) Cc: rb@astro.caltech.edu (Robert Brunner), womullan@yahoo.co.uk (William O'Mullan), szalay@jhu.edu (Alex Szalay) Here is the next version (1.2) of the Spce-time coordinate DTD. I have rationalized the coordinate vectors and moved things around a little. In addition, I have added a catalog data element and suggested a way to tie the UCDs in, as well as ensuring proper coordinate combinations in VOTable instances. At the end I have provided an example that illustrates this. I think it solves the issue that Tom raised and that I have been trying to address with this DTD: how to ensure consistent AND sufficient coordinate information. - Arnold -------------------------------------------------------------------------- Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 81 fax: +1 617 495 7356 Cambridge, MA 02138 arots@head-cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ -------------------------------------------------------------------------- $Id: coords.xml,v 1.2 2002/04/11 19:36:36 arots Exp arots $ Space-time Coordinate Definitions for the VOTable ================================================= Arnold Rots CfA/CXC This is a draft of hierarchical structures (classes) to be used to specifying space-time related metadata. The problem with the UCD is that it is purely phenomenological, while what we need for metadata is something that ensures completeness and self-consistency. In order to achieve that I am proposing to build metadata objects with required structures, where the individual attribute keywords are taken from en (expanded) UCD list. What remains to be done is to tie attributes to the UCD keywords. For UCDs, see: http://cdsweb.u-strasbg.fr/doc/UCD.htx What follows is an attempt to specify the space-time metadata in XML which will hopefully make its way into the VOTable. (I have not yet tried to understand schemata). The classes have been defined almost exclusively through ELEMENT definitions; that is not necessarily the way it needs to be implemented but it provides the required logic and is consistent with the current state of VOTable. Roy raised the question whether more elements should be defined to replace attributes. I have clearly chosen for elements with enumerated attributes to specify particular configurations (in particular, COOSYS), but if there is a better way to design a flexible, though rigorous, structure, then I would be happy to pursue that. Note that time and space need to be kept together. For instance, when the time reference position is moved (say, to the barycenter) the spatial coordinates are used for that transform and needed in order to interpret time. The basic elements are: SEARCH_LOCATION Contains a query CATENTRY_LOCATION Coordinate definition for catalog data OBSERVATORY_LOCATION \ Together describe returned OBSERVATION_LOCATION / observational data RESOURCE_PROFILE Contains the resource profile What needs to be enforced is that the values of all attributes of the top level objects are inherited by all child objects. Specifically, child objects of the same parent are required to use the same epoch, equinox, time scale, time format, reference positions, etc. Other consistencies that need to be enforced are coordinate types, including when given in a referenced FITS (ephemeris) file. I have tried to do this through the coosys_id and coordloc_id attributes. But it is not entirely clear to me whether the preferred way would be to include coosus_id in COORDS or in its child elements, or both. The default units are meter, degree, and second, though day may be used for JD and MJD formats. Of special note is the FITS REGION file that is allowed to define a coordinate area. The specification is available at: http://hea-www.harvard.edu/~arots/asc/fits/region.ps The next steps -------------- As noted above, we need to tie the UCDs to this description. I propose the following for catalog data containing positional fields: define an CATENTRY_LOCATION object where the actual coordinate attributes are given the corresponding UCDs as values (those UCDs being the ones identifying the relevant columns). I have appended an example at the end of this document. As important, though, is the issue of coordinate transformations (WCS specifications). The DTD given below is adequate for catalog data, for queries, and for resource profiles, but says nothing about actual image content or alternative coordinate systems (aside from, perhaps, specifying the center of the image); for that one would still have to go to the FITS headers. The simple thing to do is to define a WCS element and allow multiple instances in each VOTable to accommodate alternate systems (i.e., transformations). However, one has to be careful, here. It is simple enough to devise a way to do this for traditional image files (an n-dimensional array of scalar values), but one would want the scheme also to work for more exotic data products (sparse images, function-defined images, various tables, etc.). It may, therefore, be better to wait until the Data Model definition is further along. Objects ======= Example from Section 1.1 of VOTable Document ============================================ I have taken the example from Section 1.1 of the VOTable document and added the space-time coordinate elements defined above, with proper referencing. I believe this may solve Tom's quandary. This parameter is designed to store the observer's name Some bright stars
Procyon114.827 5.227 4 5 3 4 3 2 1 2 3 3 5 6
Vega279.234 38.7828 7 8 6 8 6