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).
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
> ================================================================================
>
Received on 2007-05-03Z20:00:31