From Wikidata
Jump to navigation Jump to search

How is it planned to support? What does it mean exactly? That dates (of creation/demolition, birth/death, and so on) should exist or if they exist they should coordinate? --Infovarius (talk) 10:25, 16 August 2017 (UTC)

Its implementation is pending (and near), I talked with Lucas Werkmeister about it. You can see some details in T141859. Indeed, there should be no violation if those statements aren't defined. Thanks for your interest! --abián 11:56, 16 August 2017 (UTC)

Removed from properties[edit]

As this breaks the constraint reports, I removed this from the 57 properties listed on . They can easily be re-added once support is available.
--- Jura 11:07, 16 December 2017 (UTC)

How does (did) it break the constraint reports? WikibaseQualityConstraints / checkConstraints shouldn’t have any problems with this, and I really don’t like the thought of removing constraints just because one of the systems checking them is broken (for instance, I also oppose Special:Diff/581656639, even though that one’s arguably my fault because phabricator:T178295 is still awaiting a fix). --Lucas Werkmeister (WMDE) (talk) 13:08, 18 December 2017 (UTC)
All constraint reports with this constraint hadn't been updated in four months.
--- Jura 13:54, 20 December 2017 (UTC)
I wasn't aware it worked with your gadget .. did it?
--- Jura 13:59, 20 December 2017 (UTC)
Sorry, I didn’t see your reply earlier – by constraint reports, I assume you mean Wikidata:Database reports/Constraint violations, generated by KrBot? For checkConstraints it should work, yes, you’d only see a Todo status on Special:ConstraintReport, and nothing in the gadget. (I tested it just now with Boeing 747 (Q179), since manufacturer (P176) right now does have the constraint statement.) --Lucas Werkmeister (WMDE) (talk) 14:52, 4 January 2018 (UTC)
Lucas Werkmeister (WMDE): to summarize: the addition of the constraint already questioned in August still doesn't do anything for the gadget/Special:ConstraintReport (other than "todo"), but breaks the original constraint reports: Furthermore, the constraint is thought to be insufficiently specified to enable development. Is this correct? Why is WMDE insisting on the addition of these constraints?
--- Jura 16:05, 4 January 2018 (UTC)
  • I don’t see where the addition of the constraint was questioned – if you’re referring to Infovarius’ comment above, then that is not how I would interpret it. {{Constraint:Contemporary}} has also existed since well before August 2017, and I was under the impression that KrBot used to support it, too (but I might be wrong here).
  • A detailed specification of the constraint can be found in phabricator:T141859. It’s still open for discussion, but that doesn’t prevent it from being developed.
  • WMDE is not insisting on any such thing. As the maintainer of one of the two constraint-checking systems on Wikidata (that I’m aware of), I asked for clarification of your claim that this breaks the constraint reports (in case you’d found a bug in WikibaseQualityConstraints), and then expressed my personal opinion on removing constraints due to implementation problems. Perhaps I should have marked that last part more clearly as nothing more than my opinion, but my primary reason for responding was just to check whether you had found a bug that I needed to fix :) --Lucas Werkmeister (WMDE) (talk) 11:29, 5 January 2018 (UTC)
As Jura seems to insist that Lucas isn't "allowed" to comment, and that he thus has no opposition here, let me restate the opposition that I already expressed clearly in edit summaries. I oppose these removals per Lucas. Jura has not demonstrated to anyone's satisfaction that these removals are necessary or a good idea, and in the explicit absence of consensus, he needs to wait for a consensus for form, by more editors weighing in, before he changes the status quo. Swpb (talk) 14:28, 4 January 2018 (UTC)
Other than that you oppose for the sake of opposing, maybe you can explain what the advantage of adding these statements is compared to a broken constraint reports. See #Contemporaneousness for a better aproach.
Above these constraints was questioned in August already (by User:Infovarius) and I don't think User:Lucas Werkmeister (WMDE) is ready to implement it.
As you don't seem to understand the editorial role of WMDE, I asked User:Lydia Pintscher (WMDE) to confirm it to you.
--- Jura 14:36, 4 January 2018 (UTC)
"oppose for the sake of opposing" is both false and intentionally inflammatory. Whether Lucas is allowed to "vote" or not, his logic, which I reiterate, is sound: "I really don’t like the thought of removing constraints just because one of the systems checking them is broken". Well, neither do I - there's no good reason for it. That's all the reason I or anyone should need to oppose this, and your dismissal of it doesn't strike it from the discussion. Swpb (talk) 14:43, 4 January 2018 (UTC)
I added a complex constraint to manufacturer (P176). I could also add that to the other 56 properties. Would it then be okay for you to remove it from property constraint (P2302) until the constraint is implemented in Special:ConstraintReport and the gadget? --Pasleim (talk) 20:02, 4 January 2018 (UTC)
Yes, that seems totally reasonable. Thanks for coming though with a solution! Swpb (talk) 20:06, 4 January 2018 (UTC)


