1. 2003 May 24Clive Page Physical Units in Queries

2. 2003 May 24Clive Page Where units are needed Consider simple query like this: SELECT * from t1, t2 WHERE REGION(whatever) AND properMotion > 100 ; What does the 100 mean? Vizier collection has 231 tables containing proper motions:

3. 2003 May 24Clive Page 0.01s/yr3 10-2arcsec/yr1 10-4arcsec/yr1 10-5s/yr6 10-6s/yr2 10mas/a2 10mas/yr4 10ms/yr3 arcsec/a6 arcsec/yr26 cs/yr2 mas/a10 mas/yr103 ms/a2 ms/yr11 s/a11 s/ha17 s/yr20 Us/yr1

4. 2003 May 24Clive Page Units – Vizier example Vizier collection has 231 tables containing proper motions: These have 19 different units for it. IAU recommends using SI units where possible (with a few extensions for astronomy) SI unit of angular velocity is radians/second None of the 231 tables uses radians/second.

5. 2003 May 24Clive Page Importance of supporting units The cone-search works only because the REGION keyword has the units of its parameters specified (degrees). Almost all other selections involving numerical quantities will be meaningless (or at the very least error-prone) without units information.

6. 2003 May 24Clive Page Possible solution (1) Give astronomer information on units in each column OK for simple queries on one table Will not work in general for multi-table queries, as different tables will use different units. Would have to rely astronomers checking all necessary metadata before submitting a query.

7. 2003 May 24Clive Page Possible solution (2) Use standard units in all interfaces Data access layer of DBMS has to do the conversion to/from units used in each column. Problems: –Will be hard to get agreement on standard units for hundreds of quantities –Different branches of astronomy have different conventions, e.g. flux in mJy, μJy. –SI units are approved by IAU, but rarely used –SI units with large scaling factors make browsing harder, errors much more likely.

8. 2003 May 24Clive Page Possible solution (3) Allow users to specify units in queries Example SELECT … WHERE properMotion > 100 [mas/yr] Notation: –Suggest CDS notation, based on earlier work at GSFC which is compact, flexible, unambiguous, easy to read. http://vizier.u-strasbg.fr/doc/catstd.htx –Would be nice to avoid the brackets, e.g. 100mas/yr but this will be hard to parse unambiguously. Problem: how does the VO system know what units are attributed to each column? –Answer: metadata queries.

9. 2003 May 24Clive Page Requirements on system for unit-handling Need to find the units of each column: a metadata query. Need to parse the units strings in a query and apply the appropriate conversion functions. A few complications: –Do magnitudes have units, or as the logarithm of a ratio are they unit-less? –Functions in queries need special treatment, e.g. COS returns a unit-less value, ACOS always returns radians. –Some conversions cannot be exact, e.g. magnitudes to flux densities in Janskys. (Suggest: leave until later.)

10. 2003 May 24Clive Page Metadata Queries VO opinion seems divided on whether metadata queries should be satisfied by the DBMS (via DAL?) or by the Registry. We need to invent an interface which can be implemented either way. One can regard the registry as a kind of cache of metadata. Absolutely minimal function: –What is the units string of column C of table T of database D at site S?

11. 2003 May 24Clive Page Metadata query – desirable functionality Ask which databases are available at site S Ask which tables are in database D Ask which columns are in table T Ask for properties of a table: length, width, indexes available, astronomical metadata (epoch, equinox,...), curational metadata (version, author,...) Ask for properties of a column: name, data-type, units, nullability, UCD, short description, data range,... Provided these functions are supported, it does not matter whether the information comes from the DBMS or from the Registry.