Copying here for the near or distant future:

You may want to check https://oops.linkeddata.es. It won't tell you about all the possible issues, but it will give you an idea of some (so-called) common pitfalls that still need to be resolved. By doing so you may also be solving T210337. 0:-)

More or less the same: T273370 (with subtasks T273368 and T273369)

For me, constraints should constrain (unless they have the level of suggestion defined), and exceptions should be exceptional. Those cases where the number of exceptions ends up skyrocketing are cases where either the constraints were conceived trying to generalize too small, specific and biased a set of cases, or there's a broader underlying problem of knowledge representation that is difficult to address and users choose to add exceptions to ignore it. The first reason for this task ("Currently the way to store exceptions is not scalable") is an effect of these problems, and I think we should solve them instead of thinking of a way to add even more exceptions. The Property that motivates this task (P225) is also mentioned at Wikidata:2020_report_on_Property_constraints#Exceptions in the context of some of the problems caused by exceptions; see also T244045.

😂

In T195178#7123731, @Multichill wrote:

Not sure about what your intentions are with these questions. I'll just assume good faith

My devil's advocate questions:

• I assume that the main purpose of all constraint types is to inform editors of mistakes or suggestions that would otherwise not be obvious. I also assume that all Items should have both labels and descriptions in virtually all supported languages. Why should users be told that the lack of a label in one language is a mistake and shouldn't be told the same about a label in another language that is more relevant (e.g. more demanded by Wikipedia) or more familiar to the user?
• Would it be expected that users who didn't previously fill in labels would switch to filling them in as a result of these violations? Or would these violations be ignored and contribute to all constraint types being ignored more?
• Might labels that were not suggested by these constraints be more neglected?

You fixed it. \o/

In T264535#7048342, @Lucas_Werkmeister_WMDE wrote:

Is this problematic for any particular reason? As far as I understand, it’s generally acceptable to repeat triples in RDF (they just have no effect).

(We can still fix this, of course, I’m just curious if it’s more important for some reason I’m not aware of.)

@Lydia_Pintscher, do you know to which project/team this task would belong?

Yeah, we could make the UI explicitly state "CE" for all those dates of the Common Era with one- or two-digit years, in line with https://en.wikipedia.org/wiki/WP:BCE…

According to the UI, you can retrieve people born before (or after), for example, 31 January (birthday), but what you get has nothing to do with that. I believe there are quite a few other problematic use cases (which is understandable, this is a challenging task!).

It should be fixed with this. Please feel free to reopen this task if you continue to have problems. Thanks!

Note that this could be done with inverse constraints (Q21510855) using the "mandatory" severity level. See the help page about this constraint type and an explanation on severity levels.

See also T200846#4487680.

In T272697#6875288, @Sarai-WMDE wrote:

Hey, @abian. Those are very valid and concerns, and we really appreciate you sharing them! We are aware that unfortunately some current issues will also be reproduced by the new application (e.g. querying for a specific date like 01-01-2021 will result in false positives, since 2021 with precision year will also be retrieved). In the context of the Query Builder, users will only be able to enter specific dates, and precision will be interpreted based on their input (we are yet to define how some values – e.g. years only – would be translated into SPARQL. This might be the key to alleviate some of the inherent issues with dates?). This data type is definitely a tricky one, and we wouldn't like to proceed being unaware of big problems. Since you seem to really have a deep understanding of the issue and its consequences, it'd be great if you'd be up for a chat?

