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

[Alberto Conti]

> When it comes to graphics intensive visualization such as
> gSky/WWT/Worldwind etc., this is a completely different problem.
now it is, I believe the two approaches: data and intensive viz will  
converge.

> 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.
Or perhaps a WMS that is for (science) pixels as well. Why not think  
about this?

> I would avoid over-general statements about VOTable, KML, STC, or
> whatever being the solution to all problems.
nah, over-general statements are what I do best! :P

> All technology has a
> limited scope of applicability.
and so do we, I keep telling myself...
-A


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

Dr Alberto Conti
Community Missions Office
Space Telescope Science Institute
contact | tel: 410-338-4534 | aim: wscience