On Mon, 30 Apr 2007, Iņaki Ortiz de Landaluce wrote:
> Regarding issues #4 and #5, here is a quick list of the table metadata
> we feel would be needed. For columns: column name, table name, utype,
> description, data type, array size, unit, ucd, values range. For tables:
> table name, description, primary key, number of rows, list of foreign
> keys. For example, utype, unit, ucd and value range are not provided by
> the Information Schema.
>
> 2. Table Metadata Output Format
> VOTable would fit for the Column description as all metadata could be
> included in the FIELD element, but the Table metadata does not fit in
> the VOTable document. Only Table Name and Description are accommodated
> within the document. As for using the DATA element to return the
> information, we would need one-to-n multiplicity to describe the foreign
> keys for table metadata.
To clarify: the proposal for using VOTable to return database and table metadata is to use VOTable as a standard table format and container, not as the "table" itself. This means we can return any arbitrary tabular information regardless of the details of how VOTable itself is structured.
For example, in the case of a table metadata query (describing one or more tables), if the metadata were the items listed above, the output table would be as follows:
o Each row of the output table describes one table.
o The columns of the output table are:
table name
description
primary key
number of rows
list of foreign keys (possible issue here)
o Some general metadata describing the overall tableset or
any relations between the described tables is also possible,
using various techniques (params, group associations, etc.).
Representing this same information in either XML or CSV would be fairly trivial as well.
Note that we may want more information than this to describe an individual table dataset. At the level of a data service, this could include generic dataset metadata as for the other DAL services (DataID, Curation, Char, etc.; this is in common with the other DAL interfaces, and is more descriptive than the resource metadata used at the registry level), as well as access metadata, e.g., an access reference to retrieve the entire table without a query.