Thanks for this Denny. Time:
Historians **need** to be able to have date ranges of some sort. They also need to express confidence in non-numerical terms. Take for example, the invention of gunpowder in China. Not only do several major historians have different ranges entirely (which would, of course, be treated as different line items anyways), but the premier authorities are all giving date ranges. Some will say things like "between XXX and YYY", which requires date ranges, while others say "around ZZZ", which requires us to have some sort of way to represent "about". As to the first issue, we could try pairing entries, like we already are likely to be doing for things like "reign start date/reign end date" but that would be clumsy and very easily broken. As for the latter, I'm really not sure what the proper solution is. I am sure though, that if a historian says "about 850" and we put in "850", we're going to be **wrong** and that's going to be **bad data**. Additionally, unless the historian gives a range himself, we can't say "850 +/- 25" or some such thing. That would also be wrong. Geo: I can definitely see how altitude would be good for things like a rest lodge halfway up a mountain or a shipwreck below sea level. I'm not sure if any of the map makers can handle altitude right now; as far as I know things like Open Street Map and Google Maps are two dimensional maps with 'fake' three dimensional protrusions. That being said, I think that we should build the feature in and then trust that the map making companies will eventually figure out what to do with it. Google is probably crazy enough to mount cameras and GPS software on sherpas and send them up mountains if they think that maps accounting for altitude are something that could, erm, sell. Units: Not sure I understand the post, but I might. I advocate that we should have the unit translations stored on some page in the (already automatically full protected) MediaWiki namespace, and that conversions should be handled on this project before the data is sent out to client projects. The reason for this is that it makes adoption by (non WMF) end users much, much easier. It's not like the conversions are a subject of debate. On Tue, Dec 18, 2012 at 9:29 AM, Denny Vrandečić < denny.vrande...@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.vrande...@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@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
