How about this: - Values default to a non-range value - You can click a checkbox that says "range" to turn the input into a range value instead - An entry can only be represented by either a non-range or a range number, not both
This relieves our issue with query answering: Query: When was XXX invented? Non-range answer: June 1988 Range answer: sometime between May 1988 and October 1989 Does that work? Sven M On Tue, Dec 18, 2012 at 10:56 AM, Denny Vrandečić < denny.vrande...@wikimedia.de> wrote: > 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 > >
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
