interested in helping out with item #47: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

interested in helping out with item #47: http://meta.wikimedia.org/wiki/Wikidata/Development/Current_scrum_cycle 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l