VOTable session @ Interop.Moscow

[Rob Seaman]

On Thu, 21 Sep 2006, Bob Mann wrote:

>>> An astronomer wants to cross-match sources in catalogue  A with  
>>> objects in catalogue B using an algorithm which cannot be  
>>> executed inside either database or as part of an ADQL query. She  
>>> runs a conesearch (or equivalent) on each database, to extract  
>>> the entries from each lying in the area of sky in which she is  
>>> interested, and obtains two VOTables, votA and votB. She passes  
>>> these both to her cross-matching service, which returns a VOTable  
>>> recording pairs of entries in votA and votB which her algorithms  
>>> judges to be safe matches.

On Sep 21, 2006, at 7:14 AM, Mark Taylor wrote:

>> your use case is certainly a reasonable one, but I'd say the way  
>> to tackle it is simply to insert an identifier column in each  
>> table, containing the same tag as you would have put in the TR ID  
>> attribute.

On Sep 21, 2006, at 7:49 AM, Roy Williams wrote:

> They said over and over that the VO is too complicated and too much  
> jargon and not enough astronomy.

I suspect that this will turn out to be one of the most frequent VO  
use cases.  It has certainly recurred over-and-over in the past with  
each new sky survey.  A typical survey opens up new vistas of phase  
space.  For this new territory to be useful, it must be marked with  
IDs corresponding to previous catalogs resulting from previous  
surveys.  The cross-matching can be as valuable as the new  
observations.  The key point is that the cross-matching should be  
done with astronomically meaningful IDs, not just indices into  
databases.  For just one reason, because VO users will continue to  
use non-VO tools – including perhaps, gasp!, the published literature  
– that will have astronomical IDs.

Rob