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.vrandecic@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.roehrs@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.vrandecic@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.vrandecic@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:


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