Template talk:Constraint

Integrate to Template:Property documentation edit

Good idea, but not really nice looking, and not very convenient to split it into smallish subtemplates. I think it should be integrated to Template:Property documentation. --Zolo (talk) 06:18, 1 May 2013 (UTC)Reply

See the discussion at Wikidata:Requests for comment/Property documentation. --  Docu  at 20:11, 19 May 2013 (UTC)Reply

Simmetric properties edit

Hi. Is it possible to have a symmetric check for two properties? For example if Qa is P:P155 of Qb, then Qb must be P:P156 of Qa. --Paperoastro (talk) 20:37, 13 May 2013 (UTC)Reply

Constraint "One of" and constellations edit

I'd like to use the constraint "One of" with the property P:P59 (constellation), but the constellations are 88. Is it possible to use a list so long? --Paperoastro (talk) 20:39, 13 May 2013 (UTC)Reply

Date edit

The property year of publication of scientific name for taxon (P574) should be constrained to between 1753 and the current year (2013 at the moment). Is this possible without using 260+ "one of" values? - Soulkeeper (talk) 11:43, 12 July 2013 (UTC)Reply

"Should not have statement" constraint edit

Can somebody add a template where certain statements are forbidden. --Tobias1984 (talk) 14:00, 5 August 2013 (UTC)Reply

  • Some medical properties are assigned to species (parasites) and historic events (plagues). This happend because some diseases infoboxes were not only used in the article of the disease but also in different places. If I could make a constraint that says e.g. "should not have stament" "taxon name" then I could find those pretty quickly. They don't really show up in the duplicates because that list is pretty cluttered from all the overlap of medical subjects. --Tobias1984 (talk) 14:34, 5 August 2013 (UTC)Reply

One property is not working edit

The bot does not update decay mode (P817) anymore Wikidata:Database_reports/Constraint_violations/P817. --Tobias1984 (talk) 09:53, 7 September 2013 (UTC)Reply

Apparently, there are no updates if only stats change, but not the number of constraint violations. If it is all fine => no change --  Docu  at 10:38, 7 September 2013 (UTC)Reply
So I need to add a wrong entry, so it will update the value statistics? --Tobias1984 (talk) 11:08, 7 September 2013 (UTC)Reply
Yeah, try it on some sandbox item and it should update tomorrow night. On the report page "The report is not updated if only the item count changes." was meant to explain this. Maybe you want to expand it. --  Docu  at 11:26, 7 September 2013 (UTC)Reply
There is another reason in this case: bot does not process qualifiers and refs at all. — Ivan A. Krestinin (talk) 13:05, 7 September 2013 (UTC)Reply
I didn't know that. Would that be difficult to implement? --Tobias1984 (talk) 14:51, 7 September 2013 (UTC)Reply
This is not simple task. Working with qualifiers and references is not so simple as with main value. Possible hardware upgrade will be needed die to additional volume of processed data. — Ivan A. Krestinin (talk) 19:24, 7 September 2013 (UTC)Reply
Thanks for the information. It is not a high priority task anyway. --Tobias1984 (talk) 19:31, 7 September 2013 (UTC)Reply

English language is harsh. edit

In the case that a user has a rare value that is legitimate, we were saying that they're contribution is "not desirable". Since it is my understanding that we are seeking to state what is, rather than what ought to be, I have changed the language to say that "exceptions are possible because rare values may exists". Maybe new values will expose how our modelling is biased. Maximilianklein (talk) 19:20, 17 October 2013 (UTC)Reply

It depends on the property. I do not think there should be any violaition of the "one of" constraint in IUCN protected areas category (P814). In other cases, the value might actually be very common but we forgot to add it in the template; I think we could simply have "exceptions are possible" and leave more specific explanation for individual property documentation or some other pages. --Zolo (talk) 06:33, 18 October 2013 (UTC)Reply

Extend Constraint:Item to subclasses of the item (or to one of a specified list of items)? edit

