call for presentations at the Data Model sessions in Cambridge , September 2007

[Doug Tody]

Hi Alberto -

Thanks, that helps a bit.  No one (so far as I know) is arguing that
VOTable is the solution to all problems in VO.  We use it primarily
for representing and interchanging tables, such as the output of a
DAL query or the input or output of a TAP/ADQL table query, which
are classical table-oriented queries.

VO has not done much about representing complex structured data
objects; mostly these are handled on a case-by-case basis.  VOTable is
one supported format for 1-D spectra or time series, but other formats
such as FITS and native XML are also supported, and other types of
objects in VO use a variety of different representations.

When it comes to graphics intensive visualization such as
gSky/WWT/Worldwind etc., this is a completely different problem.
For this you need something like WMS which serves up uniform
multiresolution graphics-oriented (non science) pixel tiles
efficiently, plus a markup language for annotations like KML.  In many
ways this application is more analogous to a graphics-oriented
replacement for the HTML-based browser than it is to modeling
science data or representing the result of table-oriented queries.
In particular such a markup language may produce arbitrary graphics
annotations and program the remote generic visualization tool to
generate requests back to a service, which is getting to be pretty
visual interaction specific functionality.

I would avoid over-general statements about VOTable, KML, STC, or
whatever being the solution to all problems.  All technology has a
limited scope of applicability.

	- Doug


On Tue, 22 Jan 2008, Alberto Conti wrote:

> > > You mention that WWT will speak VOTAble natively, understand SIAPs,
> > > ConeSearches, etc... this is really great. My problem (and it's a personal
> > > opinion) is that VOTable as is, as a transport mechanism is not adequate.
> > > But
> > > my opinion, as many know, is irrelevant!
> > 
> > I don't understand what your point is here Alberto.  Can you expand
> > upon this?  I am sure that KML is much better for some things than
> > is VOTable, but VOTable works very well as a standard data model and
> > transport mechanism for tabular data, a very common case in astronomy,
> > and certainly a good fit for the output of a database query (which
> > is what most VO data queries are).
> > 
> exactly! I should rephrase: I don't believe VOTable will be as efficient as
> something like KML or whatever WWT releases if it's not KML. And KML itself
> could be improved, as all have pointed out.
> 
> VOTable is not easily converted into objects (at least not in my experience
> and that of others), like a dataset in C# is for example and a rowset is in
> Java. It's schema is weak. Its structure is not easy to percolate like a well
> define industry structure. So while it is indeed efficient for tabular data
> (reminiscent of a fits file), it does not seem to be the most efficient for
> extracting data nor as a transport mechanism for non-tabular data like
> metadata.
> This is at least my experience.
> 
> > To take this anti-VOTable argument to an extreme, if we are to do
> > away with standard mechanisms for table abstractions, perhaps we
> > should do away with the relational database while we are at it.
> > It is much the same situation.
> > 
> I disagree. In contrast to what's happening with VOTable, we adopted SQL and
> its table abstraction because it gave us a huge leverage in terms of data
> access, data display, data cross-correlation, not to mention that is was and
> is the standard. ADQL sits on top of SQL.
> 
> VOTable seem to built on top of fits, which is a standard, but not an adequate
> one when for large cross-indexed metadata, which is what we are talking about.
> KML's vocabulary, for example, while limited for astronomy, contains
> constructs that are readily usable in its (well documented) schema. On top of
> this a large community is using it, something that I think we cannot ignore.
> 
> Perhaps the answer is some subset of STC, I don't know. I know that now that
> GoogleSky and WWT are a reality we are confronted on how to serve data to
> these new visualization tools. KML is a possible solution, not the only one.
> WWT will clearly require perhaps yet another adjustment, but if they too will
> adopt KML then I believe we might be able to build on top of both to push the
> KML standard in the direction we require.
> 
> Ciao,
> Alberto