Type talk:Length

From semanticweb.org

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)

[edit] 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)