Hi John,
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?
http://www.mediawiki.org/wiki/Extension:Wikibase/API 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?
Thanks! Aniket
Quoting Gerard Meijssen gerard.meijssen@gmail.com:
Hoi, 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 Wikipedia in.
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.. http://ultimategerardm.blogspot.com/2012/04/wikidata-may-support-what-wikipe... do you think ?? Thanks. GerardM
On 27 April 2012 12:55, John Blad john.blad@wikimedia.de wrote:
I was looking at the items which needed to be completed and was
interested in helping out with item #47:
http://meta.wikimedia.org/wiki/Wikidata/Development/Current_scrum_cycle 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 code somewhat in Javascript and we currently does not need it. Now 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 different sites. The Javascript libraries sees a server and are 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 | +------o------+ +-----o---------+ | | +-------+------+ +-------+--------+ | 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 branch.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l