Thu, Oct 15
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…
Sun, Oct 11
Sat, Oct 10
Fri, Oct 9
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?
Thu, Oct 8
Wed, Oct 7
If it's about testing what it's like to have the Property namespace with the permissions 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.
Tue, Oct 6
Mon, Oct 5
Sun, Oct 4
Sat, Oct 3
Fri, Oct 2
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.
Thu, Oct 1
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.
Wed, Sep 30
We have a regularly generated list in CSV format that will meet this objective. :D
Mon, Sep 28
I know three ontology (OWL) files, all independently edited (which is not good):
Fri, Sep 25
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?
Feb 21 2020
Feb 20 2020
Feb 8 2020
Another option is that this constraint type becomes a default Wikibase feature consisting of checkboxes displayed on Property pages that enable the use of a Property for the main value, as a qualifier or in a reference.
This is one of only two types whose constraints have the mandatory severity level (1,221, 78%) more often than the normal severity level (349, 22%). Consistently, it has no constraints with the suggestion level and is one of the constraint types with the fewest exceptions. Widely applicable constraint types without exceptions, with a high proportion of mandatory constraints and with a clear and controlled set of parameters should be considered good candidates for becoming default Wikibase features.
Maybe. In the case of constraints, the section should never be empty and there is only one Property to define constraints, property constraint (P2302), but in the case of external identifiers it's harder to know which property to use (if any) and an empty section isn't necessarily wrong.
I don't know if it's worth the hassle, I can't imagine if the changes would take much or little time. :-/
I haven't been able to find a sufficiently descriptive name apart from those that list the three possible "scopes", something like "main-value/qualifier/reference constraint type", which is surely not the best name ever.
The box "Data: Number of constraints by constraint type and Property type" in the report can work as an approximation. Blank cells are cases that most likely don't make sense. It will probably be necessary to code a similar matrix in WikibaseQualityConstraints. If this is done, it will be very useful to show that information in T244044.
Feb 4 2020
Feb 3 2020
A specific data/property type for regular expressions or patterns would:
- ensure that the stored regular expressions or patterns are syntactically correct, in a similar way that quantity-type properties ensure that their statements are not paragraphs, something from which all implementations, tools and reusers would benefit;
- introduce a specific input (interface) control in Wikibase (not WikibaseQualityConstraints) that could make pattern editing more friendly: monospaced text, warnings, colored brackets, and all the amazing features that the developers want to implement. :-)