[QUANTITY] The quandary

Steve Lowe slowe at cfa.harvard.edu
Wed May 21 08:10:45 PDT 2003

```All,

I've attached a draft of a document Data Models for Spectra:
Abstractions for Quantities and Coordinates (4 pages---there's an
extraneous blank page at the end) that was intended for distribution at
the Cambridge (UK) Interop meeting, but was held up by e-mail problems.

I think I can summarize our view on the Quantity quandary in a couple of
points, which are in agreement with some of the points made by others on
1) The "units" that we all learned about in high school form just one
part of the story. A coordinate system is needed, which may itself be
specified in several parts (reference system, reference frame). And the
property for which a value is being specified needs to be identified so
that you can know what other quantities are equivalent to it (e.g.,
wavelength of light in vacuum corresponds to a definite frequency.) This
leads to a new object, a Representation, which subsumes units,
coordinate system and property identity, essentially by listing them. In
actual applications, the Representation employed could be as simple or
as complex as needed---for example, a plotting program might only need
to know the "units" component of the representation to label the plot,
but a multiband spectral energy distribution program might need to know
that the value is actually a wavelength of light that can be converted
to a frequency.
2) Representations provide two pieces of information: names for things
like units, coordinate systems and properties; and the information
needed to transform between numerical values for the same quantity
expressed in different representations.

Note that even if there are a large number of values (say, a big table
of wavelengths/frequencies/photon energies), the Representation object
doesn't have to be duplicated for each value. There just has to be one
for each distinct Representation list (wavelength/Angstroms,
wavelength/meter, frequency/Hz,...), and each Quantity object has a
pointer to the one it uses. Thus, the storage overhead need be no
greater than storing just units.

Note also in the document that we're not proposing a static
programming-language class hierarchy for all physical properties, but a
small set of classes for which physical properties will be class
instances having a structure defined by some sort of "map" data file.

As for attaching values for resolution/pixel size etc., I think these
also should be considered to be richer objects for which the simplest
cases (the ones usually used) are parameterized by a single number. In
general these are properties or parameters of a more general observation
or measurement model. Similar to the way Quantities are handled, a
general framework can be devised that for which the one-parameter
"standard" cases can be implemented without excessive overhead. We're
working on that.

Steve

--
Steve Lowe
Smithsonian Astrophysical Observatory
Harvard-Smithsonian Center for Astrophysics
slowe at cfa.harvard.edu
1-617-496-1661

-------------- next part --------------
A non-text attachment was scrubbed...
Name: DataModelQuantity.pdf
Type: application/pdf
Size: 108339 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20030521/2a2cccff/attachment-0001.pdf>
```