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-france/resources/profiles/profile-07.jpg

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@wikimedia.de
<mailto:denny.vrandecic@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 <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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

--
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.