Hey over here. I'm writing to warn you that, unfortunately, this can be extremely problematic. Since Wikibase stores all dates with day precision, regardless of their actual precision (which is stored separately), and the irrelevant part of the value can be arbitrary, it's very easy to generate misinformation with these features, as has been quietly happening for years and continues to happen to many agents and to at least three Property constraint types (see T168379, one of the most important causes of false positives in the very system that is intended to ensure data quality; and see https://reasonator.toolforge.org/?q=Q100410179 mentioning the year 1476, totally arbitrary value that Wikibase stores internally and shamelessly communicates to all software agents but does not display in its web interface). Including these features in the Query Builder aimed at the general public without first resolving this problem could have very undesirable consequences. I should have opened a Phabricator task describing this general problem and all its consequences, but I have never found the time or known where to start because of its magnitude and the questions it opens up.

Good idea. :D And also a similar constraint type for the lexical category?

In T269724#6711904, @Nikki wrote:

I can't take the credit for the task description, that's Lydia's work. :)

I understand the motivation (thanks to the fact that Nikki's tasks are much more interesting and better described than mine), :-) but I believe we should strive to contain the complexity of the constraint system and, if possible, reduce the current complexity, which is quite high. The need that the example represents might not be recurrent and, for that case, I think we could have two Properties, one for Items and one for Forms, to better adjust the constraints (not only the one we're commenting on) and statements of each of them to their cases of use. I wouldn't find it a big problem if there were some similar statements on two different Properties, as they aren't expected to change frequently and they'll be used in different namespaces (so both shouldn't appear together or be read by the same software agents that might know about one Property but not about the other). Please don't hate me for this (hate me for something else…).

It would be great to have this available considering T254280 and https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Administrator/MsynABot; if there are some setbacks or this is proving more difficult than it seemed, we can comment on it, change the acceptance criteria, ask on Wikidata for ideas…

In T254280#6545624, @Lydia_Pintscher wrote:

Is the page info just out of date? Does it get overwritten by namespace-wide protection and just doesn't reflect that?

See https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/MsynABot.

In my case, do I have to do anything with the patch? I always add reviewers arbitrarily, more or less according to the suggestions of the interface; should I add more/other reviewers, or change anything else?

In T258354#6528169, @Urbanecm wrote:

Ignore rate limits? No rate limit? Fast editors? Fast users? I don't think we should go for superbot, because there are use cases for noratelimit too, such as creating accounts at outreach events.

If it's about testing what it's like to have the Property namespace with the permission settings of the actual Wikidata, we could also set the autoconfirmed status on Test Wikidata to, for example, zero days and one edit, or zero edits.

This is still happening frequently and has consequences on the project.

In T260737#6520630, @danshick-wmde wrote:

Howdy, I'm the technical writer in question.

According to the resolution of Wikidata:Requests for comment/General semi protection for all property pages today:

Thank you, Charlie! I've updated the description.

I like this solution. The only right provided by the flag of account creator is noratelimit, and right now no user account has this flag, so we can freely change the group/flag name with MediaWiki:Group-accountcreator and MediaWiki:Group-accountcreator-member to fit its future purpose on Wikidata.

We have a regularly generated list in CSV format that will meet this objective. :D

I know three ontology (OWL) files, all independently edited (which is not good):

1. https://wikiba.se/ontology-1.0.owl
2. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikibaseLexeme/+/refs/heads/master/docs/ontology.owl
3. https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/refs/heads/master/docs/ontology.owl

Pull request for wikiba.se: https://github.com/wmde/wikiba.se/pull/14.

.mw-editable was implemented and is being used, and the possible remaining loose ends are expected to be resolved with the extension of Wikidata-Bridge to all Wikipedias.

I have no news that this is happening right now, and I assume that, thanks to Wikidata-Bridge, this will be under control from now on.

In T260728#6459405, @Charlie_WMDE wrote:

Hi Abian, I am the designer working on the Bridge.

In T260737#6459414, @Charlie_WMDE wrote:

Okay. Then the description might be incomplete; for example, if I change a territorial administrative unit to a lower one, I wouldn't consider that the previous value "was not correct and has never been". I personally would think that I would have improved the original value, but not that the original value was wrong, and I wouldn't know what to choose. In this situation people might choose arbitrarily (if they didn't have much time) or they might feel forced to ask about the consequences of these decisions and about Wikidata's policies on when to add values and when to replace them.

I’m not sure i understand the scenario correctly, but i would think, if it was a mistake, then choosing the first option “correcting” would be correct, if the unit has changed then the “outdated” option would be the correct one to pick. Can you clarify?