Dimensionless units

[Martin Hill]

On Friday 18 February 2005 10:11 am, David Berry wrote:
> Alberto,
>
> > Sorry, but I don't really get the point.
> > Apples are apples, and bananas are bananas,
> > and the UCDs are clearly stating that those two things
> > are not of the same kind:
> >
> > Jy    ->  phot.fluxDens
> > Jy/sr ->  phot.fluxDens.sb
> >
> > Why would you want to use the units to discriminate between the two?
>
> That's ok if a UCD is always available, but if there are cases where you
> want to do unit conversions when no UCDs are available, then you need some
> way to distinguish "Jy/sr" from "Jy". <snip>

Noooo....  etc.  If we don't know what it's a measure of (ie we have no UCD 
or other dictionary/ontology term or 'some other way') then we can only do 
trivial unit conversions which share the same dimensions, ie we don't 
distinguish between Jy/sr and Jy without some kind of metadata about the 
values.  If we have no machine-readable metadata, unit conversions are only 
likely to be for human consumption where a set of values are displayed in 
units familiar to the user; Europeans might display velocity in m/s, 
Americans in mph, and the British in feet per minute. 

Adding 'pretend' dimensions takes us to ontologies and metadata, and trying 
to reinvent UCDs.  Instead we *should* be including metadata and 
dictionary/ontology/UCD terms with our values and units, so that we can 
describe an apple as an apple and a banana as a banana, no matter whether the 
units we count them in are individuals, cartloads, buckets or clumps (a 
banana-only unit that can only be averaged out to individual bananas using 
metadata about source, year of harvest, average banana size, etc).

> Also, if UCD's are available then why do we need a dimensional analysis
> at all since the UCD will imply the dimensions (we would still need the
> scaling factor though)?

Does *every* UCD imply a dimension?  

Also, we often use 'some other way' to describe a value.  For example, a 
parameter in a web service call might be described in some human readable 
form (eg the RA/DEC of NVO cone searches) so that we understand what the 
value is by its purpose.  We then know, and our software can be written to 
interpret, that we have an 'angle' and can accept and convert between 
sexadecimal, decimal and radian values. 

So as Pedro says, our dimension-based unit conversions are independent of the 
metadata and UCD/dictionary/ontology used to describe a value, and are only 
used to convert between values that share the same dimension equation.  

Where we do have metadata and dictionary/ontology terms, then our conversions 
are based upon our knowledge of physics and those terms as well as their 
units.  We may make use of dimension-based unit conversions as a part of 
that, but we shouldn't be looking at dimension-based unit conversions to 
solve the whole conversion problem.  We need to look at metadata- and 
ontology- based converters for that.

For example, most UCDs are a mix of dictionary, incomplete metadata and 
sometimes units, so we can use them to do rough conversions and comparisons.  
PHOT_FLUX_IR implies certain metadata about the flux measurement (it's in the 
IR band), and PHOT_FLUX_IR values can be compared and converted 
(approximately) to PHOT_MAG_IR which also implies similar metadata.  

Cheers

Martin

-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66