We eventually got the thing up and running, and imported/cleaned/reconciled data. However, when clicking on "upload edits to wikibase", we see a notification that the edits are being made with a percentage count that goes all the way to 100% (and no error messages at any point), but no changes are actually made in the wikibase (we are trying to add statements with sources to existing items, but the statements are not actually created).
Not sure how this relates exactly, but we found another thread mentioning checking that "localhost:8000/reconcile" works. In our case, it does not. When opening this in Firefox, we get " Not Found. The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again." Note that "localhost:8000" does work.
For what it's worth, the console on the 127.0.0.1:3333 page lists the following errors (not sure any of this is related, but I thought I'd bring it up): [had to add spaces in links because only 2 links are allowed for new users of the fourm]
Uncaught RangeError: radix must be an integer at least 2 and no greater than 36
** commit http:// 127.0.0.1:3333/project-bundle.js:46484
** dispatch http:// 127.0.0.1:3333/project-bundle.js:5147
** handle http:// 127.0.0.1:3333/project-bundle.js:4951
** 7 [project-bundle.js:46484:21](http:// 127.0.0.1:3333/project-bundle.js)
Cookie “NetworkProbeLimit” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. [api.php](https: //www. wikidata. org/w/api.php?callback=jQuery3710954066796702216_1722239422749&action=query&meta=siteinfo&format=json)
Cookie “NetworkProbeLimit” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. [api.php](https: //www. wikidata. org/w/api.php?callback=jQuery3710954066796702216_1722239422749&action=query&meta=siteinfo&format=json)
Cookie “NetworkProbeLimit” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. [api.php](https: //commons. wikimedia. org/w/api.php?callback=jQuery3710954066796702216_1722239422750&action=query&meta=siteinfo&format=json)
Cookie “NetworkProbeLimit” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. [api.php](https: //commons. wikimedia. org/w/api.php?callback=jQuery3710954066796702216_1722239422750&action=query&meta=siteinfo&format=json)
Cookie “WMF-Last-Access-Global” has been rejected for invalid domain. [commonswiki.png](https:// commons. wikimedia. org/static/images/project-logos/commonswiki .png)
Cookie “NetworkProbeLimit” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”. [commonswiki.png](https: //commons. wikimedia. org/static/images/project-logos/commonswiki.png)
Cookie “WMF-Last-Access-Global” has been rejected for invalid domain. [commonswiki.png](https: //commons. wikimedia. org/static/images/project-logos/commonswiki.png)
Cookie “NetworkProbeLimit” has been rejected because it is in a cross-site context and its “SameSite” is “Lax” or “Strict”.[commonswiki.png](https:// commons. wikimedia. org/static/images/project-logos/commonswiki.png)
Here is a screen capture of the process: https:// privatebin. io/?fe07eeb64969b95c#5ZXiMph98ZTfQEe95i8otRSMWk5129hS7Nxx6ShF9i3Z
Any ideas what could be the source of this?
Thanks a lot!
Mike
Thanks for reaching out about this. We are aware that using OpenRefine with non-Wikimedia Wikibase instances is quite complicated at the moment and we are trying to improve that.
To figure out why edits were not made, you have two options:
or install a snapshot release of OpenRefine, which is a preview of the upcoming release of OpenRefine. This includes an improvement we have made recently, which reports Wikibase editing errors in the project grid instead of in the server logs. Once you have re-run your upload operation with this version of OpenRefine, some errors should appear in red in your project.
Once you have access to those error messages (using either methods above), we should be able to understand better what is preventing the edits from being uploaded.
Note that in the snapshot release you will also get a more flexible handling of Wikibase tags, which should fix any problem due to a missing or incorrect tag setup in the Wikibase instance.
Kudos on your recent then, because it's working. For reference to anyone facing the same situation, I would have liked to provide any useful information, but after upgrading there were no error messagew and the data is now on the wikibase. I'll keep testing on other spreadsheets.
The only thing that I can mention is the following. Our upload consisted in the addition of a 560-line spreadsheet. These were 560 statements to be added to 10 different items. While the wikibase now seems to show all relevant statements for all 10 items, the "Wikibase editing results" panels that appears in the left-hand-side column displays "no edit 550, successful edit 10".
I remember reading that edits were grouped (unlike in QuickStatements), so, in a way, 10 edits for 10 items is correct. However, saying that in 550 instances there were no edits is incorrect or misleading. I hope this helps.
Thanks again for the quick help and I'll try and flag anything relevant going forward.
Very happy to hear that this solved your problem! Your point about the 550 "no edit" is a good one, I wonder how to improve that.
A cell in the "Wikibase editing results" column can stay empty for various reasons:
no edit was generated by the schema for this particular row (for instance, because a reconciled cell was not matched)
an edit was generated by the schema but comparing it to the existing data on the Wikibase instance resulted in not making any changes (for instance because the added statement already exists on Wikibase)
an edit was generated but it was bundled with a previous edit, to speed up the upload and save resources on the Wikibase instance
maybe even other cases I can't think of at the moment?!
So one idea would be to change the "no edit" text into something that encompasses more clearly all those cases. But it's not clear to me what text would be better.
Or we could also change the operation so that the cell would not be blank when the edit is bundled up with an earlier one: it could either contain the URL of the edit, or some constant that potentially refers to the row number where the URL of the edit is. This way we'd be able to distinguish between the third case and the others, so that the facet could show them in different categories.