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

[Alberto Conti]

>> 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