Talk:Requests for comment/Wikidata API

Previous page history was archived for backup purposes at Talk:Requests for comment/Wikidata API/LQT Archive 1 on 2015-07-10.

The links for the API samples all point to wikipedia, not wikidata.

The first one (action=wbgetentities) for example, is: https://en.wikipedia.org/w/api.php?action=wbgetentities&sites=enwiki&titles=Marie%20Curie&format=jsonfm So I have to manually change it to wikidata to make it work.

The last one (prop=wikibase) doesn't work whether I change it or not - not sure what the issue is.

I was looking for a way to get the interwiki links for a given wikidata item. It appears that "wbpprop=alias" from this last sample is the solution, but "wbpprop" is an unrecognized parameter.

This is just a proposed RfC, it hasn't been implemented yet. If you want to use the Wikidata API, your best bet is to use the automated documentation at https://www.wikidata.org/w/api.php.

Ok, thanks for the response.

I still suspect that the links were meant to be 'wikidata.org' rather then 'en.wikipedia.org'. Then some of them would work.

Yup, fixed now.

Is this RfC still reasonably up to date, or has time passed it by?

still up to date

Basically this is awaiting the author or another developer who is willing to put time into implementing it, so I'm marking it as abandoned - in the sense that without an active author who can work on it, it's dormant. Anyone else is welcome to take it up and reactivate it and post to wikitech-l when interested in working on it.

In addition to needing someone to actually write the code, this need some kind of buy-in from the Wikidata team.

Wikidata mostly agreed with the proposition, they just don't have the bandwidth to do it.

JeroenDeDauw has mentioned in IRC that it is possible to have multiple entities per mediawiki page in namespace 0. I fail to understand how that is possible based on the fact that the current API returns entities with the same ID as the wiki page name (Q5555). I don't think it is a good idea to even have many entries per one page, but that's a separate issue that might need a separate discussion. Hence, need dev feedback on this. I do understand that query pages (which would be on a non-zero namespace) will contain multiple entities. Query page results should probably work as generators, returning a list of the NS:0 - Q5555 pages.

Apparently its a mistake, there is always a one-to-one mapping between a mediawiki page and an entity like a property or an item

Some parts of the RFC refer to stuff such as labels and aliases but also to sitelinks. The later is Item specific. Does that mean these modules are only supposed to support Items? What about Properties or Queries?

It was decided to let the current wbeditentity address the items this way even if it doesn't match up with properties and queries. I'm tempted to say that we should drop this addressing (that is sitelink) for all modules that sets something. It sort of makes sense for wbgetentities, but why would an external party not know the real identity of the item?

We could go two routes - have two or more independent properties - one that would have all common values found in items, properties, and queries; and other props that have item specific or query specific ones.
Or, we could have one prop for all that would work for all, and return the data relevant based on the type of page. I am inclined to go with the second route as it would be much easier to implement and allow less DB queries, without causing too much confusion by the API users.

The MW API has q lot of design issues an I'm unhappy enough as it is we have to deal with those. The "correct" way to ApiQuery system however seems to introduce one additional issue: binding to a specific DB schema. Anything that introduces such horrid dependencies on details form such a high level component is not going to go in.

As we discussed on IRC, there is no need to use the ApiQueryBase's database access layer by the extension module, so no schema dependency. Moreover, I think we will try to move to an interface-based modules for all extensions, and possibly even refactor the core modules.

I support this idea because:

1. It's more consistent with the basic MW API.
2. It will allow to create more powerful queries using generators

A detail: Wikidata doesn't use the interwiki system for identifying websites. So, I don't know if it's possible to get the item related to "w:en:Application programming interface" in this format. I think that we will have to keep the sites/titles couple of parameters. So we would have a gwdsites=enwiki&gwdtitles=Application_programming_interface. This will make also this new API compatible with the old one with only a change of parameters name.

Answer change: I have modified everything to use "enwiki:Title" format. There is a bug pending to add enwiki and all others as global interwiki links, before the sites table starts being used more. Related langlinks RFC link.