Re: [Wikidata] Possibility of data lock

2016-07-01 Thread Biyanto Rebin
2016-06-30 0:37 GMT+07:00 Daniel Kinzler : > Am 09.06.2016 um 06:42 schrieb Biyanto Rebin: > > Now, I'm just curious, will everyone agree if (maybe) in the future > Wikidata > > team can lock some cell that already fix? For example Javanese (Q33549) > = P31: > >

Re: [Wikidata] Possibility of data lock

2016-06-11 Thread jayvdb
The straw man has lots of wrinkles. If we can build AbuseFilter rules, and apply protection (incl. semi-), on granular information, the community can better manage the growth of the data source with a serious attempt at maintaining quality and stability. We need to escape from the 'page'

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Luca Martinelli
Il 10 giu 2016 17:53, "Benjamin Good" ha scritto: > We could have argued that because of our PhDs or whatever, we should 'own' these claims that are "clearly facts...", but that would have been a huge mistake. I'd like to take a moment to thank you for your job, and

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Stas Malyshev
Hi! > More concretely: While the item about Barack Obama as a whole will > probably change ever and ever again, the value of his birthday statement > should never change: The current value is proven to be true and can't > change by its nature. What would be the problem about protecting this >

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Stas Malyshev
Hi! > (1) Statement- and property-level watching for changes (seeing > problematic changes should come before disallowing them) This might be harder to do as it's not really possible - internally - to edit just one statement. It looks like editing one statement, but the data for the whole entity

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Yellowcard
Hi Gerard, > There is another aspect that is not considered. When you lock an item or > a property how is a label in a language added that is still missing? so who exactly talks about locking a whole item or property prophylactically? Wasn't pointed out several times that this discussion is

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Andrew Gray
On the merging point in particular, a problem here is that preemptively saying "don't merge things from this upload" is inevitably going to lead to a different kind of problem - unmerged duplicate items with inconsistent data. Merging is one of our key tools, after all! There is a technical way

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Julie McMurry
I concur both with Markus K and with Ben. What sets Wikipedia apart is its democratic approach. Exerting too much control, especially if in the hands of a "trusted few", is at cross-purposes with the Wiki way and moreover not scaleable. The question regarding edit drift and notifications raises

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Benjamin Good
+1000 to Markus K's main arguments above. Yes noise will be introduced as different people come in to make edits. Administrators locking them out isn't the best way to solve that problem in an open system. There are other options, as he raised - both technical and social. Our group maintains

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Markus Kroetzsch
On 10.06.2016 12:53, Sandra Fauconnier wrote: On 10 Jun 2016, at 12:39, Yellowcard wrote: However, there are single statements (!) that are proven to be correct (possibly in connection with qualifiers) and are no subject to being changed in future. Locking these

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Markus Kroetzsch
On 10.06.2016 12:49, jay...@gmail.com wrote: Wikis also have auto patrolled rights. The fundamental issue here is that modification of a well qualified / sourced statement should be extremely rare as facts rarely change. This is a level of granularity that Wikidata promises to make fundamental

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Markus Kroetzsch
On 10.06.2016 12:20, Jane Darnell wrote: Yes I agree, so I guess I disagree with the idea of a "data lock". I do however, recognize the desire for a "data lock" which arises out of a personal frustration with good-faith Wikidata editor behavior. Many of these unnecessary edits & subsequent

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Sandra Fauconnier
> On 10 Jun 2016, at 12:39, Yellowcard wrote: > However, there are single statements (!) that > are proven to be correct (possibly in connection with qualifiers) and > are no subject to being changed in future. Locking these statements > would make them much less risky

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread jayvdb
Wikis also have auto patrolled rights. The fundamental issue here is that modification of a well qualified / sourced statement should be extremely rare as facts rarely change. This is a level of granularity that Wikidata promises to make fundamental differences to how content grows and how editing

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Yellowcard
Hi! john cummings: > I guess the issue may be different for Wikipedia and Wikidata in that the > size of the community to number of items/articles is very different. That's correct, so flagged revisions wouldn't work on Wikidata, but we need different approaches. I believe that the approach of

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Yellowcard
Hi Markus, Markus Kroetzsch schrieb: > I have read > several people expressing that "only trustworthy" or "experienced" > editors should be allowed to edit certain things. In my view, this is > fundamentally against the way in which Wikipedia is working. Protections > in Wikipedia are used in

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Jane Darnell
Yes I agree, so I guess I disagree with the idea of a "data lock". I do however, recognize the desire for a "data lock" which arises out of a personal frustration with good-faith Wikidata editor behavior. Many of these unnecessary edits & subsequent reversions on Wikidata could be avoided when a

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Markus Kroetzsch
Dear all, Many interesting views were expressed here. I agree that it would be great if we could technically limit protection to certain statements or properties. However, let us be careful not to overuse this. I have read several people expressing that "only trustworthy" or "experienced"

