call for presentations at the Data Model sessions in Cambridge , September 2007
aconti at stsci.edu
Tue Jan 22 14:35:09 PST 2008
>> You mention that WWT will speak VOTAble natively, understand SIAPs,
>> ConeSearches, etc... this is really great. My problem (and it's a
>> 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.
More information about the dal