Hi there!
Hi! :)
You sent your initial email to wikidata@lists.wikimedia.org. We're not using that one. Please use wikidata-l@lists.wikimedia.org instead.
I went ahead and used git to download the latest source code, however I didn't see any code related to wikidata?
Did you follow http://meta.wikimedia.org/wiki/Wikidata/Development/Setup ? You want to look for "Wikibase" as that is the name for the extensions.
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?
John (CC'd) is working on that. He might be able to tell more.
I was also looking at the list of bugs from here: https://bugzilla.wikimedia.org/weekly-bug-summary.cgi?tops=10&days=7 Just wondering are these bugs for Wikidata or other wikipedia sites?
There are a lot of bugs in bugs.wikimedia.de related to Mediawiki and its extensions. There is only one so far for Wikidata since we only started at the beginning of the month.
What is the difference between MediaWiki and Wikimedia?
MediaWiki is the software running the Wikipedias and many more websites. Wikimedia is the movement around Wikipedia and its related projects. See also http://en.wikipedia.org/wiki/Wikimedia_Foundation.
Cheers Lydia
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.
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
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
Hi Aniket,
2012/4/30 aniketkarmarkar@aniketkarmarkar.com
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/APIhttp://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 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-wikipedia.**htmlWhathttp://ultimategerardm.blogspot.com/2012/04/wikidata-may-support-what-wikipedia.htmlWhat 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:
Current_scrum_cyclehttp://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/APIhttp://www.mediawiki.org/wiki/Extension:Wikibase/APINote 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-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Sat, 2012-04-28 at 21:43 +0200, Gerard Meijssen wrote:
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.
Perhaps it would be the easiest to simply add the ability to link to other projects, like we now have links to Wikipedia. This would include Wiktionary, Wikisource, perhaps even external projects like OSM. Some items would have links only to Wikipedia ("Berlin, a city in Germany"), some to Wiktionary ("Berlin, a word of English language"), some to both ("Meh").
This is true. But these links should probably be somewhat different than the Wikipedia interlanguage links, and they should be extensible by users. I.e. links to IMDB, to the US statistics office, etc. -- we cannot predict all of these as developers or maintainers. But we know about which language editions of Wikipedia exist.
Cheers, Denny
2012/5/1 Nikola Smolenski smolensk@eunet.rs
On Sat, 2012-04-28 at 21:43 +0200, Gerard Meijssen wrote:
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.
Perhaps it would be the easiest to simply add the ability to link to other projects, like we now have links to Wikipedia. This would include Wiktionary, Wikisource, perhaps even external projects like OSM. Some items would have links only to Wikipedia ("Berlin, a city in Germany"), some to Wiktionary ("Berlin, a word of English language"), some to both ("Meh").
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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.
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l