Hi Francois -
I am not sure we are communicating here, but I will try to clarify. I am *not* suggesting putting the metadata in a tableset, I am talking about *describing* the metadata for a tableset. I agree that the server may return richer metadata and that we do not want to lose metadata by forcing it into a restrictive schema (unless perhaps this is for a more restricted purpose such as discovery).
On the specific issue of returning metadata as a dataless VOTable, I do not see how this can work for anything except possibly SCHEMA.columns, and only if we restrict ourselves to a mostly "semantic" VOTable schema. This approach won't work at all for other forms of tableset metadata, and will not provide a uniform mechanism as for table data queries.
Regarding Tony's comment about VOTable vs XML Schema - we had this same discussion in depth a couple years ago, and are not likely to reach a different conclusion now. The same arguments could also be made against other generic table container mechanism with lots of usful generic tools, for example a RDBMS.
On Thu, 17 May 2007, Francois Ochsenbein wrote:
>
> 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
> ================================================================================
>
Received on 2007-05-17Z15:33:55