Hi All -
While I think we all agree that TAP 1.0 need only provide a basic TAP interface and capabilities, we still need to define both of these, including what "basic metadata" is returned and how it is returned. Good progress has been made on this and it is not at all clear to me that agreement can't be reached soon on a basic schema, especially since the initial round of basic schemas proposed were so similar. It is highly desirable that whatever we provide with TAP 1.0 be consistent with what we plan to provide in 1.1 and subsequent versions. My personal view is that it is unacceptable to have different mechanisms for metadata delivery for TAP 1.0 and later versions - this really would represent a political compromise and design-by-committee.
The following is an attempt to merge the common elements of our various proposals into a new draft schema, omitting anything which has not been adequately discussed and agreed upon here (e.g., certain elements of the proposed VODataService schema such as "role", VOTable features such as arraysize, etc.):
TABLES
catalog_name The name of the catalog containing the table
schema_name The name of the schema for the table
table_name The name of the table itself
table_type The type of the table: TABLE or VIEW
Description A description of what the table contains
COLUMNS
catalog_name The name of the catalog containing the table
schema_name The name of the schema for the table
table_name The name of the table itself
column_name The name of the column
ordinal_position The position of this column in the table
is_nullable Whether this column may hold NULL values
data_type The native (SQL) datatype of values in this column
Votype The VOTable datatype of values in this column
Ucd The UCD describing the column
Utype The UTYPE describing the column
Unit The unit associated with values in this column
Width The character width of the column
Description A description of what the column contains
For clarity the fields for which the name is shown as lower case are taken directly from the SQL information schema, essentially the same as Pat proposed. The VO-specific additions have the first character of the field name capitalized.
In simple cases many of these could be NULL, however to support even basic ADQL queries or typical applications we probably need at least this minimal set of metadata.
What we most need to know is, is this basic metadata sufficient to support YOUR planned initial use-cases for TAP 1.0? Is anything critical to support your initial TAP 1.0 applications missing?
For reference the summary of our first round of attempts at a basic TAP information schema is attached.