Jul 13 2021
Jun 19 2021
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.
Jun 17 2021
Jun 2 2021
May 30 2021
Not sure about what your intentions are with these questions. I'll just assume good faith
May 29 2021
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?
May 13 2021
You fixed it. \o/
Apr 30 2021
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.)
Apr 29 2021
@Lydia_Pintscher, do you know to which project/team this task would belong?
Apr 14 2021
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…
Apr 13 2021
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!).
Apr 6 2021
It should be fixed with this. Please feel free to reopen this task if you continue to have problems. Thanks!
Mar 20 2021
Mar 11 2021
Mar 9 2021
Mar 7 2021
See also T200846#4487680.
Mar 2 2021
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.
Feb 27 2021
Feb 13 2021
Jan 30 2021
Jan 4 2021
Good idea. :D And also a similar constraint type for the lexical category?
Dec 26 2020
I can't take the credit for the task description, that's Lydia's work. :)
Dec 11 2020
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…).
Oct 15 2020
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…
Is the page info just out of date? Does it get overwritten by namespace-wide protection and just doesn't reflect that?
Oct 11 2020
Oct 10 2020
Oct 9 2020
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?
Oct 8 2020
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.
Oct 7 2020
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.
Oct 6 2020
Oct 5 2020
Oct 4 2020
Oct 3 2020
Oct 2 2020
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.
Oct 1 2020
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.
Sep 30 2020
We have a regularly generated list in CSV format that will meet this objective. :D
Sep 28 2020
I know three ontology (OWL) files, all independently edited (which is not good):
Sep 25 2020
Pull request for wikiba.se: https://github.com/wmde/wikiba.se/pull/14.
Sep 21 2020
Sep 20 2020
Sep 19 2020
.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.
Sep 14 2020
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?
Sep 13 2020
I think this is similar to T218402.
Sep 12 2020
Aug 31 2020
I have simplified the description and removed from it the features that would never have been possible, leaving the description as in T212869.
I think that "lowest" priority is maybe a bit too low. While a solution isn't found, maybe a bot can be programmed in order to remove duplicate aliases and (if possible) to send a standard warning message to the users who added them.
Hi, Léa; I hope you have enjoyed the summer (which isn't technically over). :-)