The issue is not reproduced anymore (example of edit: https://datalib.wikibase.cloud/w/index.php?title=Item:Q1&diff=31234&oldid=29566). I think the task can be closed. Thanks very much!

Just to mention the gadget relateditems, which allows to show inverse statements automatically if enabled in the Preferences: https://www.wikidata.org/wiki/MediaWiki:Gadget-relateditems.js

(I report two blog posts about the issue: https://blog.factgrid.de/archives/3467 and https://blog.factgrid.de/archives/3541)

(I have opened https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Improve_Wikidata_handling_of_duplicate_references_in_model_and_UI regarding this issue.)

Maybe the best solution would be adding a parameter to the constraint allowing the user to specify if, for that specific property, "mul" should be taken into account or not. This would be the most flexible solution IMHO.

In my opinion it is highly probably related to T325871 (as I said in my comment of June 7).

I forgot to to write it here, but the issue disappeared more than one month ago. I close the ticket accordingly; I will reopen of course if it happens again.

I have checked again today in https://hypotheseis.wikibase.cloud/wiki/Main_Page and the problem has disappeared; it also doesn't appear in other Wikibase instances on which I have been editing in the last days. So I close the ticket; I will reopen it if it happens again (hopefully not).

@Fring in the above example the precise message I get for the error is:

Illegal value: http://mw138test.wikibase.dev/entity/Q2

Could it be that the problem is that http://mw138test.wikibase.dev/entity/Q2 is a malformed URI, due to the fact that all the URIs on Wikibase Cloud instances have https (i.e. https://mw138test.wikibase.dev/entity/Q2 would be correct)?

It can be reproduced in https://mw138test.wikibase.dev/tools/quickstatements/#/ using:

This has been solved by the same patch which solved T365916; thus I close the ticket.

I tried again today and all the three cases work perfectly as in Wikidata; probably when I tried yesterday afternoon the fix had not been deployed yet on the Wikibase Cloud instance I was using (i.e. https://datalib.wikibase.cloud/).
Thanks very much for the fix!

As of now, in cases 2 and 3 the command is skipped by QuickStatements giving "Error!"; so the edit which should be saved by these commands are not saved; this is highly problematic. Hovering on the errors I get no further information. To be clear, in cases 2 and 3 _edits need to be saved_ (in case 2 the edit should add a further value of a property already having one or more values; in case 3 the edit should add a qualifier to an existing value)

Not exactly. Above I wrote:

It seems that unfortunately the fix didn't solve the issue, although I notice a change: once the batch encounters one of the 3 cases described above, before today it remained stuck in "run" status, whilst now it gives an "error" with no motivation and goes to the next edit. But effectively it is not yet able to save correctly the edits in cases 2 and 3 (for case 1 no edit should be saved, so, although seeing an unnamed error is not ideal and it would be better do see instead "done!" with the message "the value already exists", the present situation is fine because the main issue was the batch being stuck).

In my experience of today, QuickStatements on Wikibase Cloud instances is able (given a property Y with datatype string) is able to create one statement PY:value (if the item has no other values of PY already in itself); however, QuickStatements is unable to create a second value for PY in the same item, or to add qualifiers to the existing value(s) of PY. See T365916 about this.

MediaWiki:Sidebar in specific Wikibase Cloud instances can be edited, as far as I can see; e.g. I have edited the one in my instance, https://hypotheseis.wikibase.cloud/wiki/MediaWiki:Sidebar

Effectively no (at least as of now), the only problem I see is "IDs not being as predictable as they could be".

I confirm, it was my mistake; no triple is missing from the query service right now; thanks for the correct query and excuse for the disturb!

I have created https://hypotheseis.wikibase.cloud/wiki/Main_Page on 27/03/2024 and from that moment the issue has always been around.

After the solution of T347023 this seems solved too: in Wikibase Cloud the prefixes aren't removed, whilst in Wikidata they are removed and in the queries they are substituted by the full URIs; so in both the problem is fixed.

I confirm that the autocomplete (both in the search bar and while editing) of hypotheseis.wikibase.cloud has never had issues (as of now); the problem only affects Special:Search.

The service is not working perfectly: qualifiers and references aren't loaded in the query service, as well as statements not having best rank.

Solved by T361551

I have edited the task to make it more general. I experience the same issue in https://hypotheseis.wikibase.cloud/query/ - I created the instance on 28 March 2024 and as of now the Query Service still has no triples in itself.

Although it is probably superfluous, I add that the same issue happens not only on English Wikipedia, but also on Wikidata, Italian Wikipedia and probably other wikis.

If I understand correctly, this would mean having e.g. https://database.factgrid.de/entity/ instead of wd: inside the queries, and no prefixes at the start of the queries; such a solution would not be an improvement, since it would make the queries much longer and, what is most concerning, much less readable, since prefixes significantly improve readability.
I think that the easiest fix should be simply avoiding that the "format query" button erases prefixes.

Thanks. I retried the previous one changing "query" into "sparql", but something is still mistaken: https://w.wiki/7NTz gives error 500 ... I don't have an answer from NLG yet.

Thanks! I checked with an easy one, https://w.wiki/7Mv3, and it fails due to

I edited the task to make it clearer. So, two statements X could be surely merged only if they have exactly the same qualifiers (e.g. X + qual. A with X + qual. A) or if one has qualifier(s) and the other has no qualifiers and no references (e.g. X + qual. A with X without qualifiers and references). Presently, the Merge process keeps X with qualifiers and X with no qualifiers and no references separated, which should be avoided.
Of course X with qualifiers should not merged with X with no qualifiers but one or more references, since the references could or could not support the qualifiers. I hope it's clear enough.

We need to reinforce our action to convince the most important databases in accepting, in a standard way, reports from Wikidata users. Recently, e.g., BNF started refusing any mistake report: https://www.wikidata.org/wiki/User:CaféBuzz/BNF. P.S. Today this ticket turns one!

In my opinion this is a serious problem, since it falsifies a relevant amount of the dates extracted from Wikidata items through queries; and it is impossible to extract native Julian dates, but they can only be extracted in their conversion to Gregorian dates (that, being automatic, can be sometimes faulty). The solution proposed, viz. keeping Julian date in psv: and adopting psn: for automatic Gregorian conversion, seems very good to me.
If there is no objection, I think this ticket should be raised to high priority.

Maybe this should be merged with T276876. I would suggest also adding T209559 as parent task.

Note: the problem of symmetric and inverse properties presently is solved through JS gadgets: https://www.wikidata.org/wiki/User:Magnus_Manske/consistency_check.js and many enlarged forks, most notably https://www.wikidata.org/wiki/User:Frettie/consistency_check_add.js, https://www.wikidata.org/wiki/User:JonnyJD/consistency_check.js, https://www.wikidata.org/wiki/User:Xmlizer/consistency_check.js.

Hi! I tried https://w.wiki/6i4V but I obtain the error "Service URI http://digitale.bncf.firenze.sbn.it/openrdf-workbench/repositories/NS/query is not allowed". I'm not sure about the reason.

See also https://www.wikidata.org/wiki/MediaWiki_talk:Gadget-Merge.js/Archive_6#Request_of_improvement:_merging_qualified_and_not-qualified_IDs (the problem affects also the gadget merge.js).

See this bot request, aiming to remove redundant aliases https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/Bitbotje_2.

As an example of massive removal of redundant aliases, see edits by user Bitbotje today (e.g. https://www.wikidata.org/w/index.php?title=Q1415472&diff=prev&oldid=1839731916, https://www.wikidata.org/w/index.php?title=Q1470646&diff=prev&oldid=1839734646, https://www.wikidata.org/w/index.php?title=Q1468693&diff=prev&oldid=1839734526).

Historical note: this develops an idea first proposed in 2022 for the Community Wishlist Survey (https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Wikidata/Dedicated_section_for_everything_meta_on_item_pages).

Historical note: this develops an idea first proposed in 2020 for the Community Wishlist Survey (https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata/Display_reference_in_edit_summary_when_a_reference_is_added).

Probably related with T327815.

On Wikidata lots of CSRF invalid token errors in these minutes.

Example: if the label is edited so that it becomes the same as an existing alias (https://www.wikidata.org/w/index.php?title=Q11906650&diff=1778265038&oldid=1604959354), we lose a valid name of the entity because the edit isn't rejected. In cases of massive edits through QuickStatements or OpenRefine, this could cause some damage.

Note: as of now MatSuBot (operated by @matej_suchanek) only merges claims of date of birth (P 569) and date of death (P 570); while the range of properties treated by the bot can be extended (see https://www.wikidata.org/w/index.php?title=Topic:Wxspna7q8jnn17u8), this means that as of now cases of duplication in other properties with datatype "time" (62 in total, so 60 properties) are remaining not treated.

See related T159160, mainly T159160#3096928.

This task was discussed in the Bug Triage Hour at the Wikidata Data Quality Days 2022.