Fwd: VOConcepts

Tue Jun 14 09:51:31 PDT 2005

Begin forwarded message:

> From: "Frederic V. \"Rick\" Hessman" <Hessman at Astro.physik.Uni- 
> Goettingen.DE>
> Date: June 14, 2005 12:47:45 AM MST
> To: ucd-sci at ivoa.net
> Subject: Re: VOConcepts
> Reply-To: ucd-sci at ivoa.net
>
>
>  I think we'd all appreciate a general comment on whether ucd-sci  
> is the right place for a discussion
> of what we have tenatively called VOConcept.   Yes, there are lots  
> of potential relations between VOCocept and UCD
> - see the Kyoto papers by S. Derriere and A. Allan - so there are  
> lots of reasons to include both communities
> right now, but the ultimate connections will be indirect by popular  
> demand within the UCD community, since the
> UCD design documents as they are currently written don't foresee  
> any deviations beyond the VOTable-ish uses
> of UCDs.
>
> You might ask us to please shut up and worry about this later, but  
> we're in the final throes of finishing VOEvent 1.0
> and need to make a short-term decision about whether we ignore the  
> problem of naming for now (at the cost of
> a loss of naming capability) or make an initial plunge in the  
> direction of a UCD-like VOConcept (whatever you
> want to call it).
>
> Please vote:
>
> ___ Please stop talking about VOConcept in this list - we have  
> enough to worry about as it is.
> ___ I think the two issues are still related enough to warrant  
> inclusion in the ucd-sci discussion list for now.
>
> Based upon the tally, we can decide to continue (at least now and  
> then) or to start a new list.
>
> If you vote for stopping, then please ignore the rest of this  
> message and "have a nice day." :-)
>
>
> On 14 Jun 2005, at 4:27 am, Rob Seaman wrote:
>
>
>> 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.
>>
>
> SOME semantic nomenclature.  My feeling is that there is lots of  
> resistance to a generalization and not just
> because of short-term release pressures.
>
>
>> 2) VOEVENT will soon require a VOConcept style mechanism.
>>
>
> VOEvent needs it NOW.
>
>
>> 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.
>>
>
> or, more likely, parallel to 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.
>>
>
> I agree.  For those cases (and not just the Sun) we need
>
>     <object voconcept="planet">Jupiter</object>
>     <object voconcept="stars.variable.LMXB">RXJ1234+567</object>
>     <object voconcept="galaxies.spiral">NGC12345</object>
>     <object voconcept="event.burst;em.gamma-ray">GRB12345</object>
>
> Note the combination of UCD and VOConcept in the last case and note  
> that
>
>     <object ucd="em.gamma-ray" voconcept="event.burst"/>
>
> is fine for simple things but isn't necessarily the same thing for  
> more complex naming purposes.
>
>
>> 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.
>>
>
> Both.  The complex naming will enable VO-technology to combine  
> information in new ways maybe we haven't thought of.  On the
> other hand, there has to be a human interface so that the user can  
> use terms like "GRB" or "KBO".   Yes, by combining UCD-like
> elements, we're getting close to starting an ontological analysis,  
> but just barely and not necessarily because we WANT an ontology.
> Thus, CME = stars.corona;process.mass-loss.ejection is fine - one  
> for the human, one for the computer.
>
>
>> 3) Which is it?  Sun;process.pulsation or Sun;seismology?  Again,  
>> "helioseismology" is an identifier distinct from the latter  
>> classification.
>>
>
> Neither if "Sun" is kept as a proper name ;-)
>
>     <helioseismicData ucd="em.opt phys.wave"  
> voconcept="process.pulsation">
>         <object voconcept="stars">Sun</object>
>         <data>.....</data>
>     </helioseismicData>
>
>
>> 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.)
>>
>
> No - this type of inclusion is exactly what is needed for a totally  
> different VO application: education and public outreach.  See
> http://www.communicatingastronomy.org/index.html for a VO-related  
> group which is interested in such concepts.  Nearby stars
> are interesting because they move on the sky.   "Nearby" to a  
> professional is perhaps not an interesting concept - just go to
> Sinbad and get the latest catalogue to pick out what you want - but  
> identifying images available to the public as being interesting
> for studying proper motion and parallax is a great thing and it  
> would be nice to have a universal identifier for that purpose.  The
> names themselves are what's important - it's the need for a name  
> which should drive the list.
>
>
>> 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.
>>
>
> The problem of hierarchical naming (and hence implict primitive  
> ontologies) came up early in RTML: our first list was a random
> collection of names - "star", "supernova", "cepheid",... - but it  
> became difficult to manage simply because of the danger of muliple
> entries.   A minimum amount of hierarchy insures that the  
> administration of the names is straight-forward and even eases their
> use in GUIs and other more mundane uses.
>
>
>> 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.
>>
>
> I dropped "cosmology" from the original VOConcept list because my  
> VOEvent colleagues were taken somewhat aback with
> how quickly such a list can grow and because there's no immediate  
> need for "cosmology" in VOEvent.
>
> Rick
>
> ---------------------------------------------------------------------- 
> --------------------------
> Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
> Universitaets-Sternwarte     Tel.  +49-551-39-5052
> Geismarlandstr. 11                Fax +49-551-39-5043
> 37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
> ---------------------------------------------------------------------- 
> ---------------------------
> MONET: a MOnitoring NEtwork of Telescopes
> http://monet.uni-goettingen.de
> ---------------------------------------------------------------------- 
> ---------------------------
>
>