Web Cone Searches

[Andreas Wicenec]

Hi,

I totally agree with Martin's view, even more so because we can see that a lot 
of people are doing some quite advanced science programs using the very 
simple access we are providing to our catalogues and the DSS1 and DSS2. Also 
from the user point of view a simple access is much easier to go along. Of 
course the information returned has to be complete and suited to the science 
case.

On the other hand carrying out scientific reduction using services offered by 
the providers directly is a very convenient and fast way to do at least basic 
things like epoch and equinox calculations or the basic calibration of images 
and spectra.

Cheers,
Andreas

On Monday 22 September 2003 20:29, Martin Hill wrote:
> 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