Hi,
> > Accurate definitions: if they are not accurate, what good
> > are they?
>
> The practice of UCD use to date has been mainly about relating quantities
> from different catalogs which may use different column names but otherwise
> refer to the same or related concepts. In other words, UCDs are a common
> vocabulary that can be used to bridge different local schemas. I think,
> in general, the more accurate the definitions, the more meaningful the
> comparisons one can make. However, there is often a point where accuracy
> begins to work against you. Rarely are two columns from different tables
> exactly the same thing which can be compared directly. If your
> definitions are two precise, you might not be able to recognize two things
> as similar.
>
> I like to say that when interoperating between diverse resources, you need
> to squint your eyes a bit and blur the details. How much you have to blur
> is measure of how meaningful or accurate your interoperation is.
>
> What would be nice would be a UCD framework that allows the user to
> choose (to some extent) the level of accuracy at "run-time" (rather than
> having it frozen in an instance of a catalog). This might involve parsing
> the UCD in some way. For example, if two frequencies are both in the
> radio, that might be close enough. (Is there a requirement in here
> somewhere?)
I certainly agree with the general idea that for nearly any comparison you need to apply some sort of "blur" to the details. But to me this suggests that the UCDs *should* be as accurate as possible, and then they can be interpreted at the desired level of accuracy. They can be used to describe the data, *and* to interoperate. I suppose most catalogues would then have their own UCDs, but hopefully well-enough described UCDs so that comparisons can indeed be made.