From pdidelon at cea.fr Wed Jun 1 02:02:43 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 01 Jun 2005 11:02:43 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
Message-ID: <429D79B3.3@cea.fr>
Hi Rick,
(apologies for cross posting, i will try to avoid it in the future ;-) )
Frederic V. "Rick" Hessman wrote:
> On 31 May 2005, at 3:09 pm, Pierre Didelon wrote:
>
>> Frederic V. "Rick" Hessman wrote:
>>
SNIP
>> 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...
>
>>> ...?
>>> 2. I suggest we add UCD's for describing calibration observations.
>>> Presently, they are
>>> few mentions of calibrations at all in the official list:
>>> instr.calib (calibration parameter)
>>> phot.calib (photometric calibration)
>>> and they are sorely needed for things like VOEvent and RTML.
>>> It's trivial to say that there's a big different between
>>> calibrations (see above) and calibration
>>> observations, so new UCD's are needed and it seems the likely
>>> candidates would be:
>>> obs.calib (calibration observation)
>>> obs.calib.dome-flat (dome-flat observation)
>>> obs.calib.flux (flux calibration observation)
>>> obs.calib.freq (frequency calibration observation)
>>> obs.calib.guide-star (guide-star observation, e.g.
>>> for intial setup)
>>> obs.calib.phot (photometric calibration observation)
>>> obs.calib.pos (astrometric calibration observation
>>> obs.calib.sky-flat (sky-flat observation)
>>> obs.calib.slit-mask (slit-mask calibration observation)
>>> obs.calib.spect (spectral type calibration
>>> observation)
>>> obs.calib.veloc (radial velocity calibration
>>> observation, e.g. standard star)
>>> obs.calib.wl (wavelength calibration observation)
>>
>> 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 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.
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...?
...
> 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.
>
> 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".
> and data/observation/reduction models are VO prose or poetry: do you
> want us to write a VO poem
> using words no one (i.e. no app) understands?
>
>>> For completeness, one should then also add
>>> phot.calib.flux (photometric flux calibration)
>>> phot.calib.mag (photometric magnitude calibration)
>>> pos.calib (astrometric calibration)
>>> spect.calib (spectroscopic calibration)
>>> spect.calib.wl (" " in wavelength)
>>> spect.calib.freq (" " in frequency)
>>> 3. Suggested addition to spect (Spectroscopy)
>>> spect.cont (spectral continuum)
>>
>> I like it (personnaly), but why not then spect.background....
>
>
> If it's needed, why not? Your favorite VO app should be able to know the
> difference between a spectral line and a spectral contiinuum and, in the
> real world, between the spectrum in the background (sky). Again, we have
> spect.line right now only because there are spectral line catalogues
> out there but
> few spectral continuum catalogues.
>
> No, I'm not trying to get a VO ontology through the back door:
> ontologies tell us
> what the intimate relations between objects are, whereas UCD simply
> gives us
> the ability to name things.
Hmmm. Same comments as above concerning concepts vs things.
> We're still in the VO Neadertaler age where we've
> only agreed that "Ugga" means "rock". I'm worrying about how we
> ultimately
> want to transmit the knowledge of turning a rock into a spear. I hope
> that the problem now isn't going to be getting our colleagues to agree
> that we
> need a word for "stick"....
>
> Rick
SY
PiR
From Hessman at Astro.physik.Uni-Goettingen.DE Wed Jun 1 04:06:24 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 1 Jun 2005 13:06:24 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <429D79B3.3@cea.fr>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr>
Message-ID: <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
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!)
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
spiral galaxy
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
spiral galaxy
rather than src.class.galaxy.spiral but you don't have to use
instrumental bandwidth
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
------------------------------------------------------------------------
-------------------------
From pfo at star.le.ac.uk Wed Jun 1 04:44:33 2005
From: pfo at star.le.ac.uk (Patricio F. Ortiz)
Date: Wed, 1 Jun 2005 12:44:33 +0100 (BST)
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
Message-ID:
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":
- 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.
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!)
>
>
>
> 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
>
>
> spiral galaxy
>
>
> 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
>
> spiral galaxy
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> instrumental bandwidth
>
> 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, UK
From pdidelon at cea.fr Wed Jun 1 06:54:20 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 01 Jun 2005 15:54:20 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
Message-ID: <429DBE0C.7060905@cea.fr>
Hi,
First a precision.
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,
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!
Some small comments... only to try to precise "my" pov.
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!)
>
>
>
> 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
>
>
> spiral galaxy
>
>
> 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"?
OK! But do/must UCD be the solution to (all?) natural langage parsing?
It seems to be a general pb of enumerated lists and classifications.
must UCD integrate all the existing ones of every astro fields?
>
> 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.
Why?
Using already existing terms and definitions we could write
as you begin to do
galaxy
spiral
The nice part of this view is that as NGC12345 can be resolved by simbad/ned...
galaxy and spiral can be handle by separated services, living their own
live and evolutionary track. Unfortunately, it does not resolve "immediatly"
the nomenclature and parsing problem... I agree.
And may be it is not the good way? Once again... only "my" pov.
> If this is the foundation of this
> list, then please remove me.
Perhaps it's me who must be removed! ;-)
>
> 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", ....
Same remarks as above!
all this is related with DM Observation definition and may be utype
will perhaps be of some help?
>
>> 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......).
Yes certainly!
But perhaps another organizing way with a UCD defining a data kind and/or purpose
and then the corresponding parameters (not FIELD ;-), so not restricted to VOTable)
can take the desired values.
I don't think that UCD purpose is to solve nomenclature pb or definitions
but I am perhaps (certainly?) wrong.
>
>>> 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.
I don't catch the point!
> You want to have
> instr.bandwidth in order to identify that the number in a table
or anywhere else!
> 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.
and corresponding level of abstraction.
> Why do I have to use
>
> spiral galaxy
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> instrumental bandwidth
>
> instead of instr.bandwidth?
From my pov ( once again :-( ), instr.bandwidth is a concept realised in a lot of diff items
(all existing filters) while spiral galaxy is a classification schema realisation.
But I may be wrong, and the usefullness of some usage requires perhaps
the introduction of at least some classification schema!
including MK spectral type for stars?
>
> 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
> ------------------------------------------------------------------------
> -------------------------
>
--
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------
Aidez les enfants Tib?tains : http://www.a-e-t.org/jcparrain.htm
ou d'autres : http://www.sosesf.org/
------------------------------------------------------------------
Seule compte la d?marche. Car c'est elle qui dure et non le but
qui n'est qu'illusion du voyageur... Saint Exupery - Citadelle
------------------------------------------------------------------
From seaman at noao.edu Wed Jun 1 08:32:36 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 1 Jun 2005 08:32:36 -0700
Subject: UCDs vs ontologies?
In-Reply-To: <429DBE0C.7060905@cea.fr>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr>
Message-ID:
On Jun 1, 2005, at 6:54 AM, Pierre Didelon wrote:
> But do/must UCD be the solution to (all?) natural langage parsing?
It would be premature to begin the work of the board by willy-nilly
reassigning identifiers such as "em". It seems likely that we will
need to be able to express the concepts of both "electromagnetism"
and "emission". If there is emission, there is absorption. And
sometimes we may want to express the combination of "electromagnetic
emission" at the same time.
On the other hand, we're told that the role of UCDs is distinct from
that of ontologies. An ontology is an (attempt) at expressing the
complete range of some knowledge domain. Astronomy is a big subject
- its ontology will be big. Perhaps by analogy we can view an
ontology as the unabridged dictionary for some subject, whereas UCDs
are simply one way to build a glossary for a specific purpose.
Glossaries are often small enough to be appended to a brief document.
Personally, I think the VO community will need to develop several
separate ontologies over time as well as several separate glossaries
of UCDs or UCD-like constructs. It is not obvious that a glossary of
UCDs for tabular convenience is equivalent to a glossary of UCDs for
VOEvent convenience. An ontology can afford to be large and unwieldy
to reach its goal of being complete and accurate. A UCD style
glossary, on the other hand, will eventually reach an optimum size.
Its utility will pass a point of diminishing returns. Too much
precision engenders confusion. The availability of too many options
results in overlapping shades of meaning.
I gather the current list of UCDs was generated by looking at actual
tables in the literature. This is just how the unabridged OED was
created from words sieved from millions of quotations. Just like a
dictionary, the work of maintaining the list of UCDs will continue
indefinitely as new tabular usage is coined.
I would suggest that the creation of this new list of UCD-like
entities to describe astronomical "concepts" is fundamentally a
different exercise. We may not be trying to generate a complete
ontology with all interrelationships clearly drawn between all
concepts, but we are trying to be complete in the sense of not
leaving any gaps in the web of concepts. "Star" and "galaxy" will
clearly make the final cut. "Star.white_dwarf" and "galaxy.spiral"
most likely, too. But it won't take many levels to exhaust the
utility of compiling such a list. I expect the final list to have
hundreds of entries, not tens of thousands.
One final point. The nature of this board is to participate in the
process of certifying an official list of terms. I think the true
utility of both glossaries and dictionaries will be achieved when
facilities are available for creating and maintaining *unofficial*
lists. For VOEvent, for instance, it seems likely that each project
publishing events will adopt its own glossary pertinent to its own
instrumentation and observations. We should support these activities
and provide a framework for project specific glossaries. They will
spring into existence whether or not we do so. At least if we
support the creation of project specific glossaries, we can have some
say in controlling a common semantic structure and a standardized
distribution mechanism. This might also naturally lead to the next
step of layering UCD glossaries on top of our emerging ontology
(ies). A glossary, after all, is nothing but a well chosen list of
words out of the dictionary. It is the dictionary that provides
etymology, synonyms and antonyms, classification by part of speech,
tenses and gender, pronunciation, ...
Sorry for the cross-posting. If we can't restrain ourselves from
generating all these mailing lists, I'm not sure what hope we have
for a coherent set of UCD lists :-)
Rob Seaman
NOAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From eca at mssl.ucl.ac.uk Wed Jun 1 08:42:25 2005
From: eca at mssl.ucl.ac.uk (Elizabeth Auden)
Date: Wed, 1 Jun 2005 16:42:25 +0100 (BST)
Subject: UCDs vs ontologies?
In-Reply-To:
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it>
<94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
<429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
<429DBE0C.7060905@cea.fr>
Message-ID:
> On the other hand, we're told that the role of UCDs is distinct from that of
> ontologies. An ontology is an (attempt) at expressing the complete range of
> some knowledge domain. Astronomy is a big subject - its ontology will be
> big.
> Personally, I think the VO community will need to develop several separate
> ontologies over time as well as several separate glossaries of UCDs or
> UCD-like constructs. It is not obvious that a glossary of UCDs for tabular
> convenience is equivalent to a glossary of UCDs for VOEvent convenience. An
> ontology can afford to be large and unwieldy to reach its goal of being
> complete and accurate.
Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL format)
on the VOTech wiki at
http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any comments
on the structure, concepts, and coverage of this v0.000000001 ontology
would be appreciated.
cheers,
Elizabeth
From edward.j.shaya.1 at gsfc.nasa.gov Wed Jun 1 11:41:33 2005
From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya)
Date: Wed, 01 Jun 2005 14:41:33 -0400
Subject: [Ontology] UCDs vs ontologies?
In-Reply-To:
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr>
Message-ID: <429E015D.1080501@gsfc.nasa.gov>
Elizabeth,
Hurray. Another ontology fan. I have taken the liberty of using
OwlDoc in Protege to create a browser readable version of your
ontology. It is at
http://archive.astro.umd.edu/ont/Documentation/VOEVENT/index.html
Would you mind if I integrate what you have into the more general
ontology that I have been working on?
http://archive.astro.umd.edu/ont/Documentation/index.html
(And yes, Rob it does tend to get big, but one can trim it at any
level. I rather see UCDs as a form of topic maps which is quite a close
relative of Ontology. I prefer ontology because I believe one can do
more rigorous reasoning and query with it, but many prefer topic maps
because they are more loose and easy. )
Now that there are two of us interested in Ontology we can form a
group. It has been suggested to me that
Ontology discussions should reside in the data model group with
"[Ontology]" in the subject Re:. So, I
am ccing there too and will take the rest of this discussion there. I
hope you are tuned in Elizabeth.
Ed
Elizabeth Auden wrote:
>
> Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL
> format) on the VOTech wiki at
> http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any
> comments on the structure, concepts, and coverage of this v0.000000001
> ontology would be appreciated.
>
> cheers,
> Elizabeth
>
From Tony.Linde at leicester.ac.uk Wed Jun 1 12:20:09 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Wed, 1 Jun 2005 20:20:09 +0100
Subject: [Ontology] UCDs vs ontologies?
In-Reply-To: <429E015D.1080501@gsfc.nasa.gov>
Message-ID: <200506011920.j51JKG73009185@apollo.hq.eso.org>
Hi Ed,
Count me in too. In fact, you can count a whole sub-group of the VOTech
project, DS5. Check out:
http://wiki.eurovotech.org/bin/view/VOTech/ResourceDiscovery and associated.
And you don't need a new group, there already is one, the semantics
workgroup:
semantics at ivoa.net
archive at: http://ivoa.net/forum/semantics/
It was set up after discussions between variouspeople a couple of years ago
but died out.
I'll repost this message there (since I *HATE* cross-posting) and suggest we
all adjourn to the semantics forum for ontology-like discussions.
Cheers,
Tony.
> -----Original Message-----
> From: owner-dm at eso.org [mailto:owner-dm at eso.org] On Behalf Of Ed Shaya
> Sent: 01 June 2005 19:42
> To: Elizabeth Auden
> Cc: Rob Seaman; ucd-sci at ivoa.net; ucd at ivoa.net;
> ucd-tech at ivoa.net; Data Model IVOA List
> Subject: Re: [Ontology] UCDs vs ontologies?
>
> Elizabeth,
>
> Hurray. Another ontology fan. I have taken the liberty
> of using OwlDoc in Protege to create a browser readable
> version of your ontology. It is at
>
> http://archive.astro.umd.edu/ont/Documentation/VOEVENT/index.html
>
> Would you mind if I integrate what you have into the more
> general ontology that I have been working on?
> http://archive.astro.umd.edu/ont/Documentation/index.html
> (And yes, Rob it does tend to get big, but one can trim it at
> any level. I rather see UCDs as a form of topic maps which
> is quite a close relative of Ontology. I prefer ontology
> because I believe one can do more rigorous reasoning and
> query with it, but many prefer topic maps because they are
> more loose and easy. )
>
> Now that there are two of us interested in Ontology we can
> form a group. It has been suggested to me that Ontology
> discussions should reside in the data model group with
> "[Ontology]" in the subject Re:. So, I am ccing there too
> and will take the rest of this discussion there. I hope you
> are tuned in Elizabeth.
>
> Ed
>
>
>
>
> Elizabeth Auden wrote:
>
> >
> > Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL
> > format) on the VOTech wiki at
> > http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any
> > comments on the structure, concepts, and coverage of this
> v0.000000001
> > ontology would be appreciated.
> >
> > cheers,
> > Elizabeth
> >
>
>
From aam at astro.caltech.edu Wed Jun 1 12:30:06 2005
From: aam at astro.caltech.edu (Ashish Mahabal)
Date: Wed, 1 Jun 2005 12:30:06 -0700 (PDT)
Subject: [Ontology] UCDs vs ontologies?
In-Reply-To: <429E015D.1080501@gsfc.nasa.gov>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it>
<94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
<429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
<429DBE0C.7060905@cea.fr>
<429E015D.1080501@gsfc.nasa.gov>
Message-ID:
Hi Ed,
Count me in too.
I am the topic maps kind of person you mentioned, but also interested in
ontologies. This should provide me some new impetus to working on UCDs,
topic maps and ontologies.
-ashish
Ashish Mahabal, Caltech Astronomy, Pasadena, CA 91125
http://www.astro.caltech.edu/~aam aam at astro.caltech.edu
Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER
From pdidelon at cea.fr Wed Jun 1 02:02:43 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 01 Jun 2005 11:02:43 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
Message-ID: <429D79B3.3@cea.fr>
Hi Rick,
(apologies for cross posting, i will try to avoid it in the future ;-) )
Frederic V. "Rick" Hessman wrote:
> On 31 May 2005, at 3:09 pm, Pierre Didelon wrote:
>
>> Frederic V. "Rick" Hessman wrote:
>>
SNIP
>> 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...
>
>>> ...?
>>> 2. I suggest we add UCD's for describing calibration observations.
>>> Presently, they are
>>> few mentions of calibrations at all in the official list:
>>> instr.calib (calibration parameter)
>>> phot.calib (photometric calibration)
>>> and they are sorely needed for things like VOEvent and RTML.
>>> It's trivial to say that there's a big different between
>>> calibrations (see above) and calibration
>>> observations, so new UCD's are needed and it seems the likely
>>> candidates would be:
>>> obs.calib (calibration observation)
>>> obs.calib.dome-flat (dome-flat observation)
>>> obs.calib.flux (flux calibration observation)
>>> obs.calib.freq (frequency calibration observation)
>>> obs.calib.guide-star (guide-star observation, e.g.
>>> for intial setup)
>>> obs.calib.phot (photometric calibration observation)
>>> obs.calib.pos (astrometric calibration observation
>>> obs.calib.sky-flat (sky-flat observation)
>>> obs.calib.slit-mask (slit-mask calibration observation)
>>> obs.calib.spect (spectral type calibration
>>> observation)
>>> obs.calib.veloc (radial velocity calibration
>>> observation, e.g. standard star)
>>> obs.calib.wl (wavelength calibration observation)
>>
>> 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 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.
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...?
...
> 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.
>
> 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".
> and data/observation/reduction models are VO prose or poetry: do you
> want us to write a VO poem
> using words no one (i.e. no app) understands?
>
>>> For completeness, one should then also add
>>> phot.calib.flux (photometric flux calibration)
>>> phot.calib.mag (photometric magnitude calibration)
>>> pos.calib (astrometric calibration)
>>> spect.calib (spectroscopic calibration)
>>> spect.calib.wl (" " in wavelength)
>>> spect.calib.freq (" " in frequency)
>>> 3. Suggested addition to spect (Spectroscopy)
>>> spect.cont (spectral continuum)
>>
>> I like it (personnaly), but why not then spect.background....
>
>
> If it's needed, why not? Your favorite VO app should be able to know the
> difference between a spectral line and a spectral contiinuum and, in the
> real world, between the spectrum in the background (sky). Again, we have
> spect.line right now only because there are spectral line catalogues
> out there but
> few spectral continuum catalogues.
>
> No, I'm not trying to get a VO ontology through the back door:
> ontologies tell us
> what the intimate relations between objects are, whereas UCD simply
> gives us
> the ability to name things.
Hmmm. Same comments as above concerning concepts vs things.
> We're still in the VO Neadertaler age where we've
> only agreed that "Ugga" means "rock". I'm worrying about how we
> ultimately
> want to transmit the knowledge of turning a rock into a spear. I hope
> that the problem now isn't going to be getting our colleagues to agree
> that we
> need a word for "stick"....
>
> Rick
SY
PiR
From Hessman at Astro.physik.Uni-Goettingen.DE Wed Jun 1 04:06:24 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 1 Jun 2005 13:06:24 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <429D79B3.3@cea.fr>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr>
Message-ID: <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
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!)
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
spiral galaxy
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
spiral galaxy
rather than src.class.galaxy.spiral but you don't have to use
instrumental bandwidth
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
------------------------------------------------------------------------
-------------------------
From pfo at star.le.ac.uk Wed Jun 1 04:44:33 2005
From: pfo at star.le.ac.uk (Patricio F. Ortiz)
Date: Wed, 1 Jun 2005 12:44:33 +0100 (BST)
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
Message-ID:
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":
- 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.
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!)
>
>
>
> 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
>
>
> spiral galaxy
>
>
> 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
>
> spiral galaxy
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> instrumental bandwidth
>
> 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, UK
From pdidelon at cea.fr Wed Jun 1 06:54:20 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 01 Jun 2005 15:54:20 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
Message-ID: <429DBE0C.7060905@cea.fr>
Hi,
First a precision.
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,
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!
Some small comments... only to try to precise "my" pov.
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!)
>
>
>
> 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
>
>
> spiral galaxy
>
>
> 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"?
OK! But do/must UCD be the solution to (all?) natural langage parsing?
It seems to be a general pb of enumerated lists and classifications.
must UCD integrate all the existing ones of every astro fields?
>
> 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.
Why?
Using already existing terms and definitions we could write
as you begin to do
galaxy
spiral
The nice part of this view is that as NGC12345 can be resolved by simbad/ned...
galaxy and spiral can be handle by separated services, living their own
live and evolutionary track. Unfortunately, it does not resolve "immediatly"
the nomenclature and parsing problem... I agree.
And may be it is not the good way? Once again... only "my" pov.
> If this is the foundation of this
> list, then please remove me.
Perhaps it's me who must be removed! ;-)
>
> 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", ....
Same remarks as above!
all this is related with DM Observation definition and may be utype
will perhaps be of some help?
>
>> 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......).
Yes certainly!
But perhaps another organizing way with a UCD defining a data kind and/or purpose
and then the corresponding parameters (not FIELD ;-), so not restricted to VOTable)
can take the desired values.
I don't think that UCD purpose is to solve nomenclature pb or definitions
but I am perhaps (certainly?) wrong.
>
>>> 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.
I don't catch the point!
> You want to have
> instr.bandwidth in order to identify that the number in a table
or anywhere else!
> 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.
and corresponding level of abstraction.
> Why do I have to use
>
> spiral galaxy
>
> rather than src.class.galaxy.spiral but you don't have to use
>
> instrumental bandwidth
>
> instead of instr.bandwidth?
From my pov ( once again :-( ), instr.bandwidth is a concept realised in a lot of diff items
(all existing filters) while spiral galaxy is a classification schema realisation.
But I may be wrong, and the usefullness of some usage requires perhaps
the introduction of at least some classification schema!
including MK spectral type for stars?
>
> 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
> ------------------------------------------------------------------------
> -------------------------
>
--
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique 91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------
Aidez les enfants Tib?tains : http://www.a-e-t.org/jcparrain.htm
ou d'autres : http://www.sosesf.org/
------------------------------------------------------------------
Seule compte la d?marche. Car c'est elle qui dure et non le but
qui n'est qu'illusion du voyageur... Saint Exupery - Citadelle
------------------------------------------------------------------
From seaman at noao.edu Wed Jun 1 08:32:36 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 1 Jun 2005 08:32:36 -0700
Subject: UCDs vs ontologies?
In-Reply-To: <429DBE0C.7060905@cea.fr>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr>
Message-ID:
On Jun 1, 2005, at 6:54 AM, Pierre Didelon wrote:
> But do/must UCD be the solution to (all?) natural langage parsing?
It would be premature to begin the work of the board by willy-nilly
reassigning identifiers such as "em". It seems likely that we will
need to be able to express the concepts of both "electromagnetism"
and "emission". If there is emission, there is absorption. And
sometimes we may want to express the combination of "electromagnetic
emission" at the same time.
On the other hand, we're told that the role of UCDs is distinct from
that of ontologies. An ontology is an (attempt) at expressing the
complete range of some knowledge domain. Astronomy is a big subject
- its ontology will be big. Perhaps by analogy we can view an
ontology as the unabridged dictionary for some subject, whereas UCDs
are simply one way to build a glossary for a specific purpose.
Glossaries are often small enough to be appended to a brief document.
Personally, I think the VO community will need to develop several
separate ontologies over time as well as several separate glossaries
of UCDs or UCD-like constructs. It is not obvious that a glossary of
UCDs for tabular convenience is equivalent to a glossary of UCDs for
VOEvent convenience. An ontology can afford to be large and unwieldy
to reach its goal of being complete and accurate. A UCD style
glossary, on the other hand, will eventually reach an optimum size.
Its utility will pass a point of diminishing returns. Too much
precision engenders confusion. The availability of too many options
results in overlapping shades of meaning.
I gather the current list of UCDs was generated by looking at actual
tables in the literature. This is just how the unabridged OED was
created from words sieved from millions of quotations. Just like a
dictionary, the work of maintaining the list of UCDs will continue
indefinitely as new tabular usage is coined.
I would suggest that the creation of this new list of UCD-like
entities to describe astronomical "concepts" is fundamentally a
different exercise. We may not be trying to generate a complete
ontology with all interrelationships clearly drawn between all
concepts, but we are trying to be complete in the sense of not
leaving any gaps in the web of concepts. "Star" and "galaxy" will
clearly make the final cut. "Star.white_dwarf" and "galaxy.spiral"
most likely, too. But it won't take many levels to exhaust the
utility of compiling such a list. I expect the final list to have
hundreds of entries, not tens of thousands.
One final point. The nature of this board is to participate in the
process of certifying an official list of terms. I think the true
utility of both glossaries and dictionaries will be achieved when
facilities are available for creating and maintaining *unofficial*
lists. For VOEvent, for instance, it seems likely that each project
publishing events will adopt its own glossary pertinent to its own
instrumentation and observations. We should support these activities
and provide a framework for project specific glossaries. They will
spring into existence whether or not we do so. At least if we
support the creation of project specific glossaries, we can have some
say in controlling a common semantic structure and a standardized
distribution mechanism. This might also naturally lead to the next
step of layering UCD glossaries on top of our emerging ontology
(ies). A glossary, after all, is nothing but a well chosen list of
words out of the dictionary. It is the dictionary that provides
etymology, synonyms and antonyms, classification by part of speech,
tenses and gender, pronunciation, ...
Sorry for the cross-posting. If we can't restrain ourselves from
generating all these mailing lists, I'm not sure what hope we have
for a coherent set of UCD lists :-)
Rob Seaman
NOAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From eca at mssl.ucl.ac.uk Wed Jun 1 08:42:25 2005
From: eca at mssl.ucl.ac.uk (Elizabeth Auden)
Date: Wed, 1 Jun 2005 16:42:25 +0100 (BST)
Subject: UCDs vs ontologies?
In-Reply-To:
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it>
<94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
<429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
<429DBE0C.7060905@cea.fr>
Message-ID:
> On the other hand, we're told that the role of UCDs is distinct from that of
> ontologies. An ontology is an (attempt) at expressing the complete range of
> some knowledge domain. Astronomy is a big subject - its ontology will be
> big.
> Personally, I think the VO community will need to develop several separate
> ontologies over time as well as several separate glossaries of UCDs or
> UCD-like constructs. It is not obvious that a glossary of UCDs for tabular
> convenience is equivalent to a glossary of UCDs for VOEvent convenience. An
> ontology can afford to be large and unwieldy to reach its goal of being
> complete and accurate.
Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL format)
on the VOTech wiki at
http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any comments
on the structure, concepts, and coverage of this v0.000000001 ontology
would be appreciated.
cheers,
Elizabeth
From edward.j.shaya.1 at gsfc.nasa.gov Wed Jun 1 11:41:33 2005
From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya)
Date: Wed, 01 Jun 2005 14:41:33 -0400
Subject: [Ontology] UCDs vs ontologies?
In-Reply-To:
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr>
Message-ID: <429E015D.1080501@gsfc.nasa.gov>
Elizabeth,
Hurray. Another ontology fan. I have taken the liberty of using
OwlDoc in Protege to create a browser readable version of your
ontology. It is at
http://archive.astro.umd.edu/ont/Documentation/VOEVENT/index.html
Would you mind if I integrate what you have into the more general
ontology that I have been working on?
http://archive.astro.umd.edu/ont/Documentation/index.html
(And yes, Rob it does tend to get big, but one can trim it at any
level. I rather see UCDs as a form of topic maps which is quite a close
relative of Ontology. I prefer ontology because I believe one can do
more rigorous reasoning and query with it, but many prefer topic maps
because they are more loose and easy. )
Now that there are two of us interested in Ontology we can form a
group. It has been suggested to me that
Ontology discussions should reside in the data model group with
"[Ontology]" in the subject Re:. So, I
am ccing there too and will take the rest of this discussion there. I
hope you are tuned in Elizabeth.
Ed
Elizabeth Auden wrote:
>
> Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL
> format) on the VOTech wiki at
> http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any
> comments on the structure, concepts, and coverage of this v0.000000001
> ontology would be appreciated.
>
> cheers,
> Elizabeth
>
From Tony.Linde at leicester.ac.uk Wed Jun 1 12:20:09 2005
From: Tony.Linde at leicester.ac.uk (Tony Linde)
Date: Wed, 1 Jun 2005 20:20:09 +0100
Subject: [Ontology] UCDs vs ontologies?
In-Reply-To: <429E015D.1080501@gsfc.nasa.gov>
Message-ID: <200506011920.j51JKG73009185@apollo.hq.eso.org>
Hi Ed,
Count me in too. In fact, you can count a whole sub-group of the VOTech
project, DS5. Check out:
http://wiki.eurovotech.org/bin/view/VOTech/ResourceDiscovery and associated.
And you don't need a new group, there already is one, the semantics
workgroup:
semantics at ivoa.net
archive at: http://ivoa.net/forum/semantics/
It was set up after discussions between variouspeople a couple of years ago
but died out.
I'll repost this message there (since I *HATE* cross-posting) and suggest we
all adjourn to the semantics forum for ontology-like discussions.
Cheers,
Tony.
> -----Original Message-----
> From: owner-dm at eso.org [mailto:owner-dm at eso.org] On Behalf Of Ed Shaya
> Sent: 01 June 2005 19:42
> To: Elizabeth Auden
> Cc: Rob Seaman; ucd-sci at ivoa.net; ucd at ivoa.net;
> ucd-tech at ivoa.net; Data Model IVOA List
> Subject: Re: [Ontology] UCDs vs ontologies?
>
> Elizabeth,
>
> Hurray. Another ontology fan. I have taken the liberty
> of using OwlDoc in Protege to create a browser readable
> version of your ontology. It is at
>
> http://archive.astro.umd.edu/ont/Documentation/VOEVENT/index.html
>
> Would you mind if I integrate what you have into the more
> general ontology that I have been working on?
> http://archive.astro.umd.edu/ont/Documentation/index.html
> (And yes, Rob it does tend to get big, but one can trim it at
> any level. I rather see UCDs as a form of topic maps which
> is quite a close relative of Ontology. I prefer ontology
> because I believe one can do more rigorous reasoning and
> query with it, but many prefer topic maps because they are
> more loose and easy. )
>
> Now that there are two of us interested in Ontology we can
> form a group. It has been suggested to me that Ontology
> discussions should reside in the data model group with
> "[Ontology]" in the subject Re:. So, I am ccing there too
> and will take the rest of this discussion there. I hope you
> are tuned in Elizabeth.
>
> Ed
>
>
>
>
> Elizabeth Auden wrote:
>
> >
> > Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL
> > format) on the VOTech wiki at
> > http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any
> > comments on the structure, concepts, and coverage of this
> v0.000000001
> > ontology would be appreciated.
> >
> > cheers,
> > Elizabeth
> >
>
>
From aam at astro.caltech.edu Wed Jun 1 12:30:06 2005
From: aam at astro.caltech.edu (Ashish Mahabal)
Date: Wed, 1 Jun 2005 12:30:06 -0700 (PDT)
Subject: [Ontology] UCDs vs ontologies?
In-Reply-To: <429E015D.1080501@gsfc.nasa.gov>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it>
<94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE>
<429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE>
<429DBE0C.7060905@cea.fr>
<429E015D.1080501@gsfc.nasa.gov>
Message-ID:
Hi Ed,
Count me in too.
I am the topic maps kind of person you mentioned, but also interested in
ontologies. This should provide me some new impetus to working on UCDs,
topic maps and ontologies.
-ashish
Ashish Mahabal, Caltech Astronomy, Pasadena, CA 91125
http://www.astro.caltech.edu/~aam aam at astro.caltech.edu
Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER