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
<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.
GerardM
On 27 April 2012 12:55, John Blad
<john.blad@wikimedia.de> wrote:
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
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 2 | 10963 Berlin
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.