Gregor Hagedorn g.m.haged...@gmail.com schrieb:
So, please suggest terms to use for at least these two things:
1) value certainty (ideally, not using digits, but something that
is
independent of unit and rendering)
Here we want to talk about something that the true value is with a
certain
On 20.12.2012 20:52, Gregor Hagedorn wrote:
I believe there are a lot of dangerous assumptions on
http://simia.net/valueparser/
First: there is no indication in a number that it is _not_ endlessly precise.
Apostles = 12
has no uncertainty, representing it as
12 ± 1 is wrong, but also 12
On 20.12.2012 20:31, Friedrich Röhrs wrote:
Hi,
tried to enter the height of the eiffel tower. 324 meters. It suggested 324m
+-100m.
That's strange. When I enter 324m, it correctly suggests 324m+/-1 for me.
-- daniel
--
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland -
On 20.12.2012 20:59, Avenue wrote:
Thanks, the prototype helps make some this more concrete.
I am increasingly wondering if uncertainty will be overloaded here. People
seem to want to use it for various types of measurement uncertainty (e.g. the
standard error), ranges with no defined
Hi,
Does for me too now. Maybe i played around with the autouncertainty
checkbox before trying 324 (probably had some 4 digit value before).
Although the Problem remains, the height of the Eifeltower is not 324 +-1
meter. It is given as 324meters without any further information. So it
should
Hallo Lydia,
bitte mich vom Wikidata-Verteiler löschen:
Ich war einige Zeit im Krankenhaus und habe die
rd. 300 e-mails gelöscht, weil ich nicht mehr in der
Lage bin, das alles nachzuvollziehen - es wird mir
im Moment einfach alles zu viel.
Gruß aus Paderborn
- auch an Denny
-
Hm the second one is only relevant for output.
I think this is a fundamental misunderstanding: The original one is
not for output but is the primary value for interpretation, for
understanding whether a value in Wikidata is correct of fake, or a
software conversion error, or what. If I want to
I don't like significant digits because it depends on the writing system
(base
10). I'd much rather express this as absolute values.
Yes, I would like too. What I argue is that the problem is that you
simply in 99.9 % (not a researched of number of course) of cases
simply don't know more
Hi all,
wow! Thanks for all the input. I read it all through, and am trying to
digest it currently into a new draft of the data model for the discussed
data values. I will try to adress some questions here. Please be kind if I
refer the wrong person at one place or the other.
Whenever I refer to
(if i knew the private email for Denny, I'd send this there)
Martynas, there is no mention here of XSD etc. because it is not
relevant on this level of discussion. For exporting the data we will
obviously use XSD datatypes. This is so obvious that I didn't think it
needed to be explicitly
The xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive and
xsd:maxExclusive facets are absolute expressions not relative +/-
expressions, in order to accommodate fast queries. These four facets
permit specification of ranges with an unspecified median and ranges
with a specified mode,
On 21 December 2012 19:36, jmccl...@hypergrove.com wrote:
The xsd:minInclusive, xsd:maxInclusive, xsd:minExclusive and
xsd:maxExclusive facets are absolute expressions not relative +/-
expressions, in order to accommodate fast queries. These four facets permit
specification of ranges with an
I detect a need to characterize the range expression - most
important of which is whether the range is complete, or whether it
excludes (equal) tails on each end. XSD presumes a complete range is
being specified, not a subset, is the issue you're raising?
Could an
additional facet for
Hi,
On Fri, Dec 21, 2012 at 6:14 PM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
Friedrich, the term query answering simply means the ability to answer
queries against the database in Phase 3, e.g. the list of cities located in
Ghana with a population over 25,000 ordered by
14 matches
Mail list logo
