Dimensionless units

[Sebastien Derriere]

Ed Shaya wrote:
> 
> >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.
> >
> And, that 'some other way' is?

  E.g., checking other pieces of metadata like UCD.

David Berry wrote:
> 
> 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)?

   Sorry, but as Martin said, UCD do not always imply dimensions or
units.
Take for example the case of "proper motion in right ascension". This
quantity can be expressed with two different categories of unit:
angle(like deg,arcmin,arcsec...) per time 
or 
angle-of-time(like hours,min,s) per time

Martin Hill wrote:
> 
> 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.

  I agree with Martin on this! [the above paragraph would deserve
insertion
in reference documents on the topic, imho]

David Berry wrote:
> 
> 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.

  And we already have a reasonable answer:
If I submit this unit ratio: (Jy/sr)/(Jy/arcmin2)
I get the following
http://vizier.u-strasbg.fr/cgi-bin/Unit?text=%28Jy%2Fsr%29%2F%28Jy%2Farcmin2%29
----> Factor	2.693409339497422e-08;
  No need of UCD for simple unit scaling problems...

Martin Hill wrote:
> 
> As you sort of say, there is more than one analysis, but here one is
> unit analysis and the other is dimension analysis.
> 
> Unit analysis for kg, miles, Jys, etc is not, I really don't think,
> straightforward or easily automated or much fun either.
> 
> Dimension analysis for time, length, energy, etc does not solve all our
> problems, but it is very easy and works well in many situations; much
> easier than the many<->many convertions required for unit analysis.
> 
> But as soon as you start dealing with conversions such as redshift to
> distance, or flux to magnitude, you need metadata, and this becomes what
> might be called a 'domain conversion', ie the algorithms belong to a
> particular domain of physics or maths, not to unit or dimension analysis.

  Domain conversion? I use to say "quantity conversion", but maybe I
should
not use the q-word on the dm-mailing list :)
  Let me explain what I understand by quantity conversion:

Imagine I set up a tool that will draw arrows indicating proper motion
on a 
sky map. My handy drawing routine will expect two parameters:
draw({pos.eq.pmra | arcsec/yr} , {pos.eq.pmdec | arcsec/yr})
(note that I constrain the parameters by both expected UCD and expected
unit).

  Now what do I do when I receive a VOTable and I want to plot it?
I'll first check if there is a column with the right UCD.
	- If not: use extended_lookup.
	- If I find such a column, I'll check if units are scaleable (i.e.
check if the ratio
(column_unit)/(expected_unit) is unitless (= simple factor = a floating
number)). I'll
do this using an existing unit conversion library. 
		- If units are scaleable, the problem is solved: I apply 
		the unit scaling and get the expected parameter {good UCD, good unit}.
		- Else:  use extended_lookup.

   And extended_lookup could be using a dedicated list of possible
quantity conversions,
e.g.:
${pos.eq.pmra | arcsec/yr} = 15 * ${pos.eq.pmra | s/yr} *
cos(${pos.eq.dec | rad})

  ... see the idea? We'll try recursively to find the proper
quantities in the file (in this case, check for: (UCD=pos.eq.pmra AND
unit-scalable-to:s/yr) 
AND (UCD=pos.eq.dec AND unit-scalable-to:deg).


  In summary, my point is that we can already do most of the simple
tasks,
using all of the metadata we have in the VO, and especially UCD and
units.
  In the future, complex relationships like 
${pos.eq.pmra | arcsec/yr} = 15 * ${pos.eq.pmra | s/yr} *
cos(${pos.eq.dec | rad})
might be handled entirely in an ontology, but so far I have not been
convinced
that the inference tools could handle arithmetics.
  The alternative is to store these expressions as comments in an
ontology,
and have an external application doing the interpretation. That's one of
the
possible applications we will discuss in the VOTech DS5 group.

Sebastien.
-- 
    _______
   /  ~   /, Sebastien Derriere   mailto:derriere at astro.u-strasbg.fr
  / ~~~~ //  Observatoire de Strasbourg    Phone +33 (0) 390 242 444
 /______//   11, rue de l'universite     Telefax +33 (0) 390 242 417
(______(/    F-67000 Strasbourg  France