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 Received on 2006-09-21Z17:38:39