[Alberto Micol]

Dear All,

When we change UCDs we have to be careful, because those UCDs are 
probably
already used out there. The same is true for the parsing (or writing) 
software,
but I guess there is much less parsing software to change than there are
catalogues making use of those UCDs. (And the suggested s/w change was 
really minimal)
Nevertheless, mine (the ending semicolon) is a lost battle, I accept 
defeat.

Overall, I think that the number of atoms should be kept small and 
structured,
otherwise it become very difficult for data providers to assign UCDs in 
a
consistent way.
Having said that, I like the new structured atoms introduced by 
Jonathan (transition, state, species), exactly because "structure is 
good".

Instead, I'm a bit skeptical regarding phys.energy.density and 
phot.flux.fluxDens or phot.flux.density.

It is tempting  to use:
     phys.energy;phys.density
and
     phot.flux;phys.density

Would that be so wrong?

A couple of answers:

Sebastien Derriere wrote:

>
>    The debate on the usefulness of the semicolon at the end of the 
> UCD1+
> was concluded by introducing this rule of "no word should be substring
> of another
> at the same level".
>   The main motivation was that users would be reluctant to add a ;
> at the end of every UCD.

It is not affecting the end user, but just only the data provider,
or actually, more often, the software written by a data provider. And 
since
the software is always going to be written out of the UCDs specs
I would have not seen any problem with the ending semicolon.

>  With the suggested rule, UCD curators have
> to be careful when defining new words (what we do now, but only once
> hopefully), but users life is made slightly easier.

Jonathan McDowell wrote:
> but when you pass it to your search/comparison tool, a trailing
> semicolon gets added automatically
>  phot.fluxDens;

Indeed, if the parsing software knew about the ';' then there would 
have been no problem
whatsoever. And VO is about software, not about human readibility.

Alberto