Extension talk:Wikibase Quality Extensions/Archive 1

Birth dates
I notice you plan to compare birth dates to external databases as a quality control measure. However, there are bugs in Wikidata's implementation of birth and death dates. One part of the discussion is at https://phabricator.wikimedia.org/T88438

The last country to change from the Julian to the Gregorian calendar was Greece in March 1923. Before that, it is difficult to decide if a date is in the Gregorian or Julian calendar. Also, at the moment, Wikidata does not have a policy about whether dates of events that occurred at a time and place where the Julian calendar was in force should be stored in the Julian or Gregorian calendar. Also, there is no policy about what format the date should be stored in.

Another pitfall is for dates in ancient Rome, which were recorded in the Roman calendar. Not enough records survive from ancient times to precisely convert Roman calendar dates to either proleptic Julian or Gregorian calendar dates. Also, between 45 BC and 1 March AD 4, the Julian calendar was not implemented as Julius Caesar intended, so conversion of these dates to the proleptic Julian or Gregorian calendars may be wrong by a few days. (Proleptic means that one starts from a well known modern date and applies the rules of the calendar to give dates to events before the calendar was introduced.) Jc3s5h (talk) 15:56, 19 February 2015 (UTC)
 * Right. So they should show up in constraint reports to get them fixed. And they will. --Lydia Pintscher (WMDE) (talk) 09:53, 22 February 2015 (UTC)


 * I have three questions about the constraint reports. First, how could a constraint report tell the difference between a correct value and an incorrect value (except a really gross error, such as the date for "ninth day before the Kalends of Octobera in the consulship of Marcus Tullius Cicero and Gaius Antonius" for the birth date of Augustus.


 * Second, how would the dates be corrected? To you contemplate any method other that an editor performing the appropriate research?


 * Third, after a date is corrected, wouldn't the constraints still flag it as an error? Jc3s5h (talk) 20:53, 22 February 2015 (UTC)


 * Also, my comment was not really aimed at constraints. The WikidataQuality effort proposes to compare external sources to dates stored in Wikidata to identify suspicious dates. To make a valid comparison, two things must be clear: what calendar the Wikidata is stated in, and what calendar the external date is stated in. So I was pointing out a problem that the WikidataQuality effort must solve (or avoid). They could avoid the problem by giving up on a comparison if either the Wikidata or external date is before March 1923. Jc3s5h (talk) 22:10, 22 February 2015 (UTC)


 * It would be found through comparisons with external databases. It would be corrected by editors after seeing it in a list of issues or on the item itself. There is no reason why we should give up on this. --Lydia Pintscher (WMDE) (talk) 07:36, 23 February 2015 (UTC)


 * OK. Strictly speaking, a comparison with an external database is different from a constraint; constraints contain apriori knowledge about what a valid date could be, for example, the birth date of a member of the species Homo Sapiens cannot be earlier than about 200,000 BC. I am not suggesting giving up altogether, I am just pointing out that the calendar used for both the external database(s) and the Wikidata entry must be known. If the calendar for either is unknown, either the comparison for that entry should be abandoned, or a suitable tolerance should be established for the difference between Julian and Gregorian dates, also taking into account possible differences in the start of the year, should be applied. Data values presently contained in Wikidata suggest that most editors (or bots) seem to be entirely unaware that the Gregorian calendar has not been in force since the Sumarian civilization and the Xia dynasty, so I feel the need to point out the subtleties of calendars to new projects. Jc3s5h (talk) 16:40, 23 February 2015 (UTC)

Remark
First it would be good to establish a list of different constraints: nowhere on wikidata there is a single page explaining the objectives of the constraints and their limitaions or use. Then once we have the current list and their framework, a discussion is needed to see if more constrainst are needed. I am a little afraid to see the new system be abandoned in the future because it cannot be used in cases. Are we sure now that the current constraints allow to treat 90% or more of the community purposes ? Snipre (talk) 13:00, 21 February 2015 (UTC)
 * That is what d:Wikidata:Constraint violation report input was/is for. If you have any useful/important constraints that are not covered in the current system then it'd be good to know about them now to see if they can be accommodated. --Lydia Pintscher (WMDE) (talk) 09:52, 22 February 2015 (UTC)

Type constraint checking appears incomplete
For example this item is marked as "instance of battle", and battle has "subclass of event", however the constraints page still marks it as a violation for not being an event. Is this the place to bring that up? Popcorndude (talk) 19:15, 6 July 2015 (UTC)
 * Actually, I looked at it again, and what seems to be happening is that this checking works fine. The problem is that property it's objecting to accepts event or fictional event, which it appears to be interpreting as event and fictional event. Popcorndude (talk) 19:19, 6 July 2015 (UTC)
 * More specific description, if helpful: In Wikidata:Template:Constraint:Type, the "classes" parameter is generally used to mean that the item must be an instance of at least one of the items or their subclasses, not necessarily all of them. Popcorndude (talk) 19:27, 6 July 2015 (UTC)
 * Yes, this is the place to bring something like this up. Thanks for writing us! And you are absolutely right, this looks a lot like a bug. We are aware that it has to comply with at least on of the items given in the parameters, not all of them. I have an assumption why this is marked (incorrecly) as a violation. The subclass chain in Wikidata might contain circles. To avoid running in an infinite loop, we only check to a depth of 20. If this is reached, we consider it a violation. I think that on one path we reach this depth before finding a compliance. We will have a look at it in a few days to fix this issue. Espacially in this case, where one path leads to a compliance very fast, the compliance needs to be found. Sorry! Jonas.keutel (talk) 12:31, 13 July 2015 (UTC)