From derriere at newb6.u-strasbg.fr  Tue Nov 23 07:23:24 2004
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Tue, 23 Nov 2004 16:23:24 +0100
Subject: RFC for UCD is ending
References: <417F94B0.3491FD4D@astro.u-strasbg.fr>
Message-ID: <41A355EC.C9CE978B@astro.u-strasbg.fr>


  Hello,

  The RFC period for the UCD document is ending, and there have
been no comments yet !!
  If you have remarks or want changes, it is time to make them
public.

Sebastien.

Sebastien Derriere wrote:
> 
>   Dear all,
> 
>   The UCD reference document has been uploaded to the PR area of the
> IVOA document repository:
> 
> http://www.ivoa.net/Documents/latest/UCD.html
> 
>   I would like to open the 4-weeks RFC period for this document as
> of today (Oct 27), with a close date on Nov 24, before promotion to
> the Recommendation status.
> 
>   A dedicated page has been created for posting comments:
> http://www.ivoa.net/twiki/bin/view/IVOA/UnifiedContentDescriptorRFC
>   and discussions will be conducted on the UCD mailing list
> (ucd at ivoa.net).
> 
> 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 hanisch at stsci.edu  Tue Nov 23 09:33:12 2004
From: hanisch at stsci.edu (Robert Hanisch)
Date: Tue, 23 Nov 2004 12:33:12 -0500
Subject: RFC for UCD is ending
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr>
Message-ID: <009701c4d182$81aeb280$7deca782@stsci.edu>

Sorry for being so late to this discussion, but the advantage is that this
is a fresh look at the UCD1+ proposal.  Well, that is my rationale, anyway!

Minor issues:  there are a number of grammatical errors and inconsistent
usages (e.g., sometimes UCD is singular and sometimes plural; it would be
clearer, I think, to write "UCDs" when the plural is intended).

Has anyone expert in Backus-Naur Form checked Section 2.2?  There is one
mistake, I think, in that <Alpha> is defined with a capital A but the
subsequent components refer to <alpha>.  UCDs are case-insensitive, but is
BNF?

On p.7, the paragraph beginning "The order in which words are arranged..."
seems like circular reasoning to me.  It says the order matters only if the
order matters.  I think the standard should be clear on this -- does the
order matter or not?  The text elsewhere suggests yes.

I find Section 3.4 confusing...does anyone else?  phot.color is a difference
of two magnitudes, but does NOT have the associated word arith.diff.  A
temperature ratio is not a temperature, so phys.temperature;arith.ratio
seems backwards to me.  I can't use arith.ratio for M/L, so instead I see
that this is defined as phys.mass.light.  The UCD
phys.mass;phys.luminosity;arith.ratio would seem to make more sense.  If
phot.color;em.opt.B;em.opt.V means B-V and phot.color;em.opt.V;em.opt.B
means V-B, then order is clearly important.  The concern this all raises for
me is that the construction rules for new UCDs are not very clear, and that
the existing UCD1+s have a certain (large) amount of arbitrariness.

I think the list of UCD1+ words at
http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt HAS to be included in this
document, or else we do not have a complete specification.  I understand
that the vocabulary is to be extensible.  An acceptable alternative would be
to put forward the full list of UCD1+s in a second document, but I think it
is important that this document is under IVOA auspices and that revisions
ultimately go through the same review process.  This is somewhat at odds
with Section 9, I realize.  I suspect Section 9 is written the way it is to
assure flexibility and timeliness in adding new UCDs.  Hopefully our process
is flexible and timely enough now, but if not, one could certainly entertain
"provisional" UCDs, which are deemed reasonable by the UCD Steering
Committee but remain subject to broader review.

It is great that our colleagues at CDS have set up the interface for
requesting new UCDs and is keeping the UCD lists up to date, but I think it
is really best if these services/lists migrate to the IVOA site.

In the UCD word list, why does "Q" indicate both primary and secondary
usage?

I think Section 6 should be moved to an Appendix -- it is usage advice, not
something central to the UCD1+ definition.

Cheers,
Bob

----- Original Message ----- 
From: "Sebastien Derriere" <derriere at newb6.u-strasbg.fr>
To: <interop at ivoa.net>
Cc: <ucd at ivoa.net>
Sent: Tuesday, November 23, 2004 10:23 AM
Subject: RFC for UCD is ending


>
>   Hello,
>
>   The RFC period for the UCD document is ending, and there have
> been no comments yet !!
>   If you have remarks or want changes, it is time to make them
> public.
>
> Sebastien.
>
> Sebastien Derriere wrote:
> >
> >   Dear all,
> >
> >   The UCD reference document has been uploaded to the PR area of the
> > IVOA document repository:
> >
> > http://www.ivoa.net/Documents/latest/UCD.html
> >
> >   I would like to open the 4-weeks RFC period for this document as
> > of today (Oct 27), with a close date on Nov 24, before promotion to
> > the Recommendation status.
> >
> >   A dedicated page has been created for posting comments:
> > http://www.ivoa.net/twiki/bin/view/IVOA/UnifiedContentDescriptorRFC
> >   and discussions will be conducted on the UCD mailing list
> > (ucd at ivoa.net).
> >
> > 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 Alberto.Micol at eso.org  Wed Nov 24 02:58:55 2004
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 24 Nov 2004 11:58:55 +0100
Subject: RFC for UCD is ending
In-Reply-To: <009701c4d182$81aeb280$7deca782@stsci.edu>
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu>
Message-ID: <41A4696F.2070601@eso.org>


