Dimensionless units

[David Berry]

Martin,
        It would seem reasonable that a unit conversion scheme should be
able to determine the conversion from Jy/sr to Jy/arcmin**2 without needing
UCDs. The conversion is obviously just a simple scaling factor - no need
for any extra physics or UCDs or anything. But since these two units have
the same MLT dimensions, how can the conversion be determined on the basis
of a dimensional analysis alone? Introducing Angle as a dimension along
with Mass, Length and Time could do it.

David



On Fri, 18 Feb 2005, Martin Hill wrote:

> 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
>
>