On Wed, Oct 24, 2012 at 7:08 PM, Joan Creus <joan.creus.c(a)gmail.com> wrote: Yay! :) As far as I understood it this isn't really integration but instead implementing this directly in Pywikipediabot. Amir: Can you please clarify? Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Yep, I saw the code and that is completely unrelated to pywikidata. I don't think we should be dividing the efforts, and focus on either of them. I personally think it would be best to keep Pywikidata as a separate project for a while, until pywikidata and wikidata matures. We can't be changing pywikipedia constaly for users to find a broken pywikidata. As I see it, Pywikipedia is already mature and (py)wikidata is still beta. Regardless, I think implementing something like Pywikidata where items are a Python class and properties can be accessed like item.sitelinks["cawiki"] is better than handling directly low-level JSON (like PWB+WD is iirc) or something similar. The library should abstract those things and provide utility functions like wikidata.api.getItemById or wikidata.api.getItemByInterwiki, or whatever. Just some thoughts. Joan Creus. 2012/10/25 Amir Ladsgroup <ladsgroup(a)gmail.com>

Disagreed. Well, maybe everything PWD does can be done via PWB, but -- hey! -- everything done in Python, C++, Java can be done in assembly, right? The purpose of Pywikidata is to provide an easy-to-use interface, removing the hassle of working with the API directly. PWB+Wikidata integration still requires things like: site=wikipedia.getSite('wikidata',fam='wikidata') item.sitelinks["enwiki"] = "Whatever" wikidata.api.save(item, "bot summary if needed") etc. It doesn't require to know that 'language' does not work for sitelinks in the API, but 'site' does, etc. It can also save multiple changes at once, whereas it appears PWB+Wikidata integration does not. (?) Pywikidata is, IMHO, easier to use. I repeat, I think Pywikidata should be merged to Pywikipedia when Wikidata & Pywikidata have matured enough; pywikidata is already mature and the API changes constantly, with Phase II stuff already being introduced. Also, for items, claims, and all this I think an Item class will be needed, to access the properties (it seems yours only allows to save). Joan Creus. 2012/10/25 Amir Ladsgroup <ladsgroup(a)gmail.com > What is the main purpose of pywikidata? Everything it is, it can be done > by PWB > On 10/25/12, Joan Creus <joan.creus.c(a)gmail.com> wrote: > > Yep, I saw the code and that is completely unrelated to pywikidata. > > > I don't think we should be dividing the efforts, and focus on either of > > them. I personally think it would be best to keep Pywikidata as a > separate > > project for a while, until pywikidata and wikidata matures. We can't be > > changing pywikipedia constaly for users to find a broken pywikidata. As > > I > > see it, Pywikipedia is already mature and (py)wikidata is still beta. > > > Regardless, I think implementing something like Pywikidata where items > are > > a Python class and properties can be accessed like > item.sitelinks["cawiki"] > > is better than handling directly low-level JSON (like PWB+WD is iirc) > > or > > something similar. The library should abstract those things and provide > > utility functions like wikidata.api.getItemById or > > wikidata.api.getItemByInterwiki, or whatever. > > > Just some thoughts. > > > Joan Creus. > > > 2012/10/25 Amir Ladsgroup <ladsgroup(a)gmail.com> > >> Lydia is right. I changed PWB to make it run on wikidata. > >> Now i can write a code and integrate data of wikipedia and add it to > >> wikidata DIRECTLY. I say again read this: > >> http://www.mediawiki.org/wiki/Manual:Pywikipediabot/Wikidata > >> >> I suggest we merge pywikidata and PWB > >> >> On 10/25/12, Lydia Pintscher <lydia.pintscher(a)wikimedia.de> wrote: > >> > On Wed, Oct 24, 2012 at 7:08 PM, Joan Creus <joan.creus.c(a)gmail.com> >> wrote: > >> >> Hi all, > >> >> >> >> I've released a new version of Pywikidata @ > >> >> https://github.com/jcreus/pywikidata (not really a release, since > >> >> there > >> >> is > >> >> no version numbering; I should begin, maybe...). > >> > >> > Yay! :) > >> > >> >> New features include: > >> >> >> >> Changes pushed to the server are only the properties which have > >> >> changed. > >> >> This means that it is really faster, and it is the way it should be > >> >> (according to the spec). > >> >> 'uselang' is no longer accepted, per spec. > >> >> Bot flag allowed. > >> >> >> >> Right now there's some more stuff left to do (including adapting to > >> >> changes > >> >> to the API, and adding the claim system [still beta]), but is there > >> >> any > >> >> feature request of something which would be useful for bots? > >> >> >> >> In regards to Pywikipediabot integration I think someone is working > on > >> it > >> >> (thanks!); yet I think it would be better to wait. Pywikipedia is a > >> >> mature > >> >> project and Pywikidata is still evolving constantly (mostly due to > API > >> >> changes, which break it). So I'd wait until Pywikidata has matured > >> >> too, > >> >> and > >> >> Wikidata is deployed to WMF wikis. > >> > >> > As far as I understood it this isn't really integration but instead > >> > implementing this directly in Pywikipediabot. Amir: Can you please > >> > clarify? > >> > >> > >> > Cheers > >> > Lydia > >> > >> > -- > >> > Lydia Pintscher - http://about.me/lydia.pintscher > >> > Community Communications for Wikidata > >> > >> > Wikimedia Deutschland e.V. > >> > Obentrautstr. 72 > >> > 10963 Berlin > >> > www.wikimedia.de > >> > >> > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. > V. > >> > >> > Eingetragen im Vereinsregister des Amtsgerichts > >> > Berlin-Charlottenburg > >> > unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das > >> > Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. > >> > >> >> >> -- > >> Amir > >> >> _______________________________________________ > >> Wikidata-l mailing list > >> Wikidata-l(a)lists.wikimedia.org > >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l > >> > -- > Amir > _______________________________________________ > Wikidata-l mailing list > Wikidata-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l

It's okay, I always said it would be best to merge it ;). But I still think it should wait (I don't care if it's merged now, but I think it would be better to wait; however, do whatever you want). The ID isn't necessary, you also have wikidata.api.getItemByInterwiki (defined in the Wikidata API). In regards to wikidata-is-still-mediawiki: yes, but it is structured data, thus we must treat it as such (much more useful for end users). Maybe the complexity now is low, but then, Claims will appear, and dealing with them in a seperate class would certainly be useful. It might be useful to handle it directly as you said in page.get()? Yes, sometimes. In that case we might provide both options (though I prefer the structured one). (BUT the user should be warned that (s)he is editing JSON data as a string! If (s)he wants to replace "wiki" by "woki", (s)he'll probably break it). Finally, I tried your code and it seems to require the id, also (as in "q320" as page title) :S. Joan Creus.

I svn up'ed 5 minutes before sending the previous mail... Let me check again. Not working :S. Joan Creus.