Re: [Wikidata] Possibility of data lock

2016-06-10 Thread Sandra Fauconnier
> On 09 Jun 2016, at 15:25, Julie McMurry wrote: > > How big a problem is fact vandalism? It may be less likely to be > detected/fixed in languages for which there are fewer editors. Only if a big > problem, I'd suggest that specific text (not whole articles) be

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread jayvdb
Absolutely. Is this possible with the AbuseFilter? Is there a project to make AbuseFilter rules for Wikibase JSON easy to write? On Thu, 9 Jun 2016 23:08 Yair Rand, wrote: > Or maybe instead of locking things down, we could do things the wiki way > and just make it easier

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread Gerard Meijssen
Hoi, Given so much weight to references is not good. Many sources are poor including "scientific" sources. In several fields sources are quoted as an excuse to get away with abuse. "Everybody knows that the literature supports this.." it is then said. Thanks, GerardM On 9 June 2016 at

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread Federico Leva (Nemo)
john cummings, 09/06/2016 19:19: I don't know what the solution is but the current situation doesn't seem to work, I spent at least 40 hours (+ Nav's time) to import the 670 items and the data I imported has already started to become less correct through user edits and bot edits. If you start

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread john cummings
I guess the issue may be different for Wikipedia and Wikidata in that the size of the community to number of items/articles is very different. I don't know what the solution is but the current situation doesn't seem to work, I spent at least 40 hours (+ Nav's time) to import the 670 items and the

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread Yellowcard
Luca Martinelli schrieb: > Moreover, there was already a preliminary study on vandalisms on > Wikidata, and it found out that vandalism impact is very low and most > of the vandalisms happen to "sensitive" items such as... FC Barcelona, > Justin Bieber, and the like. ... which will change in the

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread John Mark Vandenberg
Or a new right, required to alter a statement that has a citation? On 9 Jun 2016 20:41, "john cummings" wrote: > I have been experiencing something similar although I would not call it > vandalism, just changing things that are official statistics to something > that is

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread john cummings
I have been experiencing something similar although I would not call it vandalism, just changing things that are official statistics to something that is not and merging items that are not the same thing. I have recently been importing information on the UNESCO Biosphere Reserves to Wikidata with

Re: [Wikidata] Possibility of data lock

2016-06-09 Thread Luca Martinelli
2016-06-09 15:25 GMT+02:00 Julie McMurry : > Only if a big problem, I'd suggest that specific text (not whole articles) be > protected, > but not locked. Eg implementing a requirement for confirmation by multiple > editors before it is published. A lock would be too

[Wikidata] Possibility of data lock

2016-06-08 Thread Biyanto Rebin
Hello, Wikidata is a great collaboration of database, I love it, but sometimes when I encounter some vandalism, it makes me so angry. Just like today, I've found Q879704 , the label, description and alias in Indonesian (ID) is vandal into something else and