Dear Sebastein,

Two things:  (a) Backus Naur form and (b) versioning/conformity.

a) Backus Naur

I'd like to re-instantiate what I already proposed in Boston
(sorry Sebastien to come back with this one):

All UCDs should terminate with a semicolon.

I'd like to see this implemented for one main reason: simplicity
which can be explicit with the following two arguments:

1) a UCD should never be a substring of another UCD
(how else to formulate this concept in a Backus Naur form?)

2) having a terminator helps when parsing or when building an SQL queries
looking for a given UCD; without a terminator a more complex SQL is 
necessary
or otherwise parsing of the result set is required.

b) versioning/conformity

Robert Hansich wrote:

>I think the list of UCD1+ words at
>http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt HAS to be included in this
>document, or else we do not have a complete specification. 
>
I totally agree.
Of course the UCD vocabulary must have its own versioning.
In other words, the UCD vocabulary should specify its own version
AND should specify which specs it conforms to (UCD1, UCD1+, UCD3, etc).

I think the machanism for versioning and conformity SHALL be described 
in the document.

Alberto



From Alberto.Micol at eso.org  Wed Nov 24 03:00:57 2004
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 24 Nov 2004 12:00:57 +0100
Subject: Confusing?
In-Reply-To: <009701c4d182$81aeb280$7deca782@stsci.edu>
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu>
Message-ID: <41A469E9.9060906@eso.org>


Robert Hanisch wrote:

>On p.7, the paragraph beginning "The order in which words are arranged..."
>seems like circular reasoning to me.  It says the order matters only if the
>order matters.  I think the standard should be clear on this -- does the
>order matter or not?  The text elsewhere suggests yes.
>
>I find Section 3.4 confusing...does anyone else?  phot.color is a difference
>of two magnitudes, but does NOT have the associated word arith.diff.  A
>temperature ratio is not a temperature, so phys.temperature;arith.ratio
>seems backwards to me.  I can't use arith.ratio for M/L, so instead I see
>that this is defined as phys.mass.light.  The UCD
>phys.mass;phys.luminosity;arith.ratio would seem to make more sense.  If
>phot.color;em.opt.B;em.opt.V means B-V and phot.color;em.opt.V;em.opt.B
>means V-B, then order is clearly important.  The concern this all raises for
>me is that the construction rules for new UCDs are not very clear, and that
>the existing UCD1+s have a certain (large) amount of arbitrariness.
>  
>

I found myself exactly in the same position as Bob. It IS confusing.
Nevertheless...

The fundamental requirement of the UCDs is (quote):

 the primary word carries most of the meaning as to "what the quantity is".

Hence, Bob's suggestion for
   *phys.mass;phys.luminosity;arith.ratio*
would make the UCDinterpreter think that the described quantity is a mass.
It is not.

The fact is that, despite being a ratio, it is a quantity that carries some
physical meaning (for a galaxy it could give indications on the type of 
stars and
the amount of dark matter), hence the existence of a ucd.

 The same is true for example for other quantities, for which nobody objects
the availability of a proper UCD. One for all: velocity, it is a ratio 
between a distance
and a time ...

(After all, the dimensional analysis of a quantity will always reveal a 
ratio between
mass length and time, some times even for adimensional quantities)


Other more complex examples of the same problem are those UCDs
which simply describe a different mathematical expression of the same 
thing,
eg phot.mag and phot.flux.

phot.mag it is the 2.5 log10 of a flux ratio
One could say that the correct ucd is:  *phot.flux;em.opt.V;arith.mag*
expliciting the algorithm applied to the flux using a special arith.mag

The question is: Why to complicate things?

In fact, not to complicate things, * phot.color;em.opt.V;em.opt.B* complies
to that fundamental requirement (it is a color) and expresses an 
implicit arith.diff.


So, it is confusing, but it is difficult to keep it simple.
What is the way out?
Can the UCDs be built in a more more mathematical way, so to avoid confusion
or would that complicate too much the problem?

For the time being I'm afraid we have to live with such fuzzy definition.
Let's hopw that UCD3 will address all this.

Alberto



From roy at caltech.edu  Wed Nov 24 07:57:59 2004
From: roy at caltech.edu (Roy Williams)
Date: Wed, 24 Nov 2004 07:57:59 -0800
Subject: Confusing?
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu> <41A469E9.9060906@eso.org>
Message-ID: <007001c4d23e$8ae58740$6801a8c0@Ropy>

>>On p.7, the paragraph beginning "The order in which words are arranged..."
>>seems like circular reasoning to me.  It says the order matters only if the
>>order matters.  I think the standard should be clear on this -- does the
>>order matter or not?  The text elsewhere suggests yes.

My understanding is that the first word matters because it is the primary type. Each 
subsequent word modifies what goes before. Think of a ucd "A; B; C; D" as "((((A) B) C) 
D)". For example:

stat.mean; phys.temperature; arith.diff; stat.max
The maximum of the difference of two mean temperatures

stat.mean; phys.temperature; stat.max; arith.diff
The difference of the two maximum temperatures

>>I find Section 3.4 confusing...does anyone else?  phot.color is a difference
>>of two magnitudes, but does NOT have the associated word arith.diff.

In this case there is a special semantic concept for the difference of magnitudes, which 
is called color. It would be equally correct to say "arith.diff; phot.magnitude", but it 
is more efficient to use one word than two.

