Response to TAP presentations
francois at vizir.u-strasbg.fr
Thu May 17 03:03:23 PDT 2007
Sorry to disagree strongly with you on this point. Putting the metadata
in a tableset is way to do the stuff -- but you are then loosing a lot of
metadata, unless you define a very sophisticated (and therefore likely
inefficient) metadata schema:
-- how to describe the groups, especially hierarchies of groups ?
-- how to describe the virtual data (data computed on the fly) ?
-- how to describe the characterisation of the tabular data ?
The main interest I see to ask the data server for metadata is that
you can get richer metadata (at least I think it's the most valuable reason).
If the result is to restrict the set of metadata to these which are already
in fine grain registries, I feel something is wrong there.
>On Thu, 17 May 2007, Francois Ochsenbein wrote:
>> About the way the metadata are returned -- I thought I was clear enough
>> this morning about which method is prefered, but it seems I was not clear
>> enough after short discussions with other attendees.
>> Therefore I state it clearly: an empty VOTable is the preferred way
>> for several reasons:
>> 1. The result as rows containing metadata (the one that Doug seems to prefer)
>> requires a definition of the schema of these meta tables. Would likely
>> require long discussions.
>The reasons I suggest this method are mainly these:
> o I don't see how the empty VOTable method works for tableset
> metadata queries other than perhaps "columns" - how does this
> work for tables, characterization, views, etc.?
> o Putting the information in the table data makes it consistent
> with any table data query, hence we have a uniform query
> method. Client software which is set up to walk through a
> table result set (the usual JDBC-like interface) will work
> identically for both table data and metadata. No special software
> is required to extract table metadata.
> o There is no need for an explicit linkage between the
> database/tableset metadata schema and that of VOTable,
> allowing us to easily define whatever is needed to describe
> a table without requiring changes to the VOTAble standard.
> o Definition of the metadata required to describe table data and
> their relationships, in order to support nontrivial queries, should
> be part of the task TAP addresses.
>> 2. As Ray pointed out, an empty VOTable can be converted into VOResourse
>> and vice-versa.
>> 3. As Alberto Micol pointed out, tools for the ingestion of the metadata from
>> an empty VOTable already exists -- no need for additional tools there.
>> 4. From the point of view of application developers who already are parsing
>> the VOTable metadata, those I've heard of are satisfied with the empty
>> VOTable which does not require further code to decrypt the meta-schema.
>> Do you think we should install a web page with on-line voting capabilities ?
>> That could help to measure the grounds on which we are taking our decisions.
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
More information about the voql