TAP issues (fwd)

[Doug Tody]

There are likely problems with merely adopting the information
schema, e.g.: many sites may not want to expose their physical
database structure to the world; many DBMS implementations may only
partially implement the schema, and we do not want to get into the
business of implementing it for them.  Hence while we may take the
information schema as a starting point, we will probably want to
restrict what we adopt to a subset, and extend it to add what we
need for our applications.  This is essentially the logic which led
to the creation of ADQL as well.  I agree though, that it would be a
mistake to reinvent the thing (which could well happen if we started
with for example, the VOTable schema, and added a bit here and a bit
there as time went on).  - Doug


On Thu, 3 May 2007, Alex Szalay wrote:

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