Until it's available, maybe we could add statement to the properties indicating the item using the property and the values used by the properties should be contemporary in one way or the other. has quality (P1552) could be used to state that. Depending on how it's measured, we could use different values, e.g. by the lifespan of two people. Such item can also help design a future constraint.
--- Jura 11:13, 16 December 2017 (UTC)

Status future plans?[edit]

Symbol strong support vote.svg Strong support I strongly support doing this as we have so many discussions in sv:Wikipedia when we have Wikidata driven templates that the name used is not the name used at that time.... this constraint will help a lot....

FYI: I added the constraint to Church of Sweden parish code (P778) and then the Wikidata:Database_reports/Constraint_violations/P778 failed

ERROR: Unknown constraint type: Q25796498.

OT: we are cleaning the Swedish church parishes in WD in project wmse-riksarkivet-tora task T199784 and I guess the implementation of this constraint will impact how we model name changes etc. - Salgo60 (talk) 07:10, 11 August 2018 (UTC)

Hi, Salgo60, thanks for your support! I'm currently implementing this constraint for Special:ConstraintReport and for the warnings on the entity pages, although T195226 will be resolved first. The constraint should be ready in September, that is, next month. :D --abián 08:21, 11 August 2018 (UTC)
Abián (talkcontribslogs) Thanks for fast answer... we are modelling about 3500 church parishes see work area and all input you have please let us know. I asked a question at Wikidata:Project_chat for feedback - Salgo60 (talk) 08:37, 11 August 2018 (UTC)

constraint check bug[edit]

It currently compares the last date of end of validity of one item to the first date of validty of another item.

However an item A may have multiple properties specifying one value declared until end date just before another value declared starting on a next day.

In that case we cannot attach item C to item A and specify also similar (but not necessarily the same) couple of dates to declare distinct values, one of these values only being item A, the other being item B declaring other distinct dates of validity.

 item A:     ...--------------------+                          (end date only)
 item B:                             +--------------------...  (start date only)

Try to declare:

 item C:                  +-------------------+

this currently conflicts in:

                          ^---------^                          (wrong start selected)
                                     ^---------^               (wrong end selected)

and this should just check:

             ^...-----------------------------^                (OK)
                          ^------------------------------...^  (OK)

The implementation forgets that not all properties are bounding their dates of validty on both start and end (the other bound is unspecified and just means "anything before", or "anything after"), and that the presence of multiple dates in a referenced item does not mean they are bound to the same declared property of that referenced object.

Verdy p (talk) 02:01, 5 October 2018 (UTC)

Hi, Verdy p. I'm not sure I understand what you expose. Could you please provide an example using specific Wikidata entities and properties? Maybe you're just dealing with this bug concerning precision. Or you've found something else? Anyway, please let me know. Thanks! --abián 13:59, 5 October 2018 (UTC)

Different precision[edit]

This constraint should not trigger for dates with different precision where match is possible. E.g. if person A has date of death of 1850, and person B, son of A, has birth date of July 5, 1850 - this is not wrong since A may have died in August or December. Laboramus (talk) 08:18, 20 October 2018 (UTC)

This is due to T168379. --abián 22:39, 20 October 2018 (UTC)