abian added a comment.

All other constraints store settings as qualifiers on property page. I think it is good practice make all constraints as similar as possible. This makes implementation and understanding of full constraints system easier.

This is actually a similar case to the one of P31/P279, and not so similar to the rest of constraints: we don't want to define information about the properties having the constraint, but about what property in Wikidata represents something.

We have two trivial parent properties, P580 and P582, whose URIs are, presumably, stable and won't change, as if they were P31 and P279. Knowing P580 and P582, and knowing that P1647 is the equivalent of P279 for properties, we can also load all the corresponding subproperties (two sets that can change, generally grow up). This keeps a correct ontology, avoids duplicating a lot of information (repeating the same qualifiers between properties, repeating which the subproperties of P580 and P582 are, etc.), avoids inconsistencies, makes maintaining the constraint easier and saves some effort to the community by not having to update anything related to the constraint when a subproperty of P580 or P582 is created, defined or deprecated.


TASK DETAIL
https://phabricator.wikimedia.org/T141859

EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: abian
Cc: Ivan_A_Krestinin, PokestarFan, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Wikibase-Quality-Constraints, abian, Aklapper, GoranSMilovanovic, Soteriaspace, JakeTheDeveloper, QZanden, Agabi10, Izno, Wikidata-bugs, aude, TheDJ, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to