>> A temperature ratio is not a temperature, so phys.temperature;arith.ratio seems 
>> backwards to me.

I agree. This should be "arith.ratio: phys.temperature"

>> If phot.color;em.opt.B;em.opt.V means B-V and phot.color;em.opt.V;em.opt.B
>>means V-B, then order is clearly important.  The concern this all raises for
>>me is that the construction rules for new UCDs are not very clear, and that
>>the existing UCD1+s have a certain (large) amount of arbitrariness.

Yes that is true. But not because of the UCD construction, rather because of the word 
"color". Perhaps I can ask those mor knowledgeable than myself how exactly color is 
defined? If I say "BV color" or "VB color", do they have opposite sign? Or do I rather 
subtract the highest wavelength magnitude from the lowest wavelength?

Roy 


From Alberto.Micol at eso.org  Wed Nov 24 09:51:54 2004
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 24 Nov 2004 18:51:54 +0100
Subject: Confusing?
In-Reply-To: <007001c4d23e$8ae58740$6801a8c0@Ropy>
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu> <41A469E9.9060906@eso.org> <007001c4d23e$8ae58740$6801a8c0@Ropy>
Message-ID: <41A4CA3A.1050001@eso.org>

Roy Williams wrote:

>>> On p.7, the paragraph beginning "The order in which words are 
>>> arranged..."
>>> seems like circular reasoning to me.  It says the order matters only 
>>> if the
>>> order matters.  I think the standard should be clear on this -- does 
>>> the
>>> order matter or not?  The text elsewhere suggests yes.
>>
>
> My understanding is that the first word matters because it is the 
> primary type. Each subsequent word modifies what goes before. Think of 
> a ucd "A; B; C; D" as "((((A) B) C) D)". For example:
>
> stat.mean; phys.temperature; arith.diff; stat.max
> The maximum of the difference of two mean temperatures


 stat.mean is not allowed as primary word...

You probably mean phys.temperature;stat.mean;arith.diff;stat.max

> I agree. This should be "arith.ratio: phys.temperature" 


Nope, again arith.ratio is not allowed as primary word.


Double confusing, isn't it?
We need a coffee, or rather, at this time for us in Europe, a beer...

Alberto







From andrea at rm.iasf.cnr.it  Wed Nov 24 10:15:52 2004
From: andrea at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed, 24 Nov 2004 19:15:52 +0100 (NFT)
Subject: Confusing?
In-Reply-To: <007001c4d23e$8ae58740$6801a8c0@Ropy>
Message-ID: <Pine.A41.4.32.0411241913260.28158-100000@saturn.rm.iasf.cnr.it>

Dear Roy,

On Wed, 24 Nov 2004, Roy Williams wrote:

> >>I find Section 3.4 confusing...does anyone else?  phot.color is a
difference
> >>of two magnitudes, but does NOT have the associated word arith.diff.
>
> In this case there is a special semantic concept for the difference of
magnit$
> is called color. It would be equally correct to say "arith.diff;
phot.magnitu$
> is more efficient to use one word than two.

Yes, this is exactly the reason for using phot.color

> >> A temperature ratio is not a temperature, so
phys.temperature;arith.ratio $
> >> backwards to me.
>
> I agree. This should be "arith.ratio: phys.temperature"

