[Data-modeling] Units and Physical Dimension

[movgp0 at gmail.com]

Hello Folks! 

* If you just want a summary scroll down to the end. 
* The next thing an intro to myself. You may skip this section. 

INTRO ==============================================

There are some issues with the Measurement Unit Domain and the way Freebase handles measurements in general: its not flexible enough for a physicist! 

I've tried to discuss this issue on freebase, but it appears that this is not the right place to do so. So, I've registered for this list. 

First, let me say that I'm not a complete newbie. I've learned microelectronics at school and have thus basic knowledge about higher maths and physics (electrodynamics with some relativity and quantum theory). Also I'm a programmer with specialisation on the .NET platform and semantic systems. 

I've also written a big part of the information on the german Wikipedia about units and physical dimensions some years ago. The german Wikipedia has now a higher quality in this matters than the english one ;-) 

I do understand that this is a very complex topic and in no way easy to implement. But nothing impossible. 


CURRENT IMPLEMENTATION ===========================

The first thing to know is how freebase handles units and dimensions currently. In the Measurement Unit Domain there is a class called "Unit Profile" which links to "Dimension" (actually this may be a fault, because a mathematical Dimension is more general than physical Dimension). 

From this base type there are deriving subtypes of the form "Unit Of ..." like "Unit Of Area" that provide a property (relation) with a float-value that is directly linked with system internal units. This internal units have forms like "s", "ms", "µs" for time or "m²", "in²", etc. for area. There is a limited set of predefined units for a limited set of dimensions. 

This way of representing units is not specific to the developers of freebase. It is very common in IT industry. The guys from freebase are rather doing a great job in their field. There are some pros about doing so: 

* easy to implement 
* industry standard: more libraries; database support available
* fast, because more native to computer hardware. 


TROUBLES =======================================

On the other side, this IT industry based unit system comes with a huge amount of troubles on the user side:  

(1) There is a potentially unlimited number of units, but only a given subset is predefined. Exotic units are not supported. 

(2) The same unit is handled as complete other kind of unit if it has another prefix. In fact, the prefix defines the scale of the unit and not another unit. This not only restricts the way a user can input values, but it also causes an exponential growth in the number of units. 

(3) Quantities may be given in other units. One can give electrical capacity in units of cm (CGS-system) rather than F (SI-system). 

The means of unit systems is only to provide units that can represent values in common dimensions in practical terms. They also provide suggestions when this units should get applied. 

Ie. the SI system suggests (and doesn't force) to use "s" for time and "m" for lenght. But you can also measure time in (light-)metres and length in (light-)seconds. 

(4) There is a potentially unlimited number of (physical) dimensions. But there is only a small subset defined in the freebase system. Also this dimensions are defined in a way that causes an exponentially growing number of "Unit Of ..." classes. 

(5) In physics, a dimension is defined as exponents to the dimensions 1, L, M, T, I, θ, N, and J. The common combinations are named, including "L T^−1" (speed) "M L^2 T^−2" (momentum) and "M L^2 T^−2 θ^−1" (entropy). Other combinations may not have a name (how would you name "M^(1/2) T^sqrt(2)"?). Exotic and unnamed dimensions are currently unable to get modelled in freebase. 

(6) Some physical dimensions are not able to get represented using scalar values. This means that float-values cant represent them. A rectangular size is currently represented using an 'x' and a 'y' value. In fact, this is a complex number of the form "x+iy". 

Support for complex numbers would be fine. 


ADVANCED ======================================

now some not so problematic issues: 

(7) The same physical dimension may have multiple kinds of sizes. Ie. the dimension T (Time) is represented by timespan, duration and 'time stamp'. 

Side note: 
* a duration is a timespan too
* a time stamp is actually a timespan with a context-given 0-point; mostly in the year 0. 

(8) For complex numbers or even octonions (8-dimensional number) some hook like in the Rectangular class might work in the most cases. But its not a good way to define matrices/tensors this way. 

Ie. take a tensor of the form:  [ [λ,1,0,0], [1,λ,1,0], [0,1,λ,1], [0,0,1,λ] ]

Tensors are very common in electrodynamics (electromagnetic tensor) and relativity theory (Lorentz transformation). 

Complex numbers in non-euclidean space are also not representable in the current system, but I guess that's only relevant in higher maths. 

This issue could get solved by accepting TeX like syntax as input. The syntax might allow to semantically link symbols (ie. units and tensors) to freebase articles and render them as MathML + XLink (+ RDFa) output. 

(9) Physical dimensions have properties (flags) how they behave. 
* proportional size
* oriented size
* extensive state size
* intensive state size
* size of process
* size of energy
* size of field
* pseudo vector
* conservation size of the C-symmetry (charge-conjugation)
* conservation size of the homogeneity of space
* conservation size of the isotropy of space

Example: 
* the angle speed (formula sign "ω", dimension "T^−1", SI unit "rad·s^−1") IS a pseudo vector
* the circular speed (formula sign "ω", dimension "T^−1", SI unit "rad·s^−1") IS NOT a pseudo vector. 

This is possible to get defined on the article level. But since the built-in dimensions of freebase are restricted to the dimensions of the programming language and not founded on the articles, this definitions will not reflect in the freebase type system. 

Measured sizes are further categorized by humans and thus may have different formula signs. This can get modelled at the article level too. 


SUMMARY =====================================

* Physical dimensions are different to mathematical dimensions. 
* A physical dimension is defined by a polynomial of the base dimensions 1, L, M, T, I, θ, N, and J. 
* A physical dimension may not have a name. Classes for them are pointless. 
* The dimension is further categorized by properties of the measured size. 
* Measured sizes are categorized by humans. (ie. length -> width, height, thickness, etc.) 
* This categories are mapped (arbitrarily) to formula signs. 
* Units are mapped as polynomials to dimensions. Units are provided by unit systems. 
* Unit systems provide suggestions when to use specific units. One can measure (almost) any value in (almost) any unit. 


WEBLINKS =====================================

* http://de.wikipedia.org/wiki/Liste_physikalischer_Gr%C3%B6%C3%9Fen (german)
* http://en.wikipedia.org/wiki/List_of_physical_quantities (english, but not complete)

You should take a look at some of the articles of units and physical dimensions on the german wikipedia. They are provided with templates for the most important information. 

Examples: 
* Unit: http://de.wikipedia.org/wiki/Volt
* Dimension: http://de.wikipedia.org/wiki/Elektrische_Spannung

==============================================
Tipp: Better get a cup of tea or coffee now. 

Thank you for reading, 

MovGP0 aka. Johann Dirry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 268 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebase.com/pipermail/data-modeling/attachments/20090429/d4962118/attachment-0001.pgp