Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Data Access
-
Labels:
-
Team:Architecture
Description
The TAP_SCHEMA data model for the schema of a set of data exposed via TAP includes a variety of elements that are intended to provide hints to user interfaces for how the organization of the data should be presented in interfaces. These include:
For "schemas"
In TAP_SCHEMA.schemas, the description and schema_index attributes for a "schema" (in the TAP sense) affect the UI presentation. schema_index, in particular, defines a suggested order of presentation of the "schemas" in a user interface.
For tables
In TAP_SCHEMA.tables, the description and table_index attributes for a table. From the standard:
Clients may order by table_index (ascending) so lower index tables would appear earlier in a listing.
For columns
In TAP_SCHEMA.columns, the description, principal, and column_index attributes for a table. From the standard:
The principal, indexed, and std columns are boolean values implemented as integers. As such, the value must be 0 or 1; no other values are allowed.
The principal flag indicates that the column is considered a core part of the content; clients can use this hint to make the principal column(s) visible, for example by selecting them by default in generating an ADQL query. In cases where the service selects the columns to return (such as a query language without an explicit output selection), the principal column indicates those columns that are returned by default.
(...)
The column_index is used to recommend column ordering for clients. Clients may order by column_index (ascending) so lower index columns would appear earlier in a listing. This is useful for keeping related columns together in output or display.
Note that there is a single TAP_SCHEMA.columns table for all the tables on a TAP service. So all the column_index values appear in a single table. However, they are primarily only meaningful in the context of the display of attributes of a single table, so it is OK if columns from different tables share a column_index value.
In general
For the *_index attributes, as they have to define an ordering, it may not be appropriate for them to be sourced "locally" with the definitions of the tables and columns in the Felis source files. Most likely the system that takes Felis definitions and produces TAP_SCHEMA content from them needs an additional input source that can provide the ordering "after the fact".
(The following is not part of the task of this ticket, it's here just for context.) We should establish a pattern for the description elements - an approximate length range for the content, for instance, and a standard for their character representation (UTF-8?) and markup, if any.
Attachments
Issue Links
- relates to
-
DM-17473 Provide "*_index" and "principal" metadata for the PDAC WISE data
- Won't Fix
-
DM-29939 Fix table_index support in Felis tooling
- Done
-
DM-30211 Introduce a rudimentary means for controlling the schema_index values in TAP_SCHEMA
- Invalid
- split to
-
DM-30002 Provide mechanism for curating schema_index (and perhaps table_index) in TAP_SCHEMA
- To Do
There's already support for adding:
Schema object:
tap:schema_index
Table object:
tap:table_index
Column Object:
tap:principal
tap:std
tap:column_index
These will be properly propagated to TAP_SCHEMA by load-tap.
There's no need to use a tap:description because we already have a description that will also fill that field. I can add support for a tap:description that will override a description on a Schema/Table/Column, the same way you can override a datatype with a mysql:datatype, for example.
I will consider this ticket a request to update the documentation. I was trying to see if some of the standardization of the vocabulary needs to be something IVOA agrees on. There wasn't that much interest at the last IVOA meeting, and I'd been working on auth so I punted on it. I think, as defined, the properties are reasonable though. If you think we should also have an extra tap:description I can add it as well, but I think we should use description where possible.