arith.ratio also means "normalized", and a normalized temperature to me
is closer to the concept of "temperature" than to an anodin "ratio".
By the way, also "temperature in units of .... " is expressed by the two
words "arith.ratio" and "phys.temperature".
In this respect I dare say that absolute, non-relative values do not exist
in our context
(please, don't open a debate on this particular case!!)

>> >> If phot.color;em.opt.B;em.opt.V means B-V and
phot.color;em.opt.V;em.opt.B
> >>means V-B, then order is clearly important.  The concern this all
raises for
> >>me is that the construction rules for new UCDs are not very clear, and
that
> >>the existing UCD1+s have a certain (large) amount of arbitrariness.
>
> Yes that is true. But not because of the UCD construction, rather
because of
> "color". Perhaps I can ask those mor knowledgeable than myself how
exactly color is
> defined? If I say "BV color" or "VB color", do they have opposite sign?
Or do$
> subtract the highest wavelength magnitude from the lowest wavelength?
>
B-V color means (Bmag - Vmag), so B-V = -(V-B)
so there is no arbitrariness in the order of em-bands when colors are
concerned.
Any way, we are testing an "ucd1+ builder" that will help
in building correct ucds from a list of words.
Example:
>From a description like: "Optical V magnitude" you can get from an
assignation tool the words: em.opt,  em.opt.V,  phot.mag .
The buider will propose: phot.mag;em.opt.V
>From a description like: "Optical to infrared color" the builder will
propose: phot.color;em.opt;em.IR

To Bob:
The reason for "Q" quantities is twofold:
1. Q is between P and S in the alphabet, as in ucd1+s
2. Q stands for "quantity", while P/S-words are usually not quantities

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: 339.3817355
00133 Roma                              CDS: +33.3.90242448
==============================================================================



From pfo at star.le.ac.uk  Thu Nov 25 08:51:26 2004
From: pfo at star.le.ac.uk (Patricio F. Ortiz)
Date: Thu, 25 Nov 2004 16:51:26 +0000 (GMT)
Subject: Comments on UCD draft
Message-ID: <Pine.LNX.4.44L0.0411251649080.10798-101000@morpheus.star.le.ac.uk>

Dear Sebastien,

here are my comments to the UCD document. I must say that I fully agree
with Bob Hanish's comments. Alberto's and Andrea's points are also quite
valid. The evolution of UCDs seems to me is going in the right direction,
so my comments are more in the line of nitpicking in hope of improving the
system (just as in the old days when we started with the UCDs and used them
to do some quality control :-)

I will concentrate my comments on the study of the two documents you
provided: "ucd1-ucd1p.txt", "ucd1p-composed.txt", which are the closest to
real data we have. I've always had in mind using UCDs to tell us what
quantities of different origins could be compared when taken out of context
in a relatively safe fashion. The original work on UCDs payed special
attention to group quantities with equivalent units (not always a success
or a trivial thing to do though).

First, the obvious:

phys.extension;stat.error 	seems to be mistaken, not sure about
meta.code;stat.error

on the same line, we're missing most of the error columns with their
corresponding ucds.

stat.stdev 	seems at first to be at the same level as stat.max,
stat.min, stat.mean. The latter are always used as a qualifyer (a  word
after a semicolon), yet stat.stdev is used the other way, having said that,
stat.stdev and stat.error are not too different though.

stat.min, stat.max:

	are used in many observables, which is fine, but also in other
	quantities in which the meaning of minimum and maximum is not
	given by the sampled elements but by observational limits,
	eg, maximum and minimum of an observational window (bandpass)
	or limiting magnitude/flux

src.fwhm and extensions
	Sooner or later we'll need to recognize quantities which relate
	to source extensions (or instrument coverage) in order to compute
	overlaps (eg, if a galaxy is located within the FOV of a plate).

	We require to know the geometry (or infer it) [rectangular,
	elliptic, polygonal). The quantities introduced in UCD1 for this
	purpose are lost in UCD1+. I believe this to be an
	oversimplification which we may regret later on.

velocities

	src.veloc.compon UCD is a real mixture between any possible
	velocity component: cartesian, expressed in km/s (or equivalent)
	and polar (radial and tangential) Perhaps we shold think of adding
	some qualifiers for coordinates system, eg:
		coord.cart.X
		coord.cart.Y
		coord.cart.Z
		coord.polar.rad
		coord.polar.tang etc!

	The following could apply:
	VELOC_GAL_U -> src.veloc.compon ==> src.veloc.gc;coord.cart.X
	VELOC_TANG_GAL -> src.veloc.compon ==> src.veloc.gc;coord.polar.tang

	VELOC_RELAT -> src.veloc.component looks more like
		src.veloc;arith.diff (but in some cases it is :-)


Gradients:

	I'd argue that gradients are physical properties rather than
	arithmetical, then phys.grad rather than arith.grad.

Surface brightness.

	I'd argue that we should have phot.sb rather than phot.mag.sb

UCDs and units:

	I think we're mixing things here:

	pos.eq.dec.arcsec
	pos.eq.ra.minutes
	pos.eq.ra.seconds

	If they represent dec and ra in different units, it's not up to the
	UCDs to resolve them. At best it looks confusing

Wavelengths:

	em.wl
	em.wl.central
	em.wl.effective

	seems to me that "central" and "effective" are qualifiers, as the
	nature of the main quantity does not change. I think it would look
	better as

	em.wl;qual.central
	em.wl;qual.effective

	a similar situation happens with the effective temperature


Photometry

	although I agree that having broad categories help locating a
	number of quantities, the lack of granularity means that we're
	no longer able to search for specific things.

	Say that I really want to locate magnitudes measured with
	PHOT_HST_F622W. In UCD1, only these quantities would be recovered.
	in UCD1+, I would have to ask for phot.mag;em.opt.R, and get 20
	other quantities (involving an undetermined number of tables).
	Fishing for data in registries will be so fuzzy that will in
	practice render the system ineffective. In a google era, users
	would expect a low overhead rate; we are diverting from that trend.

	Despite going against the stream, I propose that we keep the
	granularity in photometric systems, define the proper qualifiers,
	and even allow individual frequencies/wavelenghts (as I've heard
	Pedro proposing). What we can do is to produce a way of linking a
	group of UCDs to a single one in order to simplify broad searches.

	So, if I look for phot.mag;em.opt.R, it should actually match to
		phot.mag;band.jhn.r
		phot.mag;band.gunn.r
		phot.mag;band.hst.f622w
		etc.


OK, I'll stop here. Attached you'll find a summary of the matches from
UCD1 <--> UCD1+ which I found quite useful and have used to present this
analysis.

I'm fully aware of how difficult it is to work with the raw data, and UCDs
are an excellent way to use the registries to their full extent, hence my
pickiness on some issues.

The next thing we should be thinking is how to estimulate people to accept
queries using only UCDs rather than column names, that propmts my concern
about loosing granularity.

Cheers,

Patricio


---
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd1-1+summary.gz
Type: application/x-gzip
Size: 21197 bytes
Desc: 
URL: <http://ivoa.cacr.caltech.edu/mailman/private/ucd/attachments/20041125/ed154269/attachment.gz>

From derriere at newb6.u-strasbg.fr  Tue Nov 23 07:23:24 2004
From: derriere at newb6.u-strasbg.fr (Sebastien Derriere)
Date: Tue, 23 Nov 2004 16:23:24 +0100
Subject: RFC for UCD is ending
References: <417F94B0.3491FD4D@astro.u-strasbg.fr>
Message-ID: <41A355EC.C9CE978B@astro.u-strasbg.fr>


  Hello,

  The RFC period for the UCD document is ending, and there have
been no comments yet !!
  If you have remarks or want changes, it is time to make them
public.

Sebastien.

Sebastien Derriere wrote:
> 
>   Dear all,
> 
>   The UCD reference document has been uploaded to the PR area of the
> IVOA document repository:
> 
> http://www.ivoa.net/Documents/latest/UCD.html
> 
>   I would like to open the 4-weeks RFC period for this document as
> of today (Oct 27), with a close date on Nov 24, before promotion to
> the Recommendation status.
> 
>   A dedicated page has been created for posting comments:
> http://www.ivoa.net/twiki/bin/view/IVOA/UnifiedContentDescriptorRFC
>   and discussions will be conducted on the UCD mailing list
> (ucd at ivoa.net).
> 
> 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 hanisch at stsci.edu  Tue Nov 23 09:33:12 2004
From: hanisch at stsci.edu (Robert Hanisch)
Date: Tue, 23 Nov 2004 12:33:12 -0500
Subject: RFC for UCD is ending
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr>
Message-ID: <009701c4d182$81aeb280$7deca782@stsci.edu>

Sorry for being so late to this discussion, but the advantage is that this
is a fresh look at the UCD1+ proposal.  Well, that is my rationale, anyway!

Minor issues:  there are a number of grammatical errors and inconsistent
usages (e.g., sometimes UCD is singular and sometimes plural; it would be
clearer, I think, to write "UCDs" when the plural is intended).

Has anyone expert in Backus-Naur Form checked Section 2.2?  There is one
mistake, I think, in that <Alpha> is defined with a capital A but the
subsequent components refer to <alpha>.  UCDs are case-insensitive, but is
BNF?

On p.7, the paragraph beginning "The order in which words are arranged..."
seems like circular reasoning to me.  It says the order matters only if the
order matters.  I think the standard should be clear on this -- does the
order matter or not?  The text elsewhere suggests yes.

I find Section 3.4 confusing...does anyone else?  phot.color is a difference
of two magnitudes, but does NOT have the associated word arith.diff.  A
temperature ratio is not a temperature, so phys.temperature;arith.ratio
seems backwards to me.  I can't use arith.ratio for M/L, so instead I see
that this is defined as phys.mass.light.  The UCD
phys.mass;phys.luminosity;arith.ratio would seem to make more sense.  If
phot.color;em.opt.B;em.opt.V means B-V and phot.color;em.opt.V;em.opt.B
means V-B, then order is clearly important.  The concern this all raises for
me is that the construction rules for new UCDs are not very clear, and that
the existing UCD1+s have a certain (large) amount of arbitrariness.

I think the list of UCD1+ words at
http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt HAS to be included in this
document, or else we do not have a complete specification.  I understand
that the vocabulary is to be extensible.  An acceptable alternative would be
to put forward the full list of UCD1+s in a second document, but I think it
is important that this document is under IVOA auspices and that revisions
ultimately go through the same review process.  This is somewhat at odds
with Section 9, I realize.  I suspect Section 9 is written the way it is to
assure flexibility and timeliness in adding new UCDs.  Hopefully our process
is flexible and timely enough now, but if not, one could certainly entertain
"provisional" UCDs, which are deemed reasonable by the UCD Steering
Committee but remain subject to broader review.

It is great that our colleagues at CDS have set up the interface for
requesting new UCDs and is keeping the UCD lists up to date, but I think it
is really best if these services/lists migrate to the IVOA site.

In the UCD word list, why does "Q" indicate both primary and secondary
usage?

I think Section 6 should be moved to an Appendix -- it is usage advice, not
something central to the UCD1+ definition.

Cheers,
Bob

----- Original Message ----- 
From: "Sebastien Derriere" <derriere at newb6.u-strasbg.fr>
To: <interop at ivoa.net>
Cc: <ucd at ivoa.net>
Sent: Tuesday, November 23, 2004 10:23 AM
Subject: RFC for UCD is ending


>
>   Hello,
>
>   The RFC period for the UCD document is ending, and there have
> been no comments yet !!
>   If you have remarks or want changes, it is time to make them
> public.
>
> Sebastien.
>
> Sebastien Derriere wrote:
> >
> >   Dear all,
> >
> >   The UCD reference document has been uploaded to the PR area of the
> > IVOA document repository:
> >
> > http://www.ivoa.net/Documents/latest/UCD.html
> >
> >   I would like to open the 4-weeks RFC period for this document as
> > of today (Oct 27), with a close date on Nov 24, before promotion to
> > the Recommendation status.
> >
> >   A dedicated page has been created for posting comments:
> > http://www.ivoa.net/twiki/bin/view/IVOA/UnifiedContentDescriptorRFC
> >   and discussions will be conducted on the UCD mailing list
> > (ucd at ivoa.net).
> >
> > 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 Alberto.Micol at eso.org  Wed Nov 24 02:58:55 2004
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 24 Nov 2004 11:58:55 +0100
Subject: RFC for UCD is ending
In-Reply-To: <009701c4d182$81aeb280$7deca782@stsci.edu>
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu>
Message-ID: <41A4696F.2070601@eso.org>


Dear Sebastein,

Two things:  (a) Backus Naur form and (b) versioning/conformity.

a) Backus Naur

