>> 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
Received on 2008-01-22Z23:35:25