Denny, could you maybe elaborate on what you mean by query answering? Do you talk about some technical aspect of the wiki-software?
thanks, On Tue, Dec 18, 2012 at 5:08 PM, Sven Manguard <[email protected]>wrote: > 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ć < > [email protected]> 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 <[email protected]> >> >>> 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ć < >>> [email protected]> 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ć <[email protected]> >>>> >>>>> 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 >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >>>> >>>> >>> >>> _______________________________________________ >>> Wikidata-l mailing list >>> [email protected] >>> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >> >> > > _______________________________________________ > Wikidata-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata-l > >
_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
