On Mon, 30 Apr 2007, Patrick Dowler wrote:
> - the difference in opinions on various TAP issues is not all that large
> conceptually, just lots of details differ
I agree - if we focus on the key issues and ignore for the moment protocol details, I don't think we are that far apart on a simple core TAP protocol.
> ** on TAP:
>
> My thought right now is that TAP is somewhat different from other
> DAL services in the following ways. DAL services have an implicit
> (or explicit) astronomical data model; at one level TAP has a
> table/column model and (with joins) more or less the full relational
> (RDB) model. Once database, table, and column metadata is discovered,
> TAP then exposes a custom data model (astronomical) via UCDs and/or
> utypes or otherwise. Thus, TAP does have at least two levels of data
> model implicitly included.
>
> Further, nothing above says what the instances (rows in tables) are;
> for that level of understanding one needs to declare that a table
> or TAP service contains instances of a specific data model. This is
> what other DAL services do (SIA, SSA, etc) -- they declare what kind
> of things are described/stored inside. This is also what Pedro's
> group was trying to do by making the Source Catalog Data Model and
> having a skynode declare that it held instances of that model. This
> is kind of a "coherence" that goes beyond just using utypes and UCDs
> for specific columns -- it is the shift from a custom data model to
> a standard data model.
>
> OK, I am already getting well past the reasonable email limit (need
> to scroll to read these two paragraphs... without more detail, what
> do people think of this conceptual picture? Am I crazy?
This is the basic model. Originally we talked about layering the data model bits on top of the basic table access mechanism, but in Moscow Pedro argued to combine the two, and probably it is simpler to have it all in one interface.
This is not all that much different than the other DAL interfaces, because any of these can be extended to support a more specific class of data (for example the TSAP case). In all cases there is a core model which is explicitly supported, and an extension mechanism (e.g, UTYPE/UCD) to allow other models to be used. If we proceed as we are now, ultimately TAP probably has built-in support for ubiquitous astronomical models such as for the source catalog, but can be used as a standard table model / access interface for anything else.
(and I managed to fit this into one screen)