Comments on UCD draft

Dear Sebastien,

here are my comments to the UCD document. I must say that I fully agree with Bob Hanish's comments. Alberto's and Andrea's points are also quite valid. The evolution of UCDs seems to me is going in the right direction, so my comments are more in the line of nitpicking in hope of improving the system (just as in the old days when we started with the UCDs and used them to do some quality control :-)

I will concentrate my comments on the study of the two documents you provided: "ucd1-ucd1p.txt", "ucd1p-composed.txt", which are the closest to real data we have. I've always had in mind using UCDs to tell us what quantities of different origins could be compared when taken out of context in a relatively safe fashion. The original work on UCDs payed special attention to group quantities with equivalent units (not always a success or a trivial thing to do though).

First, the obvious:

phys.extension;stat.error seems to be mistaken, not sure about meta.code;stat.error

on the same line, we're missing most of the error columns with their corresponding ucds.

stat.stdev seems at first to be at the same level as stat.max, stat.min, stat.mean. The latter are always used as a qualifyer (a word after a semicolon), yet stat.stdev is used the other way, having said that, stat.stdev and stat.error are not too different though.

stat.min, stat.max:

	are used in many observables, which is fine, but also in other
	quantities in which the meaning of minimum and maximum is not
	given by the sampled elements but by observational limits,
	eg, maximum and minimum of an observational window (bandpass)
	or limiting magnitude/flux

src.fwhm and extensions
	Sooner or later we'll need to recognize quantities which relate
	to source extensions (or instrument coverage) in order to compute
	overlaps (eg, if a galaxy is located within the FOV of a plate).

	We require to know the geometry (or infer it) [rectangular,
	elliptic, polygonal). The quantities introduced in UCD1 for this
	purpose are lost in UCD1+. I believe this to be an
	oversimplification which we may regret later on.

velocities

	src.veloc.compon UCD is a real mixture between any possible
	velocity component: cartesian, expressed in km/s (or equivalent)
	and polar (radial and tangential) Perhaps we shold think of adding
	some qualifiers for coordinates system, eg:
		coord.cart.X
		coord.cart.Y
		coord.cart.Z
		coord.polar.rad
		coord.polar.tang etc!

	The following could apply:
	VELOC_GAL_U -> src.veloc.compon ==> src.veloc.gc;coord.cart.X
	VELOC_TANG_GAL -> src.veloc.compon ==> src.veloc.gc;coord.polar.tang

	VELOC_RELAT -> src.veloc.component looks more like
		src.veloc;arith.diff (but in some cases it is :-)

Gradients:

	I'd argue that gradients are physical properties rather than
	arithmetical, then phys.grad rather than arith.grad.

Surface brightness.

        I'd argue that we should have phot.sb rather than phot.mag.sb

UCDs and units:

        I think we're mixing things here:

	pos.eq.dec.arcsec
	pos.eq.ra.minutes
	pos.eq.ra.seconds

	If they represent dec and ra in different units, it's not up to the
	UCDs to resolve them. At best it looks confusing

Wavelengths:

	em.wl
	em.wl.central
	em.wl.effective

	seems to me that "central" and "effective" are qualifiers, as the
	nature of the main quantity does not change. I think it would look
	better as

	em.wl;qual.central
	em.wl;qual.effective

	a similar situation happens with the effective temperature

Photometry

	although I agree that having broad categories help locating a
	number of quantities, the lack of granularity means that we're
	no longer able to search for specific things.

	Say that I really want to locate magnitudes measured with
	PHOT_HST_F622W. In UCD1, only these quantities would be recovered.
	in UCD1+, I would have to ask for phot.mag;em.opt.R, and get 20
	other quantities (involving an undetermined number of tables).
	Fishing for data in registries will be so fuzzy that will in
	practice render the system ineffective. In a google era, users
	would expect a low overhead rate; we are diverting from that trend.

	Despite going against the stream, I propose that we keep the
	granularity in photometric systems, define the proper qualifiers,
	and even allow individual frequencies/wavelenghts (as I've heard
	Pedro proposing). What we can do is to produce a way of linking a
	group of UCDs to a single one in order to simplify broad searches.

	So, if I look for phot.mag;em.opt.R, it should actually match to
		phot.mag;band.jhn.r
		phot.mag;band.gunn.r
		phot.mag;band.hst.f622w
		etc.

OK, I'll stop here. Attached you'll find a summary of the matches from UCD1 <--> UCD1+ which I found quite useful and have used to present this analysis.

I'm fully aware of how difficult it is to work with the raw data, and UCDs are an excellent way to use the registries to their full extent, hence my pickiness on some issues.

The next thing we should be thinking is how to estimulate people to accept queries using only UCDs rather than column names, that propmts my concern about loosing granularity.

Cheers,

Patricio

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





APPLICATION/x-gzip attachment: ucd1-1_summary.gz