Re: Latest ADQL Document and roadmap for Proposed Recommendation

Pedro,

As I have expressed before, I am rather bothered by the way Regions are handled. Defining separate functions for each and every possible situation, as is done in the draft, is extremely cumbersome and a major obstacle to extensibility.

The value of the STC-S serialization is that all specificity is encoded in the string and that allows one to design the functions to be fully general. What is being proposed for ADQL takes no advantage of STC whatsoever and basically develops its own definitions of regions and coordinates. To me, that seesm like the wrong way to go about things. Why do we need a coordinate metadata standard if each subsequent standard invents its own?

And what has been invented for ADQL is not adequate. As I said, one would need to define new functions for new shapes and the like. But actually, it is worse: what if I were to define a circle in Cartesian coordinates? I would need to define a new 'cartcircle' that uses a new concept of 'cart2coordinates' consisting of an x and a y, because the existing 'circle' and 'coordinates' are tied to spherical systems.

My proposal would be to define an STC-S kernel of functions that are fully general and extensible. Two basic ones would be:

boolean STC_S_contains (<STC-S Region expression>, <STC-S Position expression>)

  returns true if the region specified in the first STC-S expression   contains the position specified in the second expression

string STC_S_position (<parameter>, <parameter>, ...)

  evaluates an STC-S position expression from its parameters; the   server clearly would have to know how to interpret its coordinates,   but that is required in any system, even your draft

So that one could write a query like:

select ra, dec from mytable
  where STC_S_contains ("Circle ICRS 123.0 45.6 0.7",

                        STC_S_position (ra, dec))

Here

    STC_S_position (ra, dec)
  evaluates to:
    "Position ICRS <ra value> <dec value>"   or:
    "Position FK4 <ra value> <dec value>" (depending on what the server knows its contents' coordinate system to be)

One could define a much more general evaluation function, but I think this will suffice.
What this does for ADQL is that the whole Region concept does not need to enter the language. Instead, we have defined some simple functions of known types (boolean, string) that completely internalize all STC concepts, yet remain fully general and extensible.

Cheers,

• Arnold

Pedro Osuna wrote:
> Dear all,
>
> please find attached the latest ADQL Document version produced by the
> VOQL-TEG.
>
> I would like to start the formal RFC period in around 3-4 weeks from
> now, so should you have any comments by now, please let us know as
> soon as possible.
>
> The formal RFC spans for another 4 weeks, so if everything goes well
> we would be able to have the ADQL Document as a Proposed
> Recommendation just by the next interop meeting at Trieste.
>
> I would like to thank thoroughly the VOQL-TEG group for their effort
> in this specification, but very specially Pat Dowler, Jeff Lusted,
> Alex Szalay and Inaki Ortiz for the very tough work during the latest
> steps in concluding the ADQL Doc.
>
> Should you have any comments, please don't hesitate to send them.
>
> Thanks.
>
> Cheers,
> P.
>
>
>
> ================================================================================================
> This message and any attachments are intended for the use of the addressee or addressees only. The
> unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
> is prohibited. If you received this message in error, please delete it from your system and notify
> the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
> for any e-mail if modified.
> =================================================================================================
>

[ application/pdf is not supported, skipping... ]

>
>
>
> _________________________________________
> Pedro Osuna Alcalaya
>
> European Space Agency (ESA)
> European Space Astronomy Centre (ESAC)
> Science Operations Department (SCI-O)
> Science Archives and Computer Support Engineering Unit (SCI-OE)
> e-mail: Pedro.Osuna-at-esa.int
> Tel + 34 91 813 13 14 Fax: +34 91 813 11 72
> _________________________________________
> European Space Astronomy Centre (ESAC)
> P.O. Box 78
> E-28691 Villanueva de la Cañada
> MADRID - SPAIN
>
>
>
>

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