[TAP] data type for column metadata

[Rob Seaman]

On Mar 24, 2009, at 10:16 AM, Patrick Dowler wrote:

> On 2009-03-24 03:03:48 Francois Ochsenbein wrote:
>> utype='stc:AstroCoords.Time.TimeInstant.ISOTime'
>
> I agree with Rick that this seems to conflate the encoding (ISOTime)  
> and the
> fact that it is a timestamp. That is, the last dot in the above  
> utype is
> crossing the boundary from data model to format. So this would look  
> better to
> me as:
>
> utype="stc:AstroCoords.Time.TimeInstant" format="iso8601"
>
> That would be OK for a "generic" timestamp in services with no other  
> data
> model, which still leaves one having to replace that utype with  
> another one
> from a higher level data model,

Try replacing the notion of a generic timestamp with "I am a distance"  
or "I am a magnitude".  Is there really any useful reason for  
expressing something so general purpose as "I am a timestamp"?  This  
is very different from an epoch embedded in a data model such as "I am  
mid-exposure".  If there is no specific data model, it isn't clear  
that a utype has any utility.

STC should only be mixed in when describing the nature of the  
timescale and the location of the observer (e.g., barycentric vs.  
topocentric).  In particular (and putting aside the sexagesimal format  
issues), ISO 8601 does not imply UTC.

The STC issues will typically be orthogonal to the data model issues.   
The formatting/units/data-type issues are orthogonal to both.

Like Doug said:

	"if we are able to map a data model into a set of UTYPEs we can then  
represent in many different ways and manipulate it in many contexts."

The critical epochs and intervals embedded in some data model remain  
the same whatever the underlying timescale, whether expressed  
topocentrically or barycentrically, whether formatted sexagesimally or  
as floating point, and whatever the units.

We shouldn't try to make utypes capture all that.

Rob