[09:34:52] New review: John Erling Blad; "Only smaller changes, merging this" [mediawiki/extensions/Wikibase] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/29284 [09:34:53] Change merged: John Erling Blad; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29284 [09:44:17] New patchset: John Erling Blad; "Changes to use variant length prefixes and fragments" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/28527 [11:15:17] New patchset: Henning Snater; "QUnit test for template provider" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29557 [11:43:25] New patchset: John Erling Blad; "(Bug 40392) First commit of wbsearchentities [DO NOT MERGE]" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29558 [11:53:08] New patchset: John Erling Blad; "(Bug 40392) First commit of wbsearchentities [DO NOT MERGE]" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29558 [11:53:58] New patchset: John Erling Blad; "(Bug 40392) First commit of wbsearchentities [DO NOT MERGE]" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29558 [12:02:21] New patchset: Jens Ohlig; "New function getFromTerm that searches over both aliases and labels." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/25006 [12:08:26] New patchset: Jens Ohlig; "New function getFromTerm that searches over both aliases and labels." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/25006 [16:27:19] New patchset: Jens Ohlig; "New function getFromTerm that searches over both aliases and labels." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/25006 [16:34:52] some questions: [16:35:26] - why is it now wbgetentities, but still wbsetitem, amongst others? [16:35:26] 04Error: Command “why” not recognized. Please review and correct what you’ve written. [16:36:10] - would you recommend to begin implementing the "claim" system, or is it still too beta? i think (at least in the repo) it's already there, but i don't know the state [16:36:11] 04Error: Command “would” not recognized. Please review and correct what you’ve written. [16:36:13] thanks a lot! [16:36:22] joancreus: i'm asking jeblad to help you [16:36:27] ok, thanks! [16:36:50] i think some things are being changed on the api but not exactly sure the status right now [16:37:08] why is it now wbgetentities, but still wbsetitem, amongst others? [16:37:11] would you recommend to begin implementing the "claim" system, or is it still too beta? i think (at least in the repo) it's already there, but i don't know the state [16:37:19] hi jeblad_WMDE [16:37:19] btw, pywikidata is very helpful to test the api :) [16:37:25] aude: *blush* [16:37:50] wbgetentities is a way to get several entities [16:38:02] wbsetitem is to set a single item [16:38:15] an item is a subclass of entity [16:38:21] jeblad_WMDE: but why not wbsetentity [16:38:22] whops [16:38:35] what else can an entity be? [16:38:51] (i'll read the spec now, don't worry, doesn't matter) [16:38:59] It seems like we will have a wbsetentity, but it is not clear how it will be [16:39:17] an entity can be an item, a property and a query [16:39:26] they are _very_different [16:39:30] jeblad_WMDE: ok. would you begin implementing the claim system? [16:39:32] or rather wait? [16:39:55] we are implementing the claim system [16:39:59] does http://meta.wikimedia.org/wiki/Wikidata/Notes/Data_model_primer still apply, or outdated? [16:40:12] actually a lot of it is already implemented, we are missing the api for it [16:40:18] wikidata-test-repo had wbsetclaim in the api iirc [16:40:24] let me check [16:40:39] * action=wbcreateclaim * [16:40:42] no there are no wbsetclaim there, but it will be [16:41:14] ok. is this documented anywhere? [16:42:18] https://meta.wikimedia.org/wiki/Wikidata/Development/Phase_2_API [16:42:19] another question (sorry): will we be able to add claims from wbsetitem? [16:42:25] or will it have to be done in another request? [16:42:26] prio 0, 1 and 2 is in the current sprint [16:43:29] wbsetitem will probably be able to handle some editing operations, but it is unclear which one [16:44:16] Its on the list to change its name to wbeditentiy, so make a guess how it will work [16:44:18] ;) [16:44:25] ok, finally: i guess when i call wbsetitem with &clear, it is a lot of work & db quries for wikidata. would you like it to be implemented via wbsetlanglink, in multiple requests, or is it no problem? [16:44:57] or without clear, and letting pywikiadta do the "delta" of what has been changed/removed/added [16:45:17] call to wbsetitem with and without clear is virtually similar [16:46:07] oh ok [16:46:09] You should generally _NOT_ use clear unless the purpose is to wipe out the content and start from scratch [16:47:15] In my opinion the clear parameter should not be there [16:47:29] jeblad_WMDE: i implemented it that way, because then i can simply overwrite everything. else, in case any was removed, i would have to add a 'removed' parameter and it would be slower to implement [16:47:31] programmer laziness [16:47:43] i will change it some day, to use python's __getitem__ in an elegant way [16:47:59] and create a dictionary-like object tracking changes [16:48:27] You should not track changes to try to update complete objects [16:48:35] You should add incremental changes [16:48:56] jeblad_WMDE: in multiple edits? [16:49:14] if there are an initial 200+, the recent changes would be overcrowded [16:49:33] maybe in individual edits if n < 10? [16:50:04] If you have 200+ changes submit it as one, but do not use clear [16:50:39] With clear you say your 200+ edits also contain editing of whatever else is in the item [16:51:08] i see [16:51:16] If your purpose is to change 200+ sitelinks and you add clear you will nuke the rest of the item [16:52:35] jeblad_WMDE: the latest behavior of wbsetitem (it was changed several times) is to extend, right? (unless a 'remove' parameter is added to whatever property, then such property is removed) [16:52:35] To say it another way, you are not the only one editing the item, no mater how fast you are trying to go. It will always be other editing at the same time and then there will be edit conflicts. [16:54:21] The default behavior is to set a value, to remove it you will have to add a remove marker [16:55:18] ok! sorry for so many questions, thanks a lot! [16:55:33] The add behavior is rather weird and is there because in some cases we have lists and we don't want users to set the whole list [16:56:11] We want the incremental update thingy to work for all properties, also for aliases [16:57:01] We have put a lot of work into getting the update thingy to work, but we still have some problems left [16:57:45] jeblad_WMDE: looking at the api spec, it seems wbsetitem'ing aliases works? [16:57:58] http://localhost/repo/api.php?action=wbsetitem&id=5&data={"aliases":{"en":[{"language":"en","value":"A"},{"language":"en","value":"B"},{"language":"en","value":"C"}]}}&format=jsonfm [16:58:08] That is, we can detect edit conflicts and in theory we can generate patches on the fly that makes us survive quite complex edit conflicts [16:59:05] yes, that should grow the list of aliases [16:59:19] ok [16:59:54] *away for a while [17:00:05] https://bugzilla.wikimedia.org/show_bug.cgi?id=41309 [17:01:53] Reedy: interesting [17:01:53] Oh, that model... :D [17:02:09] * jeblad_WMDE runs home [17:16:32] New patchset: Henning Snater; "Refactoring of option handling" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29609 [17:30:33] New patchset: Daniel Werner; "Change EditableValue constructor to take interfaces" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29612