This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Latest comment: 6 years ago2 comments2 people in discussion
@Pigsonthewing: do you think it’s necessary to sort the list of constraint types alphabetically? I don’t really like how similar constraints (symmetric/inverse, type/value type, range/diff within range, …) are now away from each other, and that the list starts with two “see also”s instead of real constraint types. I’d prefer to sort the list in a more (subjectively) useful way, starting out with easy-to-understand and common constraint types. --Lucas Werkmeister (WMDE) (talk) 09:17, 21 May 2017 (UTC)
@Ivan A. Krestinin: Well, the Format constraint is currently not implemented at all (it’s possible to craft regexes that take an extremely long time to run, and if we just use PHP’s regex function we can’t put a timeout on that), so for now I would suggest not migrating those constraints and keeping them on the talk page.
We don’t know yet how we’re going to implement the Format constraint, but it’s possible that the solution will be to use some less-powerful flavor of regular expressions, in which case some existing constraints might be broken anyways.
Also, IMHO… that particular constraint should just be removed. If we really want to hard-code a full list of all Stack Exchange tags – which I think is a terrible idea, since we can’t possibly provide a full and complete list – then surely that should be “One of”, not “Pattern”, right?
I’ll discuss this with some of the other devs, but I might not get the opportunity to do that before next Monday, because I’m at WikiCite and most of the other devs are back in the office. --Lucas Werkmeister (WMDE) (talk) 17:22, 22 May 2017 (UTC)
Latest comment: 6 years ago2 comments2 people in discussion
@JakobVoss: I think the section on custom constraints needs to go somewhere else. It’s currently under the warning that “the following sections refer to a future implementation” (i. e., reading constraints from statements on properties), but we have no plans to implement that constraint in the WikibaseQualityConstraints extension (and I’m not sure how we would do it, since it’s not a constraint that is checked per-entity). --Lucas Werkmeister (WMDE) (talk) 10:27, 29 May 2017 (UTC)
It will make sense once the warning is gone. If there is more content we could link to another help page, but to start with it is enough telling that one can use SPARQL for data analysis to evaluate any kind of custom constraints. -- JakobVoss (talk) 11:05, 29 May 2017 (UTC)
How do you do this?
Latest comment: 6 years ago5 comments2 people in discussion
Nice gadget.
I am wondering where the highlighted constraints come from. Do you have a constantly updated database of violations somewhere in the backgroud, or do you evaluate all constraints on the fly when I open an item page? If so, is the evaluation done server-side or client-side?
Thanks, very clear. It immediately brings up another question: does this scale in a way that it could somehow be included in the query service? Use case: define a set of items and list all constraint violations to improve these items; from the perspective of a topical editor this is more useful than covi pages (single property perspective) and this gadget (single item perspective). —MisterSynergy (talk) 15:42, 13 June 2017 (UTC) Please note: ping only works if you add a fresh signature in the same edit.
That depends… some statistics on the extension is available on Grafana, and as you can see, there are constraints that take a while to run – but those are just “Type” and “Value type”, and we’re soon going to deploy a change that checks those constraints using SPARQL instead of loading up to 1000 entities from the database and parsing and processing them all in PHP, which should speed them up by a lot. We also soon want to turn the user script into a gadget, which will hopefully result in more people using it, so in a few weeks we should have a better idea of how expensive constraint checks are, and whether it would be a good idea to put together a tool that gets a lot of items via SPARQL and then checks constraints on all of them. --Lucas Werkmeister (WMDE) (talk) 15:51, 13 June 2017 (UTC) yay for making noob mistakes under a (WMDE) account! thanks :)
Okay thanks for your impression. Since this topic is also about the query service, maybe User:Smalyshev (WMF) can also add input here (or at least hear about the idea to include a constraints check there). From my point of view a new constraints service (akin to the label service or the new Mediawiki API service) seems to be the simplest idea, but I honestly do not have much idea how the query service looks internally :-)
Latest comment: 6 years ago1 comment1 person in discussion
There should be a constraint that specifies that the property should only be used as a qualifier for a particular property or properties. Numerous properties are only supposed to be used as a qualifier for one property. --Yair rand (talk) 22:49, 20 November 2017 (UTC)
Thanks for an excellent tool
Latest comment: 6 years ago1 comment1 person in discussion
This tool ""Check constraints"" is what is needed I really like the explanations and also the suggestions...
but we need also to discuss how things are implemented and I guess we need to have region/language specific discussions...
What I have seen so far trying to move this subject in the right direction is...
Now when activating "Check constraints" I get 100:s of rules violations and as I see it error because of
The definition on the property needs to be changed
How a property should be used is a moving target that will be redefined but we need a documented concensus and change management
We will have language variants that is best discussed locally with domain experts
as this is complex maybe we need a tool like Phabricator to get better traceability
Lack of semantic knowledge
Correct semantic description of a object is difficult and its a learning process e.g. yesterday I tried describe an administrative unit in Sweden Stockholm Cathedral Parish (Q10680577) see graf and run into problems describing that this unit was created from 3 other units ==> I get error on d:Q10680577#P155
I feel this is when Wikidata is as best but this is complex from a semantic point of view plus also needs to be combined with domain expertise and how to move this forward....
phabricator:T168626 proposes checking constraints before saving statements in the wikidata.org UI. The underlying API could then also be used by external import tools. (I just updated the task descriptions to add some more information in that direction.) --Lucas Werkmeister (WMDE) (talk) 15:39, 16 December 2017 (UTC)
In the case of your example, an import preview tool shouldn't complain in a way that discourages data from being added. Adding the data with the same rank is exactly the intended behavior. ChristianKl (✉) 16:44, 16 December 2017 (UTC)
Handling nonmandatory constraints
Latest comment: 6 years ago2 comments2 people in discussion
I'm not sure about the current usage of nonmandatory constraints. The often suggest that there would be some data that would be nice to have. related property (P1659) having a constraint that suggest that the linked property should have Wikidata property example (P1855) is one example.
At the beginning I think we create constraints like that to have worklist about where we can improve. There wasn't a decision intention that related property (P1659) should only be added when the target property has Wikidata property example (P1855).
When Salgo60 argues that data importers are doing something wrong when they add additional date of death (P570) values without labeling any of the values "preferred rank", I think that suggests that it's easy to understand the nonmandatory constraints in a way they weren't intended.
One way to solve this problem is to rewrite the text that gets shown when the "single value constraint" is violated when it isn't mandatory. It might be good if it doesn't use the world should but states something along the lines that it would be good if one of the multiple values would get a preferred rank.
It's worth noting that original wording says "this property generally contains a single value" and contains no should. ChristianKl (✉) 17:24, 16 December 2017 (UTC)
Latest comment: 6 years ago11 comments2 people in discussion
The definition list is a scary to translate. I propose to replace it eventually by the following code, in which :
the translation of the big definition list that was to be translated as a whole is splitted into smaller translation unit, and splitted into the term and its definition ;
the pattern « see ref» has been extracted to a template {{Glossary ref}} and is left out of the tranlate tags ;
the bold triple quote wikitext is removed because in a definition list default CSS, the defined term is bolded. Except in the case where there is aliases (eg. source / used as reference)
Some question remains for this plan to work however.
Some keywords are translatable with the « int: » sytax on mediawiki, for some predifined string for translation like « qualifier » who can be translated by {{int:qualifier}} to give « ⧼qualifier⧽ » through translatewiki’s translation. Will one day constraint name like « one of » be on translatewiki ? Is the constraint extension a gadget or some PHP ext ?
should we translate the defined terms ? If so, then the {{Glossary ref}} content should as well be translated. If the answer to the first question is « yes », then it will be possible to replace it with {{Glossary ref|{{int:one of}}}}. If no, it may be useful to enrich the collection of term translation template and create {{Int one of}} and its cousins, as the translation can be factored in one place. Of the other hand if the defined terms are not translated and we keep « one of » in all languages for simplicity, we don’t have to translate neither the terms nor the « see … » references.
As I know some contributors think this kind of code that ease translation of pages makes it too complicated to edit I don’t do it by myself and I wait for comments. author TomT0m / talk page16:38, 19 January 2018 (UTC)
Hi! First off – splitting the huge block, and using {{Glossary ref}}, definitely makes sense. I’m also not sure why we bolded the terms explicitly – as far as I can tell, even in source / used as reference it’s not necessary, so we could remove it there as well, right?
For translating the constraint type names, I don’t think the int: syntax is the right solution. We already have items for each constraint type, which have labels in several languages, and often that label is in fact easier to understand than the name that we use here sometimes (which is based on the old {{Constraint}} templates): for instance, allowed qualifiers constraint is way better than Qualifiers. So I think we need to rethink the relationship between those names, and which ones we want to use on this portal in the first place. Perhaps we can just always use the constraint item’s label in the list?
(To answer your question, WikibaseQualityConstraints is a MediaWiki extension, and it includes a ResourceLoader module which implements the gadget that you can use on Wikidata. The actual checkConstraints gadget here does nothing except loading that ResourceLoader module. As part of that extension, violation messages for all the constraint types are on TranslateWiki (e. g. translatewiki:MediaWiki:wbqc-violation-message-type-instance/qqq), but there are no separate messages for the constraint type names: constraint types are represented by Wikidata items, so we use the labels of those items to refer to the constraint types.)
@Lucas Werkmeister (WMDE): I forgot about the possibility to use translated items (although I think I used it in some of my «Int …» templates). It’s fine but for external reuse by non english speaker on the extension, it would make sense to store the names on translatewiki. I guess this would allow to have translated constraint without any explicit reference to Wikidata. And for consistency beetween the help page and what people will read on reports (the extension does not use item labels to print the constraint names, right ?) author TomT0m / talk page18:29, 20 January 2018 (UTC)
@TomT0m: the extension does not use item labels to print the constraint names, right ? – yes, that’s exactly what it does :) and if the extension is installed on other wikis, then they will have local versions of those items, either using the same labels (the README file contains instructions to import the items from Wikidata) or using different ones, whatever the local users prefer. --Lucas Werkmeister (WMDE) (talk) 12:00, 22 January 2018 (UTC)
@TomT0m: Thanks! Looks good in general, just a few questions:
Are the queries necessary, both of them? I’m not sure even one is required, and the second one feels mostly like a duplicate.
What is the purpose of the third parameter to the {{Label}} template? As far as I can tell, the template doesn’t use it – is it just to help out translators when looking at the wikitext?
Oh, and, yes, the second parameters on the « label » templates is just to document the item id in Wikitext. I don’t speak Qids fluently, and I guess few of us does :) author TomT0m / talk page12:26, 29 January 2018 (UTC)
I propose to identify the 3 values to part of the wikibase model statement. That is rename constraint checked on main value (Q46466787) « Statement main value », putting statements
I think the notions applies very well as values of the parameters and that there is no reason that those items are « special ». author TomT0m / talk page16:43, 9 February 2018 (UTC)
@Lucas Werkmeister (WMDE): I see no real rationale behind the opinion, I can read only @Yair Rand:’s one. A detail of course, but it add work to translate and has kind of cryptic label. I prefer my model also, because the scope is actually a part of statement (qualifier’s snak, references) and not the properties. author TomT0m / talk page16:59, 9 February 2018 (UTC)
@TomT0m: I have to disagree on the cryptic label part – I fear that constraint scope is not easy to understand just from the property label of P:P4680 alone, so I’m very happy to have the extra “constraint checked on” in the label of the special values. And IMHO this extra clarity is worth a bit more translation work. For the last part of your comment, I don’t understand what you mean, sorry… --Lucas Werkmeister (WMDE) (talk) 14:37, 12 February 2018 (UTC)
Since the gadget’s “help” link goes to the subpages for individual constraint types, and people who follow that link might not be familiar with the constraints system yet, I’ve added a header template to those pages to add a hint that they can look at the general help portal for more information. Feel free to improve that header! I’m not a {{Box}}/{{Mbox}}/… expert :) --Lucas Werkmeister (WMDE) (talk) 12:16, 26 February 2018 (UTC)
Constraint violation and item redirects
Latest comment: 6 years ago10 comments5 people in discussion
@TomT0m: to be honest I’m not sure what Matěj Suchánek was referring to… I guess this behavior would vary by constraint type? And I’m not sure if something should be fixed here anyways – personally, I agree with Matěj that redirect values in statements should not be kept forever, so I’m not sure if it’s a problem that some constraint checks report inaccurate results until the statement has been updated. But I admit I haven’t seen any cases like that myself, so I don’t know how this looks in practice. --Lucas Werkmeister (WMDE) (talk) 12:35, 14 March 2018 (UTC)
In practice, they are updated after a few days so it hasn't really been much of an issue. Lately, reports take longer to generate so maybe more people notice. --- Jura12:40, 14 March 2018 (UTC)
@Lucas Werkmeister (WMDE): « I guess this behavior would vary by constraint type? » ??? I can’t see why ? The whole point is that the items refers both with the same topic. Just substitute the value of a redirected item to the target item before checking the constraint, or something like that (or like I said, recheck if a violation is found with potentially redirected items if a violation is found to avoid some substitutions when there is no problem.)
If redirects were not to be handled by the official Wikidata tools, there was no point in implementing them … It’s half baked. « OK we provide redirects but nothing works with them ». Seriously ? We better had the merge a thing that has to be done by the admins. author TomT0m / talk page12:47, 14 March 2018 (UTC)
@TomT0m: I assume that this behavior would vary by constraint type because I’m still not sure what exactly “handling redirects” entails. On the one end of the spectrum, we have constraint types like used for values only constraint (Q21528958). That constraint type doesn’t even read any data (it just tests if it’s being checked on a main snak, qualifier, or reference), so what should we do with redirects there? As far as I can tell, this constraint type doesn’t need to worry about them. On the other end of the spectrum sits value-type constraint (Q21510865) – in this case, full redirect handling presumably means to follow redirects when resolving the value of the statement, follow redirects when following its instance of (P31) statements (if the constraint has relation (P2309)instance of (Q21503252)), follow redirects when following all subclass of (P279) links on other items, and finally, when we fall back to SPARQL, adding /owl:sameAs? to all the property paths as well – or should that be /owl:sameAs+? How many levels of redirects should we follow anyways? Oh, and what about the constraint statements themselves – should we follow redirects when reading the property constraint (P2302) statement? I should hope there aren’t any redirects to constraint type items, otherwise something very strange would be going on.
Until I know what the actual problem is, I can’t even begin to answer these questions – constraint reports do not handle redirects is not enough information for me, sorry. --Lucas Werkmeister (WMDE) (talk) 13:38, 19 March 2018 (UTC)
« Until I know what the actual problem is, I can’t even begin to answer these questions » @Lucas Werkmeister (WMDE): Mmm I can’t be really satisfied with this answer. I posted here to answer my own question and Matěj Suchánek’s claim that constraint’s violation can’t handle redirect, and I got a non answer :/ Some background : https://meta.wikimedia.org/wiki/Wikidata/Development/Entity_redirect_after_merge Why did you (the devteam) implemented this feature in the first place ? I recall that we feared that item merge would be a concern to unmerge before it was done. The issue we actually have is that they are still a concern to unmerge because tools can’t really handle them so people make bot running to substitute the value of a redirect with the value of the target of the redirect, and after this it become way harder to cancel the merge. So the issue is general and should not depend on the constraint or whatever : redirected items values should be kept as their original value in the raw database, but Wikidata tools should handle them « as is » they were the final target value (for a chain of redirects). It should be easy to unmerge and we should not have to run bot to make substitutions that breaks that undoing for any tool around Wikidata to work as expected. The constraint system should treat any item value as if it was the target of a chain of redirects whenever the redirect is encountered. I understand you can’t decide it yourself, it’s a design question for the whole devteam @Lea Lacroix (WMDE):. An idea for the query engine would be to preprocess the items values and use the redirected targets and never the redirects in the RDF statements, except for the « same as » statements of course. No query would be broken, except if the redirected item id is hardcoded in the query. This would restore a kind of « unique name assumption » in the RDF dataset. On the other hand on the backend side, if Q42 becomes a redirect to Q422 and we have an existing statement « Q1 P31 Q42 » it could be left as is in the Wikidata base dataset to make the merge undoing natural. The only problem would be to handle the statement created with Q422 after the merge if is was not a good merge, as it can’t be decided for them if Q422 would meant to be actually Q42. And to propagate the unmerge to the RDF export and to the query engine.
I did not know the type constraint handled subtypes, this is actually a (pleasant) surprise. But of course if you assume any item can have several names, the equivalent sparql path would become something like « owl:sameAs*/(wdt:P31/owl:sameAs*)/(wdt:P279/owl:sameAs*)* » if we are to handle redirect as synonyms of their target value (and you don’t use the substitute before export trick). actually for any « / » path chain, say « a/b/c », I guess a general sparql trick non assuming UNA would be to transform it to « owl:sameAs*/(a/owl:sameAs*)/(b/owl:sameAs*)/(c/owl:sameAs*)* » author TomT0m / talk page15:30, 19 March 2018 (UTC)
Hey :) It'd be super useful to have some examples as Lucas said where this has caused a problem. Because I tried to write a ticket for it but there are quite a few open questions that I can't answer yet without looking at some concrete cases. Sorry! Do we have some somewhere? --Lydia Pintscher (WMDE) (talk) 19:17, 19 March 2018 (UTC)
Comment My claim about malfunctioning constraints was based on observating those handled by bot. If a statement linked to a redirect, "value type" and "target requires claim" would always be marked as error. I don't know if something has changed since then. The statement on WDQS was based on observation that ?a wdt:P123 ?b (with ?b defined previously) does not resolve if there's a redirect. Matěj Suchánek (talk) 19:08, 19 March 2018 (UTC)
OR type constraints ?
Latest comment: 6 years ago2 comments2 people in discussion
Latest comment: 5 years ago3 comments3 people in discussion
The page says constraint violations can be made visible activating "checkConstraint" gadget, but I can't manage to find it. Should the poage be updated?--Malore (talk) 15:14, 25 April 2018 (UTC)
Latest comment: 5 years ago1 comment1 person in discussion
As test, I added new sections to Help:Property constraints portal/Single value. (diff). Newly added sections are three, 1. Examples, 2. Template, 3. Lists. And 4. page was categorized into Category:Properties with single value constraints. My intention is to make the page more helpful for many readers. If this style is OK, I'm planning to do same style edit toward other constraint help pages. If there are problem, idea, question, concern, or better wording (I'm en-1!), and so on, please post here or edit page directly. Thanks! --Was a bee (talk) 01:12, 5 May 2018 (UTC)
Full set of qualifiers required
Latest comment: 5 years ago3 comments2 people in discussion
Is it possible to indicate somehow using existing constraints that in situation:
if there is one of P993/P994/P995/P877, the rest of them are mandatory (similar with P5040/P1033/P5041/P5042 – if there is one of these qualifiers, the rest should also be present)? Wostr (talk) 10:34, 1 May 2018 (UTC)
Okay, so the complex constraint is the only option here... I'll try to figure something for this ;) Wostr (talk) 15:36, 5 May 2018 (UTC)
Format or no value
Latest comment: 5 years ago4 comments3 people in discussion
I have a problem with NFPA Special (P877): the options here should be either one of the codes listed in format constraint (Q21502404) or no value (because in most cases this element of NFPA 704 fire diamond is left blank [the white part of this label is blank]). Is it possible to add this no value to the format constraint (I couldn't find anything on the help pages etc.)? Or indicate it in some different way? Wostr (talk) 15:42, 5 May 2018 (UTC)
Latest comment: 5 years ago10 comments7 people in discussion
For me constraints are a form of quality control. Constraints can be used to find mistakes and to measure completeness. Say we have a scale from 0, an empty item, to 100, an item with all relevant labels, descriptions, sourced statements, etc. A lot of the constraints are used to keep track of this completeness. For example every item using RKDimages ID (P350) has collection (P195). This way you can get the quality for a certain subset of items to a level and keep track that it stays on this level. Over time of course we hope these subsets increases and the level increases so, because that means our overall quality is improving.
Possible new constraints:
Label in language: An item using a certain property should at least have a label in this language or these languages. example defined on Property talk:P650. ---> phab:T195178
Description in language: Same as above, but for description ---> phab:T195179
Minimum number of statements: Item using a certain property should at least have this number of statements (available in RDF for a while) ---> phab:T195181
Minimum number of identifiers: Same for identifiers, might be less useful, but might as well implement it right away
Minimum number of sitelinks: Same for identifiers, might be less useful, but might as well implement it right away
Minimum number of labels: Not directly in RDF, but probably useful
Minimum number of descriptions: Not directly in RDF, but probably useful
Probably dead: Date of birth is set and it's more than 100 years in the past. The person is probably no longer around (example)
Related item is incomplete: Item using a certain property should also have another property and the target of that other statement should contain a certain property. For example every item using RKDimages ID (P350) should have creator (P170) and that target should have RKDartists ID (P650). Example defined on Property talk:P350.
First step is to have a certain statement, second step is to have it properly sourced. Would also be nice to be able to include that a statement should have a (valid) reference. So for example on RKDartists ID (P650) a constraint is set for sex or gender (P21), I would like to add that all should be sourced (phab:T195052). That brings me to a related concept: constraint status (P2316). That's currently either mandatory constraint (Q21502408) or nothing. Would be nice to have something like "complete with exceptions" to indicate statements that have been cleared out, but left with some exceptions that can't be solved.
We can probably think of some more constraints to raise the quality. Any suggestions? I haven't filed Phabricator tasks yet because I would like to discus this first.
So we have all these constraints and more of them are being added over time. It becomes increasingly harder to keep track of this. Pages like Wikidata:Database reports/Constraint violations/Mandatory constraints/Violations become too big and have too many things mixed. So I think the basic workflow as a user (or group of users) is:
Clear out the list of violations until you're done
Maintenance mode: Every once in a while a violation occurs and needs to be cleared
The last step (the "maintenance mode") is currently quite hard. Over time you clear out more and more subsets and you just loose track of it. It's like maintaining a gigantic garden, some parts are really nice, but some parts are still a wilderness. Currently I'm trying to group things together like on User:Multichill/Humans no gender, but that doesn't seem to scale.
I would like to gather some input here and maybe we can also discus this in person at the Barcelona hackathon.
Yes I think this is a good idea, and also the bit about suggestions, which should be generated from this somehow. So yes if you have RKDartist id, then you could have gender, etc. Jane023 (talk) 14:40, 27 April 2018 (UTC)
Comment Maybe the complex constraints could be converted into a statement based system. This could make it easier to replicate them to other properties. The main disadvantage of that approach is that one wont be able to query the violations through query service. At least, once that option is available. --- Jura15:32, 27 April 2018 (UTC)
Constrains check is need to be integrated to Wikidata edit API and enabled by default. Many bots do not check format as a regular expression (P1793), conflicts-with constraint (Q21502838) and others. We can ask every botmaster to integrate such checks to bot`s code. But every new bot makes the same errors as previous bots. Flag "ignore_specific_constraint" is needed of course.
Instruments like {{Autofix}} are useful for maintaining. Maybe somebody has ideas how to cover more cases using {{Autofix}}. Also bots can have some specific algorithms for specific cases.
If I may jump in at this slightly late date, I would very much like to have relative ranges. For exmaple, the producers of a work of art can be just about any agent (person, organization, etc.) but the producers of a film are human. As well, the offspring of humans are humans, but the range of offspring in general is much broader. Peter F. Patel-Schneider (talk) 13:31, 23 May 2018 (UTC)
My insight: we should have the option to prevent adding what is known to be representationally wrong, but this mainly depends on the resources and decisions of the development team. We are an open project, we accept all points of view and we assume that truth is relative, so we don't manage truth, we manage verifiability, we want to continue doing so, we want to move away from the dystopia in which "no human has successfully edited the site in years, with flocks of admin-enabled AI bots reverting any such attempt, citing concerns about referential integrity", and I agree with all this. But, at the same time, we can't just continue labeling everything as wrong, this does not ensure that labeled issues will be solved at some point: our community is small, there are too many entities per active editor and I guess we can't easily take care of more data. Fortunately, there are some constraints related to the representation of information that must always be met. These are some truly mandatory points that could be enforced, although other points could be added:
Every new item and property must have a non-reflexive statement with instance of (P31) or subclass of (P279) (or both). Since the degree of precision is arbitrary, there's no valid excuse, everyone can find a class, precise enough or not (in the worst case, something like concrete object (Q17553950), occurrence (Q1190554), etc.), to link an entity with. No exceptions.
Well-identified symmetric properties are always symmetric. But, currently, this constraint can't be enforced because it's not possible to atomically add, modify or remove two symmetric statements. It would be great that the development team could make it possible, although this seems technically hard.
Mandatory format constraints can also be enforced. If it's not technically feasible to use an arbitrary regular expression, the simplest solution would be useful too: minimum and maximum lengths, just numbers, just a-z and A-Z letters, no uppercase characters, no lowercase characters, no special characters, URL format, etc.
Apart from this, I miss some UI improvements that could increase completeness, reduce mistakes and, as a result, reduce the work of volunteers who have to correct these mistakes later. I think it would be especially useful to use pre-filled models to create or complete common instances (humans, books vs. editions, places, etc.) and add some help messages and warnings while editing.
I would like to ping Lydia Pintscher in case she want to tell what points she agrees on and, if any, how volunteers could help the developing team to address them more easily, or possible alternatives if that's simply not possible. --abián22:54, 26 May 2018 (UTC)
From the implementation point it is not just a preference. The listed properties are allowed to be used in the qualifiers and all others trigger a violation warning. Does that help? --Lydia Pintscher (WMDE) (talk) 15:36, 11 May 2018 (UTC)
Latest comment: 5 years ago1 comment1 person in discussion
copyright status (P6216) always need some qualifiers, as described in Help:Copyrights, however what qualifiers are needed might depend on the value of the property. Is there a way to set up, "this-property-requires-qualifiers" constraint, or this-property-requires this and/or this and/or this' qualifier, kind of constraint. --Jarekt (talk) 16:21, 18 December 2018 (UTC)
Latest comment: 4 years ago1 comment1 person in discussion
I noticed that the suggestion constraint rank doesn't show up properly in this template (which uses Module:Constraints), it shows up like a mandatory constraint. See for example Property talk:P5823. If we're fixing it, would it also be a good time to improve the wording?
For normal constraints: " Items with this property should also have"
For mandatory constraints: " Items with this property must also have"
For suggestion constraints: " Items with this property could also have"
Latest comment: 4 years ago5 comments2 people in discussion
Please make the help texts for property constraint problems human-readable – RegEx are not. A minimum requirement would be a correct example (or a link to a correct example). Unfortunately I cannot help because RegEx regularly make my brain melt ;-) Thank you. (please ping me in replies, I don't use a watchlist on Wikidata) --Elya (talk) 12:00, 21 September 2019 (UTC)
@Tacsipacsi: – well, what I see in openSUSE (Q16691) is this: Screenshot. It's completely un-understandable … (and not because of language ;-) – the „help“ link leads to Help:Property constraints portal/Format, not useful, and the „talk“ link leads me to Property talk:P18, which is also kind of … unreadable for „normal“ people. I'm really positive about Wikidata and no newbie, but I started just ignoring the constraint errors because they only frustrate me … How to improve that, and where is the best place to discuss an improvement? Regards, --Elya (talk) 13:17, 21 September 2019 (UTC)
Der Wert für Bild (OpenSUSE 15.1 KDE default.png) sollte „The image you have chosen seems to be a placeholder image.“ entsprechen (regulärer Ausdruck: […]).
The regex is there for geeks like me, but there’s a human-readable description as well. If you don’t understand a particular constraint’s description, it’s best to ask on the property’s talk page or directly from someone who contributed to that constraint. —Tacsipacsi (talk) 14:42, 21 September 2019 (UTC)
@Tacsipacsi: It's only an example. The text in the screenshot doesn't make any sense. However, it's only one example. I'd like to point out that non-geek people have no chance to understand constraint problems and that this should be addressed when creating such a message. However, I'll check the syntax clarification (P2916) and will see if I can add some explanation next time I stumble upon a constraint error (if I happen to understand it myself). --Elya (talk) 14:54, 21 September 2019 (UTC)
Help creating custom constraint
Latest comment: 4 years ago1 comment1 person in discussion
@Epìdosis, Alexmar983: As far as remember, the first one can be achieved using a special value (“unknown value” maybe). The second one seems to be possible using a complex constraint, although the following times out for me:
Latest comment: 2 years ago2 comments2 people in discussion
Help:Property constraints portal/Label language states that standard label language constraint is pending phab:T195178. However, that task has been closed almost half a year ago, and label in language constraint (Q108139345) is ready to use on the Wikibase side (KrBot2 doesn’t seem to support it yet, though, reporting no violations for Adelphi author ID (P5859), even though the SPARQL query generated by Module:Constraints on the talk page lists 13 violations). The help page should be updated, and maybe {{Define label language constraint}} should be updated to use the standard constraint, so that these constraints don’t need to be set twice (once for the complex constraint and once for the standard one) until KrBot2 starts to support the standard constraint and such complex constraints can be completely removed. —Tacsipacsi (talk) 12:53, 14 March 2022 (UTC)
Done (IRL decision: just keep both :) ) --Lucas Werkmeister (WMDE) (talk) 08:08, 21 May 2017 (UTC)
Resolved Wikidata:Contact_the_development_team#checkConstraints d1g (talk) 09:25, 7 July 2017 (UTC)
Comment My claim about malfunctioning constraints was based on observating those handled by bot. If a statement linked to a redirect, "value type" and "target requires claim" would always be marked as error. I don't know if something has changed since then. The statement on WDQS was based on observation that 
