UCDs and XML

Roy Williams roy at cacr.caltech.edu
Wed Mar 26 07:58:13 PST 2003


Ray

You are suggesting an alternative representation of UCD for these complex
situations, doing the same semantically as Johnathan's "parametrized" UCD,
but represented in XML. Certainly from the point of view of extensibility,
the XML would seem preferable, and the connection to Xschema and Xpath is
elegant. In VOTable, we could allow UCD as an attribute of FIELD, but then
allow an alternative definition as a full XML element.

My thinking on UCD is going around the idea of "recognition".

In writing code for VO applications, I am looking for specific UCDs. Reading
the result of a cone search means finding the POS_EQ_RA_MAIN. Reading the
result of a SIAP means looking for the UCD called VOX:Image_AccessReference.

Therefore it should be allowed to have multiple UCDs describing the same
attribute, so that different applications can recognize and use it. One
person sees a galaxy, another sees a database record, another sees
clip-art -- but it's all the same entity underneath.

This recognition idea allows us to use UCD to subclass objects. If I have a
table from a cone search, then it must have UCDs corresponding to RA, Dec,
ID. Let us subclass this, for example, to a service that returns black-hole
candidates. In this case, we would expect further UCDs to be present:
BH_mass and BH_Spin.

There is a lot that can be done with UCD, and the real question is how to
allow this semantic flexibility to blossom, but without having everyone make
their own UCD and losing all interoperability!

Roy

---
Caltech Center for Advanced Computing Research
roy at cacr.caltech.edu
626 395 3670



More information about the registry mailing list