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 ------------------------------------------------------------------------ -------------------------
http://monet.uni-goettingen.de ------------------------------------------------------------------------ -------------------------Received on 2005-06-01Z13:04:16