TAP issues (fwd)

[Alex Szalay]

I would like to urge you to look at the INFORMATION_SCHEMA and see what 
needs to be added, in the spirit of Francois' comment. But if the rest of
it is deemed as useful info, let us not reinvent the wheel. If we go this
way, it is relatively easy yo have our own metadata tables, which are an 
extension of the INFORMATION_SCHEMA, with a small number of additional
columns.

And then we are done.

--Alex

-----Original Message-----
From: owner-voql-teg at eso.org [mailto:owner-voql-teg at eso.org] On Behalf Of
Doug Tody
Sent: Thursday, May 03, 2007 2:00 PM
To: VOQL-TEG
Subject: Re: TAP issues (fwd)

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
> ======================================================================
> ==========
>