Web Cone Searches

[Martin Hill]

The cone search is a really simple search, put together so that database 
owners can publish their data as straightforwardly as possible as a web 
service.  Other more comprehensive searches, such as those based on ADQL and 
so on, will cover everything anyone can possibly ask about anything.  Or 
about 80% of it anyway.

So what is the minimum set of things we need to handle to make the results 
accurate and usable?

> 1) Epoch.  If you change the epoch of a cone search the answer should
> change, that's because some high proper motion objects will move through
> the cone with time.  So, a database with proper motions should accept and
> use an epoch.  A database without proper motions should return what epoch
> the data refer to.  Without this, cetrain science programmes will be
> impossible (e.g. proper motion studies).

The 'answer' here sounds like the querier wants the results to be given in 
the 'now' epoch.  Whereas in both cases (db with and without proper motions) 
the publisher should provide the epochs for each object, and proper motions 
if they're available, and we get accurate and usable results... Presumably if 
proper motions are not available the publisher cannot re-epoch the results 
anyway?  And proper motion studies would not be possible anyway? And if those 
*with* proper motions return them, then the science can be done at the client.

> 2) Equinox really should be dealt with, and dealt with properly.  Its all
> very well to say "everything in the VO will be equinox 2000", but it seems
> to me to be building in a serious limitation at an early stage.  Folks
> should be making the data available in what ever equinox is needed, and
> then it should be converted (on the fly?) to what the user wants.  If not,
> how are we going to cope if there is another change such as that from
> Besselian to Julian equinoxes?

I can't see that using a particular one is a *limitation*, given the 
conversion can be made anywhere - no information is hidden or distorted 
because the query is in J2000, even if many years down the line a new origin 
is introduced.  So should we say at the moment that the *results* are 
presented in whatever equinox they are stored in (and some metadata page 
describes this) to simplify the publishing process.  And many years from now, 
if a new one is introduced and the cone search still exists, we can add that 
to the cone search if it still exists, leaving it's absence as defaulting to 
J2000.

In summary, the cone search is a great 'starter' web service for people 
learning to publish data.  I feel we should (if I haven't misunderstood and 
it does limit queries) keep it as simple as possible, and devote our efforts 
to the richer, more complex web interfaces for full services.

(We can always build services 'in front of' services - so we could provide a 
standard front end cone search that takes any epoch/equinox, converts the 
query to the right values for a basic cone search, and converts the results 
to the given epoch/equinox before returning them.  This gives us a layered 
approach, but is it worth it?)

Cheers,

Martin




-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66