Physical Units in Queries

1. Physical Units in Queries Clive Page

2. 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: Clive Page

3. Clive Page

4. 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. Clive Page

5. 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. Clive Page

6. 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. Clive Page

7. 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. Clive Page

8. 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. Clive Page

9. 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.) Clive Page

10. 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? Clive Page

11. 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. Clive Page