your mail
Guy Rixon
gtr at ast.cam.ac.uk
Tue Sep 23 03:50:12 PDT 2003
On Mon, 22 Sep 2003, Tim Naylor wrote:
> > Okay, I'd like to bring up my current pet peeve about the NVO cone search
> > standard (ie http://www.us-vo.org/metadata/conesearch/), which is that it
> > doesn't include either equinox or epoch.
>
> Let me add my take (as an astrophysicist) on this.
>
> 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).
What should a DB without proper motions do? Reject the query? Do a
best-efforts approximation of the results?
> 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?
This is maybe getting a bit off-topic. Do we, the services group, want to
specify cone-search-as-a-web-service, or is that the job of another IVOA
group, such as DAL?
I _would_ like to explore the general principle of what to do when a resource
can't answer a query exactly as phrased. Is it acceptable to return an
approximate answer (e.g. assume zero proper motion if no proper motions are
known)? If so, how would we inform the "user" of the approximation, and how
might the user limit the approximations made in the processing?
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
More information about the grid
mailing list