Please see Wikidata:Database reports/Constraint violations/P964#"Item type of administrative division (P132) = municipality of Austria (Q667509)" violations. The violations listed there all have the property P132 (P132), but not with the item municipality of Austria (Q667509), but with the item statutory city of Austria (Q262882) (a subclass of municipality of Austria (Q667509)), which makes sense. Is it possible to define a constraint that says "items with this property should also have P132 (P132) = municipality of Austria (Q667509) or a subclass thereof" (or a constraint that says "items with this property should also have type of P132 (P132) = one of municipality of Austria (Q667509), statutory city of Austria (Q262882)")? --UV (talk) 09:03, 1 November 2013 (UTC)Reply

Constraint: Is not edit

It would be useful to have possibility to say: This property should be only in items which are not in no-articles namespaces (not Wikipedia, not Template, not Category...) or only in items which have links only to Wikivoyage...

something like {{Constraint:namespace|allow=0, 100|disallow=4, 10, 14}} or {{Constraint:project|one of=wiki, quote|disallow=voyage, news}}

JAn Dudík (talk) 10:59, 29 November 2013 (UTC)Reply

Request for constraint: Use as qualifier/source edit

Some properties are always supposed to be used as qualifiers, never supposed to be used as qualifiers, always supposed to be used in source statements, or never supposed to be used in source statements. Having constraints for these would be useful, in my opinion. --Yair rand (talk) 19:53, 4 February 2014 (UTC)Reply

An example is IUCN taxon ID (P627). Should only be used in a reference to IUCN conservation status (P141). --Succu (talk) 21:32, 4 February 2014 (UTC)Reply
  Support --Tobias1984 (talk) 21:38, 4 February 2014 (UTC)Reply
  SupportWylve (talk) 18:09, 19 February 2014 (UTC)Reply

Request for constraint: Value is an integer edit

Numerous properties should only have integers as values, without margins of error or fractions. --Yair rand (talk) 20:31, 4 February 2014 (UTC)Reply

I think the usage of this constraint should be expanded to a general constraint on uncertainties. This allows uncertainties other than +/-0 to be restricted, like +/-1 or +/-2, etc. —Wylve (talk) 18:09, 19 February 2014 (UTC)Reply

Request for constraint: Has specific qualifier/Is qualifier of specific property edit

Certain properties are only used when qualified by/qualifying certain other particular properties, with neither being used elsewhere. --Yair rand (talk) 08:51, 11 February 2014 (UTC)Reply

Consideration of VIAF ID (P214) edit

At Property talk:P214 there is a conversation about whether VIAF identifiers should be able to have "No value" added if an entry has not been assigned. The issue being that we need a point of time check, and ability to track entries without an a VIAF though could have one at a later point at time.  — billinghurst sDrewth 05:47, 14 October 2014 (UTC)Reply

Incompatibility between exceptions and mandatory edit

