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 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
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
