Web Cone Searches

[Guy Rixon]

On Tue, 30 Sep 2003, Martin Hill wrote:

> 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?

Advantage 1: client gets to work in epoch and equinox of choice, not in the
default epoch and equinox of the cone-search standard (where we came in...)

Advantage 2: given good tooling, it's _easier_ to build a client for a web
service than for a CGI.

> 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
>

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