TAP issues (fwd)

[Doug Tody]

Hi All -

I also think it is time to begin to specify this schema, as several
folks have already suggested, and this is a case where the experience
of certain TEG members in dealing with complex astronomical queries
will be especially needed.

My own view on the information schema issue is that it is the right
approach, however we cannot use SQL information schema directly, for
all the reasons which others have already noted.  We need to define
our own abstract schema, for many of the same reasons that we had to
define our own version of SQL (ADQL).

>   It could be noticed that the "SCHEMA" tables way enables more
>   sophisticated queries of metadata than the "methods" -- which on
>   the other hand are easier to handle in the basic approach

We don't have to permit ADQL to be used to query schema tables; it
would be easy to do so in many cases, but this could be disallowed
or relegated to an optional advanced capability.  The custom methods
approach on the other hand is not necessarily simpler, as it is less
extensible (it is easier to add a new schema table than a new service
operation), and the common interface provided by representing schema
tables as any other table allows all elements of the query interface
to be used directly without any additional effort.  In either case
a simple query against an element of the schema metadata will reduce
to a single fixed URL.

In any case, the more important thing is the schema itself and what it
defines.

>   relational schema. Some components are probably not important: is
>   it for instance important to specify how indexes are built ? or
>   to specify that some "table" is in reality a view ?

Probably at this level we only need to know that an index exists,
however it is more fundamental to know that a View is available
to view a primary table or tables, and not a separate data table.
The View is a powerful mechanism and could be very useful, e.g.,
for viewing very large source catalogs which may have hundreds of
fields (the old "VERB" parameter was a crude form of a view).  It is
attractive for a DBMS or data collection to define its own views
(as with the general problem of complex data elsewhere in DAL).

 	- Doug



On Thu, 3 May 2007, Francois Ochsenbein wrote:

>
> Hi,
>
> About the metadata access and getCapabilities:
>
> -- the specification of which version of ADQL/VOQL (if any) suggested
>   by Maria looks to me a useful component of the getCapabilities
>   (it should obviously be stored also in the register)
>
> -- for the metada discovery, I would like to insist on the semantics
>   part (meaning of the parameters), which is in my opinion at least
>   as important to issue meaningful queries as the description of the
>   relational schema. Some components are probably not important: is
>   it for instance important to specify how indexes are built ? or
>   to specify that some "table" is in reality a view ?
>
>   Getting the metadata have been proposed via essentially two ways:
>   either via methods like getTable() getColumn() getRelations()...,
>   or via a set of SCHEMA tables. In both cases, there is a need
>   for an accurate description of the components making up the
>   table(s), column(s) etc. The "SCHEMA" tables implementation could
>   hardly be some standard component of a DBMS, our needs for units,
>   UCDs, utypes etc being quite specific -- and being a fundamental
>   piece of the metadata retrieval, an evolution could be quite
>   difficult.
>
>   It could be noticed that the "SCHEMA" tables way enables more
>   sophisticated queries of metadata than the "methods" -- which on
>   the other hand are easier to handle in the basic approach
>
> All this was already discussed last year -- maybe it would be time
> to write down an actual proposal for this metadata components or schema ?
>
> --Francois
> ================================================================================
> Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
>   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
> ================================================================================
>