Units needed in ADQL-0.7

[Thomas McGlynn]

Tony Linde wrote:

>>   query/local units for querier ->
>>        query/standard units ->
>>           query/local units for database
>>   response/local units for database ->
>>         response/standard units ->
>>            response/local units for querier   
> 
> 
> The registry entry for a data source (or rather for the service that fronts
> that source) will include the columns in that dataset and should include the
> units used for each column.
> 
> When a user is sitting in front of a portal or query constructor and has
> targeted a data source, he/she can use the units of that source or some
> preferred units. The translation can then happen before the query is sent
> off to the data source so we don't need to worry about how the units are
> represented in the query.
> 
> If the user wants to broadcast a query to a number of sources, they can use
> their preferred units and the portal or workflow engine can then translate
> each query into the appropriate units for each source. 
> 
> Thus we don't need to force every data centre to install conversion software
> and keep it up to date. This is only required by anyone constructing a
> portal, query constructor, workflow engine etc. - a much smaller number of
> sites and all with an interest in getting it right at the beginning of the
> VO revolution.
> 
> Cheers,


Not entirely sure whether you were disagreeing or agreeing...

However, as I read the discussion, Clive was thinking
that any unit conversion would occur at the database,
while you are suggesting that the full unit conversion occur at the query
originator site.  In both these scenarios the implication is that the software
at some local site is capable of converting units to any other (valid) units.
In my scenario, each site is responsible only for the translation between
their own local units and the standard set.  It also means that the people
who know the peculiarities of their units are responsible for taking care of
those issues, not someone at another site which is what either Clive or your
suggestion would require.

Here's a contrived but not inconceivable example...
Suppose our system stores fluxes in linear units in a certain range
of fluxes and logarithmic units for larger values.  If our system happens
to be portal site, then Clive would seem to require remote databases to know
about this when we send them queries.  If our system happens to be a database,
the Tony requires the portals to know about our peculiar system of units.
Clearly it's much nicer if we alone need to handle this special case and don't
burden other users.

Another advantage to putting standard units on the wire is touched on in
Tony's paper.  Since the query is standardized it's easy to send it to multiple
sites.  Tony's proposal requires us to explicitly customize the query to each site.
There are a lot of ancillary advantages to a nominal form.  It's easy to store
the query and re-issue it against new services that might be discovered later
since the query syntax is not tied to its initial place of origin.  It's much easier
to discover if the query is the same as some other query for which results
have been cached.  It suggests to builders of new database systems and portals
a framework to use for units. ...

I don't think Tony's suggestion that the user reads the registry and then
adjusts the query is appropriate.  I'm certainly not competent to translate from
janskies to magnitudes per square arcsecond.  I guess a user could
select databases that have familiar units, but this scenario of the user
picking out resources individually isn't the real issue -- we can always
punt to an interactive user.  The hard problem is the one where we are trying
to do things automagically on the user's behalf.

If it is possible to put standardized units on the wire I think it would be
an enormous win.  However while I am not as pessimistic as Clive regarding
its feasiblity, it may not be possible.  If not then
I don't really know whether it's better for the translations
to be the responsibility of the portal/user site or the database.  I'm not sure
which we will have more of...

	Tom