Response to TAP presentations

[Francois Ochsenbein]

Doug,

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.

--francois

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