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, it could
still allow the "leave the field you dont know blank" way. This would allow
the value to be 2nd-5th century AD (01.01.100 - 31.12.400). Going with this
idea all the way, datetimes at the highest precision level could be handled
as periods too, just as zero length periods..
Another question that popped is how to represent (or if it should be
represented) times where for example the hour is known, but the day isn't.
If it is known someone was killed at Noon, but not the specific day.
Friedrich
On Tue, Dec 18, 2012 at 3:29 PM, Denny Vrandečić <
denny.vrandecic(a)wikimedia.de> 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 May 1918. But is this sufficient? We cannot enter a
value like 2nd-5th century AD (we could enter 1st millenium AD, which would
be a loss of precision).
* Geo: the model assumes latitude, longitude and altitude, and defines
altitude as over mean sea level (simplified). Is altitude at all useful?
Should it be removed from Geolocation and be moved instead to a property
called "height" or "altitude" which is dealt with outside of the
geolocation?
* Units are currently planned to be defined on the property page (as it is
done in SMW). So you say that the height is measured in Meter which
corresponds to 3.28084 feet, etc. Wikidata would allow to defined linear
translations within the wiki and can thus be done by the community. This
makes everything a bit more complicated -- one could also imagine to define
all dimensions and units in PHP and then have the properties reference the
dimensions. Since there are only a few hundred units and dimensions, this
could be viable.
(Non-linear transformations -- most notoriously temperature -- will get
its own implementation anyway)
Opinions?
2012/12/17 Denny Vrandečić <denny.vrandecic(a)wikimedia.de>
As Phase 2 is progressing, we have to decide on
how to represent data
values.
I have created a draft for representing numbers and units, points in
time, and locations, which can be found here:
<https://meta.wikimedia.org/wiki/Wikidata/Development/Representing_values
including a first suggestion on the functionality of the UI which we
would be aiming at eventually.
The draft is unfortunately far from perfect, and I would very welcome
comments and discussion.
We probably will implement them in the following order: geolocation, date
and time, numbers.
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 |
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 |
http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l