On 18 December 2012 12:58, Lydia Pintscher lydia.pintsc...@wikimedia.dewrote:
2012/12/5 Lydia Pintscher lydia.pintsc...@wikimedia.de:
Heya :)
On 18 December Denny and I will do the next round of Wikidata office
hours. Everyone with questions about Wikidata is welcome.
Thanks for the input so far. Here are a few explicit questions that I have:
* Time: right now the data model assumes that the precision is given on the
level decade / year / month etc., which means you can enter a date of
birth like 1435 or May 1918. But is this sufficient? We cannot enter a
Hello,
On 2012-12-18 15:29, Denny Vrandečić wrote:
Thanks for the input so far. Here are a few explicit questions that I have:
* Time: right now the data model assumes that the precision is given on
the level decade / year / month etc., which means you can enter a date
of birth like 1435 or
Hi,
* Time:
Would it make sense to use time periods instead of partial datetimes with
lower precision levels? Instead of using May 1918 as birth date it would be
something like birth date in the interval 01.05.1918 - 31.05.1918. This
does not necessarly need to be reflected in the UI of course,
Thanks for this Denny.
Time:
Historians **need** to be able to have date ranges of some sort. They also
need to express confidence in non-numerical terms. Take for example, the
invention of gunpowder in China. Not only do several major historians have
different ranges entirely (which would, of
Thank you for your comments, Marco.
2012/12/18 Marco Fleckinger marco.fleckin...@wikipedia.at
On 2012-12-18 15:29, Denny Vrandečić wrote:
* Time: right now the data model assumes that the precision is given on
the level decade / year / month etc., which means you can enter a date
of birth
Thank you for your comments, Friedrich.
It would be possible and very flexible, and certainly more powerful than
the current system. But we would loose the convenience of having one date,
which we need for query answering (or we could default to the lower or
upper bound, or the middle, but all of
How about this:
- Values default to a non-range value
- You can click a checkbox that says range to turn the input into a range
value instead
- An entry can only be represented by either a non-range or a range number,
not both
This relieves our issue with query answering:
Query: When was XXX
Denny,
could you maybe elaborate on what you mean by query answering? Do you talk
about some technical aspect of the wiki-software?
thanks,
On Tue, Dec 18, 2012 at 5:08 PM, Sven Manguard svenmangu...@gmail.comwrote:
How about this:
- Values default to a non-range value
- You can click a
On 2012-12-18 16:52, Denny Vrandečić wrote:
Thank you for your comments, Marco.
NP
2012/12/18 Marco Fleckinger marco.fleckin...@wikipedia.at
mailto:marco.fleckin...@wikipedia.at
On 2012-12-18 15:29, Denny Vrandečić wrote:
* Time: right now the data model assumes that the
It would be possible and very flexible, and certainly more powerful than the
current system. But we would loose the convenience of having one date, which
we need for query answering (or we could default to the lower or upper
bound, or the middle, but all of these are a bit arbitrary).
I
Now, I don't think we need or want ranges as a data type at all (better have
separate properties for the beginning and end).
I am afraid this will then put a heavy burden on users to enter,
proofread, and output values. Data input becomes dispersed, because
the value 18-25 cm length has to be
The great thing about MediaWiki is that we don't have to anticipate new
features, we can build them in later when we discover that they're possible
and that they're wanted. In fact, there's no requirement that the Wikidata
developers are even the ones that do develop said hypothetical future
On 2012-12-18 17:49, Gregor Hagedorn wrote:
IMHO it would make sense to use the [[International System of Units]] for
internal storage. It is not consequently used in other realms, not even in
the German spoken countries (PS vs. kW for cars). Maybe it would be possible
to use small scripts
On 18.12.2012 17:57, Gregor Hagedorn wrote:
Now, I don't think we need or want ranges as a data type at all (better have
separate properties for the beginning and end).
I am afraid this will then put a heavy burden on users to enter,
proofread, and output values. Data input becomes
On 18.12.2012 17:52, Gregor Hagedorn wrote:
It would be possible and very flexible, and certainly more powerful than the
current system. But we would loose the convenience of having one date, which
we need for query answering (or we could default to the lower or upper
bound, or the middle, but
I don't see this as a big overhead. It is more a problem for ordering,
but internally, wikidata could store a midpoint value for intervals
where no explicit central value is given, and use these for ordering
purposes.
Well, I would call that mid point simple the value, and the range would be
On 18/12/12 16:52, Denny Vrandečić wrote:
Thank you for your comments, Marco.
2012/12/18 Marco Fleckinger marco.fleckin...@wikipedia.at
mailto:marco.fleckin...@wikipedia.at
IMHO it would be make sense to have something hybrid. The datatype
for geolocation should accept something like a
(ASIDE: Regarding presentation: it is not always algorthmically eay
whether to present 0.01 m as 1 * 10e-14 or a 10 fm = 10 *
10-15. In a scientific context, only the SI steps should be used, in
another context the closest decimal may be appropriate.)
But floating point numbers
19 matches
Mail list logo
