It's been over a year and a half, and these JavaScript errors are still occurring…

The way we're modeling those kind of things right now is like this: https://www.wikidata.org/wiki/Q2345#P1552. What I don't know is if it's this way just because we can't have different labels or because someone thought it was better using properties instead of labels. Anyway if we decide to change it and use the labels instead there are currently a few others using the same strategy as in Spanish: https://w.wiki/BZ55

The community has already stated three years ago that an endpoint with authentication would see very little traction because it just won't be used for building tools (because of the authentication hurdle). Obviously running it for three years and the little traffic it has received proves exactly that point.

Note that the Search Platform team is only the technical maintainer of this service. We're not in a position to make any decision on how it should be used or how it should evolve. What we can say, is that it seems to be a very risky proposition to remove authentication without having a medium term plan on how to support this service. To make any progress, there need to be a longer term strategy.

[The above comment is removed given some other discussion that is going around on this topic]

WCQS seems to be the main way to access that data

There are multiple other ways to access structured data:

• Via CirrusSearch, already possible but see T76011: commons file search that includes structured data for UI integration.
• Via Lua modules on Commons. This will allow users to build templates such as infoboxes from structured data (e.g. T354016). Note without carefully design such templates will be unscalable by itself (T354016#9474992, T343131)

No, don't. SPARQL endpoints should be authenticated, especially the SPARQL endpoints by Wikimedia. T297995 should be resolved. This proposal is just a very bad work around to replace an even worse work around (https://commons.wikimedia.org/wiki/Commons:SPARQL_query_service/API_endpoint)

Just remove the damn authentication. T297995 has been open for three years. You have been running a quite stable, but also quite useless service for the past three years. It's extremely demotivating that I and other volunteers spend time on importing and adding structured data, but I can't properly query it. It's the primary reason why I haven't really added a lot of new things over the last years.

Aha, thanks @Legoktm. Perhaps we could

a) get stats on non-monitoring usage [to confirm that this is low], and 
b) turn off auth for a month to see how usage changes?

In T297995#9695199, @Sj wrote:

Usage seems surprisingly steady at 2.5-3 q/s, is there any information about how it's currently being used?

Some search operator setting should show all images like it's the case with MediaSearch so this can be used e.g. in the template

I'll let StructuredDataOnCommons and @AUgolnikova-WMF weight in on the expected behaviour. Please ping Search Platform if a decision is reached.

Change #1069624 merged by jenkins-bot:

[pywikibot/core@master] Add title function to MediaInfo.

https://gerrit.wikimedia.org/r/1069624

Change #1069624 had a related patch set uploaded (by Aurorakiitaja; author: Aurorakiitaja):

[pywikibot/core@master] Add title function to MediaInfo.

https://gerrit.wikimedia.org/r/1069624

Change #1063025 merged by jenkins-bot:

[pywikibot/core@master] Add tags to the wikibase functions in Pywikibot

https://gerrit.wikimedia.org/r/1063025

I agree having a wrapper around DataSite.save_claim would be useful. I just disagree with the proposed solution. There is no point in adding this method to MediaInfo since DataSite.save_claim does not need the entity object at all.

Currently using it for edits like https://commons.wikimedia.org/w/index.php?title=File:John_Meintz,_punished_during_World_War_I_-_NARA_-_283633_-_restored.jpg&diff=prev&oldid=909842445 where I add missing qualifiers to an existing claim. ( self.site.save_claim(claim, summary=summary, tags='BotSDC') )

We don't have ItemPage.changeClaim either. DataSite.save_claim is wrapped around by Claim.changeRank, and there is also Claim.changeClaimTarget which should already work for all entity types.

Change #1063025 had a related patch set uploaded (by Multichill; author: Multichill):

[pywikibot/core@master] Add tags to the wikibase functions in Pywikibot

https://gerrit.wikimedia.org/r/1063025

As I tried to explain on Telegram, you’re mixing two different things. Linking to another entity in a WikibaseRepo statement is not the same as using an entity in WikibaseClient. Usage tracking is only for the latter ({{#statements:}} and {{#property:}} parser functions, Scribunto/Lua data access), not for the former. As a random example, Q48143124 links to Q48378445 in a statement, yet Q48378445’s subscribers don’t include wikidatawiki. Likewise, as far as I know, Structured Data on Commons statements aren’t tracked as entity usage, neither in wb_changes_subscription on Wikidata nor in wbc_entity_usage on Commons. (The fact that wb_changes_subscription had a row anyway is probably a redirect-related bug due to statement usage from the redirect target, I think.)

Connecting this task to T362149: Alternative, affordable, lower-barrier approach(es) to reconciliation. Reconciliation will be a key part of this effort and this will be a great opportunity to have impact by researching more flexible and affordable approaches to that functionality.

In T241053#9996056, @Catrope wrote:

In T370378 we're discussing potentially broadening the scope of gil_to to any pages rather than just files, so maybe we could normalize gil_to to a linktarget instead, and solve both this task and that one at the same time.