On 21 December 2012 18:14, Denny Vrandečić denny.vrandecic@wikimedia.de wrote:
What about upper and lower bound?
I did like these but it has a hard semantics as well (which I were not acquainted with, so I did like it until reading: http://en.wikipedia.org/wiki/Upper_and_lower_bounds )
Or just upper and lower? And then leave the interpretation to others.
I like plus and minus better then. For the limited application that this value will have (i.e. not expressing statistics, min/max, ranges, etc.) it should not be a full value, but an addition/subtraction value.
Making it a full value will throw the quantity type into the muddy waters of being abused as a (so far missing) "range-interval with optional central value" type. I think this should be avoided.
By your own priorities, I am somewhat confused why you want to cover this case at all. Can you show the Wikipedia occurrence statistics for values for which a margin of error is given? I can remember plenty of cases where an interval type is needed, but I cannot recall more than 1 or 2 times I have encountered a plus/minus number.
I propose to drop it altogether, and use the xsd based total digits + fractional digits attributes instead, as per the proposals int he discussion.
Gregor, an infinitively precise number (the number of apostles, e.g.) would be handled trivially by +- 0.
I understand that, my problem is the default behaviour. By default (unless a wikidata editor reads this thread first :-P) you make it "11 to 13"
Regarding the height of the Eiffel tower: 324 m +- 1m is exactly what I would like to see here if the source states 324 meter. I know the source doesn't say +-1m, but this is certainly supported by the source. Think about why we need this +-1m: it is simply so we can give a useful transformation into feet. Otherwise we cannot convert units. The +-1m would not be displayed usually.
If Wikidata converts all data entered into something that is supported by the data, but much less informative, the value will be drastically diminished. Your argument would hold for "I know the source doesn't say +-100 m, but this is certainly supported by the source." as well.
The margin of error is as valuable information as the value itself. I see no reason nor justification to fabricate it. Yes, you can add an additional property "fabricated margin of error" (a somewhat derogative, but I think fair rendering of "autouncertainty"). Why does Wikidata want to introduce this level of complexity?
It seems you intend to use it for dealing with conversions and return converted values with meaningful significant digits, is that correct? According to my analysis, the error introduced in applying the digits after conversion is at most 0.5 in the original unit. This is less than the error introduced in the unsupported assumption made when the software invents somewhat arbitrary margins of error (like the +/- 1 m for Eiffel tower) and identical to the error introduced by the more conventional bracketing of 0/- 0.5:
1.234 mm -> 0.001234 m = significant digits are lossless. 1.234 m -> 4.04856 ft -> round to significant digits: -> 4.049 ft 1.234 ft -> 0.376123 m -> round to significant digits: -> 0.3761 m
Gregor