[Fwd: Sample table description using VOTable]

From: Keith Noddle <ktn-at-star.le.ac.uk>
Date: Wed, 03 Oct 2007 16:26:48 +0100

Keith. 

-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Email:  ktn-at-star.le.ac.uk
Leicester, UK   LE1 7RH         Web:    http://www.astrogrid.org


attached mail follows:

Hi Guys,

Attached is my take on the action item regarding an information 
schema-like description of a set of tables using VOTable.  In particular, 
the action was to present an example of what such a VOTable would look 
like, restricted to the metadata that is already capturable in the VOTable 
My attempt is attached as the file "tapmeta.xml".

In my cut, I focused on the VOTable data model (i.e. the FORMAT=METADATA 
approach) more so than the information schema.  The motivation was not to 
worry so much about what the names of the (meta) columns were but rather 
focus on capturing all of the components of VOTable model (and no more). 
It should therefore be clear what IS attributes are missing.

Because of the close correspondence between the VOTable data model and the 
IS-like approach shown in my example, it is straight-forward to convert a 
VOTable into the IS-like description.  To prove this, I've attached 3 
versions of a stylesheet (one for each version of VOTable) that converts a 
VOTable document into a IS-like description.  It follows, therefore, that 
if there are additional bit of info to be included that is not part of the 
VOTable model, it would have to be added by hand.

Here are specific notes:

   o  I left out the FIELD's deprecated "type" attribute"

   o  I left out the "ref" attributes as well as it's unclear whether it is
      always meaningful/useful in this context.  One use is to relate
      position columns to a coordinate system.  This might be handled
      slightly different in the STC-aware 1.2 version.  It could be added
      easily, however.

   o  This rendering does not capture information that can be encoded
      in FIELD/VALUES (min, max, null values, & controlled vocabulary).

   o  PARAM elements technically are not columns; however, some protocols
      (e.g. SIA) allow a completely uniform column (i.e. column where all
      the values are the same) to be expressed as a PARAM.  This is not
      captured in the attached example, but it perhaps could be easily.  It
      would require an additional column in the columns table indicated
      whether it was a real column or a PARAM.

cheers,
Ray
Received on 2007-10-03Z17:50:10