On 19.12.2012 16:57, Sven Manguard wrote: > There is a balance. The more flexible the parameters, the easier it is to put > data in, but the harder it is for computers to make useful connections with > it. > I'm not sure how to handle this, but I am sure that we can't just keep > pretending that all of the data we're going to collect falls nicely into the > metric system. Reality just doesn't work that way, and for Wikidata to be > useful, we can't discount data that doesn't fit in the mold of modern units.
First off: our target use case is Wikipedia infoboxes. Do you have examples and numbers about the usage of such ancient units in infoboxes on wikipedia? If they are not in main stream use there, I don't see why Wikidata would have to support them. Though, of course, it would be nice to support them. Basically, what I envision is this: for every property with the data type "quantity", you can specify a default unit. That can be kilogram or pascal or kilometer, or li or ancient egypt foot (I'll leave the question of how to define such units for later). The default unit implicitly defines the dimension that is measured by the property (length, weight, charge, whatever) and thereby implies the base unit to be used internally (kg, m, etc). Some units have derived units (km derives from m, g derives from kg, etc) and support automatic conversion to different units of the same dimension (meter to foot, kg to stone, whatever). Some, like li, will not have a conversion to the metric system defined. You can still use them, but you cannot compare them to values in another system of measurement. -- daniel PS: the above reflects my personal ideas on how to best do this, this is not a finished design and wasn't discussed with the rest of the wikidata team. -- Daniel Kinzler, Softwarearchitekt Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
