On 21 December 2012 18:14, Denny Vrandečić <denny.vrandecic(a)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