Yuji,
Inserting the coordinate frame is no more verbose than inserting a table alias when there is only one table.
My proposal has been to use STC-S in the ADQL-S queries. That has the
advantage that it is a fully defined system, consistent, extensible,
and compliant with other IVOA functions, and that it is convertible to
the STC-X XML serialization.
Within that context the default value for a missing element is always
UNKNOWN. Proper frame identification avoids confusion - which will
happen if you don't require it. The user will almost always assume
that it is his/her favorite frame.
I'd be happy to include simulations in STC-S since they are in STC-X. That will allow more sensible querying of those datasets: only being able to ask for a circle in (X,Y) seems rather restrictive.
And again, how many users do you expect to actually craft ADQL queries? I would imagine that most queries would be constructed by a more user-friendly user interface.
On two other issues:
Units are included in the STC-S definition and actually have defaults,
but should be the same for all related numbers in a query.
For time ISO8601, JD, or MJD are allowed. I would strongly suggest for the ISO case to adopt the same restrictions that are in FITS and in STC: yyyy-mm-ddThh:mm:ss.s..., optionally dropping the 'T' in SQL conversion; no support for time zones or the 'Z' indicator, but instead a timescale specification where needed.
Yuji SHIRASAKI wrote:
> I forgot to send to the voql list.
>
> Forwarded by Yuji SHIRASAKI <yuji.shirasaki-at-nao.ac.jp>
> ----------------------- Original Message -----------------------
> From: Yuji SHIRASAKI <yuji.shirasaki-at-nao.ac.jp>
> To: Arnold Rots <arots-at-head.cfa.harvard.edu>
> Date: Sun, 14 May 2006 09:17:44 -0700
> Subject: Re: slide of my talk
> ----
>
> Dear Arnold,
>
> Thank you your comments,
>
> My suggestion on the coordinate frame is
>
> 1) default coordinate frame should be defined on each service, and
> it should be exposed by metadata interface.
> 2) recommend to use "FK5" or "ICRS"? as a default if there is no
> strong reason to use another frame.
> 3) user need to specify the coordinate frame, if he/she does not
> know which frame is a default for the table in advance
> 4) user does not need to specify the frame, if he/she know
> which frame is a default for the table.
>
> You are saying that to include the frame in a query is a very small
> effort, but it is a little verbose for a user who know which
> frame is a defualt as he/she uses the table very frenquently.
>
> And it is possible to inform at the user interface level which frame
> is a default, so user will no be confused if he/she uses the smart
> user interface.
>
> In case of the simulation data, data might be queried based on the
> cartesian coordinate. The query might be someting like this:
>
> Select *
> From table
> Where Region('CIRCLE 0 0 10')
>
> This is a query searching data on XY plane withradius of 10 (arbitrary
> unit). In this case specifying the frame is almost meaningless.
>
> Yuji Shirasaki
>
> > Yuji,
> >
> > I haven't had time to go through your entire talk, but there is one
> > point that I would like to raise.
> >
> > You are suggesting that the coordinate frame can be omitted under
> > certain consitions.
> > I think that is a bad idea, for the same reasons why you were arguing
> > that a table alias should always be specified: users get confused when
> > it is sometimes needed, sometimes not. And it is a very small effort
> > to just include it to begin with, especially as I suspect most users
> > will not fashion the queries themselves, but through an interface. I
> > have no problems with the interface presenting the user with defaults,
> > but it should include the frame explicitly in the query.
> >
> > The larger picture is that we hope to include more than galactic and
> > extra-galactic astronomers to the VO. In the past week we have had
> > discussions with solar people on coordintes. Invariably, if you allow
> > defaults in queries, people are going to assume that the default is
> > what *they* think is the most "natural" choice. That has the
> > potential for large-scale confusion and it is much better to state
> > from the beginning that a frame needs to be specified.
> >
> > - Arnold
> >
> > Yuji SHIRASAKI wrote:
> > >
> > > Dear VOQLers,
> > >
> > > I have uploaded a slide that will be presented at the
> > > VOQL meeting. Please look at the following URL:
> > >
> > > http://www.ivoa.net/internal/IVOA/InterOpMay2006VOQL/VOQL-YujiShirasaki-ver1.pdf
> > >
> > > It is still under preparation, but I wellcome your comments and/or
> > > questions on the contents, especially from those who cannot attend
> > > the meeting.
> > >
> > > It is worthwhile to start the discussion even before the meeting.
> > >
> > > I also uploaded update versions of ADQL and ADQL-Core schema.
> > >
> > > See you soon.
> > >
> > > Yuji Shirasaki.
> > >
> > --------------------------------------------------------------------------
> > Arnold H. Rots Chandra X-ray Science Center
> > Smithsonian Astrophysical Observatory tel: +1 617 496 7701
> > 60 Garden Street, MS 67 fax: +1 617 495 7356
> > Cambridge, MA 02138 arots-at-head.cfa.harvard.edu
> > USA http://hea-www.harvard.edu/~arots/
> > --------------------------------------------------------------------------
> >
> >
> > __________ NOD32 1.1537 (20060514) Information __________
> >
> > This message was checked by NOD32 antivirus system.
> > http://canon-sol.jp/product/nd
> >
> >
> >
> >
> > __________ NOD32 1.1537 (20060514) Information __________
> >
> > This message was checked by NOD32 antivirus system.
> > http://canon-sol.jp/product/nd
> >
>
> --
> Yuji SHIRASAKI <yuji.shirasaki-at-nao.ac.jp>
>
>
>
>
> __________ NOD32 1.1537 (20060514) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://canon-sol.jp/product/nd
>
>
>
>
> __________ NOD32 1.1537 (20060514) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://canon-sol.jp/product/nd
>
>
> --------------------- Original Message Ends --------------------
>
> --
> Yuji SHIRASAKI <yuji.shirasaki-at-nao.ac.jp>
>
>
Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots-at-head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ --------------------------------------------------------------------------Received on 2006-05-15Z16:27:46