Type talk:Length

Why not calling this Type just "length"? It would be simpler to use. Timespans could be named "Timespan" or "Duration" for distinction anyway. MovGP0 01:19, 20 November 2005 (CET)

Atomic lengths have a different range (nanometers) then geographic lengths (meters, kilometers) and are even different from astronimic lenghts (parsec and such). The problem we see lies in current computer systems: There is simply no established way in RDF and XML to encode numbers with arbitrary precision. Either one uses decimal numbers, which for only for a certain interval (format: string with a comma) or one uses floats, which loose precison due to rounding errors. Some normalisation is needed in order to be able to compare numbers. As it makes no sense to compare e.g. astronomic and geographical lengths (list of cities and planets, ordered by surface area), we chose to seperate them. --86.42.0.170 13:06, 20 November 2005 (CET)


 * What we need to handle any Units is Math. Currently the units are hard-coded, because coding an CAS is really hard work - and even implementing an existing one is not so easy than hardcoding. But I've already suggested to use a CAS. We probably won't see such a thing in the first release. But maybe we will see that in a later Release in some Years. MovGP0 17:50, 20 November 2005 (CET)

geographic vs. other lengths
"Geographic length" seems to have broken several attributes, though "Geographic area" is working OK.

This wiki currently makes the strange claim that Property:height is a Property:length which is of Type:Geographic length. "Giraffes are about height:=5 m tall" is not a geographic length as English speakers understand the word "geographic". Maybe the attribute "elevation above sealevel" is a Geographic length.

It seems the main reason for particular kinds of lengths is to display appropriate units in normalized attribute values (km and miles for Geographical length, maybe cm for Biological length, parsecs for astronomical distances, etc.). For reading in units in attribute values there's no guarantee that an article won't say "California is 1,240,000 m long" or even "California is 102,400,000 cm long". So perhaps consider inheriting all length types from one type that reads any units. --Skierpage 13:47, 24 January 2006 (CET)


 * We did this in SMW 0.5. An attribute using Type:Length can specify preferred display units from the set that the underlying type implements. -- Skierpage 01:37, 14 September 2006 (CEST)

sensible decimal precision
Is there a way to fuzzify the displayed decimal precision, or to round the display of a property that is converted from one unit to another?

for example, I have a property defined as speed (of type velocity), with display units km/h, mph

thus an item annotated with a speed of 90 MPH displays in the fact box as 144.841 m/s (90 mph). The precision is excessive in this case. A 'fuzzier' result would be nice where appropriate.

thanks