[Wikidata-bugs] [Maniphest] [Closed] T146740: Create an operational reconciliation service for Wikidata on OpenRefine
Pintoch closed this task as "Resolved".Pintoch claimed this task.Pintoch added a comment. This issue is resolved, the feature was released in OpenRefine 2.7 rc1.TASK DETAILhttps://phabricator.wikimedia.org/T146740EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Micru, Esc3300, Pauljmackay, -jem-, Spinster, Magnus, Aklapper, QZanden, Salgo60, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173749: QuickStatements to RDF converter
Pintoch added a comment. @Smalyshev thanks for your quick reply! Just for clarity, I am not personally working on the PST, I was just trying to find out if there was any established way to use RDF to represent a data import. If that is the case, then other tools could use that format too (for instance, OpenRefine could export datasets to this format). I'd be happy to work on that but I can only do it if a RDF model is agreed on. It looks like the Munger from wikidata-query-rdf can be used to fill a Wikibase instance, but that is a different use case.TASK DETAILhttps://phabricator.wikimedia.org/T173749EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Hjfocs, Tpt, Lydia_Pintscher, Smalyshev, GoranSMilovanovic, Kiailandi, QZanden, dachary, Izno, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173749: QuickStatements to RDF converter
Pintoch added a comment. @Lydia_Pintscher , @Smalyshev and @Tpt : is there any info about how RDF is expected to behave as an import format for Wikidata? As far as I can tell, the RDF that gets fed into the Query Service is not designed for import at all: first, there is a lot of redundancy: values are represented by simple values and value nodes, truthy statements are redundant with statement nodes, and other things like that. (this is absolutely not a criticism of the RDF serialization strategy: it totally makes sense as an export format!) So is there any designated subset of the exported triples that data producers would need to emit? I assume that subset would need to be as expressive as possible (so, for instance, the truthy triples would be dropped in favor of the full statement nodes). That is going to be very verbose, right? second, the identifiers on the nodes are generated by Wikibase: so, how does a data producer picks identifiers? Is it just going to impose its own hashes that Wikibase will have to respect? It would be great to have something else than QuickStatements to represent a data import, but I still have doubts about why RDF is suitable for that in the first place. The good thing about RDF is that it is a standard, so many tools can deal with it. But given the issues mentioned above, I expect it is going to be quite painful to reuse these tools to produce data in the right schema, as everything is deeply reified. Anyway, if that is the path you have chosen, we need specs please! Also, it seems that this project uses Java, so may I suggest that the reusable parts go to the Wikidata-Toolkit rather than the Primary Sources Tool? Wikidata-Toolkit has already got RDF export, so it would make sense to have RDF import (from RDF statements to the datamodel representation, say).TASK DETAILhttps://phabricator.wikimedia.org/T173749EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Hjfocs, Tpt, Lydia_Pintscher, Smalyshev, GoranSMilovanovic, Kiailandi, QZanden, dachary, Izno, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T173749: QuickStatements to RDF converter
Pintoch added a comment. @Lydia_Pintscher that makes sense. Okay, thank you to you both, we are on the same page! Given all these tickets on the topic I was worried that I had missed something obvious about this issue…TASK DETAILhttps://phabricator.wikimedia.org/T173749EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Hjfocs, Tpt, Lydia_Pintscher, Smalyshev, GoranSMilovanovic, Kiailandi, QZanden, dachary, Izno, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T162250: Query Service: "order by" doesn't work on graph views
Pintoch added a comment. Two closely related examples which exhibit different behaviors: http://tinyurl.com/y9ctl9vo (incorrect ordering) http://tinyurl.com/y8gy77hf (correct ordering)TASK DETAILhttps://phabricator.wikimedia.org/T162250EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Smalyshev, VIGNERON, LucasWerkmeister, Jonas, Lea_Lacroix_WMDE, Aklapper, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, Gehel, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
Pintoch added a comment. The import was discussed at various places, including at the data import hub, the property talk page and my talk page.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Karima, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
Pintoch added a comment. I think there are plenty of examples of non-CC0 data being imported in Wikidata. PubMedCentral is being imported at a large scale and as far as I can tell it is not CC0 (at least https://europepmc.org/Copyright does not make that clear. It focuses on the full texts, which we don't import, but I guess the metadata could also be protected?). I don't want to point fingers at all - I think this import is completely fine, but I would be interested if this general impression that "it's fine" can be grounded legally. Example of an item imported from there: https://www.wikidata.org/wiki/Q46524969 Another example (where I am involved): the French national registry of research structures (RNSR). Example of item: https://www.wikidata.org/wiki/Q30261396 Source dataset: https://www.data.gouv.fr/fr/datasets/repertoire-national-des-structures-de-recherche-rnsr/ (released under a custom "open license", which looks similar to CC-BY).TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Karima, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
Pintoch added a comment. I am glad I got the discussion going then: you now have one concrete example to look at (or maybe two? you did not comment on PMC). I think it is fair to say that this is not exactly an isolated case (but I am surprised that you seem to (pretend) not to know? Maybe for legal reasons?) How do you think these problematic uploads should be treated? If there a drift between the practices of the community and the rules of the project, that problem should be solved. My impression is that the references I added on these statements fulfill the attribution requirement of the license (or at least the spirit of it). But I am not a lawyer. The curators of the database are aware of the import and seem quite happy with it. In general I think many open data producers do not expect that requiring attribution would be a significant hurdle for reuse. (In this particular case, they were aware of Wikidata before - they actually have a bunch of Qids in their dataset.)TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T191963: New constraint: properties with identical values
Pintoch added a comment. Both properties mentioned above have been created in the mean time: https://www.wikidata.org/wiki/Property:P5037 https://www.wikidata.org/wiki/Property:P5115 So this constraint could be useful, I think.TASK DETAILhttps://phabricator.wikimedia.org/T191963EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: abian, Hsarrazin, Pigsonthewing, Liuxinyu970226, Pintoch, Aklapper, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T191885: Reflect atomic changes in wbeditentity summary
Pintoch added a comment. It would be fantastic to have more meaningful edit summaries with wbeditentity. It's of course hard to do this in general, but it would be great to have this for some common cases where a short summary seems doable (adding multiple statements with the same property, for instance).TASK DETAILhttps://phabricator.wikimedia.org/T191885EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Jakob_WMDE, Addshore, WMDE-leszek, Pablo-WMDE, Aklapper, Lydia_Pintscher, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T193875: Improving Wikidata reconciliation in OpenRefine
Pintoch created this task.Pintoch added projects: Wikimedia-Hackathon-2018, Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCome to complain about anything you do not like about the process of matching data to Wikidata with OpenRefine! This aspect of OpenRefine is suitable for quick incremental improvements. I will help people get more familiar with the code base if needed. Example of relevant issues: https://github.com/OpenRefine/OpenRefine/issues?q=is:issue+is:open+label:reconciliation https://github.com/wetneb/openrefine-wikidata/issuesTASK DETAILhttps://phabricator.wikimedia.org/T193875WORKBOARDhttps://phabricator.wikimedia.org/project/board/3260/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T194194: Add possibility to check constraints on unsaved statements
Pintoch added a comment. As soon as this is supported by the Wikibase API, then it makes sense to build support for this directly in Wikidata-Toolkit. This is something that would be massively useful for many people. As for OpenRefine, we need to brainstorm a bit to find when exactly these calls should be made. Currently, constraint validation is run on the entire batch every time a change is made. There could be two sorts of constraints checks: the ones we run in real time because they are cheap, and the ones we perform just before the edits are made… but then they would need to be reported in a different way? So it's not just a backend issue, we also need to understand how this will be presented to the user. Other random thoughts: for some constraints (such as inverse constraints) we need to look at the entire edit batch, not just an individual statement change, to detect if a violation will be triggered (so caching stuff is tricky) we can probably make some assumptions about the batches (for instance, assume that an edit batch will not make any chances to the P279 type hierarchy of the types involved in its constraints) I'm not familiar with the testing infrastructure for Wikidata. On OpenRefine, everything is pretty much hardcoded to use wikidata.org and not test.wikidata.org. Moving to another instance would require cleaning that up (and this must be done for the openrefine-wikidata reconciliation service first…) On the long term, OpenRefine should just have a Wikibase extension and be agnostic to the instance, but we are quite far from that. TASK DETAILhttps://phabricator.wikimedia.org/T194194EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Agabi10, Pasleim, Lucas_Werkmeister_WMDE, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, lisong, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T194869: Wikibase date datatype: default value of the "after" parameter
Pintoch created this task.Pintoch added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONThe Wikibase date datatype has a notion of precision, and also a lesser known notion of upper and lower bounds expressed as integer multiples of this precision. For instance, the following data value represents the current day in UTC: Timestamp +2018-05-17T00:00:00Z Timezone +00:00 Calendar Gregorian Precision 1 day Before 0 After 1 (meaning that it starts at the beginning of 2018-05-17, midnight, and continues until the next day) When creating a claim with a date value in the Wikibase UI, by default the "After" parameter is set to 0. Is it intentional? I believe that 1 should be the default value there (regardless of the precision). If this is indeed a bug, should we run a bot to fix all the date values? If this is not a bug, then there is a bug in Wikidata-Toolkit, which agrees with this interpretation of the default value: https://github.com/Wikidata/Wikidata-Toolkit/blob/297160438fecb86e7b86ae05cee3c46eae44797d/wdtk-datamodel/src/main/java/org/wikidata/wdtk/datamodel/interfaces/TimeValue.java (except that there is a typo there: before-tolerance should obviously be after-tolerance in the last comment)TASK DETAILhttps://phabricator.wikimedia.org/T194869EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T194869: Wikibase date datatype: default value of the "after" parameter
Pintoch updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...If this is not a bug, then there is a bug in Wikidata-Toolkit, which agrees with thismy interpretation of the default value:...TASK DETAILhttps://phabricator.wikimedia.org/T194869EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T194869: Wikibase date datatype: default value of the "after" parameter
Pintoch added a project: Wikibase-DataModel. TASK DETAILhttps://phabricator.wikimedia.org/T194869EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T194869: Wikibase date datatype: default value of the "after" parameter
Pintoch updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...When creating a claim with a date value in the Wikibase UI, by default the "After" parameter is set to 0 (see [[ https://www.wikidata.org/w/index.php?title=Q4115189=prev=680600484 |this example]]). Is it intentional? I believe that 1 should be the default value there (regardless of the precision)TASK DETAILhttps://phabricator.wikimedia.org/T194869EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T194767: Set up OpenRefine on Cloud VPS
Pintoch added a comment. Note to self: for this we would need to rethink Wikidata authentication in OpenRefine, migrating it to OAuth. This would include adding OAuth support in Wikidata-Toolkit. This has not been done yet because OAuth is not suited for open source software that is run directly by the user on their own machine.TASK DETAILhttps://phabricator.wikimedia.org/T194767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Abbe98, Pintoch, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T193875: Improving Wikidata reconciliation in OpenRefine
Pintoch added subscribers: Spinster, DarTar.Pintoch added a comment. @Spinster @DarTar That's in 20 minutes in Sala de Projectes! QC/0011TASK DETAILhttps://phabricator.wikimedia.org/T193875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: DarTar, Spinster, PeterTheOne, Lucas_Werkmeister_WMDE, Tpt, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T194767: Set up OpenRefine on Cloud VPS
Pintoch added a comment. When running software on localhost, the client needs to have OAuth consumer credentials, which are supposed to be private. If I apply for an OAuth consumer for OpenRefine, I cannot put the credentials in OpenRefine's source code, because it would allow anyone to reuse them for any other application. So every user would need to go through the OAuth registration themselves (and then OAuth login). https://stackoverflow.com/questions/27585412/can-i-really-not-ship-open-source-with-client-id For hosted versions of OpenRefine the problem disappears, but indeed we need to be more careful with tying OAuth tokens to sessions.TASK DETAILhttps://phabricator.wikimedia.org/T194767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Abbe98, Pintoch, Lucas_Werkmeister_WMDE, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T194952: Introducing the EditGroups tool
Pintoch added a comment. Oh I meant 10:30, fixing that nowTASK DETAILhttps://phabricator.wikimedia.org/T194952EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Rfarrand, bcampbell, Halfak, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T194952: Introducing the EditGroups tool
Pintoch created this task.Pintoch added projects: Wikidata, Wikimedia-Hackathon-2018.Herald added a subscriber: Aklapper. TASK DESCRIPTIONI will introduce the EditGroups tool, designed to keep track of edit batches in Wikidata, review them and revert them easily: https://tools.wmflabs.org/editgroups/TASK DETAILhttps://phabricator.wikimedia.org/T194952EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T194952: Introducing the EditGroups tool
Pintoch added a comment. @bcampbell that would be nice! but only if it's not too much effort :)TASK DETAILhttps://phabricator.wikimedia.org/T194952EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Rfarrand, bcampbell, Halfak, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T194869: Wikibase date datatype: default value of the "after" parameter
Pintoch added a subscriber: Tpt.Pintoch added a comment. After discussion with @Tpt, for now we are just going to change Wikidata-Toolkit's behaviour to use 0 in the After parameter as well… but that's just because it's really hard to shift the default now.TASK DETAILhttps://phabricator.wikimedia.org/T194869EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Tpt, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T197587: Add WikibaseQualityConstraints to the docker image
Pintoch added a project: Wikibase-Quality-Constraints. TASK DETAILhttps://phabricator.wikimedia.org/T197587EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Aklapper, Pintoch, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Agabi10, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197587: Add WikibaseQualityConstraints to the docker image
Pintoch created this task.Pintoch added a project: Wikibase-Containers.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONIt would be fabulous if we could just say "yes I want quality constraints in my own wikibase" and automatically populate the instance with all the necessary items and properties to define the constraints.TASK DETAILhttps://phabricator.wikimedia.org/T197587EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Aklapper, Pintoch, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Addshore, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T197588: Agree on a "manifest" format to expose the configuration of Wikibase instances
Pintoch created this task.Pintoch added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONBackground: we want to make it possible for OpenRefine users to upload statements to arbitrary Wikibase instances. Idea: the user should be able to specify which instance they want to push to just with a single URI. That URI should contain a "manifest" file which would describe everything we need to know about this instance (such as: URL of the MediaWiki API, query service, and so on). We have drafted the necessary information as far as OpenRefine is concerned: https://etherpad.wikimedia.org/p/wm_modelling_Wikibase Of course the idea is that manifest file could also be consumed by other tools which could be adapted to various Wikibase instances - so there might be other sensible things to add there. We need input about: the format and typical URI of that file? which information to include (what is redundant, what did we forget, …)? TASK DETAILhttps://phabricator.wikimedia.org/T197588EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197588: Agree on a "manifest" format to expose the configuration of Wikibase instances
Pintoch added a comment. A sample of what such a manifest could look like is here: https://gist.github.com/despens/d6ae4110c4e97944ddba29f23d78899f It could be served at a predictable location for each wikibase instance - such as, for instance, https://www.wikidata.org/manifest-v0.1.json or something similarTASK DETAILhttps://phabricator.wikimedia.org/T197588EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T197588: Agree on a "manifest" format to expose the configuration of Wikibase instances
Pintoch added a comment. One other approach to this problem would be to consider that these manifest files are not expected to be necessarily hosted by the Wikibase instance itself - these configuration files could be user-contributed and hosted anywhere (or derived automatically from the Wikibase Registry). The downside is that this requires more work from the community (users need to maintain these manifest files themselves) but it could be necessary if we want to include things like URLs of external tools like QuickStatements.TASK DETAILhttps://phabricator.wikimedia.org/T197588EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T193875: Improving Wikidata reconciliation in OpenRefine
Pintoch closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T193875EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: DarTar, Spinster, PeterTheOne, Lucas_Werkmeister_WMDE, Tpt, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T194952: Introducing the EditGroups tool
Pintoch closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T194952EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Rfarrand, bcampbell, Halfak, Pintoch, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T195615: handle use of statements linking to Lexemes (and Forms?) more gracefully on client
Pintoch added a comment. Just noting that this prevents us from adding examples on lexeme-related properties, such as https://www.wikidata.org/wiki/Property:P5244.TASK DETAILhttps://phabricator.wikimedia.org/T195615EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: WMDE-leszek, PintochCc: Pintoch, Stashbot, gerritbot, WMDE-leszek, Tractopelle-jaune, Addshore, Aklapper, Lydia_Pintscher, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T195258: [weird] Wikidata SPARQL query results not the same when exported
Pintoch added a comment. I have observed this bug multiple times now (also using Firefox).TASK DETAILhttps://phabricator.wikimedia.org/T195258EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, hoo, Seb35, abian, Lucas_Werkmeister_WMDE, VIGNERON, Aklapper, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T186945: Message welcome bots at local wikis trigger due to edits at Wikidata
Pintoch added a comment. this bug seems to be fairly new, it has probably been introduced by a recent code change. I have just run into it and it is definitely a new behavior.TASK DETAILhttps://phabricator.wikimedia.org/T186945EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, A2093064, Aklapper, Billinghurst, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
Pintoch added a comment. Etalab (who runs the open data portal of the French government) have released a statement (in French) concerning the attribution requirement of their "licence ouverte", confirming that it only applies to the first re-user. https://github.com/etalab/wiki-data-gouv#point-juridique Therefore it is possible for a license to require attribution and still be fully compatible with Wikidata. So we should really stop asserting that we can only import CC0 data in Wikidata, I think.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Aklapper, Huji, ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, AndrewSu, Mateusz_Konieczny, Maxlath, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T202729: When creating a new Sense through wbeditentity the summary is confusing "Created a new entity"
Pintoch added a comment. @Lydia_Pintscher @Ladsgroup any idea how I could be notified of any new automatic edit summaries, such as the wbeditentity-create-item that this change introduced? For any such summary, I need to add it to EditGroups, especially if the new auto summary replaces a highly-used existing one, as in this case. Otherwise, this breaks the tagging of batches. More broadly, is the list of these auto summaries exposed anywhere? To write EditGroups I extracted it from the localization files of Wikibase, but that's not really ideal. I am not requesting a stable interface policy or anything like that - it's great that these auto summaries become more informative!TASK DETAILhttps://phabricator.wikimedia.org/T202729EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, PintochCc: Pintoch, gerritbot, Lydia_Pintscher, Addshore, Mringgaard, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Wikidata-bugs, aude, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T191963: New constraint: properties with identical values
Pintoch updated the task description. (Show Details) CHANGES TO TASK DESCRIPTIONSome Wikidata properties are expected to hold the same values when they are both present on the same item. This is the case for https://www.wikidata.org/wiki/Property:P4285 and https://www.wikidata.org/wiki/Property:P269 for instance (see https://www.wikidata.org/wiki/Q334065#P4285 and https://www.wikidata.org/wiki/Q334065#P269 for an example). These two properties are used to link to different databases which use a shared identifierTASK DETAILhttps://phabricator.wikimedia.org/T191963EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T191963: New constraint: properties with identical values
Pintoch created this task.Pintoch added projects: Wikibase-Quality-Constraints, Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONSome Wikidata properties are expected to hold the same values when they are both present on the same item. This is the case for P4285 and P269 for instance (see https://www.wikidata.org/wiki/Q334065#P4285 and https://www.wikidata.org/wiki/Q334065#P269 for an example). These two properties are used to link to different databases which use a shared identifier. The question of whether this is the desired way to link to two databases which share a common identifier is still being debated (see https://www.wikidata.org/wiki/Wikidata:Property_proposal/Directory_of_Open_Access_Journals_ID and https://www.wikidata.org/wiki/Wikidata:Property_proposal/Plants_of_the_World_online for instance). The issue with this approach is that it creates some redundancy. One possible way to help with that redundancy would be to have a constraint that would enforce equality of these values on a given item. This constraint would be useful for existing properties which have this redundancy issue and potentially for others if we decide to use this solution in other cases.TASK DETAILhttps://phabricator.wikimedia.org/T191963EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T192811: Provide an OpenRefine API for matching by class and properties
Pintoch added a comment. I think this ticket can be closed given that we cannot figure out what it is supposed to be about. For reference, https://github.com/wetneb/openrefine-wikibase works for arbitrary Wikibase instances now (the first bullet point in my reply above).TASK DETAILhttps://phabricator.wikimedia.org/T192811EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Aklapper, Lydia_Pintscher, Pintoch, Daniel_Mietchen, RazShuty, Nandana, LJ, Lahi, Gq86, SandraF_WMF, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T192811: Provide an OpenRefine API for matching by class and properties
Pintoch closed this task as "Invalid". TASK DETAILhttps://phabricator.wikimedia.org/T192811EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Aklapper, Lydia_Pintscher, Pintoch, Daniel_Mietchen, RazShuty, Nandana, LJ, Lahi, Gq86, SandraF_WMF, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207370: Statistics of number of Wikidata edits with Magnus Manske's tools
Pintoch added a comment. Some of the OpenRefine edits were not tagged during development but all edits done with a released version should be. Some of the OpenRefine batches are uploaded via QuickStatements, in which case they are tagged as such. (The main benefits of using QS with OpenRefine is to run batches in the background or to have a statement matching rules when updating existing claims).TASK DETAILhttps://phabricator.wikimedia.org/T207370EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SandraF_WMF, PintochCc: Daniel_Mietchen, Pintoch, Samwalton9, Addshore, Aklapper, SandraF_WMF, Magnus, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T207839: Batch add WO II war memorials to Wikidata
Pintoch claimed this task.Pintoch added a comment. I would be interested in helping with this - I can guide you through the uploading process with OpenRefine. If you want to prepare for this, I feel free to download OpenRefine have a look at tutorials, like these: https://www.wikidata.org/wiki/Wikidata:Tools/OpenRefine/Editing/Tutorials/Basic_editing https://www.wikidata.org/wiki/Wikidata:Tools/OpenRefine/Editing/Tutorials/Video The videos at http://openrefine.org/ are also useful to get an idea of what OpenRefine does (with no reference to Wikidata).TASK DETAILhttps://phabricator.wikimedia.org/T207839EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, RonnieV, SIryn, Elvalente, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, DDJJ, Harmonia_Amanda, Spinster, Jane023, Wikidata-bugs, aude, Mbch331, valhallasw___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207839: Batch add WO II war memorials to Wikidata
Pintoch added a comment.
Just to let you know that the problem with the ".0" will be solved in the next version of OpenRefine.
In the meantime, you can solve the issue by transforming your column with the following _expression_: value.toString().replace(".0",""). Hope it helps!TASK DETAILhttps://phabricator.wikimedia.org/T207839EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Jane023, Multichill, Footech, Elvalente, Pintoch, RonnieV, SIryn, Vemonet, A_ka_es, Teffubud, S9a8m, Arybolab, Dja, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, DDJJ, Harmonia_Amanda, Spinster, Wikidata-bugs, aude, Mbch331, valhallasw___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T199228: Define an SLO for Wikidata Query Service public endpoint and communicate it
Pintoch added a comment. Thanks for the ping Lydia! On the top of my mind, the only uses of SPARQL in the tools I maintain are in the openrefine-wikidata interface: queries to retrieve the list of subclasses of a given class - lag is not critical at all for this as the ontology is assumed to be stable. (These results are cached on my side for 24 hours, for any root class.) queries to retrieve items by external identifiers or sitelinks - lag can be more of an issue for this but I would not consider it critical. (These results are not cached.) What matters much more for this tool is getting quick results and as little downtime as possible - lag is not really a concern.TASK DETAILhttps://phabricator.wikimedia.org/T199228EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Magnus, Pintoch, gerritbot, Mathew.onipe, Stashbot, Lydia_Pintscher, EBjune, debt, Joe, Smalyshev, Gehel, Aklapper, Legado_Shulgin, CucyNoiD, Nandana, NebulousIris, thifranc, AndyTan, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Davinaclare77, Adrian1985, Qtn1293, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, merbst, LawExplorer, Lewizho99, Zppix, Maathavan, Jonas, Xmlizer, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207839: Batch add WO II war memorials to Wikidata
Pintoch added a comment. Awesome! \o/ Actually OpenRefine could potentially help you already at that stage to do the matching - let me know if you want a quick demo :)TASK DETAILhttps://phabricator.wikimedia.org/T207839EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Footech, Elvalente, Pintoch, RonnieV, SIryn, Vemonet, A_ka_es, Teffubud, S9a8m, Dja, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, DDJJ, Harmonia_Amanda, Spinster, Jane023, Wikidata-bugs, aude, Mbch331, valhallasw___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T199228: Define an SLO for Wikidata Query Service public endpoint and communicate it
Pintoch added a comment. @Gehel my service has been quite unstable for some time, but I haven't found the time yet to find out exactly where the problem is coming from - it could be SPARQL, the Wikidata API, redis or the webservice itself. I will add a few more metrics to understand what is going on and report back here.TASK DETAILhttps://phabricator.wikimedia.org/T199228EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Magnus, Pintoch, gerritbot, Mathew.onipe, Stashbot, Lydia_Pintscher, EBjune, debt, Joe, Smalyshev, Gehel, Aklapper, Legado_Shulgin, CucyNoiD, Nandana, NebulousIris, thifranc, AndyTan, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Davinaclare77, Adrian1985, Qtn1293, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, merbst, LawExplorer, Lewizho99, Zppix, Maathavan, Jonas, Xmlizer, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T199228: Define an SLO for Wikidata Query Service public endpoint and communicate it
Pintoch added a comment. The search interface can also be used for that thanks to the haswbstatement command. That only gets you one id per query, so it might not be suited for all tools. I don't know if the lag is lower in this interface. Retrieving items by identifiers is quite crucial in many tools so it would be useful to have a solid interface for that instead of relying on SPARQL (which feels indeed like using a sledgehammer to crack a nut).TASK DETAILhttps://phabricator.wikimedia.org/T199228EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Jheald, Magnus, Pintoch, gerritbot, Mathew.onipe, Stashbot, Lydia_Pintscher, EBjune, debt, Joe, Smalyshev, Gehel, Aklapper, Legado_Shulgin, CucyNoiD, Nandana, NebulousIris, thifranc, AndyTan, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Davinaclare77, Adrian1985, Qtn1293, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Adik2382, Th3d3v1ls, Hfbn0, Ramalepe, Liugev6, QZanden, merbst, LawExplorer, Lewizho99, Zppix, Maathavan, Jonas, Xmlizer, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T209031: Not able to scoop comment table in labs for mediawiki reconstruction process
Pintoch edited subscribers, added: Pintoch; removed: Cloud-Services.Pintoch added a comment. I have taken the liberty to remove "Cloud Services" as a subscriber to this ticket as I do not think every toollabs user wants to receive notifications about this.TASK DETAILhttps://phabricator.wikimedia.org/T209031EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, bd808, tstarling, Fjalapeno, jcrespo, Marostegui, mforns, faidon, Milimetric, Krenair, elukey, Nuria, Aklapper, JAllemandou, Akovalyov, Banyek, AndyTan, Killertrap, Zylc, Giuliamocci, 1978Gage2001, Chicocvenancio, Tbscho, Minhnv-2809, JJMC89, srodlund, Luke081515, mys_721tx, Gryllida, scfc, Jay8g, jeremyb, chasemp, Cloud-Services___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T204024: Store WikibaseQualityConstraint check data in an SQL table instead of in the cache
Pintoch added a comment. I was thinking of the opposite: consider the violations related to the revision R of the item I to be the violations of the statements of I with respect to the state of Wikidata just before R+1 was saved. Because for the current revision, you do want to keep invalidating the violations when other edits impact them - you don't want to display the violations as they were when the latest edit was done. But that does not solve the issue: the scenario you describe can still happen in the opposite direction.TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Lydia_Pintscher, Pintoch, Tpt, Smalyshev, Eevans, daniel, mobrovac, Jonas, Lucas_Werkmeister_WMDE, Aklapper, Addshore, Lahi, Gq86, GoranSMilovanovic, QZanden, merbst, LawExplorer, Agabi10, Hardikj, Wikidata-bugs, aude, Mbch331, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T139898: New gadget to aid property creation process
Pintoch added a comment. I currently use my own custom hacky script to create properties, but having something stable and usable by anyone would be highly beneficial.TASK DETAILhttps://phabricator.wikimedia.org/T139898EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, ChristianKl, Micru, Lydia_Pintscher, Josve05a, Edgars2007, Aklapper, Zppix, Bugreporter, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, dachary, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T213012: Enable the Watchlist Messages gadget in Wikidata
Pintoch created this task.Pintoch added a project: Wikidata-Gadgets.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata.
TASK DESCRIPTIONSome other Wikimedia sites have a gadget which makes it possible to display dynamic watchlist messages (above the actual content of the watchlist).
Wikidata currently displays a static content there, which is updated mostly manually by admins. This content is often stale, takes a lot of space on small screens, and users have no simple way to hide it once they have read it.
Enwiki has two gadgets (watchlist messages and geonotices) which adds a button enabling users to dismiss messages displayed there. Commonswiki has one gadget (called WatchlistMessages) which merges the functionality of both gadgets into one gadget (which allows the community to advertise particular events to a very narrow geographical audience). Other wikis probably have similar gadgets.
The template used by enwiki's gadget already exists in Wikidata but is not functional without the gadget (the dismiss button will not appear, even if the message is rendered in the watchlist).
Therefore I request the activation of such a gadget (probably the one from commons as it looks more advanced) in Wikidata. After a trial period we probably want to consider enabling it by default given that the code is already well tested in sister projects (where it is also enabled by default).
The move was discussed on wiki:
https://www.wikidata.org/wiki/Template_talk:Watchlist_summary#Changing_the_format_of_this_summary_to_use_{{Display/watchlist}}
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2018/12#Watchlist_notices:_let_users_dismiss_these_notifications
https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2018/11#Watchlist_UI_squalor
This move requires both the activation of one of these gadgets and also changes in the messages themselves. The migration to the relevant templates can be done first: although users will not be able to dismiss the messages, they will still expire by themselves after a set delay.TASK DETAILhttps://phabricator.wikimedia.org/T213012EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, dachary, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T205017: Investigation: Look at what gadgets it might make sense to pull into Wikibase
Pintoch added a comment. Related: T213012: Enable the Watchlist Messages gadget in Wikidata TASK DETAILhttps://phabricator.wikimedia.org/T205017EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Addshore, Aklapper, Tarrow, Nandana, LJ, Lahi, Gq86, SandraF_WMF, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, dachary, Gstupp, LawExplorer, _jensen, Jneubert, D3r1ck01, Wikidata-bugs, aude, Daniel_Mietchen, Ricordisamoa, Lydia_Pintscher, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T213012: Enable the Watchlist Messages gadget in Wikidata
Pintoch added a comment. Oh can they? Sorry I had no idea! Thanks, I will try to enable it myself.TASK DETAILhttps://phabricator.wikimedia.org/T213012EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Lydia_Pintscher, Pintoch, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, dachary, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T213012: Enable the Watchlist Messages gadget in Wikidata
Pintoch added a comment. I have pinged a few interface admins on wiki to enable this.TASK DETAILhttps://phabricator.wikimedia.org/T213012EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Lydia_Pintscher, Pintoch, Aklapper, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, dachary, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T204024: Store WikibaseQualityConstraint check data in an SQL table instead of in the cache
Pintoch added subscribers: Tpt, Pintoch.Pintoch added a comment. This ticket is fantastic news. It's probably completely out of the scope of this, but let's mention it anyway: I think it would be massively useful for revision scoring if we could have access to both the current violation report and the one for the previous revision. So that we could compute the new violations each edit introduced or solved. (Pinging @Tpt about that). But I suspect storing the violations reports for all revisions of a given item might require too much storage? (For vandalism detection purposes I guess only the last few revisions should be needed, but you probably don't want to introduce an arbitrary cutoff…)TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Tpt, Smalyshev, Eevans, daniel, mobrovac, Jonas, Lucas_Werkmeister_WMDE, Aklapper, Addshore, Lahi, Gq86, GoranSMilovanovic, QZanden, merbst, LawExplorer, Agabi10, Hardikj, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T204267: Flood of WDQS requests from wbqc
Pintoch added a comment. @aborrero thanks for the ping. I do not recognize the shape of the queries as coming from this tool though. The openrefine-wikidata tool should do relatively few SPARQL queries, whose results are cached in redis. How did you determine that this tool is the source of the problem?TASK DETAILhttps://phabricator.wikimedia.org/T204267EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Addshore, PintochCc: aborrero, Pintoch, Stashbot, Jonas, Addshore, TerraCodes, Liuxinyu970226, Aklapper, Smalyshev, AndyTan, Zylc, Davinaclare77, Qtn1293, 1978Gage2001, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, Chicocvenancio, Th3d3v1ls, Hfbn0, QZanden, EBjune, Tbscho, merbst, LawExplorer, Zppix, JJMC89, Agabi10, Xmlizer, srodlund, Wong128hk, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Gryllida, faidon, scfc, Mbch331, Jay8g, Krenair, fgiunchedi, chasemp___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T204024: Store WikibaseQualityConstraint check data in an SQL table instead of in the cache
Pintoch added a comment. @Lydia_Pintscher personally here is what I would concretely implement in the EditGroups tool. For each edit that is part of an edit group: fetch the constraints violations before and after the edit (this fetching would happen as the edit is retrieved, so in near real-time) compute the difference of constraints violations of each type (for instance, 1 new "value type constraint" violation and 2 less "statement required constraint" violation) aggregate these statistics at a batch level and expose them in batch views (for instance, this batch added 342 new value type constraint" violations and solved 764 "statement required constraint" violations) Together with the number of reverted edits in a batch (which the tool already aggregates), this could potentially make it easier to spot problematic batches. Other ideas of applications (that I would not write myself): I am not involved in ORES development but I believe the statistics computed above (at edit level) could be useful for vandalism detection - if the constraints violations are already computed and cheap to retrieve, it might be much easier for them to rely on that. I believe @Tpt could be interested in this as he has been working on detecting edits which introduce / solve constraint violations. TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Lydia_Pintscher, Pintoch, Tpt, Smalyshev, Eevans, daniel, mobrovac, Jonas, Lucas_Werkmeister_WMDE, Aklapper, Addshore, Lahi, Gq86, GoranSMilovanovic, QZanden, merbst, LawExplorer, Agabi10, Hardikj, Wikidata-bugs, aude, Mbch331, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T204024: Store WikibaseQualityConstraint check data in an SQL table instead of in the cache
Pintoch added a comment. @Lydia_Pintscher yes indeed! For instance the aggregation at batch-level would probably not be meaningful for inverse constraints (unless there is a way to detect all the violations added and solved by an edit, not just on the item where the edit was made). But isn't this a problem that you have anyway, even when storing only the latest violations? For instance, if I add a "subclass of (P279)" statement between two items, don't you need to recompute type violations for all items which are instances of some transitive subclass of the new subclass? I am not sure how this invalidation is done at the moment. Maybe it is too hard to store the entire violations reports for previous revisions, but it might be feasible for you to expose some statistics about the changes in the violations for each edit? If you have some clever invalidation logic to deal with changes of violations on other items, and if the invalidated violations are recomputed immediately after, it might even be doable to include these in the statistics? That all sounds pretty hard to me and I don't want to hijack your thread!TASK DETAILhttps://phabricator.wikimedia.org/T204024EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Lydia_Pintscher, Pintoch, Tpt, Smalyshev, Eevans, daniel, mobrovac, Jonas, Lucas_Werkmeister_WMDE, Aklapper, Addshore, Lahi, Gq86, GoranSMilovanovic, QZanden, merbst, LawExplorer, Agabi10, Hardikj, Wikidata-bugs, aude, Mbch331, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T207484: API to efficiently format large numbers of entity IDs
Pintoch added a comment. @Lucas_Werkmeister_WMDE thank you very much for that!TASK DETAILhttps://phabricator.wikimedia.org/T207484EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, PintochCc: Pintoch, Addshore, Lydia_Pintscher, Lea_Lacroix_WMDE, gerritbot, Aklapper, LucasWerkmeister, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, D3r1ck01, Jonas, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T92961: [Story] Versioning in JSON output
Pintoch added a comment. Concerning the dumps, it should be possible to add versioning information on a per-entity basis, for instance by adding the revision id in the JSON serialization of the entity, as is currently done in Special:EntityData. This would arguably be more useful than a per-dump versioning, given that the dump generation process is not atomic. It would also be less of a breaking change: it would just amount to make JSON serialization of entities more uniform. This is debated in T87283 <https://phabricator.wikimedia.org/T87283>. TASK DETAIL https://phabricator.wikimedia.org/T92961 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Pfps, aude, Smalyshev, Ricordisamoa, Addshore, Lydia_Pintscher, adrianheine, JanZerebecki, daniel, Tobi_WMDE_SW, Aklapper, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T87283: Wikidata dumps should have revision ID or other sequence mark
Pintoch added a comment. I am wondering what is the status of this: is more discussion needed about what version information to include, or are we simply waiting for a patch? I vote for the revision id to serve as version id (possibly with other metadata such as timestamp, as in Special:EntityData). If there is consensus for that, and if directed to the relevant part of the code, I could contribute patch. TASK DETAIL https://phabricator.wikimedia.org/T87283 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Addshore, Ivan_A_Krestinin, TorbenRahbekKoch, Ricordisamoa, Denis.bykov, Jimkont, Magnus, mkroetzsch, JanZerebecki, daniel, hoo, Aklapper, Smalyshev, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T94019: Generate RDF from JSON
Pintoch added a comment. I think Wikidata-Toolkit could be used for that: https://github.com/Wikidata/Wikidata-Toolkit/blob/master/wdtk-rdf/src/main/java/org/wikidata/wdtk/rdf/RdfSerializer.java Obviously it would mean making sure the RDF serialization produced by it is consistent with what is being fed in WDQS at the moment. TASK DETAIL https://phabricator.wikimedia.org/T94019 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Smalyshev, hoo, Liuxinyu970226, mkroetzsch, Aklapper, daniel, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T87283: Wikidata dumps should have revision ID or other sequence mark
Pintoch added a comment. @Smalyshev okay! Sorry if this is not the right place: I would be happy to migrate the patch to another ticket. Indeed this only adds entity-level metadata, not dump-level metadata. I think this would be less of a breaking change, given that it does not require changing the dump structure (and of course it is more useful to me, haha!) TASK DETAIL https://phabricator.wikimedia.org/T87283 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Addshore, Ivan_A_Krestinin, TorbenRahbekKoch, Ricordisamoa, Denis.bykov, Jimkont, Magnus, mkroetzsch, JanZerebecki, daniel, hoo, Aklapper, Smalyshev, alaa_wmde, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T216160: Update wikidata-entities dump generation to fixed day-of-month instead of fixed weekday
Pintoch added a comment. I agree with @Nicolastorzec above. I suspect that the entity dumps are more popular and cheaper to generate than the full SQL/XML dumps, so I would argue that they should be generated more often. Even if the entity dumps and the SQL/XML dumps were generated "at the same time", it would probably be hard to give guarantees about their relatedness: some revisions will always be included in one but not the other given the different time frames for the generation, no? I have proposed a patch <https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/500806/> to add the revision id for each entity in the JSON dumps. This way, users have at least a way to compare the freshness of the data from different sources. TASK DETAIL https://phabricator.wikimedia.org/T216160 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Rosiestep, Lea_Lacroix_WMDE, WMDE-leszek, Mvolz, notconfusing, Envlh, Melderick, Nicolastorzec, hoo, Smalyshev, Addshore, ArielGlenn, JAllemandou, alaa_wmde, CucyNoiD, Nandana, NebulousIris, Akovalyov, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Zambujo, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Lunewa, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, gnosygnu, Wikidata-bugs, aude, Daniel_Mietchen, jayvdb, Mbch331, jeremyb ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T217258: Language handling for adding citations with citoid in wikidata
Pintoch added a comment. If you need a mapping from ISO language codes to Wikimedia ones, Wikidata-Toolkit has such a mapping: https://github.com/Wikidata/Wikidata-Toolkit/blob/3e62f93b137c25961c5a12172c7f213a720ecb67/wdtk-datamodel/src/main/java/org/wikidata/wdtk/datamodel/interfaces/WikimediaLanguageCodes.java It might not be the most up to date mapping you can get though (I would be interested in updating it but I haven't investigated how to do that) TASK DETAIL https://phabricator.wikimedia.org/T217258 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mvolz, Pintoch Cc: Pintoch, Aklapper, Mvolz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, Shangkuanlc, mobrovac, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T217239: Expose the graph of language fallbacks in an API
Pintoch added a subscriber: Mvolz. Pintoch added a comment. > As a tool developer, it would be very useful to access the language fallback graph from an API. I would use the resulting graph in https://tools.wmflabs.org/openrefine-wikidata/ . This tool is basically a wrapper over the Wikibase API (and a bit of SPARQL) to comply with OpenRefine's reconciliation API. The tool can be configured to work in any language and would benefit from knowing about the language fallback graph to retrieve labels, descriptions and aliases. The current code that does that is here: https://github.com/wetneb/openrefine-wikibase/blob/master/wdreconcile/language.py (it's a crude approximation, where every language falls back on English). I will let @Mvolz comment about her own use case. Concerning performance, of course this would be only retrieved quite rarely and cached on my side. So maybe a web API is overkill for that - but it would ideally be good to be able to download that structured graph from somewhere. It does not have to be served by the MediaWiki instance itself. TASK DETAIL https://phabricator.wikimedia.org/T217239 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Mvolz, Anomie, Lucas_Werkmeister_WMDE, Pintoch, Aklapper, Nandana, Lahi, Gq86, Baloch007, GoranSMilovanovic, QZanden, LawExplorer, Sethakill, dg711, _jensen, MuhammadShuaib, LNDDYL, Psychoslave, Wikidata-bugs, aude, jayvdb, Arrbee, KartikMistry, Mbch331, Jay8g, Legoktm ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T217768: The entity suggester should return properties
Pintoch created this task. Pintoch added projects: Discovery-Search, Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION The entity suggester only returns items, not properties. This is counter-intuitive as Special:Search returns both items and properties by default. For consistency, the entity suggester should include properties too (for instance, searching for P17 should return https://www.wikidata.org/wiki/Property:P17 as first result). As a user, when looking for a property, I usually go to a random item and pretend I want to add a statement there: this is the only way I can think of to get a property suggester. This does not feel very natural. Using Special:Search can work too of course, but because of the different way the data is indexed there, results can be quite different. TASK DETAIL https://phabricator.wikimedia.org/T217768 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Aklapper, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206392: Redesign rank icons for better visibility
Pintoch added a comment. What is the protocol to go forward on this? Should we hold a RFC on-wiki to let people choose among the possible solutions above? TASK DETAIL https://phabricator.wikimedia.org/T206392 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Lydia_Pintscher, MichaelSchoenitzer, Aklapper, Nandana, A.S.Kochergin, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, JGirault, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T218779: Exposed structured diffs in Wikibase API
Pintoch added a parent task: T56328: Provide intraline diff format in API action=compare. TASK DETAIL https://phabricator.wikimedia.org/T218779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T218779: Exposed structured diffs in Wikibase API
Pintoch created this task. Pintoch added a project: Wikidata-Campsite. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION As an API user, I would like to be able to access diffs between revisions of items (or properties, lexemes). Currently, the API only exposes the HTML rendition of these diffs, via the `compare` action: https://www.wikidata.org/w/api.php?action=help=compare It would be great to have a JSON representation of these diffs as well. Currently, I can parse the HTML to extract the information I need, but this is brittle as any change in diff rendering could potentially break my consumer. There is already a task T56328 <https://phabricator.wikimedia.org/T56328> about this in MediaWiki, but given that there is an even stronger case for this in Wikidata, I am creating a specific ticket for it. This could potentially be implemented by a dedicated API action given the different data format. I do not have a particular JSON format to propose: anything that is easy to produce by the underlying PHP implementation would be great to have. TASK DETAIL https://phabricator.wikimedia.org/T218779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T218779: Exposed structured diffs in Wikibase API
Pintoch updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T218779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T218779: Expose structured diffs in Wikibase API
Pintoch renamed this task from "Exposed structured diffs in Wikibase API" to "Expose structured diffs in Wikibase API". TASK DETAIL https://phabricator.wikimedia.org/T218779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T218779: Expose structured diffs in Wikibase API
Pintoch added a comment. @Lydia_Pintscher Sure! I have just deployed a demonstration of this use case on EditGroups <https://tools.wmflabs.org/editgroups/>. The goal is to index all Wikidata edit groups by the properties that they change (as statements or qualifiers, added or removed by the edit group). This can be useful to get an overview of the data imports that happened in a particular domain. For instance, the list of all edit groups using P50 (author) <https://tools.wmflabs.org/editgroups/?tags=prop-P50> gives you an overview of the ongoing author disambiguation effort in Wikicite. Some editing actions (such as `wbeditentity-create` or `wbeditentity-update`) allow users to perform big changes on items, and therefore do not expose the properties used in the edit summary. So, to make sure these edits are also indexed, we need to analyze their diffs. Hence the need for this API. One alternative would be to retrieve the JSON representation of the entities for all revisions involved and compute the diff manually, client-side. This is potentially more scalable as we could retrieve 25 diffs in one API call (25*2 revisions). But implementing the diff logic is probably a bit more involved. Relevant code: https://github.com/Wikidata/editgroups/blob/master/tagging/diffinspector.py TASK DETAIL https://phabricator.wikimedia.org/T218779 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Lydia_Pintscher, Aklapper, Pintoch, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206392: Redesign rank icons for better visibility
Pintoch added a comment.
Useful solution from Nikki: add in your common.css:
/* from [[User:Nikki/common.css]] */
.wb-preferred { background-color: lavender }
.wb-deprecated { background-color: mistyrose }TASK DETAILhttps://phabricator.wikimedia.org/T206392EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Lydia_Pintscher, MichaelSchoenitzer, Aklapper, Nandana, A.S.Kochergin, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, JGirault, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T57755: Allow time values more precise than day
Pintoch added a comment. I have updated the Wikibase data model docs, which incorrectly mentioned precisions of hours, minutes and seconds. I assume that they were there because they were part of an earlier design?TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: PintochCc: Pintoch, Abit, Magnus, Ramsey-WMF, Addshore, valerio.bozzolan, Sabas88, Sannita, Paucabot, MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T87283: Wikidata dumps should have revision ID or other sequence mark
Pintoch added a comment. Ok great! I'll move the field to the end and try to make Jenkins happy then. TASK DETAIL https://phabricator.wikimedia.org/T87283 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Lydia_Pintscher, Pintoch, Addshore, Ivan_A_Krestinin, TorbenRahbekKoch, Ricordisamoa, Denis.bykov, Jimkont, Magnus, mkroetzsch, JanZerebecki, hoo, Aklapper, Smalyshev, alaa_wmde, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T191963: New constraint: properties with identical values
Pintoch added a comment. On a similar note, we also have some properties whose value is expected to be the subject entity id: - https://www.wikidata.org/wiki/Property:P6482 - https://www.wikidata.org/wiki/Property:P6413 TASK DETAIL https://phabricator.wikimedia.org/T191963 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: abian, Hsarrazin, Pigsonthewing, Liuxinyu970226, Pintoch, Aklapper, darthmon_wmde, Premeditated, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, merbst, LawExplorer, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T197588: Agree on a "manifest" format to expose the configuration of Wikibase instances
Pintoch added a project: OpenRefine. TASK DETAIL https://phabricator.wikimedia.org/T197588 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Nikerabbit, Salgo60, Aklapper, Gstupp, Lucas_Werkmeister_WMDE, Pintoch, darthmon_wmde, Premeditated, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T194767: Set up OpenRefine on Cloud VPS
Pintoch added a project: OpenRefine. TASK DETAIL https://phabricator.wikimedia.org/T194767 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Abbe98, Pintoch, Lucas_Werkmeister_WMDE, darthmon_wmde, Premeditated, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Culex, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T87283: Wikidata dumps should have revision ID or other sequence mark
Pintoch added a comment. Thanks all for your patience for this! Excited to see my first commit making it into Wikibase \o/ TASK DETAIL https://phabricator.wikimedia.org/T87283 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Lydia_Pintscher, Pintoch, Addshore, Ivan_A_Krestinin, TorbenRahbekKoch, Ricordisamoa, Denis.bykov, Jimkont, Magnus, mkroetzsch, JanZerebecki, hoo, Aklapper, Smalyshev, darthmon_wmde, alaa_wmde, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T223776: Create Wikidata autocomplete gadget for external entities
Pintoch added a comment. That's great! Is there a list of the supported external ids? TASK DETAIL https://phabricator.wikimedia.org/T223776 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Danmichaelo, Pintoch Cc: Pintoch, Lea_Lacroix_WMDE, Aklapper, Danmichaelo, darthmon_wmde, alaa_wmde, Ferenczy, sarhan.alaa, Samuditha24, IM3847, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, Chicocvenancio, MichaelSchoenitzer_WMDE, QZanden, dachary, LawExplorer, Jogi_don, _jensen, rosalieper, D3r1ck01, Wikidata-bugs, Jdlrobson, aude, Ricordisamoa, Sjoerddebruin, Mbch331, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T87283: Wikidata dumps should have revision ID or other sequence mark
Pintoch added a subscriber: Lydia_Pintscher. Pintoch added a comment. @Lydia_Pintscher we would need your thoughts about this. In a nutshell, the proposal is to add the `lastrevid` field currently exposed in `Special:EntityData` and in the API (`action=wbgetentities`) to the JSON dumps too. This field stores the id of the revision which contains the entity as serialized. Currently, no revision information is included in the dumps at all. Because this only adds an extra field to JSON objects, without changing the rest of the structure, this should not break any reasonable consumer, especially if they are able to parse JSON representations from the API as well. The patch is here: https://gerrit.wikimedia.org/r/500806 (I'll fix the issues picked up by Jenkins if you think the change is useful) TASK DETAIL https://phabricator.wikimedia.org/T87283 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Lydia_Pintscher, Pintoch, Addshore, Ivan_A_Krestinin, TorbenRahbekKoch, Ricordisamoa, Denis.bykov, Jimkont, Magnus, mkroetzsch, JanZerebecki, hoo, Aklapper, Smalyshev, alaa_wmde, joker88john, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T204440: analyze and visualize the identifier landscape of Wikidata
Pintoch added a comment. This is nice! However, when visualizing properties by category, it seems that subclasses are not taken into account: only the properties bearing that exact category as P31 <https://phabricator.wikimedia.org/P31> value are listed. This gives a pretty inaccurate view: it is crucial to respect this hierarchy, just like the prop-explorer tool does: https://tools.wmflabs.org/prop-explorer/ For instance, when browsing the category Wikidata property to identify organisations <https://www.wikidata.org/wiki/Q21745557>, I want to see Corporate Number (Japan) <https://www.wikidata.org/wiki/Property:P3225>, because it is marked as a Wikidata property to identify organizations in company registers <https://www.wikidata.org/wiki/Q26235166>, which is a subclass. I believe that might be the issue that confused @connorshea above: they might have looked for their property in a super-class of the classes explicitly declared on it. TASK DETAIL https://phabricator.wikimedia.org/T204440 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GoranSMilovanovic, Pintoch Cc: Pintoch, Daniel_Mietchen, connorshea, Moebeus, Multichill, Hjfocs, RazShuty, GoranSMilovanovic, Aklapper, Lydia_Pintscher, alaa_wmde, Nandana, Lahi, Gq86, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T203557: Create a Edit group extension
Pintoch added a comment. Great point! I did not think about that in this way. It sounds like a very sensible route to follow. TASK DETAIL https://phabricator.wikimedia.org/T203557 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Abit, Ramsey-WMF, Jony, Lydia_Pintscher, JeanFred, LucasWerkmeister, Pintoch, Framawiki, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, Jayprakash12345, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Dinoguy1000, Ricordisamoa, Wesalius, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T203557: Create a Edit group extension
Pintoch added a comment. I thought for a moment that there was an issue with the fact that at the moment, filtering by tags only works for Special:RecentChanges (which only contain the most recent changes, not all of them). But Lucas pointed out that it is also supported by Special:Contributions, which is uncapped in time. EditGroups currently assumes that all edits in a given group are made by the same user, which I think makes sense as a constraint. So, in the current situation, if you had an edit group which corresponded to a single tag, it would be possible to retrieve all edits in it via Special:Contributions (assuming you know the user in the first place). This suggests that an approach along the lines of what Lucas describes above is viable. Perhaps "sub-tags" should be attached to a parent user rather than a parent tag (or possibly both) given this observation. TASK DETAIL https://phabricator.wikimedia.org/T203557 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Abit, Ramsey-WMF, Jony, Lydia_Pintscher, JeanFred, LucasWerkmeister, Pintoch, Framawiki, Aklapper, Bugreporter, darthmon_wmde, DannyS712, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Cparle, Anooprao, SandraF_WMF, GoranSMilovanovic, Jayprakash12345, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Susannaanas, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Dinoguy1000, Ricordisamoa, Wesalius, Fabrice_Florin, Raymond, Steinsplitter, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T220696: [Story] Create better edit summaries for wbeditentity API endpoint
Pintoch added a comment. Exciting developments! I am wondering if that `comment_data` could be (or already is) exposed in any public API? Exposing such diffs would also solve T106306 <https://phabricator.wikimedia.org/T106306> in the same go. As an API consumer I would have a great appetite for such diffs, for instance in the EditGroups <https://tools.wmflabs.org/editgroups/> tool (see T218779#5049167 <https://phabricator.wikimedia.org/T218779#5049167> for the motivation). TASK DETAIL https://phabricator.wikimedia.org/T220696 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Jakob_WMDE, Addshore, rosalieper, Pintoch, Lea_Lacroix_WMDE, NicoScribe, Rosalie_WMDE, alaa_wmde, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Aklapper, Lea_WMDE, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T238003: Delete openrefine01 instance
Pintoch added a comment. Thanks! I am working on making OpenRefine easier to host, but it's a long term project indeed (exciting announcement about that soon). TASK DETAIL https://phabricator.wikimedia.org/T238003 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Lucas_Werkmeister_WMDE, Aklapper, darthmon_wmde, DannyS712, Nandana, JKSTNK, Fheredia, Jony, Zylc, 1978Gage2001, Lahi, aborrero, Gq86, GoranSMilovanovic, Chicocvenancio, QZanden, Tbscho, LawExplorer, JJMC89, _jensen, rosalieper, Scott_WUaS, srodlund, Wikidata-bugs, Jitrixis, aude, Gryllida, Nikerabbit, scfc, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T221774: Add Wikidata query service lag to Wikidata maxlag
Pintoch added a comment. So this is what we get with an exponential back-off (1.5 factor), at the moment: 22:37:27.148 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 1000 milliseconds. (19338ms) 22:37:28.729 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 1500 milliseconds. (1581ms) 22:37:33.809 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 2250 milliseconds. (5080ms) 22:37:37.931 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 3375 milliseconds. (4122ms) 22:37:42.663 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 5062 milliseconds. (4732ms) 22:37:49.437 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 7593 milliseconds. (6774ms) 22:37:58.429 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 5.49167 seconds lagged. -- pausing for 11389 milliseconds. (8992ms) 22:38:18.217 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 6 seconds lagged. -- pausing for 17083 milliseconds. (19788ms) 22:38:36.461 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 6 seconds lagged. -- pausing for 25624 milliseconds. (18244ms) 22:39:05.013 [..baseapi.WbEditingAction] [maxlag] Waiting for all: 6.46667 seconds lagged. -- pausing for 38436 milliseconds. (28552ms) So it looks like this means no OpenRefine edits at all with these new rules, in the current situation. TASK DETAIL https://phabricator.wikimedia.org/T221774 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, Pintoch Cc: Envlh, Gstupp, Sebotic, Tagishsimon, Liridon, Bugreporter, Magnus, Tpt, Pintoch, Lydia_Pintscher, Matthias_Geisler_WMDE, Simon_Villeneuve, Lea_Lacroix_WMDE, Tarrow, alaa_wmde, Andrawaag, Multichill, Ladsgroup, Smalyshev, fgiunchedi, hoo, Daniel_Mietchen, MisterSynergy, Addshore, Sjoerddebruin, Aklapper, Lucas_Werkmeister_WMDE, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, Iflorez, darthmon_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Chicocvenancio, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, LawExplorer, WSH1906, Lewizho99, Volans, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T221774: Add Wikidata query service lag to Wikidata maxlag
Pintoch added a comment. I am first getting in touch with people who seem to be running bots with maxlag greater than 5 or no maxlag parameter at all, to see if they would accept to follow @Addshore's advice never to use maxlag greater than 5 at all. TASK DETAIL https://phabricator.wikimedia.org/T221774 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore, Pintoch Cc: Envlh, Gstupp, Sebotic, Tagishsimon, Liridon, Bugreporter, Magnus, Tpt, Pintoch, Lydia_Pintscher, Matthias_Geisler_WMDE, Simon_Villeneuve, Lea_Lacroix_WMDE, Tarrow, alaa_wmde, Andrawaag, Multichill, Ladsgroup, Smalyshev, fgiunchedi, hoo, Daniel_Mietchen, MisterSynergy, Addshore, Sjoerddebruin, Aklapper, Lucas_Werkmeister_WMDE, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, Iflorez, darthmon_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Chicocvenancio, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, LawExplorer, WSH1906, Lewizho99, Volans, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240370: Maxlag=5 for Petscan
Pintoch added a comment. I've had a quick look at the code to see if I could submit a patch for this myself but it is not clear to me where the edits are done - I have looked in petscan_rs and wikibase_rs to no avail. Petscan edits might be done in the browser by sending them to some Widar-like interface? TASK DETAIL https://phabricator.wikimedia.org/T240370 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Magnus, Pintoch Cc: Bugreporter, Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T197588: Agree on a "manifest" format to expose the configuration of Wikibase instances
Pintoch added a comment. @Theklan let's move your issue to a different ticket as your issue does not seem to be related: T240436 <https://phabricator.wikimedia.org/T240436> TASK DETAIL https://phabricator.wikimedia.org/T197588 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Theklan, Nikerabbit, Salgo60, Aklapper, Gstupp, Lucas_Werkmeister_WMDE, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240370: Maxlag=5 for Petscan
Pintoch added a comment. @Bugreporter have you got details of where this behaviour is currently implemented in PetScan? In particular, how do you request the current maxlag with the MediaWiki API? TASK DETAIL https://phabricator.wikimedia.org/T240370 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Magnus, Pintoch Cc: Bugreporter, Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240442: Design a continuous throttling policy for Wikidata bots
Pintoch added a comment. If clients are able to retrieve the current lag periodically (through some MediaWiki API call? which one?), then this should not require any server-side change. Clients can continue to use `maxlag=5` but to also throttle themselves using the smoothed function proposed. TASK DETAIL https://phabricator.wikimedia.org/T240442 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T240442: Design a continuous throttling policy for Wikidata bots
Pintoch created this task. Pintoch added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION With the introduction of the WDQS lag in Wikidata's maxlag computation (T221774 <https://phabricator.wikimedia.org/T221774>), we are now seeing the behaviour I feared: bots start and stop brutally as the lag rises and falls. F31469424: maxlag.png <https://phabricator.wikimedia.org/F31469424> https://grafana.wikimedia.org/dashboard/snapshot/mbbjQjo7FMnDAath4tuRyP7F9300Wj2S?orgId=1 This morning, bots which used `maxlag=5` for their edits (as advised) could only edit about half of the time. This start and stop behaviour is not desirable: bots should slow down gradually as the lag increases instead of running at full speed until the lag reaches 5. We should agree on a better throttling policy and implement it in most bot editing frameworks (QuickStatements, Pywikibot, OpenRefine, …) to improve everyone's experience with the service. The current policy looks like this, assuming a default rate of 1 edit/sec: F31469546: currentpolicy.png <https://phabricator.wikimedia.org/F31469546> We could instead try something like this, with a gradual slowdown as soon as maxlag goes above 2.5 sec (half the threshold where it should stop), for instance: F31469548: proposedpolicy.png <https://phabricator.wikimedia.org/F31469548> Would this be a sensible throttling policy to encourage? I believe this should avoid the start/stop behaviour shown above, once such a behaviour is adopted by most bots (which should not be super hard: by patching the most popular editing backends, we should cover most of it). TASK DETAIL https://phabricator.wikimedia.org/T240442 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240442: Design a continuous throttling policy for Wikidata bots
Pintoch added a comment. Thanks! I think dynamically changing the maxlag value is likely to still introduce some thresholds, whereas a continuous slowdown (by retrieving the lag and compute one's edit rate based on it) should in theory reach an equilibrium point. In the meantime, Wikidata is really unusable with mass-editing tools at the moment. It is hard to convince people to respect maxlag=5 when that prevents them from editing half of the time, so I think it would be worth raising the WDQS factor again. We have identified which tools need to comply better, and having a small factor was useful for that. We probably do not want to stay in this state for weeks (Widar is likely to take a long time to get fixed). We might not want to punish the polite ones too hard! TASK DETAIL https://phabricator.wikimedia.org/T240442 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Addshore, Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240370: Maxlag=5 for Petscan
Pintoch added a comment. Thanks for the analysis! Whether this is a breaking change or not is not my concern: Petscan and other mass-editing tools based on Widar should play by the book. I can provide a simple patch which ensures maxlag=5 is applied to all Widar edits: if someone wants to do a refined version which allows specific user-triggered edits to go through without a maxlag parameter, that is great. @Magnus, what is your take on this? TASK DETAIL https://phabricator.wikimedia.org/T240370 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Magnus, Pintoch Cc: Bugreporter, Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T240369: Chase up bot operators whose bot keeps running when the dispatch lag is higher than 5
Pintoch created this task. Pintoch added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION To ensure that Wikidata bot edits slow down when lag is high, we should ensure that bot operators follow the guidelines which recommend to use the `maxlag` parameter with a value no higher than 5. This task tracks efforts towards getting in touch with tool and bot operators to request compliance with this policy. TASK DETAIL https://phabricator.wikimedia.org/T240369 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Pintoch, Aklapper, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T240371: Maxlag=5 for Author Disambiguator
Pintoch created this task. Pintoch added a project: Wikidata. TASK DESCRIPTION Author Disambiguator edits go through even if maxlag is higher than 5, we should fix the code to ensure it complies with the maxlag policy on Wikimedia wikis <https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by using maxlag=5 (or a lower value) on all editing API queries. TASK DETAIL https://phabricator.wikimedia.org/T240371 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ArthurPSmith, Pintoch Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T240370: Maxlag=5 for Petscan
Pintoch created this task. Pintoch added a project: Wikidata. TASK DESCRIPTION Petscan edits go through even if maxlag is higher than 5, we should fix the code to ensure it complies with the maxlag policy on Wikimedia wikis <https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by using maxlag=5 (or a lower value) on all editing API queries. TASK DETAIL https://phabricator.wikimedia.org/T240370 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Pintoch Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T240373: Maxlag=5 for Edoderoobot
Pintoch created this task. Pintoch added a project: Wikidata. TASK DESCRIPTION Edoderoobot edits go through even if maxlag is higher than 5, we should fix the code to ensure it complies with the maxlag policy on Wikimedia wikis <https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by using maxlag=5 (or a lower value) on all editing API queries. Discussion on-wiki: https://www.wikidata.org/wiki/Topic:Vcp3k439ptb0ob0q TASK DETAIL https://phabricator.wikimedia.org/T240373 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Edoderoo, Pintoch Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T240375: Maxlag=5 for LargeDatasetBot
Pintoch created this task. Pintoch added a project: Wikidata. TASK DESCRIPTION LargeDatasetBot edits go through even if maxlag is higher than 5, we should fix the code to ensure it complies with the maxlag policy on Wikimedia wikis <https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by using maxlag=5 (or a lower value) on all editing API queries. TASK DETAIL https://phabricator.wikimedia.org/T240375 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bugreporter, Pintoch Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
