On 2012-12-18 16:52, Denny Vrandečić wrote:
Thank you for your comments, Marco.
NP
2012/12/18 Marco Fleckinger <marco.fleckinger@wikipedia.at mailto:marco.fleckinger@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.
I'd use the same unit as tha base – its 300 years AD so the uncertainty is also measured in years.
* 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.
A list of the highest mountains with their peaks within a specific area?
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?
The answer is below.
What is the altitude in the geolocation good for?
Peaks of mountains e.g. are geolocated with an altitude. Also passes, some events, places where something scientific was found or took place.
Is there an example in Wikipedia where it is or would be used, and where a property of its own would not be better?
E.g. preventing having one geolocation and multiple altitudes. A list of point on one section of the Tour de France should contain all point where each one should contain all three components, because they belong together. The place is always mentioned with the altitude.
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/maps/ETAPE%2007%202012.jpg> http://www.grassyknolltv.com/__2012/tour-de-france/resources/__profiles/profile-07.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.
+1
Cheers
Marco