Hi Pierre & Frederic,
Seems to me that you both have some good points in your arguments. I'll just try to put things in a different light here.
As far as I can see it, we are dealing with three (or more) "parallel universes":
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.
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.
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?
I just launched a lot of (to me at least) open questions.
Back to the VOevent case, handling a few concepts and attaching them to short descriptors seems to be quite necesary. Quite likely this list will evolve with time (everything does).
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). 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 :-)
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.
Cheers,
Patricio
On Wed, 1 Jun 2005, Frederic V. "Rick" Hessman wrote:
>
> On 1 Jun 2005, at 11:02 am, Pierre Didelon wrote:
>
> >>> UCD must define preferentially concept I suppose, isn't it?
> >>> Enumerated lists must be handle with other mechanisms!
> >>> Keyword (<=>UCD) and the corresponding values...Y/N?
> >> I'm not sure what you mean....
> >
> > I will try to explain what I mean with two or three examples...
> > if I have time, in an other mail. ;-)
> > It is related with the pb of describing things (not really naming
> > them!?)
> > (for bandpass see http://www.ivoa.net/forum/ucd/0505/0197.htm)
> > and how precise UCD must be
> > (http://www.ivoa.net/forum/ucd/0505/0202.htm).
> > The two mails of P.Ortiz give a clear insight of the basic pb.
> > To make it brief, if we can perhaps admit to have bandpass "names" in
> > UCD vocabulary
> > it become very very difficult to have solar system object names,
> > and certainly inacceptable to have all astronomical object names... I
> > hope :-D
> > This last purpose is handle by name resolvers : NED,SIMBAD...
>
> Let's leave the solar system out of the way at first. If we just take
> stellar+extragalactic
> astronomy, then - of course - NOBODY wants a UCD which says
>
> src.class.galaxy.spiral.virgocluster.northern-part.opt.name.NGC12345
>
> What VOEvent DOES needs, however, is something generic like (ignore the
> actual XML tag names!)
>
> <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
>
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.
> This is totally different
> from having a DM/ontology which says what it means to have a spiral
> galaxy or what properties are
> associated with a spiral galaxy or whether the name makes any sense.
> Of course UCD isn't a name
> resolver, but if isn't a concept resolver, what is it? Why are some
> concepts more equal than others?
>
> What we have now is the possibility
>
> <src name="NGC12345">
> <type ucd="src.class">spiral galaxy</type>
> </src>
>
> and who says what "spiral galaxy" means? Who has to parse a different
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
>
> To say that UCD should NOT do the first (say that something is a spiral
> galaxy) but should do the latter
> (say that a table entry is a radial velocity) means that UCD is only
> intended to be
> used for tables and catalogues. If this is the foundation of this
> list, then please remove me.
>
> Yes, we shouldn't throw together a list of random concepts and declare
> our work done. So, please
> complain if you don't like my suggestions. But isn't the whole point
> of ucd-sci to determine what astronomical
> concepts need to be expressable?
>
> >>> Looks like you are trying to define a data model for observation
> >>> and data reduction with UCD... which is perhaps not the best way to
> >>> go?
> >> Absolutely NOT!!!! I just want to be able to say what something is,
> > Not only!
> > For example obs.calib.dome-flat is certainly an image (or may be a
> > spectra?)
> > which have been obtained under specific conditions and used in a
> > precise context
> > to derive reduced data. It describe only a "personnal" point of view
> > of the way a
> > piece of data can be used!
>
> But the point is that the original purpose of the observation has been
> expressed.
> Whether it's an image, a spectrum, or simply a number can be extracted
> from all the
> other metadata. If you don't have "obs.calib.dome-flat", then you're
> left with scanning
> the FITS header for OBJECT="DOMEFLT", OBJECT="DFLAT", OBJECT="DOMFLAT",
> OBJECT="FLAT-DOME", ....
>
> > But take an image obs.calib.sky-flat (sky-flat observation), although
> > its main
> > usage will be calibration nobody can assert that some project can use
> > these data
> > for other purposes, even scientific ones : variability event follow
> > up, historical
> > tracing back, proper motion detection... or whatever else we are not
> > already
> > thinking or aware of.
>
> Ah, but if I'm looking for a bright GRB in daytime observations,
> knowing that the image
> is an obs.calib.sky-flat makes tremendous difference: it could have
> been an
> obs.calib.dome-flat (which wouldn't be of any use)!
>
> > obs.calib.freq or obs.calib.spectcan certainly be better defined with
> > another syntax,
> > and first of all what is the kind of observed data concerned, image,
> > spectra, linelist...?
>
> Since UCDs can be concatenated, this isn't important: the role of the
> observation has
> been named as a concept - the rest comes from the data and metadata.
>
> A trivial example of how useful this could be would be in a data
> pipeline: if all the images
> had things attached like obs.calib.dome-flat, obs.calib.wl then there
> would be a universal
> and trivial method for determining just what the data are, independent
> of FITS keywords
> and local systems (e.g. ESO.DET.CCD.PAR.TEMP......).
>
> >> just like the original
> >> VOTable types who wanted to describe their catalogue entries.
> >> There's nothing fundamentally
> >> different in a VO sense between a calibration image (say, an
> >> obs.calib.phot) and a table entry
> >> of the resulting calibration (say, phot.calib). Right now, UCD is
> >> mainly (some but not me might
> >> say only) useful for tables, which is why it needs to be extended to
> >> non-table standard VO uses.
> > Yes but it is not the goal of the SCI-Board, at least from the point
> > of view
> > of the structure, it is only concern by the content, and I am not sure
> > that all the UCD problems can be resolve only by content "handling".
> > Worthwhile for ucd-at-ivoa.net perhaps not for ucd-sci-at-ivoa.net.
>
> I disagree: the WHOLE point of ucd-sci is to make high-level decisions
> of what is needed scientifically.
> Otherwise, what's the "sci" in ucd-sci for?
>
> >> A "data model for observation and data reduction" looks very
> >> different indeed, though it must
> >> ultimately use elements for which the VO has a primitive description.
> >> UCD is our VO dictionary
> > But dictionnary of what?
> > All the words in astronomy (so it is related to ontology and semantic
> > I suppose)
> > or a dictionary of concepts, these ones beeing able to "take" values
> > or can be
> > instanciate in more precise description.
> > UCD is only a part (conceptuel one AFAI understand) of a "parameter"
> > description
> > which can be more precisely define by "values" (restricted by
> > enumerated lists,
> > obtained from name resolver....), others "attributes" or even others
> > "parameters".
>
> This is a particularly VOTable-ish view of the VO and of the role of
> UCDs. You want to have
> instr.bandwidth in order to identify that the number in a table is the
> instrumental bandwidth. I want to
> have src.class.galaxy.spiral in order to be able to identify that the
> VOEvent happened next to a spiral
> galaxy. Where's the difference? What one calls "values",
> "attributes" and "parameters" is just
> a question of semantics. Why do I have to use
>
> <concept>spiral galaxy</concept>
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> <concept>instrumental bandwidth</concept>
>
> instead of instr.bandwidth?
>
> 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
> ------------------------------------------------------------------------
> -------------------------
>
>
--- Patricio F. Ortiz pfo-at-star.le.ac.uk Department of Physics & Astronomy Phone: +44 (0)116 252 2015 University of Leicester Leicester, LE1 7RH, UKReceived on 2005-06-01Z11:45:57