[TAP] data type for column metadata

[Rick Wagner]

Hello Francois (et al),

> Well, that's typically why the utype attribute was introduced:
> specify as accurately as possible what is the meaning of a parameter
> vs a data model. For instance, an ISO time could be defined as
> utype='stc:AstroCoords.Time.TimeInstant.ISOTime'
> the stc prefix referring tp Space-Time coordinates
> (there should therefore be at the top of the VOTable
> a reference to the XML schema as:
>   xmlns:stc="http://www.ivoa.net/xml/STC/stc-v1.30.xsd" )
>
> Or do you think that this is not appropriate ?
> Sure it looks complex, but Arnold would answer that
> specifying accurately which time is used is complex...

Pardon any ignorance on my part, but I don't see how we can use  
utypes to define both the format of a FIELD, and its relationship to  
a data model. For example, how can I specify that a FIELD represents  
the execution time of a simulation using  
utype='simdb:Simulation.ExecutionTime', and that is in ISO format,  
utype='stc:AstroCoords.Time.TimeInstant.ISOTime'?

I like Mark's format suggestion, since it separate the description of  
what a FIELD (or other element) represents, and how it is presented.

--Rick

>
> Cheers, francois
>
>>
>> On 2009-03-19 13:26:41 Mark Taylor wrote:
>>> I believe the best way to handle this would be to introduce an
>>> additional attribute on VOTable FIELDs (columns) called something
>>> like "format".  The interpretation of the content of this field
>>> need not (and probably should not) be specified by the VOTable
>>> standard itself, but by VOTable 'customers', for instance the TAP
>>> standard, or user communities.  A string column labelled
>>> format="iso8601" (or possibly something like format="tap:iso8601",
>>> or indeed, format="postgresql:MAC") could be processed as a string
>>> by generic VOTable libraries without requiring any changes to the
>>> VOTable standard or implementations, but an application which
>>> understood this format type could do something sensible with it
>>> as appropriate.
>>
>> I like this idea as it lets you specify the way something was  
>> encoded,
>> typically into a string. In TAP we could use that for timestamps  
>> and STC
>> regions (format="STC/S"?)... maybe some other uses that have not  
>> come to
>> light yet.
>>
>>> Having these conventions outside the VOTable standard itself means
>>> that the VOTable standard does not have to keep undergoing
>>> changes as different user communities find that the type they need
>>> is not currently offered by VOTable.  This benefits the VOTable
>>> standard (more stable) and the user communities (less effort
>>> adapting it to their uses).
>>
>> On a  practical level, can we feasibly request/expect such an  
>> addition to
>> VOTable (it appears that 1.2 is still a WD) and have TAP require  
>> that new
>> version of VOTable (for output)? On a relatively short timescale?
>>
>> -- 
>>
>> Patrick Dowler
>> Tel/Tél: (250) 363-0044
>> Canadian Astronomy Data Centre
>> National Research Council Canada
>> 5071 West Saanich Road
>> Victoria, BC V9E 2M7
>>
>> Centre canadien de donnees astronomiques
>> Conseil national de recherches Canada
>> 5071, chemin West Saanich
>> Victoria (C.-B.) V9E 2M7
> ====================================================================== 
> =
> Francois Ochsenbein    ------   Observatoire Astronomique de  
> Strasbourg
>    11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24  
> 24 29
> Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24  
> 24 17
> ====================================================================== 
> =
>