Web Cone Searches

[Martin Hill]

Hmmm, I would have thought that the decision on whether to use a cone search 
or an ADQL search (assuming the query is simple enough to use either) would 
be made at the workflow stage, probably based on performance.

Again, I think that if you want to do more than the simple cone search, you 
use an ADQL service, rather than get everyone to extend the cone search - is 
that what you meant?

What advantages do we get from "Cone Search 2: The Web Search" over the CGI 
one?  I would have thought the CGI one is easier for most people to implement 
and simple to call.  If a client wants to go to the effort of using web 
services, they could use the full ADQL one?  Or do people think it would be 
useful to offer a service call that auto-generated the ADQL for a conesearch, 
for a simple interface?

On Tuesday 23 September 2003 10:31 am, Guy Rixon wrote:
> OK...I think there's a general principle up for debate here.
>
> If job X, which has many variations and parameters in its general form, can
> be done either by a general ADQL service, or by a specialized, simpler
> service on the same data, is it required that the specialized service cover
> the general form of X, or can the general form be deferred to the ADQL
> service.
>
> In this case, if I want cone search for B1950 positions, with known epochs
> and PMs, must the cone-search service support this, or must I go to the
> ADQL service?
>
> (In this case, I'm considering the cone-search service to be "Cone Search
> 2: the Web Service", not a revision to the CGI-based services.)
>
> On Tue, 23 Sep 2003, Andreas Wicenec wrote:
> > 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
>
> Guy Rixon 				        gtr at ast.cam.ac.uk
> Institute of Astronomy   	                Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523

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