Version 1.9.9 of UCD definition

[Patricio F. Ortiz]

Hi,

I'm glad we are going into this discussion, not because it's an easy
subject, but because it is a relevant one. The EMS is perhaps the most
important 'tree' which we want to describe properly.

I see several different regimes:
a) broad band observations (eg, Johnson's V, radio bands, X-ray bands)
b) narrow bands
c) line spectroscopy (H-alpha, 21cm, CO, OIII, etc)
d) continuum spectroscopy (eg, from blue to red)
e) flux ratios

The question of how to describe these quantities is strongly linked to what
we want to use with the descriptors.

It is different what we assign to the column (the UCD) and the type of
search we intend to perform.

If our goal is to find all radio fluxes, then we could cut the UCD in
phot.flux.radio at the level of search, so even if we have infinite
granularity (eg, phot.flux.radio.22Ghz), this column will be recognized.

If on the other hand we are interested in finding observations in 22GHz,
having an assigned UCD phot.flux.radio assures us to find the 22GHz data
(eventually), but the S/N will be quite low, having to browse through
hundreds of catalogues to find 1 is not desirable, and it's not what we
had in mind when UCDs were introduced. Specifity also means that one can
discover quantities which are comparable, that one will not mix a line
measurement with a continuum one (despite being very close in frequency).

What I think is important to decide now is if up to what extent the UCDs
can do the job, without complicating them too much or oversimplifying them
to the point of becoming useless for discovery purposes. One thing I
wouldn't like to see is to see UCDs become as ambiguous as column
descriptions.

It is quite possible that we should resource to another element of
meta-information for the description of a quantity and for its discovery.

I thought that 'utype' could be used to link observational windows with
their description (data model?). eg,
UCD="phot.mag.opt" utype="strongrem.B" or
UCD="phot.flux.radio" utype="JBO.22Ghz" or
UCD="phot.flux.radio" utype="VLA.6cm"

For accurate matching, one would have to use both pieces of information to
avoid mixing apples with oranges.

The method that Anita and Clive mention (a fine piano-keyboard mask) is
something I've considered as well. It is broader than the UCD, but requires
accurate knowledge of each band observation window (I'm not saying it's not
doable). Users could then specify which part of the spectrum they are
interested in and they will find the tables which contain data in those
parts of the EMS. This works quite well for broad bands, but it is not so
great if one is interested in narrow bands. Imagine one searches data
around HBeta. Most catalogues with "blue broad band" observations will
have 1's in that area of the spectrum, therefore, the noise will be huge!
The same is valid for lines in other areas of the spectruma. (that's why I
didn't pursue this model farther).
Same is valid for colour indices: looking for V-K in terms of its initial
and final wavelength will bring a large number of undesired catalogues/columns.


One solution I've proposed is to stick to a very fine granularity at the
UCD level which will allow us to compare alike quantities, but to create
"virtual containers" in as many orthogonal directions as needed to solve
the EM problem, as boundaries will continue shifting and being taste
dependent.

Imagine for a second that we keep the fine granularity, having UCDs like

phot.jhn.B, phot.jhn.V, phot.jhn.R, phot.jhn.I,
phot.str.B, ....
phot.sloan.b (if exists)

The original UCD structure allowed users to retrieve any catalogue with
Johnson's photometry (just search for /phot.jhn/ and voila), but there was
no room to look for "catalogues with blue broad-band observations"

A "virtual container" for this example could be phot.opt.blue.bb. No column
will ever be assigned this VC-UCD, but a search engine will understand it
as "hmm, phot.opt.blue.bb is not a UCD, I need to look for catalogues which
contain any of the UCDs listed in its index". To follow the example,

phot.opt.blue.bb := ("phot.jhn.B", "phot.str.B", "phot.sloan.b");

And if later, GAIA introduces its own blue filter, phot.gaia.B will be
created as a UCD, and "phot.gaia.B" will become part of this list:

phot.opt.blue.bb := ("phot.jhn.B", "phot.str.B", "phot.sloan.b", "phot.gaia.b");

Finally, alhough a column should have one and only one UCD, nothing
should prevent that a UCD could belong to several virtual containers.
UCDs would describe what quantities are, VCs are used to describe contexts
or related concepts accepted by the community at any time, and quite
possibly user-definable in the future.

Food for thought... after all, > 50% of the current and future quantities
are related to the EMS!

Cheers,

Patricio

---
Patricio F. Ortiz			pfo at star.le.ac.uk
AstroGrid project
Department of Physics and Astronomy
University of Leicester			Tel: +44 (0)116 252 2015
LE1 7RH, UK