T0 : extensions to em, obs, spect, instr

[Rob Seaman]

On Jun 1, 2005, at 10:25 AM, Sebastien Derriere wrote:

> <src>
>     <param ucd="meta.id" value="NGC12345" />
>     <param ucd="src.class" value="Galaxy" />
>     <param ucd="src.morph.type" value="Sc" />
> </src>

This is similar to how I was envisioning VOEvent usage.  Rick should  
speak up (on whatever mailing list :-) if he sees this much  
differently.  That said, I question whether these specific UCDs will  
survive our discussions.

> instead of saying: "This object is a spiral galaxy", I'd rather say  
> "The result of the classification process gives for this object the  
> value [galaxy] for the source class, and the value [spiral] for the  
> morphological type".

I think we need support for both.  A name is sometimes both an  
enumerated value and a hierarchical classification.  This is  
particularly true when the words express some underlying physics (or  
merely physical description) that is still plastic.  We think we have  
a pretty good idea now what a "spiral galaxy" is.  It wasn't so very  
long ago that we hadn't the slightest idea of its true nature.  As  
long as astronomy is a living subject, there will be names with fluid  
meanings.

Another concern is that a "src.class" expression would cover vast  
expanses of phase space - dozens of orders of magnitude in size (from  
chunks of rock in the solar system to cosmological structure) and  
having to distinguish between objects and processes with every  
possible physical/chemical/even biological property in play.  Imagine  
a UCD-like expression of some field of biology - human anatomy, for  
instance.  The corresponding sci.class would only have to distinguish  
a modest size range and modest variety of entities.  (There are  
something like 200 cell types in the body.)  What we're looking for  
is a reasonable way to separate the equivalent of cell biology from  
tissue biology from physiology at the level of organs.

In particular, the allowed values for different UCDs become  
interrelated.  (This seems likely to be something you folks have  
previously considered.)  There are different values for  
src.morph.type depending on the value of src.class - and there are  
even different sets of UCDs entirely that are pertinent depending on  
the class.

In short, Sebastien's view and Rick's view need to be synthesized  
into a common vision.

> If we start creating words for each "concept" that we can name, we  
> go the wrong direction.I'd create a UCD word for objects
> in the constellation Draco,

But this is precisely what is done all the time.  An astronomer  
pursues a new line of research and invents new terminology.  Those  
terms may be representative of universal phenomena or may be specific  
to some area of study.  We're hundreds of years past caring about  
constellations scientifically, but the details of some specific  
galaxy or cluster (M13, the Hyades) may be very important to describe  
accurately and precisely.  To borrow a page from Rick, if UCDs don't  
support project specific glossaries, these will be expressed in some  
other fashion.

Rob Seaman
NOAO