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.
Sat, Feb 27
Sat, Feb 13
Jan 30 2021
Jan 4 2021
Good idea. :D And also a similar constraint type for the lexical category?
Dec 26 2020
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…
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
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
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.
Hi, Léa; I hope you have enjoyed the summer (which isn't technically over). :-)
Aug 28 2020
This is already working for the HTML pages of Wikidata.
Aug 26 2020
Side note: Please keep in mind that data quality is often understood as the "fitness for use" (http://www.semantic-web-journal.net/system/files/swj414.pdf) or "purpose" (https://www.cio.com/article/3124402/ensuring-the-quality-of-fit-for-purpose-data.html) of the data. From the RfC "Data quality framework for Wikidata":
Aug 19 2020
Everything looks good to me on https://wikidata.beta.wmflabs.org/. Thank you, folks!
Aug 18 2020
Jul 9 2020
Jun 7 2020
I'm sorry I put this aside (my fault). I didn't include tests, but I feel I don't know the architecture well enough to write them; I sense that these will be complex or that I'll need to touch code elsewhere. I think it's better for me to officially give up on these tests so that a developer on the team (or other volunteer) can code them. I'll list a few checks I have in mind, but please don't consider this list essential or exhaustive:
- A request for a page that is not a Wikibase entity does not generate a response with links to alternative structured representations.
- A request for a Wikibase Item generates a response with links to alternative structured representations.
- A request for a Wikibase Property generates a response with links to alternative structured representations.
- The link headers are well formatted.
- All the alternative structured representations listed are available.
- All the alternative structured representations available are listed.
- All the alternative structured representations listed are about the requested Wikibase entity.
May 21 2020
@DannyS712: I think I don't understand your question. What do you mean by reusing a regex? What would you expect could be done on the UI that is not possible now? On https://www.wikidata.org/wiki/Wikidata:2020_report_on_Property_constraints#format there are also some general stats about our regular expressions.
Mar 26 2020
I think that other constraints still apply even if "manner of death" (P1196) is used as a qualifier for "category contains" (P4224). Also, "category contains" (P4224) will not be the only property with which "manner of death" (P1196) and other properties can be used as qualifiers.
(Sorry for commenting so late)
I'm afraid this will continue the path of overcomplicating property constraints with exception layers patching weak or ill-defined constraints. Do you think it would be okay to complete/relax the constraint by allowing P1196, and other properties, to be used as a qualifier, @Bugreporter?