@Ivan A. Krestinin: Why are they incompatible? The violation reports seem to work fine. There is a good reason for being able to use them together: To make sure that no new violations are created. If you don't mark a constraint as mandatory, it won't show in mandatory reports and the community will not patrol its violations. Petr Matas 06:17, 15 December 2014 (UTC)Reply

  • Hello Petr, constraints with exceptions are not strongly valid usually. Exceptions lists are incomplete usually. Single mandatory+exceptions constraint is not a problem, but 100 or 1000 such constraints will produce too many violations in future. This will made our primary report useless. It will not be cleared every day and it`s size will grow. — Ivan A. Krestinin (talk) 06:33, 15 December 2014 (UTC)Reply
    • Hello Ivan, some of them may be strongly valid nevertheless and they help a lot to spot errors. Furthermore, majority of mandatory violations are real errors, aren't they? I think that we should give it a try. If their false positive rate becomes too high, we can always make some of them not mandatory. Petr Matas 06:53, 15 December 2014 (UTC)Reply
    • The policy could be that whenever you encounter a new exception from a constraint, which has had multiple exceptions already, you will remove the mandatory flag. Petr Matas 07:04, 15 December 2014 (UTC)Reply
      • I understand that there is a little number of strongly valid constraints with exceptions. But the most number are not. "Without exceptions" scope is easily defined and controlled. But border "well constraint with exceptions / bad constraint with exceptions" can not be defined. This will produce errors when bas constraint will be marked as well. Removing mandatory flag will have negative reaction from user who set up the flag. Lets assume, we allow mandatory+exceptions, ~100 constraints was marked, the report is spammed by new and new violations. Reverting scope to "no exceptions" border will not be possible because negative reactions for removing single mandatory flag * ~100 constraints will need long discussion using RfC. So attempt to try is really impossible. — Ivan A. Krestinin (talk) 08:17, 15 December 2014 (UTC)Reply

Request for number unit constraints edit

It would be useful to have constraints regarding what units can be used with a property. For example, length (P2043) could be constrained to only use items with value type unit of length (Q1978718). Other properties could be constrained to use no units. --Yair rand (talk) 23:08, 10 September 2015 (UTC)Reply

text-align edit

I changed

<div style="background-color:{{#if:{{{mandatory|}}}|#DDFFFF|#FFFFFF}}; border: 2px solid #CDDDDD; padding: 3px;">

into

<div style="background-color:{{#if:{{{mandatory|}}}|#DDFFFF|#FFFFFF}}; border: 2px solid #CDDDDD; padding: 3px; text-align:{{LangSwitch|ar=right|en=left}}; float:{{LangSwitch|ar=right|en=left}}; width:100%;">

to make the text-align:right in Arabic. Is that correct? --Mr. Ibrahem (talk) 16:03, 26 February 2016 (UTC)Reply

@Mr. Ibrahem, Matěj Suchánek, Laddo: float:(left|right); seemingly causes problems, do we need that? It was inserted a few days ago, and now the first section heading below a constraint box is no longer displayed properly. (via Wikidata:Forum#Abschnittsüberschrift verschluckt)MisterSynergy (talk) 21:23, 1 March 2016 (UTC)Reply

Check ID against check rule edit

Some IDs have a check digit which allows to be sure that the ID is correctly written. As example for CAS Registry Number (P231), we have that check rule. Can we create a constraint report for that kind of check ? The check equation if different for each ID so we need to have some flexible user constraints. Examples of ID with check digit: CAS Registry Number (P231), ISBN-10 (P957), ISBN-13 (P212), ISSN (P236), IMO ship number (P458). Snipre (talk) 15:46, 2 August 2016 (UTC)Reply

It's not a good idea to have violations reports, we must integrate these constraints as a part of the software and prevent any violation. The case that you're describing is controlled by the abuse filters, eminently maintained by Matěj Suchánek. --abián 16:07, 2 August 2016 (UTC)Reply
See also Wikidata:Project_chat#Check_digit. --abián 16:14, 2 August 2016 (UTC)Reply

Template help needed edit

I've proposed another template, modelled on this one, for "Humans with missing claims" reports. Please see Wikidata talk:Database reports/Humans with missing claims#Talk page template if you can help. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 16 October 2016 (UTC)Reply

Constraint:Qualifiers and novalue statements edit

Is it possible to require the qualifiers only for statements with a real value? Example of the problem: Wikidata:Database reports/Constraint violations/P3250.--AVRS (talk) 08:58, 7 November 2016 (UTC)Reply

Request for constraint: Unique value per namespace edit

I would like to request a tweak of {{Constraint:Unique value}} which would allow unique value per namespace, or unique value among article items and/or unique value among category items. Intended use would be Commons category (P373) and Commons gallery (P935) which at the moment have 200k violations. Most violations are because of the way people are using those properties and it is easier to fix the query than to fix all those items. At the same time two article items or category items should not link to the same category and such cases should be detected. If we want to get very fancy we can also check if the article and category items are linked through topic's main category (P910) and category's main topic (P301). --Jarekt (talk) 21:30, 21 February 2017 (UTC)Reply

Migration from templates to properties edit

Hello, I will start migration shortly. Please notify me if something is not ready. — Ivan A. Krestinin (talk) 20:19, 29 April 2017 (UTC)Reply

Good news! --Marsupium (talk) 10:17, 30 May 2017 (UTC)Reply
@Lucas Werkmeister (WMDE): Do your code ready? — Ivan A. Krestinin (talk) 18:42, 30 May 2017 (UTC)Reply
@Ivan A. Krestinin: um, no, not yet… when is “shortly”? I think we’ll need a few more weeks.
I set up a test wiki at https://wikidata-constraints.wmflabs.org/, feel free to use that for testing if it’s useful to you. --Lucas Werkmeister (WMDE) (talk) 11:32, 31 May 2017 (UTC)Reply
It is not simple task to create full infrastructure on this site. I prefer testing using Sandbox-Item (P369) and read-only simulation. My code is ready for migration. I can start the migration now. If your code is ready of course. Or if you prefer adapt your code after migration. — Ivan A. Krestinin (talk) 18:38, 31 May 2017 (UTC)Reply
Well, if you start the migration now, I think people will be confused that constraint statements work on the database reports page but not in the user script… can we wait for a few more weeks and then do a proper announcement and all? --Lucas Werkmeister (WMDE) (talk) 11:11, 1 June 2017 (UTC)Reply
As I know your code uses caching for constraints. Could you disable the cache update for now? Your script will use cached version of constraints until new reading code is not ready. — Ivan A. Krestinin (talk) 16:34, 1 June 2017 (UTC)Reply
It’s not really a cache, at least not one we can turn off… we just re-run the import (manually) every few months. I don’t think we plan to do that before the migration (i. e., it probably won’t happen again at all), but still, I think it would be very confusing if people started using constraint statements and the changes didn’t affect what the extension does.
Can you please just wait a few more weeks? It shouldn’t take too long – one or two weeks for the implementation, and then one or two more weeks for deployment. Once the implementation is done, we can do an announcement (“we will enable this on day X”), which will probably also include a link to the test system where people can play around with it. --Lucas Werkmeister (WMDE) (talk) 17:09, 1 June 2017 (UTC)Reply
Ok — Ivan A. Krestinin (talk) 17:43, 1 June 2017 (UTC)Reply
@Lucas Werkmeister (WMDE): Now I making final preparation. The migration script will be run today. — Ivan A. Krestinin (talk) 18:10, 12 July 2017 (UTC)Reply
Thanks! Unfortunately, we didn’t have a deployment this week due to build problems, so we’ll turn on constraint statements Thursday next week, but it’s good that constraint statements are already available now. --Lucas Werkmeister (WMDE) (talk) 14:40, 13 July 2017 (UTC)Reply
All templates had been migrated now except two cases:
  1. [1] - {{Constraint:Format}} with long patterns (more than 400 symbols). We need to extend or remove some wikidata core limitations.
  2. [2] - {{Constraint:One of}} with string items. Additional property is need to be created for this case.
Ivan A. Krestinin (talk) 07:19, 17 July 2017 (UTC)Reply
@Ivan A. Krestinin: For the remaining “one of” constraints, I already created phab:T165152 a while ago. It’s probably better to model these as “range” constraints with an additional (to be added) “integer” constraint, instead of adding support for non-item values to the “one of” constraint. --Lucas Werkmeister (WMDE) (talk) 09:07, 17 July 2017 (UTC)Reply
Earlier we had interesting case: {{Constraint:One of|values=1, {{overline|1}}, 2, m, 2/m, 222, mm2, mmm, 4, {{overline|4}}, 4/m, 422, 4mm, 42m, 4/mmm, 3, {{overline|3}}, 32, 3m, {{overline|3}}m, 6, {{overline|6}}, 6/m, 622, 6mm, 6m2, 6/mmm, 23, m3, 432, {{overline|4}}3m, m{{overline|3}}m}} for Hermann-Mauguin notation (P1632). — Ivan A. Krestinin (talk) 20:19, 17 July 2017 (UTC)Reply

Requests: Integer value and No bounds edit

As already requested by @Yair rand, Wylve: in #Request for constraint: Value is an integer in Feb 2014 on this page, I’d like to see two more constraints for Quantity data type properties:

  • Integer value for properties that only allow integer values, such as population (P1082). I had to fix around 350 mistakes yesterday only for this property. The main reason for mistakes is confusion about a “thousands separator”: an input of 123.456 does not and should not automatically convert to 123456.
  • No bounds for properties that are non-physical quantities without uncertainty. This is in fact a substantial fraction of our quantity properties. Since use of bound indicates uncertainty and we cannot use novalue for bounds, we need to indicate the absence of uncertainty by using no bounds at all, rather than ±0 bounds.

Thanks, MisterSynergy (talk) 06:12, 9 June 2017 (UTC)Reply

There’s already a task for an “integer” constraint, phab:T167989. Feel free to add one for “no bounds” too – sounds useful. --Lucas Werkmeister (WMDE) (talk) 14:41, 13 July 2017 (UTC)Reply
Thanks; there is now phab:T170610 as a request for “no bounds”. —MisterSynergy (talk) 17:33, 13 July 2017 (UTC)Reply

Mandatory constraints with exceptions edit

I think it should be possible for a mandatory constraint to have exceptions. In the WikibaseQualityConstraints extension, the constraint status (mandatory or not) is interpreted as a severity of a constraint violation: violations of mandatory constraints are more serious than violations of non-mandatory constraints. But that doesn’t mean that the constraint can’t have any exceptions: the real world is messy, and even constraints that should, by all rights, always hold might have a handful of exceptions.

Currently, there are six properties with mandatory constraints with exceptions (query), and they all have an ugly error message on their talk page because this template declares that "exceptions" is incompatible with "mandatory" parameter. Can that error condition be removed from the template? Ping Ivan A. Krestinin. --Lucas Werkmeister (WMDE) (talk) 15:56, 17 August 2017 (UTC)Reply

None of these are really convincing. I just fixed the three Australian ones. Personally, I'd stick to the current approach: it should either have no exceptions or not be mandatory. Obviously, it all depends on people's approach to exceptions ..
--- Jura 17:54, 17 August 2017 (UTC)Reply
Well, the current approach of the extension is to support mandatory exceptions with constraints, so “stick to the current approach” doesn’t really work IMO. It’s also hardly surprising that there aren’t many convincing examples for something that currently isn’t allowed by the template… but consider, for example, a constraint “date of death must be after date of birth” (diff within range  ). That constraint could have one or two exceptions (fictional time-travellers), but that doesn’t mean it shouldn’t be mandatory for every single non-fictional human ever :) --Lucas Werkmeister (WMDE) (talk) 19:22, 18 August 2017 (UTC)Reply
BTW, can you add support for separator (P4155)? It would reduce the number of exceptions.
--- Jura 18:00, 17 August 2017 (UTC)Reply
Sure, phab:T173594. Perhaps you can open a task right away next time? I didn’t see the property proposal at all. --Lucas Werkmeister (WMDE) (talk) 19:22, 18 August 2017 (UTC)Reply

Explanation parameter edit

It would be helpful if the constraint subtemplates would include an additional parameter that could be filled with an explanation, links to more info or to community decisions, etc, related to the specific transclusion of that template.

For example, the talk page of title (P1476) has several discussion threads about the single value constraint, which show many people who assumed it would be logical to encode titles in various languages in that property, using qualifiers to specify the language; instead, the current consensus seems to be to use has edition or translation (P747) instead. In other words, the current arrangement is generating some friction among editors who are not aware of the convention.

It would be convenient for editors if this information was provided either as an extra parameter in {{Constraint:Single value}}, or as a qualifier ("motive"? "reason"? "explanation"? "details"?) of the "single value" constraint of the title property.

Please let me know if this is not the right venue to discuss this, or if it has been discussed elsewhere. --Waldir (talk) 16:24, 9 September 2017 (UTC)Reply

Update: I just came across Wikidata usage instructions (P2559), which I had forgotten about. It seems to fit the bill for a qualifier for constraints. I've added it to the list of allowed properties of property constraint (P2302), but this now raises the question of whether it overlaps with syntax clarification (P2916), which was already there. Should we disambiguate them by clarifying their descriptions, or perhaps merge them? --Waldir (talk) 18:18, 9 September 2017 (UTC)Reply

syntax clarification (P2916) is specifically for explaining a regular expression, or other things where some syntax (like the regular expression syntax) needs to be explained. Wikidata usage instructions (P2559) is for more general explanations. But also, as far as I know, Wikidata usage instructions (P2559) should be used as a main statement on the whole property, not as parameter of one particular constraint. I’m not sure if it’s good to have it on constraints as well. --Lucas Werkmeister (WMDE) (talk) 10:13, 11 September 2017 (UTC)Reply
Ah thanks -- that makes sense and explains the ambiguity. Should we then rename syntax clarification (P2916) to "regex explanation" or "regular expression explanation"? That would make it more explicit what it is about.
As for adding Wikidata usage instructions (P2559) only as a main statement in a property, could you expand a bit on what in your view could be the downsides of the extended usage I proposed? And if we're to make such a restriction, how else would you suggest resolving the issue of documenting the reason / rationale for a given constraint? --Waldir (talk) 15:56, 11 September 2017 (UTC)Reply
I’m not sure if syntax clarification (P2916) should be renamed – some other project (independent of property constraints) might also be using it…
For Wikidata usage instructions (P2559) – you’re probably right that some kind of explanation for a constraint is needed (some already exist – syntax clarification (P2916)For Twitter usernames, use P2002 on a hashtag (P2572) format constraint isn’t really an explanation of the format), I’m just hesitant whether Wikidata usage instructions (P2559) is the right property for it – I feel like it’s not always about the usage of the property. Perhaps a new property should be proposed? --Lucas Werkmeister (WMDE) (talk) 13:12, 22 September 2017 (UTC)Reply
Sorry I haven't had the time to reply properly. I just wanted to invite @Sjoerddebruin to this discussion, due to this edit. --Waldir (talk) 13:33, 28 September 2017 (UTC)Reply
Re-reading the discussion above (and thanks to the ping at Wikidata talk:WikiProject property constraints#Adding explanations for constraints), I think I understand better what you mean: when a statement has a constraint, the constraint comes in the form of a property-value pair; but this property isn't always used in the context of a constraint, so a Wikidata usage instructions (P2559) included in the property page would be wrong to provide constraint-specific usage instructions, as these wouldn't be valid in non-constraint usages -- this would call for a new property, as you said (say, something like "Wikidata constraint rationale").
On the other hand, properties typically have self-explanatory labels, so a "Wikidata usage instructions" would only be useful as a disambiguation note than as a basic description of their use. And these disambiguation notes tend to mention the context where they are applicable, so in cases where the note doesn't apply, it wouldn't confuse editors. Besides, since different properties require different types of disambiguation/clarification, it seems appropriate to me to use that as a free-form text field with context-sensitive content, rather than a data-like field with a very specific meaning.
Considering that the latter approach is also simpler to implement, I'm inclined to favor it instead of the former. What do you think? --Waldir (talk) 13:16, 15 December 2017 (UTC)Reply

"Single value violations" ignores distinguishing qualifiers edit

The section "Single value" violations seems to completely ignore separator (P4155) qualifiers of single-value constraint (Q19474404) value in the property constraint (P2302) statements. Validly distinguished values should be not considered as "violations" but at most as special cases requiring special monitoring. Cases of non-differentiated duplicate values (real violations) should be listed separately. --ŠJů (talk) 18:48, 29 August 2021 (UTC)Reply

Return to "Constraint" page.