Thank you for your comments, Friedrich. It would be possible and very flexible, and certainly more powerful than the current system. But we would loose the convenience of having one date, which we need for query answering (or we could default to the lower or upper bound, or the middle, but all of these are a bit arbitrary).
The other option would be, as discussed in the answer to Marco, to use one data and an uncertainty, probably an uncertainty with a unit (and probably different lower and upper bounds). This would make it more consistent to the ways numbers are treated. I start to think that the additional complexity for this solution might be warranted. 2012/12/18 Friedrich Röhrs <f.roe...@mis.uni-saarland.de> > Hi, > > * Time: > > Would it make sense to use time periods instead of partial datetimes with > lower precision levels? Instead of using May 1918 as birth date it would be > something like "birth date in the interval 01.05.1918 - 31.05.1918". This > does not necessarly need to be reflected in the UI of course, it could > still allow the "leave the field you dont know blank" way. This would allow > the value to be 2nd-5th century AD (01.01.100 - 31.12.400). Going with this > idea all the way, datetimes at the highest precision level could be handled > as periods too, just as zero length periods.. > > Another question that popped is how to represent (or if it should be > represented) times where for example the hour is known, but the day isn't. > If it is known someone was killed at Noon, but not the specific day. > > Friedrich > > > > On Tue, Dec 18, 2012 at 3:29 PM, 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 > > -- 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