Francois wrote:
> This question of accurate/inaccurate description was discussed
> many times --- and one of the results was the definition of 2
> different entities :
> -- the UCDs which have the role of broad classification
> -- the "utype" was introduced to fulfil the role of the accurate
> description -- the "utype" being in principle connected to a
> data model which gives the necessary level of detail.
My own thoughts on the relation between UCD and utype/DM have evolved a little (although it comes to essentially the same answer as Francois). I believe that the UCD should have a precise and accurate definition, but that when you need metadata, or parameters, i.e. you need to refer to other UCDs, the utype/DM is needed. It's not a question of level of detail or "accurate", it's a question of "complete" - do you need more than one number of value to describe the idea?
Thus,
flux.photDens.sb and
flux.photDens;instr.beam
are different physical concepts - subtly different, and we are going
to a high level of detail, but it's necessary to do so.
But
RA2000 and RA1950 are the same basic concept differing only by a parameter.
The concept 'RA' and the concept 'equinox' are the two different concepts
here:
pos.eq.ra (value = 12:26:03.4) and
time.equinox (value = 2000.0)
and these are related to each other in the context of a coordinate frame (e.g. STC) data model. RA1950 and RA2000 are really the same physical concept simply with different metadata. pos.eq.ra is PRECISELY defined, it's just not COMPLETELY defined without tying it to the STC metadata.
In contrast, you can't really say that about "surface brightness" and "flux density per beam", there's no associated metadata to distinguish them. (I guess you could use instr.scale or instr.pixel and tie it to the spatially variable beam size in the second case but I think implicitly using an algorithm to connect two concepts is cheating.)
Of course for pragmatic reasons we do break this paradigm for the "phot.*;em.*" UCDs where the "em.IR" is really metadata for the "phot.*" concept. But in general I think this is a good rule of thumb for deciding whether you need a new UCD, or whether you need to relate two different UCDs via a data model.
> while UCDs can be used to define the RA and Dec, an accurate
> definition of these values requires a lot of extra parameters
> -- have a look at Arnold's Space-Time model and be sure you
> have specified everything if you want to be accurate...
> In many practical cases -- e.g. for statistical cross-matching --
> a full description is not required, and then the UCDs have their
> place.
The key phrase here is "requires a lot of extra parameters". In some other practical cases, a full description *is* required: so you need the parameters and a data model to relate them to each other. But if the data model is very generic you still need the UCDs to describe precisely what the individual parameters are.
This is of course fuzzy, since sometimes - as in parts of STC - the utype implies what the UCD must be. But sometimes the utype describes only the precise relationship between two concepts, and the UCDs describe the precise identity of the concepts - both precise, but doing different jobs. Thus you might use utypes to link a velocity and its standard of rest, but you still need to use UCDs to explain that this is the escape velocity from the star (src.veloc.escape) and not the expansion velocity of the wind (src.veloc.expansion) that you're talking about.
If you look at the src.veloc tree I see three different kinds of UCD:
Group 1
- different kinds of velocity
src.veloc
src.veloc.ang
(src.veloc means radial velocity, we're missing a way to say "(norm of) 3D space velocity", I suggest src.veloc.space or src.veloc.total)
Group 2
- the velocity of what? (distinguishing different physics concepts):
src.veloc.dispersion src.veloc.escape src.veloc.expansion src.veloc.microTurb src.veloc.pulsat src.veloc.rotat
Group 3
- shortcuts for giving parameter values of the STC frames:
src.veloc.cmb src.veloc.lg src.veloc.lsr
Do other people see the same distinction I'm seeing here?
I suggest that instead of Group 3 we should have
pos.frame.cmb, pos.frame.lg, pos.frame.lsr, pos.frame.src and allow combinations like
src.veloc;pos.frame.lsr
src.veloc.space;pos.frame.lsr
to make more clear that the concept that's changing is the frame, not the
velocity.