Talk:Q25796498

Latest comment: 10 months ago by Vicarage in topic Different precision

Autodescription — contemporary constraint (Q25796498)

description: type of constraint for Wikidata properties: used to specify that the subject and the object have to coincide or coexist at some point of history
Useful links:
Classification of the class contemporary constraint (Q25796498)  View with Reasonator View with SQID
For help about classification, see Wikidata:Classification.
Parent classes (classes of items which contain this one item)
Subclasses (classes which contain special kinds of items of this class)
contemporary constraint⟩ on wikidata tree visualisation (external tool)(depth=1)
Generic queries for classes
See also


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)Reply

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)Reply

Removed from properties edit

As this breaks the constraint reports, I removed this from the 57 properties listed on https://www.wikidata.org/w/index.php?&oldid=609831868 . They can easily be re-added once support is available.
--- Jura 11:07, 16 December 2017 (UTC)Reply

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)Reply
All constraint reports with this constraint hadn't been updated in four months.
--- Jura 13:54, 20 December 2017 (UTC)Reply
I wasn't aware it worked with your gadget .. did it?
--- Jura 13:59, 20 December 2017 (UTC)Reply
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)Reply
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: https://www.wikidata.org/w/index.php?&oldid=609831868 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)Reply
  • 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)Reply
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)Reply
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)Reply
"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)Reply
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)Reply
Yes, that seems totally reasonable. Thanks for coming though with a solution! Swpb (talk) 20:06, 4 January 2018 (UTC)Reply

Contemporaneousness edit

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 characteristic (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)Reply

Status future plans? edit

  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)Reply

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)Reply
Abián 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)Reply

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)Reply

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)Reply

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)Reply

This is due to T168379. --abián 22:39, 20 October 2018 (UTC)Reply
Also, if A is the mother, she could have died at childbirth. If A is the father, he could even have died nine months before, in 1849. -Ash Crow (talk) 05:24, 10 February 2019 (UTC)Reply
You're right! mother (P25) and father (P22) aren't contemporary properties. You can see a list of truly contemporary properties on File:Restricción de coetaneidad - Trabajo Fin de Grado - David Abián.pdf, pages 51, 52, 53 and 54. However, sometimes editors want to have the constraint added to other properties to detect wrong data in most cases, although not all. In none of these cases the constraint should be added as a mandatory constraint (Q21502408). --abián 11:49, 10 February 2019 (UTC)Reply
Still a problem 5 years later where Nelson is flagged as an invalid participant at the Battle of Trafalgar (Q171416). The battle and his death date are to the same precision, but it merely reports the year being 1805 being incompatible with a battle on the 21 Oct 1805 Vicarage (talk) 22:25, 25 May 2023 (UTC)Reply
Return to "Q25796498" page.