Thank you for your comments, Marco.
2012/12/18 Marco Fleckinger <marco.fleckinger(a)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 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).
Sometimes we do not have exact dates for an events, because they are in
future,
like the opening of the airport Berlin/Brandenburg ;-)
So in this case it would be great to have property values like N/A for "not
available" for some parts. A date could then look
like May, N/A 1435.
The current model allows to set a precision to a specific level. In that
case you would set it to "Month" and say May 1435.
Expressions like 2nd to 56h century could easily be
expressed by using
tolerances. This would then look like 300 AD ± 200 years, which will is
(max+min)/2 ± |(max-(max+min)/2)|.
This on the other hand would be a completely different system for precision
(the one that we are using for numbers, actually), where have an
uncertainty. The problem with uncertainty and time is that neither years
nor months nor almost anything have uniform length. So we would need to
save both the uncertainty and the unit of the uncertainty, which would make
the model more complex. This would be a viable solution, I guess.
* 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?
Altitudes are for sure very important. Maybe not in Germany but for
Austria I
know several altitudes. It's very interested for passes,
mountains, cities, villages, wells of brooks, etc.
How will you create a list of the highest mountains without an altitude of
their highest peaks (Phase 3)? Or even one for the lowest passes for
crossing the alps.
The question is not whether we need an altitude at all. The question is
whether it should be part of the Geolocation datavalue or if it should be
in a property of its own. If you want to have a list of the highest
mountains, you would actually sort them by the height-property.
Look at the articles for living creatures. Often there
is mentioned from
which to which altitude they can be found. There we also have it twice. But
here we do not have geolocations.
IMHO it would be make sense to have something hybrid. The datatype for
geolocation should accept something like a NAN-value for optional
altitudes. But it should also be possible to use altitudes without
longitude and latitude.
Why would it make sense to have both? What is the altitude in the
geolocation good for? Is there an example in Wikipedia where it is or would
be used, and where a property of its own would not be better?
So we can store something like
http://www.grassyknolltv.com/**2012/tour-de-france/resources/**
maps/ETAPE%2007%202012.jpg<http://www.grassyknolltv.com/2012/tour-de-fra…
http://www.grassyknolltv.com/**2012/tour-de-france/resources/**
profiles/profile-07.jpg<http://www.grassyknolltv.com/2012/tour-de-france…
which is both about the 7th stage of the Tour de France 2012, just in
different views. Providing the possibility to store seperate altitudes
allows us to store properties like "grows at altitudes from 1800 to 2200
meters above sea level".
Separate altitudes is possibly very similar to lengths of snakes which is
also measured in meters and has also to value just in another dimension.
Exactly.
* 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?
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 (such as WP-templates) to transcalc values,
which can easily be developed by the community.
Internally we would translate it, yes, otherwise the numbers would not be
comparable. But for editing we need to keep the unit of the source / of the
editor, or else we will loose precision.
Cheers
Marco
2012/12/17 Denny Vrandečić <denny.vrandecic(a)wikimedia.de
<mailto:denny.vrandecic@**wikimedia.de
<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<https://meta.wikimedia.org/wiki/Wikidata/Development…
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 <tel:%2B49-30-219%20158%2026-**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 <tel:27%2F681%2F51985>.
--
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<https://lists.…
______________________________**_________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikidata-l<https://lists.…
--
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.