VOConcepts

Howdy,

I picked this list as the most appropriate place for this conversation. Please comment if you've got a different idea. This discussion is being driven by VOEvent issues, but the implications are broader. Some observations, assumptions, and conclusions:

1. UCDs appear to be the near term VO solution for semantic nomenclature.
2. VOEVENT will soon require a VOConcept style mechanism.
3. It seems obvious that VOConcept will borrow UCD syntax.
4. There seems to be significant delay implicit with establishing VOConcept as an official offshoot of UCDland.
5. Thus it seems that there will be significant pressure to establish VOConcept as a separate namespace of some sort under UCD.

Operating under that assumption, the question is what that namespace will look like. The current snapshot is available at http:// monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/UnifiedContentDescriptors

Here are my comments;

1. Proper names don't belong under the VOConcept namespace. Whether this is a separate namespace of its own, or whether proper names are handled by a completely separate mechanism, there is no need to specify something like "solar_system.Sun". Call me a radical, but I think the Sun should simply be called "Sun". In any event, a proper name of an object or process is distinct from any sort of classification of that particular object or process.
2. A "coronal mass ejection" is not equivalent to stars.corona;process.mass-loss.ejection, whether or not this precisely describes the physical event. My point is that just as with proper names, the astronomical community has chosen to assign
   "proper class names" to certain phenomena: CMEs, GRBs, KBOs, etc.
   We will fail if we seek to provide a namespace that usefully predicts what new class names will be needed in the future. Rather, we need a mechanism for adding new identifiers.
3. Which is it? Sun;process.pulsation or Sun;seismology? Again,
   "helioseismology" is an identifier distinct from the latter
   classification.
4. We need neither stars;planets nor stars.planets - just planets. I think we can assume for most purposes that if you are describing a planet that a star is somewhere in the neighborhood.
5. How about both stars.multiple and stars.binary? These are just two out of several clustering options, such as stars.cluster, for that matter.
6. It's interesting what stars.nearby is trying to describe, but this seems pretty parochial. There are a lot of "neighborhoods" scattered throughout astronomical semantics. Maybe there is some way to generalize this as some kind of operator notation. (On the other hand, that seems a bit precious.)
7. stars.supernova seems redundant. What else would it be? This is just the "planet" comment revisited. This is distinct from the star.variable family precisely because a SN is rather emphatic.
8. VOConcept (however constituted under whatever name) needs to represent stars, galaxies, and other objects. It isn't so obvious that "cosmology" is useful classification for VOEvent purposes. It isn't obvious what VO-wide purposes this classification would be used for in general.
9. VOEvent provides a good testbed for a number of VO technologies. It seems to me that a VOConcept list targeted precisely at VOEvent needs, perhaps augmented by some carefully selected concepts to fill in just a few missing items is a good place to start.

Rob Seaman
NOAO Received on 2005-06-14Z04:27:54