Fwd: VOConcepts

[Rob Seaman]

Begin forwarded message:

> From: Rob Seaman <seaman at noao.edu>
> Date: June 13, 2005 7:27:31 PM MST
> To: ucd-sci at ivoa.net
> Cc: Rob Seaman <seaman at noao.edu>
> Subject: 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
>