Units needed in ADQL-0.7

[Martin Hill]

Jim Gray wrote:

>  The registry will not know everything (as you postulate) about
> everyone, it will only know what it is told. 
>  Every column of every table in the registry does indeed carry a ucd
> that gives its units (among other things).
>  The UCD model gives conversions among units (where conversion is
> possible).

Unfortunately the UCDs don't actually give us units.  For example, the UCD 
POS_RA_MAIN can have associated values in degrees (and they can be in dd mm ss.s 
or decimal) or radians.  And one of the big arguments surrounding UCDs at the 
moment is that even when combined with units, this may not be enough for 
converting between magnitudes & fluxes.

> 
>  I assume most archives will have their own "portal" that gives direct
> access to the archive's data in the form it thinks best.
> So, there is no "exclusivity" of portals, that would not be workable. 
> Archives can do whatever they want, but if they want to talk to the
> Portal we are implementing then they have to follow our rules.

We are hoping to do this the other way around - if we give our archives common 
interfaces, then many different portals can access them all.  I don't envisage 
any datacenters talking to portals... or?

> 
>  Queries involving data from multiple sources are teased apart by the
> portal and just the relevant parts are sent to each archive.

I see the portal as just being the UI, and there will be many services behind it 
that will handle the grid-side workflows and assignments, and this might be the 
place to do the appropriate translations.   But maybe this is what you call the 
portal?

>  SkQuery does not send the same query to every archive.
>  We want it to be EASY to implement an archive and put most of the
> burden on the portal since they must deal with heterogeneity (and hence
> there are fewer of them).

Yes - datacenters should be easy to implement as these are going to be different 
every instance.  Whereas the layers that use the datacenters are likely to be 
lots of instances of the same (or very few) applications, so we can build the 
conversions into that once.  But - is it really possible to build generic unit 
converters in the astronomical world?

Martin

--
Martin Hill
www.astrogrid.org

> 
> Jim 
> 
> Jim Gray
> Microsoft Research,  Suite 1690, SF CA 94105,
> tel: 415 778 8222 fax: 425 706 7329
> Gray at Microsoft.com   http://research.Microsoft.com/~gray
> 
> -----Original Message-----
> From: owner-voql at eso.org [mailto:owner-voql at eso.org] On Behalf Of Clive
> Page
> Sent: Friday, January 16, 2004 3:43 AM
> To: voql at ivoa.net
> Subject: Re: Units needed in ADQL-0.7
> 
> I think that what Tony is saying is that the AstroGrid model of how the
> VO works is like this (if I've got this wrong no doubt he will correct
> me):
> 
> Every query from an astronomer using the VO has to go via a Portal and
> (though the astronomer need not know this) a Registry: direct access to
> data centers is not allowed, except wholly outside the VO.  The user
> accesses a Portal to compose a query and does so using agreed standards
> for units: say degrees for all celestial coordinates, or
> milliarcseconds/year for proper motions, or Janskys for fluxes, or
> whatever we come up with; no doubt a good portal will support
> sexagesimals for RA/DEC.  The Portal then fans this query out to one or
> more data centres and in each case does the appropriate translation, but
> not of the syntax only the units, since we have agreed to use ADQL.  Of
> course if a Portal allows a power user to enter an SQL-like string
> query, this does have its syntax translated to the ADQL equivalent,
> along with the units conversions, but the current thinking in AstroGrid
> seems to be that queries will all be generated using drop-down lists and
> similar, in which the user can be notified of the column names allowed,
> and the units to be used in expressions.
> 
> This translation is possible because the Registry is omniscient: it
> knows the units of every column in every table in every database of
> every data center in the VO world, it can therefore translate every
> numerical constant in every query to the units actually appropriate for
> each column.
> Since ADQL is only used for these translated queries, units are not
> needed in ADQL, provided we have agreed standards for them.
> 
> The query parser obviously has to be quite good to work out, for each
> numerical constant, which column it is being applied to, and therefore
> the appropriate units conversion, but since we are translating SQL to
> XML form anyway, this may not be too difficult.
> 
> The other aspect of the design is that it should be possible to send a
> query to more than one destination using UCDs rather than column names.
> The translation again being done by the Registry, upon request by the
> Portal.  This requires us to define a standard set of units for each
> UCD, as at present UCDs and units have been carefully decoupled.
> 
> 
> The alternative model, of course, is that the same query is sent to each
> data center, and translated to specific JDBC/SQL locally, when both the
> syntax and the units are converted.  This does require either standard
> units in each ADQL query, or a notation for specifying them.
> 
> 
> --
> Clive Page
> Dept of Physics & Astronomy,
> University of Leicester,    Tel +44 116 252 3551
> Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311
> 
> 
> 
> 

-- 
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org