Shortcut: WD:RATP

Wikidata:Report a technical problem

From Wikidata
Jump to navigation Jump to search

Report a problemHow to report a problemHelp with PhabricatorGet involvedWDQS and Search
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2022/05.

Start a new discussion

Problem when adding quantity statements with tolerance using QuickStatements[edit]


I am currently adding quantity statements with a tolerance (aka uncertainty or margin of error), using QuickStatements. In many cases (but not every time, I would guess in ca. 75 % of the edits), the upper and lower bound are messed up by a number being added in the 15th position after the decimal point. It looks like a datatype issue to me. Examples: [1], [2], [3], [4] and many more. Positive example from the same QuickStatements batch: [5].

The margin of error was entered with one position after the decimal point.

Is this a QuickStatements issue or Wikidata/Wikibase issue? Any idea how to solve this? (BTW, I cannot find too much information about the margin of error for quanitity data in the Wikidata documentation, so please help me if I have missed some documentation besides Help:Data_type/de#quantity.) Thanks, Yellowcard (talk) 09:42, 3 May 2022 (UTC)[reply]

Double-precision floating point only guarantees 15-17 decimal points of precision. The imprecision occurs on your 17th significant digit, which isn't unexpected, but I guess Wikibase shouldn't try to display more digits than can be reliably reproduced. Infrastruktur (talk) 12:30, 3 May 2022 (UTC)[reply]
So it seems to be a Wikibase error, not a QuickStatements error, if I understand your hypothesis correctly?
And is it, according to your explanation, rather a display issue than an editing / data uploading issue? Regards, Yellowcard (talk) 13:20, 3 May 2022 (UTC)[reply]
Add: The automatic edit summary (I am not sure whether it is created by QuickStatements or Wikibase, but I assume it is Wikibase) also contains the tolerance with the weird 17th position. To me, this does not look like a display issue (at least not according to what I understand as a display issue). Yellowcard (talk) 13:22, 3 May 2022 (UTC)[reply]
Had another look and did a quick test to confirm. Since quantity is stored as a string, the culprit is more likely Quickstatements. Don't know why it uses floating-point if Wikibase allows for arbitrary precision. Infrastruktur (talk) 23:15, 3 May 2022 (UTC)[reply]
Thanks Infrastruktur for your help. I also think that this is a QuickStatements issue. However, I don't think that QuickStatements (as an extremely important tool for Wikidata) is maintained well enough to have anyone to fix such bugs (Magnus is just too busy to be capable to do so). Maybe anyone else can fix this?
@ Wikidata dev team: Is it planned to support maintaining QuickStatements at least to hotfix bugs like this one? Yellowcard (talk) 06:10, 4 May 2022 (UTC)[reply]
There’s some previous discussion of this issue at phab:D911 and phab:D948; for the lower and upper bound, it’s unfortunately not easy to solve. Lucas Werkmeister (WMDE) (talk) 11:17, 4 May 2022 (UTC)[reply]
What does that mean in the end? How can I upload a very high number of statements with a given margin of error to Wikidata? QuickStatements seems to be buggy here, is there another solution available? Or is it common sense to refrain from using the errors? (Which would be a pity as the margin of error is very important function for some data such as the average age of a specific plase, like in the given example.) Regards, Yellowcard (talk) 11:48, 4 May 2022 (UTC)[reply]
@Lucas Werkmeister (WMDE): Is there the possibility to apply a hotfix to Quickstatements that cuts away everything after the 15th position or so? Currently I am unsure about hot to proceed, shall I stop uploading the data, shall I upload the data without precision, or shall I simply continue as before even though there is some strange results? Regards, Yellowcard (talk) 14:22, 4 May 2022 (UTC)[reply]
The problem does not occur when the precision is a number without decimal point. So how about a hotfix before a permanent solution will be found: For precision with decimal numbers, the digits last digits are just cut off so the overall number of digits (before and after decimal point) is not bigger than 15. Would that help? Regards, Yellowcard (talk) 09:25, 5 May 2022 (UTC)[reply]
Hello @Lucas Werkmeister (WMDE), do you think that it is realistic to have a QuickStatements hotfix for this issue within the next days? Otherwise I plan to continue the uploads. Thanks and best regards, Yellowcard (talk) 07:09, 10 May 2022 (UTC)[reply]
@Yellowcard: No, I don’t think that’s realistic. WMDE is not responsible for QuickStatements as far as I’m aware – Magnus is the sole maintainer. Whether you should continue the import despite known issues is for you to decide and the community to judge, I’d say. Have you looked for other tools that can import quantities? (It seems OpenRefine can only infer a ±0.5 precision from engineering notation, so that’s probably not enough for your data.) Lucas Werkmeister (WMDE) (talk) 09:02, 10 May 2022 (UTC)[reply]
@Yellowcard: You might want to check out Wikibase-CLI. Infrastruktur (talk) 14:48, 10 May 2022 (UTC)[reply]
@Infrastruktur: Potentially a solution, but I am not a coder. Using the CLI and a complicated syntax to add statements with two qualifiers and a reference seems to be too complicated.
I have a CSV/Excel table, 55,000 datasets, each is one statement with a value, two qualifiers and a reference. Why does it require me to invest days of uploading, being asked to slow down editing by the WD staff, or require me to have my computer running for days? Is it really the state of the art that adding 55,000 datasets is a big project like that, with bugs coming along that are "not realistic" to be solved at all? Sorry for the frustration, and thanks a lot for the tip on Wikibase-CLI. Best regards, Yellowcard (talk) 22:43, 10 May 2022 (UTC)[reply]

Incorrect webiste[edit]

Jaafar Guesmi (Q3156990) has an incorrect website but I cannot manage to remove it and I get an error message linked to anti-spam filtering. Can someone else do it? Moumou82 (talk) 19:30, 9 May 2022 (UTC)[reply]

@Moumou82: Hello, I don't know why you couldn't remove this spam, but I cleaned it. Thank you for the heads up! — Envlh (talk) 19:39, 9 May 2022 (UTC)[reply]

Dangling nodes[edit]

If this query is any indication, it would appear there is no functionality for removing nodes from the triplestore that are no longer connected to anything. Not sure what the extent of this may be, but it's something that would accumulate over time. Infrastruktur (talk) 05:23, 10 May 2022 (UTC)[reply]

Need help with merge[edit]

The item Ludwig Emanuel Schaerer (Q6096135) is the same as Ludwig Schaerer (Q111824419), and the two should be merged. The latter was created by a bot before I had time to come here and create the proper links, and now I've wasted too much time at Help:Merge trying to figure out how to fix it unsuccessfully. Please help! Esculenta (talk) 15:39, 10 May 2022 (UTC)[reply]

Merged. –LiberatorG (talk) 15:57, 10 May 2022 (UTC)[reply]
Thanks! Esculenta (talk) 16:11, 10 May 2022 (UTC)[reply]

Need a way to copy the qid onto clipboard, by clicking on an icon in the UI[edit]

When reviewing wikidata entities for merging, we need a way to copy the qid easily for pasting in the merge dialog later. Right now, we need to go to the URL or the title text and carefully select the qid part. If there an icon in the UI to copy the qid to clipboard, it will be a great help. Arjunaraoc (talk) 07:39, 12 May 2022 (UTC)[reply]

Albin made a tool that allows to copy the Qid to clipboard. - —M@sssly 09:31, 12 May 2022 (UTC)[reply]

QuickStatements Down[edit]

Hello all, QuickStatements background run has been down for more than two days now, see here, can anyone help? Thanks, Yellowcard (talk) 07:24, 13 May 2022 (UTC)[reply]

I've pinged Magnus. --Tagishsimon (talk) 12:05, 13 May 2022 (UTC)[reply]
@Yellowcard: All happy now. --Tagishsimon (talk) 17:43, 13 May 2022 (UTC)[reply]
@Tagishsimon: Great, thank you. Has Magnus fixed this or how did you manage? Yellowcard (talk) 05:58, 16 May 2022 (UTC)[reply]
@Yellowcard: Magnus sorted it. It happens every few months & when alerted - he's on twitter - - he'll restart it. --Tagishsimon (talk) 06:58, 16 May 2022 (UTC)[reply]
Awesome. Thank you very much! Yellowcard (talk) 08:42, 16 May 2022 (UTC)[reply]

URL spam filter exception[edit]

Hello! I'm trying to add a search formatter URL (P4354) statement to Twitter moment ID (P10767), but the spam filter doesn't allow Twitter search URLs. Can this be added by someone higher up?

The URL (Remove the spaces): https:// search ?$1 AntisocialRyan (Talk) 16:24, 17 May 2022 (UTC)[reply]

Problems loading split queries over nested interface[edit]

Hi, has anyone else had this issue? I’m trying to work out how to resolve encryption discrepancies without resetting the interface functions (assuming that’s what the problem is, and I’m pretty sure that’s it). So far I’ve been able to bypass the sorting analytics but it looks like the heuristic framework doesn’t allow for the differential sequence processing that would resolve the issue. Does anyone else have any experience with this? Lostinrace (talk) 15:37, 20 May 2022 (UTC)[reply]