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 Received on 2005-11-08Z09:54:04