SED Data Model: Questions and Comments

[Pedro Osuna]

Dave,

parsing of strings is the traditional way to handle units, and we
believe there are examples more than enough of cases where units are
named wrongly, despite any effort to homogeneise unit names (which vary,
by the way, sometimes from FITS WCS paper I to A&A recommended units
conventions (a la Vizier, I believe), to CODATA ones, etc.).

Only thing we say is that dimensional input gives added value, as allows
clients to handle units without the need of string name comparisons with
internal tables. This is a very easy procedure and gives a lot of
throughput, thus our request to include it. 

As Peter Draper says in his SPLAT release, 

[...]Differences between data value units can be automatically taken
account of when overlaying spectra as long as the units strings conform
to the system described in FITS WCS paper I.[...]

so you need to parse strings and compare them with tables somewhere. 
[...]Also, automatic identification and conversion between flux per unit
wavelength and flux per unit frequency is provided and does not require
any "dimensional analysis" information to be present[...]

obviously, if you're parsing strings you don't need dimensional analysis
for this. This is what we used to do in our Spectral tool for ISO
project. However, we insist that for superimposition of different
spectra in different units, the dimensional approach gives -even
algorithmically- a lot of benefits.



Cheers,
P.



On Wed, 2005-02-16 at 11:29, David Berry wrote:
> Pedro,
> 
> > about the units handling, I think the units should be handled by the
> > clients, not the Data Model.
> 
> I'm not sure what you mean by "handled" here. The DM should *describe*
> the units, and the client shoudlinclude software for converting between
> units.
> 
> The only information the client needs is
> > the dimensions (equation) of the units together with the scale factor,
> > therefore the units don't have to be stored in any specific format.
> 
> But we already have a standard form for specifying units given in FITS-WCS
> paper one. What information does the dimensional analysis add which is not
> already present in (or can be determined from) the units string? If it
> adds nothing, then including a dimensional analysis in a data set would
> seem not only redundant but also a little dangerous, since having the same
> information in two different places in the DM introduces the possibility
> of inconsistency. I know this wouldn't happen in a perfect world but...
> 
> So what can be done with a dimensional analysis which cannot be done
> with a simple units string? There is publicly available software which
> has unit mapping functions to parse these strings and automatically
> determine the mapping between them (if any). And the dimensional analysis
> is implicitly built into these units strings. For instance, to determine
> if a given units string has the dimensions of flux per unit frequency, you
> just use the unit mapping function to determine a mapping between the
> given units and "W/m^2/Hz" - if a mapping is returned, then the supplied
> units string has the dimensions of flux per unti frequency; if no mapping
> is returned then it has some other dimensions. So you can then step
> through the systems your code supports, looking for one which can be
> determined from the given units.
> 
> 
> > We have proposed to include those in the SSA protocol and they have been
> > included in the SED data model. We have shown in several places how well
> > this works for flux densities. The Quantity Data Model should include
> > the dimensions as well.
> 
> I think this should only be done if the dimensional analysis adds any
> information which is not already present in the units string. Does it?
> 
> > For other things like photometry, other information like the zero point
> > and zero flux is needed, and I think we still lack a proper data model
> 
> What part would dimensional analysis play in such a data model? For
> instance, how would it help in converting between antenna temperature and
> flux density? Or indeed between some specified magnitude system and flux
> density?
> 
> David
-- 
Pedro Osuna Alcalaya

 
Software Engineer
Science Archive Team
European Space Astronomy Centre
(ESAC/ESA)
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 8131314
---------------------------------                                                                                
European Space Astronomy Centre
European Space Agency
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN