From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:24:01 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:24:01 +0200
Subject: T0 : extensions to em, obs, spect, instr
Message-ID: <20050601092401.q3m7lpliuw84sssw@webmail.sic.rm.cnr.it>

Msg sent by:
    Data: Mon, 30 May 2005 13:06:23 +0200
    Da: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
Rispondi-A: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
 Oggetto: T0 : extensions to em, obs, spect, instr
      A: ucd at ivoa.net

1. I suggest we rename em from "electromagnetic spectrum" to "emission"
and add

		em.grav-wave			(gravitational wave)
		em.neutrino			(neutrino)

	Alternatively, add

		phys.grav-wave			(gravitational wave)
		phys.particle				(particle emission)
		phys.particle.cosmic-ray
		phys.particle.neutrino
		...?

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)

	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)

	We already have spect.line.


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
------------------------------------------------------------------------
-------------------------



----- End of forwarded mail. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:24:41 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:24:41 +0200
Subject: Fwd: Txx
Message-ID: <20050601092441.99iuzngajagowosc@webmail.sic.rm.cnr.it>



----- Messaggio inoltrato da Hessman at Astro.physik.Uni-Goettingen.DE -----
    Data: Mon, 30 May 2005 13:23:44 +0200
    Da: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
Rispondi-A: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
 Oggetto: Txx
      A: ucd at ivoa.net

Again, because of VOEvent and RTML, I'd like to suggest we include at
least

	event				(physical or observational event)
	event.burst			("sudden" observed change in state)
	event.chirp			(continuous change in frequency)
	event.discovery		(discovery of previously unknown object)
	event.eclipse			(intrinsic eclipse of physically related objects)
	event.eruption			("sudden" physical change in state resulting in
more/less observed emission)
	event.explosion		(physical explosion)
	event.glitch			(discontinuous change in frequency)
	event.occulation		(extrinsic occulation of physically unrelated
objects)
	event.variation			(variation in some observable property)
	event.variation.phot		(photometric variation)
	event.variation.pos		(astrometric shift in position)
	event.variation.spect	(spectroscopic variation)

If we're going to have solar system UCD's, then it's only fair to have
stellar and
extragalactic ones:  I suggest looking at

	http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/
UnifiedContentDescriptors

were there are unit UCD's like "stars", "ism", "galaxy" (as in milky
way), "galaxies", and "cosmology".
Yes, we don't have to adopt ALL of them, but it would help to have the
basic ones.

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
------------------------------------------------------------------------
-------------------------



----- Fine messaggio inoltrato. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:27:04 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:27:04 +0200
Subject: Inoltro: SciBoard
Message-ID: <20050601092704.10nrsjdzawis0gog@webmail.sic.rm.cnr.it>



----- Messaggio inoltrato da jcm at head.cfa.harvard.edu -----
    Data: Mon, 30 May 2005 15:38:49 -0400 (EDT)
    Da: Jonathan McDowell <jcm at head.cfa.harvard.edu>
Rispondi-A: Jonathan McDowell <jcm at head.cfa.harvard.edu>
 Oggetto: SciBoard
      A: andrea at rm.iasf.cnr.it


Andrea.
 very slow email connection here at aas..
>
> A. Roadmap.
> Our goal is very simple: we need to stabilize (which means adding,
deleting,
> transforming ) the present draft list of  ucd-words, that you can find at
>
> http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt  (just the list)
> http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCDlist-20050429.pdf (the WD
> document)
>
> in order to (i) reach  consensus, and (ii) be able to promote the list
(and
> the associated document) to the level of IVOA Proposed Recommendation as
> soon as possible (within June).

OK. Doesn't need to be complete right?: in other words deleting
and transforming are more important than adding, which can be done later.


>
> B. The Board
> 1. Duration.
> There will be a Sci-Board as long as UCDs will be in use in the VO, in
order
> to maintain the vocabulary. The mission of the board is described in the
> main UCD document, that you can find at
>
> http://www.ivoa.net/Documents/latest/UCD.html
>
> now under minor revisions as suggested during the Exec Meeting in Kyoto.
> It is possible that in the future the Exec could change the mission to
suit
> new needs of the VO.

Agreed.

>
> 2. Participation.
> Participation is on a voluntary basis. Colleagues can ask the chair of the
> Board to be inserted in (or deleted from) the mailing list of the Board,
> and to work for a specific task (see below).
>
> 3. Chair
> For the transition period required to set up the Board and let it run, I
> will act as chair person of the Board (by the way,  setting up the Board
> and upgrading the present list of UCD-words to the level of IVOA PR is a
> formal action for the chairman of the UCD-WG). I propose to go for an
> election of the chairman of the Board in a month from now.
>
> C. Organization
> 1. What (Tasks)
> Time is very short, at least for this first phase of our work. I propose
> then to define a number of key tasks and form task-groups on different
> aspects of the vocabulary. The most urgent cases were well pinned down
> during the last InterOp Meeting. My first draft proposal is to organize
our
> work around the following tasks:
>
> T1: the "velocity" and the resolution(s) problems
> T2: theory and simulations (sim ?)
> T3: at/mol physics
> T4: curation (humans, organizations) and other "meta"-likes
> T5: flux (total, net, backgr. and various "flux densities") and time
(period
> of, instant of)
> T6: solar system
> Txx : ??

OK

> T0: Coordination, general issues, not included in the above Ts.
> Like the Board, tasks are not "closed". The discussion is open ("plenary")
> and contributions are welcome from every member of the Board. It will help
> people with an analytical mind (like mine!) to see "T5" appear in the
> subject of your message, if dealing with "net flux" or mid-time of
> exposure.
>
> We need a coordinator for each task, with the responsibility to make a
final
> proposal to the Board.
> There is nothing formal in the following list of people, I'm just asking
> them to pay more attention to the discussion relevant to the corresponding
> task, and summarize the discussion to the Board in due time.
> Making use of the list of members (as of today) I propose the following
> coordinators:
>
> T0	General		Andrea
> T1	Velocity/resolution	Alberto Micol
> T2	Theory/simulations	Volunteer(?)
> T3	At/Mol physics	Marie-Lise Dubernet
> T4	Meta			S?bastien D.
> T5	flux/time		Jonathan MD
> T6	Solar system		Pierre Didelon
>

Agreed.
Gerard, or Laurie Shaw maybe, as theory?

> 2. How
> Through the Board's mailing list. Always "reply to all". The chair will
> record all messages.
> In this first phase of our work time is very short. So please answer
within
> the given deadlines. We won't wait for late messages.

You need to make a "ucd-board at ivoa.net" mailing list so we
don't have to all rely on 'reply' working right.
I guess Markus or Marco can help with that?

>
> 3. When
> FIRST ACTION: please comment on the above organization/rules/tasks within
> Thursday the 2nd of June.

Comments above. Basically fine.
  Jonathan

>
> This message is sent (for the last time) also to the wider
interop at ivoa.net
> community to ask the laziest to join in.
>
> Best regards
>
> Andrea


Solar System UCDs (really Astronomical Object UCDs):
they will not be UCDs per the PR. But IVOA may need such a list
and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
group doesn't want to take that work on, the DM group should
probably do it. I think either group could do it, provided we
keep the distinction between the two lists (UCDs, as semantics
for astronomical non-object concepts, and the other list,
as semantics for astronomical objects).

 - Jonathan


----- Fine messaggio inoltrato. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================



From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:27:55 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:27:55 +0200
Subject: Fwd: SciBoard
Message-ID: <20050601092755.aupeljrjs9pcg04o@webmail.sic.rm.cnr.it>



----- Messaggio inoltrato da derriere at newb6.u-strasbg.fr -----
    Data: Tue, 31 May 2005 10:35:14 +0200
    Da: Sebastien Derriere <derriere at newb6.u-strasbg.fr>
Rispondi-A: Sebastien Derriere <derriere at newb6.u-strasbg.fr>
 Oggetto: Re: Inoltro: SciBoard
      A: Andrea Preite Martinez <andrea.preitemartinez at rm.iasf.cnr.it>,
jcm at head.cfa.harvard.edu

>
> Solar System UCDs (really Astronomical Object UCDs):
> they will not be UCDs per the PR. But IVOA may need such a list
> and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
> group doesn't want to take that work on, the DM group should
> probably do it. I think either group could do it, provided we
> keep the distinction between the two lists (UCDs, as semantics
> for astronomical non-object concepts, and the other list,
> as semantics for astronomical objects).
>

  Hi Jonathan,

  There might be a slight misunderstanding on this.
The planetary system community has worked on their needs
to express the quantities they are measuring in their field
with proper UCDs. You can see the result of this reflexion
here:
http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html
  I think these suggestions are worth examining, and they seem
quite mature: why not taking them into account for the PR.
  I am less confident that we can incorporate in the PR all the
astronomical object types/phenomenons that were discussed
for VOEvent (is this what you call "semantics for astronomical
objects"?).

Sebastien.

-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


----- Fine messaggio inoltrato. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


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!)

	<src ucd="src.class.galaxy.spiral" name="NGC12345"/>

This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and  
usefulness to having a VOTable
which contains some entry identified as meaning some physical property.  
  This is totally different
from having a DM/ontology which says what it means to have a spiral  
galaxy or what properties are
associated with a spiral galaxy or whether the name makes any sense.   
Of course UCD isn't a name
resolver, but if isn't a concept resolver, what is it? Why are some  
concepts more equal than others?

What we have now is the possibility

	<src name="NGC12345">
		<type ucd="src.class">spiral galaxy</type>
	</src>

and who says what "spiral galaxy" means?  Who has to parse a different  
object where the type is
"galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....    
Wouldn't life be so easy if we could just
say that there is a UCD "src.class.galaxy.spiral"?

To say that UCD should NOT do the first (say that something is a spiral  
galaxy) but should do the latter
(say that a table entry is a radial velocity) means that UCD is only  
intended to be
used for tables and catalogues.  If this is the foundation of this  
list, then please remove me.

Yes, we shouldn't throw together a list of random concepts and declare  
our work done.  So, please
complain if you don't like my suggestions.   But isn't the whole point  
of ucd-sci to determine what astronomical
concepts need to be expressable?

>>> Looks like you are trying to define a data model for observation
>>> and data reduction with UCD... which is perhaps not the best way to  
>>> go?
>> Absolutely NOT!!!!  I just want to be able to say what something is,
> Not only!
> For example obs.calib.dome-flat is certainly an image (or may be a  
> spectra?)
> which have been obtained under specific conditions and used in a  
> precise context
> to derive reduced data. It describe only a "personnal" point of view  
> of the way a
> piece of data can be used!

But the point is that the original purpose of the observation has been  
expressed.
Whether it's an image, a spectrum, or simply a number can be extracted  
from all the
other metadata.   If you don't have "obs.calib.dome-flat", then you're  
left with scanning
the FITS header for OBJECT="DOMEFLT", OBJECT="DFLAT", OBJECT="DOMFLAT",
OBJECT="FLAT-DOME", ....

> But take an image obs.calib.sky-flat (sky-flat observation), although  
> its main
> usage will be calibration nobody can assert that some project can use  
> these data
> for other purposes,  even scientific ones : variability event follow  
> up, historical
> tracing back, proper motion detection... or whatever else we are not  
> already
> thinking or aware of.

Ah, but if I'm looking for a bright GRB in daytime observations,  
knowing that the image
is an obs.calib.sky-flat makes tremendous difference: it could have  
been an
obs.calib.dome-flat (which wouldn't be of any use)!

> obs.calib.freq or obs.calib.spectcan certainly be better defined with  
> another syntax,
> and first of all what is the kind of observed data concerned, image,  
> spectra, linelist...?

Since UCDs can be concatenated, this isn't important: the role of the  
observation has
been named as a concept - the rest comes from the data and metadata.

A trivial example of how useful this could be would be in a data  
pipeline: if all the images
had things attached like obs.calib.dome-flat, obs.calib.wl then there  
would be a universal
and trivial method for determining just what the data are, independent  
of FITS keywords
and local systems (e.g. ESO.DET.CCD.PAR.TEMP......).

>> just like the original
>> VOTable types who wanted to describe their catalogue entries.   
>> There's  nothing fundamentally
>> different in a VO sense between a calibration image (say, an   
>> obs.calib.phot) and a table entry
>> of the resulting calibration (say, phot.calib).  Right now, UCD is   
>> mainly (some but not me might
>> say only) useful for tables, which is why it needs to be extended to   
>> non-table standard VO uses.
> Yes but it is not the goal of the SCI-Board, at least from the point  
> of view
> of the structure, it is only concern by the content, and I am not sure
> that all the UCD problems can be resolve only by content "handling".
> Worthwhile for ucd at ivoa.net perhaps not for ucd-sci at ivoa.net.

I disagree: the WHOLE point of ucd-sci is to make high-level decisions  
of what is needed scientifically.
Otherwise, what's the "sci" in ucd-sci for?

>> A "data model for observation and data reduction" looks very  
>> different  indeed, though it must
>> ultimately use elements for which the VO has a primitive description.  
>>     UCD is our VO dictionary
> But dictionnary of what?
> All the words in astronomy (so it is related to ontology and semantic  
> I suppose)
> or a dictionary of concepts, these ones beeing able to "take" values  
> or can be
> instanciate in more precise description.
> UCD is only a part (conceptuel one AFAI understand) of a "parameter"  
> description
> which can be more precisely define by  "values" (restricted by  
> enumerated lists,
> obtained from name resolver....), others "attributes" or even others  
> "parameters".

This is a particularly VOTable-ish view of the VO and of the role of  
UCDs.  You want to have
instr.bandwidth in order to identify that the number in a table is the  
instrumental bandwidth.  I want to
have src.class.galaxy.spiral in order to be able to identify that the  
VOEvent happened next to a spiral
galaxy.   Where's the difference?   What one calls "values",  
"attributes" and "parameters" is just
a question of semantics.  Why do I have to use

	<concept>spiral galaxy</concept>

rather than src.class.galaxy.spiral but you don't have to use

	<concept>instrumental bandwidth</concept>

instead of instr.bandwidth?

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------


From Hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun  1 04:21:04 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 1 Jun 2005 13:21:04 +0200
Subject: SciBoard
In-Reply-To: <20050601092755.aupeljrjs9pcg04o@webmail.sic.rm.cnr.it>
References: <20050601092755.aupeljrjs9pcg04o@webmail.sic.rm.cnr.it>
Message-ID: <214afc13b7e2902af7d44d1b6a062131@Astro.physik.Uni-Goettingen.DE>

Sebastien Derriere said:
> Solar System UCDs (really Astronomical Object UCDs):
> they will not be UCDs per the PR. But IVOA may need such a list
> and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
> group doesn't want to take that work on, the DM group should
> probably do it. I think either group could do it, provided we
> keep the distinction between the two lists (UCDs, as semantics
> for astronomical non-object concepts, and the other list,
> as semantics for astronomical objects).

The reason for separating "astronomical non-object concepts" and
"sematics for astronomical objects" escapes me entirely, even if it
were possible to do so (which it isn't).   At least someone agrees that
a natural but major extension to UCD "may be appropriate"..... :-)

The UCD group has already done a fine job of starting the listing of
astronomical concepts (object and non-object).   Do we really want
DM (or even worse, VOEvent) to do the other job, even if there's no
"model" behind the data model?  The non-table extensions to UCD
are so obvious, relatively limited in number, and totally driven by
the requirement in a variety of VO-related efforts, i.e. can't wait for
a year-long discussion of whether we want to proceed beyond VOTable.

If the consenus within the ucd-sci board is that we only need a few more
(or less) table labels, then VOEvent or RTML will be forced to do the  
job which
naturally should be done by UCD and the IVOA efforts to make VO
tools as integrated as possible will suffer a major and utterly  
unnecessary
setback.

Don't worry - my blood pressure has returned to normal and I'll shut up.

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: <Pine.LNX.4.44.0506011216540.11365-100000@barbara.star.le.ac.uk>

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!)
> 
> 	<src ucd="src.class.galaxy.spiral" name="NGC12345"/>
> 
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and  
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.  
>   This is totally different
> from having a DM/ontology which says what it means to have a spiral  
> galaxy or what properties are
> associated with a spiral galaxy or whether the name makes any sense.   
> Of course UCD isn't a name
> resolver, but if isn't a concept resolver, what is it? Why are some  
> concepts more equal than others?
> 
> What we have now is the possibility
> 
> 	<src name="NGC12345">
> 		<type ucd="src.class">spiral galaxy</type>
> 	</src>
> 
> and who says what "spiral galaxy" means?  Who has to parse a different  
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....    
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
> 
> To say that UCD should NOT do the first (say that something is a spiral  
> galaxy) but should do the latter
> (say that a table entry is a radial velocity) means that UCD is only  
> intended to be
> used for tables and catalogues.  If this is the foundation of this  
> list, then please remove me.
> 
> Yes, we shouldn't throw together a list of random concepts and declare  
> our work done.  So, please
> complain if you don't like my suggestions.   But isn't the whole point  
> of ucd-sci to determine what astronomical
> concepts need to be expressable?
> 
> >>> Looks like you are trying to define a data model for observation
> >>> and data reduction with UCD... which is perhaps not the best way to  
> >>> go?
> >> Absolutely NOT!!!!  I just want to be able to say what something is,
> > Not only!
> > For example obs.calib.dome-flat is certainly an image (or may be a  
> > spectra?)
> > which have been obtained under specific conditions and used in a  
> > precise context
> > to derive reduced data. It describe only a "personnal" point of view  
> > of the way a
> > piece of data can be used!
> 
> But the point is that the original purpose of the observation has been  
> expressed.
> Whether it's an image, a spectrum, or simply a number can be extracted  
> from all the
> other metadata.   If you don't have "obs.calib.dome-flat", then you're  
> left with scanning
> the FITS header for OBJECT="DOMEFLT", OBJECT="DFLAT", OBJECT="DOMFLAT",
> OBJECT="FLAT-DOME", ....
> 
> > But take an image obs.calib.sky-flat (sky-flat observation), although  
> > its main
> > usage will be calibration nobody can assert that some project can use  
> > these data
> > for other purposes,  even scientific ones : variability event follow  
> > up, historical
> > tracing back, proper motion detection... or whatever else we are not  
> > already
> > thinking or aware of.
> 
> Ah, but if I'm looking for a bright GRB in daytime observations,  
> knowing that the image
> is an obs.calib.sky-flat makes tremendous difference: it could have  
> been an
> obs.calib.dome-flat (which wouldn't be of any use)!
> 
> > obs.calib.freq or obs.calib.spectcan certainly be better defined with  
> > another syntax,
> > and first of all what is the kind of observed data concerned, image,  
> > spectra, linelist...?
> 
> Since UCDs can be concatenated, this isn't important: the role of the  
> observation has
> been named as a concept - the rest comes from the data and metadata.
> 
> A trivial example of how useful this could be would be in a data  
> pipeline: if all the images
> had things attached like obs.calib.dome-flat, obs.calib.wl then there  
> would be a universal
> and trivial method for determining just what the data are, independent  
> of FITS keywords
> and local systems (e.g. ESO.DET.CCD.PAR.TEMP......).
> 
> >> just like the original
> >> VOTable types who wanted to describe their catalogue entries.   
> >> There's  nothing fundamentally
> >> different in a VO sense between a calibration image (say, an   
> >> obs.calib.phot) and a table entry
> >> of the resulting calibration (say, phot.calib).  Right now, UCD is   
> >> mainly (some but not me might
> >> say only) useful for tables, which is why it needs to be extended to   
> >> non-table standard VO uses.
> > Yes but it is not the goal of the SCI-Board, at least from the point  
> > of view
> > of the structure, it is only concern by the content, and I am not sure
> > that all the UCD problems can be resolve only by content "handling".
> > Worthwhile for ucd at ivoa.net perhaps not for ucd-sci at ivoa.net.
> 
> I disagree: the WHOLE point of ucd-sci is to make high-level decisions  
> of what is needed scientifically.
> Otherwise, what's the "sci" in ucd-sci for?
> 
> >> A "data model for observation and data reduction" looks very  
> >> different  indeed, though it must
> >> ultimately use elements for which the VO has a primitive description.  
> >>     UCD is our VO dictionary
> > But dictionnary of what?
> > All the words in astronomy (so it is related to ontology and semantic  
> > I suppose)
> > or a dictionary of concepts, these ones beeing able to "take" values  
> > or can be
> > instanciate in more precise description.
> > UCD is only a part (conceptuel one AFAI understand) of a "parameter"  
> > description
> > which can be more precisely define by  "values" (restricted by  
> > enumerated lists,
> > obtained from name resolver....), others "attributes" or even others  
> > "parameters".
> 
> This is a particularly VOTable-ish view of the VO and of the role of  
> UCDs.  You want to have
> instr.bandwidth in order to identify that the number in a table is the  
> instrumental bandwidth.  I want to
> have src.class.galaxy.spiral in order to be able to identify that the  
> VOEvent happened next to a spiral
> galaxy.   Where's the difference?   What one calls "values",  
> "attributes" and "parameters" is just
> a question of semantics.  Why do I have to use
> 
> 	<concept>spiral galaxy</concept>
> 
> rather than src.class.galaxy.spiral but you don't have to use
> 
> 	<concept>instrumental bandwidth</concept>
> 
> instead of instr.bandwidth?
> 
> Rick
> 
> ------------------------------------------------------------------------ 
> ------------------------
> Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
> Universitaets-Sternwarte     Tel.  +49-551-39-5052
> Geismarlandstr. 11                Fax +49-551-39-5043
> 37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
> ------------------------------------------------------------------------ 
> -------------------------
> MONET: a MOnitoring NEtwork of Telescopes
> http://monet.uni-goettingen.de
> ------------------------------------------------------------------------ 
> -------------------------
> 
> 

---
Patricio F. Ortiz			pfo at star.le.ac.uk
Department of Physics & Astronomy	Phone: +44 (0)116 252 2015
University of Leicester			
Leicester, LE1 7RH, 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!)
> 
>     <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
> 
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and  
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.  
>  This is totally different
> from having a DM/ontology which says what it means to have a spiral  
> galaxy or what properties are
> associated with a spiral galaxy or whether the name makes any sense.   
> Of course UCD isn't a name
> resolver, but if isn't a concept resolver, what is it? Why are some  
> concepts more equal than others?
> 
> What we have now is the possibility
> 
>     <src name="NGC12345">
>         <type ucd="src.class">spiral galaxy</type>
>     </src>
> 
> and who says what "spiral galaxy" means?  Who has to parse a different  
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....    
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
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
<src name="NGC12345">
          <automatedObjType ucd="src.class">galaxy</automatedObjType>
	 <supervisedMorphType ucd="src.morph">spiral</supervisedMorphType>
</src>
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
> 
>     <concept>spiral galaxy</concept>
> 
> rather than src.class.galaxy.spiral but you don't have to use
> 
>     <concept>instrumental bandwidth</concept>
> 
> instead of instr.bandwidth?
 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 derriere at newb6.u-strasbg.fr  Wed Jun  1 06:56:06 2005
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Wed, 01 Jun 2005 15:56:06 +0200
Subject: ucdComments page
Message-ID: <429DBE76.DD411C81@astro.u-strasbg.fr>


  Hi all,

  An answer to both Pierre and Miguel:

Pierre Didelon wrote:
> 
> Is there a formal/official way to do this?
> Can people who are not part of the board submit modifications? How?
> Is there an entry point for the community outside the board?
> What is the "good" submission path or procedure?
> Four questions for the same pb is perhaps enough! :-D
> Cordially,
> Pierre

Miguel Cervi?o wrote:
> 
> Additionally, should be the UCDs posted at:
> 
> http://cdsweb.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments?sort=C
> 
> included in the draft-list?

  Now that we have a proper scientific board, with a mailing-list
that is archived (1), etc... we might close submissions on the 
aforementioned web page, and redirect instead people from the 
community to the ucd-sci at ivoa.net for their comments/suggestions.
  This would avoid confusion: the sci-board would clearly be the only
entry point for UCD curation. If noone disagrees, I'll disable
posting on the ucdComments page, and invite submissions by email
to ucd-sci at ivoa.net.

  And we can discuss some of the suggestions that are still unanswered
on that page!

Sebastien.

1: http://www.ivoa.net/forum/ucd-sci/
-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


From derriere at newb6.u-strasbg.fr  Wed Jun  1 07:50:24 2005
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Wed, 01 Jun 2005 16:50:24 +0200
Subject: T0 : extensions to em, obs, spect, instr
References: <e4a51a9b1b83d9019eda7106de4e7265@Astro.physik.Uni-Goettingen.DE> <429C61EF.4020300@cea.fr>
Message-ID: <429DCB30.C9F96D0E@astro.u-strasbg.fr>

Pierre Didelon wrote:
> 
> UCD must define preferentially concept I suppose, isn't it?

"Frederic V. \"Rick\" Hessman" wrote:
> 
> The reason for separating "astronomical non-object concepts" and
> "sematics for astronomical objects" escapes me entirely, even if it
> were possible to do so (which it isn't).   At least someone agrees that
> a natural but major extension to UCD "may be appropriate"..... :-)

  Hi,

  Reading the last messages, I realize that we must be *very* careful
with the vocabulary we use (especially as members of a board aiming at 
describing semantic contents!).
  I have already experienced how words like "objects", "concepts" and
"types" can be (mis)understood when discussing across (and even
within) different domains (mainly astronomy and computer science).
Let me explain a few points that don't seem clear:

  Concept / properties :

  Following the ontology vocabulary, a *concept* is something abstract
(can be seen as a class in object-oriented programming).
  This concept can have *properties*.
  When you define an *instance* of a concept, you associate values to
the
various properties.

example: "telescope" can be seen as a concept (something abstract).
Several
properties can be associated to the concept of a telescope (its name,
size,
mass, location, ...). A particular telescope (one that you can see, or
observe
with) will be an instance of the concept "telescope".

  In the UCD vocabulary, most of the words correspond to *properties*.
Because
some properties are common to different concepts, we also created some
UCD-words 
corresponding to *concepts*, and we can build complete UCDs by writing:
"property;concept". This was done to reduce the number of words: for M
properties
and N concepts, this leads to N+M words instead of N*M.
  For the example above, we have the concept of telescope: "instr.tel".
It can have a name: ucd="meta.id;instr.tel", a size:
ucd="phys.size.diameter;instr.tel",
a location, eg: ucd="pos.earth.lon;instr.tel" and
ucd="pos.earth.lat;instr.tel", ...

  Basically, concepts were only introduced in the vocabulary for
allowing
re-usability of words. But the most important UCD-words are those
describing properties: they are used to say what a quantity (can be a
number
or a string) is.

  Objects / non-objects :

  I'm confused with the "astronomical non-object concepts" and 
"sematics for astronomical objects" expressions.
  Astronomical objects (I understand sources detected in the sky, here)
are
named individually according to a controlled Nomenclature. The UCD have
no role to
play in this nomenclature. But there is one UCD word to say that a
quantity is an
object's name: meta.id  :  Identifier, name or designation
  Or maybe we can write: "meta.id;src"
e.g. <PARAM ucd="meta.id;src" value="NGC 234">

  Currently, most of the existing UCD words are used to identify
the *properties* of the astronomical objects (detected sources).



Sebastien.  

-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


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: <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>

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: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050601/ccb525ef/attachment.html>

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: <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>
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> <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>
Message-ID: <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk>

> 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 Hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun  1 08:57:15 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 1 Jun 2005 17:57:15 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <429DCB30.C9F96D0E@astro.u-strasbg.fr>
References: <e4a51a9b1b83d9019eda7106de4e7265@Astro.physik.Uni-Goettingen.DE> <429C61EF.4020300@cea.fr> <429DCB30.C9F96D0E@astro.u-strasbg.fr>
Message-ID: <868c9786a97ac1836b54c4783c304dc7@Astro.physik.Uni-Goettingen.DE>

On 1 Jun 2005, at 3:54 pm, Pierre Didelon wrote:

> It was only my point of view (friendly i assume, at least when writing  
> it)
> and certainly not "THE" UCD-SCI board pov, and I didn't want to hurt  
> you,

No problem at all :-)

> just express a (my?) difficulty when defining new UCD (similar to the  
> one we had
> when trying to define UCD for planetology) which is related to the
> definition of the "good level of abstraction" to be enoughly high to
> be widely re-usable but at the same time enoughly precise to be usable  
> at all!

This is why I probably sound somewhat exasperated: I keep feeling that  
something
which sounds so simple, so necessary, and so obvious is meeting such  
resistance.
I didn't join to partake in abstract philosophical discussions about  
ontological
problems but to be able to teach my software how to handle events and  
observing
requests.  Thus, the whole goal has to be defining something which is  
exactly
what you want: "good (enough) level of abstraction", "widely  
re-useable" and
certainly "precise enough to be useful at all".


On 1 Jun 2005, at 4:50 pm, Sebastien Derriere wrote:
> Basically, concepts were only introduced in the vocabulary for
> allowing
> re-usability of words. But the most important UCD-words are those
> describing properties: they are used to say what a quantity (can be a
> number or a string) is.

Exactly.  Now just abstract that idea to include not just numbers or  
strings but
anything which the VO can deal with: images, spectra, astronomical  
events, generic
classifications,....     Saying "what a quantity... is" is just naming  
it, so anything
which needs to be identified deserves an official VO "name" (not to be
confused with names like "Sebastien" or "NGC1234").  UCD
has done this for table-like quantities, so why not extend it for the  
rest of us?

>   I'm confused with the "astronomical non-object concepts" and
> "sematics for astronomical objects" expressions.
>   Astronomical objects (I understand sources detected in the sky, here)
> are
> named individually according to a controlled Nomenclature. The UCD have
> no role to
> play in this nomenclature.

... and no one is saying that it should.  I want to name concepts, not  
objects.

>   Currently, most of the existing UCD words are used to identify
> the *properties* of the astronomical objects (detected sources).

Exactly, except properties like "being a spiral galaxy" are not yet  
allowed
even though properties like "being the rotation rate" are.

Being a spiral galaxy in the VO universe shouldn't be tied to the string
"spiral galaxy" but to an official VO concept, e.g.  
src.class.galaxy.spiral.


On 1 Jun 2005, at 1:44 pm, Patricio F. Ortiz wrote:

> As far as I can see it, we are dealing with three (or more) "parallel
> universes":
> - table metadata (the raw material we used to develop UCDs)
> - image metadata
> - VOevents metadata
>
> Looks like the structure suggested by UCDs in the 'table metadata'  
> could
> fit well into the other two cases. I see no reason not to use it.

If the present UCD weren't handy for other purposes, we frankly wouldn't
be interested in extending it.

Much more important, though, is the idea that a general UCD naming all
the needed VO concepts forms the lingua franca by which VO tools, apps,
processes, data, interactions,... can at least agree about what they're
talking about.    If UCD doesn't do this, then someone else will and  
you'll
be forced in the long run to abandon UCD, because we don't need two
ways of expressing ourselves and maintaining two or more dictionaries
will never work.

> It's unlikely that elements from one domain could be openly used in the
> other, eg, adding an object type to a list of objects in a catalogue  
> using
> its "type-ucd". Maybe someone would like to do so, but it won't happen  
> in
> the large surveys.

But this is exactly what tools like sextractor do: they tell you what  
it thinks zillions of
objects are.  Yes, the primitive versions just give you things like  
phot.mag and
pos.eq.ra, but the more "intelligent" ones will tell you if the object  
is a spiral or
an elliptical galaxy.   If the large surveys don't start identifying  
objects this
explicitly, then they'll only produce petabytes of useless garbage.   
Add the
time domain (eg LSST) and you'll have a problem if there isn't also  
something
like src.class.star.variable and event.eclipse, because otherwise  
they'll have
to use strings.

> Image metadata is something I haven't thought much, but it is true  
> that if
> one could immediately recognize a dome-flat by looking at just one  
> element
> on the metadata it would be great! People handling archives would  
> likely be
> very interested in exploring this domain and propose their set of
> standardized descriptors (ucd-like or image-ucd). How can I handle it  
> now
> if I want to find an image (processed with bias subtraction and
> flat-fielded?) How do I locate the adequate flat fields for a given  
> image?
> I could've located the object images in an archive by the pointing
> position, but their accompaning calibration images?

This is getting away from "concepts" and toward "processes" and  
"models".
Don't want to touch this can of worms! Suffice it to say that something  
like

	obs.image.calibrated
	obs.image.uncalibrated

would be handy, but connecting this to the correct

	obs.calib.flatfield

isn't the job of UCD.

> VOevent seems to require description of an object and perhaps naming,
> but I see naming as a way to locate the object (at a given time).

The point is that naming in the sense of "RXJ 1234-567" is fine if  
that's what
you want, but often one couldn't care less what the official name is as  
long
as one knows what the object is generically.

> You will
> shoot me if I'm wrong, I'm sure :-) but this seems very much like how  
> to
> build a IAU telegram to notify a supernova in a way which the  
> description
> elements could be easily recognized and processed by automated agents
> (and possibly humans :-)

That's exactly what VOEvent is and why I'm here fighting ;-)

> Finally, I think Frederic mentioned why we don't have ucds with  
> neutrino
> or gravity waves observations... well, 6 or 7 years ago there was  
> nearly
> nothing (tables) in the literature... I agree, they should be there,  
> and as
> the observation methods are likely to be quite different from
> night-astronomy, we could think of having
>
> em.	electromagnetic spectrum
> gw.	gravity wave detection
> nd.	neutrino detection
>
> as base sections within the UCD schemes, just as we have at. to denote
> atomic transitions usually measured in the lab.

Putting it in "phys" makes more sense to me: while "gw" is ok, having
"nd" means adding "ad" (axion detection), "crd" (cosmic-ray  
detection),....

If "em" is just the physical concept of electromagnetic radiation, then  
one could argue that it
belongs in phys too.   If "em" is there to descibe the means by which
an observation was made, then "em=emission" could include gravitational
waves and neutrinos and other things.

I know, I know, there are probably endless discussions about where a
concept belongs (lower level, higher level,..).   I'd argue that naming  
the
concepts in the long run is enough: the people who will do the  
ontologies
won't care what we've called it officially.  There will never be the  
perfect
set of concept names but concepts are so heterogeneous and infinitely
useful.    Still, better to have ANY name at all than NO name at all.

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------


From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 09:08:41 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 18:08:41 +0200
Subject: cross-posting!!
Message-ID: <20050601180841.chccno54i8g7ksog@webmail.sic.rm.cnr.it>

Dear all,

could you please STOP cross-posting your messages?

The manager of the IVOA mailing list was so kind to open for the discussion
two new mailing lists.
After half a day he is already asking himself if that was of any use,
because people continues to send discussion mails also to ucd/voevents/...
lists!!

Thank you for your attention.

Andrea
==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From pdidelon at cea.fr  Wed Jun  1 09:43:50 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 01 Jun 2005 18:43:50 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <868c9786a97ac1836b54c4783c304dc7@Astro.physik.Uni-Goettingen.DE>
References: <e4a51a9b1b83d9019eda7106de4e7265@Astro.physik.Uni-Goettingen.DE> <429C61EF.4020300@cea.fr> <429DCB30.C9F96D0E@astro.u-strasbg.fr> <868c9786a97ac1836b54c4783c304dc7@Astro.physik.Uni-Goettingen.DE>
Message-ID: <429DE5C6.40809@cea.fr>



Frederic V. "Rick" Hessman wrote:

> On 1 Jun 2005, at 3:54 pm, Pierre Didelon wrote:
> 
>> It was only my point of view (friendly i assume, at least when 
>> writing  it)
>> and certainly not "THE" UCD-SCI board pov, and I didn't want to hurt  
>> you,
> 
> 
> No problem at all :-)

Ouf/Ah!
> 
>> just express a (my?) difficulty when defining new UCD (similar to the  
>> one we had
>> when trying to define UCD for planetology) which is related to the
>> definition of the "good level of abstraction" to be enoughly high to
>> be widely re-usable but at the same time enoughly precise to be 
>> usable  at all!
> 
> 
> This is why I probably sound somewhat exasperated: I keep feeling that  
> something
> which sounds so simple, so necessary, and so obvious is meeting such  
> resistance.
> I didn't join to partake in abstract philosophical discussions about  
> ontological
> problems but to be able to teach my software how to handle events and  
> observing
> requests.  Thus, the whole goal has to be defining something which is  
> exactly
> what you want: "good (enough) level of abstraction", "widely  
> re-useable" and
> certainly "precise enough to be useful at all".
;-)
But something obvious or "natural" for somebody in a specific context
can have diff. meaning for somebody else in another context.
That's also why  trying to convince colleagues of the usefullness of terms
is important, it force to express the implicit part of the definition.
See comment below on calib. The pb of galaxy.spiral is diff. I agree.
> On 1 Jun 2005, at 4:50 pm, Sebastien Derriere wrote:
[SNIP]
>>   Currently, most of the existing UCD words are used to identify
>> the *properties* of the astronomical objects (detected sources).
> 
> 
> Exactly, except properties like "being a spiral galaxy" are not yet  
> allowed
> even though properties like "being the rotation rate" are.
> 
> Being a spiral galaxy in the VO universe shouldn't be tied to the string
> "spiral galaxy" but to an official VO concept, e.g.  
> src.class.galaxy.spiral.
> 
:-(
src.class.galaxy is perhaps ok (if I understand correctly the mail of Rob Seaman
http://www.ivoa.net/forum/ucd-sci/0506/0015.htm) then spiral can be an "additional"
property extracted from an enumerated list... official or project specific?
Not clear for me.
> 
[snipp]
> 
> This is getting away from "concepts" and toward "processes" and  "models".
> Don't want to touch this can of worms! Suffice it to say that something  
> like
> 
>     obs.image.calibrated
>     obs.image.uncalibrated
Calibrated means astrometrically and/or phtometrically calibrated? Relative or absolute?
in which reference system? ...
What about spectral data, interferogramm, cosmic ray and neutrino detection?
All these data have diff. level of calibration, completly diff. one from the other.
Do we need to define all these in UCD, or something more general like
meta.dataset.status a property which can take values like raw, astrom.calib, photomCalib...
or whatever needed by a project or a context.
> 
> would be handy, but connecting this to the correct
> 
>     obs.calib.flatfield
> 
> isn't the job of UCD.
> 
Agree ;-).
SY
PiR



From derriere at newb6.u-strasbg.fr  Wed Jun  1 10:25:59 2005
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Wed, 01 Jun 2005 19:25:59 +0200
Subject: T0 : extensions to em, obs, spect, instr
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: <429DEFA7.197122FF@astro.u-strasbg.fr>

"Frederic V. \"Rick\" Hessman" wrote:
> 
> Let's leave the solar system out of the way at first.  If we just take
> stellar+extragalactic
> astronomy, then - of course - NOBODY wants a UCD which says
> 
>         src.class.galaxy.spiral.virgocluster.northern-part.opt.name.NGC12345
> 
> What VOEvent DOES needs, however, is something generic like (ignore the
> actual XML tag names!)
> 
>         <src ucd="src.class.galaxy.spiral" name="NGC12345"/>

  I agree with you that nobody wants the first expression :o)
But I'm also scared by the second one, because there is a lot
of implicit knowledge in it: because I am human (and astronomer),
I can understand it, but what would a computer understand?
  You are trying to express that the observation target has a name
which is "NGC12345", and that it is a galaxy with a spiral Hubble 
type (right?).
  During the discussions in Kyoto, we discussed several ways of
expressing
all these informations, and we came with the following:
<src>
	<param ucd="meta.id" value="NGC12345" />
	<param ucd="src.class" value="Galaxy" />
	<param ucd="src.morph.type" value="Sc" />
</src>

  Maybe that <src> could also be <group ucd="src"> ?

> 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.

  Not quite. When you say: <param ucd="phot.mag" value="12.3" />
you indicate that the value 12.3 represents a magnitude.
Whereas <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
is ambiguous: you implicitly conceptualize a property of the
source (the morphological type), and you use an attribute ("name")
to give a value ("NGC12345") that refers to the contents of the "ucd"
attribute. As we speak, we often make the simplification
name-of-a-thing=thing, but machines won't like it...

> What we have now is the possibility
> 
>         <src name="NGC12345">
>                 <type ucd="src.class">spiral galaxy</type>
>         </src>

  In this example, does "type" mean something precise? In fact, the 
contents of the "ucd" attribute gives the semantic type of the value
that is associated. That is why you can use neutral tags (param) in the
schema with ucd attributes: <param ucd="" value=""/>.
  If you already give special names to your schema elements, then you
implicitly give the semantic type of their contents: no need for ucd!
<magnitude>12.3</magnitude> instead of <param
ucd="phot.mag">12.3</param>
  Basically, if all elements of your xml schema are already strongly
semantically typed... you don't need UCDs - but you can do a mapping
from your schema's elements to the corresponding UCDs.

> 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"?

  Now we come to the crucial point of the discussion: how to standardize
the writing of possible values of astronomical object types (in the
sense
of object classification)? Which I agree we do need in the VO.
  Note however that instead of saying: "This object is a spiral galaxy",
I'd rather say "The result of the classification process gives for this
object
the value [galaxy] for the source class, and the value [spiral] for the
morphological type". Which is quite different, and hopefully much easier
for a computer to understand.

> 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.

  We must be very careful on the role that we choose for those the
words we create. If we start creating words for each "concept" that
we can name, we go the wrong direction.I'd create a UCD word for objects 
in the constellation Draco, or to see things like "pos.eq.dec.north".
  I think the best would be to come with a series of practical
use cases where we need to manipulate information like that of
"spiral galaxy", then see how we (humans+software) can handle it.

>  Why do I have to use
> 
>         <concept>spiral galaxy</concept>
> 
> rather than src.class.galaxy.spiral but you don't have to use
> 
>         <concept>instrumental bandwidth</concept>
> 
> instead of instr.bandwidth?

  I think the whole point is that "instrumental bandwidth"
can readily be associated to a value. But what kind of value 
do you associate with "spiral galaxy"? Or would this "concept"
be used to characterize a set of measures? 
  If "src.class.galaxy.spiral" is only used to indicate without 
ambiguity to a software the morphological type of a source, then
we could live with a value of (src.class) picked from an enumerated 
list of stadardized tokens (new UCD branch, pointer to a DM, or
ontology distinguishing properly subtleties between Hubble and 
deVaucouleur classification, etc...) 

Sebastien.
-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


From seaman at noao.edu  Wed Jun  1 11:03:16 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 1 Jun 2005 11:03:16 -0700
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <429DEFA7.197122FF@astro.u-strasbg.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> <429DEFA7.197122FF@astro.u-strasbg.fr>
Message-ID: <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>

On Jun 1, 2005, at 10:25 AM, Sebastien Derriere wrote:

> <src>
>     <param ucd="meta.id" value="NGC12345" />
>     <param ucd="src.class" value="Galaxy" />
>     <param ucd="src.morph.type" value="Sc" />
> </src>

This is similar to how I was envisioning VOEvent usage.  Rick should  
speak up (on whatever mailing list :-) if he sees this much  
differently.  That said, I question whether these specific UCDs will  
survive our discussions.

> instead of saying: "This object is a spiral galaxy", I'd rather say  
> "The result of the classification process gives for this object the  
> value [galaxy] for the source class, and the value [spiral] for the  
> morphological type".

I think we need support for both.  A name is sometimes both an  
enumerated value and a hierarchical classification.  This is  
particularly true when the words express some underlying physics (or  
merely physical description) that is still plastic.  We think we have  
a pretty good idea now what a "spiral galaxy" is.  It wasn't so very  
long ago that we hadn't the slightest idea of its true nature.  As  
long as astronomy is a living subject, there will be names with fluid  
meanings.

Another concern is that a "src.class" expression would cover vast  
expanses of phase space - dozens of orders of magnitude in size (from  
chunks of rock in the solar system to cosmological structure) and  
having to distinguish between objects and processes with every  
possible physical/chemical/even biological property in play.  Imagine  
a UCD-like expression of some field of biology - human anatomy, for  
instance.  The corresponding sci.class would only have to distinguish  
a modest size range and modest variety of entities.  (There are  
something like 200 cell types in the body.)  What we're looking for  
is a reasonable way to separate the equivalent of cell biology from  
tissue biology from physiology at the level of organs.

In particular, the allowed values for different UCDs become  
interrelated.  (This seems likely to be something you folks have  
previously considered.)  There are different values for  
src.morph.type depending on the value of src.class - and there are  
even different sets of UCDs entirely that are pertinent depending on  
the class.

In short, Sebastien's view and Rick's view need to be synthesized  
into a common vision.

> If we start creating words for each "concept" that we can name, we  
> go the wrong direction.I'd create a UCD word for objects
> in the constellation Draco,

But this is precisely what is done all the time.  An astronomer  
pursues a new line of research and invents new terminology.  Those  
terms may be representative of universal phenomena or may be specific  
to some area of study.  We're hundreds of years past caring about  
constellations scientifically, but the details of some specific  
galaxy or cluster (M13, the Hyades) may be very important to describe  
accurately and precisely.  To borrow a page from Rick, if UCDs don't  
support project specific glossaries, these will be expressed in some  
other fashion.

Rob Seaman
NOAO


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: <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk>
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> <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu> <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk>
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 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> <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>
 <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk> <429E015D.1080501@gsfc.nasa.gov>
Message-ID: <Pine.LNX.4.58.0506011228430.765@avyakta.caltech.edu>


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 mcs at iaa.es  Thu Jun  2 01:48:01 2005
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 2 Jun 2005 10:48:01 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DEFA7.197122FF@astro.u-strasbg.fr> <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
Message-ID: <F020612C-AC94-4CEE-B06E-85ED27E3D896@iaa.es>

Hello all,

I give you my opinion in the present discussion from a naif point of  
view :)

Something that has been rounding my mind when I think about UCDs is  
how much "detailed" it must be and what are the implications for  
others "fields" (I mean, value, units, datatype, etc...) in a "param"  
tag. I post some cases and latter my opinion below.

  - A given UCD would imply something for the "data type"?:

         <param ucd="phot.mag" value="12.3" />

     Implies that this UCD has a value with datatype="float". It  
means that only in cases
     where it will be ambiguity  the datatype should be defined?

- Would be used a UCD alone without an associated value?
       It would be the case of:

          obs.image.uncalibrated  that defines by itself a property  
of the image, what would be the
              "value" in that case? Yes, No?
         src.class.galaxy.spiral is a similar situation.

- Should an UCD give some information about the zero-points or the  
units?

         phy.abund.X  means implicitly abundance by mass or by  
number? It has sense phys.abund.X.byMass?
         Would a UDC distinguish between log Luminosity or  
Luminosity? (phot.flux and pho.mag have sense if
         this distinction is the work to do by the UCD; they are  
redundant if such a work must be done by "units")

- Should an UCD be a "standard" assignation of the "name" filed?

Well, now comes my point of view:

I think that UDCs words are only valid if they do imply NO inference
in the other possible "fileds", a ucd-tag have sense  only as a  
complement of  "value" or "datatype" fields (sometimes also units  
etc..., I am not compltly sure about "name")

  As an example which would be the UDC in a VOtable with this line:

       <description>My Eliptical (E0) galaxies</description>
       <field ucd="..." datatype="character*" name="Galaxy name">
            ...........

     ??

In this case I am not sure it it would be required an UDC of It would  
more useful a line with
<PARAM ucd="gal.sp" dataype="char" value="Elliptical">

Any casee I aggre that there is a problem in how the "value" is  
spelling (Elliptical, E0,....) that would difficult any direct  
search, I think that it is a un-soluble problem: Each astronomer/VO  
developer etc has their own
preferences (that is great, by the way).... and any machine program  
will have the preferences of its "owner"
etc...

Summing up. If we agree that every possible "field" in a "tag" must  
do their own job, I think that the UCDs definition becomes more  
simple (and in some way most useful)..... I do not know.... but maybe  
asked to each UCDs which range of values they my have would be  
useful....


Now, for practical issues :)
I think that most of the discussion has been focus in the UCD  
"length": Or, UCD words-like vs. UCD-sentence-like. Here comes My  
suggestion.

May be we can began in an atomized way:
    1- Are all the "1st-atoms" in the list valid? (or it is needed  
more?, or less?)
    2- Are the present words that contain two atoms valid?
            .........

In this case, I think, most of the present discussion would be  
related with the lower levels (words with many atoms), and whatever  
the final result we will have at least a list of really valid words :)


     cheers


         Miguel





From Hessman at Astro.physik.Uni-Goettingen.DE  Thu Jun  2 05:41:23 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Thu, 2 Jun 2005 14:41:23 +0200
Subject: T0 : extensions to em, obs, spect, instr - FINAL COMMENT?
In-Reply-To: <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DEFA7.197122FF@astro.u-strasbg.fr> <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
Message-ID: <3921b09bd80d7ddf22e0e6f24b9a7103@Astro.physik.Uni-Goettingen.DE>


On 1 Jun 2005, at 8:03 pm, Rob Seaman wrote:

> On Jun 1, 2005, at 10:25 AM, Sebastien Derriere wrote:
>
>> <src>
>>     <param ucd="meta.id" value="NGC12345" />
>>     <param ucd="src.class" value="Galaxy" />
>>     <param ucd="src.morph.type" value="Sc" />
>> </src>
>
> This is similar to how I was envisioning VOEvent usage.  Rick should  
> speak up (on whatever mailing list :-) if he sees this much  
> differently.  That said, I question whether these specific UCDs will  
> survive our discussions.

This is fine for VOTable, where "value" is really rather diffuse  
scientifically ("the thing in the table row and column with some
scientific meaning given by the ucd") and where the main purpose is to  
recreate the non-astronomical thing "table" into an
astronomical unit which can be processed.  You really don't care if you  
have

	<param ucd="src.class" value="Galaxy"/>
or
	<param ucd="src.class" value="galaxy"/>
or
	<param ucd="src.class" value="island universe"/>

As soon as you get away from tables, things become more complex, since  
the "value" can - and SHOULD - take on
more meaning.   In VOEvent, the point is NOT to have a string which  
someone used to randomly label an object (the VOTable
equivalent task), but to tell stupid computers that the object is  
something in particular.  With

	<param ucd="src.class" value="Galaxy"/>

there's no way to know if the class is "galaxies in general" or even  
"The Milky Way" unless the VO has an official
dictionary saying that the "value" of "src.class" for galaxies in  
general should be "Galaxy" (a poor choice if you ask
me, but...).  Thus, I personally find the present model good for random  
information (non-classification tasks) but extremely bad
for particular information (classification tasks).

If the only way to express "spiral galaxy" is to use "src.class" =  
"Galaxy" and "src.morph" = "SC", then someone (i.e.
a programmer) with have to deal with the fact that "src.morph" - a  
concept used for zillions of other astronomical
objects not related to galaxies - may or may not be applicable to the  
object in question.  That forces her/him to use
an ontology :-(    While I applaud those willing to tackle such, it'll  
be a long while until we have one which can be
used in real applications.  And all of this work simply because we  
don't have "src.galaxies.spiral" (note I've dropped
"class" to reduce the number of hierarchies).

> We think we have a pretty good idea now what a "spiral galaxy" is.  It  
> wasn't so very long ago that we hadn't the slightest idea of its true  
> nature.  As long as astronomy is a living subject, there will be names  
> with fluid meanings.

True enough, but the point is we DO know what a "spiral galaxy" is  
right now, we already know of billions of them, and survey
projects need NOW to be able to tell us that they've found one.

Let's worry about the concepts we haven't developed when they appear.


On 2 Jun 2005, at 10:48 am, Miguel Cervi?o wrote:

> In this case I am not sure it it would be required an UDC of It would  
> more useful a line with
> <PARAM ucd="gal.sp" dataype="char" value="Elliptical">
>
> Any casee I aggre that there is a problem in how the "value" is  
> spelling (Elliptical, E0,....) that would difficult any direct search,  
> I think that it is a un-soluble problem: Each astronomer/VO developer  
> etc has their own
> preferences (that is great, by the way).... and any machine program  
> will have the preferences of its "owner"
> etc...

NO!!!   The VO apps of the future will  "know" how to express the  
concept of "elliptical galaxy" in a common fashion (otherwise they're  
too
stupid to be able to talk to each other about them) but the human user  
see's what the human equivalent is supposed to
be in terms s/he WANTS to see (e.g. in english, in french, or for a 3rd  
grade student in Malaysia,...).   The ONLY question now
is how difficult we want to make the life of VO programmers - nothing  
else!    An astronomer who refuses to accept that
somewhere buried in the VO software architecture there's a  
"src.galaxies.elliptical" or a "src.class"="Galaxy" +
"src.morph"="elliptical" instead of the string "elliptische Galaxie"  
simply won't (and shouldn't) use the VO.

Miguel's comment does raise a totally different issue which may explain  
why there's no confluence of ideas: do we want a
VO architecture which is simply a more elegant means of letting a human  
user deal with complex sets of VO data and
VO apps - in which case "Elliptical" will be fine to describe the  
galaxy since a human in there to interpret what it means - or
do we want to use things like UCD's to permit computers to deal with  
this information without ANY human involved
IN PRINCIPLE (e.g. automatic classification of zillions of LSST sources  
triggering robotic observations).  My feeling is that
the work on VOTable and UCD has been based largely on the former and I  
know that the work on VOEvent is largely based
on the latter.  Yes, this is oversimplified, but it would help to  
explain why we don't seem to be talking about the same thing......

Don't get me wrong - I think UCD's in their present form are great -  
but if this list is just about last-minute refining of the
present list using the present limited set of officially allowed  
concepts, then please remove me so you won't have to be bothered by
my rantings anymore.  I'm sure you'll do a great job and we'll  
certainly use UCDs all over the place, but I'm then personally
interested in something else and would then try to find a IVOA group  
doing the next - and unfortunately officially defined as
different - task of teaching computers a minimal set of concepts needed  
to do automatic processing of VO information NOW
without the use of ontologies (we just barely got our GRB colleagues to  
accept XML - wait until I tell them they're going to have to use OWL!).  
  Seems
a shame, but then the IVOA has historically been a pretty heterogeneous  
bunch and so yet another group doing some of the same
work using a totally different approach won't be noticed.   Computers  
are fast, databases can be linked, cross-references can be made,  
translators and parsers can be written, generations of students need to  
be given work, .... :-)

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 andrea.preitemartinez at rm.iasf.cnr.it  Thu Jun  2 06:24:38 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Thu,  2 Jun 2005 15:24:38 +0200
Subject: Sci-Board-3
Message-ID: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>

***Sci-Board-3

Dear all,

I think it is time to remind you what the goal of the Sci-Board on a short
time-scale is:
we (eg: IVOA project and people) urgently need a stabilized version of the
UCD vocabulary.

Adds-on are possible in this phase, but in the short term (<1 month) the
main job is to get a basic ?kernel? of ?stable? words that can be
immediately used by data providers. The starting point is the list of words
already available as an IVOA-WD.

If the present version of the list is too much ?table/catalogue?-like
for somebody's tastes, I remind that at CDS (just to quote one of the data
centers) about 150.000 columns wait for a ?stable? ucd-vocabulary in
order to be treated (e.g.: to have an ucd assigned to them), their number
growing at the rate of 1000 per month.

What I mean is: they are already there. This is why at the joint UCD-VOEvent
session we decided to postpone the discussion on <UCDs and the VOEvent
vocabulary> (to be precise, on the <hypothesis> schema only, because actual
UCDs are usable in other Event contexts/schemas) : to gather a real working
vocabulary on events and associated hypothesis.

The situation is not very simple : on one hand we have now a <standard> way
(a <precise> way) to define <fuzzy>-enough UCDs, on the other hand we need
to have within the IVOA community   (DM, Theory, VOEvent, ..) the
possibility to express the same concepts using the same words. And, why
not, using the same syntax already used for the UCDs.

A way out is to be rigorous and <open> at the same time.

I remind you that in the actual version of UCDs we do have <objects>: in the
sense that we do (we can) distinguish between the temperature of a star (its
effective temperature) and that of a detector or instrument. We do
distinguish between the name/identifier of an astronomical object and that
of a telescope, instrument, or even a fov. In all these cases we use
ucd-words describing <objects> as <qualifiers>.

While today an UCD like :  src.galaxies.S0   would be meaningless,
meta.id;src.galaxies.S0   would not. In the UCD context  src.galaxies.S0 is
only a secondary word, but in another context it could be used as primary.

We can (I would say: we have to) work in this direction.

I totally agree with Rick's final statement on ontologies: we need standards
NOW, not in 30-40 man-years time!

Best regards

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From seaman at noao.edu  Thu Jun  2 08:18:42 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 2 Jun 2005 08:18:42 -0700
Subject: Sci-Board-3
In-Reply-To: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
Message-ID: <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>

This is why I prefer separate threads on a single mailing list to  
attempts to segregate discussions up front into conceptually  
different mailing lists.  There appear to be at least four different  
places to talk about UCDs/Ontologies.  Either the members of those  
mailing lists overlap strongly - or they don't.  In the former case,  
why have separate lists?  In the latter case, some folks miss large  
parts of the conversation.  In either case, administrivia messages  
proliferate trying to keep everybody in line.  Oh, well...shall we  
take the more conceptual discussions over to ucd-tech?

On Jun 2, 2005, at 6:24 AM, Andrea Preite Martinez wrote:

> we (eg: IVOA project and people) urgently need a stabilized version  
> of the UCD vocabulary.

Fine.  (Although one might read discussion to date as an expression  
of a sense that this goal will not be trivial.)  If the ucd-sci board  
is to focus exclusively on generating vocabulary, what we need is a  
structured discussion, not a free-for-all.  Is there a specific  
action item on the table?  "Provide vocabulary" ain't gonna cut it.

> The starting point is the list of words already available as an  
> IVOA-WD.

Reminder where that is?

> we decided to postpone the discussion on <UCDs and the VOEvent

Define "postpone".  The VOEvent WG certainly intends that its  
prototypes be fast-tracked.

> I remind you that in the actual version of UCDs we do have  
> <objects>: in the sense that we do (we can) distinguish between the  
> temperature of a star (its effective temperature) and that of a  
> detector or instrument. We do distinguish between the name/ 
> identifier of an astronomical object and that of a telescope,  
> instrument, or even a fov. In all these cases we use ucd-words  
> describing <objects> as <qualifiers>.

It would be useful to those of us now joining the UCD conversation  
from outside to see such examples expressed in in their full and gory  
detail.

> I totally agree with Rick's final statement on ontologies: we need  
> standards NOW, not in 30-40 man-years time!

Rather, we need prototype solutions now.  A standard itself cannot be  
reached via a short-cut.  The ontologies will inevitably form the  
long term standards.  UCDs and other semantic constructs will  
inevitably ultimately flow from the formalized ontologies.  Astronomy  
is the oldest of the sciences - we have all the time in the world for  
these academic pursuits.  In the mean time, pilot projects will  
produce prototype solutions that will serve the community's needs for  
a season before being supplanted by better technology layered on our  
always evolving understanding of the issues.

Rob Seaman
NOAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050602/1cd966c9/attachment.html>

From mleoni at eso.org  Thu Jun  2 08:43:03 2005
From: mleoni at eso.org (Marco C. Leoni)
Date: Thu, 02 Jun 2005 17:43:03 +0200
Subject: Sci-Board-3
In-Reply-To: <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
Message-ID: <429F2907.1010201@eso.org>

Rob Seaman wrote:

> [...]
>
>> The starting point is the list of words already available as an IVOA-WD.
>
>
> Reminder where that is?


It should be this one:
    http://www.ivoa.net/Documents/latest/UCDlist.html


Cheers,
    Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050602/d91deebf/attachment.html>

From andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun  3 01:11:29 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri,  3 Jun 2005 10:11:29 +0200
Subject: Sci-Board-3
In-Reply-To: <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
Message-ID: <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>

Quoting Rob Seaman <seaman at noao.edu>:

> On Jun 2, 2005, at 6:24 AM, Andrea Preite Martinez wrote:
>
>> we (eg: IVOA project and people) urgently need a stabilized version  
>> of the UCD vocabulary.
>
> Fine.  (Although one might read discussion to date as an expression
> of a sense that this goal will not be trivial.)  If the ucd-sci board
> is to focus exclusively on generating vocabulary, what we need is a
> structured discussion, not a free-for-all.  Is there a specific
> action item on the table?  "Provide vocabulary" ain't gonna cut it.

Of course there is. You were probably late in joining the sci-board, and you
missed it. The list was created <en route>, so the first messages were
inserted in the list by hand. For reasons that I do not understand the
message I'm talking about (Sci-Board-1) is there as subject, but not as
content. I copy it here for you and those that joined late our list.

==========================Sci-Board-1===================================
Dear colleagues,

this first message is for setting up our roadmap and organizing the Board
and our work on the UCD-vocabulary..

A. Roadmap.
Our goal is very simple: we need to stabilize (which means adding, deleting,
transforming ) the present draft list of  ucd-words, that you can find at

http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt  (just the list)
http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCDlist-20050429.pdf (the WD
document)

in order to (i) reach  consensus, and (ii) be able to promote the list (and
the associated document) to the level of IVOA Proposed Recommendation as
soon as possible (within June).

B. The Board
1. Duration.
There will be a Sci-Board as long as UCDs will be in use in the VO, in order
to maintain the vocabulary. The mission of the board is described in the
main UCD document, that you can find at

http://www.ivoa.net/Documents/latest/UCD.html

now under minor revisions as suggested during the Exec Meeting in Kyoto.
It is possible that in the future the Exec could change the mission to suit
new needs of the VO.

2. Participation.
Participation is on a voluntary basis. Colleagues can ask the chair of the
Board to be inserted in (or deleted from) the mailing list of the Board,
and to work for a specific task (see below).

3. Chair
For the transition period required to set up the Board and let it run, I
will act as chair person of the Board (by the way,  setting up the Board
and upgrading the present list of UCD-words to the level of IVOA PR is a
formal action for the chairman of the UCD-WG). I propose to go for an
election of the chairman of the Board in a month from now.

C. Organization
1. What (Tasks)
Time is very short, at least for this first phase of our work. I propose
then to define a number of key tasks and form task-groups on different
aspects of the vocabulary. The most urgent cases were well pinned down
during the last InterOp Meeting. My first draft proposal is to organize our
work around the following tasks:

T1: the "velocity" and the resolution(s) problems
T2: theory and simulations (sim ?)
T3: at/mol physics
T4: curation (humans, organizations) and other "meta"-likes
T5: flux (total, net, backgr. and various "flux densities") and time (period
of, instant of)
T6: solar system
Txx : ??

T0: Coordination, general issues, not included in the above Ts.

Like the Board, tasks are not "closed". The discussion is open ("plenary")
and contributions are welcome from every member of the Board. It will help
people with an analytical mind (like mine!) to see "T5" appear in the
subject of your message, if dealing with "net flux" or mid-time of
exposure.

We need a coordinator for each task, with the responsibility to make a final
proposal to the Board.
There is nothing formal in the following list of people, I'm just asking
them to pay more attention to the discussion relevant to the corresponding
task, and summarize the discussion to the Board in due time.
Making use of the list of members (as of today) I propose the following
coordinators:

T0        General                Andrea
T1        Velocity/resolution        Alberto Micol
T2        Theory/simulations        Volunteer(?)
T3        At/Mol physics        Marie-Lise Dubernet
T4        Meta                        S?bastien D.
T5        flux/time                Jonathan MD
T6        Solar system                Pierre Didelon


2. How
Through the Board's mailing list. Always "reply to all". The chair will
record all messages.
In this first phase of our work time is very short. So please answer within
the given deadlines. We won't wait for late messages.

3. When
FIRST ACTION: please comment on the above organization/rules/tasks within
Thursday the 2nd of June.

This message is sent (for the last time) also to the wider interop at ivoa.net
community to ask the laziest to join in.

Best regards

Andrea
============== end of Sci-Board-1=======================================

>> we decided to postpone the discussion on <UCDs and the VOEvent
> Define "postpone".  The VOEvent WG certainly intends that its
> prototypes be fast-tracked.

As above, I copy for you my second message Sci-Board-2.

======================Sci-Board-2=========================================
Dear colleagues,

I see from the first answers to Sci-Board-1 that thinks are not clear for
everybody:

  1. Please, REPLY TO ALL the members of the Board, not to the ucd-list nor
to my address. Remember that not all the members of the Board are also
members of the UCD-WG. You can "cc" to your pet-list, I don't care, but
make sure that at least the Board can read your message.

2. When suggesting new UCD-words, please ask yourself which kind of
"quantity" you want to describe or, if not a quantity, which kind of
attribute (qualifier/modifier).
By the way, our mission is to stabilize and maintain a list of "words", NOT
a list of UCDs.
Syntax will take care of how to build UCDs, based on the classification of
the word (e.g. P/Q/S syntactic flag).

3. For what VOEvent is concerned, please have a look at the conclusions of
the joint session UCD/VOEvent at
http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2005UCD

We will discuss Event vocabulary at the end of the year, when a first
bottom-up list of terms will be available.

4. Sorry, there isn't such a thing as Solar System UCDs. I remind you that
the IVOA (Proposed)  Recommendation on UCDs explicitly forbids UCDs like
"star", "galaxy", or "Sun", "my_pet_object", and so on.
On the contrary, qualifiers like "stellar", "galactic", "solar" can be valid
atoms.

Regards

Andrea
=======================end of Sci-Board-2=================================

>> I remind you that in the actual version of UCDs we do have  
>> <objects>: in the sense that we do (we can) distinguish between the  
>> temperature of a star (its effective temperature) and that of a  
>> detector or instrument. We do distinguish between the name/ 
>> identifier of an astronomical object and that of a telescope,  
>> instrument, or even a fov. In all these cases we use ucd-words  
>> describing <objects> as <qualifiers>.
>
> It would be useful to those of us now joining the UCD conversation
> from outside to see such examples expressed in in their full and gory
> detail.

You can use the UCD builder on line at:

http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd

>> I totally agree with Rick's final statement on ontologies: we need  
>> standards NOW, not in 30-40 man-years time!
>
> Rather, we need prototype solutions now.
I don't see why you say <Rather>. There is not contradiction. I'm talking
about STANDARDS NOW. STANDARDS LATER
> ... The ontologies will inevitably form the long term standards...
need prototyping now.

> Rob Seaman
> NOAO

Andrea





From mcs at iaa.es  Mon Jun  6 10:22:29 2005
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Mon, 6 Jun 2005 19:22:29 +0200
Subject: T0: UCDs for "em"
In-Reply-To: <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu> <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
Message-ID: <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>

Dear all,

I just revised the "em" UDCs and I post here some suggestions.
I had just rewriten the whole "Q" list and added some entries, taken  
from
the 27-Feb 2005 Working Draft on IVOA SED Data Model (marked with *).

For clarity I has put together "Q" UCDs and "S" UCDs,
the latter writen in increasing energy order.

First I center in "Q" UCDs, and I propose to keep:

Q|em.energy        |Energy value in the em frame
Q|em.freq         |Frequency value in the em frame
Q|em.wavenumber        |Wavenumber value in the em frame
Q|em.wl         |Wavelength value in the em frame

- Include:

Q|em.wl.air*         |Wavelength value in the em frame in air frame

      somewhere it should be established default is vacuum?
      In most optical observation default is air and
      in UV vacuum as example, but SLOAN data release
      gives optical wl en vacuum...

- Other suggestions in IVOA SED DM WD:

Q|em.veloc*        |Apparent radial velocity
Q|em.veloc.radio*    |radio velocity
Q|em.veloc.optical*    |optical velocity
Q|em.veloc.beta*        |velocity/cr

- Changue from Q to E?

Q|em.wl.central     |Central wavelength
Q|em.wl.effective     |Effective wavelength

   I think that this UDCs does not corresponds to the EM but more
   important for photometric characterizations. I do not know



About the characterization of the em spectrum by their energy ranges  
as proposed at:

http://www.ivoa.net/internal/IVOA/IvoaUCD/NoteEMSpectrum-20040520.html

I completely agree :) however, for clarity purpose and hogenity
the UDCs I would suggest the following changues:

em.IR.K -->  em.IR.2-3um
em.IR.H -->  em.IR1500-2000nm
em.IR.J -->  em.IR1000-1500nm

em.opt.I -->  em.opt.750-1000nm
em.opt.R -->  em.opt.600-750nm
em.opt.V -->  em.opt.500-600nm
em.opt.B -->  em.opt.400-500nm
em.opt.U -->  em.opt.300-400nm

so there no will be confusion with fotometry bands (and machines  
always will found
      em.string.(number - number unit)
that, I do not know, but may be is more easier)


Analogously, for high energy:

em.X-ray.soft --> em.X.120-2000eV
em.X-ray.medium --> em.X.2-12keV
em.X-ray.hard --> em.X.12-120keV

em.gamma.soft --> em.gamma.120-500keV
em.gamma.hard --> em.gamma.500-1000keV
                   em.gamma.1-20MeV
                   em.VHgamma  (Very-high gamma: 20Mev-10GeV)
                   em.VHgamma.20-100MeV
                   em.VHgamma.100-1000MeV
                   em.VHgamma.1-10GeV
                   em.UHgamma  (Ultra high gamma rays, cosmic ray- 
domain)
                   em.UHgama.10-30GeV
                   em.UHgama.30+GeV

Here, the definitions for gamma-ray is a bit lossy, and I have not  
found a clear consensus between very-high and ultra-high gamma in the  
literature.... :(


Finally, I think that the inclusion of em.line would be useful, but  
only for a very sort list of lines (like there is irregular verbs in  
any language that, by the way,  corresponds to the most commonly used  
verbs)
so (with a strong background of visual astronomy) I would agree with
Hydrogen lines, but I do think that em.line.OIII should be  
depreciated (there is several OIII lines!, and if OIII is here, by  
not, O I, or
H+K Ca II etc...? so I propose depreciate em.line.OIII ...

so the list would be:

S    |em.line.HI     |21cm hydrogen line
S    |em.line.Brgamma     |Bracket gamma line
S    |em.line.Halpha     |H-alpha line
S    |em.line.Hbeta     |H-beta line
S    |em.line.Hgamma     |H-gamma line

Depreciated:

S    |em.line.OIII     |[OIII] line


Cheers

     Miguel



From jcm at head.cfa.harvard.edu  Thu Jun  9 11:44:45 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:44:45 -0400 (EDT)
Subject: SciBoard
Message-ID: <200506091844.j59IijxU002921@urania.cfa.harvard.edu>


Hi UCD board,
 Sorry, I've been on travel and then sick. I've tried to catch up
on the emails.
 About the solar system UCDs, Seb.  said:


>   Hi Jonathan,
> 
>   There might be a slight misunderstanding on this.
> The planetary system community has worked on their needs
> to express the quantities they are measuring in their field
> with proper UCDs. You can see the result of this reflexion 
> here:
> http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html

>   I think these suggestions are worth examining, and they seem


I have no major problems with this list, I was talking about
suggestions that were raised for object types like asteroid, comet,
etc.

> quite mature: why not taking them into account for the PR.

I had assumed in Kyoto that we would go for the PR as is, on the
basis that the current list is not too bad, and then use the
board to make modifications shortly afterwards. I think everyone 
is happy with the syntax and the methodology, while we can spend
ages arguing about the actual list. It sounds like we want
to add lots of things to the list before going to PR, which I worry
will unnecessarily delay the PR.  See Andrea's message of Jun 3 -
my view is that we should look for any things in the current list
that are BAD, and get rid of them; there are many things
that are MISSING, but we can easily add them later. The list will
be stable in the sense that valid UCDs should rarely become invalid,
but it will never be stable in the sense that it will always grow.

Which doesn't mean the board should delay discussing additions
to the list (just that I don't think we have to agree on them
before approving the PR). I'll give my comments on the planetary list below.

>   I am less confident that we can incorporate in the PR all the
> astronomical object types/phenomenons that were discussed
> for VOEvent (is this what you call "semantics for astronomical
> objects"?).

Yes, particularly the tree of object types: galaxy.Seyfert2 etc.
I'm not so worried about the phenomena (outburst, glitch, etc..),
and I thought Rick's list was quite good. But I've heard you and
others say that you are worried about putting the object types in UCD,
whereas it's becoming clear that the object types do need to
be somewhere in the VO fairly soon.

OK, now for the particular UCDs:

 * meta.id.(x,y,z)     
     Hmm. I thought meta.id was more for names, how about arith.cpt.x, etc.?

 * obs.atm  instead of obs.air    I agree
 
 * obs.atm.refraction, phys.refraction - one the angle, the other the index.
   I guess I agree, but maybe obs.atm.refractAngle and phys.refractIndex is more explicit?

 * obs.elongation, obs.phaseAng  - these are both angles.
 How about   pos.angle.elongation, pos.angle.phase ?

 * pos.az.azi and pos.eq.ha
 I agree.   

 * pos.brc.*    In STC and I think in WCS-III the word 'topocentric' is being used
               for some of this, but body is fine too. I'd prefer pos.body.* which I find
               more obvious.

 * pos.eop.*  I like, although as we become more active on other worlds isn't it likely
    that we'll be needing similar parameters for Mars, etc.? But maybe it's fine for now.
  
 * pos.precess   Perhaps pos.eq.precess if we are talking specifically about
                 the effect of terrestrial precession on coordinate systems
                (as opposed to the precession of the pole of (433)Eros or something)

 * phys.magAbs.G   Isn't there an H as well? My asteroid friends keep talking about H....

 * src.orbital.*, src.veloc.* I agree, with the possible exception of src.veloc.tan.
   Perhaps 'transverse' rather than 'tangential' is more clear?

 - Jonathan


From jcm at head.cfa.harvard.edu  Thu Jun  9 11:46:05 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:46:05 -0400 (EDT)
Subject: T0 : extensions to em, obs, spect, instr
Message-ID: <200506091846.j59Ik5kY003131@urania.cfa.harvard.edu>


UCD comments 2: Rick's suggestions

Hi UCD board,

Rick Hessman proposed a number of UCDs (May 30) and I wanted to comment on them.

One was
 spect.cont    spectral continuum

I endorse adding this, it's very useful for my own data.


Rick suggested either
 em.grav-wave
 em.neutrino
with 'em' redefined as 'emission', or else
 phys.grav-wave
 phys.particle.{cosmic-ray,neutrino}

I like both. If you are comparing the light curves of the
SN1987a neutrino flux and the optical flux, it makes sense
to me to have 
  phot.flux;em.neutrino
even though 'photometry' strictly doesn't apply to non-photons, or
maybe better
  phys.flux;em.neutrino
but I think that
  phys.flux;phys.particle.neutrino
is more generalizable, so I suggest we go with that.

He also proposed an obs.calib tree to describe many different kinds
of observation. I feel many of these are better handled with secondary
words, for instance 
  obs.calib;phot.flux     instead of obs.calib.flux
I know that some people feel excessive use of secondary words
means that a simple search returns too many false positives - but I am
convinced that alternative is an explosion of the vocabulary that
will overwhelm us, and that a mild increase in search query sophistication
will solve the perceived problem.

We already have instr.calib, but many calibrations are not
just for the instrument per se but for the observation as a whole (e.g.
for ground based photometric calibrations it's usually not the
instrument but the sky that is changing and needs calibration).
So I think obs.calib is a better UCD.

So here's my proposal for Rick's list, in which proposed new UCDs
are marked by a *  (sort of the paleolinguistics convention of
marking hypothetical word forms with a *).

 Rick                                   Jonathan 
 phys.grav-wave/em.grav-wave            *phys.wave.gravitational
 phys.particle.neutrino/em.neutrino     *phys.particle.neutrino

(note that phys.wave is a good subtree for other things like
phys.wave.Alfven or phys.wave.dispersionRrelation)

 instr.calib                 *obs.calib  [Calibration observation]
 phot.calib                   obs.image;*obs.calib;phot.flux
       [It's an image; it's for calibration; what are we calibrating - flux.]
                              spect;*obs.calib;phot.flux
       [or, it's a spectrum...]
 obs.calib.dome-flat          obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
       [We're calibrating the flatness of the detector; we're using the dome to do it]
 obs.calib.flux               obs.image;*obs.calib;phot.flux
 obs.calib.freq               spect;*obs.calib;em.freq
       [It's a spectrum; it's for calibration; we're calibrating freq]
 obs.calib.guide-star         meta.id;*obs.calib;*pos.astrometry
       [If this is the name of the guide star used..]
 obs.calib.phot    [What's the difference with obs.calib.flux?]
 obs.calib.pos                obs.image;*obs.calib;*pos.astrometry  (?)
 obs.calib.sky-flat           obs.image;obs.calib;*instr.det.flat
 obs.calib.slit-mask          *instr.spect.slit
 obs.calib.spect              spect;*obs.calib;em.wl
      [If you mean by this an arc spectrum; what diff from obs.calib.wl?]
 obs.calib.veloc              spect;*obs.calib;src.veloc
 obs.calib.wl                 spect;*obs.calib;em.wl

 phot.calib.flux              [same as obs.calib.flux?]
 phot.calib.mag               *obs.calib;em.opt.B   (etc.)
 pos.calib                    *obs.calib;pos
 spect.calib                  spect;*obs.calib
 spect.calib.wl               spect;*obs.calib;em.wl
 spect.calib.freq             spect;*obs.calib;em.freq

Rick's next message on May 30 proposed an 'event' tree.
All his events are things that happen to sources, so we
might want to make this a src.event subtree.
Also, it's "occultation", not "occulation". Otherwise
I like it. But as we agreed in Kyoto, let's wait a while on this subject.


 - Jonathan


From jcm at head.cfa.harvard.edu  Thu Jun  9 11:47:21 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:47:21 -0400 (EDT)
Subject: T0 : extensions to em, obs, spect, instr
Message-ID: <200506091847.j59IlLcR003225@urania.cfa.harvard.edu>


UCD comments 3: the standard vocabulary for the universe

Rick Hessman said:
: 
: Sebastien Derriere said:
: > Solar System UCDs (really Astronomical Object UCDs):
: > they will not be UCDs per the PR. But IVOA may need such a list
: > and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
: > group doesn't want to take that work on, the DM group should
: > probably do it. I think either group could do it, provided we
: > keep the distinction between the two lists (UCDs, as semantics
: > for astronomical non-object concepts, and the other list,
: > as semantics for astronomical objects).
: 


Actually, it was me who said this, Sebastien's message quoted me.

At the time I wrote this, I actually agreed with  Rick; I was trying to
find a compromise approach since it seemed that Sebastien (and I think
Patricio and other originators of the UCDs) do want to make such a
distinction. Someone is going to have to list object-classification
concepts. I would prefer it was the UCD board, but if not, it'll have to
be the DM group or the vo-semantics folks.

However, after the discussion I take a more nuanced (i.e. confused) position.

I do now think there is some real justification for a separate list using the
 ucd = src.class  value = galaxy.spiral
approach: the other approach with
 ucd = src.class.galaxy.spiral 
might be ok, but very quickly we want
 ucd = src.class.galaxy.spiral.SB(r)cd...
 ucd = src.class.star.binary.O7e+PNe/LMXB
 ucd = src.class.comet.sungrazer
 ucd = src.class.body.feature.rupes

In other words, 'galaxy' is not just a concept, it's a classification,
and the coarsest bin in a complicated tree of classifications. 
(Sebastien made a distinction between classification and morphological
type which I don't think is a real one in practice; morph type, variable
star class, spectral type, etc. are all part of the classification of
what this object is).
I don't think the classification's really quite the same as
distinguishing between radial velocity and some other kind of velocity.
And as my examples above show, once you get down to the detailed
classification the UCD syntax doesn't actually make a good match. Rick
will probably argue that it still makes sense to have UCDs which go down
as far as the less detailed level (star.binary etc) and I could buy that.

Like Rick, I focus on the data-header applications more than the
Vizier-catalog applications, and I take it as a clue that in 
FITS headers, "spiral galaxy" is always a keyword value, not a
keyword name. This suggested to me that in fact UCD may not 
be the right controlled vocab for this set of concepts.

But then Sebastien reminded us of the 'concept/property' way of looking
at UCDs, where the question becomes: are there specific properties we
need to describe? To be more specific:

      radial.velocity;src.class.galaxy

would be the radial velocity of a galaxy. Does having this add anything to
just saying

       radial.velocity;src

- do you really care that it's a galaxy and not a star.
This leads to a data model question: what properties do a galaxy and a star
*not* share? For example:
       object.galaxy.spiral.HolmbergRadius
       object.star.convectionParameter

This, to my mind, is the correct role of object types in UCD and argues for a tree
of this kind. Right now, these kind of properties go in the phys or src
list without the 'object.<particularkind>.' prefix.

 - Jonathan








 - Jonathan


From jcm at head.cfa.harvard.edu  Thu Jun  9 11:47:39 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:47:39 -0400 (EDT)
Subject: T0: basic UCD tree
Message-ID: <200506091847.j59IldO1003229@urania.cfa.harvard.edu>


* UCD comments 4: overall UCD tree

Hi UCD board,

I looked again at the UCD primary concepts and tried to group them.
The one I am most worried about is "spect".



time,pos,em,phot  Fundamental astro concepts, fine. 

obs, phys  Also good basic concepts

arith    a good basic tree, although "math" might be better.
stat     Maybe should be under arith?

src      Another fundamental concept, although as usual I would argue for 
         a distinction between "src" (2D on the sky, results of observation) and
         "object" (real 3D thing in space).

instr    Fairly fundamental but one could argue should be under obs

spect    I worry about spect - this is a kind of data.
         If spect, why not image? I predict a few years from now
         we will have to change spec and instr.image to data.spect, data.image, etc.

Despite this worry, I am willing to endorse the current list for the PR.



 - Jonathan


From andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun 10 02:00:19 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri, 10 Jun 2005 11:00:19 +0200
Subject: T0: UCDs for "em"
In-Reply-To: <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
	<20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
	<AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
Message-ID: <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>

Miguel Cervino wrote:

> First I center in "Q" UCDs, and I propose to keep:
>
> Q|em.energy        |Energy value in the em frame
> Q|em.freq         |Frequency value in the em frame
> Q|em.wavenumber        |Wavenumber value in the em frame
> Q|em.wl         |Wavelength value in the em frame

The point is that:
1. It would be clearer to use the em branch just to describe the
electro-magnetic axis (radio, ir,opt,...,line,..) and move energy, freq, wl
to the phys branch.
2. We now have phys.energy and em.energy
If you ask the assign tool
http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd
the word energy is translated always into phys.energy : correct.
You only get em.energy if you type photon energy : correct too.
But we are describing the same quantity with two ucd-words!


> Q|em.wl.air*         |Wavelength value in the em frame in air frame
>
>       somewhere it should be established default is vacuum?
>       In most optical observation default is air and
>       in UV vacuum as example, but SLOAN data release
>       gives optical wl en vacuum...
yes, things are complicated: you often find <laboratory wl> which, I
suspect, are wl.air in the optical and, obviously, wl.vacuum in the UV!

> Q|em.veloc*        |Apparent radial velocity
> Q|em.veloc.radio*    |radio velocity
> Q|em.veloc.optical*    |optical velocity
> Q|em.veloc.beta*        |velocity/cr
somebody proposed already velocRadio, velocOpt. I ask him/her to re-submit
that proposal

>
> - Change from Q to E:
> Q|em.wl.central     |Central wavelength
> Q|em.wl.effective     |Effective wavelength
Yes, with the flag set to Q and a description like: central wl of Halpha
you'll get only wl.central .

> ... for clarity purpose and hogenity
> the UDCs I would suggest the following changues:
>
> em.IR.K -->  em.IR.2-3um
> em.IR.H -->  em.IR1500-2000nm
> em.IR.J -->  em.IR1000-1500nm
>
> em.opt.I -->  em.opt.750-1000nm
> em.opt.R -->  em.opt.600-750nm
> em.opt.V -->  em.opt.500-600nm
> em.opt.B -->  em.opt.400-500nm
> em.opt.U -->  em.opt.300-400nm
>
> so there no will be confusion with fotometry bands
may be we should go this way, because the names of those bands can be
misleading.
In the case of x- and gamma-rays though there is no confusion, so I would
keep the existing names...

> Finally, I think that the inclusion of em.line would be useful, but
> only for a very sort list of lines so ... I would agree with
> Hydrogen lines, but I do think that em.line.OIII should be
> depreciated (there is several OIII lines!, and if OIII is here, by
> not, O I, or H+K Ca II etc...? so I propose depreciate em.line.OIII ...
the reason for the inclusion of the OIII line is that the doublet 4959+5007
is one of the strongest lines in emission-line objects (second only to
Halpha in most cases). There are surveys in Halpha/beta and in OIII, not in
OI.
My point is: today em.line.OIII is used/useful. The day we'll find other
lines useful we'll propose their inclusion.
By the way: em.line.XXX is not a quantity: it is a qualifier of some other
quantity, e.g. intensity, flux, etc..

Cheers

Andrea



From Hessman at Astro.physik.Uni-Goettingen.DE  Fri Jun 10 03:11:08 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Fri, 10 Jun 2005 12:11:08 +0200
Subject: T0: basic UCD tree
In-Reply-To: <200506091847.j59IldO1003229@urania.cfa.harvard.edu>
References: <200506091847.j59IldO1003229@urania.cfa.harvard.edu>
Message-ID: <25d39d6a9dc407818d6d6b228334efae@Astro.physik.Uni-Goettingen.DE>


On 9 Jun 2005, at 8:47 pm, Jonathan McDowell wrote:

> arith    a good basic tree, although "math" might be better.
> stat     Maybe should be under arith?

I agree :  math covers arith and stat.		*math.arith    *math.stat

> src      Another fundamental concept, although as usual I would argue  
> for
>          a distinction between "src" (2D on the sky, results of  
> observation) and
>          "object" (real 3D thing in space).

Now, now: don't try to bring "concepts" into the UCD world ;-) !

We have to agree that "src" means "object on the sky" (where the  
definition of "sky" is,
of course, relative to an observer, e.g. a spacecraft), since  
everything that
UCD describes is for observations or observed properties.   Otherwise,  
the whole
"concept" (or, God-forbid, "ontology") discussion comes up again!

Right now, the official UCD description of "src" is "Source" - not very  
helpful.  I suggest
using "Observed source viewed on the sky".

> instr    Fairly fundamental but one could argue should be under obs

No!:  "obs" is an observation thing made with an instrument "inst".  The
focal length of a telescope isn't (in our present sense) an  
observation, but a
property of an instrument and so doesn't at ALL belong to "obs".


> spect    I worry about spect - this is a kind of data.
>          If spect, why not image? I predict a few years from now
>          we will have to change spec and instr.image to data.spect,  
> data.image, etc.

I agree that data.image and data.spec is a much better model, at least  
for observations.  After all, what UCD
often does is to provide generalized "keywords" a la FITS.

On the other hand, the VO theory people might complain that their  
"images" and "spectra" are not really "data".

Sounds like a problem which has to be put off until later.

> But then Sebastien reminded us of the 'concept/property' way of looking
> at UCDs, where the question becomes: are there specific properties we
> need to describe? To be more specific:
>
>       radial.velocity;src.class.galaxy
>
> would be the radial velocity of a galaxy. Does having this add  
> anything to
> just saying
>
>        radial.velocity;src
>
> - do you really care that it's a galaxy and not a star.
> This leads to a data model question: what properties do a galaxy and a  
> star
> *not* share? For example:
>        object.galaxy.spiral.HolmbergRadius
>        object.star.convectionParameter
>
> This, to my mind, is the correct role of object types in UCD and  
> argues for a tree
> of this kind. Right now, these kind of properties go in the phys or src
> list without the 'object.<particularkind>.' prefix.

This can of worms obviously won't be solved using UCD alone: that's why  
I'm pushing the
development of a parallel system which LOOKS like UCD and can be  
treated/
manipulated/concatenated like UCD but addresses this concept/property  
problem.

Simply put: one person's property is another's  concept and vice versa,  
so we need
a system which can be used in both directions.

>  instr.calib                 *obs.calib  [Calibration observation]
>  phot.calib                   obs.image;*obs.calib;phot.flux
>  obs.calib.dome-flat           
> obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
>  obs.calib.flux               obs.image;*obs.calib;phot.flux
>  obs.calib.freq               spect;*obs.calib;em.freq
>  obs.calib.guide-star         meta.id;*obs.calib;*pos.astrometry
>  obs.calib.phot    [What's the difference with obs.calib.flux?]
>  obs.calib.pos                obs.image;*obs.calib;*pos.astrometry  (?)
>  obs.calib.sky-flat           obs.image;obs.calib;*instr.det.flat
>  obs.calib.slit-mask          *instr.spect.slit
>  obs.calib.spect              spect;*obs.calib;em.wl
>  obs.calib.veloc              spect;*obs.calib;src.veloc
>  obs.calib.wl                 spect;*obs.calib;em.wl
>  phot.calib.flux              [same as obs.calib.flux?]
>  phot.calib.mag               *obs.calib;em.opt.B   (etc.)
>  pos.calib                    *obs.calib;pos
>  spect.calib                  spect;*obs.calib
>  spect.calib.wl               spect;*obs.calib;em.wl
>  spect.calib.freq             spect;*obs.calib;em.freq

I basically think this is a very good compromise.  See my other mail
about problems with instr and others.

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 Hessman at Astro.physik.Uni-Goettingen.DE  Fri Jun 10 03:10:44 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Fri, 10 Jun 2005 12:10:44 +0200
Subject: T0: needed last minute changes
Message-ID: <12358f5050de60892fe99445a10af612@Astro.physik.Uni-Goettingen.DE>

After reading Jonathon's comments and re-reading the UCD vocabulary
document again, I realized that we definitely need a few changes:

1.  I first stumbled over
	
		instr.obsty.site.seeing

	Does this mean we need...

		instr.obsty.site.temperature
		instr.obsty.site.humidity

	Seem like a better solution would be to introduce "weather", which  
permits the concatenation

		instr.obsty.site;weather.seeing

	which would open a new handy family

		weather				| meteorological condition
		weather.seeing		| atmospheric image quality
		weather.temp			| local temperature
		weather.humidity		| relative humidity
		weather.dewpoint		| dewpoint temperature
		weather.precipitation	| presence of rain/snow/sleet (boolean?)

	This would be VERY helpful for VOEvent/RTML.   I won't open up a new
	discussion of the uneven choice of contractions (e.g. "temp" instead of
	"temperature" but "wavenumber" instead of "wavenum" - sigh!).

	The topic "space weather" comes into mind as well , but I'll let others
	worry about that.


2. instr

	First of all, a trivial but needed addition:

		instr.det.temp			| temperature of detector

	Next: we presently have "instr.tel.focus" and "instr.fov" which are
	quantities which refer to the "end-users" - no info about how the fov  
or
	focus came into being.  The problem is whether to assign something
	like "focus" to the telescope or to the instrument.  Generally, the
	fov of an instrument (e.g. CCD camera) is very different from that of  
the
	telescope.   Do we then interpret "instr" things as being from a black
	box or from a specific instrument hanging on a telescope?  If it's the  
latter,
	then one may need double entries.  In any case there's a need for  
something
	like

		instr.tel.aperture		| geometric diameter of telescope optics
		instr.tel.area			| (effective?) collecting area of telescope optics
		instr.tel.focallength		| focal length (effective?) of telescope
		instr.tel.fRatio			| ratio of focal length to aperture diameter
		instr.tel.temp			| temperature of telescope

	After all, we already have instr.focus, which is a much less needed  
number than
	the above!

	Sounds to me as if we need to distinguish between generic instr =
	e.g. telescope+filterwheel+CCD or telescope+spectrograph+CCD and
	"device" (can't think of a better name) which could be just the  
instrument part of the
	above (e.g. just the imaging camera or just the spectrograph).

	This would also imply that we need to make tel a primary key, since  
the telescope
	doesn't "belong" to the generic instrument - it's an associated thing.  
  This would solve
	Jonathon's suggested of using

		obs.image;obs.calib;instr.det.flat;instr.tel.dome

	(i.e. using proposed UCDs obs.calib and instr.tel.dome) by permitting

		obs.image;obs.calib;inst.det.flat;tel.dome

	and would permit the differentiation between e.g. instr.focallength and
	tel.focallength.  On the other hand, this means a lot of double  
entries which
	could only be gotten rid of using something like

		instr;optics.focallength
		tel;optics.focallength

	(unfortunately, "opt" is already taken: if we would be using "optical"  
for
	wavelength band and "optics" for optics, there wouldn't be any  
confusion).

	In summary, we need to get rid of

		instr.tel
		instr.tel.focus

	and add

		optics
		optics.focus
		optics.focallength
		optics.aperture
		optics.area
		optics.fRatio
		tel
		tel.dome		(instr.obsty.dome is no good if there are lots of domes at  
the site)
		tel.mount		(e.g. "alt-az", "equatorial", "english",....)


3. PLEASE PLEASE PLEASE change

			src.class.struct		->	src.class.struct.BautzMorgan
			src.class.distance	->	src.class.distance.Abell
			src.class.richness	->	src.class.richness.Abell
			src.spType		->	src.class.spectral.MK
			src.morph.type		->	src.morph.Hubble

		The present definitions associating general class descriptions with  
very particular versions
		of  mostly extragalactic classifications are absolutely insane!   Or,  
the description has to be
		changed to something like

			src.class.struct		| structure classification, e.g. Bautz-Morgan  
galaxy type
			src.class.distance	| distance classification, e.g. Abell galaxy  
cluster
			src.class.richness	| richness classification, e.g. Abell galaxy  
cluster
			src.class.spectral	| spectral classification, e.g. MK spectral class

		which results in a loss of specificity.  There are other spectral  
classes beyond MK stellar,
		other richness classifications other than Abell (e.g. open stellar  
clusters), ....


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 andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun 10 06:00:51 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri, 10 Jun 2005 15:00:51 +0200
Subject: T6 - solar system UCDs
In-Reply-To: <200506091844.j59IijxU002921@urania.cfa.harvard.edu>
References: <200506091844.j59IijxU002921@urania.cfa.harvard.edu>
Message-ID: <20050610150051.dq8plmskejc4cso8@webmail.sic.rm.cnr.it>

Here are my comments on the UCDs proposed by SS people, see:
  http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html

1. meta.id.(x,y,z)   Cartesian component of a vector

In the present list of ucd-words you find
S|pos.cartesian            |Cartesian (rectangular) coordinates
Q|pos.cartesian.x          |Cartesian coordinate along the x-axis
Q|pos.cartesian.y          |Cartesian coordinate along the y-axis
Q|pos.cartesian.z          |Cartesian coordinate along the z-axis

The keywords used for assigning these ucd-words are:
Q|pos.cartesian.(x,y,z)    |(x,y,z) axis coordinate position (U,V,W)
component projected

so that the description: y component of any-V-quantity
leads to the ucd:       any-V-quantity;pos.cartesian.y

where vectorial quantities are, for the moment,

V|phys.electField
V|phys.magField
V|pos.distance
V|pos.pm
V|pos.precess
V|src.veloc

On the other hand, pos.cartesian.x/y/z is a quantity (position on axis
x/y/z), so that the description :

Xpos on detector   yields   pos.cartesian.x;instr.det

My suggestion is: keep pos.cartesian.x/y/z

2. obs.air    suppress
3. replace with: obs.atm
I agree.
But then we need to change air  into atm  in:
S|obs.air              |Atmosphere
Q|obs.air.extinction   |Atmospheric extinction
and
Q|obs.air.mass         |Airmass   could become
Q|obs.airMass

4. obs.atm.refraction / phys.refraction
I support Jonathan suggestion: change into
obs.atm.refractAngle
phys.refractIndex

5. obs.elongation
The elongation of a celestial body its the angular separation from the body
around which it orbits
The UCD for this quantity already exists: pos.angDistance

6. obs.phaseAng
as above

7. pos.az.ha, pos.az.azi, pos.eq.ha
I agree with the proposal.

8. pos.brc.(), pos.earth()
I basically agree. I also totally agree with Jonathan's comment.

9. pos.eop.()
OK

10. pos.precess
No, the description is all right: just <precession>
Equatorial precession  ==> pos.precess;pos.eq
I prefer this, its more flexible.

11. phys.magAbs.G
I'm only aware of the H mag (which is actually a visual mag!!)
I remind you that phys.magAbs has E-flag: if you just need to specify the
phot band, you can say: phys.magAbs;em.opt.V

12. src.orbital.meanMotion
I suppose it is an average angular velocity (src.veloc.ang;stat.mean).
No strong feelings about it.

13. ...veloc...
to be revised (not only in the framwork of SS!!

14. src.veloc.compon
Not in the present list.

Cheers,

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From pdidelon at cea.fr  Fri Jun 10 06:59:33 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Fri, 10 Jun 2005 15:59:33 +0200
Subject: T6 - solar system UCDs
In-Reply-To: <20050610150051.dq8plmskejc4cso8@webmail.sic.rm.cnr.it>
References: <200506091844.j59IijxU002921@urania.cfa.harvard.edu> <20050610150051.dq8plmskejc4cso8@webmail.sic.rm.cnr.it>
Message-ID: <42A99CC5.4070601@cea.fr>

Nice ;-)

Andrea Preite Martinez wrote:

> Here are my comments on the UCDs proposed by SS people, see:
>  http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html
> 
> 1. meta.id.(x,y,z)   Cartesian component of a vector
> 
> In the present list of ucd-words you find
> S|pos.cartesian            |Cartesian (rectangular) coordinates
> Q|pos.cartesian.x          |Cartesian coordinate along the x-axis
> Q|pos.cartesian.y          |Cartesian coordinate along the y-axis
> Q|pos.cartesian.z          |Cartesian coordinate along the z-axis
> 
> The keywords used for assigning these ucd-words are:
> Q|pos.cartesian.(x,y,z)    |(x,y,z) axis coordinate position (U,V,W)
> component projected
> 
> so that the description: y component of any-V-quantity
> leads to the ucd:       any-V-quantity;pos.cartesian.y
> 
> where vectorial quantities are, for the moment,
> 
> V|phys.electField
> V|phys.magField
> V|pos.distance
> V|pos.pm
> V|pos.precess
> V|src.veloc
> 
> On the other hand, pos.cartesian.x/y/z is a quantity (position on axis
> x/y/z), so that the description :
> 
> Xpos on detector   yields   pos.cartesian.x;instr.det
> 
> My suggestion is: keep pos.cartesian.x/y/z
I think that we introduce this meta.id when working on previous versions
where pos.cartesian did not exists.
> 
> 2. obs.air    suppress
> 3. replace with: obs.atm
> I agree.
> But then we need to change air  into atm  in:
> S|obs.air              |Atmosphere
> Q|obs.air.extinction   |Atmospheric extinction
> and
> Q|obs.air.mass         |Airmass   could become
> Q|obs.airMass
> 
> 4. obs.atm.refraction / phys.refraction
> I support Jonathan suggestion: change into
> obs.atm.refractAngle
> phys.refractIndex
> 
> 5. obs.elongation
> The elongation of a celestial body its the angular separation from the body
> around which it orbits
> The UCD for this quantity already exists: pos.angDistance
Not really!
Unless we do not need src.veloc.* because src.veloc exists. ( joke ;-) )
elongation is a "special/specific" parameter in planetology,
why not then pos.angDistance.elongation
> 
> 6. obs.phaseAng
> as above
It is even less true here because pos.angDistance is the angular distance
betwwen two points (on a sphere) from the observer point of view
and obs.phaseAng gives the angle between the sun and the observer
from the observed spot point of view and is related to illumination,
light incidence and re-emission...
> 
> 7. pos.az.ha, pos.az.azi, pos.eq.ha
> I agree with the proposal.
> 
> 8. pos.brc.(), pos.earth()
> I basically agree. I also totally agree with Jonathan's comment.
> 
> 9. pos.eop.()
> OK
> 
> 10. pos.precess
> No, the description is all right: just <precession>
> Equatorial precession  ==> pos.precess;pos.eq
> I prefer this, its more flexible.
but perhaps not sufficient to "describe completly" precession in some case!
> 
> 11. phys.magAbs.G
> I'm only aware of the H mag (which is actually a visual mag!!)
> I remind you that phys.magAbs has E-flag: if you just need to specify the
> phot band, you can say: phys.magAbs;em.opt.V
~ phys.magAbs.G is a parameter for the derivation of the absolute magnitude of asteroids
> 
> 12. src.orbital.meanMotion
> I suppose it is an average angular velocity (src.veloc.ang;stat.mean).
> No strong feelings about it.
> 
> 13. ...veloc...
> to be revised (not only in the framwork of SS!!
sure
> 
> 14. src.veloc.compon
> Not in the present list.
> 
> Cheers,
> 
> Andrea
> 
> ============================================================================== 
> 
> Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma
> ============================================================================== 
> 
> 

-- 
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------




From mcs at iaa.es  Fri Jun 10 09:01:14 2005
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 10 Jun 2005 18:01:14 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu> <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it> <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es> <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
Message-ID: <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>

Hi again :)


>> ... for clarity purpose and hogenity
>> the UDCs I would suggest the following changues:
>>
>> em.IR.K -->  em.IR.2-3um
>> em.IR.H -->  em.IR1500-2000nm
>> em.IR.J -->  em.IR1000-1500nm
>>
....

> may be we should go this way, because the names of those bands can be
> misleading.
> In the case of x- and gamma-rays though there is no confusion, so I  
> would
> keep the existing names...
>

Uhmm, for X-ray and gamma-rays I was asking X-ray and gamma-ray  
people....
I know that UCDs are not for humans, but asking about what  soft and  
hard X-rays mean,
the answer is highly dependent on the asked astronomer. Usually they  
talk  only about
soft and hard. "medium-Xrays" is not understood. In fact, most people  
I asked consider
hard X-ray as aprox 4-10 keV band (from maximmun energy from ROSAT/ 
EINSTEIN to max energy by CHANDRA/ASCA/XMM)..... I do not know, but I  
think that
keep em.X-ray.soft medium and hard is misunderstanding for X-ray  
people. Another example,
ROSAT has a "hardness" ratio that is 0.2 keV-1.5keV (soft) vs. 1-4kev  
(hard) (I do not remember exactly the
energies, sorry) where "soft" and "hard" refers to the detectors in  
ROSAT (but they are used in thsi way in the articles)....

In gamma ray, the situation is similar. You can take a look the  
INTEGRAL instruments, or CGRO ones.
The problem is that each energy range use techniques completely  
different (due to the physics of the process) and em.gamma.hard is to  
wide! It includes from only space instruments to only ground based  
instruments (using the atmosphere as detector). In fact some gamma- 
ray people make distinction between gamma-ray VeryHigh gamma-rays and  
Ultra-High gamma rays as clearly different parts of the
electromagnetic spectrum.... (I was also thinking about INTEGRAL  
where a more defined bands
would be and asset).


>> Finally, I think that the inclusion of em.line would be useful, but
>> only for a very sort list of lines so ... I would agree with
>> Hydrogen lines, but I do think that em.line.OIII should be
>> depreciated (there is several OIII lines!, and if OIII is here, by
>> not, O I, or H+K Ca II etc...? so I propose depreciate  
>> em.line.OIII ...
>>
> the reason for the inclusion of the OIII line is that the doublet  
> 4959+5007
> is one of the strongest lines in emission-line objects (second only to
> Halpha in most cases). There are surveys in Halpha/beta and in  
> OIII, not in
> OI.

ok :)

About other issues. I also agree with include arith and stat in  
"math". I also suggest

        math.stat.moment

that means the order moment of the statistical distribution, i.e.  
mean is 1,
variance is 2, skewness 3, and kurtosis 4....), so allows to include  
more statistical information
(e.j. there is some published data in skewness distributions of  
globular cluster, also are useful
for some synthesis models)


In the case of:


>
>> spect    I worry about spect - this is a kind of data.
>>          If spect, why not image? I predict a few years from now
>>          we will have to change spec and instr.image to  
>> data.spect, data.image, etc.
>>
>
> I agree that data.image and data.spec is a much better model, at  
> least for observations.  After all, what UCD
> often does is to provide generalized "keywords" a la FITS.
>
> On the other hand, the VO theory people might complain that their  
> "images" and "spectra" are not really "data".
>
> Sounds like a problem which has to be put off until later.


Form a theoretical point of view (mine) theory results can be  
considered as "data", produced by a computer
instead a telescope but.... (any case the results of theory will be  
also under a tag <TABLEDATA> isn't  it?
(it is my very particular opinion). (any case there is also a S UCD  
called "meta.modelled"


Finally, about the "line" atom used in "spect"... Uhmm, I do not know  
if there is a more usefull atom. I mean, some lick indices, as  
example, are obtained from "bands" and no lines.... there is no  
problem is it is explicti in the definition that it would refers not  
only to lines but also to bands...

In the same way, I think that

spect.line.intensity  ---> spect.line; phot.fluxDens

Atoms like: profile. width, eqwidth sound ok, but  
spect.line.asymmetry is not included in spect.line.profile?
also for spect.line.broad? (this last I am not sure)


Nice weekend

     Miguel


From Matteo.Guainazzi at sciops.esa.int  Mon Jun 13 02:48:40 2005
From: Matteo.Guainazzi at sciops.esa.int (Matteo Guainazzi)
Date: Mon, 13 Jun 2005 09:48:40 +0000
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
 <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
 <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
 <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
 <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
 <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
Message-ID: <42AD5678.9010707@sciops.esa.int>

Dear Miguel, dear Andrea,

 from the X-ray perspective, I confirm basically Miguel's findings. The 
terms "soft", "medium", "hard" X-rays have been and are being used with 
very different meanings in different papers. What is "hard" for 
XMM-Newton and Chandra (2 to 8, 10 or 15 keV), was called sometimes 
"intermediate" in BeppoSAX papers. Moreover, I have almost never seen 
"medium" in a published paper.

 There are two possible ways out:

    * to substitute words with explicit energy ranges, as suggested for
      the optical bands. "Soft" may become "0.1-2.4 keV" (the energy
      range of the ROSAT All Sky-Survey); "hard" becomes "2-10 keV" (the
      energy range of ASCA surveys), or "2-8 keV" (if we want to follow
      the typical range being used in Chandra surveys), or "2-12 keV"
      (if one wants to follow the typical range used in XMM-Newton
      source catalogues); "medium" may become "0.5-4.5 keV" (the energy
      range of the Einstein Slew Survey). "Very hard" (it does not
      currently exist, but it should if gamma-ray astronomers agree) may
      become "15-200 keV" (typical BeppoSAX/PDS range).
    * to substitute explicit survey bands and sub-bands (ROSAT has, for
      instance, a "soft soft band, 0.1-0.4 keV, and a "hard soft band",
      0.4-2.4 keV) for qualitative qualifiers; e.g.: "Einstein Slew
      Survey band" (".emss"), or "ROSAT All Sky Survey soft" (".rasss"),
      "PDS energy range" (".pds") instead of "soft", ...

 The consequences of either choice are clear: in the former, we risk 
mis-understanding old surveys (those done when I was not born, but still 
in use), in the latter we multiply we number of UCD endlessly.

 None of the above solutions is therefore satisfactory, from my point of 
view. As often in the VO context we are trying to extract order from 
chaos, i.e. one to derive standards where standards have never been 
applied in the past.

 My favorite (and surely controversial) solution? A more conservative 
and radical (!) approach: we remove "soft", "medium" and "hard", and 
keep only "em.X-rays".

 Regards, Matteo

-- 
Matteo Guainazzi
XMM-Newton SOC				Matteo.Guainazzi at sciops.esa.int
European Space Astronomy Center	of ESA	Phone:     +34 91 8131 176
VILSPA, Apartado 50727, E-28080 Madrid 	Fax:       +34 91 8131 172         


From andrea.preitemartinez at rm.iasf.cnr.it  Mon Jun 13 03:10:31 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Mon, 13 Jun 2005 12:10:31 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
	<20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
	<AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
	<20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
	<872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
Message-ID: <20050613121031.r4m3ie1qsyxw44cg@webmail.sic.rm.cnr.it>

Hi Miguel:

>> In the case of x- and gamma-rays though there is no confusion, so I  
>> would keep the existing names...
> Uhmm, for X-ray and gamma-rays I was asking X-ray and gamma-ray
> people....

I gave those bands the names soft/medium/hard x-rays because I'm an x-ray
man and I'm coming from an x/gamma-ray institute...

> I know that UCDs are not for humans, but asking about what  soft and
> hard X-rays mean,
> the answer is highly dependent on the asked astronomer. Usually they
> talk  only about
> soft and hard. "medium-Xrays" is not understood. In fact, most people
> I asked consider
> hard X-ray as aprox 4-10 keV band (from maximmun energy from ROSAT/
> EINSTEIN to max energy by CHANDRA/ASCA/XMM)..... I do not know, but I
> think that
> keep em.X-ray.soft medium and hard is misunderstanding for X-ray
> people. Another example,
> ROSAT has a "hardness" ratio that is 0.2 keV-1.5keV (soft) vs. 1-4kev
> (hard) (I do not remember exactly the
> energies, sorry) where "soft" and "hard" refers to the detectors in
> ROSAT (but they are used in this way in the articles)....

You are perfectly right, usually they think in terms of the bandpass of
their instrument. 4 keV are hard for ROSAT people because 4keV is hardER
than 0.2 keV (their soft limit). For XMM people 10keV are hard. For
BeppoSAX people 10 keV are medium, because the bandpass reaches 2-300 keV.
We should not forget that we are parsing the em spectrum, we have to
describe it, not the bandpasses of instruments.
So, to avoid a narrow-minded interpretation of the ucd-words em.X-ray.*
your suggestion (use energies instead of labels) is the safest one.

> In gamma ray, the situation is similar. You can take a look the
> INTEGRAL instruments, or CGRO ones.
> The problem is that each energy range use techniques completely
> different (due to the physics of the process) and em.gamma.hard is to
> wide! It includes from only space instruments to only ground based
> instruments (using the atmosphere as detector). In fact some gamma-
> ray people make distinction between gamma-ray VeryHigh gamma-rays and
> Ultra-High gamma rays as clearly different parts of the
> electromagnetic spectrum....

I agree that gamma.hard is rather wide!! Probably we should go for
at least three bands:
hard/high
VeryHigh
UltraHigh

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From andrea.preitemartinez at rm.iasf.cnr.it  Mon Jun 13 06:09:09 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Mon, 13 Jun 2005 15:09:09 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <42AD5678.9010707@sciops.esa.int>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
	<20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
	<AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
	<20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
	<872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
	<42AD5678.9010707@sciops.esa.int>
Message-ID: <20050613150909.dc3n3n7vynswgkkk@webmail.sic.rm.cnr.it>

Quoting Matteo Guainazzi:

> Dear Miguel, dear Andrea,

>  My favorite (and surely controversial) solution? A more conservative
> and radical (!) approach: we remove "soft", "medium" and "hard", and
> keep only "em.X-rays".

No way, Matteo!! How do you define the beginning and the end energies of
what you call x-ray :) ?
The only solution is to decouple energies from sub-bands, and to describe
"regions" of the em spectrum by numbers and not by labels.

Regards

Andrea


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From Hessman at Astro.physik.Uni-Goettingen.DE  Mon Jun 13 06:22:10 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Mon, 13 Jun 2005 15:22:10 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <20050613121031.r4m3ie1qsyxw44cg@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu> <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it> <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es> <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it> <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es> <20050613121031.r4m3ie1qsyxw44cg@webmail.sic.rm.cnr.it>
Message-ID: <e78085b4bbb2bcd59f2a63fcc24fcdf3@Astro.physik.Uni-Goettingen.DE>

>> In gamma ray, the situation is similar. You can take a look the
>> INTEGRAL instruments, or CGRO ones.
>> The problem is that each energy range use techniques completely
>> different (due to the physics of the process) and em.gamma.hard is to
>> wide! It includes from only space instruments to only ground based
>> instruments (using the atmosphere as detector). In fact some gamma-
>> ray people make distinction between gamma-ray VeryHigh gamma-rays and
>> Ultra-High gamma rays as clearly different parts of the
>> electromagnetic spectrum....
>
> I agree that gamma.hard is rather wide!! Probably we should go for
> at least three bands:
> hard/high
> VeryHigh
> UltraHigh

But the problem remains that "hard" and "very" and "ultra" are  
undefined.
If the band is so wide, then use more than 3 bands, just like the  
present
use in the radio (which is also wide).

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 andrea.preitemartinez at rm.iasf.cnr.it  Mon Jun 13 09:00:55 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Mon, 13 Jun 2005 18:00:55 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <200506091846.j59Ik5kY003131@urania.cfa.harvard.edu>
References: <200506091846.j59Ik5kY003131@urania.cfa.harvard.edu>
Message-ID: <20050613180055.cwxyf7fm3u88css4@webmail.sic.rm.cnr.it>

Quoting Jonathan McDowell :

> Rick Hessman proposed a number of UCDs (May 30) and I wanted to 
> comment on them.
> One was
>  spect.cont    spectral continuum
> I endorse adding this, it's very useful for my own data.

If you mean that  spect.cont is a sort of flux per unit something, than
it'll be better to wait for a revision of the fluxDensity word

> So here's my proposal for Rick's list, in which proposed new UCDs
> are marked by a *  (sort of the paleolinguistics convention of
> marking hypothetical word forms with a *).
>
>  Rick                                   Jonathan
>  phys.grav-wave/em.grav-wave            *phys.wave.gravitational
>  phys.particle.neutrino/em.neutrino     *phys.particle.neutrino
>  instr.calib                 *obs.calib  [Calibration observation]

Yes, we could introduce the three sub-trees:
S | phys.wave.*
S | phys.particle.*  (starting for the already present electron)
S | obs.calib(.*)

A few comments on the following list:

>  phot.calib                   obs.image;*obs.calib;phot.flux
>        [It's an image; it's for calibration; what are we calibrating - flux.]
>                               spect;*obs.calib;phot.flux
>        [or, it's a spectrum...]
>  obs.calib.dome-flat          
> obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
>        [We're calibrating the flatness of the detector; we're using 
> the dome to do it]
>  obs.calib.flux               obs.image;*obs.calib;phot.flux
>  obs.calib.freq               spect;*obs.calib;em.freq
>        [It's a spectrum; it's for calibration; we're calibrating freq]
>  obs.calib.guide-star         meta.id;*obs.calib;*pos.astrometry
>        [If this is the name of the guide star used..]
>  obs.calib.phot    [What's the difference with obs.calib.flux?]
>  obs.calib.pos                obs.image;*obs.calib;*pos.astrometry  (?)
>  obs.calib.sky-flat           obs.image;obs.calib;*instr.det.flat
>  obs.calib.slit-mask          *instr.spect.slit
>  obs.calib.spect              spect;*obs.calib;em.wl
>       [If you mean by this an arc spectrum; what diff from obs.calib.wl?]
>  obs.calib.veloc              spect;*obs.calib;src.veloc
>  obs.calib.wl                 spect;*obs.calib;em.wl
>  phot.calib.flux              [same as obs.calib.flux?]
>  phot.calib.mag               *obs.calib;em.opt.B   (etc.)
>  pos.calib                    *obs.calib;pos
>  spect.calib                  spect;*obs.calib
>  spect.calib.wl               spect;*obs.calib;em.wl
>  spect.calib.freq             spect;*obs.calib;em.freq

1. the order is inverted: e.g.
obs.image;*obs.calib;phot.flux   ==> phot.flux;obs.calib
spect;*obs.calib;src.veloc       ==> src.veloc;obs.calib
*obs.calib;em.opt.B              ==> phot.mag;em.opt.B;obs.calib

The same for Rick's suggestions:
instr/tel;optics.focallength     ==> optics.focallength;instr/tel

2. We have to maintain UCD-words, not UCDs

3. Saying: [It's an image; it's for calibration; what are we calibrating -
flux.] means that you are probably describing a detaset, so an alternative
description could be: [name (or url, or ...) of an image used for
flux-calibrating other images of raw data]
that could translate into :
meta.id;obs.image;obs.calib

We probably need a deeper discussion before introducing new trees.
I agree with Jonathan: let's move quickly from WD to PR, and continue at the
same time the discussion on new words, object types, events, etc...

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From seaman at noao.edu  Mon Jun 13 19:27:31 2005
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 13 Jun 2005 19:27:31 -0700
Subject: VOConcepts
Message-ID: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>

Howdy,

I picked this list as the most appropriate place for this  
conversation.  Please comment if you've got a different idea.  This  
discussion is being driven by VOEvent issues, but the implications  
are broader.  Some observations, assumptions, and conclusions:

1) UCDs appear to be the near term VO solution for semantic  
nomenclature.
2) VOEVENT will soon require a VOConcept style mechanism.
3) It seems obvious that VOConcept will borrow UCD syntax.
4) There seems to be significant delay implicit with establishing
         VOConcept as an official offshoot of UCDland.
5) Thus it seems that there will be significant pressure to establish
         VOConcept as a separate namespace of some sort under UCD.

Operating under that assumption, the question is what that namespace  
will look like.  The current snapshot is available at http:// 
monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/UnifiedContentDescriptors

Here are my comments;

1) Proper names don't belong under the VOConcept namespace.  Whether  
this is a separate namespace of its own, or whether proper names are  
handled by a completely separate mechanism, there is no need to  
specify something like "solar_system.Sun".  Call me a radical, but I  
think the Sun should simply be called "Sun".  In any event, a proper  
name of an object or process is distinct from any sort of  
classification of that particular object or process.

2) A "coronal mass ejection" is not equivalent to  
stars.corona;process.mass-loss.ejection, whether or not this  
precisely describes the physical event.  My point is that just as  
with proper names, the astronomical community has chosen to assign  
"proper class names" to certain phenomena:  CMEs, GRBs, KBOs, etc.   
We will fail if we seek to provide a namespace that usefully predicts  
what new class names will be needed in the future.  Rather, we need a  
mechanism for adding new identifiers.

3) Which is it?  Sun;process.pulsation or Sun;seismology?  Again,  
"helioseismology" is an identifier distinct from the latter  
classification.

4) We need neither stars;planets nor stars.planets - just planets.  I  
think we can assume for most purposes that if you are describing a  
planet that a star is somewhere in the neighborhood.

5) How about both stars.multiple and stars.binary?  These are just  
two out of several clustering options, such as stars.cluster, for  
that matter.

6) It's interesting what stars.nearby is trying to describe, but this  
seems pretty parochial.  There are a lot of "neighborhoods" scattered  
throughout astronomical semantics.  Maybe there is some way to  
generalize this as some kind of operator notation.  (On the other  
hand, that seems a bit precious.)

7) stars.supernova seems redundant.  What else would it be?  This is  
just the "planet" comment revisited.  This is distinct from the  
star.variable family precisely because a SN is rather emphatic.

8) VOConcept (however constituted under whatever name) needs to  
represent stars, galaxies, and other objects.  It isn't so obvious  
that "cosmology" is useful classification for VOEvent purposes.  It  
isn't obvious what VO-wide purposes this classification would be used  
for in general.

9) VOEvent provides a good testbed for a number of VO technologies.   
It seems to me that a VOConcept list targeted precisely at VOEvent  
needs, perhaps augmented by some carefully selected concepts to fill  
in just a few missing items is a good place to start.

Rob Seaman
NOAO 


From Hessman at Astro.physik.Uni-Goettingen.DE  Tue Jun 14 00:47:45 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Tue, 14 Jun 2005 09:47:45 +0200
Subject: VOConcepts
In-Reply-To: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
Message-ID: <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>

  I think we'd all appreciate a general comment on whether ucd-sci is  
the right place for a discussion
of what we have tenatively called VOConcept.   Yes, there are lots of  
potential relations between VOCocept and UCD
- see the Kyoto papers by S. Derriere and A. Allan - so there are lots  
of reasons to include both communities
right now, but the ultimate connections will be indirect by popular  
demand within the UCD community, since the
UCD design documents as they are currently written don't foresee any  
deviations beyond the VOTable-ish uses
of UCDs.

You might ask us to please shut up and worry about this later, but  
we're in the final throes of finishing VOEvent 1.0
and need to make a short-term decision about whether we ignore the  
problem of naming for now (at the cost of
a loss of naming capability) or make an initial plunge in the direction  
of a UCD-like VOConcept (whatever you
want to call it).

Please vote:

___ Please stop talking about VOConcept in this list - we have enough  
to worry about as it is.
___ I think the two issues are still related enough to warrant  
inclusion in the ucd-sci discussion list for now.

Based upon the tally, we can decide to continue (at least now and then)  
or to start a new list.

If you vote for stopping, then please ignore the rest of this message  
and "have a nice day." :-)


On 14 Jun 2005, at 4:27 am, Rob Seaman wrote:

> I picked this list as the most appropriate place for this  
> conversation.  Please comment if you've got a different idea.  This  
> discussion is being driven by VOEvent issues, but the implications are  
> broader.  Some observations, assumptions, and conclusions:
>
> 1) UCDs appear to be the near term VO solution for semantic  
> nomenclature.

SOME semantic nomenclature.  My feeling is that there is lots of  
resistance to a generalization and not just
because of short-term release pressures.

> 2) VOEVENT will soon require a VOConcept style mechanism.

VOEvent needs it NOW.

> 3) It seems obvious that VOConcept will borrow UCD syntax.
> 4) There seems to be significant delay implicit with establishing
>         VOConcept as an official offshoot of UCDland.
> 5) Thus it seems that there will be significant pressure to establish
>         VOConcept as a separate namespace of some sort under UCD.

or, more likely, parallel to UCD.

> Operating under that assumption, the question is what that namespace  
> will look like.  The current snapshot is available at  
> http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ 
> UnifiedContentDescriptors
>
> Here are my comments;
>
> 1) Proper names don't belong under the VOConcept namespace.  Whether  
> this is a separate namespace of its own, or whether proper names are  
> handled by a completely separate mechanism, there is no need to  
> specify something like "solar_system.Sun".  Call me a radical, but I  
> think the Sun should simply be called "Sun".  In any event, a proper  
> name of an object or process is distinct from any sort of  
> classification of that particular object or process.

I agree.  For those cases (and not just the Sun) we need

	<object voconcept="planet">Jupiter</object>
	<object voconcept="stars.variable.LMXB">RXJ1234+567</object>
	<object voconcept="galaxies.spiral">NGC12345</object>
	<object voconcept="event.burst;em.gamma-ray">GRB12345</object>

Note the combination of UCD and VOConcept in the last case and note that

	<object ucd="em.gamma-ray" voconcept="event.burst"/>

is fine for simple things but isn't necessarily the same thing for more  
complex naming purposes.

> 2) A "coronal mass ejection" is not equivalent to  
> stars.corona;process.mass-loss.ejection, whether or not this precisely  
> describes the physical event.  My point is that just as with proper  
> names, the astronomical community has chosen to assign "proper class  
> names" to certain phenomena:  CMEs, GRBs, KBOs, etc.  We will fail if  
> we seek to provide a namespace that usefully predicts what new class  
> names will be needed in the future.  Rather, we need a mechanism for  
> adding new identifiers.

Both.  The complex naming will enable VO-technology to combine  
information in new ways maybe we haven't thought of.  On the
other hand, there has to be a human interface so that the user can use  
terms like "GRB" or "KBO".   Yes, by combining UCD-like
elements, we're getting close to starting an ontological analysis, but  
just barely and not necessarily because we WANT an ontology.
Thus, CME = stars.corona;process.mass-loss.ejection is fine - one for  
the human, one for the computer.

> 3) Which is it?  Sun;process.pulsation or Sun;seismology?  Again,  
> "helioseismology" is an identifier distinct from the latter  
> classification.

Neither if "Sun" is kept as a proper name ;-)

	<helioseismicData ucd="em.opt phys.wave" voconcept="process.pulsation">
		<object voconcept="stars">Sun</object>
		<data>.....</data>
	</helioseismicData>

> 4) We need neither stars;planets nor stars.planets - just planets.  I  
> think we can assume for most purposes that if you are describing a  
> planet that a star is somewhere in the neighborhood.
>
> 5) How about both stars.multiple and stars.binary?  These are just two  
> out of several clustering options, such as stars.cluster, for that  
> matter.
>
> 6) It's interesting what stars.nearby is trying to describe, but this  
> seems pretty parochial.  There are a lot of "neighborhoods" scattered  
> throughout astronomical semantics.  Maybe there is some way to  
> generalize this as some kind of operator notation.  (On the other  
> hand, that seems a bit precious.)

No - this type of inclusion is exactly what is needed for a totally  
different VO application: education and public outreach.  See
http://www.communicatingastronomy.org/index.html for a VO-related group  
which is interested in such concepts.  Nearby stars
are interesting because they move on the sky.   "Nearby" to a  
professional is perhaps not an interesting concept - just go to
Sinbad and get the latest catalogue to pick out what you want - but  
identifying images available to the public as being interesting
for studying proper motion and parallax is a great thing and it would  
be nice to have a universal identifier for that purpose.  The
names themselves are what's important - it's the need for a name which  
should drive the list.

> 7) stars.supernova seems redundant.  What else would it be?  This is  
> just the "planet" comment revisited.  This is distinct from the  
> star.variable family precisely because a SN is rather emphatic.

The problem of hierarchical naming (and hence implict primitive  
ontologies) came up early in RTML: our first list was a random
collection of names - "star", "supernova", "cepheid",... - but it  
became difficult to manage simply because of the danger of muliple
entries.   A minimum amount of hierarchy insures that the  
administration of the names is straight-forward and even eases their
use in GUIs and other more mundane uses.

> 8) VOConcept (however constituted under whatever name) needs to  
> represent stars, galaxies, and other objects.  It isn't so obvious  
> that "cosmology" is useful classification for VOEvent purposes.  It  
> isn't obvious what VO-wide purposes this classification would be used  
> for in general.

I dropped "cosmology" from the original VOConcept list because my  
VOEvent colleagues were taken somewhat aback with
how quickly such a list can grow and because there's no immediate need  
for "cosmology" in VOEvent.

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------


From andrea.preitemartinez at rm.iasf.cnr.it  Tue Jun 14 06:06:39 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Tue, 14 Jun 2005 15:06:39 +0200
Subject: VOConcepts
In-Reply-To: <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
	<6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
Message-ID: <20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>

Dear Rick,

I think I will not vote.

I find the discussion (any discussion) among people with different ideas
very stimulating.
And sometimes also more useful than perfect agreement.
Reducing the size of the group until you can feel eventually "among us"
is not good at all in real life, certainly not in the VO.

Just to show you that you are not the only one "uneasy" with somebody
else's point of view, I'll make an example of how "uneasy" could feel an
UCD-folk like me.
Take for instance the UCD you proposed few days ago:

instr.obsty.site;weather.seeing  just to express "seeing"

When I saw it I made a jump on my chair: why?
In inverse order of importance:

1. The UCD-like syntax is wrong: first the "quantity", then the "qualifier"
it should read: weather.seeing;instr.obsty.site

2. We are proposing UCD-words, not UCDs. If you propose an independent word
for "seeing", ok, it's :weather.seeing

3. My mind works in terms of "how to assign ucd-words starting from a
description, and then build an UCD" e.g. in term of the process to
build an UCD from one or more keyword(s):
the "keywords => ucd-words => UCDs" chain.
It is impossible (in this framework) to go from the single keyword
"seeing" to an UCD composed of two UCD-words
(each one of these UCD-words needs its own description).

Let's reverse the roles: you jump on the chair when you see the description
of the src.class.* words.
You are perfectly right. What is not said is that I do not use the
description
field to assign words/ucds: I use a series of words (keywords
derived from the description) that are OR-ed,
which is exactly equivalent to the loosier description you suggest.


As I already said, the ucd vocabulary is not only composed of words
that are "quantities". More and more "objects" are creeping in, and I can
imagine the development of two sub-lists :

a "q-list" slowly evolving (or even stabilized; after all the number of
new (astro-)physical quantities per year is probably very easy
to control!!)

and an "o-list" (or whatever name we decide for it!!) for "non-quantities",

both lists with the same syntax (just for simplicity and
"interoperability" (!!),
so that we can continue to build UCDs of the form:

word[q-list];word[o-list] ...

as we do today without knowing that we are actually doing it (!)

Andrea


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From roy at cacr.caltech.edu  Tue Jun 14 08:47:54 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Tue, 14 Jun 2005 08:47:54 -0700
Subject: VOConcepts
In-Reply-To: <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu> <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
Message-ID: <90d425de570af37c027e96fc39d04638@cacr.caltech.edu>


On Jun 14, 2005, at 12:47 AM, Frederic V. "Rick" Hessman wrote:

>  I think we'd all appreciate a general comment on whether ucd-sci is 
> the right place for a discussion
> of what we have tenatively called VOConcept.

Rick

It says in the UCD document "UCD describe astronomical quantities", 
meaning that they are "semantic meaning of data quantities", for 
example "phys.temperature".  The implication is that UCD is NOT 
something like "satellite.Phobos;planet.Mars" and it is NOT something 
like "image.jpeg;human.JacquesChirac". I believe that the scope here is 
correct, and that extensions in to these other areas of knowledge will 
slow down the well-developed and sophisticated UCD effort.  One of the 
best things about UCD is that it has been mined from thousands of table 
instances written by hundreds of astronomers, and therefore has 
unimpeachable credentials as a representation of the astronomical 
community.

However, we should tackle wider questions when supported by use cases 
from the community. I believe the UCD effort should become part of a 
wider "semantics" effort, which may use UCD syntax for other areas of 
knowledge (eg. astrophysical events), or it may use OWL or RDF or other 
syntax. Frankly I don't care about the syntax part, that comes later: 
what is important in these semantics efforts is formalizing some branch 
of knowledge so that computers can record, compare, and deduce.

> Yes, there are lots of potential relations between VOConcept and UCD

I would prefer not to use the term "VOConcept", as it is too vague. I 
think the Semantics WG should concentrate on small, well-defined, 
areas.

> You might ask us to please shut up and worry about this later, but 
> we're in the final throes of finishing VOEvent 1.0 and need to make a 
> short-term decision about whether we ignore the problem of naming for 
> now (at the cost of a loss of naming capability) or make an initial 
> plunge in the direction of a UCD-like VOConcept (whatever you want to 
> call it).

I think that VOEvent should be published as version 1.0 Working Draft 
without any formal semantics for describing events, but rather describe 
events in natural language: "Looks like an exploding square galaxy" 
would be a typical description. Then in VOEvent 1.1 we can tackle 
formal semantics and other matters.

And that formal description of astronomical events should not be called 
"VOConcept", but something more specific, such as "Unified Event 
Description", or "VOEventDescription". The first task of that 
discussion group is define what is the area of knowledge that is being 
covered, and agree to a short paragraph expressing what is an is not 
being formalized into syntax. For example, in VOEventDescription, is it 
an event when Michael Jackson is acquitted? How about when a new planet 
is discovered? How about a flare from a star that flares every 2 weeks?

I believe that defining scope is the key to progress here, and that the 
tighter that scope, the better chances for agreement. Otherwise we are 
caught in a morass of ontological questions. In the words of Bill 
Clinton, "It depends upon what the meaning of the word is means. "

> Please vote:
> ___ Please stop talking about VOConcept in this list - we have enough 
> to worry about as it is.
> ___ I think the two issues are still related enough to warrant 
> inclusion in the ucd-sci discussion list for now.
>
> Based upon the tally, we can decide to continue (at least now and 
> then) or to start a new list.

I think the discussion of VOEventDescription should take place in the 
VOEvent mailing list, perhaps copying the entire Semantics WG when 
wider issues come up.

Roy


From seaman at noao.edu  Tue Jun 14 09:54:03 2005
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 14 Jun 2005 09:54:03 -0700
Subject: VOConcepts
In-Reply-To: <90d425de570af37c027e96fc39d04638@cacr.caltech.edu>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu> <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE> <90d425de570af37c027e96fc39d04638@cacr.caltech.edu>
Message-ID: <D121ED79-8C51-425F-8075-0A3AC0B549BF@noao.edu>

Roy says:

> I think the discussion of VOEventDescription should take place in  
> the VOEvent mailing list, perhaps copying the entire Semantics WG  
> when wider issues come up.

I've forwarded the last few messages to VOEvent.  Further discussion  
will continue over there.

Rob Seaman
NOAO


From Hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun 15 00:24:44 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 15 Jun 2005 09:24:44 +0200
Subject: src.class.* and weather.*
In-Reply-To: <20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu> <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE> <20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>
Message-ID: <25e0156b6e8fe2c7269c22897f2887f8@Astro.physik.Uni-Goettingen.DE>

> Just to show you that you are not the only one "uneasy" with somebody
> else's point of view, I'll make an example of how "uneasy" could feel  
> an
> UCD-folk like me.
> Take for instance the UCD you proposed few days ago:
> instr.obsty.site;weather.seeing  just to express "seeing"
>
> When I saw it I made a jump on my chair: why?
> In inverse order of importance:
>
> 1. The UCD-like syntax is wrong: first the "quantity", then the  
> "qualifier"
> it should read: weather.seeing;instr.obsty.site

Sorry - I confess that I haven't been worrying AT ALL about things like  
order, since
the examples I've been worrying about don't depend upon it: is there  
really a
fundamental difference between "seeing at an  
observatory"=weather.seeing;instr.obsty.site
and "observatory's seeing"=intr.obsty.site;weather.seeing.  Maybe for  
some extreme
examples and onotolgy folks, but otherwise......

> 2. We are proposing UCD-words, not UCDs. If you propose an independent  
> word
> for "seeing", ok, it's :weather.seeing

True, but my bottom line is how to use them to express something.  The  
UCD words
are defined not just to be there but to be used.   I forgot to  
distinguish between words
and atoms - excuse moi!

> 3. My mind works in terms of "how to assign ucd-words starting from a
> description, and then build an UCD" e.g. in term of the process to
> build an UCD from one or more keyword(s):
> the "keywords => ucd-words => UCDs" chain.
> It is impossible (in this framework) to go from the single keyword
> "seeing" to an UCD composed of two UCD-words
> (each one of these UCD-words needs its own description).

Hmmm.... don't quite get that.  My approach has been
	- I want to express something
	- look at the official UCD list to see what comes closest
	- if there's no exact/good match, look for related things to see if  
composing works
	- if there are no matches/composing solutions at all, think of new  
atoms or words, worrying about whether one
		needs a single atom/family of words or just additions to present  
families
Not obvious that we're talking about a different process, but just my  
laziness in atom/word
order, no specification of the "syntax code" and too few descriptions.

> Let's reverse the roles: you jump on the chair when you see the  
> description
> of the src.class.* words.
> You are perfectly right. What is not said is that I do not use the
> description
> field to assign words/ucds: I use a series of words (keywords
> derived from the description) that are OR-ed,
> which is exactly equivalent to the loosier description you suggest.

Sorry - still don't get this.....   Are you saying that  
src.class.richness DOESN'T mean
Abell class  (even though that's what the official list says) or not?   
If it  DOES mean
that, then we need to rename the word.  If it DOESN'T mean that, we  
need to change
the description.  Either way, we need to change something, because  
leaving it as
it is will forever prevent someone from using richness for anything  
else with
a good conscience.   It's perfectly valid for someone to suggest a word  
based on their
own needs (indeed, this is the BEST way), but the UCD community should  
make sure
that the necessary generalizations are made when needed, and in the  
case of my
list, I feel they are needed.

> As I already said, the ucd vocabulary is not only composed of words
> that are "quantities". More and more "objects" are creeping in, and I  
> can
> imagine the development of two sub-lists :
>
> a "q-list" slowly evolving (or even stabilized; after all the number of
> new (astro-)physical quantities per year is probably very easy
> to control!!)
>
> and an "o-list" (or whatever name we decide for it!!) for  
> "non-quantities",
>
> both lists with the same syntax (just for simplicity and
> "interoperability" (!!),
> so that we can continue to build UCDs of the form:
>
> word[q-list];word[o-list] ...
>
> as we do today without knowing that we are actually doing it (!)

I'm have been arguing for exactly this solution, but I have been  
getting the impression that others aren't
so happy with it.

I've trimmed down the VOConcept list to a bit more than 100  
words/compositions
to include only those which are needed by VOEvent.   I'd be very happy  
to add "syntax codes"
and formal descriptions, trim the list even further, mail everyone a  
down-to-earth ASCII file, and
drop the whole issue of XML Schema integration if the UCD community  
would absorb VOConcept.

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 andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun 15 01:29:05 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed, 15 Jun 2005 10:29:05 +0200
Subject: src.class.* and weather.*
In-Reply-To: <25e0156b6e8fe2c7269c22897f2887f8@Astro.physik.Uni-Goettingen.DE>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
	<6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
	<20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>
	<25e0156b6e8fe2c7269c22897f2887f8@Astro.physik.Uni-Goettingen.DE>
Message-ID: <20050615102905.vk0zlgvdmmlck4sc@webmail.sic.rm.cnr.it>


>> In inverse order of importance:
>> 1. The UCD-like syntax is wrong: first the "quantity", then the  "qualifier"
>> it should read: weather.seeing;instr.obsty.site
>
> Sorry - I confess that I haven't been worrying AT ALL about things like
> order...
That's why I said it's the least important thing :)

>> 3. My mind works in terms of "how to assign ucd-words starting from a
>> description, and then build an UCD" ...
>> It is impossible (in this framework) to go from the single keyword
>> "seeing" to an UCD composed of two UCD-words
>> (each one of these UCD-words needs its own description).
>
> Hmmm.... don't quite get that.  My approach has been
> 	- I want to express something
> 	- look at the official UCD list to see what comes closest
> 	- if there's no exact/good match, look for related things to see if
> composing works

The above points correspond to the action:
   - find the ucd-word(s) that best match what you "want to express"

which is followed by the action of
   - "building" the ucd from the words just found and according to
ucd-syntax.

These two actions together are performed by the "UCD-builder" that
you can find, in its "beta-version", at
http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd

>> Let's reverse the roles: you jump on the chair when you see the  description
>> of the src.class.* words.
>> You are perfectly right. What is not said is that I do not use the
>> description
>> field to assign words/ucds: I use a series of words (keywords
>> derived from the description) that are OR-ed,
>> which is exactly equivalent to the loosier description you suggest.
>
> Sorry - still don't get this.....   Are you saying that
> src.class.richness DOESN'T mean
> Abell class  (even though that's what the official list says) or not?

It actually means :
richness class e.g. Abell richness class
(by the way, ther is also a "Abell distance class" !! Try "Abell class"
as input for the builder...)

> If it  DOES mean
> that, then we need to rename the word.  If it DOESN'T mean that, we
> need to change the description. Either way, we need to change 
> something, because leaving it as
> it is will forever prevent someone from using richness for anything
> else with a good conscience.

Yes, we need to change the descriptions of all src.class.*, and this
thanks to the discussion that is going on!!

Andrea


From andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun 24 05:53:46 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri, 24 Jun 2005 14:53:46 +0200
Subject: Draft list of ucd-words
Message-ID: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>

Dear all,

after 26 days of discussion and contributions from many of you, I decided to
sum up things and to modify the list of words according to my personal
feelings.

You can find the proposed list in the txt file appended.
Of course the discussion is not over, but unfortunately we need a rather
"stable" version soon.
The PR-version of the document (the text accompanying the list) will be sent
around after the meeting in Garching.

A list of all (I hope !!) the modifications is shown below
(Descr=changes in the description
 Canc=word erased
 Added= word added) :

< S  |  em.IR.H                      |Descr
< S  |  em.IR.J                      |Descr
< S  |  em.IR.K                      |Descr
< S  |  em.X-ray.hard                |Descr
< S  |  em.X-ray.medium              |Descr
< S  |  em.X-ray.soft                |Descr
< S  |  em.gamma.hard                |Descr
< S  |  em.gamma.soft                |Descr
< S  |  em.opt.B                     |Descr
< S  |  em.opt.I                     |Descr
< S  |  em.opt.R                     |Descr
< S  |  em.opt.U                     |Descr
< S  |  em.opt.V                     |Descr
<    |  instr.angRes                 |Canc
< Q  |  instr.bandpass               |Descr
< Q  |  instr.dispersion             |Added
< Q  |  instr.order                  |Added
<    |  instr.spect                  |Canc
<    |  instr.spect.dispersion       |Canc
<    |  instr.spect.order            |Canc
<    |  instr.spect.resolution       |Canc
<    |  instr.tel.focus              |Canc
< Q  |  instr.tel.focalLength        |Added
< P  |  meta.curation                |Added
< P  |  meta.version                 |Added
< Q  |  obs.airMass                  |Added
< S  |  obs.atmos                    |Added
< Q  |  obs.atmos.extinction         |Added
< Q  |  obs.atmos.refractAngle       |Added
< S  |  obs.calib                    |Added
< Q  |  phys.density                 |Descr
< Q  |  phys.energy                  |Descr
< Q  |  phys.energyDensity           |Added
< Q  |  phys.refractIndex            |Added
< Q  |  phys.transmission            |Added
< V  |  phys.veloc                   |Added
< Q  |  phys.veloc.ang               |Added
< Q  |  phys.veloc.cmb               |Added
< Q  |  phys.veloc.dispersion        |Added
< Q  |  phys.veloc.escape            |Added
< Q  |  phys.veloc.expansion         |Added
< Q  |  phys.veloc.lg                |Added
< Q  |  phys.veloc.lsr               |Added
< Q  |  phys.veloc.microTurb         |Added
< Q  |  phys.veloc.orbital           |Added
< Q  |  phys.veloc.pulsat            |Added
< Q  |  phys.veloc.rotat             |Added
< Q  |  phys.veloc.transverse        |Added
< Q  |  pos.angDistance              |Descr
< Q  |  pos.az.azi                   |Added
< S  |  pos.bodyrc                   |Added
<    |  pos.earth.nutation           |Canc
< S  |  pos.earthop                  |Added
< Q  |  pos.earthop.nutation         |Added
< Q  |  pos.eq.ha                    |Added
< Q  |  pos.phaseAng                 |Added
< V  |  pos.precess                  |Descr
< Q  |  pos.resolution               |Added
< Q  |  spect.resolution             |Added
<    |  spect.veloc                  |Canc
< E  |  spect.dopplerVeloc           |Added
< E  |  spect.dopplerVeloc.radio     |Added
< E  |  spect.dopplerVeloc.optic     |Added
< S  |  src                          |Descr
< Q  |  src.class.distance           |Descr
< Q  |  src.class.richness           |Descr
< Q  |  src.class.starGalaxy         |Descr
< Q  |  src.class.struct             |Descr
<    |  src.orbital.veloc            |Canc
<    |  src.veloc                    |Canc
<    |  src.veloc.ang                |Canc
<    |  src.veloc.cmb                |Canc
<    |  src.veloc.dispersion         |Canc
<    |  src.veloc.escape             |Canc
<    |  src.veloc.expansion          |Canc
<    |  src.veloc.lg                 |Canc
<    |  src.veloc.lsr                |Canc
<    |  src.veloc.microTurb          |Canc
<    |  src.veloc.pulsat             |Canc
<    |  src.veloc.rotat              |Canc
< Q  |  time.obs                     |Added
< Q  |  time.obs.end                 |Added
< Q  |  time.obs.start               |Added


Regards

Andrea
==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master_sent
Type: application/octet-stream
Size: 50611 bytes
Desc: not available
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050624/9f7116e9/attachment.obj>

From pdidelon at cea.fr  Tue Jun 28 06:16:26 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Tue, 28 Jun 2005 15:16:26 +0200
Subject: Draft list of ucd-words
In-Reply-To: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
Message-ID: <42C14DAA.2020400@cea.fr>

Hi everybody,
some comments...

A) global comments

A.0 instr.obsty
- S | instr.obsty                  |  Observatory satellite mission
you mean Observatory or satellite mission -> Observatory / satellite mission  ?
- Q | instr.obsty.site.seeing      |  Seeing 

Is this the global seeing resulting of detector, instrument, atmosphere...
or does it concern only the instrumental part? If so, did we need a obs.seeing? 

Not clear for me.

A.1 phys.veloc.trans
- Q | phys.veloc.transverse        |  Transverse / tangential velocity
I am not sure that these two definitions are (allways?) compatible.
Moreover, transverse is perhaps not the right word. It isn't tangential, as opposed to radial?
Or do we need two definitions? But velocity transverse to the mouvment seems strange/unappropriate?

A.2 radial velocities
they are now spread in 3 separate group
- phys.veloc.[lg|lsr]
- spect.dopplerVeloc.*
- src.redshift.*
Is spect.dopplerVeloc.* equivalent to radial velocity?
Some "reduced" RV, to the earth center, to the sun are not defined/available,
( see gc, geoc and hc in src.veloc.radial at http://www.imcce.fr/fr/expert/ssvo/wgovp/ucdtree.html )
and the frame corresponding to spect.dopplerVeloc is not defined.
So, phys.veloc.hc for heliocentric value is not available, while
the corresponding position pos.heliocentric is.
I suggest to complete RV and clearly identify them using phys.veloc.radial.[gc|geoc|hc|lg|lsr]
and to change description of spect.dopplerVeloc.* to clearly define the information
about the "place of measurement" : ObsLocation (in case of spacecraft it can be tricky)
or referential frame.

A.3 pos.* the big case/issue already clarified but still some inhomogeneity
or confusion (at least in my head).

A.3.1 pos.earth
  Q | pos.earth.lon                |  Longitude on Earth
exists but not latitude!
Q | pos.earth.altitude           |  Altitude on Earth
exists but not distance which give the distance to the center

A.3.2 lon/lat/alt/dist
For any coordinate system (pos.*centric and mainly pos.bodyrc)
the four informations can be usefull, and if  pos.distance 
                      is available the others don't exist, and can be used to construct composed words.
I suggest introduction of pos.[alt|lat|lon] (at least the two last ones)
to be able to used composed words like pos.lat;pos.bodyrc
or to introduce  [dist|lat|lon] for all coordinate system and alt for some of them.

A.3.3 Some subdivision are not sufficients.
pos.bodyrc as mentionned above ;-)
but also : pos.precess, pos.earthop.nutation and pos.earthop too
see corresponding needs at http://www.imcce.fr/fr/expert/ssvo/wgovp/ucdtree.html

B additional comments mainly related to (small?) solar system objects
( or extra solar system sytem and not only planetary one ;-) )

B.1 Mean motion

 >>>>> Andrea Preite Martinez wrote:
 >>>>>
 >>>>>> 12. src.orbital.meanMotion
 >>>>>> I suppose it is an average angular velocity (src.veloc.ang;stat.mean).
 >>>>>> No strong feelings about it.
 >>>>>
No, the mean motion is not an average angular velocity. It is given
by the third Kepler's law: n2 * a3 = cste with n the mean motion
and a the semi-major axis of the orbit. So it is a corner stone of
the computation of orbits: we need it as a proper UCD.

B.2 asteroid Absolute Magnitude

H is the absolute magnitude which already exist in the UCD (phys.magAbs)
for asteroids we need also the slope parameter usually called G : phys.magAbs.G
but seen as a kind of "calibration" parameter may be a better place somewhere
else in the UCD tree is perhaps possible?

B.3 pos.precess

I guess pos.precess could be more generic because it could be used both for
the equatorial and ecliptic precessions. Perhaps we should change .ra and .dec
to .lon and .lat and, in the same way, .dzeta, .z and ,theta should be change
because they usually refer to the equatorial precession when the ecliptic
precession parameters are expressed  with other letters.

B.4 pos.eop.*

Jonathan McDowell wrote:
 > * pos.eop.*  I like, although as we become more active on other worlds isn't it likely
 >     that we'll be needing similar parameters for Mars, etc.? But maybe it's fine for now.

  yes, SolarSystem people mind about this. But the Earth is a special case which is used often
in ephemeris computation. I guess that first this UCD should be created and
then  a more generic one should be added ?



That's all for the moment.
sincerely yours,
Pierre



Andrea Preite Martinez wrote:

> Dear all,
> 
> after 26 days of discussion and contributions from many of you, I decided to
> sum up things and to modify the list of words according to my personal
> feelings.
> 
> You can find the proposed list in the txt file appended.
> Of course the discussion is not over, but unfortunately we need a rather
> "stable" version soon.
> The PR-version of the document (the text accompanying the list) will be sent
> around after the meeting in Garching.
...
> 
> Regards
> 
> Andrea
> ==============================================================================
> Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma
> ==============================================================================

------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------



From sla at ucolick.org  Tue Jun 28 15:13:11 2005
From: sla at ucolick.org (Steve Allen)
Date: Tue, 28 Jun 2005 15:13:11 -0700
Subject: Draft list of ucd-words
In-Reply-To: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
Message-ID: <20050628221311.GA12268@ucolick.org>

On Fri 2005-06-24T14:53:46 +0200, Andrea Preite Martinez hath writ:

> < Q  |  obs.atmos.refractAngle       |Added

I am a bit mystified by the utility of this quantity.

In actual practice it is usually impossible to distinguish the amount
of refraction from the amount of unmodelled telescope flexure.
It is a rare situation when it is actually possible to make a
measurement of the refraction angle.  Any error is simply accommodated
by the ever-requisite fine pointing adjustment of the telescope.

Under what circumstances is refractAngle actually used?
What drives any requirements for it to be accurate or precise?

On the other hand, the differential refraction, which is to say both
the change in the amount of refraction over a field of view and the
atmospheric dispersion due to refraction are quantities which are
often calculated and used.

The differential refraction and the atmospheric dispersion are needed
for designing and manufacturing focal plane constructs for multi
object spectrographs.

The dispersion enters directly into the decision about the position
angle at which a slit spectrograph should be oriented.

A map of the differential refraction is necessary for
multi-slit spectrographs and for fiber-fed spectrographs.

In my experience these two are needed far more often, and to greater
precision, than the absolute amount of refraction.

> S | pos.earthop                  |  Earth orientation parameters
> Q | pos.earthop.nutation         |  Earth nutation

These specifications seem incomplete, but I'm not sure what
they are supposed to be communicating.

As a starter for discussion, does nutation refer to
IAU 2000A model,  IAU 2000B model, or the models resulting from
the FK5-based revision performed between 1976/1984, or
the nutation based on the older Newcomb models of precession, or what?

Is polar motion and UT1 relevant?  Do they use the IAU 2000 models, or
one of the older forms used in previous versions of the IERS
conventions, or the even older FK5 forms, or what?

> Q | pos.eq.ha                    |  Hour-angle

> Q | pos.az                       |  Position in alt-azimutal frame
> Q | pos.az.alt                   |  Alt-azimutal altitude
> Q | pos.az.azi                   |  Alt-azimutal azimut
> Q | pos.az.zd                    |  Alt-azimutal zenith distance

If I understand the work of the general relativists who have been
contributing to various IAU initiatives over the past two decades then
all of the above quantities do not have precisely-defined meanings.
There is no mathematical framework for a rigorous mapping of celestial
sphere to observation angles which is valid at the microarcsecond
level.

The meaning of hour angle has been called into question at
a precision much less tight by the IAU 2000 redefinition of UT1
and the introduction of the CIO/CEO- and TIO/TEO- based
expressions.  There is an active IAU committee trying to work
out nomenclature for the "classical" vs. the "CIO-based"
versions of these sorts of quantities.

Should the definitions of these admit that they may
not be meaningful at the milliarcsecond level and give
references to the draft documents which explain why?

On Tue 2005-06-28T15:16:26 +0200, Pierre Didelon hath writ:

> A.3.1 pos.earth
>  Q | pos.earth.lon                |  Longitude on Earth
> exists but not latitude!
> Q | pos.earth.altitude           |  Altitude on Earth
> exists but not distance which give the distance to the center
>
> A.3.2 lon/lat/alt/dist

In the context of FITS WCS Paper III we decided that it was not a good idea
to admit the concepts of latitude, longitude, and height into the
standard.

(Note, by the way that I strongly prefer to use the term "height" rather
than "altitude" or "elevation".  The geodetic community also uses "height"
at least in part to avoid confusion with the other two, which may be angles.)

Unless there is also a UCD word something like pos.earth.geodatum it is not
possible to associate a precise meaning with .lon, .lat, and .alt

As we point out in FITS WCS Paper III, there are something like 1000
different geodetic datums in use, and some of their positions differ
from each other by kilometers.  Rather than burden FITS with the need
to recognize even a small subset of those datums we decided to omit
angular body coordinates and stick to Cartesian coordinates only.

True, even Cartesian coordinates technically require the specification
of a datum, but in current usage all the Cartesian terrestrial datums
differ by only about 0.1 m.

I recognize that there is a very strong tradition for the use of
angular body coordinates, but if precise meaning is required they
are not a good idea.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99858
University of California    Voice: +1 831 459 3046           Lng -122.06014
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m


From seaman at noao.edu  Tue Jun 28 20:25:31 2005
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 28 Jun 2005 20:25:31 -0700
Subject: Draft list of ucd-words
In-Reply-To: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
Message-ID: <4B410189-D4C3-4D71-8F7E-3B0ADA7A2CD5@noao.edu>

On Jun 24, 2005, at 5:53 AM, Andrea Preite Martinez wrote:


> Of course the discussion is not over, but unfortunately we need a  
> rather "stable" version soon.
>

I'm concerned about the general nature of the UCDs in the list.  It  
seems to me that the most useful quantities are those such as em.opt. 
[UBVRI] that have the broadest or most empirically determined  
definitions.  Steve points out the shortcomings of several of the  
more precisely definable quantities.  Many of these require some more  
complicated data structure to even attempt to describe the underlying  
physics.  A simple scalar will never suffice.  For instance, Steve  
picks apart several of the WCS related UCDs.

What is the precise benefit to the VO or its users of selecting UCDs  
to convey these quantities rather than STC elements?  Note that I'm  
not seeking to reopen the "UCDs are not XML" discussion - rather, in  
a loose analogy in which XML represents a variety of data types and  
UCDs represent names, what is the point of providing names for scalar  
quantities that are of no utility standing by themselves?  I suppose  
you could attach a UCD to a more complicated XML (or other kind of)  
data structure - but how would that work exactly?  Wouldn't this  
possibility need to be reflected within the UCD mechanism itself?

The other thing about "em.opt.B" is that it represents a quantity  
whose definition is completely within the control of the  
international astronomical community.  Other than additionally  
specifying exactly what it is whose measured Johnson B magnitude is  
being quoted (some object through some aperture), there is no  
intrinsic ambiguity.  Some of the other quantities "belong" to non- 
astronomical constituencies at least as much as they belong to us.

Not trying to make trouble - please point me to a document or  
discussion thread if such carping is old news.

Rob Seaman
NOAO



From pdidelon at cea.fr  Wed Jun 29 01:14:45 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 29 Jun 2005 10:14:45 +0200
Subject: Draft list of ucd-words
In-Reply-To: <20050628221311.GA12268@ucolick.org>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org>
Message-ID: <42C25875.80501@cea.fr>



Steve Allen wrote:

> On Fri 2005-06-24T14:53:46 +0200, Andrea Preite Martinez hath writ:
...
>>S | pos.earthop                  |  Earth orientation parameters
>>Q | pos.earthop.nutation         |  Earth nutation
> 
> These specifications seem incomplete, but I'm not sure what
> they are supposed to be communicating.

open corresponding items ( pos.eop, pos.eop.nutation, pos.eop.pole )
at http://www.imcce.fr/fr/expert/ssvo/wgovp/ucdtree.html to see more possible elements.
Passing the mouse over the proposed UCD display a few words meaning in the upper part
of the window ;-)

> 
> As a starter for discussion, does nutation refer to
> IAU 2000A model,  IAU 2000B model, or the models resulting from
> the FK5-based revision performed between 1976/1984, or
> the nutation based on the older Newcomb models of precession, or what?
> 
> Is polar motion and UT1 relevant?  Do they use the IAU 2000 models, or
> one of the older forms used in previous versions of the IERS
> conventions, or the even older FK5 forms, or what?
> 
> 
>>Q | pos.eq.ha                    |  Hour-angle
> 
> 
>>Q | pos.az                       |  Position in alt-azimutal frame
>>Q | pos.az.alt                   |  Alt-azimutal altitude
>>Q | pos.az.azi                   |  Alt-azimutal azimut
>>Q | pos.az.zd                    |  Alt-azimutal zenith distance
> 
> 
> If I understand the work of the general relativists who have been
> contributing to various IAU initiatives over the past two decades then
> all of the above quantities do not have precisely-defined meanings.
> There is no mathematical framework for a rigorous mapping of celestial
> sphere to observation angles which is valid at the microarcsecond
> level.
Perhaps, but a lot of measurements with much less accuracy exist.
UCD has not the goal to replace STC or any equivalent,
only give some (not all) informations about used quantity.
> 
> The meaning of hour angle has been called into question at
> a precision much less tight by the IAU 2000 redefinition of UT1
> and the introduction of the CIO/CEO- and TIO/TEO- based
> expressions.  There is an active IAU committee trying to work
> out nomenclature for the "classical" vs. the "CIO-based"
> versions of these sorts of quantities.
> 
> Should the definitions of these admit that they may
> not be meaningful at the milliarcsecond level and give
> references to the draft documents which explain why?
> 
> On Tue 2005-06-28T15:16:26 +0200, Pierre Didelon hath writ:
> 
> 
>>A.3.1 pos.earth
>> Q | pos.earth.lon                |  Longitude on Earth
>>exists but not latitude!
>>Q | pos.earth.altitude           |  Altitude on Earth
>>exists but not distance which give the distance to the center
>>
>>A.3.2 lon/lat/alt/dist
> 
> 
> In the context of FITS WCS Paper III we decided that it was not a good idea
> to admit the concepts of latitude, longitude, and height into the
> standard.
> 
> (Note, by the way that I strongly prefer to use the term "height" rather
> than "altitude" or "elevation".  The geodetic community also uses "height"
> at least in part to avoid confusion with the other two, which may be angles.)
Whatever is the choosen term, it is needed, even in STC, at least to specify
the altitude of the observing place.
> 
> Unless there is also a UCD word something like pos.earth.geodatum it is not
> possible to associate a precise meaning with .lon, .lat, and .alt
> 
> As we point out in FITS WCS Paper III, there are something like 1000
> different geodetic datums in use, and some of their positions differ
> from each other by kilometers.  Rather than burden FITS with the need
> to recognize even a small subset of those datums we decided to omit
> angular body coordinates and stick to Cartesian coordinates only.
> 
> True, even Cartesian coordinates technically require the specification
> of a datum, but in current usage all the Cartesian terrestrial datums
> differ by only about 0.1 m.
> 
> I recognize that there is a very strong tradition for the use of
> angular body coordinates, but if precise meaning is required they
> are not a good idea.
> 
> --
> Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
> UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99858
> University of California    Voice: +1 831 459 3046           Lng -122.06014
> Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m 
								^
                                                                 |
   perhaps not precise enough, but nevertheless usefull quantities ;-)

-- 
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/
------------------------------------------------------------------
Puiss?-je toujours marcher avec la beaut? devant moi.
    Dicton Navajo   Tony Hillerman - Les clowns sacr?s
------------------------------------------------------------------




From roy at cacr.caltech.edu  Wed Jun 29 03:19:00 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Wed, 29 Jun 2005 03:19:00 -0700
Subject: Draft list of ucd-words
In-Reply-To: <42C25875.80501@cea.fr>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr>
Message-ID: <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu>

I see questions on this list about precise definitions of UCD, and I do 
not think it is relevant. We are not building a self-consistent data 
model of astronomy, but rather we are pragmatically taking the list of 
quantities that real astronomers have used in 5000 real tables at 
Vizier.

  If a table is published in ApJ that defines the "altitude" of their 
observatory (pos.earth.altitude), it is not for us to say the writer 
was a fool, it is for us to make sure there is a UCD for that concept.

Similarly, the STC is irrelevant here. If astronomical tables contain 
RA and Dec, then there should be pos.eq.ra and pos.eq.dec. It is not 
for us to say that RA and Dec do not always have unambiguous 
definitions.


California Institute of Technology
626 395 3670
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 854 bytes
Desc: not available
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050629/93771521/attachment.bin>

From seaman at noao.edu  Wed Jun 29 08:47:17 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 29 Jun 2005 08:47:17 -0700
Subject: Draft list of ucd-words
In-Reply-To: <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu>
Message-ID: <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>

Hi Roy,

> I see questions on this list about precise definitions of UCD, and  
> I do not think it is relevant. We are not building a self- 
> consistent data model of astronomy, but rather we are pragmatically  
> taking the list of quantities that real astronomers have used in  
> 5000 real tables at Vizier.

That's precisely my point.  If the idea is merely to construct a  
complete (and indeed, consistent) list of the minimal number of  
identifiers necessary to capture some large (and growing) set of  
tables from the astronomical literature - well, then, what is the  
point of discussion at all?  Harvest all the identifiers, correct  
typos, remove synonyms and you're done. Rather, we appear to be  
chartered to do something different - to construct a poor man's  
ontology.  Certainly UCDs are often offered up as the pragmatic path  
out of ontological jungles.

>  If a table is published in ApJ that defines the "altitude" of  
> their observatory (pos.earth.altitude), it is not for us to say the  
> writer was a fool, it is for us to make sure there is a UCD for  
> that concept.

Right - and I agree with Steve that this should rather be called  
"height".  But this begs the question of whether we need to provide  
UCDs for *both* height above the Earth's surface *and* distance from  
its center.  And dozens of other questions for this one little  
identifier such as how (or whether) to express the shape of the earth  
such that "height" from one table means even approximately the same  
thing as "altitude" from another.

> Similarly, the STC is irrelevant here. If astronomical tables  
> contain RA and Dec, then there should be pos.eq.ra and pos.eq.dec.  
> It is not for us to say that RA and Dec do not always have  
> unambiguous definitions.

But naming has the implication of defining.  By attaching the same  
UCD to values from two different tables we are asserting that for  
[all | most | many | some | any] purposes that these values represent  
identical "things".  Certainly VO users will take it this way.  Why  
else provide common class identifiers other than to assert a common  
class?

We are clearly seeking some semantic middle ground between  
instantiating a separate UCD for each column of each table (e.g.,  
Hertzsprung.1947.fig_1.pos.eq.ra) and the evanescent dream of a full  
astronomical ontology.  If that is not the case, I would argue that  
rather than seat a committee to decide these issues that some purely  
mechanical process be sought to convert the column headings from each  
month's new batch of tables from the literature into UCDs.

I think we are precisely building a simple kind of data model of  
astronomy.  It is indeed intended to be self-consistent, but  
certainly not to be complete (either in extent or expressive  
ability).  Ideally we will understand the holes in the data model as  
well as the consensus descriptors.  In general, holes should be left  
where simple UCD expressions don't suffice.  We will fail if we aim  
too close to completeness.  We will also fail if the UCD "data  
model" (or whatever folks want to call it) diverges too far from a  
coherent expression of the domain of astronomy.

The quickest way to wrap up the current exercise is to severely limit  
the list of UCDs to only contain the least controversial.  If columns  
from 5000 tables have left holes in the list of UCDs, one might  
expect that this reflects underlying difficulties of astronomical  
semantics that we will not more easily overcome.

The way to extend a robust UCD process into the future is to provide  
an explicit namespace mechanism from the start.  This will allow  
capturing controversial or peripheral identifiers such as VOConcept,  
but will also allow us to wipe the etch-a-sketch clean with new  
version(s) of subject dependent list(s) of UCDs.  If later we decide  
that v1:pos.earth.height should indeed have been  
v2:pos.earth.altitude, there needs to be a lightweight way to make  
the transition.  This is also the way to ensure a speedy process in  
the future.  The alternative is a heavyweight process such as FITS  
standardization - talk about it for ten years and still leave some  
folks unhappy and eager to violate the standard.

Better an incomplete list of UCDs than an incorrect one.  Better two  
lists than one.

Rob Seaman
NOAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050629/8c2097a8/attachment.html>

From roy at cacr.caltech.edu  Wed Jun 29 09:27:51 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Wed, 29 Jun 2005 09:27:51 -0700
Subject: Draft list of ucd-words
In-Reply-To: <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
Message-ID: <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu>

> By attaching the same UCD to values from two different tables we are 
> asserting that .....  these values represent identical "things".?

We are asserting that there exists a context in which they are the 
same. Question: In what context is an R-magnitude and a B-magnitude the 
same thing? Answer: when you count photons without regard to their 
wavelength.

> some purely mechanical process be sought to convert the column 
> headings from each month's new batch of tables from the literature 
> into UCDs.

That was the original conception. The only structure was some grouping. 
Then we tried to get clever, and replaced the single UCD "magnitude 
error" by two components ("magnitude" and "error"). That was the 
slippery slope towards a data model. And here we are up to our asses in 
ontological alligators!

> .....  building a simple kind of data model of astronomy.
> ..... evanescent dream of a full astronomical ontology

I don't think these things are possible.  Everyone has their own 
opinion. It would be too complex and unwieldy.

> The way to extend a robust UCD process into the future is to provide 
> an explicit namespace mechanism from the start.?

We tried this before about 2 years ago, but it was vetoed. The problem 
with namespace is that it reduces interoperability -- there was a fear 
that everyone would simply use their own namespace.

Roy


From seaman at noao.edu  Wed Jun 29 09:55:50 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 29 Jun 2005 09:55:50 -0700
Subject: Draft list of ucd-words
In-Reply-To: <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu>
Message-ID: <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu>

Roy says;

> We are asserting that there exists a context in which they are the  
> same. Question: In what context is an R-magnitude and a B-magnitude  
> the same thing? Answer: when you count photons without regard to  
> their wavelength.

Photon counting and the logarithmic ratios of the magnitude scale are  
very different beasts.  If you are going to pursue photon counting  
you are likely to end up with something resembling IRAF's QPOE  
interface.  Similarly with expressing world coordinates - there is an  
irreducible core of complexity.  The way to deal with this is to  
embrace the complexity, not attempt to implement false simplicity.

> The problem with namespace is that it reduces interoperability --  
> there was a fear that everyone would simply use their own namespace.

There are 340+ sessions here at JavaOne - and something like 340  
different - and differently named - java class libraries and other  
"thingies" being discussed.  Many of these overlap each other.  It  
hasn't seemed to hurt the 15,000 attendees any.  Folks may well  
define utilitarian namespaces willy-nilly for purposes internal to  
their own projects.  They will, however, gravitate toward a few  
standard choices for any expressions that need to be shared with the  
larger VO community.

You aren't describing a problem - you describe an opportunity.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050629/845d8d19/attachment.html>

From roy at cacr.caltech.edu  Wed Jun 29 10:19:47 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Wed, 29 Jun 2005 10:19:47 -0700
Subject: Draft list of ucd-words
In-Reply-To: <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu> <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu>
Message-ID: <f5a90ee216b455d3dd3c9142cccec07e@cacr.caltech.edu>

>> We are asserting that there exists a context in which they are the 
>> same. Question: In what context is an R-magnitude and a B-magnitude 
>> the same thing? Answer: when you count photons without regard to 
>> their wavelength.
> Photon counting and the logarithmic ratios of the magnitude scale are 
> very different beasts.? If you are going to pursue photon counting you 
> are likely to end up with something resembling IRAF's QPOE interface.? 
> Similarly with expressing world coordinates - there is an irreducible 
> core of complexity.? The way to deal with this is to embrace the 
> complexity, not attempt to implement false simplicity.

OK I am showing my ignorance of what magnitude exactly means. But it 
sounds like you are taking a hard line that the concept of "magnitude" 
is meaningless by itself, and has no place in the UCD list. Surely it 
has some rigorous definition in terms of photons or flux or energy or 
SOMETHING? And therefore a context in which they can be compared.

And what is wrong with world coordinates? We have UCDs for CRVAL and 
CRPIX and CTYPE and all those good WCS keywords.  Are they also so 
poorly defined as to be useless? They are well-defined in the 
Calabretta papers, aren't they?

>> The problem with namespace is that it reduces interoperability -- 
>> there was a fear that everyone would simply use their own namespace.
>
> You aren't describing a problem - you describe an opportunity.

The namespaces for UCD was my suggestion. I was voted down.



From norman at astro.gla.ac.uk  Wed Jun 29 10:32:14 2005
From: norman at astro.gla.ac.uk (Norman Gray)
Date: Wed, 29 Jun 2005 18:32:14 +0100
Subject: Draft list of ucd-words
In-Reply-To: <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
Message-ID: <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>


Greetings,

On 2005 Jun 29 , at 16.47, Rob Seaman wrote:

>>  If a table is published in ApJ that defines the "altitude" of  
>> their observatory (pos.earth.altitude), it is not for us to say  
>> the writer was a fool, it is for us to make sure there is a UCD  
>> for that concept.
>
> Right - and I agree with Steve that this should rather be called  
> "height".

The Gene Ontology folk have described a few key ideas that helped  
them create a big and very successful ontology.  Though GO has  
problems -- some quite fundamental -- non-ontologists do actually use  
it to do actual science.  Some of these `rules' are rather obvious,  
such as `involve users', but Rob's message is a hook for a couple of  
the non-obvious ones.

GO uses opaque labels for every concept, so that pos.earth.altitude  
and pos.earth.height would both be ucd12345 or something.  They do  
this (i) to avoid arguments about which noun it should be, (ii) so  
they can version them easily (when are we going to have fight about  
replacing pos.earth.height with pos.earth.height2? whereas no-one has  
a sentimental attachment to ucd12345), (iii) so users aren't tempted  
to use their intuition about what the labels mean, and are forced to  
use the project's tools to discover and resolve labels, and (iiia) to  
make it transparently clear to everyone that the label really doesn't  
matter -- it's just a string which keys to a careful description  
elsewhere.

I'm not suggesting replacing all the UCDs with numbers (don't worry),  
but suggesting that it might be best to avoid `obvious' names, and  
even that it might be a virtue than a vice to have names which are  
mnemonic but still vague enough to force folk to look up careful  
definitions _before_ they use them.

> But this begs the question of whether we need to provide UCDs for  
> *both* height above the Earth's surface *and* distance from its  
> center.

Agreeing with what I take to be Rob's argument, I think this is  
settled by an observation that these distinct concepts do or do not  
appear in multiple published tables, where `multiple' represents some  
vague threshold number less than ten but definitely more than one.

> And dozens of other questions for this one little identifier such  
> as how (or whether) to express the shape of the earth such that  
> "height" from one table means even approximately the same thing as  
> "altitude" from another.

However I think any discussion about the geoid implies an attempt to  
push UCDs well beyond what I believe to be their valuably constrained  
scope.  Thus the description of pos.earth.height should carefully  
_not_ say which datum it is relative to, and draw attention to the  
fact that it is not saying this!

This is because...

>  By attaching the same UCD to values from two different tables we  
> are asserting that for [all | most | many | some | any] purposes  
> that these values represent identical "things".

It seems to me that the purpose in question is `find tables I might  
be interested in', and that the equivalence relation here is not one  
of identity.  My perception is that the UCD word set has been  
successful, and should remain successful, to the extent that it  
abides by two principles: that the word list is small enough and  
mnemonic enough that folk are likely to remember a respectable  
proportion of the words, and that it service those use-cases where  
false positives are good.  That set includes searching for tables,  
and excludes driving processing.

It might be a bit late to edit things now, but I have said before  
that I feel the UCD document would benefit from a bolder statement of  
its scope, and of its non-goals.

> The way to extend a robust UCD process into the future is to  
> provide an explicit namespace mechanism from the start.  This will  
> allow capturing controversial or peripheral identifiers such as  
> VOConcept, but will also allow us to wipe the etch-a-sketch clean  
> with new version(s) of subject dependent list(s) of UCDs.  If later  
> we decide that v1:pos.earth.height should indeed have been  
> v2:pos.earth.altitude, there needs to be a lightweight way to make  
> the transition.

Hear, hear.  One of the other GO maxims -- up there with `involve the  
users' -- was `version the ontology'.  It seems the GO is in more-or- 
less continuous flux, but this simply doesn't matter, because they  
recognised at the outset that they were going to have to do this, and  
so designed their formalism and tools to cope/help with it.

I hope this helps.  All the best,

Norman


-- 
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk



From seaman at noao.edu  Wed Jun 29 10:51:55 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 29 Jun 2005 10:51:55 -0700
Subject: Draft list of ucd-words
In-Reply-To: <f5a90ee216b455d3dd3c9142cccec07e@cacr.caltech.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu> <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu> <f5a90ee216b455d3dd3c9142cccec07e@cacr.caltech.edu>
Message-ID: <50C96AD6-350E-4D76-AEED-A3C088197FA0@noao.edu>

Roy says:

> OK I am showing my ignorance of what magnitude exactly means. But  
> it sounds like you are taking a hard line that the concept of  
> "magnitude" is meaningless by itself, and has no place in the UCD  
> list. Surely it has some rigorous definition in terms of photons or  
> flux or energy or SOMETHING? And therefore a context in which they  
> can be compared.

No, magnitudes are fine - precisely because they have a fuzzy  
definition.  What I was apparently arguing only poorly was that more  
interesting things like photon counting are harder to represent using  
simple scalar quantities/names or lists (even hierarchical lists) of  
same.

> And what is wrong with world coordinates? We have UCDs for CRVAL  
> and CRPIX and CTYPE and all those good WCS keywords.  Are they also  
> so poorly defined as to be useless? They are well-defined in the  
> Calabretta papers, aren't they?

I'm situated in a rather awkward location in the Moscone Center and  
the wifi keeps cutting out, so I won't try to reply in detail, but  
surely it would be better to provide a single identifier to a  
complete WCS data structure than to label each separate piece of  
same?  But fundamentally I was just attempting so add a "me, too" to  
Steve's much more cogently worded reply.  If he isn't panicking -  
neither am I.

> The namespaces for UCD was my suggestion. I was voted down.

Maybe it's time to have another vote.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd-sci/attachments/20050629/e99e2897/attachment.html>

From hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun 29 23:13:22 2005
From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman)
Date: Thu, 30 Jun 2005 08:13:22 +0200
Subject: Draft list of ucd-words
In-Reply-To: <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
Message-ID: <8421f512d315809626d3b4cc3bc809a3@astro.physik.uni-goettingen.de>

>> The way to extend a robust UCD process into the future is to provide  
>> an explicit namespace mechanism from the start.  This will allow  
>> capturing controversial or peripheral identifiers such as VOConcept,  
>> but will also allow us to wipe the etch-a-sketch clean with new  
>> version(s) of subject dependent list(s) of UCDs.  If later we decide  
>> that v1:pos.earth.height should indeed have been  
>> v2:pos.earth.altitude, there needs to be a lightweight way to make  
>> the transition.
>
> Hear, hear.  One of the other GO maxims -- up there with `involve the  
> users' -- was `version the ontology'.  It seems the GO is in  
> more-or-less continuous flux, but this simply doesn't matter, because  
> they recognised at the outset that they were going to have to do this,  
> and so designed their formalism and tools to cope/help with it.

(back on-line after a painful move of our entire institute)

I confess that even I can see the advantages of this in principle - and  
I was the most vociferous complainer about opaque UCD's.
However, I'm not crazy about numbering the concepts - yet another layer  
of naming, this time utterly random in
appearance - and I'm not quite sure how versioning is going to function  
in practice.  On the other hand, if GO works, then
what can one say?

Rick

------------------------------------------------------------------------ 
------------------------
                                             NEW ADDRESS!!!
------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman     Hessman at Astro.physik.Uni-Goettingen.DE
Institut f?r Astrophysik          Tel.  +49-551-39-5052
Friedrich-Hund-Platz 1         Fax +49-551-39-5043
37077 Goettingen
http://www.Astro.physik.Uni-Goettingen.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de
------------------------------------------------------------------------ 
-------------------------



From pdidelon at cea.fr  Thu Jun 30 01:13:48 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Thu, 30 Jun 2005 10:13:48 +0200
Subject: Draft list of ucd-words
In-Reply-To: <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
Message-ID: <42C3A9BC.3050009@cea.fr>



Norman Gray wrote:

> 
> Greetings,
> 
> On 2005 Jun 29 , at 16.47, Rob Seaman wrote:
> 
>>>  If a table is published in ApJ that defines the "altitude" of  their 
>>> observatory (pos.earth.altitude), it is not for us to say  the writer 
>>> was a fool, it is for us to make sure there is a UCD  for that concept.
>>
>>
>> Right - and I agree with Steve that this should rather be called  
>> "height".
> 
> 
> The Gene Ontology folk have described a few key ideas that helped  them 
> create a big and very successful ontology.  Though GO has  problems -- 
> some quite fundamental -- non-ontologists do actually use  it to do 
> actual science.  Some of these `rules' are rather obvious,  such as 
> `involve users', but Rob's message is a hook for a couple of  the 
> non-obvious ones.
> 
> GO uses opaque labels for every concept, so that pos.earth.altitude  and 
> pos.earth.height would both be ucd12345 or something.  They do  this (i) 
> to avoid arguments about which noun it should be, (ii) so  they can 
> version them easily (when are we going to have fight about  replacing 
> pos.earth.height with pos.earth.height2? whereas no-one has  a 
> sentimental attachment to ucd12345), (iii) so users aren't tempted  to 
> use their intuition about what the labels mean, and are forced to  use 
> the project's tools to discover and resolve labels, and (iiia) to  make 
> it transparently clear to everyone that the label really doesn't  matter 
> -- it's just a string which keys to a careful description  elsewhere.
> 
> I'm not suggesting replacing all the UCDs with numbers (don't worry),  
> but suggesting that it might be best to avoid `obvious' names, and  even 
> that it might be a virtue than a vice to have names which are  mnemonic 
> but still vague enough to force folk to look up careful  definitions 
> _before_ they use them.
> 

Agree ;-)
"the Word is not the Thing it represents"
(Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics,
1933, Alfred KORZYBSKI)
or "the word dog doesn't bite".
The words didn't really matter if we agree about the descriptions/definitions.

>> The way to extend a robust UCD process into the future is to  provide 
>> an explicit namespace mechanism from the start.  This will  allow 
>> capturing controversial or peripheral identifiers such as  VOConcept, 
>> but will also allow us to wipe the etch-a-sketch clean  with new 
>> version(s) of subject dependent list(s) of UCDs.  If later  we decide 
>> that v1:pos.earth.height should indeed have been  
>> v2:pos.earth.altitude, there needs to be a lightweight way to make  
>> the transition.
> 
> 
> Hear, hear.  One of the other GO maxims -- up there with `involve the  
> users' -- was `version the ontology'.  It seems the GO is in more-or- 
> less continuous flux, but this simply doesn't matter, because they  
> recognised at the outset that they were going to have to do this, and  
> so designed their formalism and tools to cope/help with it.

Descriptions can change, as a lot of things... including our minds :-)
> 
> I hope this helps.  All the best,

I allways appreciate your interventions.
> 
> Norman
> 
> 

-- 
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------
La carte n'est pas le territoire - Alfred KORZYBSKI
------------------------------------------------------------------




From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:24:01 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:24:01 +0200
Subject: T0 : extensions to em, obs, spect, instr
Message-ID: <20050601092401.q3m7lpliuw84sssw@webmail.sic.rm.cnr.it>

Msg sent by:
    Data: Mon, 30 May 2005 13:06:23 +0200
    Da: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
Rispondi-A: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
 Oggetto: T0 : extensions to em, obs, spect, instr
      A: ucd at ivoa.net

1. I suggest we rename em from "electromagnetic spectrum" to "emission"
and add

		em.grav-wave			(gravitational wave)
		em.neutrino			(neutrino)

	Alternatively, add

		phys.grav-wave			(gravitational wave)
		phys.particle				(particle emission)
		phys.particle.cosmic-ray
		phys.particle.neutrino
		...?

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)

	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)

	We already have spect.line.


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
------------------------------------------------------------------------
-------------------------



----- End of forwarded mail. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:24:41 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:24:41 +0200
Subject: Fwd: Txx
Message-ID: <20050601092441.99iuzngajagowosc@webmail.sic.rm.cnr.it>



----- Messaggio inoltrato da Hessman at Astro.physik.Uni-Goettingen.DE -----
    Data: Mon, 30 May 2005 13:23:44 +0200
    Da: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
Rispondi-A: "Frederic V. \\Rick\\ Hessman"
<Hessman at Astro.physik.Uni-Goettingen.DE>
 Oggetto: Txx
      A: ucd at ivoa.net

Again, because of VOEvent and RTML, I'd like to suggest we include at
least

	event				(physical or observational event)
	event.burst			("sudden" observed change in state)
	event.chirp			(continuous change in frequency)
	event.discovery		(discovery of previously unknown object)
	event.eclipse			(intrinsic eclipse of physically related objects)
	event.eruption			("sudden" physical change in state resulting in
more/less observed emission)
	event.explosion		(physical explosion)
	event.glitch			(discontinuous change in frequency)
	event.occulation		(extrinsic occulation of physically unrelated
objects)
	event.variation			(variation in some observable property)
	event.variation.phot		(photometric variation)
	event.variation.pos		(astrometric shift in position)
	event.variation.spect	(spectroscopic variation)

If we're going to have solar system UCD's, then it's only fair to have
stellar and
extragalactic ones:  I suggest looking at

	http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/
UnifiedContentDescriptors

were there are unit UCD's like "stars", "ism", "galaxy" (as in milky
way), "galaxies", and "cosmology".
Yes, we don't have to adopt ALL of them, but it would help to have the
basic ones.

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
------------------------------------------------------------------------
-------------------------



----- Fine messaggio inoltrato. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:27:04 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:27:04 +0200
Subject: Inoltro: SciBoard
Message-ID: <20050601092704.10nrsjdzawis0gog@webmail.sic.rm.cnr.it>



----- Messaggio inoltrato da jcm at head.cfa.harvard.edu -----
    Data: Mon, 30 May 2005 15:38:49 -0400 (EDT)
    Da: Jonathan McDowell <jcm at head.cfa.harvard.edu>
Rispondi-A: Jonathan McDowell <jcm at head.cfa.harvard.edu>
 Oggetto: SciBoard
      A: andrea at rm.iasf.cnr.it


Andrea.
 very slow email connection here at aas..
>
> A. Roadmap.
> Our goal is very simple: we need to stabilize (which means adding,
deleting,
> transforming ) the present draft list of  ucd-words, that you can find at
>
> http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt  (just the list)
> http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCDlist-20050429.pdf (the WD
> document)
>
> in order to (i) reach  consensus, and (ii) be able to promote the list
(and
> the associated document) to the level of IVOA Proposed Recommendation as
> soon as possible (within June).

OK. Doesn't need to be complete right?: in other words deleting
and transforming are more important than adding, which can be done later.


>
> B. The Board
> 1. Duration.
> There will be a Sci-Board as long as UCDs will be in use in the VO, in
order
> to maintain the vocabulary. The mission of the board is described in the
> main UCD document, that you can find at
>
> http://www.ivoa.net/Documents/latest/UCD.html
>
> now under minor revisions as suggested during the Exec Meeting in Kyoto.
> It is possible that in the future the Exec could change the mission to
suit
> new needs of the VO.

Agreed.

>
> 2. Participation.
> Participation is on a voluntary basis. Colleagues can ask the chair of the
> Board to be inserted in (or deleted from) the mailing list of the Board,
> and to work for a specific task (see below).
>
> 3. Chair
> For the transition period required to set up the Board and let it run, I
> will act as chair person of the Board (by the way,  setting up the Board
> and upgrading the present list of UCD-words to the level of IVOA PR is a
> formal action for the chairman of the UCD-WG). I propose to go for an
> election of the chairman of the Board in a month from now.
>
> C. Organization
> 1. What (Tasks)
> Time is very short, at least for this first phase of our work. I propose
> then to define a number of key tasks and form task-groups on different
> aspects of the vocabulary. The most urgent cases were well pinned down
> during the last InterOp Meeting. My first draft proposal is to organize
our
> work around the following tasks:
>
> T1: the "velocity" and the resolution(s) problems
> T2: theory and simulations (sim ?)
> T3: at/mol physics
> T4: curation (humans, organizations) and other "meta"-likes
> T5: flux (total, net, backgr. and various "flux densities") and time
(period
> of, instant of)
> T6: solar system
> Txx : ??

OK

> T0: Coordination, general issues, not included in the above Ts.
> Like the Board, tasks are not "closed". The discussion is open ("plenary")
> and contributions are welcome from every member of the Board. It will help
> people with an analytical mind (like mine!) to see "T5" appear in the
> subject of your message, if dealing with "net flux" or mid-time of
> exposure.
>
> We need a coordinator for each task, with the responsibility to make a
final
> proposal to the Board.
> There is nothing formal in the following list of people, I'm just asking
> them to pay more attention to the discussion relevant to the corresponding
> task, and summarize the discussion to the Board in due time.
> Making use of the list of members (as of today) I propose the following
> coordinators:
>
> T0	General		Andrea
> T1	Velocity/resolution	Alberto Micol
> T2	Theory/simulations	Volunteer(?)
> T3	At/Mol physics	Marie-Lise Dubernet
> T4	Meta			S?bastien D.
> T5	flux/time		Jonathan MD
> T6	Solar system		Pierre Didelon
>

Agreed.
Gerard, or Laurie Shaw maybe, as theory?

> 2. How
> Through the Board's mailing list. Always "reply to all". The chair will
> record all messages.
> In this first phase of our work time is very short. So please answer
within
> the given deadlines. We won't wait for late messages.

You need to make a "ucd-board at ivoa.net" mailing list so we
don't have to all rely on 'reply' working right.
I guess Markus or Marco can help with that?

>
> 3. When
> FIRST ACTION: please comment on the above organization/rules/tasks within
> Thursday the 2nd of June.

Comments above. Basically fine.
  Jonathan

>
> This message is sent (for the last time) also to the wider
interop at ivoa.net
> community to ask the laziest to join in.
>
> Best regards
>
> Andrea


Solar System UCDs (really Astronomical Object UCDs):
they will not be UCDs per the PR. But IVOA may need such a list
and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
group doesn't want to take that work on, the DM group should
probably do it. I think either group could do it, provided we
keep the distinction between the two lists (UCDs, as semantics
for astronomical non-object concepts, and the other list,
as semantics for astronomical objects).

 - Jonathan


----- Fine messaggio inoltrato. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================



From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 00:27:55 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 09:27:55 +0200
Subject: Fwd: SciBoard
Message-ID: <20050601092755.aupeljrjs9pcg04o@webmail.sic.rm.cnr.it>



----- Messaggio inoltrato da derriere at newb6.u-strasbg.fr -----
    Data: Tue, 31 May 2005 10:35:14 +0200
    Da: Sebastien Derriere <derriere at newb6.u-strasbg.fr>
Rispondi-A: Sebastien Derriere <derriere at newb6.u-strasbg.fr>
 Oggetto: Re: Inoltro: SciBoard
      A: Andrea Preite Martinez <andrea.preitemartinez at rm.iasf.cnr.it>,
jcm at head.cfa.harvard.edu

>
> Solar System UCDs (really Astronomical Object UCDs):
> they will not be UCDs per the PR. But IVOA may need such a list
> and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
> group doesn't want to take that work on, the DM group should
> probably do it. I think either group could do it, provided we
> keep the distinction between the two lists (UCDs, as semantics
> for astronomical non-object concepts, and the other list,
> as semantics for astronomical objects).
>

  Hi Jonathan,

  There might be a slight misunderstanding on this.
The planetary system community has worked on their needs
to express the quantities they are measuring in their field
with proper UCDs. You can see the result of this reflexion
here:
http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html
  I think these suggestions are worth examining, and they seem
quite mature: why not taking them into account for the PR.
  I am less confident that we can incorporate in the PR all the
astronomical object types/phenomenons that were discussed
for VOEvent (is this what you call "semantics for astronomical
objects"?).

Sebastien.

-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


----- Fine messaggio inoltrato. -----


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


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!)

	<src ucd="src.class.galaxy.spiral" name="NGC12345"/>

This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and  
usefulness to having a VOTable
which contains some entry identified as meaning some physical property.  
  This is totally different
from having a DM/ontology which says what it means to have a spiral  
galaxy or what properties are
associated with a spiral galaxy or whether the name makes any sense.   
Of course UCD isn't a name
resolver, but if isn't a concept resolver, what is it? Why are some  
concepts more equal than others?

What we have now is the possibility

	<src name="NGC12345">
		<type ucd="src.class">spiral galaxy</type>
	</src>

and who says what "spiral galaxy" means?  Who has to parse a different  
object where the type is
"galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....    
Wouldn't life be so easy if we could just
say that there is a UCD "src.class.galaxy.spiral"?

To say that UCD should NOT do the first (say that something is a spiral  
galaxy) but should do the latter
(say that a table entry is a radial velocity) means that UCD is only  
intended to be
used for tables and catalogues.  If this is the foundation of this  
list, then please remove me.

Yes, we shouldn't throw together a list of random concepts and declare  
our work done.  So, please
complain if you don't like my suggestions.   But isn't the whole point  
of ucd-sci to determine what astronomical
concepts need to be expressable?

>>> Looks like you are trying to define a data model for observation
>>> and data reduction with UCD... which is perhaps not the best way to  
>>> go?
>> Absolutely NOT!!!!  I just want to be able to say what something is,
> Not only!
> For example obs.calib.dome-flat is certainly an image (or may be a  
> spectra?)
> which have been obtained under specific conditions and used in a  
> precise context
> to derive reduced data. It describe only a "personnal" point of view  
> of the way a
> piece of data can be used!

But the point is that the original purpose of the observation has been  
expressed.
Whether it's an image, a spectrum, or simply a number can be extracted  
from all the
other metadata.   If you don't have "obs.calib.dome-flat", then you're  
left with scanning
the FITS header for OBJECT="DOMEFLT", OBJECT="DFLAT", OBJECT="DOMFLAT",
OBJECT="FLAT-DOME", ....

> But take an image obs.calib.sky-flat (sky-flat observation), although  
> its main
> usage will be calibration nobody can assert that some project can use  
> these data
> for other purposes,  even scientific ones : variability event follow  
> up, historical
> tracing back, proper motion detection... or whatever else we are not  
> already
> thinking or aware of.

Ah, but if I'm looking for a bright GRB in daytime observations,  
knowing that the image
is an obs.calib.sky-flat makes tremendous difference: it could have  
been an
obs.calib.dome-flat (which wouldn't be of any use)!

> obs.calib.freq or obs.calib.spectcan certainly be better defined with  
> another syntax,
> and first of all what is the kind of observed data concerned, image,  
> spectra, linelist...?

Since UCDs can be concatenated, this isn't important: the role of the  
observation has
been named as a concept - the rest comes from the data and metadata.

A trivial example of how useful this could be would be in a data  
pipeline: if all the images
had things attached like obs.calib.dome-flat, obs.calib.wl then there  
would be a universal
and trivial method for determining just what the data are, independent  
of FITS keywords
and local systems (e.g. ESO.DET.CCD.PAR.TEMP......).

>> just like the original
>> VOTable types who wanted to describe their catalogue entries.   
>> There's  nothing fundamentally
>> different in a VO sense between a calibration image (say, an   
>> obs.calib.phot) and a table entry
>> of the resulting calibration (say, phot.calib).  Right now, UCD is   
>> mainly (some but not me might
>> say only) useful for tables, which is why it needs to be extended to   
>> non-table standard VO uses.
> Yes but it is not the goal of the SCI-Board, at least from the point  
> of view
> of the structure, it is only concern by the content, and I am not sure
> that all the UCD problems can be resolve only by content "handling".
> Worthwhile for ucd at ivoa.net perhaps not for ucd-sci at ivoa.net.

I disagree: the WHOLE point of ucd-sci is to make high-level decisions  
of what is needed scientifically.
Otherwise, what's the "sci" in ucd-sci for?

>> A "data model for observation and data reduction" looks very  
>> different  indeed, though it must
>> ultimately use elements for which the VO has a primitive description.  
>>     UCD is our VO dictionary
> But dictionnary of what?
> All the words in astronomy (so it is related to ontology and semantic  
> I suppose)
> or a dictionary of concepts, these ones beeing able to "take" values  
> or can be
> instanciate in more precise description.
> UCD is only a part (conceptuel one AFAI understand) of a "parameter"  
> description
> which can be more precisely define by  "values" (restricted by  
> enumerated lists,
> obtained from name resolver....), others "attributes" or even others  
> "parameters".

This is a particularly VOTable-ish view of the VO and of the role of  
UCDs.  You want to have
instr.bandwidth in order to identify that the number in a table is the  
instrumental bandwidth.  I want to
have src.class.galaxy.spiral in order to be able to identify that the  
VOEvent happened next to a spiral
galaxy.   Where's the difference?   What one calls "values",  
"attributes" and "parameters" is just
a question of semantics.  Why do I have to use

	<concept>spiral galaxy</concept>

rather than src.class.galaxy.spiral but you don't have to use

	<concept>instrumental bandwidth</concept>

instead of instr.bandwidth?

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------


From Hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun  1 04:21:04 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 1 Jun 2005 13:21:04 +0200
Subject: SciBoard
In-Reply-To: <20050601092755.aupeljrjs9pcg04o@webmail.sic.rm.cnr.it>
References: <20050601092755.aupeljrjs9pcg04o@webmail.sic.rm.cnr.it>
Message-ID: <214afc13b7e2902af7d44d1b6a062131@Astro.physik.Uni-Goettingen.DE>

Sebastien Derriere said:
> Solar System UCDs (really Astronomical Object UCDs):
> they will not be UCDs per the PR. But IVOA may need such a list
> and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
> group doesn't want to take that work on, the DM group should
> probably do it. I think either group could do it, provided we
> keep the distinction between the two lists (UCDs, as semantics
> for astronomical non-object concepts, and the other list,
> as semantics for astronomical objects).

The reason for separating "astronomical non-object concepts" and
"sematics for astronomical objects" escapes me entirely, even if it
were possible to do so (which it isn't).   At least someone agrees that
a natural but major extension to UCD "may be appropriate"..... :-)

The UCD group has already done a fine job of starting the listing of
astronomical concepts (object and non-object).   Do we really want
DM (or even worse, VOEvent) to do the other job, even if there's no
"model" behind the data model?  The non-table extensions to UCD
are so obvious, relatively limited in number, and totally driven by
the requirement in a variety of VO-related efforts, i.e. can't wait for
a year-long discussion of whether we want to proceed beyond VOTable.

If the consenus within the ucd-sci board is that we only need a few more
(or less) table labels, then VOEvent or RTML will be forced to do the  
job which
naturally should be done by UCD and the IVOA efforts to make VO
tools as integrated as possible will suffer a major and utterly  
unnecessary
setback.

Don't worry - my blood pressure has returned to normal and I'll shut up.

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: <Pine.LNX.4.44.0506011216540.11365-100000@barbara.star.le.ac.uk>

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!)
> 
> 	<src ucd="src.class.galaxy.spiral" name="NGC12345"/>
> 
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and  
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.  
>   This is totally different
> from having a DM/ontology which says what it means to have a spiral  
> galaxy or what properties are
> associated with a spiral galaxy or whether the name makes any sense.   
> Of course UCD isn't a name
> resolver, but if isn't a concept resolver, what is it? Why are some  
> concepts more equal than others?
> 
> What we have now is the possibility
> 
> 	<src name="NGC12345">
> 		<type ucd="src.class">spiral galaxy</type>
> 	</src>
> 
> and who says what "spiral galaxy" means?  Who has to parse a different  
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....    
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
> 
> To say that UCD should NOT do the first (say that something is a spiral  
> galaxy) but should do the latter
> (say that a table entry is a radial velocity) means that UCD is only  
> intended to be
> used for tables and catalogues.  If this is the foundation of this  
> list, then please remove me.
> 
> Yes, we shouldn't throw together a list of random concepts and declare  
> our work done.  So, please
> complain if you don't like my suggestions.   But isn't the whole point  
> of ucd-sci to determine what astronomical
> concepts need to be expressable?
> 
> >>> Looks like you are trying to define a data model for observation
> >>> and data reduction with UCD... which is perhaps not the best way to  
> >>> go?
> >> Absolutely NOT!!!!  I just want to be able to say what something is,
> > Not only!
> > For example obs.calib.dome-flat is certainly an image (or may be a  
> > spectra?)
> > which have been obtained under specific conditions and used in a  
> > precise context
> > to derive reduced data. It describe only a "personnal" point of view  
> > of the way a
> > piece of data can be used!
> 
> But the point is that the original purpose of the observation has been  
> expressed.
> Whether it's an image, a spectrum, or simply a number can be extracted  
> from all the
> other metadata.   If you don't have "obs.calib.dome-flat", then you're  
> left with scanning
> the FITS header for OBJECT="DOMEFLT", OBJECT="DFLAT", OBJECT="DOMFLAT",
> OBJECT="FLAT-DOME", ....
> 
> > But take an image obs.calib.sky-flat (sky-flat observation), although  
> > its main
> > usage will be calibration nobody can assert that some project can use  
> > these data
> > for other purposes,  even scientific ones : variability event follow  
> > up, historical
> > tracing back, proper motion detection... or whatever else we are not  
> > already
> > thinking or aware of.
> 
> Ah, but if I'm looking for a bright GRB in daytime observations,  
> knowing that the image
> is an obs.calib.sky-flat makes tremendous difference: it could have  
> been an
> obs.calib.dome-flat (which wouldn't be of any use)!
> 
> > obs.calib.freq or obs.calib.spectcan certainly be better defined with  
> > another syntax,
> > and first of all what is the kind of observed data concerned, image,  
> > spectra, linelist...?
> 
> Since UCDs can be concatenated, this isn't important: the role of the  
> observation has
> been named as a concept - the rest comes from the data and metadata.
> 
> A trivial example of how useful this could be would be in a data  
> pipeline: if all the images
> had things attached like obs.calib.dome-flat, obs.calib.wl then there  
> would be a universal
> and trivial method for determining just what the data are, independent  
> of FITS keywords
> and local systems (e.g. ESO.DET.CCD.PAR.TEMP......).
> 
> >> just like the original
> >> VOTable types who wanted to describe their catalogue entries.   
> >> There's  nothing fundamentally
> >> different in a VO sense between a calibration image (say, an   
> >> obs.calib.phot) and a table entry
> >> of the resulting calibration (say, phot.calib).  Right now, UCD is   
> >> mainly (some but not me might
> >> say only) useful for tables, which is why it needs to be extended to   
> >> non-table standard VO uses.
> > Yes but it is not the goal of the SCI-Board, at least from the point  
> > of view
> > of the structure, it is only concern by the content, and I am not sure
> > that all the UCD problems can be resolve only by content "handling".
> > Worthwhile for ucd at ivoa.net perhaps not for ucd-sci at ivoa.net.
> 
> I disagree: the WHOLE point of ucd-sci is to make high-level decisions  
> of what is needed scientifically.
> Otherwise, what's the "sci" in ucd-sci for?
> 
> >> A "data model for observation and data reduction" looks very  
> >> different  indeed, though it must
> >> ultimately use elements for which the VO has a primitive description.  
> >>     UCD is our VO dictionary
> > But dictionnary of what?
> > All the words in astronomy (so it is related to ontology and semantic  
> > I suppose)
> > or a dictionary of concepts, these ones beeing able to "take" values  
> > or can be
> > instanciate in more precise description.
> > UCD is only a part (conceptuel one AFAI understand) of a "parameter"  
> > description
> > which can be more precisely define by  "values" (restricted by  
> > enumerated lists,
> > obtained from name resolver....), others "attributes" or even others  
> > "parameters".
> 
> This is a particularly VOTable-ish view of the VO and of the role of  
> UCDs.  You want to have
> instr.bandwidth in order to identify that the number in a table is the  
> instrumental bandwidth.  I want to
> have src.class.galaxy.spiral in order to be able to identify that the  
> VOEvent happened next to a spiral
> galaxy.   Where's the difference?   What one calls "values",  
> "attributes" and "parameters" is just
> a question of semantics.  Why do I have to use
> 
> 	<concept>spiral galaxy</concept>
> 
> rather than src.class.galaxy.spiral but you don't have to use
> 
> 	<concept>instrumental bandwidth</concept>
> 
> instead of instr.bandwidth?
> 
> Rick
> 
> ------------------------------------------------------------------------ 
> ------------------------
> Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
> Universitaets-Sternwarte     Tel.  +49-551-39-5052
> Geismarlandstr. 11                Fax +49-551-39-5043
> 37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
> ------------------------------------------------------------------------ 
> -------------------------
> MONET: a MOnitoring NEtwork of Telescopes
> http://monet.uni-goettingen.de
> ------------------------------------------------------------------------ 
> -------------------------
> 
> 

---
Patricio F. Ortiz			pfo at star.le.ac.uk
Department of Physics & Astronomy	Phone: +44 (0)116 252 2015
University of Leicester			
Leicester, LE1 7RH, 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!)
> 
>     <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
> 
> This use is ENTIRELY EQUIVALENT in its VO meaning, scope, and  
> usefulness to having a VOTable
> which contains some entry identified as meaning some physical property.  
>  This is totally different
> from having a DM/ontology which says what it means to have a spiral  
> galaxy or what properties are
> associated with a spiral galaxy or whether the name makes any sense.   
> Of course UCD isn't a name
> resolver, but if isn't a concept resolver, what is it? Why are some  
> concepts more equal than others?
> 
> What we have now is the possibility
> 
>     <src name="NGC12345">
>         <type ucd="src.class">spiral galaxy</type>
>     </src>
> 
> and who says what "spiral galaxy" means?  Who has to parse a different  
> object where the type is
> "galaxy, spiral" or "galaxy of type spiral" or "spiralgalaxy" or....    
> Wouldn't life be so easy if we could just
> say that there is a UCD "src.class.galaxy.spiral"?
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
<src name="NGC12345">
          <automatedObjType ucd="src.class">galaxy</automatedObjType>
	 <supervisedMorphType ucd="src.morph">spiral</supervisedMorphType>
</src>
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
> 
>     <concept>spiral galaxy</concept>
> 
> rather than src.class.galaxy.spiral but you don't have to use
> 
>     <concept>instrumental bandwidth</concept>
> 
> instead of instr.bandwidth?
 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 derriere at newb6.u-strasbg.fr  Wed Jun  1 06:56:06 2005
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Wed, 01 Jun 2005 15:56:06 +0200
Subject: ucdComments page
Message-ID: <429DBE76.DD411C81@astro.u-strasbg.fr>


  Hi all,

  An answer to both Pierre and Miguel:

Pierre Didelon wrote:
> 
> Is there a formal/official way to do this?
> Can people who are not part of the board submit modifications? How?
> Is there an entry point for the community outside the board?
> What is the "good" submission path or procedure?
> Four questions for the same pb is perhaps enough! :-D
> Cordially,
> Pierre

Miguel Cervi?o wrote:
> 
> Additionally, should be the UCDs posted at:
> 
> http://cdsweb.u-strasbg.fr/UCD/cgi-bin/comment/ucdComments?sort=C
> 
> included in the draft-list?

  Now that we have a proper scientific board, with a mailing-list
that is archived (1), etc... we might close submissions on the 
aforementioned web page, and redirect instead people from the 
community to the ucd-sci at ivoa.net for their comments/suggestions.
  This would avoid confusion: the sci-board would clearly be the only
entry point for UCD curation. If noone disagrees, I'll disable
posting on the ucdComments page, and invite submissions by email
to ucd-sci at ivoa.net.

  And we can discuss some of the suggestions that are still unanswered
on that page!

Sebastien.

1: http://www.ivoa.net/forum/ucd-sci/
-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


From derriere at newb6.u-strasbg.fr  Wed Jun  1 07:50:24 2005
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Wed, 01 Jun 2005 16:50:24 +0200
Subject: T0 : extensions to em, obs, spect, instr
References: <e4a51a9b1b83d9019eda7106de4e7265@Astro.physik.Uni-Goettingen.DE> <429C61EF.4020300@cea.fr>
Message-ID: <429DCB30.C9F96D0E@astro.u-strasbg.fr>

Pierre Didelon wrote:
> 
> UCD must define preferentially concept I suppose, isn't it?

"Frederic V. \"Rick\" Hessman" wrote:
> 
> The reason for separating "astronomical non-object concepts" and
> "sematics for astronomical objects" escapes me entirely, even if it
> were possible to do so (which it isn't).   At least someone agrees that
> a natural but major extension to UCD "may be appropriate"..... :-)

  Hi,

  Reading the last messages, I realize that we must be *very* careful
with the vocabulary we use (especially as members of a board aiming at 
describing semantic contents!).
  I have already experienced how words like "objects", "concepts" and
"types" can be (mis)understood when discussing across (and even
within) different domains (mainly astronomy and computer science).
Let me explain a few points that don't seem clear:

  Concept / properties :

  Following the ontology vocabulary, a *concept* is something abstract
(can be seen as a class in object-oriented programming).
  This concept can have *properties*.
  When you define an *instance* of a concept, you associate values to
the
various properties.

example: "telescope" can be seen as a concept (something abstract).
Several
properties can be associated to the concept of a telescope (its name,
size,
mass, location, ...). A particular telescope (one that you can see, or
observe
with) will be an instance of the concept "telescope".

  In the UCD vocabulary, most of the words correspond to *properties*.
Because
some properties are common to different concepts, we also created some
UCD-words 
corresponding to *concepts*, and we can build complete UCDs by writing:
"property;concept". This was done to reduce the number of words: for M
properties
and N concepts, this leads to N+M words instead of N*M.
  For the example above, we have the concept of telescope: "instr.tel".
It can have a name: ucd="meta.id;instr.tel", a size:
ucd="phys.size.diameter;instr.tel",
a location, eg: ucd="pos.earth.lon;instr.tel" and
ucd="pos.earth.lat;instr.tel", ...

  Basically, concepts were only introduced in the vocabulary for
allowing
re-usability of words. But the most important UCD-words are those
describing properties: they are used to say what a quantity (can be a
number
or a string) is.

  Objects / non-objects :

  I'm confused with the "astronomical non-object concepts" and 
"sematics for astronomical objects" expressions.
  Astronomical objects (I understand sources detected in the sky, here)
are
named individually according to a controlled Nomenclature. The UCD have
no role to
play in this nomenclature. But there is one UCD word to say that a
quantity is an
object's name: meta.id  :  Identifier, name or designation
  Or maybe we can write: "meta.id;src"
e.g. <PARAM ucd="meta.id;src" value="NGC 234">

  Currently, most of the existing UCD words are used to identify
the *properties* of the astronomical objects (detected sources).



Sebastien.  

-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


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: <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>

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: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050601/ccb525ef/attachment-0001.html>

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: <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>
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> <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>
Message-ID: <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk>

> 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 Hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun  1 08:57:15 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 1 Jun 2005 17:57:15 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <429DCB30.C9F96D0E@astro.u-strasbg.fr>
References: <e4a51a9b1b83d9019eda7106de4e7265@Astro.physik.Uni-Goettingen.DE> <429C61EF.4020300@cea.fr> <429DCB30.C9F96D0E@astro.u-strasbg.fr>
Message-ID: <868c9786a97ac1836b54c4783c304dc7@Astro.physik.Uni-Goettingen.DE>

On 1 Jun 2005, at 3:54 pm, Pierre Didelon wrote:

> It was only my point of view (friendly i assume, at least when writing  
> it)
> and certainly not "THE" UCD-SCI board pov, and I didn't want to hurt  
> you,

No problem at all :-)

> just express a (my?) difficulty when defining new UCD (similar to the  
> one we had
> when trying to define UCD for planetology) which is related to the
> definition of the "good level of abstraction" to be enoughly high to
> be widely re-usable but at the same time enoughly precise to be usable  
> at all!

This is why I probably sound somewhat exasperated: I keep feeling that  
something
which sounds so simple, so necessary, and so obvious is meeting such  
resistance.
I didn't join to partake in abstract philosophical discussions about  
ontological
problems but to be able to teach my software how to handle events and  
observing
requests.  Thus, the whole goal has to be defining something which is  
exactly
what you want: "good (enough) level of abstraction", "widely  
re-useable" and
certainly "precise enough to be useful at all".


On 1 Jun 2005, at 4:50 pm, Sebastien Derriere wrote:
> Basically, concepts were only introduced in the vocabulary for
> allowing
> re-usability of words. But the most important UCD-words are those
> describing properties: they are used to say what a quantity (can be a
> number or a string) is.

Exactly.  Now just abstract that idea to include not just numbers or  
strings but
anything which the VO can deal with: images, spectra, astronomical  
events, generic
classifications,....     Saying "what a quantity... is" is just naming  
it, so anything
which needs to be identified deserves an official VO "name" (not to be
confused with names like "Sebastien" or "NGC1234").  UCD
has done this for table-like quantities, so why not extend it for the  
rest of us?

>   I'm confused with the "astronomical non-object concepts" and
> "sematics for astronomical objects" expressions.
>   Astronomical objects (I understand sources detected in the sky, here)
> are
> named individually according to a controlled Nomenclature. The UCD have
> no role to
> play in this nomenclature.

... and no one is saying that it should.  I want to name concepts, not  
objects.

>   Currently, most of the existing UCD words are used to identify
> the *properties* of the astronomical objects (detected sources).

Exactly, except properties like "being a spiral galaxy" are not yet  
allowed
even though properties like "being the rotation rate" are.

Being a spiral galaxy in the VO universe shouldn't be tied to the string
"spiral galaxy" but to an official VO concept, e.g.  
src.class.galaxy.spiral.


On 1 Jun 2005, at 1:44 pm, Patricio F. Ortiz wrote:

> As far as I can see it, we are dealing with three (or more) "parallel
> universes":
> - table metadata (the raw material we used to develop UCDs)
> - image metadata
> - VOevents metadata
>
> Looks like the structure suggested by UCDs in the 'table metadata'  
> could
> fit well into the other two cases. I see no reason not to use it.

If the present UCD weren't handy for other purposes, we frankly wouldn't
be interested in extending it.

Much more important, though, is the idea that a general UCD naming all
the needed VO concepts forms the lingua franca by which VO tools, apps,
processes, data, interactions,... can at least agree about what they're
talking about.    If UCD doesn't do this, then someone else will and  
you'll
be forced in the long run to abandon UCD, because we don't need two
ways of expressing ourselves and maintaining two or more dictionaries
will never work.

> It's unlikely that elements from one domain could be openly used in the
> other, eg, adding an object type to a list of objects in a catalogue  
> using
> its "type-ucd". Maybe someone would like to do so, but it won't happen  
> in
> the large surveys.

But this is exactly what tools like sextractor do: they tell you what  
it thinks zillions of
objects are.  Yes, the primitive versions just give you things like  
phot.mag and
pos.eq.ra, but the more "intelligent" ones will tell you if the object  
is a spiral or
an elliptical galaxy.   If the large surveys don't start identifying  
objects this
explicitly, then they'll only produce petabytes of useless garbage.   
Add the
time domain (eg LSST) and you'll have a problem if there isn't also  
something
like src.class.star.variable and event.eclipse, because otherwise  
they'll have
to use strings.

> Image metadata is something I haven't thought much, but it is true  
> that if
> one could immediately recognize a dome-flat by looking at just one  
> element
> on the metadata it would be great! People handling archives would  
> likely be
> very interested in exploring this domain and propose their set of
> standardized descriptors (ucd-like or image-ucd). How can I handle it  
> now
> if I want to find an image (processed with bias subtraction and
> flat-fielded?) How do I locate the adequate flat fields for a given  
> image?
> I could've located the object images in an archive by the pointing
> position, but their accompaning calibration images?

This is getting away from "concepts" and toward "processes" and  
"models".
Don't want to touch this can of worms! Suffice it to say that something  
like

	obs.image.calibrated
	obs.image.uncalibrated

would be handy, but connecting this to the correct

	obs.calib.flatfield

isn't the job of UCD.

> VOevent seems to require description of an object and perhaps naming,
> but I see naming as a way to locate the object (at a given time).

The point is that naming in the sense of "RXJ 1234-567" is fine if  
that's what
you want, but often one couldn't care less what the official name is as  
long
as one knows what the object is generically.

> You will
> shoot me if I'm wrong, I'm sure :-) but this seems very much like how  
> to
> build a IAU telegram to notify a supernova in a way which the  
> description
> elements could be easily recognized and processed by automated agents
> (and possibly humans :-)

That's exactly what VOEvent is and why I'm here fighting ;-)

> Finally, I think Frederic mentioned why we don't have ucds with  
> neutrino
> or gravity waves observations... well, 6 or 7 years ago there was  
> nearly
> nothing (tables) in the literature... I agree, they should be there,  
> and as
> the observation methods are likely to be quite different from
> night-astronomy, we could think of having
>
> em.	electromagnetic spectrum
> gw.	gravity wave detection
> nd.	neutrino detection
>
> as base sections within the UCD schemes, just as we have at. to denote
> atomic transitions usually measured in the lab.

Putting it in "phys" makes more sense to me: while "gw" is ok, having
"nd" means adding "ad" (axion detection), "crd" (cosmic-ray  
detection),....

If "em" is just the physical concept of electromagnetic radiation, then  
one could argue that it
belongs in phys too.   If "em" is there to descibe the means by which
an observation was made, then "em=emission" could include gravitational
waves and neutrinos and other things.

I know, I know, there are probably endless discussions about where a
concept belongs (lower level, higher level,..).   I'd argue that naming  
the
concepts in the long run is enough: the people who will do the  
ontologies
won't care what we've called it officially.  There will never be the  
perfect
set of concept names but concepts are so heterogeneous and infinitely
useful.    Still, better to have ANY name at all than NO name at all.

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------


From andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun  1 09:08:41 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed,  1 Jun 2005 18:08:41 +0200
Subject: cross-posting!!
Message-ID: <20050601180841.chccno54i8g7ksog@webmail.sic.rm.cnr.it>

Dear all,

could you please STOP cross-posting your messages?

The manager of the IVOA mailing list was so kind to open for the discussion
two new mailing lists.
After half a day he is already asking himself if that was of any use,
because people continues to send discussion mails also to ucd/voevents/...
lists!!

Thank you for your attention.

Andrea
==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From pdidelon at cea.fr  Wed Jun  1 09:43:50 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 01 Jun 2005 18:43:50 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <868c9786a97ac1836b54c4783c304dc7@Astro.physik.Uni-Goettingen.DE>
References: <e4a51a9b1b83d9019eda7106de4e7265@Astro.physik.Uni-Goettingen.DE> <429C61EF.4020300@cea.fr> <429DCB30.C9F96D0E@astro.u-strasbg.fr> <868c9786a97ac1836b54c4783c304dc7@Astro.physik.Uni-Goettingen.DE>
Message-ID: <429DE5C6.40809@cea.fr>



Frederic V. "Rick" Hessman wrote:

> On 1 Jun 2005, at 3:54 pm, Pierre Didelon wrote:
> 
>> It was only my point of view (friendly i assume, at least when 
>> writing  it)
>> and certainly not "THE" UCD-SCI board pov, and I didn't want to hurt  
>> you,
> 
> 
> No problem at all :-)

Ouf/Ah!
> 
>> just express a (my?) difficulty when defining new UCD (similar to the  
>> one we had
>> when trying to define UCD for planetology) which is related to the
>> definition of the "good level of abstraction" to be enoughly high to
>> be widely re-usable but at the same time enoughly precise to be 
>> usable  at all!
> 
> 
> This is why I probably sound somewhat exasperated: I keep feeling that  
> something
> which sounds so simple, so necessary, and so obvious is meeting such  
> resistance.
> I didn't join to partake in abstract philosophical discussions about  
> ontological
> problems but to be able to teach my software how to handle events and  
> observing
> requests.  Thus, the whole goal has to be defining something which is  
> exactly
> what you want: "good (enough) level of abstraction", "widely  
> re-useable" and
> certainly "precise enough to be useful at all".
;-)
But something obvious or "natural" for somebody in a specific context
can have diff. meaning for somebody else in another context.
That's also why  trying to convince colleagues of the usefullness of terms
is important, it force to express the implicit part of the definition.
See comment below on calib. The pb of galaxy.spiral is diff. I agree.
> On 1 Jun 2005, at 4:50 pm, Sebastien Derriere wrote:
[SNIP]
>>   Currently, most of the existing UCD words are used to identify
>> the *properties* of the astronomical objects (detected sources).
> 
> 
> Exactly, except properties like "being a spiral galaxy" are not yet  
> allowed
> even though properties like "being the rotation rate" are.
> 
> Being a spiral galaxy in the VO universe shouldn't be tied to the string
> "spiral galaxy" but to an official VO concept, e.g.  
> src.class.galaxy.spiral.
> 
:-(
src.class.galaxy is perhaps ok (if I understand correctly the mail of Rob Seaman
http://www.ivoa.net/forum/ucd-sci/0506/0015.htm) then spiral can be an "additional"
property extracted from an enumerated list... official or project specific?
Not clear for me.
> 
[snipp]
> 
> This is getting away from "concepts" and toward "processes" and  "models".
> Don't want to touch this can of worms! Suffice it to say that something  
> like
> 
>     obs.image.calibrated
>     obs.image.uncalibrated
Calibrated means astrometrically and/or phtometrically calibrated? Relative or absolute?
in which reference system? ...
What about spectral data, interferogramm, cosmic ray and neutrino detection?
All these data have diff. level of calibration, completly diff. one from the other.
Do we need to define all these in UCD, or something more general like
meta.dataset.status a property which can take values like raw, astrom.calib, photomCalib...
or whatever needed by a project or a context.
> 
> would be handy, but connecting this to the correct
> 
>     obs.calib.flatfield
> 
> isn't the job of UCD.
> 
Agree ;-).
SY
PiR



From derriere at newb6.u-strasbg.fr  Wed Jun  1 10:25:59 2005
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Wed, 01 Jun 2005 19:25:59 +0200
Subject: T0 : extensions to em, obs, spect, instr
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: <429DEFA7.197122FF@astro.u-strasbg.fr>

"Frederic V. \"Rick\" Hessman" wrote:
> 
> Let's leave the solar system out of the way at first.  If we just take
> stellar+extragalactic
> astronomy, then - of course - NOBODY wants a UCD which says
> 
>         src.class.galaxy.spiral.virgocluster.northern-part.opt.name.NGC12345
> 
> What VOEvent DOES needs, however, is something generic like (ignore the
> actual XML tag names!)
> 
>         <src ucd="src.class.galaxy.spiral" name="NGC12345"/>

  I agree with you that nobody wants the first expression :o)
But I'm also scared by the second one, because there is a lot
of implicit knowledge in it: because I am human (and astronomer),
I can understand it, but what would a computer understand?
  You are trying to express that the observation target has a name
which is "NGC12345", and that it is a galaxy with a spiral Hubble 
type (right?).
  During the discussions in Kyoto, we discussed several ways of
expressing
all these informations, and we came with the following:
<src>
	<param ucd="meta.id" value="NGC12345" />
	<param ucd="src.class" value="Galaxy" />
	<param ucd="src.morph.type" value="Sc" />
</src>

  Maybe that <src> could also be <group ucd="src"> ?

> 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.

  Not quite. When you say: <param ucd="phot.mag" value="12.3" />
you indicate that the value 12.3 represents a magnitude.
Whereas <src ucd="src.class.galaxy.spiral" name="NGC12345"/>
is ambiguous: you implicitly conceptualize a property of the
source (the morphological type), and you use an attribute ("name")
to give a value ("NGC12345") that refers to the contents of the "ucd"
attribute. As we speak, we often make the simplification
name-of-a-thing=thing, but machines won't like it...

> What we have now is the possibility
> 
>         <src name="NGC12345">
>                 <type ucd="src.class">spiral galaxy</type>
>         </src>

  In this example, does "type" mean something precise? In fact, the 
contents of the "ucd" attribute gives the semantic type of the value
that is associated. That is why you can use neutral tags (param) in the
schema with ucd attributes: <param ucd="" value=""/>.
  If you already give special names to your schema elements, then you
implicitly give the semantic type of their contents: no need for ucd!
<magnitude>12.3</magnitude> instead of <param
ucd="phot.mag">12.3</param>
  Basically, if all elements of your xml schema are already strongly
semantically typed... you don't need UCDs - but you can do a mapping
from your schema's elements to the corresponding UCDs.

> 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"?

  Now we come to the crucial point of the discussion: how to standardize
the writing of possible values of astronomical object types (in the
sense
of object classification)? Which I agree we do need in the VO.
  Note however that instead of saying: "This object is a spiral galaxy",
I'd rather say "The result of the classification process gives for this
object
the value [galaxy] for the source class, and the value [spiral] for the
morphological type". Which is quite different, and hopefully much easier
for a computer to understand.

> 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.

  We must be very careful on the role that we choose for those the
words we create. If we start creating words for each "concept" that
we can name, we go the wrong direction.I'd create a UCD word for objects 
in the constellation Draco, or to see things like "pos.eq.dec.north".
  I think the best would be to come with a series of practical
use cases where we need to manipulate information like that of
"spiral galaxy", then see how we (humans+software) can handle it.

>  Why do I have to use
> 
>         <concept>spiral galaxy</concept>
> 
> rather than src.class.galaxy.spiral but you don't have to use
> 
>         <concept>instrumental bandwidth</concept>
> 
> instead of instr.bandwidth?

  I think the whole point is that "instrumental bandwidth"
can readily be associated to a value. But what kind of value 
do you associate with "spiral galaxy"? Or would this "concept"
be used to characterize a set of measures? 
  If "src.class.galaxy.spiral" is only used to indicate without 
ambiguity to a software the morphological type of a source, then
we could live with a value of (src.class) picked from an enumerated 
list of stadardized tokens (new UCD branch, pointer to a DM, or
ontology distinguishing properly subtleties between Hubble and 
deVaucouleur classification, etc...) 

Sebastien.
-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France


From seaman at noao.edu  Wed Jun  1 11:03:16 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 1 Jun 2005 11:03:16 -0700
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <429DEFA7.197122FF@astro.u-strasbg.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> <429DEFA7.197122FF@astro.u-strasbg.fr>
Message-ID: <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>

On Jun 1, 2005, at 10:25 AM, Sebastien Derriere wrote:

> <src>
>     <param ucd="meta.id" value="NGC12345" />
>     <param ucd="src.class" value="Galaxy" />
>     <param ucd="src.morph.type" value="Sc" />
> </src>

This is similar to how I was envisioning VOEvent usage.  Rick should  
speak up (on whatever mailing list :-) if he sees this much  
differently.  That said, I question whether these specific UCDs will  
survive our discussions.

> instead of saying: "This object is a spiral galaxy", I'd rather say  
> "The result of the classification process gives for this object the  
> value [galaxy] for the source class, and the value [spiral] for the  
> morphological type".

I think we need support for both.  A name is sometimes both an  
enumerated value and a hierarchical classification.  This is  
particularly true when the words express some underlying physics (or  
merely physical description) that is still plastic.  We think we have  
a pretty good idea now what a "spiral galaxy" is.  It wasn't so very  
long ago that we hadn't the slightest idea of its true nature.  As  
long as astronomy is a living subject, there will be names with fluid  
meanings.

Another concern is that a "src.class" expression would cover vast  
expanses of phase space - dozens of orders of magnitude in size (from  
chunks of rock in the solar system to cosmological structure) and  
having to distinguish between objects and processes with every  
possible physical/chemical/even biological property in play.  Imagine  
a UCD-like expression of some field of biology - human anatomy, for  
instance.  The corresponding sci.class would only have to distinguish  
a modest size range and modest variety of entities.  (There are  
something like 200 cell types in the body.)  What we're looking for  
is a reasonable way to separate the equivalent of cell biology from  
tissue biology from physiology at the level of organs.

In particular, the allowed values for different UCDs become  
interrelated.  (This seems likely to be something you folks have  
previously considered.)  There are different values for  
src.morph.type depending on the value of src.class - and there are  
even different sets of UCDs entirely that are pertinent depending on  
the class.

In short, Sebastien's view and Rick's view need to be synthesized  
into a common vision.

> If we start creating words for each "concept" that we can name, we  
> go the wrong direction.I'd create a UCD word for objects
> in the constellation Draco,

But this is precisely what is done all the time.  An astronomer  
pursues a new line of research and invents new terminology.  Those  
terms may be representative of universal phenomena or may be specific  
to some area of study.  We're hundreds of years past caring about  
constellations scientifically, but the details of some specific  
galaxy or cluster (M13, the Hyades) may be very important to describe  
accurately and precisely.  To borrow a page from Rick, if UCDs don't  
support project specific glossaries, these will be expressed in some  
other fashion.

Rob Seaman
NOAO


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: <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk>
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> <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu> <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk>
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 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> <EB6B2AC0-5268-4F2E-8DA7-FCD728C7B9FE@noao.edu>
 <Pine.LNX.4.61.0506011639350.29094@msslta.mssl.ucl.ac.uk> <429E015D.1080501@gsfc.nasa.gov>
Message-ID: <Pine.LNX.4.58.0506011228430.765@avyakta.caltech.edu>


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 mcs at iaa.es  Thu Jun  2 01:48:01 2005
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Thu, 2 Jun 2005 10:48:01 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DEFA7.197122FF@astro.u-strasbg.fr> <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
Message-ID: <F020612C-AC94-4CEE-B06E-85ED27E3D896@iaa.es>

Hello all,

I give you my opinion in the present discussion from a naif point of  
view :)

Something that has been rounding my mind when I think about UCDs is  
how much "detailed" it must be and what are the implications for  
others "fields" (I mean, value, units, datatype, etc...) in a "param"  
tag. I post some cases and latter my opinion below.

  - A given UCD would imply something for the "data type"?:

         <param ucd="phot.mag" value="12.3" />

     Implies that this UCD has a value with datatype="float". It  
means that only in cases
     where it will be ambiguity  the datatype should be defined?

- Would be used a UCD alone without an associated value?
       It would be the case of:

          obs.image.uncalibrated  that defines by itself a property  
of the image, what would be the
              "value" in that case? Yes, No?
         src.class.galaxy.spiral is a similar situation.

- Should an UCD give some information about the zero-points or the  
units?

         phy.abund.X  means implicitly abundance by mass or by  
number? It has sense phys.abund.X.byMass?
         Would a UDC distinguish between log Luminosity or  
Luminosity? (phot.flux and pho.mag have sense if
         this distinction is the work to do by the UCD; they are  
redundant if such a work must be done by "units")

- Should an UCD be a "standard" assignation of the "name" filed?

Well, now comes my point of view:

I think that UDCs words are only valid if they do imply NO inference
in the other possible "fileds", a ucd-tag have sense  only as a  
complement of  "value" or "datatype" fields (sometimes also units  
etc..., I am not compltly sure about "name")

  As an example which would be the UDC in a VOtable with this line:

       <description>My Eliptical (E0) galaxies</description>
       <field ucd="..." datatype="character*" name="Galaxy name">
            ...........

     ??

In this case I am not sure it it would be required an UDC of It would  
more useful a line with
<PARAM ucd="gal.sp" dataype="char" value="Elliptical">

Any casee I aggre that there is a problem in how the "value" is  
spelling (Elliptical, E0,....) that would difficult any direct  
search, I think that it is a un-soluble problem: Each astronomer/VO  
developer etc has their own
preferences (that is great, by the way).... and any machine program  
will have the preferences of its "owner"
etc...

Summing up. If we agree that every possible "field" in a "tag" must  
do their own job, I think that the UCDs definition becomes more  
simple (and in some way most useful)..... I do not know.... but maybe  
asked to each UCDs which range of values they my have would be  
useful....


Now, for practical issues :)
I think that most of the discussion has been focus in the UCD  
"length": Or, UCD words-like vs. UCD-sentence-like. Here comes My  
suggestion.

May be we can began in an atomized way:
    1- Are all the "1st-atoms" in the list valid? (or it is needed  
more?, or less?)
    2- Are the present words that contain two atoms valid?
            .........

In this case, I think, most of the present discussion would be  
related with the lower levels (words with many atoms), and whatever  
the final result we will have at least a list of really valid words :)


     cheers


         Miguel





From Hessman at Astro.physik.Uni-Goettingen.DE  Thu Jun  2 05:41:23 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Thu, 2 Jun 2005 14:41:23 +0200
Subject: T0 : extensions to em, obs, spect, instr - FINAL COMMENT?
In-Reply-To: <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DEFA7.197122FF@astro.u-strasbg.fr> <C68303AC-A27B-4174-AE02-5D5B970C1346@noao.edu>
Message-ID: <3921b09bd80d7ddf22e0e6f24b9a7103@Astro.physik.Uni-Goettingen.DE>


On 1 Jun 2005, at 8:03 pm, Rob Seaman wrote:

> On Jun 1, 2005, at 10:25 AM, Sebastien Derriere wrote:
>
>> <src>
>>     <param ucd="meta.id" value="NGC12345" />
>>     <param ucd="src.class" value="Galaxy" />
>>     <param ucd="src.morph.type" value="Sc" />
>> </src>
>
> This is similar to how I was envisioning VOEvent usage.  Rick should  
> speak up (on whatever mailing list :-) if he sees this much  
> differently.  That said, I question whether these specific UCDs will  
> survive our discussions.

This is fine for VOTable, where "value" is really rather diffuse  
scientifically ("the thing in the table row and column with some
scientific meaning given by the ucd") and where the main purpose is to  
recreate the non-astronomical thing "table" into an
astronomical unit which can be processed.  You really don't care if you  
have

	<param ucd="src.class" value="Galaxy"/>
or
	<param ucd="src.class" value="galaxy"/>
or
	<param ucd="src.class" value="island universe"/>

As soon as you get away from tables, things become more complex, since  
the "value" can - and SHOULD - take on
more meaning.   In VOEvent, the point is NOT to have a string which  
someone used to randomly label an object (the VOTable
equivalent task), but to tell stupid computers that the object is  
something in particular.  With

	<param ucd="src.class" value="Galaxy"/>

there's no way to know if the class is "galaxies in general" or even  
"The Milky Way" unless the VO has an official
dictionary saying that the "value" of "src.class" for galaxies in  
general should be "Galaxy" (a poor choice if you ask
me, but...).  Thus, I personally find the present model good for random  
information (non-classification tasks) but extremely bad
for particular information (classification tasks).

If the only way to express "spiral galaxy" is to use "src.class" =  
"Galaxy" and "src.morph" = "SC", then someone (i.e.
a programmer) with have to deal with the fact that "src.morph" - a  
concept used for zillions of other astronomical
objects not related to galaxies - may or may not be applicable to the  
object in question.  That forces her/him to use
an ontology :-(    While I applaud those willing to tackle such, it'll  
be a long while until we have one which can be
used in real applications.  And all of this work simply because we  
don't have "src.galaxies.spiral" (note I've dropped
"class" to reduce the number of hierarchies).

> We think we have a pretty good idea now what a "spiral galaxy" is.  It  
> wasn't so very long ago that we hadn't the slightest idea of its true  
> nature.  As long as astronomy is a living subject, there will be names  
> with fluid meanings.

True enough, but the point is we DO know what a "spiral galaxy" is  
right now, we already know of billions of them, and survey
projects need NOW to be able to tell us that they've found one.

Let's worry about the concepts we haven't developed when they appear.


On 2 Jun 2005, at 10:48 am, Miguel Cervi?o wrote:

> In this case I am not sure it it would be required an UDC of It would  
> more useful a line with
> <PARAM ucd="gal.sp" dataype="char" value="Elliptical">
>
> Any casee I aggre that there is a problem in how the "value" is  
> spelling (Elliptical, E0,....) that would difficult any direct search,  
> I think that it is a un-soluble problem: Each astronomer/VO developer  
> etc has their own
> preferences (that is great, by the way).... and any machine program  
> will have the preferences of its "owner"
> etc...

NO!!!   The VO apps of the future will  "know" how to express the  
concept of "elliptical galaxy" in a common fashion (otherwise they're  
too
stupid to be able to talk to each other about them) but the human user  
see's what the human equivalent is supposed to
be in terms s/he WANTS to see (e.g. in english, in french, or for a 3rd  
grade student in Malaysia,...).   The ONLY question now
is how difficult we want to make the life of VO programmers - nothing  
else!    An astronomer who refuses to accept that
somewhere buried in the VO software architecture there's a  
"src.galaxies.elliptical" or a "src.class"="Galaxy" +
"src.morph"="elliptical" instead of the string "elliptische Galaxie"  
simply won't (and shouldn't) use the VO.

Miguel's comment does raise a totally different issue which may explain  
why there's no confluence of ideas: do we want a
VO architecture which is simply a more elegant means of letting a human  
user deal with complex sets of VO data and
VO apps - in which case "Elliptical" will be fine to describe the  
galaxy since a human in there to interpret what it means - or
do we want to use things like UCD's to permit computers to deal with  
this information without ANY human involved
IN PRINCIPLE (e.g. automatic classification of zillions of LSST sources  
triggering robotic observations).  My feeling is that
the work on VOTable and UCD has been based largely on the former and I  
know that the work on VOEvent is largely based
on the latter.  Yes, this is oversimplified, but it would help to  
explain why we don't seem to be talking about the same thing......

Don't get me wrong - I think UCD's in their present form are great -  
but if this list is just about last-minute refining of the
present list using the present limited set of officially allowed  
concepts, then please remove me so you won't have to be bothered by
my rantings anymore.  I'm sure you'll do a great job and we'll  
certainly use UCDs all over the place, but I'm then personally
interested in something else and would then try to find a IVOA group  
doing the next - and unfortunately officially defined as
different - task of teaching computers a minimal set of concepts needed  
to do automatic processing of VO information NOW
without the use of ontologies (we just barely got our GRB colleagues to  
accept XML - wait until I tell them they're going to have to use OWL!).  
  Seems
a shame, but then the IVOA has historically been a pretty heterogeneous  
bunch and so yet another group doing some of the same
work using a totally different approach won't be noticed.   Computers  
are fast, databases can be linked, cross-references can be made,  
translators and parsers can be written, generations of students need to  
be given work, .... :-)

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 andrea.preitemartinez at rm.iasf.cnr.it  Thu Jun  2 06:24:38 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Thu,  2 Jun 2005 15:24:38 +0200
Subject: Sci-Board-3
Message-ID: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>

***Sci-Board-3

Dear all,

I think it is time to remind you what the goal of the Sci-Board on a short
time-scale is:
we (eg: IVOA project and people) urgently need a stabilized version of the
UCD vocabulary.

Adds-on are possible in this phase, but in the short term (<1 month) the
main job is to get a basic ?kernel? of ?stable? words that can be
immediately used by data providers. The starting point is the list of words
already available as an IVOA-WD.

If the present version of the list is too much ?table/catalogue?-like
for somebody's tastes, I remind that at CDS (just to quote one of the data
centers) about 150.000 columns wait for a ?stable? ucd-vocabulary in
order to be treated (e.g.: to have an ucd assigned to them), their number
growing at the rate of 1000 per month.

What I mean is: they are already there. This is why at the joint UCD-VOEvent
session we decided to postpone the discussion on <UCDs and the VOEvent
vocabulary> (to be precise, on the <hypothesis> schema only, because actual
UCDs are usable in other Event contexts/schemas) : to gather a real working
vocabulary on events and associated hypothesis.

The situation is not very simple : on one hand we have now a <standard> way
(a <precise> way) to define <fuzzy>-enough UCDs, on the other hand we need
to have within the IVOA community   (DM, Theory, VOEvent, ..) the
possibility to express the same concepts using the same words. And, why
not, using the same syntax already used for the UCDs.

A way out is to be rigorous and <open> at the same time.

I remind you that in the actual version of UCDs we do have <objects>: in the
sense that we do (we can) distinguish between the temperature of a star (its
effective temperature) and that of a detector or instrument. We do
distinguish between the name/identifier of an astronomical object and that
of a telescope, instrument, or even a fov. In all these cases we use
ucd-words describing <objects> as <qualifiers>.

While today an UCD like :  src.galaxies.S0   would be meaningless,
meta.id;src.galaxies.S0   would not. In the UCD context  src.galaxies.S0 is
only a secondary word, but in another context it could be used as primary.

We can (I would say: we have to) work in this direction.

I totally agree with Rick's final statement on ontologies: we need standards
NOW, not in 30-40 man-years time!

Best regards

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From seaman at noao.edu  Thu Jun  2 08:18:42 2005
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 2 Jun 2005 08:18:42 -0700
Subject: Sci-Board-3
In-Reply-To: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
Message-ID: <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>

This is why I prefer separate threads on a single mailing list to  
attempts to segregate discussions up front into conceptually  
different mailing lists.  There appear to be at least four different  
places to talk about UCDs/Ontologies.  Either the members of those  
mailing lists overlap strongly - or they don't.  In the former case,  
why have separate lists?  In the latter case, some folks miss large  
parts of the conversation.  In either case, administrivia messages  
proliferate trying to keep everybody in line.  Oh, well...shall we  
take the more conceptual discussions over to ucd-tech?

On Jun 2, 2005, at 6:24 AM, Andrea Preite Martinez wrote:

> we (eg: IVOA project and people) urgently need a stabilized version  
> of the UCD vocabulary.

Fine.  (Although one might read discussion to date as an expression  
of a sense that this goal will not be trivial.)  If the ucd-sci board  
is to focus exclusively on generating vocabulary, what we need is a  
structured discussion, not a free-for-all.  Is there a specific  
action item on the table?  "Provide vocabulary" ain't gonna cut it.

> The starting point is the list of words already available as an  
> IVOA-WD.

Reminder where that is?

> we decided to postpone the discussion on <UCDs and the VOEvent

Define "postpone".  The VOEvent WG certainly intends that its  
prototypes be fast-tracked.

> I remind you that in the actual version of UCDs we do have  
> <objects>: in the sense that we do (we can) distinguish between the  
> temperature of a star (its effective temperature) and that of a  
> detector or instrument. We do distinguish between the name/ 
> identifier of an astronomical object and that of a telescope,  
> instrument, or even a fov. In all these cases we use ucd-words  
> describing <objects> as <qualifiers>.

It would be useful to those of us now joining the UCD conversation  
from outside to see such examples expressed in in their full and gory  
detail.

> I totally agree with Rick's final statement on ontologies: we need  
> standards NOW, not in 30-40 man-years time!

Rather, we need prototype solutions now.  A standard itself cannot be  
reached via a short-cut.  The ontologies will inevitably form the  
long term standards.  UCDs and other semantic constructs will  
inevitably ultimately flow from the formalized ontologies.  Astronomy  
is the oldest of the sciences - we have all the time in the world for  
these academic pursuits.  In the mean time, pilot projects will  
produce prototype solutions that will serve the community's needs for  
a season before being supplanted by better technology layered on our  
always evolving understanding of the issues.

Rob Seaman
NOAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050602/1cd966c9/attachment-0001.html>

From mleoni at eso.org  Thu Jun  2 08:43:03 2005
From: mleoni at eso.org (Marco C. Leoni)
Date: Thu, 02 Jun 2005 17:43:03 +0200
Subject: Sci-Board-3
In-Reply-To: <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
Message-ID: <429F2907.1010201@eso.org>

Rob Seaman wrote:

> [...]
>
>> The starting point is the list of words already available as an IVOA-WD.
>
>
> Reminder where that is?


It should be this one:
    http://www.ivoa.net/Documents/latest/UCDlist.html


Cheers,
    Marco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050602/d91deebf/attachment-0001.html>

From andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun  3 01:11:29 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri,  3 Jun 2005 10:11:29 +0200
Subject: Sci-Board-3
In-Reply-To: <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
Message-ID: <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>

Quoting Rob Seaman <seaman at noao.edu>:

> On Jun 2, 2005, at 6:24 AM, Andrea Preite Martinez wrote:
>
>> we (eg: IVOA project and people) urgently need a stabilized version  
>> of the UCD vocabulary.
>
> Fine.  (Although one might read discussion to date as an expression
> of a sense that this goal will not be trivial.)  If the ucd-sci board
> is to focus exclusively on generating vocabulary, what we need is a
> structured discussion, not a free-for-all.  Is there a specific
> action item on the table?  "Provide vocabulary" ain't gonna cut it.

Of course there is. You were probably late in joining the sci-board, and you
missed it. The list was created <en route>, so the first messages were
inserted in the list by hand. For reasons that I do not understand the
message I'm talking about (Sci-Board-1) is there as subject, but not as
content. I copy it here for you and those that joined late our list.

==========================Sci-Board-1===================================
Dear colleagues,

this first message is for setting up our roadmap and organizing the Board
and our work on the UCD-vocabulary..

A. Roadmap.
Our goal is very simple: we need to stabilize (which means adding, deleting,
transforming ) the present draft list of  ucd-words, that you can find at

http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt  (just the list)
http://www.ivoa.net/internal/IVOA/IvoaUCD/WD-UCDlist-20050429.pdf (the WD
document)

in order to (i) reach  consensus, and (ii) be able to promote the list (and
the associated document) to the level of IVOA Proposed Recommendation as
soon as possible (within June).

B. The Board
1. Duration.
There will be a Sci-Board as long as UCDs will be in use in the VO, in order
to maintain the vocabulary. The mission of the board is described in the
main UCD document, that you can find at

http://www.ivoa.net/Documents/latest/UCD.html

now under minor revisions as suggested during the Exec Meeting in Kyoto.
It is possible that in the future the Exec could change the mission to suit
new needs of the VO.

2. Participation.
Participation is on a voluntary basis. Colleagues can ask the chair of the
Board to be inserted in (or deleted from) the mailing list of the Board,
and to work for a specific task (see below).

3. Chair
For the transition period required to set up the Board and let it run, I
will act as chair person of the Board (by the way,  setting up the Board
and upgrading the present list of UCD-words to the level of IVOA PR is a
formal action for the chairman of the UCD-WG). I propose to go for an
election of the chairman of the Board in a month from now.

C. Organization
1. What (Tasks)
Time is very short, at least for this first phase of our work. I propose
then to define a number of key tasks and form task-groups on different
aspects of the vocabulary. The most urgent cases were well pinned down
during the last InterOp Meeting. My first draft proposal is to organize our
work around the following tasks:

T1: the "velocity" and the resolution(s) problems
T2: theory and simulations (sim ?)
T3: at/mol physics
T4: curation (humans, organizations) and other "meta"-likes
T5: flux (total, net, backgr. and various "flux densities") and time (period
of, instant of)
T6: solar system
Txx : ??

T0: Coordination, general issues, not included in the above Ts.

Like the Board, tasks are not "closed". The discussion is open ("plenary")
and contributions are welcome from every member of the Board. It will help
people with an analytical mind (like mine!) to see "T5" appear in the
subject of your message, if dealing with "net flux" or mid-time of
exposure.

We need a coordinator for each task, with the responsibility to make a final
proposal to the Board.
There is nothing formal in the following list of people, I'm just asking
them to pay more attention to the discussion relevant to the corresponding
task, and summarize the discussion to the Board in due time.
Making use of the list of members (as of today) I propose the following
coordinators:

T0        General                Andrea
T1        Velocity/resolution        Alberto Micol
T2        Theory/simulations        Volunteer(?)
T3        At/Mol physics        Marie-Lise Dubernet
T4        Meta                        S?bastien D.
T5        flux/time                Jonathan MD
T6        Solar system                Pierre Didelon


2. How
Through the Board's mailing list. Always "reply to all". The chair will
record all messages.
In this first phase of our work time is very short. So please answer within
the given deadlines. We won't wait for late messages.

3. When
FIRST ACTION: please comment on the above organization/rules/tasks within
Thursday the 2nd of June.

This message is sent (for the last time) also to the wider interop at ivoa.net
community to ask the laziest to join in.

Best regards

Andrea
============== end of Sci-Board-1=======================================

>> we decided to postpone the discussion on <UCDs and the VOEvent
> Define "postpone".  The VOEvent WG certainly intends that its
> prototypes be fast-tracked.

As above, I copy for you my second message Sci-Board-2.

======================Sci-Board-2=========================================
Dear colleagues,

I see from the first answers to Sci-Board-1 that thinks are not clear for
everybody:

  1. Please, REPLY TO ALL the members of the Board, not to the ucd-list nor
to my address. Remember that not all the members of the Board are also
members of the UCD-WG. You can "cc" to your pet-list, I don't care, but
make sure that at least the Board can read your message.

2. When suggesting new UCD-words, please ask yourself which kind of
"quantity" you want to describe or, if not a quantity, which kind of
attribute (qualifier/modifier).
By the way, our mission is to stabilize and maintain a list of "words", NOT
a list of UCDs.
Syntax will take care of how to build UCDs, based on the classification of
the word (e.g. P/Q/S syntactic flag).

3. For what VOEvent is concerned, please have a look at the conclusions of
the joint session UCD/VOEvent at
http://www.ivoa.net/twiki/bin/view/IVOA/InterOpMay2005UCD

We will discuss Event vocabulary at the end of the year, when a first
bottom-up list of terms will be available.

4. Sorry, there isn't such a thing as Solar System UCDs. I remind you that
the IVOA (Proposed)  Recommendation on UCDs explicitly forbids UCDs like
"star", "galaxy", or "Sun", "my_pet_object", and so on.
On the contrary, qualifiers like "stellar", "galactic", "solar" can be valid
atoms.

Regards

Andrea
=======================end of Sci-Board-2=================================

>> I remind you that in the actual version of UCDs we do have  
>> <objects>: in the sense that we do (we can) distinguish between the  
>> temperature of a star (its effective temperature) and that of a  
>> detector or instrument. We do distinguish between the name/ 
>> identifier of an astronomical object and that of a telescope,  
>> instrument, or even a fov. In all these cases we use ucd-words  
>> describing <objects> as <qualifiers>.
>
> It would be useful to those of us now joining the UCD conversation
> from outside to see such examples expressed in in their full and gory
> detail.

You can use the UCD builder on line at:

http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd

>> I totally agree with Rick's final statement on ontologies: we need  
>> standards NOW, not in 30-40 man-years time!
>
> Rather, we need prototype solutions now.
I don't see why you say <Rather>. There is not contradiction. I'm talking
about STANDARDS NOW. STANDARDS LATER
> ... The ontologies will inevitably form the long term standards...
need prototyping now.

> Rob Seaman
> NOAO

Andrea





From mcs at iaa.es  Mon Jun  6 10:22:29 2005
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Mon, 6 Jun 2005 19:22:29 +0200
Subject: T0: UCDs for "em"
In-Reply-To: <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu> <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
Message-ID: <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>

Dear all,

I just revised the "em" UDCs and I post here some suggestions.
I had just rewriten the whole "Q" list and added some entries, taken  
from
the 27-Feb 2005 Working Draft on IVOA SED Data Model (marked with *).

For clarity I has put together "Q" UCDs and "S" UCDs,
the latter writen in increasing energy order.

First I center in "Q" UCDs, and I propose to keep:

Q|em.energy        |Energy value in the em frame
Q|em.freq         |Frequency value in the em frame
Q|em.wavenumber        |Wavenumber value in the em frame
Q|em.wl         |Wavelength value in the em frame

- Include:

Q|em.wl.air*         |Wavelength value in the em frame in air frame

      somewhere it should be established default is vacuum?
      In most optical observation default is air and
      in UV vacuum as example, but SLOAN data release
      gives optical wl en vacuum...

- Other suggestions in IVOA SED DM WD:

Q|em.veloc*        |Apparent radial velocity
Q|em.veloc.radio*    |radio velocity
Q|em.veloc.optical*    |optical velocity
Q|em.veloc.beta*        |velocity/cr

- Changue from Q to E?

Q|em.wl.central     |Central wavelength
Q|em.wl.effective     |Effective wavelength

   I think that this UDCs does not corresponds to the EM but more
   important for photometric characterizations. I do not know



About the characterization of the em spectrum by their energy ranges  
as proposed at:

http://www.ivoa.net/internal/IVOA/IvoaUCD/NoteEMSpectrum-20040520.html

I completely agree :) however, for clarity purpose and hogenity
the UDCs I would suggest the following changues:

em.IR.K -->  em.IR.2-3um
em.IR.H -->  em.IR1500-2000nm
em.IR.J -->  em.IR1000-1500nm

em.opt.I -->  em.opt.750-1000nm
em.opt.R -->  em.opt.600-750nm
em.opt.V -->  em.opt.500-600nm
em.opt.B -->  em.opt.400-500nm
em.opt.U -->  em.opt.300-400nm

so there no will be confusion with fotometry bands (and machines  
always will found
      em.string.(number - number unit)
that, I do not know, but may be is more easier)


Analogously, for high energy:

em.X-ray.soft --> em.X.120-2000eV
em.X-ray.medium --> em.X.2-12keV
em.X-ray.hard --> em.X.12-120keV

em.gamma.soft --> em.gamma.120-500keV
em.gamma.hard --> em.gamma.500-1000keV
                   em.gamma.1-20MeV
                   em.VHgamma  (Very-high gamma: 20Mev-10GeV)
                   em.VHgamma.20-100MeV
                   em.VHgamma.100-1000MeV
                   em.VHgamma.1-10GeV
                   em.UHgamma  (Ultra high gamma rays, cosmic ray- 
domain)
                   em.UHgama.10-30GeV
                   em.UHgama.30+GeV

Here, the definitions for gamma-ray is a bit lossy, and I have not  
found a clear consensus between very-high and ultra-high gamma in the  
literature.... :(


Finally, I think that the inclusion of em.line would be useful, but  
only for a very sort list of lines (like there is irregular verbs in  
any language that, by the way,  corresponds to the most commonly used  
verbs)
so (with a strong background of visual astronomy) I would agree with
Hydrogen lines, but I do think that em.line.OIII should be  
depreciated (there is several OIII lines!, and if OIII is here, by  
not, O I, or
H+K Ca II etc...? so I propose depreciate em.line.OIII ...

so the list would be:

S    |em.line.HI     |21cm hydrogen line
S    |em.line.Brgamma     |Bracket gamma line
S    |em.line.Halpha     |H-alpha line
S    |em.line.Hbeta     |H-beta line
S    |em.line.Hgamma     |H-gamma line

Depreciated:

S    |em.line.OIII     |[OIII] line


Cheers

     Miguel



From jcm at head.cfa.harvard.edu  Thu Jun  9 11:44:45 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:44:45 -0400 (EDT)
Subject: SciBoard
Message-ID: <200506091844.j59IijxU002921@urania.cfa.harvard.edu>


Hi UCD board,
 Sorry, I've been on travel and then sick. I've tried to catch up
on the emails.
 About the solar system UCDs, Seb.  said:


>   Hi Jonathan,
> 
>   There might be a slight misunderstanding on this.
> The planetary system community has worked on their needs
> to express the quantities they are measuring in their field
> with proper UCDs. You can see the result of this reflexion 
> here:
> http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html

>   I think these suggestions are worth examining, and they seem


I have no major problems with this list, I was talking about
suggestions that were raised for object types like asteroid, comet,
etc.

> quite mature: why not taking them into account for the PR.

I had assumed in Kyoto that we would go for the PR as is, on the
basis that the current list is not too bad, and then use the
board to make modifications shortly afterwards. I think everyone 
is happy with the syntax and the methodology, while we can spend
ages arguing about the actual list. It sounds like we want
to add lots of things to the list before going to PR, which I worry
will unnecessarily delay the PR.  See Andrea's message of Jun 3 -
my view is that we should look for any things in the current list
that are BAD, and get rid of them; there are many things
that are MISSING, but we can easily add them later. The list will
be stable in the sense that valid UCDs should rarely become invalid,
but it will never be stable in the sense that it will always grow.

Which doesn't mean the board should delay discussing additions
to the list (just that I don't think we have to agree on them
before approving the PR). I'll give my comments on the planetary list below.

>   I am less confident that we can incorporate in the PR all the
> astronomical object types/phenomenons that were discussed
> for VOEvent (is this what you call "semantics for astronomical
> objects"?).

Yes, particularly the tree of object types: galaxy.Seyfert2 etc.
I'm not so worried about the phenomena (outburst, glitch, etc..),
and I thought Rick's list was quite good. But I've heard you and
others say that you are worried about putting the object types in UCD,
whereas it's becoming clear that the object types do need to
be somewhere in the VO fairly soon.

OK, now for the particular UCDs:

 * meta.id.(x,y,z)     
     Hmm. I thought meta.id was more for names, how about arith.cpt.x, etc.?

 * obs.atm  instead of obs.air    I agree
 
 * obs.atm.refraction, phys.refraction - one the angle, the other the index.
   I guess I agree, but maybe obs.atm.refractAngle and phys.refractIndex is more explicit?

 * obs.elongation, obs.phaseAng  - these are both angles.
 How about   pos.angle.elongation, pos.angle.phase ?

 * pos.az.azi and pos.eq.ha
 I agree.   

 * pos.brc.*    In STC and I think in WCS-III the word 'topocentric' is being used
               for some of this, but body is fine too. I'd prefer pos.body.* which I find
               more obvious.

 * pos.eop.*  I like, although as we become more active on other worlds isn't it likely
    that we'll be needing similar parameters for Mars, etc.? But maybe it's fine for now.
  
 * pos.precess   Perhaps pos.eq.precess if we are talking specifically about
                 the effect of terrestrial precession on coordinate systems
                (as opposed to the precession of the pole of (433)Eros or something)

 * phys.magAbs.G   Isn't there an H as well? My asteroid friends keep talking about H....

 * src.orbital.*, src.veloc.* I agree, with the possible exception of src.veloc.tan.
   Perhaps 'transverse' rather than 'tangential' is more clear?

 - Jonathan


From jcm at head.cfa.harvard.edu  Thu Jun  9 11:46:05 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:46:05 -0400 (EDT)
Subject: T0 : extensions to em, obs, spect, instr
Message-ID: <200506091846.j59Ik5kY003131@urania.cfa.harvard.edu>


UCD comments 2: Rick's suggestions

Hi UCD board,

Rick Hessman proposed a number of UCDs (May 30) and I wanted to comment on them.

One was
 spect.cont    spectral continuum

I endorse adding this, it's very useful for my own data.


Rick suggested either
 em.grav-wave
 em.neutrino
with 'em' redefined as 'emission', or else
 phys.grav-wave
 phys.particle.{cosmic-ray,neutrino}

I like both. If you are comparing the light curves of the
SN1987a neutrino flux and the optical flux, it makes sense
to me to have 
  phot.flux;em.neutrino
even though 'photometry' strictly doesn't apply to non-photons, or
maybe better
  phys.flux;em.neutrino
but I think that
  phys.flux;phys.particle.neutrino
is more generalizable, so I suggest we go with that.

He also proposed an obs.calib tree to describe many different kinds
of observation. I feel many of these are better handled with secondary
words, for instance 
  obs.calib;phot.flux     instead of obs.calib.flux
I know that some people feel excessive use of secondary words
means that a simple search returns too many false positives - but I am
convinced that alternative is an explosion of the vocabulary that
will overwhelm us, and that a mild increase in search query sophistication
will solve the perceived problem.

We already have instr.calib, but many calibrations are not
just for the instrument per se but for the observation as a whole (e.g.
for ground based photometric calibrations it's usually not the
instrument but the sky that is changing and needs calibration).
So I think obs.calib is a better UCD.

So here's my proposal for Rick's list, in which proposed new UCDs
are marked by a *  (sort of the paleolinguistics convention of
marking hypothetical word forms with a *).

 Rick                                   Jonathan 
 phys.grav-wave/em.grav-wave            *phys.wave.gravitational
 phys.particle.neutrino/em.neutrino     *phys.particle.neutrino

(note that phys.wave is a good subtree for other things like
phys.wave.Alfven or phys.wave.dispersionRrelation)

 instr.calib                 *obs.calib  [Calibration observation]
 phot.calib                   obs.image;*obs.calib;phot.flux
       [It's an image; it's for calibration; what are we calibrating - flux.]
                              spect;*obs.calib;phot.flux
       [or, it's a spectrum...]
 obs.calib.dome-flat          obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
       [We're calibrating the flatness of the detector; we're using the dome to do it]
 obs.calib.flux               obs.image;*obs.calib;phot.flux
 obs.calib.freq               spect;*obs.calib;em.freq
       [It's a spectrum; it's for calibration; we're calibrating freq]
 obs.calib.guide-star         meta.id;*obs.calib;*pos.astrometry
       [If this is the name of the guide star used..]
 obs.calib.phot    [What's the difference with obs.calib.flux?]
 obs.calib.pos                obs.image;*obs.calib;*pos.astrometry  (?)
 obs.calib.sky-flat           obs.image;obs.calib;*instr.det.flat
 obs.calib.slit-mask          *instr.spect.slit
 obs.calib.spect              spect;*obs.calib;em.wl
      [If you mean by this an arc spectrum; what diff from obs.calib.wl?]
 obs.calib.veloc              spect;*obs.calib;src.veloc
 obs.calib.wl                 spect;*obs.calib;em.wl

 phot.calib.flux              [same as obs.calib.flux?]
 phot.calib.mag               *obs.calib;em.opt.B   (etc.)
 pos.calib                    *obs.calib;pos
 spect.calib                  spect;*obs.calib
 spect.calib.wl               spect;*obs.calib;em.wl
 spect.calib.freq             spect;*obs.calib;em.freq

Rick's next message on May 30 proposed an 'event' tree.
All his events are things that happen to sources, so we
might want to make this a src.event subtree.
Also, it's "occultation", not "occulation". Otherwise
I like it. But as we agreed in Kyoto, let's wait a while on this subject.


 - Jonathan


From jcm at head.cfa.harvard.edu  Thu Jun  9 11:47:21 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:47:21 -0400 (EDT)
Subject: T0 : extensions to em, obs, spect, instr
Message-ID: <200506091847.j59IlLcR003225@urania.cfa.harvard.edu>


UCD comments 3: the standard vocabulary for the universe

Rick Hessman said:
: 
: Sebastien Derriere said:
: > Solar System UCDs (really Astronomical Object UCDs):
: > they will not be UCDs per the PR. But IVOA may need such a list
: > and a UCD-compatible syntax may be appropriate. If the UCD/Semantics
: > group doesn't want to take that work on, the DM group should
: > probably do it. I think either group could do it, provided we
: > keep the distinction between the two lists (UCDs, as semantics
: > for astronomical non-object concepts, and the other list,
: > as semantics for astronomical objects).
: 


Actually, it was me who said this, Sebastien's message quoted me.

At the time I wrote this, I actually agreed with  Rick; I was trying to
find a compromise approach since it seemed that Sebastien (and I think
Patricio and other originators of the UCDs) do want to make such a
distinction. Someone is going to have to list object-classification
concepts. I would prefer it was the UCD board, but if not, it'll have to
be the DM group or the vo-semantics folks.

However, after the discussion I take a more nuanced (i.e. confused) position.

I do now think there is some real justification for a separate list using the
 ucd = src.class  value = galaxy.spiral
approach: the other approach with
 ucd = src.class.galaxy.spiral 
might be ok, but very quickly we want
 ucd = src.class.galaxy.spiral.SB(r)cd...
 ucd = src.class.star.binary.O7e+PNe/LMXB
 ucd = src.class.comet.sungrazer
 ucd = src.class.body.feature.rupes

In other words, 'galaxy' is not just a concept, it's a classification,
and the coarsest bin in a complicated tree of classifications. 
(Sebastien made a distinction between classification and morphological
type which I don't think is a real one in practice; morph type, variable
star class, spectral type, etc. are all part of the classification of
what this object is).
I don't think the classification's really quite the same as
distinguishing between radial velocity and some other kind of velocity.
And as my examples above show, once you get down to the detailed
classification the UCD syntax doesn't actually make a good match. Rick
will probably argue that it still makes sense to have UCDs which go down
as far as the less detailed level (star.binary etc) and I could buy that.

Like Rick, I focus on the data-header applications more than the
Vizier-catalog applications, and I take it as a clue that in 
FITS headers, "spiral galaxy" is always a keyword value, not a
keyword name. This suggested to me that in fact UCD may not 
be the right controlled vocab for this set of concepts.

But then Sebastien reminded us of the 'concept/property' way of looking
at UCDs, where the question becomes: are there specific properties we
need to describe? To be more specific:

      radial.velocity;src.class.galaxy

would be the radial velocity of a galaxy. Does having this add anything to
just saying

       radial.velocity;src

- do you really care that it's a galaxy and not a star.
This leads to a data model question: what properties do a galaxy and a star
*not* share? For example:
       object.galaxy.spiral.HolmbergRadius
       object.star.convectionParameter

This, to my mind, is the correct role of object types in UCD and argues for a tree
of this kind. Right now, these kind of properties go in the phys or src
list without the 'object.<particularkind>.' prefix.

 - Jonathan








 - Jonathan


From jcm at head.cfa.harvard.edu  Thu Jun  9 11:47:39 2005
From: jcm at head.cfa.harvard.edu (Jonathan McDowell)
Date: Thu, 9 Jun 2005 14:47:39 -0400 (EDT)
Subject: T0: basic UCD tree
Message-ID: <200506091847.j59IldO1003229@urania.cfa.harvard.edu>


* UCD comments 4: overall UCD tree

Hi UCD board,

I looked again at the UCD primary concepts and tried to group them.
The one I am most worried about is "spect".



time,pos,em,phot  Fundamental astro concepts, fine. 

obs, phys  Also good basic concepts

arith    a good basic tree, although "math" might be better.
stat     Maybe should be under arith?

src      Another fundamental concept, although as usual I would argue for 
         a distinction between "src" (2D on the sky, results of observation) and
         "object" (real 3D thing in space).

instr    Fairly fundamental but one could argue should be under obs

spect    I worry about spect - this is a kind of data.
         If spect, why not image? I predict a few years from now
         we will have to change spec and instr.image to data.spect, data.image, etc.

Despite this worry, I am willing to endorse the current list for the PR.



 - Jonathan


From andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun 10 02:00:19 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri, 10 Jun 2005 11:00:19 +0200
Subject: T0: UCDs for "em"
In-Reply-To: <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
	<20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
	<AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
Message-ID: <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>

Miguel Cervino wrote:

> First I center in "Q" UCDs, and I propose to keep:
>
> Q|em.energy        |Energy value in the em frame
> Q|em.freq         |Frequency value in the em frame
> Q|em.wavenumber        |Wavenumber value in the em frame
> Q|em.wl         |Wavelength value in the em frame

The point is that:
1. It would be clearer to use the em branch just to describe the
electro-magnetic axis (radio, ir,opt,...,line,..) and move energy, freq, wl
to the phys branch.
2. We now have phys.energy and em.energy
If you ask the assign tool
http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd
the word energy is translated always into phys.energy : correct.
You only get em.energy if you type photon energy : correct too.
But we are describing the same quantity with two ucd-words!


> Q|em.wl.air*         |Wavelength value in the em frame in air frame
>
>       somewhere it should be established default is vacuum?
>       In most optical observation default is air and
>       in UV vacuum as example, but SLOAN data release
>       gives optical wl en vacuum...
yes, things are complicated: you often find <laboratory wl> which, I
suspect, are wl.air in the optical and, obviously, wl.vacuum in the UV!

> Q|em.veloc*        |Apparent radial velocity
> Q|em.veloc.radio*    |radio velocity
> Q|em.veloc.optical*    |optical velocity
> Q|em.veloc.beta*        |velocity/cr
somebody proposed already velocRadio, velocOpt. I ask him/her to re-submit
that proposal

>
> - Change from Q to E:
> Q|em.wl.central     |Central wavelength
> Q|em.wl.effective     |Effective wavelength
Yes, with the flag set to Q and a description like: central wl of Halpha
you'll get only wl.central .

> ... for clarity purpose and hogenity
> the UDCs I would suggest the following changues:
>
> em.IR.K -->  em.IR.2-3um
> em.IR.H -->  em.IR1500-2000nm
> em.IR.J -->  em.IR1000-1500nm
>
> em.opt.I -->  em.opt.750-1000nm
> em.opt.R -->  em.opt.600-750nm
> em.opt.V -->  em.opt.500-600nm
> em.opt.B -->  em.opt.400-500nm
> em.opt.U -->  em.opt.300-400nm
>
> so there no will be confusion with fotometry bands
may be we should go this way, because the names of those bands can be
misleading.
In the case of x- and gamma-rays though there is no confusion, so I would
keep the existing names...

> Finally, I think that the inclusion of em.line would be useful, but
> only for a very sort list of lines so ... I would agree with
> Hydrogen lines, but I do think that em.line.OIII should be
> depreciated (there is several OIII lines!, and if OIII is here, by
> not, O I, or H+K Ca II etc...? so I propose depreciate em.line.OIII ...
the reason for the inclusion of the OIII line is that the doublet 4959+5007
is one of the strongest lines in emission-line objects (second only to
Halpha in most cases). There are surveys in Halpha/beta and in OIII, not in
OI.
My point is: today em.line.OIII is used/useful. The day we'll find other
lines useful we'll propose their inclusion.
By the way: em.line.XXX is not a quantity: it is a qualifier of some other
quantity, e.g. intensity, flux, etc..

Cheers

Andrea



From Hessman at Astro.physik.Uni-Goettingen.DE  Fri Jun 10 03:11:08 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Fri, 10 Jun 2005 12:11:08 +0200
Subject: T0: basic UCD tree
In-Reply-To: <200506091847.j59IldO1003229@urania.cfa.harvard.edu>
References: <200506091847.j59IldO1003229@urania.cfa.harvard.edu>
Message-ID: <25d39d6a9dc407818d6d6b228334efae@Astro.physik.Uni-Goettingen.DE>


On 9 Jun 2005, at 8:47 pm, Jonathan McDowell wrote:

> arith    a good basic tree, although "math" might be better.
> stat     Maybe should be under arith?

I agree :  math covers arith and stat.		*math.arith    *math.stat

> src      Another fundamental concept, although as usual I would argue  
> for
>          a distinction between "src" (2D on the sky, results of  
> observation) and
>          "object" (real 3D thing in space).

Now, now: don't try to bring "concepts" into the UCD world ;-) !

We have to agree that "src" means "object on the sky" (where the  
definition of "sky" is,
of course, relative to an observer, e.g. a spacecraft), since  
everything that
UCD describes is for observations or observed properties.   Otherwise,  
the whole
"concept" (or, God-forbid, "ontology") discussion comes up again!

Right now, the official UCD description of "src" is "Source" - not very  
helpful.  I suggest
using "Observed source viewed on the sky".

> instr    Fairly fundamental but one could argue should be under obs

No!:  "obs" is an observation thing made with an instrument "inst".  The
focal length of a telescope isn't (in our present sense) an  
observation, but a
property of an instrument and so doesn't at ALL belong to "obs".


> spect    I worry about spect - this is a kind of data.
>          If spect, why not image? I predict a few years from now
>          we will have to change spec and instr.image to data.spect,  
> data.image, etc.

I agree that data.image and data.spec is a much better model, at least  
for observations.  After all, what UCD
often does is to provide generalized "keywords" a la FITS.

On the other hand, the VO theory people might complain that their  
"images" and "spectra" are not really "data".

Sounds like a problem which has to be put off until later.

> But then Sebastien reminded us of the 'concept/property' way of looking
> at UCDs, where the question becomes: are there specific properties we
> need to describe? To be more specific:
>
>       radial.velocity;src.class.galaxy
>
> would be the radial velocity of a galaxy. Does having this add  
> anything to
> just saying
>
>        radial.velocity;src
>
> - do you really care that it's a galaxy and not a star.
> This leads to a data model question: what properties do a galaxy and a  
> star
> *not* share? For example:
>        object.galaxy.spiral.HolmbergRadius
>        object.star.convectionParameter
>
> This, to my mind, is the correct role of object types in UCD and  
> argues for a tree
> of this kind. Right now, these kind of properties go in the phys or src
> list without the 'object.<particularkind>.' prefix.

This can of worms obviously won't be solved using UCD alone: that's why  
I'm pushing the
development of a parallel system which LOOKS like UCD and can be  
treated/
manipulated/concatenated like UCD but addresses this concept/property  
problem.

Simply put: one person's property is another's  concept and vice versa,  
so we need
a system which can be used in both directions.

>  instr.calib                 *obs.calib  [Calibration observation]
>  phot.calib                   obs.image;*obs.calib;phot.flux
>  obs.calib.dome-flat           
> obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
>  obs.calib.flux               obs.image;*obs.calib;phot.flux
>  obs.calib.freq               spect;*obs.calib;em.freq
>  obs.calib.guide-star         meta.id;*obs.calib;*pos.astrometry
>  obs.calib.phot    [What's the difference with obs.calib.flux?]
>  obs.calib.pos                obs.image;*obs.calib;*pos.astrometry  (?)
>  obs.calib.sky-flat           obs.image;obs.calib;*instr.det.flat
>  obs.calib.slit-mask          *instr.spect.slit
>  obs.calib.spect              spect;*obs.calib;em.wl
>  obs.calib.veloc              spect;*obs.calib;src.veloc
>  obs.calib.wl                 spect;*obs.calib;em.wl
>  phot.calib.flux              [same as obs.calib.flux?]
>  phot.calib.mag               *obs.calib;em.opt.B   (etc.)
>  pos.calib                    *obs.calib;pos
>  spect.calib                  spect;*obs.calib
>  spect.calib.wl               spect;*obs.calib;em.wl
>  spect.calib.freq             spect;*obs.calib;em.freq

I basically think this is a very good compromise.  See my other mail
about problems with instr and others.

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 Hessman at Astro.physik.Uni-Goettingen.DE  Fri Jun 10 03:10:44 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Fri, 10 Jun 2005 12:10:44 +0200
Subject: T0: needed last minute changes
Message-ID: <12358f5050de60892fe99445a10af612@Astro.physik.Uni-Goettingen.DE>

After reading Jonathon's comments and re-reading the UCD vocabulary
document again, I realized that we definitely need a few changes:

1.  I first stumbled over
	
		instr.obsty.site.seeing

	Does this mean we need...

		instr.obsty.site.temperature
		instr.obsty.site.humidity

	Seem like a better solution would be to introduce "weather", which  
permits the concatenation

		instr.obsty.site;weather.seeing

	which would open a new handy family

		weather				| meteorological condition
		weather.seeing		| atmospheric image quality
		weather.temp			| local temperature
		weather.humidity		| relative humidity
		weather.dewpoint		| dewpoint temperature
		weather.precipitation	| presence of rain/snow/sleet (boolean?)

	This would be VERY helpful for VOEvent/RTML.   I won't open up a new
	discussion of the uneven choice of contractions (e.g. "temp" instead of
	"temperature" but "wavenumber" instead of "wavenum" - sigh!).

	The topic "space weather" comes into mind as well , but I'll let others
	worry about that.


2. instr

	First of all, a trivial but needed addition:

		instr.det.temp			| temperature of detector

	Next: we presently have "instr.tel.focus" and "instr.fov" which are
	quantities which refer to the "end-users" - no info about how the fov  
or
	focus came into being.  The problem is whether to assign something
	like "focus" to the telescope or to the instrument.  Generally, the
	fov of an instrument (e.g. CCD camera) is very different from that of  
the
	telescope.   Do we then interpret "instr" things as being from a black
	box or from a specific instrument hanging on a telescope?  If it's the  
latter,
	then one may need double entries.  In any case there's a need for  
something
	like

		instr.tel.aperture		| geometric diameter of telescope optics
		instr.tel.area			| (effective?) collecting area of telescope optics
		instr.tel.focallength		| focal length (effective?) of telescope
		instr.tel.fRatio			| ratio of focal length to aperture diameter
		instr.tel.temp			| temperature of telescope

	After all, we already have instr.focus, which is a much less needed  
number than
	the above!

	Sounds to me as if we need to distinguish between generic instr =
	e.g. telescope+filterwheel+CCD or telescope+spectrograph+CCD and
	"device" (can't think of a better name) which could be just the  
instrument part of the
	above (e.g. just the imaging camera or just the spectrograph).

	This would also imply that we need to make tel a primary key, since  
the telescope
	doesn't "belong" to the generic instrument - it's an associated thing.  
  This would solve
	Jonathon's suggested of using

		obs.image;obs.calib;instr.det.flat;instr.tel.dome

	(i.e. using proposed UCDs obs.calib and instr.tel.dome) by permitting

		obs.image;obs.calib;inst.det.flat;tel.dome

	and would permit the differentiation between e.g. instr.focallength and
	tel.focallength.  On the other hand, this means a lot of double  
entries which
	could only be gotten rid of using something like

		instr;optics.focallength
		tel;optics.focallength

	(unfortunately, "opt" is already taken: if we would be using "optical"  
for
	wavelength band and "optics" for optics, there wouldn't be any  
confusion).

	In summary, we need to get rid of

		instr.tel
		instr.tel.focus

	and add

		optics
		optics.focus
		optics.focallength
		optics.aperture
		optics.area
		optics.fRatio
		tel
		tel.dome		(instr.obsty.dome is no good if there are lots of domes at  
the site)
		tel.mount		(e.g. "alt-az", "equatorial", "english",....)


3. PLEASE PLEASE PLEASE change

			src.class.struct		->	src.class.struct.BautzMorgan
			src.class.distance	->	src.class.distance.Abell
			src.class.richness	->	src.class.richness.Abell
			src.spType		->	src.class.spectral.MK
			src.morph.type		->	src.morph.Hubble

		The present definitions associating general class descriptions with  
very particular versions
		of  mostly extragalactic classifications are absolutely insane!   Or,  
the description has to be
		changed to something like

			src.class.struct		| structure classification, e.g. Bautz-Morgan  
galaxy type
			src.class.distance	| distance classification, e.g. Abell galaxy  
cluster
			src.class.richness	| richness classification, e.g. Abell galaxy  
cluster
			src.class.spectral	| spectral classification, e.g. MK spectral class

		which results in a loss of specificity.  There are other spectral  
classes beyond MK stellar,
		other richness classifications other than Abell (e.g. open stellar  
clusters), ....


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 andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun 10 06:00:51 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri, 10 Jun 2005 15:00:51 +0200
Subject: T6 - solar system UCDs
In-Reply-To: <200506091844.j59IijxU002921@urania.cfa.harvard.edu>
References: <200506091844.j59IijxU002921@urania.cfa.harvard.edu>
Message-ID: <20050610150051.dq8plmskejc4cso8@webmail.sic.rm.cnr.it>

Here are my comments on the UCDs proposed by SS people, see:
  http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html

1. meta.id.(x,y,z)   Cartesian component of a vector

In the present list of ucd-words you find
S|pos.cartesian            |Cartesian (rectangular) coordinates
Q|pos.cartesian.x          |Cartesian coordinate along the x-axis
Q|pos.cartesian.y          |Cartesian coordinate along the y-axis
Q|pos.cartesian.z          |Cartesian coordinate along the z-axis

The keywords used for assigning these ucd-words are:
Q|pos.cartesian.(x,y,z)    |(x,y,z) axis coordinate position (U,V,W)
component projected

so that the description: y component of any-V-quantity
leads to the ucd:       any-V-quantity;pos.cartesian.y

where vectorial quantities are, for the moment,

V|phys.electField
V|phys.magField
V|pos.distance
V|pos.pm
V|pos.precess
V|src.veloc

On the other hand, pos.cartesian.x/y/z is a quantity (position on axis
x/y/z), so that the description :

Xpos on detector   yields   pos.cartesian.x;instr.det

My suggestion is: keep pos.cartesian.x/y/z

2. obs.air    suppress
3. replace with: obs.atm
I agree.
But then we need to change air  into atm  in:
S|obs.air              |Atmosphere
Q|obs.air.extinction   |Atmospheric extinction
and
Q|obs.air.mass         |Airmass   could become
Q|obs.airMass

4. obs.atm.refraction / phys.refraction
I support Jonathan suggestion: change into
obs.atm.refractAngle
phys.refractIndex

5. obs.elongation
The elongation of a celestial body its the angular separation from the body
around which it orbits
The UCD for this quantity already exists: pos.angDistance

6. obs.phaseAng
as above

7. pos.az.ha, pos.az.azi, pos.eq.ha
I agree with the proposal.

8. pos.brc.(), pos.earth()
I basically agree. I also totally agree with Jonathan's comment.

9. pos.eop.()
OK

10. pos.precess
No, the description is all right: just <precession>
Equatorial precession  ==> pos.precess;pos.eq
I prefer this, its more flexible.

11. phys.magAbs.G
I'm only aware of the H mag (which is actually a visual mag!!)
I remind you that phys.magAbs has E-flag: if you just need to specify the
phot band, you can say: phys.magAbs;em.opt.V

12. src.orbital.meanMotion
I suppose it is an average angular velocity (src.veloc.ang;stat.mean).
No strong feelings about it.

13. ...veloc...
to be revised (not only in the framwork of SS!!

14. src.veloc.compon
Not in the present list.

Cheers,

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From pdidelon at cea.fr  Fri Jun 10 06:59:33 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Fri, 10 Jun 2005 15:59:33 +0200
Subject: T6 - solar system UCDs
In-Reply-To: <20050610150051.dq8plmskejc4cso8@webmail.sic.rm.cnr.it>
References: <200506091844.j59IijxU002921@urania.cfa.harvard.edu> <20050610150051.dq8plmskejc4cso8@webmail.sic.rm.cnr.it>
Message-ID: <42A99CC5.4070601@cea.fr>

Nice ;-)

Andrea Preite Martinez wrote:

> Here are my comments on the UCDs proposed by SS people, see:
>  http://portail.imcce.fr/fr/expert/ssvo/wgovp/propucd.html
> 
> 1. meta.id.(x,y,z)   Cartesian component of a vector
> 
> In the present list of ucd-words you find
> S|pos.cartesian            |Cartesian (rectangular) coordinates
> Q|pos.cartesian.x          |Cartesian coordinate along the x-axis
> Q|pos.cartesian.y          |Cartesian coordinate along the y-axis
> Q|pos.cartesian.z          |Cartesian coordinate along the z-axis
> 
> The keywords used for assigning these ucd-words are:
> Q|pos.cartesian.(x,y,z)    |(x,y,z) axis coordinate position (U,V,W)
> component projected
> 
> so that the description: y component of any-V-quantity
> leads to the ucd:       any-V-quantity;pos.cartesian.y
> 
> where vectorial quantities are, for the moment,
> 
> V|phys.electField
> V|phys.magField
> V|pos.distance
> V|pos.pm
> V|pos.precess
> V|src.veloc
> 
> On the other hand, pos.cartesian.x/y/z is a quantity (position on axis
> x/y/z), so that the description :
> 
> Xpos on detector   yields   pos.cartesian.x;instr.det
> 
> My suggestion is: keep pos.cartesian.x/y/z
I think that we introduce this meta.id when working on previous versions
where pos.cartesian did not exists.
> 
> 2. obs.air    suppress
> 3. replace with: obs.atm
> I agree.
> But then we need to change air  into atm  in:
> S|obs.air              |Atmosphere
> Q|obs.air.extinction   |Atmospheric extinction
> and
> Q|obs.air.mass         |Airmass   could become
> Q|obs.airMass
> 
> 4. obs.atm.refraction / phys.refraction
> I support Jonathan suggestion: change into
> obs.atm.refractAngle
> phys.refractIndex
> 
> 5. obs.elongation
> The elongation of a celestial body its the angular separation from the body
> around which it orbits
> The UCD for this quantity already exists: pos.angDistance
Not really!
Unless we do not need src.veloc.* because src.veloc exists. ( joke ;-) )
elongation is a "special/specific" parameter in planetology,
why not then pos.angDistance.elongation
> 
> 6. obs.phaseAng
> as above
It is even less true here because pos.angDistance is the angular distance
betwwen two points (on a sphere) from the observer point of view
and obs.phaseAng gives the angle between the sun and the observer
from the observed spot point of view and is related to illumination,
light incidence and re-emission...
> 
> 7. pos.az.ha, pos.az.azi, pos.eq.ha
> I agree with the proposal.
> 
> 8. pos.brc.(), pos.earth()
> I basically agree. I also totally agree with Jonathan's comment.
> 
> 9. pos.eop.()
> OK
> 
> 10. pos.precess
> No, the description is all right: just <precession>
> Equatorial precession  ==> pos.precess;pos.eq
> I prefer this, its more flexible.
but perhaps not sufficient to "describe completly" precession in some case!
> 
> 11. phys.magAbs.G
> I'm only aware of the H mag (which is actually a visual mag!!)
> I remind you that phys.magAbs has E-flag: if you just need to specify the
> phot band, you can say: phys.magAbs;em.opt.V
~ phys.magAbs.G is a parameter for the derivation of the absolute magnitude of asteroids
> 
> 12. src.orbital.meanMotion
> I suppose it is an average angular velocity (src.veloc.ang;stat.mean).
> No strong feelings about it.
> 
> 13. ...veloc...
> to be revised (not only in the framwork of SS!!
sure
> 
> 14. src.veloc.compon
> Not in the present list.
> 
> Cheers,
> 
> Andrea
> 
> ============================================================================== 
> 
> Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma
> ============================================================================== 
> 
> 

-- 
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------




From mcs at iaa.es  Fri Jun 10 09:01:14 2005
From: mcs at iaa.es (=?ISO-8859-1?Q?Miguel_Cervi=F1o?=)
Date: Fri, 10 Jun 2005 18:01:14 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu> <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it> <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es> <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
Message-ID: <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>

Hi again :)


>> ... for clarity purpose and hogenity
>> the UDCs I would suggest the following changues:
>>
>> em.IR.K -->  em.IR.2-3um
>> em.IR.H -->  em.IR1500-2000nm
>> em.IR.J -->  em.IR1000-1500nm
>>
....

> may be we should go this way, because the names of those bands can be
> misleading.
> In the case of x- and gamma-rays though there is no confusion, so I  
> would
> keep the existing names...
>

Uhmm, for X-ray and gamma-rays I was asking X-ray and gamma-ray  
people....
I know that UCDs are not for humans, but asking about what  soft and  
hard X-rays mean,
the answer is highly dependent on the asked astronomer. Usually they  
talk  only about
soft and hard. "medium-Xrays" is not understood. In fact, most people  
I asked consider
hard X-ray as aprox 4-10 keV band (from maximmun energy from ROSAT/ 
EINSTEIN to max energy by CHANDRA/ASCA/XMM)..... I do not know, but I  
think that
keep em.X-ray.soft medium and hard is misunderstanding for X-ray  
people. Another example,
ROSAT has a "hardness" ratio that is 0.2 keV-1.5keV (soft) vs. 1-4kev  
(hard) (I do not remember exactly the
energies, sorry) where "soft" and "hard" refers to the detectors in  
ROSAT (but they are used in thsi way in the articles)....

In gamma ray, the situation is similar. You can take a look the  
INTEGRAL instruments, or CGRO ones.
The problem is that each energy range use techniques completely  
different (due to the physics of the process) and em.gamma.hard is to  
wide! It includes from only space instruments to only ground based  
instruments (using the atmosphere as detector). In fact some gamma- 
ray people make distinction between gamma-ray VeryHigh gamma-rays and  
Ultra-High gamma rays as clearly different parts of the
electromagnetic spectrum.... (I was also thinking about INTEGRAL  
where a more defined bands
would be and asset).


>> Finally, I think that the inclusion of em.line would be useful, but
>> only for a very sort list of lines so ... I would agree with
>> Hydrogen lines, but I do think that em.line.OIII should be
>> depreciated (there is several OIII lines!, and if OIII is here, by
>> not, O I, or H+K Ca II etc...? so I propose depreciate  
>> em.line.OIII ...
>>
> the reason for the inclusion of the OIII line is that the doublet  
> 4959+5007
> is one of the strongest lines in emission-line objects (second only to
> Halpha in most cases). There are surveys in Halpha/beta and in  
> OIII, not in
> OI.

ok :)

About other issues. I also agree with include arith and stat in  
"math". I also suggest

        math.stat.moment

that means the order moment of the statistical distribution, i.e.  
mean is 1,
variance is 2, skewness 3, and kurtosis 4....), so allows to include  
more statistical information
(e.j. there is some published data in skewness distributions of  
globular cluster, also are useful
for some synthesis models)


In the case of:


>
>> spect    I worry about spect - this is a kind of data.
>>          If spect, why not image? I predict a few years from now
>>          we will have to change spec and instr.image to  
>> data.spect, data.image, etc.
>>
>
> I agree that data.image and data.spec is a much better model, at  
> least for observations.  After all, what UCD
> often does is to provide generalized "keywords" a la FITS.
>
> On the other hand, the VO theory people might complain that their  
> "images" and "spectra" are not really "data".
>
> Sounds like a problem which has to be put off until later.


Form a theoretical point of view (mine) theory results can be  
considered as "data", produced by a computer
instead a telescope but.... (any case the results of theory will be  
also under a tag <TABLEDATA> isn't  it?
(it is my very particular opinion). (any case there is also a S UCD  
called "meta.modelled"


Finally, about the "line" atom used in "spect"... Uhmm, I do not know  
if there is a more usefull atom. I mean, some lick indices, as  
example, are obtained from "bands" and no lines.... there is no  
problem is it is explicti in the definition that it would refers not  
only to lines but also to bands...

In the same way, I think that

spect.line.intensity  ---> spect.line; phot.fluxDens

Atoms like: profile. width, eqwidth sound ok, but  
spect.line.asymmetry is not included in spect.line.profile?
also for spect.line.broad? (this last I am not sure)


Nice weekend

     Miguel


From Matteo.Guainazzi at sciops.esa.int  Mon Jun 13 02:48:40 2005
From: Matteo.Guainazzi at sciops.esa.int (Matteo Guainazzi)
Date: Mon, 13 Jun 2005 09:48:40 +0000
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
 <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
 <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
 <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
 <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
 <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
Message-ID: <42AD5678.9010707@sciops.esa.int>

Dear Miguel, dear Andrea,

 from the X-ray perspective, I confirm basically Miguel's findings. The 
terms "soft", "medium", "hard" X-rays have been and are being used with 
very different meanings in different papers. What is "hard" for 
XMM-Newton and Chandra (2 to 8, 10 or 15 keV), was called sometimes 
"intermediate" in BeppoSAX papers. Moreover, I have almost never seen 
"medium" in a published paper.

 There are two possible ways out:

    * to substitute words with explicit energy ranges, as suggested for
      the optical bands. "Soft" may become "0.1-2.4 keV" (the energy
      range of the ROSAT All Sky-Survey); "hard" becomes "2-10 keV" (the
      energy range of ASCA surveys), or "2-8 keV" (if we want to follow
      the typical range being used in Chandra surveys), or "2-12 keV"
      (if one wants to follow the typical range used in XMM-Newton
      source catalogues); "medium" may become "0.5-4.5 keV" (the energy
      range of the Einstein Slew Survey). "Very hard" (it does not
      currently exist, but it should if gamma-ray astronomers agree) may
      become "15-200 keV" (typical BeppoSAX/PDS range).
    * to substitute explicit survey bands and sub-bands (ROSAT has, for
      instance, a "soft soft band, 0.1-0.4 keV, and a "hard soft band",
      0.4-2.4 keV) for qualitative qualifiers; e.g.: "Einstein Slew
      Survey band" (".emss"), or "ROSAT All Sky Survey soft" (".rasss"),
      "PDS energy range" (".pds") instead of "soft", ...

 The consequences of either choice are clear: in the former, we risk 
mis-understanding old surveys (those done when I was not born, but still 
in use), in the latter we multiply we number of UCD endlessly.

 None of the above solutions is therefore satisfactory, from my point of 
view. As often in the VO context we are trying to extract order from 
chaos, i.e. one to derive standards where standards have never been 
applied in the past.

 My favorite (and surely controversial) solution? A more conservative 
and radical (!) approach: we remove "soft", "medium" and "hard", and 
keep only "em.X-rays".

 Regards, Matteo

-- 
Matteo Guainazzi
XMM-Newton SOC				Matteo.Guainazzi at sciops.esa.int
European Space Astronomy Center	of ESA	Phone:     +34 91 8131 176
VILSPA, Apartado 50727, E-28080 Madrid 	Fax:       +34 91 8131 172         


From andrea.preitemartinez at rm.iasf.cnr.it  Mon Jun 13 03:10:31 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Mon, 13 Jun 2005 12:10:31 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
	<20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
	<AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
	<20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
	<872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
Message-ID: <20050613121031.r4m3ie1qsyxw44cg@webmail.sic.rm.cnr.it>

Hi Miguel:

>> In the case of x- and gamma-rays though there is no confusion, so I  
>> would keep the existing names...
> Uhmm, for X-ray and gamma-rays I was asking X-ray and gamma-ray
> people....

I gave those bands the names soft/medium/hard x-rays because I'm an x-ray
man and I'm coming from an x/gamma-ray institute...

> I know that UCDs are not for humans, but asking about what  soft and
> hard X-rays mean,
> the answer is highly dependent on the asked astronomer. Usually they
> talk  only about
> soft and hard. "medium-Xrays" is not understood. In fact, most people
> I asked consider
> hard X-ray as aprox 4-10 keV band (from maximmun energy from ROSAT/
> EINSTEIN to max energy by CHANDRA/ASCA/XMM)..... I do not know, but I
> think that
> keep em.X-ray.soft medium and hard is misunderstanding for X-ray
> people. Another example,
> ROSAT has a "hardness" ratio that is 0.2 keV-1.5keV (soft) vs. 1-4kev
> (hard) (I do not remember exactly the
> energies, sorry) where "soft" and "hard" refers to the detectors in
> ROSAT (but they are used in this way in the articles)....

You are perfectly right, usually they think in terms of the bandpass of
their instrument. 4 keV are hard for ROSAT people because 4keV is hardER
than 0.2 keV (their soft limit). For XMM people 10keV are hard. For
BeppoSAX people 10 keV are medium, because the bandpass reaches 2-300 keV.
We should not forget that we are parsing the em spectrum, we have to
describe it, not the bandpasses of instruments.
So, to avoid a narrow-minded interpretation of the ucd-words em.X-ray.*
your suggestion (use energies instead of labels) is the safest one.

> In gamma ray, the situation is similar. You can take a look the
> INTEGRAL instruments, or CGRO ones.
> The problem is that each energy range use techniques completely
> different (due to the physics of the process) and em.gamma.hard is to
> wide! It includes from only space instruments to only ground based
> instruments (using the atmosphere as detector). In fact some gamma-
> ray people make distinction between gamma-ray VeryHigh gamma-rays and
> Ultra-High gamma rays as clearly different parts of the
> electromagnetic spectrum....

I agree that gamma.hard is rather wide!! Probably we should go for
at least three bands:
hard/high
VeryHigh
UltraHigh

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From andrea.preitemartinez at rm.iasf.cnr.it  Mon Jun 13 06:09:09 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Mon, 13 Jun 2005 15:09:09 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <42AD5678.9010707@sciops.esa.int>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it>
	<18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu>
	<20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it>
	<AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es>
	<20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it>
	<872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es>
	<42AD5678.9010707@sciops.esa.int>
Message-ID: <20050613150909.dc3n3n7vynswgkkk@webmail.sic.rm.cnr.it>

Quoting Matteo Guainazzi:

> Dear Miguel, dear Andrea,

>  My favorite (and surely controversial) solution? A more conservative
> and radical (!) approach: we remove "soft", "medium" and "hard", and
> keep only "em.X-rays".

No way, Matteo!! How do you define the beginning and the end energies of
what you call x-ray :) ?
The only solution is to decouple energies from sub-bands, and to describe
"regions" of the em spectrum by numbers and not by labels.

Regards

Andrea


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From Hessman at Astro.physik.Uni-Goettingen.DE  Mon Jun 13 06:22:10 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Mon, 13 Jun 2005 15:22:10 +0200
Subject: T0: UCDs for "em" & "spect"
In-Reply-To: <20050613121031.r4m3ie1qsyxw44cg@webmail.sic.rm.cnr.it>
References: <20050602152438.fdmq7yxtgdcgg40k@webmail.sic.rm.cnr.it> <18AB023D-4017-4716-BA26-6642EA40EC36@noao.edu> <20050603101129.diyu1dvr2wj4sg4g@webmail.sic.rm.cnr.it> <AFA10E01-4408-456C-B567-2D0517EE9549@iaa.es> <20050610110019.0nl83m6u32zkks0w@webmail.sic.rm.cnr.it> <872B0715-B051-49A2-9DE8-E23200EE41D3@iaa.es> <20050613121031.r4m3ie1qsyxw44cg@webmail.sic.rm.cnr.it>
Message-ID: <e78085b4bbb2bcd59f2a63fcc24fcdf3@Astro.physik.Uni-Goettingen.DE>

>> In gamma ray, the situation is similar. You can take a look the
>> INTEGRAL instruments, or CGRO ones.
>> The problem is that each energy range use techniques completely
>> different (due to the physics of the process) and em.gamma.hard is to
>> wide! It includes from only space instruments to only ground based
>> instruments (using the atmosphere as detector). In fact some gamma-
>> ray people make distinction between gamma-ray VeryHigh gamma-rays and
>> Ultra-High gamma rays as clearly different parts of the
>> electromagnetic spectrum....
>
> I agree that gamma.hard is rather wide!! Probably we should go for
> at least three bands:
> hard/high
> VeryHigh
> UltraHigh

But the problem remains that "hard" and "very" and "ultra" are  
undefined.
If the band is so wide, then use more than 3 bands, just like the  
present
use in the radio (which is also wide).

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 andrea.preitemartinez at rm.iasf.cnr.it  Mon Jun 13 09:00:55 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Mon, 13 Jun 2005 18:00:55 +0200
Subject: T0 : extensions to em, obs, spect, instr
In-Reply-To: <200506091846.j59Ik5kY003131@urania.cfa.harvard.edu>
References: <200506091846.j59Ik5kY003131@urania.cfa.harvard.edu>
Message-ID: <20050613180055.cwxyf7fm3u88css4@webmail.sic.rm.cnr.it>

Quoting Jonathan McDowell :

> Rick Hessman proposed a number of UCDs (May 30) and I wanted to 
> comment on them.
> One was
>  spect.cont    spectral continuum
> I endorse adding this, it's very useful for my own data.

If you mean that  spect.cont is a sort of flux per unit something, than
it'll be better to wait for a revision of the fluxDensity word

> So here's my proposal for Rick's list, in which proposed new UCDs
> are marked by a *  (sort of the paleolinguistics convention of
> marking hypothetical word forms with a *).
>
>  Rick                                   Jonathan
>  phys.grav-wave/em.grav-wave            *phys.wave.gravitational
>  phys.particle.neutrino/em.neutrino     *phys.particle.neutrino
>  instr.calib                 *obs.calib  [Calibration observation]

Yes, we could introduce the three sub-trees:
S | phys.wave.*
S | phys.particle.*  (starting for the already present electron)
S | obs.calib(.*)

A few comments on the following list:

>  phot.calib                   obs.image;*obs.calib;phot.flux
>        [It's an image; it's for calibration; what are we calibrating - flux.]
>                               spect;*obs.calib;phot.flux
>        [or, it's a spectrum...]
>  obs.calib.dome-flat          
> obs.image;obs.calib;*instr.det.flat;*instr.tel.dome
>        [We're calibrating the flatness of the detector; we're using 
> the dome to do it]
>  obs.calib.flux               obs.image;*obs.calib;phot.flux
>  obs.calib.freq               spect;*obs.calib;em.freq
>        [It's a spectrum; it's for calibration; we're calibrating freq]
>  obs.calib.guide-star         meta.id;*obs.calib;*pos.astrometry
>        [If this is the name of the guide star used..]
>  obs.calib.phot    [What's the difference with obs.calib.flux?]
>  obs.calib.pos                obs.image;*obs.calib;*pos.astrometry  (?)
>  obs.calib.sky-flat           obs.image;obs.calib;*instr.det.flat
>  obs.calib.slit-mask          *instr.spect.slit
>  obs.calib.spect              spect;*obs.calib;em.wl
>       [If you mean by this an arc spectrum; what diff from obs.calib.wl?]
>  obs.calib.veloc              spect;*obs.calib;src.veloc
>  obs.calib.wl                 spect;*obs.calib;em.wl
>  phot.calib.flux              [same as obs.calib.flux?]
>  phot.calib.mag               *obs.calib;em.opt.B   (etc.)
>  pos.calib                    *obs.calib;pos
>  spect.calib                  spect;*obs.calib
>  spect.calib.wl               spect;*obs.calib;em.wl
>  spect.calib.freq             spect;*obs.calib;em.freq

1. the order is inverted: e.g.
obs.image;*obs.calib;phot.flux   ==> phot.flux;obs.calib
spect;*obs.calib;src.veloc       ==> src.veloc;obs.calib
*obs.calib;em.opt.B              ==> phot.mag;em.opt.B;obs.calib

The same for Rick's suggestions:
instr/tel;optics.focallength     ==> optics.focallength;instr/tel

2. We have to maintain UCD-words, not UCDs

3. Saying: [It's an image; it's for calibration; what are we calibrating -
flux.] means that you are probably describing a detaset, so an alternative
description could be: [name (or url, or ...) of an image used for
flux-calibrating other images of raw data]
that could translate into :
meta.id;obs.image;obs.calib

We probably need a deeper discussion before introducing new trees.
I agree with Jonathan: let's move quickly from WD to PR, and continue at the
same time the discussion on new words, object types, events, etc...

Andrea

==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From seaman at noao.edu  Mon Jun 13 19:27:31 2005
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 13 Jun 2005 19:27:31 -0700
Subject: VOConcepts
Message-ID: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>

Howdy,

I picked this list as the most appropriate place for this  
conversation.  Please comment if you've got a different idea.  This  
discussion is being driven by VOEvent issues, but the implications  
are broader.  Some observations, assumptions, and conclusions:

1) UCDs appear to be the near term VO solution for semantic  
nomenclature.
2) VOEVENT will soon require a VOConcept style mechanism.
3) It seems obvious that VOConcept will borrow UCD syntax.
4) There seems to be significant delay implicit with establishing
         VOConcept as an official offshoot of UCDland.
5) Thus it seems that there will be significant pressure to establish
         VOConcept as a separate namespace of some sort under UCD.

Operating under that assumption, the question is what that namespace  
will look like.  The current snapshot is available at http:// 
monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/UnifiedContentDescriptors

Here are my comments;

1) Proper names don't belong under the VOConcept namespace.  Whether  
this is a separate namespace of its own, or whether proper names are  
handled by a completely separate mechanism, there is no need to  
specify something like "solar_system.Sun".  Call me a radical, but I  
think the Sun should simply be called "Sun".  In any event, a proper  
name of an object or process is distinct from any sort of  
classification of that particular object or process.

2) A "coronal mass ejection" is not equivalent to  
stars.corona;process.mass-loss.ejection, whether or not this  
precisely describes the physical event.  My point is that just as  
with proper names, the astronomical community has chosen to assign  
"proper class names" to certain phenomena:  CMEs, GRBs, KBOs, etc.   
We will fail if we seek to provide a namespace that usefully predicts  
what new class names will be needed in the future.  Rather, we need a  
mechanism for adding new identifiers.

3) Which is it?  Sun;process.pulsation or Sun;seismology?  Again,  
"helioseismology" is an identifier distinct from the latter  
classification.

4) We need neither stars;planets nor stars.planets - just planets.  I  
think we can assume for most purposes that if you are describing a  
planet that a star is somewhere in the neighborhood.

5) How about both stars.multiple and stars.binary?  These are just  
two out of several clustering options, such as stars.cluster, for  
that matter.

6) It's interesting what stars.nearby is trying to describe, but this  
seems pretty parochial.  There are a lot of "neighborhoods" scattered  
throughout astronomical semantics.  Maybe there is some way to  
generalize this as some kind of operator notation.  (On the other  
hand, that seems a bit precious.)

7) stars.supernova seems redundant.  What else would it be?  This is  
just the "planet" comment revisited.  This is distinct from the  
star.variable family precisely because a SN is rather emphatic.

8) VOConcept (however constituted under whatever name) needs to  
represent stars, galaxies, and other objects.  It isn't so obvious  
that "cosmology" is useful classification for VOEvent purposes.  It  
isn't obvious what VO-wide purposes this classification would be used  
for in general.

9) VOEvent provides a good testbed for a number of VO technologies.   
It seems to me that a VOConcept list targeted precisely at VOEvent  
needs, perhaps augmented by some carefully selected concepts to fill  
in just a few missing items is a good place to start.

Rob Seaman
NOAO 


From Hessman at Astro.physik.Uni-Goettingen.DE  Tue Jun 14 00:47:45 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Tue, 14 Jun 2005 09:47:45 +0200
Subject: VOConcepts
In-Reply-To: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
Message-ID: <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>

  I think we'd all appreciate a general comment on whether ucd-sci is  
the right place for a discussion
of what we have tenatively called VOConcept.   Yes, there are lots of  
potential relations between VOCocept and UCD
- see the Kyoto papers by S. Derriere and A. Allan - so there are lots  
of reasons to include both communities
right now, but the ultimate connections will be indirect by popular  
demand within the UCD community, since the
UCD design documents as they are currently written don't foresee any  
deviations beyond the VOTable-ish uses
of UCDs.

You might ask us to please shut up and worry about this later, but  
we're in the final throes of finishing VOEvent 1.0
and need to make a short-term decision about whether we ignore the  
problem of naming for now (at the cost of
a loss of naming capability) or make an initial plunge in the direction  
of a UCD-like VOConcept (whatever you
want to call it).

Please vote:

___ Please stop talking about VOConcept in this list - we have enough  
to worry about as it is.
___ I think the two issues are still related enough to warrant  
inclusion in the ucd-sci discussion list for now.

Based upon the tally, we can decide to continue (at least now and then)  
or to start a new list.

If you vote for stopping, then please ignore the rest of this message  
and "have a nice day." :-)


On 14 Jun 2005, at 4:27 am, Rob Seaman wrote:

> I picked this list as the most appropriate place for this  
> conversation.  Please comment if you've got a different idea.  This  
> discussion is being driven by VOEvent issues, but the implications are  
> broader.  Some observations, assumptions, and conclusions:
>
> 1) UCDs appear to be the near term VO solution for semantic  
> nomenclature.

SOME semantic nomenclature.  My feeling is that there is lots of  
resistance to a generalization and not just
because of short-term release pressures.

> 2) VOEVENT will soon require a VOConcept style mechanism.

VOEvent needs it NOW.

> 3) It seems obvious that VOConcept will borrow UCD syntax.
> 4) There seems to be significant delay implicit with establishing
>         VOConcept as an official offshoot of UCDland.
> 5) Thus it seems that there will be significant pressure to establish
>         VOConcept as a separate namespace of some sort under UCD.

or, more likely, parallel to UCD.

> Operating under that assumption, the question is what that namespace  
> will look like.  The current snapshot is available at  
> http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ 
> UnifiedContentDescriptors
>
> Here are my comments;
>
> 1) Proper names don't belong under the VOConcept namespace.  Whether  
> this is a separate namespace of its own, or whether proper names are  
> handled by a completely separate mechanism, there is no need to  
> specify something like "solar_system.Sun".  Call me a radical, but I  
> think the Sun should simply be called "Sun".  In any event, a proper  
> name of an object or process is distinct from any sort of  
> classification of that particular object or process.

I agree.  For those cases (and not just the Sun) we need

	<object voconcept="planet">Jupiter</object>
	<object voconcept="stars.variable.LMXB">RXJ1234+567</object>
	<object voconcept="galaxies.spiral">NGC12345</object>
	<object voconcept="event.burst;em.gamma-ray">GRB12345</object>

Note the combination of UCD and VOConcept in the last case and note that

	<object ucd="em.gamma-ray" voconcept="event.burst"/>

is fine for simple things but isn't necessarily the same thing for more  
complex naming purposes.

> 2) A "coronal mass ejection" is not equivalent to  
> stars.corona;process.mass-loss.ejection, whether or not this precisely  
> describes the physical event.  My point is that just as with proper  
> names, the astronomical community has chosen to assign "proper class  
> names" to certain phenomena:  CMEs, GRBs, KBOs, etc.  We will fail if  
> we seek to provide a namespace that usefully predicts what new class  
> names will be needed in the future.  Rather, we need a mechanism for  
> adding new identifiers.

Both.  The complex naming will enable VO-technology to combine  
information in new ways maybe we haven't thought of.  On the
other hand, there has to be a human interface so that the user can use  
terms like "GRB" or "KBO".   Yes, by combining UCD-like
elements, we're getting close to starting an ontological analysis, but  
just barely and not necessarily because we WANT an ontology.
Thus, CME = stars.corona;process.mass-loss.ejection is fine - one for  
the human, one for the computer.

> 3) Which is it?  Sun;process.pulsation or Sun;seismology?  Again,  
> "helioseismology" is an identifier distinct from the latter  
> classification.

Neither if "Sun" is kept as a proper name ;-)

	<helioseismicData ucd="em.opt phys.wave" voconcept="process.pulsation">
		<object voconcept="stars">Sun</object>
		<data>.....</data>
	</helioseismicData>

> 4) We need neither stars;planets nor stars.planets - just planets.  I  
> think we can assume for most purposes that if you are describing a  
> planet that a star is somewhere in the neighborhood.
>
> 5) How about both stars.multiple and stars.binary?  These are just two  
> out of several clustering options, such as stars.cluster, for that  
> matter.
>
> 6) It's interesting what stars.nearby is trying to describe, but this  
> seems pretty parochial.  There are a lot of "neighborhoods" scattered  
> throughout astronomical semantics.  Maybe there is some way to  
> generalize this as some kind of operator notation.  (On the other  
> hand, that seems a bit precious.)

No - this type of inclusion is exactly what is needed for a totally  
different VO application: education and public outreach.  See
http://www.communicatingastronomy.org/index.html for a VO-related group  
which is interested in such concepts.  Nearby stars
are interesting because they move on the sky.   "Nearby" to a  
professional is perhaps not an interesting concept - just go to
Sinbad and get the latest catalogue to pick out what you want - but  
identifying images available to the public as being interesting
for studying proper motion and parallax is a great thing and it would  
be nice to have a universal identifier for that purpose.  The
names themselves are what's important - it's the need for a name which  
should drive the list.

> 7) stars.supernova seems redundant.  What else would it be?  This is  
> just the "planet" comment revisited.  This is distinct from the  
> star.variable family precisely because a SN is rather emphatic.

The problem of hierarchical naming (and hence implict primitive  
ontologies) came up early in RTML: our first list was a random
collection of names - "star", "supernova", "cepheid",... - but it  
became difficult to manage simply because of the danger of muliple
entries.   A minimum amount of hierarchy insures that the  
administration of the names is straight-forward and even eases their
use in GUIs and other more mundane uses.

> 8) VOConcept (however constituted under whatever name) needs to  
> represent stars, galaxies, and other objects.  It isn't so obvious  
> that "cosmology" is useful classification for VOEvent purposes.  It  
> isn't obvious what VO-wide purposes this classification would be used  
> for in general.

I dropped "cosmology" from the original VOConcept list because my  
VOEvent colleagues were taken somewhat aback with
how quickly such a list can grow and because there's no immediate need  
for "cosmology" in VOEvent.

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------


From andrea.preitemartinez at rm.iasf.cnr.it  Tue Jun 14 06:06:39 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Tue, 14 Jun 2005 15:06:39 +0200
Subject: VOConcepts
In-Reply-To: <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
	<6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
Message-ID: <20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>

Dear Rick,

I think I will not vote.

I find the discussion (any discussion) among people with different ideas
very stimulating.
And sometimes also more useful than perfect agreement.
Reducing the size of the group until you can feel eventually "among us"
is not good at all in real life, certainly not in the VO.

Just to show you that you are not the only one "uneasy" with somebody
else's point of view, I'll make an example of how "uneasy" could feel an
UCD-folk like me.
Take for instance the UCD you proposed few days ago:

instr.obsty.site;weather.seeing  just to express "seeing"

When I saw it I made a jump on my chair: why?
In inverse order of importance:

1. The UCD-like syntax is wrong: first the "quantity", then the "qualifier"
it should read: weather.seeing;instr.obsty.site

2. We are proposing UCD-words, not UCDs. If you propose an independent word
for "seeing", ok, it's :weather.seeing

3. My mind works in terms of "how to assign ucd-words starting from a
description, and then build an UCD" e.g. in term of the process to
build an UCD from one or more keyword(s):
the "keywords => ucd-words => UCDs" chain.
It is impossible (in this framework) to go from the single keyword
"seeing" to an UCD composed of two UCD-words
(each one of these UCD-words needs its own description).

Let's reverse the roles: you jump on the chair when you see the description
of the src.class.* words.
You are perfectly right. What is not said is that I do not use the
description
field to assign words/ucds: I use a series of words (keywords
derived from the description) that are OR-ed,
which is exactly equivalent to the loosier description you suggest.


As I already said, the ucd vocabulary is not only composed of words
that are "quantities". More and more "objects" are creeping in, and I can
imagine the development of two sub-lists :

a "q-list" slowly evolving (or even stabilized; after all the number of
new (astro-)physical quantities per year is probably very easy
to control!!)

and an "o-list" (or whatever name we decide for it!!) for "non-quantities",

both lists with the same syntax (just for simplicity and
"interoperability" (!!),
so that we can continue to build UCDs of the form:

word[q-list];word[o-list] ...

as we do today without knowing that we are actually doing it (!)

Andrea


==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================


From roy at cacr.caltech.edu  Tue Jun 14 08:47:54 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Tue, 14 Jun 2005 08:47:54 -0700
Subject: VOConcepts
In-Reply-To: <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu> <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
Message-ID: <90d425de570af37c027e96fc39d04638@cacr.caltech.edu>


On Jun 14, 2005, at 12:47 AM, Frederic V. "Rick" Hessman wrote:

>  I think we'd all appreciate a general comment on whether ucd-sci is 
> the right place for a discussion
> of what we have tenatively called VOConcept.

Rick

It says in the UCD document "UCD describe astronomical quantities", 
meaning that they are "semantic meaning of data quantities", for 
example "phys.temperature".  The implication is that UCD is NOT 
something like "satellite.Phobos;planet.Mars" and it is NOT something 
like "image.jpeg;human.JacquesChirac". I believe that the scope here is 
correct, and that extensions in to these other areas of knowledge will 
slow down the well-developed and sophisticated UCD effort.  One of the 
best things about UCD is that it has been mined from thousands of table 
instances written by hundreds of astronomers, and therefore has 
unimpeachable credentials as a representation of the astronomical 
community.

However, we should tackle wider questions when supported by use cases 
from the community. I believe the UCD effort should become part of a 
wider "semantics" effort, which may use UCD syntax for other areas of 
knowledge (eg. astrophysical events), or it may use OWL or RDF or other 
syntax. Frankly I don't care about the syntax part, that comes later: 
what is important in these semantics efforts is formalizing some branch 
of knowledge so that computers can record, compare, and deduce.

> Yes, there are lots of potential relations between VOConcept and UCD

I would prefer not to use the term "VOConcept", as it is too vague. I 
think the Semantics WG should concentrate on small, well-defined, 
areas.

> You might ask us to please shut up and worry about this later, but 
> we're in the final throes of finishing VOEvent 1.0 and need to make a 
> short-term decision about whether we ignore the problem of naming for 
> now (at the cost of a loss of naming capability) or make an initial 
> plunge in the direction of a UCD-like VOConcept (whatever you want to 
> call it).

I think that VOEvent should be published as version 1.0 Working Draft 
without any formal semantics for describing events, but rather describe 
events in natural language: "Looks like an exploding square galaxy" 
would be a typical description. Then in VOEvent 1.1 we can tackle 
formal semantics and other matters.

And that formal description of astronomical events should not be called 
"VOConcept", but something more specific, such as "Unified Event 
Description", or "VOEventDescription". The first task of that 
discussion group is define what is the area of knowledge that is being 
covered, and agree to a short paragraph expressing what is an is not 
being formalized into syntax. For example, in VOEventDescription, is it 
an event when Michael Jackson is acquitted? How about when a new planet 
is discovered? How about a flare from a star that flares every 2 weeks?

I believe that defining scope is the key to progress here, and that the 
tighter that scope, the better chances for agreement. Otherwise we are 
caught in a morass of ontological questions. In the words of Bill 
Clinton, "It depends upon what the meaning of the word is means. "

> Please vote:
> ___ Please stop talking about VOConcept in this list - we have enough 
> to worry about as it is.
> ___ I think the two issues are still related enough to warrant 
> inclusion in the ucd-sci discussion list for now.
>
> Based upon the tally, we can decide to continue (at least now and 
> then) or to start a new list.

I think the discussion of VOEventDescription should take place in the 
VOEvent mailing list, perhaps copying the entire Semantics WG when 
wider issues come up.

Roy


From seaman at noao.edu  Tue Jun 14 09:54:03 2005
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 14 Jun 2005 09:54:03 -0700
Subject: VOConcepts
In-Reply-To: <90d425de570af37c027e96fc39d04638@cacr.caltech.edu>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu> <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE> <90d425de570af37c027e96fc39d04638@cacr.caltech.edu>
Message-ID: <D121ED79-8C51-425F-8075-0A3AC0B549BF@noao.edu>

Roy says:

> I think the discussion of VOEventDescription should take place in  
> the VOEvent mailing list, perhaps copying the entire Semantics WG  
> when wider issues come up.

I've forwarded the last few messages to VOEvent.  Further discussion  
will continue over there.

Rob Seaman
NOAO


From Hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun 15 00:24:44 2005
From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman)
Date: Wed, 15 Jun 2005 09:24:44 +0200
Subject: src.class.* and weather.*
In-Reply-To: <20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu> <6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE> <20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>
Message-ID: <25e0156b6e8fe2c7269c22897f2887f8@Astro.physik.Uni-Goettingen.DE>

> Just to show you that you are not the only one "uneasy" with somebody
> else's point of view, I'll make an example of how "uneasy" could feel  
> an
> UCD-folk like me.
> Take for instance the UCD you proposed few days ago:
> instr.obsty.site;weather.seeing  just to express "seeing"
>
> When I saw it I made a jump on my chair: why?
> In inverse order of importance:
>
> 1. The UCD-like syntax is wrong: first the "quantity", then the  
> "qualifier"
> it should read: weather.seeing;instr.obsty.site

Sorry - I confess that I haven't been worrying AT ALL about things like  
order, since
the examples I've been worrying about don't depend upon it: is there  
really a
fundamental difference between "seeing at an  
observatory"=weather.seeing;instr.obsty.site
and "observatory's seeing"=intr.obsty.site;weather.seeing.  Maybe for  
some extreme
examples and onotolgy folks, but otherwise......

> 2. We are proposing UCD-words, not UCDs. If you propose an independent  
> word
> for "seeing", ok, it's :weather.seeing

True, but my bottom line is how to use them to express something.  The  
UCD words
are defined not just to be there but to be used.   I forgot to  
distinguish between words
and atoms - excuse moi!

> 3. My mind works in terms of "how to assign ucd-words starting from a
> description, and then build an UCD" e.g. in term of the process to
> build an UCD from one or more keyword(s):
> the "keywords => ucd-words => UCDs" chain.
> It is impossible (in this framework) to go from the single keyword
> "seeing" to an UCD composed of two UCD-words
> (each one of these UCD-words needs its own description).

Hmmm.... don't quite get that.  My approach has been
	- I want to express something
	- look at the official UCD list to see what comes closest
	- if there's no exact/good match, look for related things to see if  
composing works
	- if there are no matches/composing solutions at all, think of new  
atoms or words, worrying about whether one
		needs a single atom/family of words or just additions to present  
families
Not obvious that we're talking about a different process, but just my  
laziness in atom/word
order, no specification of the "syntax code" and too few descriptions.

> Let's reverse the roles: you jump on the chair when you see the  
> description
> of the src.class.* words.
> You are perfectly right. What is not said is that I do not use the
> description
> field to assign words/ucds: I use a series of words (keywords
> derived from the description) that are OR-ed,
> which is exactly equivalent to the loosier description you suggest.

Sorry - still don't get this.....   Are you saying that  
src.class.richness DOESN'T mean
Abell class  (even though that's what the official list says) or not?   
If it  DOES mean
that, then we need to rename the word.  If it DOESN'T mean that, we  
need to change
the description.  Either way, we need to change something, because  
leaving it as
it is will forever prevent someone from using richness for anything  
else with
a good conscience.   It's perfectly valid for someone to suggest a word  
based on their
own needs (indeed, this is the BEST way), but the UCD community should  
make sure
that the necessary generalizations are made when needed, and in the  
case of my
list, I feel they are needed.

> As I already said, the ucd vocabulary is not only composed of words
> that are "quantities". More and more "objects" are creeping in, and I  
> can
> imagine the development of two sub-lists :
>
> a "q-list" slowly evolving (or even stabilized; after all the number of
> new (astro-)physical quantities per year is probably very easy
> to control!!)
>
> and an "o-list" (or whatever name we decide for it!!) for  
> "non-quantities",
>
> both lists with the same syntax (just for simplicity and
> "interoperability" (!!),
> so that we can continue to build UCDs of the form:
>
> word[q-list];word[o-list] ...
>
> as we do today without knowing that we are actually doing it (!)

I'm have been arguing for exactly this solution, but I have been  
getting the impression that others aren't
so happy with it.

I've trimmed down the VOConcept list to a bit more than 100  
words/compositions
to include only those which are needed by VOEvent.   I'd be very happy  
to add "syntax codes"
and formal descriptions, trim the list even further, mail everyone a  
down-to-earth ASCII file, and
drop the whole issue of XML Schema integration if the UCD community  
would absorb VOConcept.

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 andrea.preitemartinez at rm.iasf.cnr.it  Wed Jun 15 01:29:05 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed, 15 Jun 2005 10:29:05 +0200
Subject: src.class.* and weather.*
In-Reply-To: <25e0156b6e8fe2c7269c22897f2887f8@Astro.physik.Uni-Goettingen.DE>
References: <18E084E6-5413-49C6-ABB0-CFAD3CFA1D80@noao.edu>
	<6e48c566b5bd5a515f17edbe25223fbd@Astro.physik.Uni-Goettingen.DE>
	<20050614150639.qgep7mgcut1cskg8@webmail.sic.rm.cnr.it>
	<25e0156b6e8fe2c7269c22897f2887f8@Astro.physik.Uni-Goettingen.DE>
Message-ID: <20050615102905.vk0zlgvdmmlck4sc@webmail.sic.rm.cnr.it>


>> In inverse order of importance:
>> 1. The UCD-like syntax is wrong: first the "quantity", then the  "qualifier"
>> it should read: weather.seeing;instr.obsty.site
>
> Sorry - I confess that I haven't been worrying AT ALL about things like
> order...
That's why I said it's the least important thing :)

>> 3. My mind works in terms of "how to assign ucd-words starting from a
>> description, and then build an UCD" ...
>> It is impossible (in this framework) to go from the single keyword
>> "seeing" to an UCD composed of two UCD-words
>> (each one of these UCD-words needs its own description).
>
> Hmmm.... don't quite get that.  My approach has been
> 	- I want to express something
> 	- look at the official UCD list to see what comes closest
> 	- if there's no exact/good match, look for related things to see if
> composing works

The above points correspond to the action:
   - find the ucd-word(s) that best match what you "want to express"

which is followed by the action of
   - "building" the ucd from the words just found and according to
ucd-syntax.

These two actions together are performed by the "UCD-builder" that
you can find, in its "beta-version", at
http://vizier.u-strasbg.fr/UCD/cgi-bin/descr2ucd

>> Let's reverse the roles: you jump on the chair when you see the  description
>> of the src.class.* words.
>> You are perfectly right. What is not said is that I do not use the
>> description
>> field to assign words/ucds: I use a series of words (keywords
>> derived from the description) that are OR-ed,
>> which is exactly equivalent to the loosier description you suggest.
>
> Sorry - still don't get this.....   Are you saying that
> src.class.richness DOESN'T mean
> Abell class  (even though that's what the official list says) or not?

It actually means :
richness class e.g. Abell richness class
(by the way, ther is also a "Abell distance class" !! Try "Abell class"
as input for the builder...)

> If it  DOES mean
> that, then we need to rename the word.  If it DOESN'T mean that, we
> need to change the description. Either way, we need to change 
> something, because leaving it as
> it is will forever prevent someone from using richness for anything
> else with a good conscience.

Yes, we need to change the descriptions of all src.class.*, and this
thanks to the discussion that is going on!!

Andrea


From andrea.preitemartinez at rm.iasf.cnr.it  Fri Jun 24 05:53:46 2005
From: andrea.preitemartinez at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Fri, 24 Jun 2005 14:53:46 +0200
Subject: Draft list of ucd-words
Message-ID: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>

Dear all,

after 26 days of discussion and contributions from many of you, I decided to
sum up things and to modify the list of words according to my personal
feelings.

You can find the proposed list in the txt file appended.
Of course the discussion is not over, but unfortunately we need a rather
"stable" version soon.
The PR-version of the document (the text accompanying the list) will be sent
around after the meeting in Garching.

A list of all (I hope !!) the modifications is shown below
(Descr=changes in the description
 Canc=word erased
 Added= word added) :

< S  |  em.IR.H                      |Descr
< S  |  em.IR.J                      |Descr
< S  |  em.IR.K                      |Descr
< S  |  em.X-ray.hard                |Descr
< S  |  em.X-ray.medium              |Descr
< S  |  em.X-ray.soft                |Descr
< S  |  em.gamma.hard                |Descr
< S  |  em.gamma.soft                |Descr
< S  |  em.opt.B                     |Descr
< S  |  em.opt.I                     |Descr
< S  |  em.opt.R                     |Descr
< S  |  em.opt.U                     |Descr
< S  |  em.opt.V                     |Descr
<    |  instr.angRes                 |Canc
< Q  |  instr.bandpass               |Descr
< Q  |  instr.dispersion             |Added
< Q  |  instr.order                  |Added
<    |  instr.spect                  |Canc
<    |  instr.spect.dispersion       |Canc
<    |  instr.spect.order            |Canc
<    |  instr.spect.resolution       |Canc
<    |  instr.tel.focus              |Canc
< Q  |  instr.tel.focalLength        |Added
< P  |  meta.curation                |Added
< P  |  meta.version                 |Added
< Q  |  obs.airMass                  |Added
< S  |  obs.atmos                    |Added
< Q  |  obs.atmos.extinction         |Added
< Q  |  obs.atmos.refractAngle       |Added
< S  |  obs.calib                    |Added
< Q  |  phys.density                 |Descr
< Q  |  phys.energy                  |Descr
< Q  |  phys.energyDensity           |Added
< Q  |  phys.refractIndex            |Added
< Q  |  phys.transmission            |Added
< V  |  phys.veloc                   |Added
< Q  |  phys.veloc.ang               |Added
< Q  |  phys.veloc.cmb               |Added
< Q  |  phys.veloc.dispersion        |Added
< Q  |  phys.veloc.escape            |Added
< Q  |  phys.veloc.expansion         |Added
< Q  |  phys.veloc.lg                |Added
< Q  |  phys.veloc.lsr               |Added
< Q  |  phys.veloc.microTurb         |Added
< Q  |  phys.veloc.orbital           |Added
< Q  |  phys.veloc.pulsat            |Added
< Q  |  phys.veloc.rotat             |Added
< Q  |  phys.veloc.transverse        |Added
< Q  |  pos.angDistance              |Descr
< Q  |  pos.az.azi                   |Added
< S  |  pos.bodyrc                   |Added
<    |  pos.earth.nutation           |Canc
< S  |  pos.earthop                  |Added
< Q  |  pos.earthop.nutation         |Added
< Q  |  pos.eq.ha                    |Added
< Q  |  pos.phaseAng                 |Added
< V  |  pos.precess                  |Descr
< Q  |  pos.resolution               |Added
< Q  |  spect.resolution             |Added
<    |  spect.veloc                  |Canc
< E  |  spect.dopplerVeloc           |Added
< E  |  spect.dopplerVeloc.radio     |Added
< E  |  spect.dopplerVeloc.optic     |Added
< S  |  src                          |Descr
< Q  |  src.class.distance           |Descr
< Q  |  src.class.richness           |Descr
< Q  |  src.class.starGalaxy         |Descr
< Q  |  src.class.struct             |Descr
<    |  src.orbital.veloc            |Canc
<    |  src.veloc                    |Canc
<    |  src.veloc.ang                |Canc
<    |  src.veloc.cmb                |Canc
<    |  src.veloc.dispersion         |Canc
<    |  src.veloc.escape             |Canc
<    |  src.veloc.expansion          |Canc
<    |  src.veloc.lg                 |Canc
<    |  src.veloc.lsr                |Canc
<    |  src.veloc.microTurb          |Canc
<    |  src.veloc.pulsat             |Canc
<    |  src.veloc.rotat              |Canc
< Q  |  time.obs                     |Added
< Q  |  time.obs.end                 |Added
< Q  |  time.obs.start               |Added


Regards

Andrea
==============================================================================
Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
00133 Roma
==============================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master_sent
Type: application/octet-stream
Size: 50611 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050624/9f7116e9/attachment-0001.obj>

From pdidelon at cea.fr  Tue Jun 28 06:16:26 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Tue, 28 Jun 2005 15:16:26 +0200
Subject: Draft list of ucd-words
In-Reply-To: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
Message-ID: <42C14DAA.2020400@cea.fr>

Hi everybody,
some comments...

A) global comments

A.0 instr.obsty
- S | instr.obsty                  |  Observatory satellite mission
you mean Observatory or satellite mission -> Observatory / satellite mission  ?
- Q | instr.obsty.site.seeing      |  Seeing 

Is this the global seeing resulting of detector, instrument, atmosphere...
or does it concern only the instrumental part? If so, did we need a obs.seeing? 

Not clear for me.

A.1 phys.veloc.trans
- Q | phys.veloc.transverse        |  Transverse / tangential velocity
I am not sure that these two definitions are (allways?) compatible.
Moreover, transverse is perhaps not the right word. It isn't tangential, as opposed to radial?
Or do we need two definitions? But velocity transverse to the mouvment seems strange/unappropriate?

A.2 radial velocities
they are now spread in 3 separate group
- phys.veloc.[lg|lsr]
- spect.dopplerVeloc.*
- src.redshift.*
Is spect.dopplerVeloc.* equivalent to radial velocity?
Some "reduced" RV, to the earth center, to the sun are not defined/available,
( see gc, geoc and hc in src.veloc.radial at http://www.imcce.fr/fr/expert/ssvo/wgovp/ucdtree.html )
and the frame corresponding to spect.dopplerVeloc is not defined.
So, phys.veloc.hc for heliocentric value is not available, while
the corresponding position pos.heliocentric is.
I suggest to complete RV and clearly identify them using phys.veloc.radial.[gc|geoc|hc|lg|lsr]
and to change description of spect.dopplerVeloc.* to clearly define the information
about the "place of measurement" : ObsLocation (in case of spacecraft it can be tricky)
or referential frame.

A.3 pos.* the big case/issue already clarified but still some inhomogeneity
or confusion (at least in my head).

A.3.1 pos.earth
  Q | pos.earth.lon                |  Longitude on Earth
exists but not latitude!
Q | pos.earth.altitude           |  Altitude on Earth
exists but not distance which give the distance to the center

A.3.2 lon/lat/alt/dist
For any coordinate system (pos.*centric and mainly pos.bodyrc)
the four informations can be usefull, and if  pos.distance 
                      is available the others don't exist, and can be used to construct composed words.
I suggest introduction of pos.[alt|lat|lon] (at least the two last ones)
to be able to used composed words like pos.lat;pos.bodyrc
or to introduce  [dist|lat|lon] for all coordinate system and alt for some of them.

A.3.3 Some subdivision are not sufficients.
pos.bodyrc as mentionned above ;-)
but also : pos.precess, pos.earthop.nutation and pos.earthop too
see corresponding needs at http://www.imcce.fr/fr/expert/ssvo/wgovp/ucdtree.html

B additional comments mainly related to (small?) solar system objects
( or extra solar system sytem and not only planetary one ;-) )

B.1 Mean motion

 >>>>> Andrea Preite Martinez wrote:
 >>>>>
 >>>>>> 12. src.orbital.meanMotion
 >>>>>> I suppose it is an average angular velocity (src.veloc.ang;stat.mean).
 >>>>>> No strong feelings about it.
 >>>>>
No, the mean motion is not an average angular velocity. It is given
by the third Kepler's law: n2 * a3 = cste with n the mean motion
and a the semi-major axis of the orbit. So it is a corner stone of
the computation of orbits: we need it as a proper UCD.

B.2 asteroid Absolute Magnitude

H is the absolute magnitude which already exist in the UCD (phys.magAbs)
for asteroids we need also the slope parameter usually called G : phys.magAbs.G
but seen as a kind of "calibration" parameter may be a better place somewhere
else in the UCD tree is perhaps possible?

B.3 pos.precess

I guess pos.precess could be more generic because it could be used both for
the equatorial and ecliptic precessions. Perhaps we should change .ra and .dec
to .lon and .lat and, in the same way, .dzeta, .z and ,theta should be change
because they usually refer to the equatorial precession when the ecliptic
precession parameters are expressed  with other letters.

B.4 pos.eop.*

Jonathan McDowell wrote:
 > * pos.eop.*  I like, although as we become more active on other worlds isn't it likely
 >     that we'll be needing similar parameters for Mars, etc.? But maybe it's fine for now.

  yes, SolarSystem people mind about this. But the Earth is a special case which is used often
in ephemeris computation. I guess that first this UCD should be created and
then  a more generic one should be added ?



That's all for the moment.
sincerely yours,
Pierre



Andrea Preite Martinez wrote:

> Dear all,
> 
> after 26 days of discussion and contributions from many of you, I decided to
> sum up things and to modify the list of words according to my personal
> feelings.
> 
> You can find the proposed list in the txt file appended.
> Of course the discussion is not over, but unfortunately we need a rather
> "stable" version soon.
> The PR-version of the document (the text accompanying the list) will be sent
> around after the meeting in Garching.
...
> 
> Regards
> 
> Andrea
> ==============================================================================
> Andrea Preite Martinez                  andrea at rm.iasf.cnr.it
> Istituto di Astrofisica Spaziale        Tel.:+39.06.4993.4641
> Area di Ricerca di Tor Vergata          Fax.:+39.06.2066.0188
> Via del Fosso del Cavaliere 100         Cell:+39.339.3817355
> 00133 Roma
> ==============================================================================

------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------



From sla at ucolick.org  Tue Jun 28 15:13:11 2005
From: sla at ucolick.org (Steve Allen)
Date: Tue, 28 Jun 2005 15:13:11 -0700
Subject: Draft list of ucd-words
In-Reply-To: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
Message-ID: <20050628221311.GA12268@ucolick.org>

On Fri 2005-06-24T14:53:46 +0200, Andrea Preite Martinez hath writ:

> < Q  |  obs.atmos.refractAngle       |Added

I am a bit mystified by the utility of this quantity.

In actual practice it is usually impossible to distinguish the amount
of refraction from the amount of unmodelled telescope flexure.
It is a rare situation when it is actually possible to make a
measurement of the refraction angle.  Any error is simply accommodated
by the ever-requisite fine pointing adjustment of the telescope.

Under what circumstances is refractAngle actually used?
What drives any requirements for it to be accurate or precise?

On the other hand, the differential refraction, which is to say both
the change in the amount of refraction over a field of view and the
atmospheric dispersion due to refraction are quantities which are
often calculated and used.

The differential refraction and the atmospheric dispersion are needed
for designing and manufacturing focal plane constructs for multi
object spectrographs.

The dispersion enters directly into the decision about the position
angle at which a slit spectrograph should be oriented.

A map of the differential refraction is necessary for
multi-slit spectrographs and for fiber-fed spectrographs.

In my experience these two are needed far more often, and to greater
precision, than the absolute amount of refraction.

> S | pos.earthop                  |  Earth orientation parameters
> Q | pos.earthop.nutation         |  Earth nutation

These specifications seem incomplete, but I'm not sure what
they are supposed to be communicating.

As a starter for discussion, does nutation refer to
IAU 2000A model,  IAU 2000B model, or the models resulting from
the FK5-based revision performed between 1976/1984, or
the nutation based on the older Newcomb models of precession, or what?

Is polar motion and UT1 relevant?  Do they use the IAU 2000 models, or
one of the older forms used in previous versions of the IERS
conventions, or the even older FK5 forms, or what?

> Q | pos.eq.ha                    |  Hour-angle

> Q | pos.az                       |  Position in alt-azimutal frame
> Q | pos.az.alt                   |  Alt-azimutal altitude
> Q | pos.az.azi                   |  Alt-azimutal azimut
> Q | pos.az.zd                    |  Alt-azimutal zenith distance

If I understand the work of the general relativists who have been
contributing to various IAU initiatives over the past two decades then
all of the above quantities do not have precisely-defined meanings.
There is no mathematical framework for a rigorous mapping of celestial
sphere to observation angles which is valid at the microarcsecond
level.

The meaning of hour angle has been called into question at
a precision much less tight by the IAU 2000 redefinition of UT1
and the introduction of the CIO/CEO- and TIO/TEO- based
expressions.  There is an active IAU committee trying to work
out nomenclature for the "classical" vs. the "CIO-based"
versions of these sorts of quantities.

Should the definitions of these admit that they may
not be meaningful at the milliarcsecond level and give
references to the draft documents which explain why?

On Tue 2005-06-28T15:16:26 +0200, Pierre Didelon hath writ:

> A.3.1 pos.earth
>  Q | pos.earth.lon                |  Longitude on Earth
> exists but not latitude!
> Q | pos.earth.altitude           |  Altitude on Earth
> exists but not distance which give the distance to the center
>
> A.3.2 lon/lat/alt/dist

In the context of FITS WCS Paper III we decided that it was not a good idea
to admit the concepts of latitude, longitude, and height into the
standard.

(Note, by the way that I strongly prefer to use the term "height" rather
than "altitude" or "elevation".  The geodetic community also uses "height"
at least in part to avoid confusion with the other two, which may be angles.)

Unless there is also a UCD word something like pos.earth.geodatum it is not
possible to associate a precise meaning with .lon, .lat, and .alt

As we point out in FITS WCS Paper III, there are something like 1000
different geodetic datums in use, and some of their positions differ
from each other by kilometers.  Rather than burden FITS with the need
to recognize even a small subset of those datums we decided to omit
angular body coordinates and stick to Cartesian coordinates only.

True, even Cartesian coordinates technically require the specification
of a datum, but in current usage all the Cartesian terrestrial datums
differ by only about 0.1 m.

I recognize that there is a very strong tradition for the use of
angular body coordinates, but if precise meaning is required they
are not a good idea.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99858
University of California    Voice: +1 831 459 3046           Lng -122.06014
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m


From seaman at noao.edu  Tue Jun 28 20:25:31 2005
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 28 Jun 2005 20:25:31 -0700
Subject: Draft list of ucd-words
In-Reply-To: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it>
Message-ID: <4B410189-D4C3-4D71-8F7E-3B0ADA7A2CD5@noao.edu>

On Jun 24, 2005, at 5:53 AM, Andrea Preite Martinez wrote:


> Of course the discussion is not over, but unfortunately we need a  
> rather "stable" version soon.
>

I'm concerned about the general nature of the UCDs in the list.  It  
seems to me that the most useful quantities are those such as em.opt. 
[UBVRI] that have the broadest or most empirically determined  
definitions.  Steve points out the shortcomings of several of the  
more precisely definable quantities.  Many of these require some more  
complicated data structure to even attempt to describe the underlying  
physics.  A simple scalar will never suffice.  For instance, Steve  
picks apart several of the WCS related UCDs.

What is the precise benefit to the VO or its users of selecting UCDs  
to convey these quantities rather than STC elements?  Note that I'm  
not seeking to reopen the "UCDs are not XML" discussion - rather, in  
a loose analogy in which XML represents a variety of data types and  
UCDs represent names, what is the point of providing names for scalar  
quantities that are of no utility standing by themselves?  I suppose  
you could attach a UCD to a more complicated XML (or other kind of)  
data structure - but how would that work exactly?  Wouldn't this  
possibility need to be reflected within the UCD mechanism itself?

The other thing about "em.opt.B" is that it represents a quantity  
whose definition is completely within the control of the  
international astronomical community.  Other than additionally  
specifying exactly what it is whose measured Johnson B magnitude is  
being quoted (some object through some aperture), there is no  
intrinsic ambiguity.  Some of the other quantities "belong" to non- 
astronomical constituencies at least as much as they belong to us.

Not trying to make trouble - please point me to a document or  
discussion thread if such carping is old news.

Rob Seaman
NOAO



From pdidelon at cea.fr  Wed Jun 29 01:14:45 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Wed, 29 Jun 2005 10:14:45 +0200
Subject: Draft list of ucd-words
In-Reply-To: <20050628221311.GA12268@ucolick.org>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org>
Message-ID: <42C25875.80501@cea.fr>



Steve Allen wrote:

> On Fri 2005-06-24T14:53:46 +0200, Andrea Preite Martinez hath writ:
...
>>S | pos.earthop                  |  Earth orientation parameters
>>Q | pos.earthop.nutation         |  Earth nutation
> 
> These specifications seem incomplete, but I'm not sure what
> they are supposed to be communicating.

open corresponding items ( pos.eop, pos.eop.nutation, pos.eop.pole )
at http://www.imcce.fr/fr/expert/ssvo/wgovp/ucdtree.html to see more possible elements.
Passing the mouse over the proposed UCD display a few words meaning in the upper part
of the window ;-)

> 
> As a starter for discussion, does nutation refer to
> IAU 2000A model,  IAU 2000B model, or the models resulting from
> the FK5-based revision performed between 1976/1984, or
> the nutation based on the older Newcomb models of precession, or what?
> 
> Is polar motion and UT1 relevant?  Do they use the IAU 2000 models, or
> one of the older forms used in previous versions of the IERS
> conventions, or the even older FK5 forms, or what?
> 
> 
>>Q | pos.eq.ha                    |  Hour-angle
> 
> 
>>Q | pos.az                       |  Position in alt-azimutal frame
>>Q | pos.az.alt                   |  Alt-azimutal altitude
>>Q | pos.az.azi                   |  Alt-azimutal azimut
>>Q | pos.az.zd                    |  Alt-azimutal zenith distance
> 
> 
> If I understand the work of the general relativists who have been
> contributing to various IAU initiatives over the past two decades then
> all of the above quantities do not have precisely-defined meanings.
> There is no mathematical framework for a rigorous mapping of celestial
> sphere to observation angles which is valid at the microarcsecond
> level.
Perhaps, but a lot of measurements with much less accuracy exist.
UCD has not the goal to replace STC or any equivalent,
only give some (not all) informations about used quantity.
> 
> The meaning of hour angle has been called into question at
> a precision much less tight by the IAU 2000 redefinition of UT1
> and the introduction of the CIO/CEO- and TIO/TEO- based
> expressions.  There is an active IAU committee trying to work
> out nomenclature for the "classical" vs. the "CIO-based"
> versions of these sorts of quantities.
> 
> Should the definitions of these admit that they may
> not be meaningful at the milliarcsecond level and give
> references to the draft documents which explain why?
> 
> On Tue 2005-06-28T15:16:26 +0200, Pierre Didelon hath writ:
> 
> 
>>A.3.1 pos.earth
>> Q | pos.earth.lon                |  Longitude on Earth
>>exists but not latitude!
>>Q | pos.earth.altitude           |  Altitude on Earth
>>exists but not distance which give the distance to the center
>>
>>A.3.2 lon/lat/alt/dist
> 
> 
> In the context of FITS WCS Paper III we decided that it was not a good idea
> to admit the concepts of latitude, longitude, and height into the
> standard.
> 
> (Note, by the way that I strongly prefer to use the term "height" rather
> than "altitude" or "elevation".  The geodetic community also uses "height"
> at least in part to avoid confusion with the other two, which may be angles.)
Whatever is the choosen term, it is needed, even in STC, at least to specify
the altitude of the observing place.
> 
> Unless there is also a UCD word something like pos.earth.geodatum it is not
> possible to associate a precise meaning with .lon, .lat, and .alt
> 
> As we point out in FITS WCS Paper III, there are something like 1000
> different geodetic datums in use, and some of their positions differ
> from each other by kilometers.  Rather than burden FITS with the need
> to recognize even a small subset of those datums we decided to omit
> angular body coordinates and stick to Cartesian coordinates only.
> 
> True, even Cartesian coordinates technically require the specification
> of a datum, but in current usage all the Cartesian terrestrial datums
> differ by only about 0.1 m.
> 
> I recognize that there is a very strong tradition for the use of
> angular body coordinates, but if precise meaning is required they
> are not a good idea.
> 
> --
> Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
> UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99858
> University of California    Voice: +1 831 459 3046           Lng -122.06014
> Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m 
								^
                                                                 |
   perhaps not precise enough, but nevertheless usefull quantities ;-)

-- 
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/
------------------------------------------------------------------
Puiss?-je toujours marcher avec la beaut? devant moi.
    Dicton Navajo   Tony Hillerman - Les clowns sacr?s
------------------------------------------------------------------




From roy at cacr.caltech.edu  Wed Jun 29 03:19:00 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Wed, 29 Jun 2005 03:19:00 -0700
Subject: Draft list of ucd-words
In-Reply-To: <42C25875.80501@cea.fr>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr>
Message-ID: <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu>

I see questions on this list about precise definitions of UCD, and I do 
not think it is relevant. We are not building a self-consistent data 
model of astronomy, but rather we are pragmatically taking the list of 
quantities that real astronomers have used in 5000 real tables at 
Vizier.

  If a table is published in ApJ that defines the "altitude" of their 
observatory (pos.earth.altitude), it is not for us to say the writer 
was a fool, it is for us to make sure there is a UCD for that concept.

Similarly, the STC is irrelevant here. If astronomical tables contain 
RA and Dec, then there should be pos.eq.ra and pos.eq.dec. It is not 
for us to say that RA and Dec do not always have unambiguous 
definitions.


California Institute of Technology
626 395 3670
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 854 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050629/93771521/attachment-0001.bin>

From seaman at noao.edu  Wed Jun 29 08:47:17 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 29 Jun 2005 08:47:17 -0700
Subject: Draft list of ucd-words
In-Reply-To: <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu>
Message-ID: <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>

Hi Roy,

> I see questions on this list about precise definitions of UCD, and  
> I do not think it is relevant. We are not building a self- 
> consistent data model of astronomy, but rather we are pragmatically  
> taking the list of quantities that real astronomers have used in  
> 5000 real tables at Vizier.

That's precisely my point.  If the idea is merely to construct a  
complete (and indeed, consistent) list of the minimal number of  
identifiers necessary to capture some large (and growing) set of  
tables from the astronomical literature - well, then, what is the  
point of discussion at all?  Harvest all the identifiers, correct  
typos, remove synonyms and you're done. Rather, we appear to be  
chartered to do something different - to construct a poor man's  
ontology.  Certainly UCDs are often offered up as the pragmatic path  
out of ontological jungles.

>  If a table is published in ApJ that defines the "altitude" of  
> their observatory (pos.earth.altitude), it is not for us to say the  
> writer was a fool, it is for us to make sure there is a UCD for  
> that concept.

Right - and I agree with Steve that this should rather be called  
"height".  But this begs the question of whether we need to provide  
UCDs for *both* height above the Earth's surface *and* distance from  
its center.  And dozens of other questions for this one little  
identifier such as how (or whether) to express the shape of the earth  
such that "height" from one table means even approximately the same  
thing as "altitude" from another.

> Similarly, the STC is irrelevant here. If astronomical tables  
> contain RA and Dec, then there should be pos.eq.ra and pos.eq.dec.  
> It is not for us to say that RA and Dec do not always have  
> unambiguous definitions.

But naming has the implication of defining.  By attaching the same  
UCD to values from two different tables we are asserting that for  
[all | most | many | some | any] purposes that these values represent  
identical "things".  Certainly VO users will take it this way.  Why  
else provide common class identifiers other than to assert a common  
class?

We are clearly seeking some semantic middle ground between  
instantiating a separate UCD for each column of each table (e.g.,  
Hertzsprung.1947.fig_1.pos.eq.ra) and the evanescent dream of a full  
astronomical ontology.  If that is not the case, I would argue that  
rather than seat a committee to decide these issues that some purely  
mechanical process be sought to convert the column headings from each  
month's new batch of tables from the literature into UCDs.

I think we are precisely building a simple kind of data model of  
astronomy.  It is indeed intended to be self-consistent, but  
certainly not to be complete (either in extent or expressive  
ability).  Ideally we will understand the holes in the data model as  
well as the consensus descriptors.  In general, holes should be left  
where simple UCD expressions don't suffice.  We will fail if we aim  
too close to completeness.  We will also fail if the UCD "data  
model" (or whatever folks want to call it) diverges too far from a  
coherent expression of the domain of astronomy.

The quickest way to wrap up the current exercise is to severely limit  
the list of UCDs to only contain the least controversial.  If columns  
from 5000 tables have left holes in the list of UCDs, one might  
expect that this reflects underlying difficulties of astronomical  
semantics that we will not more easily overcome.

The way to extend a robust UCD process into the future is to provide  
an explicit namespace mechanism from the start.  This will allow  
capturing controversial or peripheral identifiers such as VOConcept,  
but will also allow us to wipe the etch-a-sketch clean with new  
version(s) of subject dependent list(s) of UCDs.  If later we decide  
that v1:pos.earth.height should indeed have been  
v2:pos.earth.altitude, there needs to be a lightweight way to make  
the transition.  This is also the way to ensure a speedy process in  
the future.  The alternative is a heavyweight process such as FITS  
standardization - talk about it for ten years and still leave some  
folks unhappy and eager to violate the standard.

Better an incomplete list of UCDs than an incorrect one.  Better two  
lists than one.

Rob Seaman
NOAO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050629/8c2097a8/attachment-0001.html>

From roy at cacr.caltech.edu  Wed Jun 29 09:27:51 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Wed, 29 Jun 2005 09:27:51 -0700
Subject: Draft list of ucd-words
In-Reply-To: <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
Message-ID: <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu>

> By attaching the same UCD to values from two different tables we are 
> asserting that .....  these values represent identical "things".?

We are asserting that there exists a context in which they are the 
same. Question: In what context is an R-magnitude and a B-magnitude the 
same thing? Answer: when you count photons without regard to their 
wavelength.

> some purely mechanical process be sought to convert the column 
> headings from each month's new batch of tables from the literature 
> into UCDs.

That was the original conception. The only structure was some grouping. 
Then we tried to get clever, and replaced the single UCD "magnitude 
error" by two components ("magnitude" and "error"). That was the 
slippery slope towards a data model. And here we are up to our asses in 
ontological alligators!

> .....  building a simple kind of data model of astronomy.
> ..... evanescent dream of a full astronomical ontology

I don't think these things are possible.  Everyone has their own 
opinion. It would be too complex and unwieldy.

> The way to extend a robust UCD process into the future is to provide 
> an explicit namespace mechanism from the start.?

We tried this before about 2 years ago, but it was vetoed. The problem 
with namespace is that it reduces interoperability -- there was a fear 
that everyone would simply use their own namespace.

Roy


From seaman at noao.edu  Wed Jun 29 09:55:50 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 29 Jun 2005 09:55:50 -0700
Subject: Draft list of ucd-words
In-Reply-To: <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu>
Message-ID: <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu>

Roy says;

> We are asserting that there exists a context in which they are the  
> same. Question: In what context is an R-magnitude and a B-magnitude  
> the same thing? Answer: when you count photons without regard to  
> their wavelength.

Photon counting and the logarithmic ratios of the magnitude scale are  
very different beasts.  If you are going to pursue photon counting  
you are likely to end up with something resembling IRAF's QPOE  
interface.  Similarly with expressing world coordinates - there is an  
irreducible core of complexity.  The way to deal with this is to  
embrace the complexity, not attempt to implement false simplicity.

> The problem with namespace is that it reduces interoperability --  
> there was a fear that everyone would simply use their own namespace.

There are 340+ sessions here at JavaOne - and something like 340  
different - and differently named - java class libraries and other  
"thingies" being discussed.  Many of these overlap each other.  It  
hasn't seemed to hurt the 15,000 attendees any.  Folks may well  
define utilitarian namespaces willy-nilly for purposes internal to  
their own projects.  They will, however, gravitate toward a few  
standard choices for any expressions that need to be shared with the  
larger VO community.

You aren't describing a problem - you describe an opportunity.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050629/845d8d19/attachment-0001.html>

From roy at cacr.caltech.edu  Wed Jun 29 10:19:47 2005
From: roy at cacr.caltech.edu (Roy Williams)
Date: Wed, 29 Jun 2005 10:19:47 -0700
Subject: Draft list of ucd-words
In-Reply-To: <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu> <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu>
Message-ID: <f5a90ee216b455d3dd3c9142cccec07e@cacr.caltech.edu>

>> We are asserting that there exists a context in which they are the 
>> same. Question: In what context is an R-magnitude and a B-magnitude 
>> the same thing? Answer: when you count photons without regard to 
>> their wavelength.
> Photon counting and the logarithmic ratios of the magnitude scale are 
> very different beasts.? If you are going to pursue photon counting you 
> are likely to end up with something resembling IRAF's QPOE interface.? 
> Similarly with expressing world coordinates - there is an irreducible 
> core of complexity.? The way to deal with this is to embrace the 
> complexity, not attempt to implement false simplicity.

OK I am showing my ignorance of what magnitude exactly means. But it 
sounds like you are taking a hard line that the concept of "magnitude" 
is meaningless by itself, and has no place in the UCD list. Surely it 
has some rigorous definition in terms of photons or flux or energy or 
SOMETHING? And therefore a context in which they can be compared.

And what is wrong with world coordinates? We have UCDs for CRVAL and 
CRPIX and CTYPE and all those good WCS keywords.  Are they also so 
poorly defined as to be useless? They are well-defined in the 
Calabretta papers, aren't they?

>> The problem with namespace is that it reduces interoperability -- 
>> there was a fear that everyone would simply use their own namespace.
>
> You aren't describing a problem - you describe an opportunity.

The namespaces for UCD was my suggestion. I was voted down.



From norman at astro.gla.ac.uk  Wed Jun 29 10:32:14 2005
From: norman at astro.gla.ac.uk (Norman Gray)
Date: Wed, 29 Jun 2005 18:32:14 +0100
Subject: Draft list of ucd-words
In-Reply-To: <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu>
Message-ID: <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>


Greetings,

On 2005 Jun 29 , at 16.47, Rob Seaman wrote:

>>  If a table is published in ApJ that defines the "altitude" of  
>> their observatory (pos.earth.altitude), it is not for us to say  
>> the writer was a fool, it is for us to make sure there is a UCD  
>> for that concept.
>
> Right - and I agree with Steve that this should rather be called  
> "height".

The Gene Ontology folk have described a few key ideas that helped  
them create a big and very successful ontology.  Though GO has  
problems -- some quite fundamental -- non-ontologists do actually use  
it to do actual science.  Some of these `rules' are rather obvious,  
such as `involve users', but Rob's message is a hook for a couple of  
the non-obvious ones.

GO uses opaque labels for every concept, so that pos.earth.altitude  
and pos.earth.height would both be ucd12345 or something.  They do  
this (i) to avoid arguments about which noun it should be, (ii) so  
they can version them easily (when are we going to have fight about  
replacing pos.earth.height with pos.earth.height2? whereas no-one has  
a sentimental attachment to ucd12345), (iii) so users aren't tempted  
to use their intuition about what the labels mean, and are forced to  
use the project's tools to discover and resolve labels, and (iiia) to  
make it transparently clear to everyone that the label really doesn't  
matter -- it's just a string which keys to a careful description  
elsewhere.

I'm not suggesting replacing all the UCDs with numbers (don't worry),  
but suggesting that it might be best to avoid `obvious' names, and  
even that it might be a virtue than a vice to have names which are  
mnemonic but still vague enough to force folk to look up careful  
definitions _before_ they use them.

> But this begs the question of whether we need to provide UCDs for  
> *both* height above the Earth's surface *and* distance from its  
> center.

Agreeing with what I take to be Rob's argument, I think this is  
settled by an observation that these distinct concepts do or do not  
appear in multiple published tables, where `multiple' represents some  
vague threshold number less than ten but definitely more than one.

> And dozens of other questions for this one little identifier such  
> as how (or whether) to express the shape of the earth such that  
> "height" from one table means even approximately the same thing as  
> "altitude" from another.

However I think any discussion about the geoid implies an attempt to  
push UCDs well beyond what I believe to be their valuably constrained  
scope.  Thus the description of pos.earth.height should carefully  
_not_ say which datum it is relative to, and draw attention to the  
fact that it is not saying this!

This is because...

>  By attaching the same UCD to values from two different tables we  
> are asserting that for [all | most | many | some | any] purposes  
> that these values represent identical "things".

It seems to me that the purpose in question is `find tables I might  
be interested in', and that the equivalence relation here is not one  
of identity.  My perception is that the UCD word set has been  
successful, and should remain successful, to the extent that it  
abides by two principles: that the word list is small enough and  
mnemonic enough that folk are likely to remember a respectable  
proportion of the words, and that it service those use-cases where  
false positives are good.  That set includes searching for tables,  
and excludes driving processing.

It might be a bit late to edit things now, but I have said before  
that I feel the UCD document would benefit from a bolder statement of  
its scope, and of its non-goals.

> The way to extend a robust UCD process into the future is to  
> provide an explicit namespace mechanism from the start.  This will  
> allow capturing controversial or peripheral identifiers such as  
> VOConcept, but will also allow us to wipe the etch-a-sketch clean  
> with new version(s) of subject dependent list(s) of UCDs.  If later  
> we decide that v1:pos.earth.height should indeed have been  
> v2:pos.earth.altitude, there needs to be a lightweight way to make  
> the transition.

Hear, hear.  One of the other GO maxims -- up there with `involve the  
users' -- was `version the ontology'.  It seems the GO is in more-or- 
less continuous flux, but this simply doesn't matter, because they  
recognised at the outset that they were going to have to do this, and  
so designed their formalism and tools to cope/help with it.

I hope this helps.  All the best,

Norman


-- 
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk



From seaman at noao.edu  Wed Jun 29 10:51:55 2005
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 29 Jun 2005 10:51:55 -0700
Subject: Draft list of ucd-words
In-Reply-To: <f5a90ee216b455d3dd3c9142cccec07e@cacr.caltech.edu>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <0f37cba6a09192ef4c0f597ce6aa4349@cacr.caltech.edu> <F0FBA6AA-FCB6-4E9C-A587-800D0D5E1D8A@noao.edu> <f5a90ee216b455d3dd3c9142cccec07e@cacr.caltech.edu>
Message-ID: <50C96AD6-350E-4D76-AEED-A3C088197FA0@noao.edu>

Roy says:

> OK I am showing my ignorance of what magnitude exactly means. But  
> it sounds like you are taking a hard line that the concept of  
> "magnitude" is meaningless by itself, and has no place in the UCD  
> list. Surely it has some rigorous definition in terms of photons or  
> flux or energy or SOMETHING? And therefore a context in which they  
> can be compared.

No, magnitudes are fine - precisely because they have a fuzzy  
definition.  What I was apparently arguing only poorly was that more  
interesting things like photon counting are harder to represent using  
simple scalar quantities/names or lists (even hierarchical lists) of  
same.

> And what is wrong with world coordinates? We have UCDs for CRVAL  
> and CRPIX and CTYPE and all those good WCS keywords.  Are they also  
> so poorly defined as to be useless? They are well-defined in the  
> Calabretta papers, aren't they?

I'm situated in a rather awkward location in the Moscone Center and  
the wifi keeps cutting out, so I won't try to reply in detail, but  
surely it would be better to provide a single identifier to a  
complete WCS data structure than to label each separate piece of  
same?  But fundamentally I was just attempting so add a "me, too" to  
Steve's much more cogently worded reply.  If he isn't panicking -  
neither am I.

> The namespaces for UCD was my suggestion. I was voted down.

Maybe it's time to have another vote.

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/ucd-sci/attachments/20050629/e99e2897/attachment-0001.html>

From hessman at Astro.physik.Uni-Goettingen.DE  Wed Jun 29 23:13:22 2005
From: hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. Hessman)
Date: Thu, 30 Jun 2005 08:13:22 +0200
Subject: Draft list of ucd-words
In-Reply-To: <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
Message-ID: <8421f512d315809626d3b4cc3bc809a3@astro.physik.uni-goettingen.de>

>> The way to extend a robust UCD process into the future is to provide  
>> an explicit namespace mechanism from the start.  This will allow  
>> capturing controversial or peripheral identifiers such as VOConcept,  
>> but will also allow us to wipe the etch-a-sketch clean with new  
>> version(s) of subject dependent list(s) of UCDs.  If later we decide  
>> that v1:pos.earth.height should indeed have been  
>> v2:pos.earth.altitude, there needs to be a lightweight way to make  
>> the transition.
>
> Hear, hear.  One of the other GO maxims -- up there with `involve the  
> users' -- was `version the ontology'.  It seems the GO is in  
> more-or-less continuous flux, but this simply doesn't matter, because  
> they recognised at the outset that they were going to have to do this,  
> and so designed their formalism and tools to cope/help with it.

(back on-line after a painful move of our entire institute)

I confess that even I can see the advantages of this in principle - and  
I was the most vociferous complainer about opaque UCD's.
However, I'm not crazy about numbering the concepts - yet another layer  
of naming, this time utterly random in
appearance - and I'm not quite sure how versioning is going to function  
in practice.  On the other hand, if GO works, then
what can one say?

Rick

------------------------------------------------------------------------ 
------------------------
                                             NEW ADDRESS!!!
------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman     Hessman at Astro.physik.Uni-Goettingen.DE
Institut f?r Astrophysik          Tel.  +49-551-39-5052
Friedrich-Hund-Platz 1         Fax +49-551-39-5043
37077 Goettingen
http://www.Astro.physik.Uni-Goettingen.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.Uni-Goettingen.de
------------------------------------------------------------------------ 
-------------------------



From pdidelon at cea.fr  Thu Jun 30 01:13:48 2005
From: pdidelon at cea.fr (Pierre Didelon)
Date: Thu, 30 Jun 2005 10:13:48 +0200
Subject: Draft list of ucd-words
In-Reply-To: <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
References: <20050624145346.xxa5qiwl0ri8wgsw@webmail.sic.rm.cnr.it> <20050628221311.GA12268@ucolick.org> <42C25875.80501@cea.fr> <1055be75840525c23e851cc2b61bfe2b@cacr.caltech.edu> <8DAB1A37-2372-40F0-B2D5-46DD5250C0A7@noao.edu> <578357BE-8513-488B-BF49-EB57A6E8415C@astro.gla.ac.uk>
Message-ID: <42C3A9BC.3050009@cea.fr>



Norman Gray wrote:

> 
> Greetings,
> 
> On 2005 Jun 29 , at 16.47, Rob Seaman wrote:
> 
>>>  If a table is published in ApJ that defines the "altitude" of  their 
>>> observatory (pos.earth.altitude), it is not for us to say  the writer 
>>> was a fool, it is for us to make sure there is a UCD  for that concept.
>>
>>
>> Right - and I agree with Steve that this should rather be called  
>> "height".
> 
> 
> The Gene Ontology folk have described a few key ideas that helped  them 
> create a big and very successful ontology.  Though GO has  problems -- 
> some quite fundamental -- non-ontologists do actually use  it to do 
> actual science.  Some of these `rules' are rather obvious,  such as 
> `involve users', but Rob's message is a hook for a couple of  the 
> non-obvious ones.
> 
> GO uses opaque labels for every concept, so that pos.earth.altitude  and 
> pos.earth.height would both be ucd12345 or something.  They do  this (i) 
> to avoid arguments about which noun it should be, (ii) so  they can 
> version them easily (when are we going to have fight about  replacing 
> pos.earth.height with pos.earth.height2? whereas no-one has  a 
> sentimental attachment to ucd12345), (iii) so users aren't tempted  to 
> use their intuition about what the labels mean, and are forced to  use 
> the project's tools to discover and resolve labels, and (iiia) to  make 
> it transparently clear to everyone that the label really doesn't  matter 
> -- it's just a string which keys to a careful description  elsewhere.
> 
> I'm not suggesting replacing all the UCDs with numbers (don't worry),  
> but suggesting that it might be best to avoid `obvious' names, and  even 
> that it might be a virtue than a vice to have names which are  mnemonic 
> but still vague enough to force folk to look up careful  definitions 
> _before_ they use them.
> 

Agree ;-)
"the Word is not the Thing it represents"
(Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics,
1933, Alfred KORZYBSKI)
or "the word dog doesn't bite".
The words didn't really matter if we agree about the descriptions/definitions.

>> The way to extend a robust UCD process into the future is to  provide 
>> an explicit namespace mechanism from the start.  This will  allow 
>> capturing controversial or peripheral identifiers such as  VOConcept, 
>> but will also allow us to wipe the etch-a-sketch clean  with new 
>> version(s) of subject dependent list(s) of UCDs.  If later  we decide 
>> that v1:pos.earth.height should indeed have been  
>> v2:pos.earth.altitude, there needs to be a lightweight way to make  
>> the transition.
> 
> 
> Hear, hear.  One of the other GO maxims -- up there with `involve the  
> users' -- was `version the ontology'.  It seems the GO is in more-or- 
> less continuous flux, but this simply doesn't matter, because they  
> recognised at the outset that they were going to have to do this, and  
> so designed their formalism and tools to cope/help with it.

Descriptions can change, as a lot of things... including our minds :-)
> 
> I hope this helps.  All the best,

I allways appreciate your interventions.
> 
> Norman
> 
> 

-- 
Pierre
------------------------------------------------------------------
DIDELON :@: pdidelon_at_cea.fr        Phone : 33 (0)1 69 08 58 89
CEA SACLAY - Service d'Astrophysique  91191 Gif-Sur-Yvette Cedex
------------------------------------------------------------------
La carte n'est pas le territoire - Alfred KORZYBSKI
------------------------------------------------------------------