So am I correct to assume that the API only deals with Interwiki links but will be expanded as other phases come on board? I thought the purpose of an API was so that external users can access the labeled data? I guess that would be the WikidataClient?
So we are currently implementing the WikidataRepo which is the internal API call?
For items 8 and 9(setalias and wbsearchbyname):
What is setalias supposed to do? Does it given the site and title refer to them as a alias? Not sure I follow.
What is wbsearchname supposed to do? Based on language selected and the fragment passed, it searches the wikipedia and finds the correct article? Not sure what hints is referring to in this case?
Quoting Gerard Meijssen <email@example.com>:
So far the discussion is about interwiki links in a Wikipedia context.
There are however interwiki links in a Wiktionary context as well. They are
often linked from Wikipedia and they often have information in languages we
do not have an article in or information in languages we do not have a
Consequently I do agree that at this stage it may be out of scope. But the
use case for such a link is compelling.
I blogged about it..
do you think ??
On 27 April 2012 12:55, John Blad <firstname.lastname@example.org> wrote:
>> I was looking at the items which needed to be completed and was
interested in helping out with item #47:
>> How do I go about helping out with this task?
The API as of now is very close to the actual use cases for the UI
relating to phase I, that is inter language links on Wikipedia. This
is important, we implement for the actual use cases, not for a general
API. I guess the API should be somewhat more general and probably
closer to the style used in the current API, but that would increase
the APi focuses on easy set up of the initial user interface and small
calls to do update of that. The code for query modules are removed
(there was initially written a few of them), and it is now impossible
to request items through the query module and filter individual
attributes from Wikidata items.
It could be important to point out that there are in fact two
different API sets; one is for the repo (WikidataRepo) and is the
actual (real) Wikidata site, and one is for the client
(WikidataClient) and this is the Wikipedia sites. There are two
different sets of UI extensions for the web pages that use those two
themselves clients for those servers, but the among the servers one is
the repo and the others are clients for this one.
A page with help and examples in addition to whats reported by the
help module exist on
http://www.mediawiki.org/wiki/Extension:Wikibase/API Note that this
page covers WikidataRepo only.
I'll make an attempt on a ASCII art for an object diagram , but it
will probably fail badly.. ;)
| JS repo lib | | JS client lib |
| WikidataRepo +--o WikidataClient |
Between each of the boxes there is API calls, and some are implemented
while some are not. The underlaying code is simply not in place for
some of the calls.
This is not a very sound solution for other external use, even if it
is possible to (mis)use the API for other use cases. It should be
possible to use the usual query interface, and it should definitely be
possible to use such things as "sitelinks" as generators for further
queries. That is a lot more troublesome than it seems because the
pages referred are actually on other sites. An other interesting thing
that could be implemented is to extend the request for language links
with the sitelinks from Wikidata (WikidataClient API), add and filter
sitelinks for props, list and generator (WikidataRepo API), and add
and filter labels and descriptions for props and list (WikidataRepo
API). Then there is the whole bulk upload issue, but that should be
handled better than the current "setitem", it is basically just a
quick fix to be able to define initial items.
Bulk upload is also something the community must decide upon,
especially wetter it should be allowed to define items for entities
that does not exist in Wikipedia (that is pages in Wikidata that does
not exist in Wikipedia). As long as we are only talking about
sitelinks (inter language links) it is pretty obvious that we do not
want them, but for
If someone wants to extend the API it is probably best to work on
additional functionality that doesn't interfere with the current code,
or to do refactoring and/or cleanup that doesn't change the existing
API calls. If something do change the existing API calls I think it
should be proposed as a feature request and developed in an other
Wikidata-l mailing list
Wikidata-l mailing list