[TAP] data type for column metadata

[Roy Williams]

Pat
This is all very comprehensive, and we thank you for your devotion in 
factoring all this machine knowledge. But there is also a much simpler 
way to do things, and it would be good to point that out in the TAP 
document.

The simple way is NOT to implement astronomical time in TAP!

We can just use floats and doubles and strings. A column may be called 
MJDtime, and be a real number, and in the natural language description 
of that column it says what the values really mean. Users read the 
documentation and make their queries: Select * where MJDtime < 54000.0. 
No flavor, no refposition, no refsystem. For TAP, Astronomical Epoch is 
simply a number.

These automated coordinate transformations are scary enough with Time. 
Is the intention now for the TAP engine to do spatial transformations? 
For example: "Select points from the X catalog (in B1950 as seen from 
Jupiter) which are in the Y region (in heliocentric supergalactic 
coordinates)".

Will it be "allowed" by the IVOA to have a TAP engine that does not have 
full support for coordinate transformations?
Roy




Patrick Dowler wrote:
> I have been mulling things over and also talked with Arnold a bit, and this 
> was the result:
>
> I think a simple extension to the column metadata would be as follows. The 
> name and datatype would be mandatory and all others optional (as they don't 
> apply in many cases, or are simply not important; if a service doesn't 
> specify that should be OK).
>
> http://www.ivoa.net/Documents/latest/STC.html
> http://tycho.usno.navy.mil/systime.html
>
> name: the column name
> datatype: the SQL-ish datatype as discussed last week
> units: units the column values are in
> refsystem: reference system or scale
>  - values taken from STC, Table 2 (time), Table 3 (space), 
>  - values from FITS WCS Paper 3 Table 1 (energy): spectral CTYPE?
> refposition: reference position
>  - values taken from STC, Table 1
> flavor: what kind of a value is it? 
>  - could be taken from STC, section 4.4.1.2.2 (CARTESIAN, SPHERICAL, etc)
>  - could be taken from STC section 4.4.1.4.2 (for doppler/velocity)?
>  - includes differentiating JD vs MJD
>  - could be taken from FITS WCS style generally
>  
> Note: In STC one differentiates energy vs frequency vs wavelength somewhat 
> implicitly via the units. In FITS WCS Paper 3 Table 1 there are explicit 
> CTYPE values for these as well as the different velocity definitions. The 
> text in STC section 4.4.1.4.2 says that a future version will be compliant 
> with the FITS WCS std. 
>
> Examples: name, datatype, units, refsystem, refposition, flavor
>
> * a column containing spatial positions:
>   pos, POINT, deg, ICRS, TOPOCENTER, UNITSPHERE
>
> * separate columns containing spatial coordinates:
>   ra, DOUBLE, deg, ICRS, TOPOCENTER, UNITSPHERE
>   dec, DOUBLE, deg, ICRS, TOPOCENTER, UNITSPHERE
> note: nothing really says which is LON and which is LAT
>
> * a column containing an instant of time
>   some_date, DOUBLE, d, UTC, TOPOCENTER, MJD
>
> * another column containing an instant in time
>   lastModified, TIMESTAMP,  <null>, UTC, <null>, <null>
> note: reference position not important for this sort of time value
>
> * a pair of columns containing energy bounds of an obervation
>   energy1, DOUBLE, m, WAVE, BARYCENTER, <null>
>   energy2, DOUBLE, m, WAVE, BARYCENTER, <null>
> note: using FITS WCS CTYPE for refsystem, no flavor needed for 1D
>
> * a column containing a  measured redshift
>   z, DOUBLE, <null>, ZOPT, BARYCENTER, <null>
> note: using FITS WCS CTYPE for refsystem
>
> * a column containing a measured velocity
>   v, DOUBLE, m s-1, VOPT, BARYCENTER, <null>
> note: using FITS WCS CTYPE for refsystem
>
> For many columns in a table, the values for refsystem, refposition, and flavor 
> will be null (not applicable), but for coordinate values they are necessary.
>
> Comments on this? 
>
>   

-- 

California Institute of Technology
626 395 3670