I'd like to re-instantiate what I already proposed in Boston
(sorry Sebastien to come back with this one):

All UCDs should terminate with a semicolon.

I'd like to see this implemented for one main reason: simplicity
which can be explicit with the following two arguments:

1) a UCD should never be a substring of another UCD
(how else to formulate this concept in a Backus Naur form?)

2) having a terminator helps when parsing or when building an SQL queries
looking for a given UCD; without a terminator a more complex SQL is 
necessary
or otherwise parsing of the result set is required.

b) versioning/conformity

Robert Hansich wrote:

>I think the list of UCD1+ words at
>http://cdsweb.u-strasbg.fr/UCD/ucd1p-words.txt HAS to be included in this
>document, or else we do not have a complete specification. 
>
I totally agree.
Of course the UCD vocabulary must have its own versioning.
In other words, the UCD vocabulary should specify its own version
AND should specify which specs it conforms to (UCD1, UCD1+, UCD3, etc).

I think the machanism for versioning and conformity SHALL be described 
in the document.

Alberto



From Alberto.Micol at eso.org  Wed Nov 24 03:00:57 2004
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 24 Nov 2004 12:00:57 +0100
Subject: Confusing?
In-Reply-To: <009701c4d182$81aeb280$7deca782@stsci.edu>
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu>
Message-ID: <41A469E9.9060906@eso.org>


