Page MenuHomePhabricator

allow to exclude selected claims from wbgetentities (or state positively which properties you want)
Closed, DeclinedPublicFeature

Description

see https://www.wikidata.org/w/api.php?action=help&modules=wbgetentities

https://www.mediawiki.org/wiki/API:Presenting_Wikidata_knowledge says

<<... wbgetentities has no means to specify which properties you want, instead you request all claims about the entity ...>>

https://www.wikidata.org/wiki/Q83835 (Swiss Federal Railways - SBB) breaks getEntities() / simplify() has a huge number "owner of" (P1830) statements (a lot of railway stations).
that cause the wbgetentities to get quite slow and the response very big.

It would be very helpful to be able narrow down what is returned

Event Timeline

Bean49 subscribed.

Many Wikibase items have many statements. Many tasks deal with only one or few properties. It would considerably improve performance, traffic and load if it were a possibility to filter properties in the same manner as languages and sitefilter, especially when getting 500 entities at once.
It would be very useful to add a parameter properties or similar and allow values like P31|P1082|P939 to filter the returned data.
There is something similar for wbgetclaims.

Bean49 changed the subtype of this task from "Task" to "Feature Request".Nov 11 2023, 6:25 PM
Lydia_Pintscher subscribed.

We are now putting the limited resources we have into the new REST API and I fear we'll not be able to spend time on this. The ability to do what is asked for here was added to the REST API in T309021. More details about the REST API can be found here: https://www.wikidata.org/wiki/Wikidata:REST_API

@Lydia_Pintscher It's not the case. How can you download the _P131 property of 1800 items with only 4 requests? Either you have to do 1800 requests, or download tons of data you use for nothing. This would not be for my convenience, it would be better for Wikimedia servers and resources. Did you take into account? Are you aware how big the items have grown? What a small percentage of total download the bots use?

I think this request was closed without addressing the issues reported in it.

Stewards/maintainers/owners of the codebase decided not to fix this very ticket, thus reflecting that decision.

What are the recommendations of stewards/maintainers/owners of the codebase regarding the issues? Either workaround is not desirable.

wbgetentities has no means to specify which properties you want

That’s because there’s a separate wbgetclaims module which already has this feature. (Though it currently only supports one property.) Example: https://www.wikidata.org/w/api.php?action=wbgetclaims&format=json&entity=Q64&property=P31&formatversion=2

That's true, but you cannot get 500 entities at once, it remains the problem that you have to do 1800 requests in my previous example instead of 4. Is this not a problem?

Could someone with expertise state that understands the problem and indicate which workaround is less worse?

  1. make 1800 API requests instead of 4
  2. use a very low percentage (1-15%) of downloaded data, increasing network traffic with no use

We could easily resolve this with a new filter parameter.
Thank you.

It's possible to add a comment without changing the status. Thanks. :)

@Aklapper Why do you close it? No one addressed the reported issues. I don't understand. Why would anyone report anything if you close it without answering? Could you please clarify or answer my previous questions. Thanks.

Could someone with expertise state that understands the problem and indicate which workaround is less worse?

  1. make 1800 API requests instead of 4
  2. use a very low percentage (1-15%) of downloaded data, increasing network traffic with no use

We could easily resolve this with a new filter parameter.

That might very well be true but as I've said earlier we are spending the very limited resources we have on the Wikibase REST API.

Thank you.

Depending on what you actually want to achieve it might be easiest to get the result from a query to query.wikidata.org but it's hard to say without more context.