"Frederic V. \"Rick\" Hessman" wrote:
>
> Let's leave the solar system out of the way at first. If we just take
> stellar+extragalactic
> astronomy, then - of course - NOBODY wants a UCD which says
>
> src.class.galaxy.spiral.virgocluster.northern-part.opt.name.NGC12345
>
> What VOEvent DOES needs, however, is something generic like (ignore the
> actual XML tag names!)
>
> <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
I agree with you that nobody wants the first expression :o)
But I'm also scared by the second one, because there is a lot
of implicit knowledge in it: because I am human (and astronomer),
I can understand it, but what would a computer understand?
You are trying to express that the observation target has a name
which is "NGC12345", and that it is a galaxy with a spiral Hubble
type (right?).
During the discussions in Kyoto, we discussed several ways of
expressing
all these informations, and we came with the following:
<src>
<param ucd="meta.id" value="NGC12345" /> <param ucd="src.class" value="Galaxy" /> <param ucd="src.morph.type" value="Sc" /></src>
Maybe that <src> could also be <group ucd="src"> ?
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.
Not quite. When you say: <param ucd="phot.mag" value="12.3" /> you indicate that the value 12.3 represents a magnitude. Whereas <src ucd="src.class.galaxy.spiral" name="NGC12345"/> is ambiguous: you implicitly conceptualize a property of the source (the morphological type), and you use an attribute ("name") to give a value ("NGC12345") that refers to the contents of the "ucd" attribute. As we speak, we often make the simplification name-of-a-thing=thing, but machines won't like it...
> What we have now is the possibility
>
> <src name="NGC12345">
> <type ucd="src.class">spiral galaxy</type>
> </src>
In this example, does "type" mean something precise? In fact, the
contents of the "ucd" attribute gives the semantic type of the value
that is associated. That is why you can use neutral tags (param) in the
schema with ucd attributes: <param ucd="" value=""/>.
If you already give special names to your schema elements, then you
implicitly give the semantic type of their contents: no need for ucd!
<magnitude>12.3</magnitude> instead of <param
ucd="phot.mag">12.3</param>
Basically, if all elements of your xml schema are already strongly
semantically typed... you don't need UCDs - but you can do a mapping
from your schema's elements to the corresponding UCDs.
> and who says what "spiral galaxy" means? Who has to parse a different
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
Now we come to the crucial point of the discussion: how to standardize
the writing of possible values of astronomical object types (in the
sense
of object classification)? Which I agree we do need in the VO.
Note however that 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". Which is quite different, and hopefully much easier
for a computer to understand.
> To say that UCD should NOT do the first (say that something is a spiral
> galaxy) but should do the latter
> (say that a table entry is a radial velocity) means that UCD is only
> intended to be
> used for tables and catalogues. If this is the foundation of this
> list, then please remove me.
We must be very careful on the role that we choose for those the words we create. 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, or to see things like "pos.eq.dec.north". I think the best would be to come with a series of practical use cases where we need to manipulate information like that of "spiral galaxy", then see how we (humans+software) can handle it.
> Why do I have to use
>
> <concept>spiral galaxy</concept>
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> <concept>instrumental bandwidth</concept>
>
> instead of instr.bandwidth?
I think the whole point is that "instrumental bandwidth" can readily be associated to a value. But what kind of value do you associate with "spiral galaxy"? Or would this "concept" be used to characterize a set of measures? If "src.class.galaxy.spiral" is only used to indicate without ambiguity to a software the morphological type of a source, then we could live with a value of (src.class) picked from an enumerated list of stadardized tokens (new UCD branch, pointer to a DM, or ontology distinguishing properly subtleties between Hubble and deVaucouleur classification, etc...)
Sebastien.
--
_______
/ ~ /, Sebastien Derriere mailto:derriere-at-astro.u-strasbg.fr
/ ~~~~ // Observatoire de Strasbourg Phone +33 (0) 390 242 444
/______// 11, rue de l'universite Telefax +33 (0) 390 242 417
(______(/ F-67000 Strasbourg France
Received on 2005-06-01Z19:26:26