Robert Hanisch wrote:

>On p.7, the paragraph beginning "The order in which words are arranged..."
>seems like circular reasoning to me.  It says the order matters only if the
>order matters.  I think the standard should be clear on this -- does the
>order matter or not?  The text elsewhere suggests yes.
>
>I find Section 3.4 confusing...does anyone else?  phot.color is a difference
>of two magnitudes, but does NOT have the associated word arith.diff.  A
>temperature ratio is not a temperature, so phys.temperature;arith.ratio
>seems backwards to me.  I can't use arith.ratio for M/L, so instead I see
>that this is defined as phys.mass.light.  The UCD
>phys.mass;phys.luminosity;arith.ratio would seem to make more sense.  If
>phot.color;em.opt.B;em.opt.V means B-V and phot.color;em.opt.V;em.opt.B
>means V-B, then order is clearly important.  The concern this all raises for
>me is that the construction rules for new UCDs are not very clear, and that
>the existing UCD1+s have a certain (large) amount of arbitrariness.
>  
>

I found myself exactly in the same position as Bob. It IS confusing.
Nevertheless...

The fundamental requirement of the UCDs is (quote):

 the primary word carries most of the meaning as to "what the quantity is".

Hence, Bob's suggestion for
   *phys.mass;phys.luminosity;arith.ratio*
would make the UCDinterpreter think that the described quantity is a mass.
It is not.

The fact is that, despite being a ratio, it is a quantity that carries some
physical meaning (for a galaxy it could give indications on the type of 
stars and
the amount of dark matter), hence the existence of a ucd.

 The same is true for example for other quantities, for which nobody objects
the availability of a proper UCD. One for all: velocity, it is a ratio 
between a distance
and a time ...

(After all, the dimensional analysis of a quantity will always reveal a 
ratio between
mass length and time, some times even for adimensional quantities)


Other more complex examples of the same problem are those UCDs
which simply describe a different mathematical expression of the same 
thing,
eg phot.mag and phot.flux.

phot.mag it is the 2.5 log10 of a flux ratio
One could say that the correct ucd is:  *phot.flux;em.opt.V;arith.mag*
expliciting the algorithm applied to the flux using a special arith.mag

The question is: Why to complicate things?

In fact, not to complicate things, * phot.color;em.opt.V;em.opt.B* complies
to that fundamental requirement (it is a color) and expresses an 
implicit arith.diff.


So, it is confusing, but it is difficult to keep it simple.
What is the way out?
Can the UCDs be built in a more more mathematical way, so to avoid confusion
or would that complicate too much the problem?

For the time being I'm afraid we have to live with such fuzzy definition.
Let's hopw that UCD3 will address all this.

Alberto



From roy at caltech.edu  Wed Nov 24 07:57:59 2004
From: roy at caltech.edu (Roy Williams)
Date: Wed, 24 Nov 2004 07:57:59 -0800
Subject: Confusing?
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu> <41A469E9.9060906@eso.org>
Message-ID: <007001c4d23e$8ae58740$6801a8c0@Ropy>

>>On p.7, the paragraph beginning "The order in which words are arranged..."
>>seems like circular reasoning to me.  It says the order matters only if the
>>order matters.  I think the standard should be clear on this -- does the
>>order matter or not?  The text elsewhere suggests yes.

My understanding is that the first word matters because it is the primary type. Each 
subsequent word modifies what goes before. Think of a ucd "A; B; C; D" as "((((A) B) C) 
D)". For example:

stat.mean; phys.temperature; arith.diff; stat.max
The maximum of the difference of two mean temperatures

stat.mean; phys.temperature; stat.max; arith.diff
The difference of the two maximum temperatures

>>I find Section 3.4 confusing...does anyone else?  phot.color is a difference
>>of two magnitudes, but does NOT have the associated word arith.diff.

In this case there is a special semantic concept for the difference of magnitudes, which 
is called color. It would be equally correct to say "arith.diff; phot.magnitude", but it 
is more efficient to use one word than two.

