Ed Shaya wrote:
> Martin Hill wrote:
>
>> Units and dimensions are not ontologies (thank goodness!) >>
Well... I think we're mixing unit analysis with value analysis. Unit analysis, comparisons and convertions only works when we know what the value(s) are a measure of. And we shouldn't be trying to work out what a value is a measure of from the units.
>> We don't expect the units to fully define what we're measuring, but >> they are an important part of that definition. So, in this case, we >> don't expect um to tell us we have a wavelength, instead we know 'in >> some other way' that we have a wavelength value, and its units are in >> um. >>
Ontologies, dictionaries, UCDs, or simply by definition (For example, the SSAP protocol formats define which 'measures' go into which part of the document without requiring an ontology). This is, as we know, a difficult subject and I don't think it should be mixed up into unit analysis.
>> The equivelence between wavelength and frequency and energy in light, >> say, requires knowing that we are dealing with photons (the >> equivelence is different for waves in beer), so we can make use of the >> units to simplify the ontology; if we know 'in some other way' that we >> have photons, then the units can be length, time-1 or energy. >>
>> Similarly the difference between surface flux and observed flux need >> to be described, but is a problem for ontologies not units or dimensions. >>
Well... a *unit converter* should only deal with units. Converting between different 'measures' (I can't think of a better term just now) requires different algorithms, which will vary depending on the measures and the particular task in hand.
So in those measurements where space is a vacuum enough to assume a constant conversion between wavelength/energy/frequency, then we can have a single term (eg 'photon') describing what the value is a measure of, and different units that we can freely convert between. But these particular unit conversions should be part of a 'photon' library of algorithms (for example), not some massive unit conversion library that needs to know about all the various contexts that the unit conversions exist in.
>
>> Units and dimensions allow us to convert and compare things that we >> know 'in some other way' are the same. These need not be simple >> comparisons; Pedro has demonstrated that you can build an SED from >> dimension analysis, because you already know which values go on the >> 'brightness' axis and which go on the 'wavelength' axis, even if the >> units are all different. >> >>
I must admit I thought we were talking about dimensions L, T, etc with a scaling factor. So our unit conversion library can convert between all the various units (kg, um, etc) and dimensions. That way values in miles per hour can be compared with values in meters per second, or fathoms per fortnight, by using the dimensions as an intermediary.
I understood from the previous posts that we get problems with this approach when we have units that are dimensionless. So this method doesn't work very well converting even between radians and degrees, but we could perhaps add some pseudodimensions ('count', 'ratio').
This doesn't help with some measures that we think of as the same thing (such as magnitudes and fluxes) because they're not actually the same measures. Again, this is a problem for a higher level library which will have to look at the metadata (such as finding the magnitude zero point), not a unit converter.
Similarly I think David's list:
> deg (plus rad, arcmin, arcsec, mas) > sr > mag > count (plus photon, ct, ph) > pixel (plus pix) > Sun > chan > bin > voxel > bit > byte > adu > beam
is mixing the concept of dimensions and units with types and ontology and metadata. We often use terms for units even when they're not really units, because it's convenient. We must avoid trying to make our unit definitions into a UCD-like dictionary.
Martin
-- Martin Hill Software Engineer, AstroGrid (ROE) 07901 55 24 66 (mobile) 0131 668 8326 (ROE)Received on 2005-02-17Z21:03:56