Hi Aniket, 2012/4/30 <[email protected]>
> 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? > > It is correct. The API is now dealing with interlanguage links. > So we are currently implementing the WikidataRepo which is the internal > API call? > > Yes, this is what is currently happening. > > http://www.mediawiki.org/wiki/**Extension:Wikibase/API<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. > > An alias is an alternative label for an item. E.g. "George Bush" would be an alias for the item about George H. W. Bush. > 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? > > It does not search Wikipedia, but Wikidata. So given "New Y" it might find the item about New York. Hints is meant for later use, and could be a hint like the category of the searched for items, like, in this case, city, but is currently underspecified. > Thanks! > Aniket > > > Cheers, Denny > > > Quoting Gerard Meijssen <[email protected]>: > > 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-wikipedia.**htmlWhat<http://ultimategerardm.blogspot.com/2012/04/wikidata-may-support-what-wikipedia.htmlWhat> >> do you think ?? >> Thanks. >> GerardM >> >> On 27 April 2012 12:55, John Blad <[email protected]> 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<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<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 >>> [email protected] >>> https://lists.wikimedia.org/**mailman/listinfo/wikidata-l<https://lists.wikimedia.org/mailman/listinfo/wikidata-l> >>> >>> >> > > > ______________________________**_________________ > Wikidata-l mailing list > [email protected] > https://lists.wikimedia.org/**mailman/listinfo/wikidata-l<https://lists.wikimedia.org/mailman/listinfo/wikidata-l> > -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 2 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