>> A temperature ratio is not a temperature, so phys.temperature;arith.ratio seems 
>> backwards to me.

I agree. This should be "arith.ratio: phys.temperature"

>> If phot.color;em.opt.B;em.opt.V means B-V and phot.color;em.opt.V;em.opt.B
>>means V-B, then order is clearly important.  The concern this all raises for
>>me is that the construction rules for new UCDs are not very clear, and that
>>the existing UCD1+s have a certain (large) amount of arbitrariness.

Yes that is true. But not because of the UCD construction, rather because of the word 
"color". Perhaps I can ask those mor knowledgeable than myself how exactly color is 
defined? If I say "BV color" or "VB color", do they have opposite sign? Or do I rather 
subtract the highest wavelength magnitude from the lowest wavelength?

Roy 


From Alberto.Micol at eso.org  Wed Nov 24 09:51:54 2004
From: Alberto.Micol at eso.org (Alberto Micol)
Date: Wed, 24 Nov 2004 18:51:54 +0100
Subject: Confusing?
In-Reply-To: <007001c4d23e$8ae58740$6801a8c0@Ropy>
References: <417F94B0.3491FD4D@astro.u-strasbg.fr> <41A355EC.C9CE978B@astro.u-strasbg.fr> <009701c4d182$81aeb280$7deca782@stsci.edu> <41A469E9.9060906@eso.org> <007001c4d23e$8ae58740$6801a8c0@Ropy>
Message-ID: <41A4CA3A.1050001@eso.org>

Roy Williams wrote:

>>> On p.7, the paragraph beginning "The order in which words are 
>>> arranged..."
>>> seems like circular reasoning to me.  It says the order matters only 
>>> if the
>>> order matters.  I think the standard should be clear on this -- does 
>>> the
>>> order matter or not?  The text elsewhere suggests yes.
>>
>
> My understanding is that the first word matters because it is the 
> primary type. Each subsequent word modifies what goes before. Think of 
> a ucd "A; B; C; D" as "((((A) B) C) D)". For example:
>
> stat.mean; phys.temperature; arith.diff; stat.max
> The maximum of the difference of two mean temperatures


 stat.mean is not allowed as primary word...

You probably mean phys.temperature;stat.mean;arith.diff;stat.max

> I agree. This should be "arith.ratio: phys.temperature" 


Nope, again arith.ratio is not allowed as primary word.


Double confusing, isn't it?
We need a coffee, or rather, at this time for us in Europe, a beer...

Alberto







From andrea at rm.iasf.cnr.it  Wed Nov 24 10:15:52 2004
From: andrea at rm.iasf.cnr.it (Andrea Preite Martinez)
Date: Wed, 24 Nov 2004 19:15:52 +0100 (NFT)
Subject: Confusing?
In-Reply-To: <007001c4d23e$8ae58740$6801a8c0@Ropy>
Message-ID: <Pine.A41.4.32.0411241913260.28158-100000@saturn.rm.iasf.cnr.it>

Dear Roy,

On Wed, 24 Nov 2004, Roy Williams wrote:

> >>I find Section 3.4 confusing...does anyone else?  phot.color is a
difference
> >>of two magnitudes, but does NOT have the associated word arith.diff.
>
> In this case there is a special semantic concept for the difference of
magnit$
> is called color. It would be equally correct to say "arith.diff;
phot.magnitu$
> is more efficient to use one word than two.

Yes, this is exactly the reason for using phot.color

> >> A temperature ratio is not a temperature, so
phys.temperature;arith.ratio $
> >> backwards to me.
>
> I agree. This should be "arith.ratio: phys.temperature"

