On 1 Jun 2005, at 3:54 pm, Pierre Didelon wrote:
> It was only my point of view (friendly i assume, at least when writing
> it)
> and certainly not "THE" UCD-SCI board pov, and I didn't want to hurt
> you,
No problem at all :-)
> just express a (my?) difficulty when defining new UCD (similar to the
> one we had
> when trying to define UCD for planetology) which is related to the
> definition of the "good level of abstraction" to be enoughly high to
> be widely re-usable but at the same time enoughly precise to be usable
> at all!
This is why I probably sound somewhat exasperated: I keep feeling that
something
which sounds so simple, so necessary, and so obvious is meeting such
resistance.
I didn't join to partake in abstract philosophical discussions about
ontological
problems but to be able to teach my software how to handle events and
observing
requests. Thus, the whole goal has to be defining something which is
exactly
what you want: "good (enough) level of abstraction", "widely
re-useable" and
certainly "precise enough to be useful at all".
On 1 Jun 2005, at 4:50 pm, Sebastien Derriere wrote:
> Basically, concepts were only introduced in the vocabulary for
> allowing
> re-usability of words. But the most important UCD-words are those
> describing properties: they are used to say what a quantity (can be a
> number or a string) is.
Exactly. Now just abstract that idea to include not just numbers or
strings but
anything which the VO can deal with: images, spectra, astronomical
events, generic
classifications,.... Saying "what a quantity... is" is just naming
it, so anything
which needs to be identified deserves an official VO "name" (not to be
confused with names like "Sebastien" or "NGC1234"). UCD
has done this for table-like quantities, so why not extend it for the
rest of us?
> I'm confused with the "astronomical non-object concepts" and
> "sematics for astronomical objects" expressions.
> Astronomical objects (I understand sources detected in the sky, here)
> are
> named individually according to a controlled Nomenclature. The UCD have
> no role to
> play in this nomenclature.
... and no one is saying that it should. I want to name concepts, not objects.
> Currently, most of the existing UCD words are used to identify
> the *properties* of the astronomical objects (detected sources).
Exactly, except properties like "being a spiral galaxy" are not yet
allowed
even though properties like "being the rotation rate" are.
Being a spiral galaxy in the VO universe shouldn't be tied to the string "spiral galaxy" but to an official VO concept, e.g. src.class.galaxy.spiral.
On 1 Jun 2005, at 1:44 pm, Patricio F. Ortiz wrote:
> As far as I can see it, we are dealing with three (or more) "parallel
> universes":
> - table metadata (the raw material we used to develop UCDs)
> - image metadata
> - VOevents metadata
>
> Looks like the structure suggested by UCDs in the 'table metadata'
> could
> fit well into the other two cases. I see no reason not to use it.
If the present UCD weren't handy for other purposes, we frankly wouldn't be interested in extending it.
Much more important, though, is the idea that a general UCD naming all
the needed VO concepts forms the lingua franca by which VO tools, apps,
processes, data, interactions,... can at least agree about what they're
talking about. If UCD doesn't do this, then someone else will and
you'll
be forced in the long run to abandon UCD, because we don't need two
ways of expressing ourselves and maintaining two or more dictionaries
will never work.
> It's unlikely that elements from one domain could be openly used in the
> other, eg, adding an object type to a list of objects in a catalogue
> using
> its "type-ucd". Maybe someone would like to do so, but it won't happen
> in
> the large surveys.
But this is exactly what tools like sextractor do: they tell you what
it thinks zillions of
objects are. Yes, the primitive versions just give you things like
phot.mag and
pos.eq.ra, but the more "intelligent" ones will tell you if the object
is a spiral or
an elliptical galaxy. If the large surveys don't start identifying
objects this
explicitly, then they'll only produce petabytes of useless garbage.
Add the
time domain (eg LSST) and you'll have a problem if there isn't also
something
like src.class.star.variable and event.eclipse, because otherwise
they'll have
to use strings.
> Image metadata is something I haven't thought much, but it is true
> that if
> one could immediately recognize a dome-flat by looking at just one
> element
> on the metadata it would be great! People handling archives would
> likely be
> very interested in exploring this domain and propose their set of
> standardized descriptors (ucd-like or image-ucd). How can I handle it
> now
> if I want to find an image (processed with bias subtraction and
> flat-fielded?) How do I locate the adequate flat fields for a given
> image?
> I could've located the object images in an archive by the pointing
> position, but their accompaning calibration images?
This is getting away from "concepts" and toward "processes" and
"models".
Don't want to touch this can of worms! Suffice it to say that something
like
obs.image.calibrated obs.image.uncalibrated
would be handy, but connecting this to the correct
obs.calib.flatfield
isn't the job of UCD.
> VOevent seems to require description of an object and perhaps naming,
> but I see naming as a way to locate the object (at a given time).
The point is that naming in the sense of "RXJ 1234-567" is fine if
that's what
you want, but often one couldn't care less what the official name is as
long
as one knows what the object is generically.
> You will
> shoot me if I'm wrong, I'm sure :-) but this seems very much like how
> to
> build a IAU telegram to notify a supernova in a way which the
> description
> elements could be easily recognized and processed by automated agents
> (and possibly humans :-)
That's exactly what VOEvent is and why I'm here fighting ;-)
> Finally, I think Frederic mentioned why we don't have ucds with
> neutrino
> or gravity waves observations... well, 6 or 7 years ago there was
> nearly
> nothing (tables) in the literature... I agree, they should be there,
> and as
> the observation methods are likely to be quite different from
> night-astronomy, we could think of having
>
> em. electromagnetic spectrum
> gw. gravity wave detection
> nd. neutrino detection
>
> as base sections within the UCD schemes, just as we have at. to denote
> atomic transitions usually measured in the lab.
Putting it in "phys" makes more sense to me: while "gw" is ok, having "nd" means adding "ad" (axion detection), "crd" (cosmic-ray detection),....
If "em" is just the physical concept of electromagnetic radiation, then
one could argue that it
belongs in phys too. If "em" is there to descibe the means by which
an observation was made, then "em=emission" could include gravitational
waves and neutrinos and other things.
I know, I know, there are probably endless discussions about where a
concept belongs (lower level, higher level,..). I'd argue that naming
the
concepts in the long run is enough: the people who will do the
ontologies
won't care what we've called it officially. There will never be the
perfect
set of concept names but concepts are so heterogeneous and infinitely
useful. Still, better to have ANY name at all than NO name at all.
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-01Z17:55:07