Wikidata talk:WikiProject property constraints

On this page, old discussions are archived after 60 days. An overview of all archives can be found at this page's archive index. The current archive is located at Wikidata talk:WikiProject property constraints/Archive 2.

Interpreting replacement property (P6824) and replacement value (P9729) in the same constraint

1. When a constraint has both replacement property (P6824) and replacement value (P9729), should those be interpreted as applying to the same replacement statement, or two separate statements?

2. What is the right way to make the correct interpretation clear? Two separate constraints whenever two replacement statements are intended? A constraint clarification (P6607) on every constraint that uses both replacement property (P6824) and replacement value (P9729)?

3. Have the answers to 1 and 2 been established by consensus, and written down somewhere?

Examples:

• Here is a constraint where the replacement property (P6824) and replacement value (P9729) are meant to apply to the same replacement statement, and would produce nonsense if applied to separate statements.
• And here is one where the replacement property (P6824) and replacement value (P9729) are intended for two separate replacement statements, and would produce nonsense if applied to the same statement.

This query should show all constraints that have both replacement property (P6824) and replacement value (P9729). Swpb (talk) 15:21, 1 April 2024 (UTC)

A sense constraint for the parent lexeme

Lucas Werkmeister (WMDE)
Jarekt - mostly interested in properties related to Commons
MisterSynergy
John Samuel
Sannita
Yair rand
Jon Harald Søby
Pasleim
Jura
PKM
ChristianKl
Sjoerddebruin
Fralambert
Manu1400
Was a bee
Malore
Ivanhercaz
Peter F. Patel-Schneider
Pizza1016
Ogoorcs
ZI Jony
Eihel
cdo256
Epìdosis
Dhx1
99of9
Mathieu Kappler
Lectrician1
SM5POR
Infrastruktur
Samoasambia

Notified participants of WikiProject property constraints

The newly created Duden sense ID (P12641) has a subject type constraint. But this is a property for lexeme senses and the constraint is meant to be applied to the associated lexeme. What can be done here?– Shisma (talk) 08:08, 19 April 2024 (UTC)

@Shisma First of all I think this should preferrably be disccussed on [Property̜̙talkːP12641 the talk page corresponding to that property. Unfortunately,I seem to have forgot how to link to such pages,but I hope you can find it anyway.--̃-̃-̃-̃ SM5POR (talk) 15:10, 19 April 2024 (UTC)

Proposal: remove redundant ^ and $ from format constraints

Lucas Werkmeister (WMDE)
Jarekt - mostly interested in properties related to Commons
MisterSynergy
John Samuel
Sannita
Yair rand
Jon Harald Søby
Pasleim
Jura
PKM
ChristianKl
Sjoerddebruin
Fralambert
Manu1400
Was a bee
Malore
Ivanhercaz
Peter F. Patel-Schneider
Pizza1016
Ogoorcs
ZI Jony
Eihel
cdo256
Epìdosis
Dhx1
99of9
Mathieu Kappler
Lectrician1
SM5POR
Infrastruktur
Samoasambia

Notified participants of WikiProject property constraints

A query by dcausse (source) shows that there are some format constraints that are shared between many properties (e.g. [1-9]\d* is currently used 1279 times), and some of these common format constraints use ^ at the start and $ at the end. As far as I’m aware, using these assertions (aka “anchors”) in the format is unnecessary: the format is expected to match the whole value anyway (e.g. WikibaseQualityConstraints wraps the regex in ^$). To reduce the number of different formats we have, and keep the regexes easier to understand, I’d like to mass-change those formats to remove the ^$ where not needed (e.g. turn ^[1-9]\d*$, currently used 162 times, into [1-9]\d*). Does that sound okay to y’all? Lucas Werkmeister (talk) 17:26, 14 June 2024 (UTC)

•  Support —MisterSynergy (talk) 19:01, 14 June 2024 (UTC)
•  Support I agree. This is redundant. John Samuel (talk) 19:36, 14 June 2024 (UTC)
•  Support The linked phabricator ticket has a good reason for this change. Infrastruktur (talk) 19:55, 14 June 2024 (UTC)
•  Support I support this change. But before mass modification, each property should be checked to see if it contains other P1793 (even usefulness of this constraint). Many add an additional constraint without worrying about another constraint with another RegEx. ―Eihel (talk) 21:19, 14 June 2024 (UTC)
•  Support As redundant. --Fralambert (talk) 02:05, 15 June 2024 (UTC)
•  Support good idea. --99of9 (talk) 04:13, 15 June 2024 (UTC)
•  Support -- Regards, ZI Jony ^(Talk) 07:53, 15 June 2024 (UTC)

I put together some code for this and made a first test batch, does that look alright? (If nobody objects, I’ll probably start updating regexes tomorrow or so.) Lucas Werkmeister (talk) 16:08, 16 June 2024 (UTC)

Looks good. Can you mail me a copy of your shell history file? ^.^ Infrastruktur (talk) 18:58, 16 June 2024 (UTC)

…no? Lucas Werkmeister (talk) 20:48, 16 June 2024 (UTC)

(I’m not stupid enough to have put my password into the shell history anyway, but even so I’m very much not amused by an administrator(!) asking me to please compromise my account) Lucas Werkmeister (talk) 21:16, 16 June 2024 (UTC)

I wasn't implying, nor did I think you were unaware of the implications of handling user credentials in this manner. Nor would it necessarily matter that much for a personal script run on a personal computer, but it wouldn't be good practice if it was written for other users - hence my jokingly remark. Infrastruktur (talk) 22:48, 16 June 2024 (UTC)

•  Support --Jarekt (talk) 02:13, 17 June 2024 (UTC)

First real batch is now running: toolforge:editgroups/b/CB/aa10a6856bed Lucas Werkmeister (talk) 18:25, 17 June 2024 (UTC)

And already completed. Lucas Werkmeister (talk) 18:27, 17 June 2024 (UTC)

Second real batch (probably the largest one) is now running: toolforge:editgroups/b/CB/29f961a13362 Lucas Werkmeister (talk) 18:53, 18 June 2024 (UTC)

And done. Lucas Werkmeister (talk) 18:59, 18 June 2024 (UTC)