WD for the Obscoredata model and its implementation on TAP

[Douglas Tody]

On Tue, 21 Dec 2010, Anita M. S. Richards wrote:

>
>> Arnold - All of this is (except possibly adequate treatment of
>> redshift) is already in the full model.  But ObsCore is a simplified
>> subset intended only for data discovery.  Agreed something like
>> reference position is needed for analysis, but that level of precision
>> is not likely to be needed for data discovery.
>> 
>> Fixing the units is essential for discovery, at least if we plan to
>> use TAP-ADQL expressions globally.  The primary requirement is that
>
> Why? Conversions are easy and don't even need trig !

Because 1) TAP-ADQL (SQL) is limited to simple arithmetic expressions
for constraints on random table fields, and 2) we want to be able
to send the same query to multiple ObsTAP services to do global data
discovery.  So we will have something like (em_min < X AND X < em_max)
to determine if X is within the spectral coverage of the dataset.
Requirement 2) prevents us from doing unit conversion on the client
side.

If instead PQL is used then we can support some simple frame/unit
conversions directly in the service.  This would allow us to query a
broader range of tables, not just ObsTAP tables (e.g. general catalogs
or index tables).  But for ObsTAP we still need to fix the units to
support ADQL queries.

On the other hand, if we give the user a nice application to do the
discovery queries and display the query results then we can do the
unit/frame conversions in the client application and make things just
as the user wants.  In that case keeping the protocol simple, e.g.,
by fixing units, makes the software simpler and more reliable.

(All a very old VO story of course...)

 	- Doug


> all the best
> a