arith.ratio also means "normalized", and a normalized temperature to me
is closer to the concept of "temperature" than to an anodin "ratio".
By the way, also "temperature in units of .... " is expressed by the two
words "arith.ratio" and "phys.temperature".
In this respect I dare say that absolute, non-relative values do not exist
in our context
(please, don't open a debate on this particular case!!)

>> >> If phot.color;em.opt.B;em.opt.V means B-V and
phot.color;em.opt.V;em.opt.B
> >>means V-B, then order is clearly important.  The concern this all
raises for
> >>me is that the construction rules for new UCDs are not very clear, and
that
> >>the existing UCD1+s have a certain (large) amount of arbitrariness.
>
> Yes that is true. But not because of the UCD construction, rather
because of
> "color". Perhaps I can ask those mor knowledgeable than myself how
exactly color is
> defined? If I say "BV color" or "VB color", do they have opposite sign?
Or do$
> subtract the highest wavelength magnitude from the lowest wavelength?
>
B-V color means (Bmag - Vmag), so B-V = -(V-B)
so there is no arbitrariness in the order of em-bands when colors are
concerned.
Any way, we are testing an "ucd1+ builder" that will help
in building correct ucds from a list of words.
Example:
>From a description like: "Optical V magnitude" you can get from an
assignation tool the words: em.opt,  em.opt.V,  phot.mag .
The buider will propose: phot.mag;em.opt.V
>From a description like: "Optical to infrared color" the builder will
propose: phot.color;em.opt;em.IR

To Bob:
The reason for "Q" quantities is twofold:
1. Q is between P and S in the alphabet, as in ucd1+s
2. Q stands for "quantity", while P/S-words are usually not quantities

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: 339.3817355
00133 Roma                              CDS: +33.3.90242448
==============================================================================



From pfo at star.le.ac.uk  Thu Nov 25 08:51:26 2004
From: pfo at star.le.ac.uk (Patricio F. Ortiz)
Date: Thu, 25 Nov 2004 16:51:26 +0000 (GMT)
Subject: Comments on UCD draft
Message-ID: <Pine.LNX.4.44L0.0411251649080.10798-101000@morpheus.star.le.ac.uk>

Dear Sebastien,

here are my comments to the UCD document. I must say that I fully agree
with Bob Hanish's comments. Alberto's and Andrea's points are also quite
valid. The evolution of UCDs seems to me is going in the right direction,
so my comments are more in the line of nitpicking in hope of improving the
system (just as in the old days when we started with the UCDs and used them
to do some quality control :-)

I will concentrate my comments on the study of the two documents you
provided: "ucd1-ucd1p.txt", "ucd1p-composed.txt", which are the closest to
real data we have. I've always had in mind using UCDs to tell us what
quantities of different origins could be compared when taken out of context
in a relatively safe fashion. The original work on UCDs payed special
attention to group quantities with equivalent units (not always a success
or a trivial thing to do though).

First, the obvious:

phys.extension;stat.error 	seems to be mistaken, not sure about
meta.code;stat.error

on the same line, we're missing most of the error columns with their
corresponding ucds.

stat.stdev 	seems at first to be at the same level as stat.max,
stat.min, stat.mean. The latter are always used as a qualifyer (a  word
after a semicolon), yet stat.stdev is used the other way, having said that,
stat.stdev and stat.error are not too different though.

stat.min, stat.max:

	are used in many observables, which is fine, but also in other
	quantities in which the meaning of minimum and maximum is not
	given by the sampled elements but by observational limits,
	eg, maximum and minimum of an observational window (bandpass)
	or limiting magnitude/flux

src.fwhm and extensions
	Sooner or later we'll need to recognize quantities which relate
	to source extensions (or instrument coverage) in order to compute
	overlaps (eg, if a galaxy is located within the FOV of a plate).

	We require to know the geometry (or infer it) [rectangular,
	elliptic, polygonal). The quantities introduced in UCD1 for this
	purpose are lost in UCD1+. I believe this to be an
	oversimplification which we may regret later on.

velocities

	src.veloc.compon UCD is a real mixture between any possible
	velocity component: cartesian, expressed in km/s (or equivalent)
	and polar (radial and tangential) Perhaps we shold think of adding
	some qualifiers for coordinates system, eg:
		coord.cart.X
		coord.cart.Y
		coord.cart.Z
		coord.polar.rad
		coord.polar.tang etc!

	The following could apply:
	VELOC_GAL_U -> src.veloc.compon ==> src.veloc.gc;coord.cart.X
	VELOC_TANG_GAL -> src.veloc.compon ==> src.veloc.gc;coord.polar.tang

	VELOC_RELAT -> src.veloc.component looks more like
		src.veloc;arith.diff (but in some cases it is :-)


Gradients:

	I'd argue that gradients are physical properties rather than
	arithmetical, then phys.grad rather than arith.grad.

Surface brightness.

	I'd argue that we should have phot.sb rather than phot.mag.sb

UCDs and units:

	I think we're mixing things here:

	pos.eq.dec.arcsec
	pos.eq.ra.minutes
	pos.eq.ra.seconds

	If they represent dec and ra in different units, it's not up to the
	UCDs to resolve them. At best it looks confusing

Wavelengths:

	em.wl
	em.wl.central
	em.wl.effective

	seems to me that "central" and "effective" are qualifiers, as the
	nature of the main quantity does not change. I think it would look
	better as

	em.wl;qual.central
	em.wl;qual.effective

	a similar situation happens with the effective temperature


Photometry

	although I agree that having broad categories help locating a
	number of quantities, the lack of granularity means that we're
	no longer able to search for specific things.

	Say that I really want to locate magnitudes measured with
	PHOT_HST_F622W. In UCD1, only these quantities would be recovered.
	in UCD1+, I would have to ask for phot.mag;em.opt.R, and get 20
	other quantities (involving an undetermined number of tables).
	Fishing for data in registries will be so fuzzy that will in
	practice render the system ineffective. In a google era, users
	would expect a low overhead rate; we are diverting from that trend.

	Despite going against the stream, I propose that we keep the
	granularity in photometric systems, define the proper qualifiers,
	and even allow individual frequencies/wavelenghts (as I've heard
	Pedro proposing). What we can do is to produce a way of linking a
	group of UCDs to a single one in order to simplify broad searches.

	So, if I look for phot.mag;em.opt.R, it should actually match to
		phot.mag;band.jhn.r
		phot.mag;band.gunn.r
		phot.mag;band.hst.f622w
		etc.


OK, I'll stop here. Attached you'll find a summary of the matches from
UCD1 <--> UCD1+ which I found quite useful and have used to present this
analysis.

I'm fully aware of how difficult it is to work with the raw data, and UCDs
are an excellent way to use the registries to their full extent, hence my
pickiness on some issues.

The next thing we should be thinking is how to estimulate people to accept
queries using only UCDs rather than column names, that propmts my concern
about loosing granularity.

Cheers,

Patricio


---
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucd1-1+summary.gz
Type: application/x-gzip
Size: 21197 bytes
Desc: 
URL: <http://www.ivoa.net/pipermail/ucd/attachments/20041125/ed154269/attachment-0001.gz>