[Fwd: Re: TAP information schema]

From: Keith Noddle <ktn-at-star.le.ac.uk>
Date: Wed, 03 Oct 2007 16:27:28 +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 Francois, On Mon, 1 Oct 2007, Francois Ochsenbein wrote:
> Did I correctly understand that your xsl scripts are directly transforming
> a VOTable into its schema (i.e. table structures) ? It's not the full
> information schema (as you noted, some items, which are not easy to capture,
> are missing) but you are demonstrating that the basics of the VOTable metadata
> can be converted into an information schema.
This is all correct. I haven't exhaustively tested the stylesheet, but you should be able to feed it any VOTable, and it will spit out a VOTable with an IS-like description of the tables.
> Is this transformation meant to be used to generate registry records ?
No. In either case, a tranformation would be necessary to convert the VOTable-based description into a form currently used by the registry.
> Anyway, it is useful for the presentation of table metadata -- but for
> queries, I don't see a priori why this organisation would be superior to
> a query to an XML database containing a concatenation of all VOTables
> contained in a server. Isn't it the way registry records are organized ?
The motivation is to enable searching of the table metadata directly through the service itself, using the same ADQL-based searching protocols as for the tables themselves. A few problems with relying on the registry to do the searching include... o Since table metadata falls into our potentially "fine-grained" information, there is no guarantee that a registry will collect and enable searching on it. o The registry search interface only supports a restricted form of ADQL using flattened data model. As a result, there is a class of complex queries, which would include the sort you might do to figure out what tables you need to query, that cannot be expressed via the standard registry search interface. o One motivation for using an IS-based approach is that it can be easily extended to additional metadata about the tables and columns without changes to the carrier XML schema (be it VOTable or VOResource). Requiring such a change would be a major barrier to introducing such information. cheers, Ray

Received on 2007-10-03Z18:20:32