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 ------------------------------------------------------------------------ -------------------------
http://monet.uni-goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2005-06-14Z09:45:31