Hi Keith -
The "uniform query mechanism" proposal is basically just as you suggest; the only question is whether we make VOResource-format output support mandatory. Once the information content for a metadata query is settled, supporting another output format is pretty trivial, so I would have no problem with making VOResource format support mandatory if enough folks feel this is important. VOTable should be the default for a uniform query mechanism used for both types of data.
On Thu, 17 May 2007, Keith Noddle wrote:
> Hi Doug,
>
> > I could probably agree with all of your points except for the following:
> I'm really keen that we use what we have wherever possible. However, I also
> recognise the need to make everyone's lives as easy as possible - that way
> lies adoption of the VO! I am further convinced that consistent access to
> resource metadata - wherever and whatever their type - is vital and will
> become more so as time passes. How about this as a compromise:
>
> 1. TAP mandates that services return their metadata in VOResource format using
> the mechanisms defined in the VOSI
> 2. TAP mandates that the service ALSO returns those metadata in VOTable format
> in response to a metadata query
>
> Given the formats will be so similar, the burden on the service developer will
> be reasonably light - hopefully a simple XSLT translation will do the trick. I
> know we tend to try to avoid mandating too much, but in this case, I think
> there is justification.
>
>
> >
> > On Thu, 17 May 2007, Keith Noddle wrote:
> >
> > > > (5) Tables and table metadata are both tables, and the IVOA has adopted
> > > > a
> > > > standard representation for tables, it is called VOTable. I believe
> > > > VOTable
> > > > should be the principle way that relational schema and the table data
> > > > should
> > > > be returned from TAP, although other formats may be offered by
> > > > implementers.
> > > > Because tables and table metadata are unified, it means that querying
> > > > the
> > > > table metadata is no different from querying table data itself.
> > > How ever the metadata are returned, the results will have to have some
> > > format.
> > > VOTable is XML as is VOResource and the VODataService extension. Given the
> > > returned VOTable will contain exactly the same information as defined by
> > > VODataService, why are we suggesting that IVOA defines yet another format
> > > (schema) to apply to the returned VOTable? VOTable is designed to return
> > > data;
> > > I am not convinced it is optimised to return medatata. Let's use what we
> > > have.
> >
> > The client application already has to support VOTable as the
> > default output format for table data queries. If native XML
> > (VOResource/VODataService) is the only format for table metadata (which
> > appears to be the suggestion here) then a client has to be prepared
> > to accept two completely different delivery formats for table data
> > and metadata, despite the fact that both are fundamentally the same,
> > i.e., tabular in nature. I think this is an unnecessary complication
> > and would break the elegant relational approach, with a uniform
> > interface for both table data and metadata, already demonstrated by
> > the SQL information_schema. Since TAP is mainly about ADQL/SQL and
> > relational queries, this would be a serious step to take.
> >
> > - Doug
> >
>
>
>
> Keith.
>
> --
> Keith Noddle Phone: +44 (0)116 223 1894
> AstroGrid Project manager Fax: +44 (0)116 252 3311
> Dept of Physics & Astronomy Mobile: +44 (0)7721 926 461
> University of Leicester Email: ktn-at-star.le.ac.uk
> Leicester, UK LE1 7RH Web: http://www.astrogrid.org
>
Received on 2007-05-17Z05:36:22