The question of Interlanguage links in Wiktionary should probably be revisited once we have it settled for Wikipedia, and once Wikidata is in place.
I am a bit wary of tackling too many open questions at once. Interlanguage links in Wiktionary is something that we have, as the initial development team, deferred to later, as I think that Interlanguage links in Wikipedia will keep us sufficiently occupied for now. I really like going one step after another for Wikidata. I read your blog, and I am looking forward to see it unravel how Wikidata and Wiktionary will play along in due time. Cheers, Denny 2012/4/28 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 > 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 >> >> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >> > > > _______________________________________________ > Wikidata-l mailing list > [email protected] > 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
