call for presentations at the Data Model sessions in Cambridge , September 2007
dtody at nrao.edu
Tue Jan 22 15:04:32 PST 2008
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.
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
> 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.
More information about the dal