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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id javascript:_e(%7B%7D,'cvml','biyanto.rebin@wikimedia.or.id');
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi
2016-06-09 15:25 GMT+02:00 Julie McMurry mcmurry.julie@gmail.com:
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 likely to thwart legitimate edits and could be abused by moderators.
+1
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.
Let's continue as we did all these years: if something's wrong, just fix it; if something becomes a vandal target, (ask to) protect it.
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 moment we're widely obtaining data from Wikidata directly in Wikipedia articles, as vandalism on Wikidata will be much more worthwhile compared to vandalism on Wikipedia regarding all Wikipedias that use flagged revisions. Providing direct links to the Wikidata item, e.g. in infoboxes (see [1]), will increase this problem also. Vandalism on Wikidata will become much more attractive than it is at the moment.
I still don't have an idea how to avoid the situation that data obtained from Wikidata and used in Wikipedia articles bypasses the flagged revisions. In many Wikipedias, all edits by IPs / new editors have to be flagged as "vandalism free" before they become visible for all readers. Obtaining data directly from Wikidata weakens this principle, as edits on Wikidata are not part of the flagged revisions procedure.
Locking certain statements against changes would solve this problem. As there are many statements that are proven to be true and will never turn false again, it would be very useful to lock these statements. Only trusted users would be able to edit locked statements, then.
Locking items as a whole, however, should only happen if it is necessary due to acute vandalism and should stay a privilege of administrators.
Yellowcard
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 data I imported has already started to become less correct through user edits and bot edits.
On 9 June 2016 at 18:42, Yellowcard yellowcard@wikipedia.de wrote:
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 moment we're widely obtaining data from Wikidata directly in Wikipedia articles, as vandalism on Wikidata will be much more worthwhile compared to vandalism on Wikipedia regarding all Wikipedias that use flagged revisions. Providing direct links to the Wikidata item, e.g. in infoboxes (see [1]), will increase this problem also. Vandalism on Wikidata will become much more attractive than it is at the moment.
I still don't have an idea how to avoid the situation that data obtained from Wikidata and used in Wikipedia articles bypasses the flagged revisions. In many Wikipedias, all edits by IPs / new editors have to be flagged as "vandalism free" before they become visible for all readers. Obtaining data directly from Wikidata weakens this principle, as edits on Wikidata are not part of the flagged revisions procedure.
Locking certain statements against changes would solve this problem. As there are many statements that are proven to be true and will never turn false again, it would be very useful to lock these statements. Only trusted users would be able to edit locked statements, then.
Locking items as a whole, however, should only happen if it is necessary due to acute vandalism and should stay a privilege of administrators.
Yellowcard
[1] https://de.wikipedia.org/wiki/Didier_Drogba
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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 from the assumption that the starting data is perfect, of course it can only get worse. I'm not sure what was your purpose in importing this dataset (is there a page describing the effort?) but you might want to look into another method.
All the datasets I've seen imported on Wikidata have been improved significantly on the wiki. Of course, one has to live with the fact that the dataset will diverge. That's hardly a novel challenge: free software flourishes with forks, and each language edition of Wikipedia has its own version of each article.
Nemo
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 locking single statements against changes by anonymous / very new editors would be a good one.
Federico Leva (Nemo):
All the datasets I've seen imported on Wikidata have been improved significantly on the wiki. Of course, one has to live with the fact that the dataset will diverge.
You probably mean items by speaking of "datasets". Items will diverge and be improved, no doubt. 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 to obtain them and use them directly in Wikipedia. What would be the disadvantage of this, given that slightly experienced users can still edit them and the lock is only a protection against anonymous vandalism?
Yellowcard
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 on wikis is managed needs to reflect that.
On Fri, 10 Jun 2016 17:39 Yellowcard, yellowcard@wikipedia.de wrote:
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 locking single statements against changes by anonymous / very new editors would be a good one.
Federico Leva (Nemo):
All the datasets I've seen imported on Wikidata have been improved significantly on the wiki. Of course, one has to live with the fact that the dataset will diverge.
You probably mean items by speaking of "datasets". Items will diverge and be improved, no doubt. 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 to obtain them and use them directly in Wikipedia. What would be the disadvantage of this, given that slightly experienced users can still edit them and the lock is only a protection against anonymous vandalism?
Yellowcard
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 10.06.2016 12:49, jayvdb@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 differences to how content grows and how editing on wikis is managed needs to reflect that.
This is what I meant when asking for more advanced watching technology. One particularly interesting thing to watch for are cases where the value or qualifiers of a statement is changed, but the reference given is not changed. I think this could be a symptom of a typical misunderstanding by newcomers (the population changed, so we just "edit" it to fix the number, rather than creating a new population value that supersedes the historic one).
Markus
On 10 Jun 2016, at 12:39, Yellowcard yellowcard@wikipedia.de 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 to obtain them and use them directly in Wikipedia. What would be the disadvantage of this, given that slightly experienced users can still edit them and the lock is only a protection against anonymous vandalism?
I agree 100%, and would like to add (again) that this would also make our data more reliable for re-use outside Wikimedia projects.
There’s a huge scala of possibilities between locking harshly (no-one can edit it anymore) and leaving stuff entirely open. I disagree that just one tiny step away from ‘entirely open’ betrays the wiki principle.
Of course I’m in favour of all improvements to watchlist systematics. However, with 100,000+ items I’ll probably be watching at some point, even great tools might not be enough to catch everything. And I’d indeed like to focus all my time on constructive new edits, and advocating the great work we do ;-)
Sandra
I'm thinking about this in relation to importing external data sets and possibly automating keeping the data up to date within Wikidata. To use a practical example the Office for National Statistics https://www.ons.gov.uk/ in the UK produces many of the official datasets about the UK including population, income levels, consumer price index, unemployment rate, etc, there are equivalent organisations in many countries. The ONS produces a new large data set every week, much of which (at least the headline figures) would be very useful to have on Wikidata. It seems unrealistic to keep all this data up to date by hand given the amount of data, the size of the community and the different skill levels and interests within it.
If someone (either within Wikidata or ONS) set up a bot or other system to keep these figures up to date it seems sensible to have some sort of system in place so that if someone wanted to change/merge or delete an item or set of items that were fed by this external data set (either manually or using a bot) that they were at least aware that doing so would break a link keeping the values up to date.
John
On 10 June 2016 at 12:53, Sandra Fauconnier sandra.fauconnier@gmail.com wrote:
On 10 Jun 2016, at 12:39, Yellowcard yellowcard@wikipedia.de 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 to obtain them and use them directly in Wikipedia. What would be the disadvantage of this, given that slightly experienced users can still edit them and the lock is only a protection against anonymous vandalism?
I agree 100%, and would like to add (again) that this would also make our data more reliable for re-use outside Wikimedia projects.
There’s a huge scala of possibilities between locking harshly (no-one can edit it anymore) and leaving stuff entirely open. I disagree that just one tiny step away from ‘entirely open’ betrays the wiki principle.
Of course I’m in favour of all improvements to watchlist systematics. However, with 100,000+ items I’ll probably be watching at some point, even great tools might not be enough to catch everything. And I’d indeed like to focus all my time on constructive new edits, and advocating the great work we do ;-)
Sandra _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 10.06.2016 12:53, Sandra Fauconnier wrote:
On 10 Jun 2016, at 12:39, Yellowcard yellowcard@wikipedia.de 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 to obtain them and use them directly in Wikipedia. What would be the disadvantage of this, given that slightly experienced users can still edit them and the lock is only a protection against anonymous vandalism?
I agree 100%, and would like to add (again) that this would also make our data more reliable for re-use outside Wikimedia projects.
There’s a huge scala of possibilities between locking harshly (no-one can edit it anymore) and leaving stuff entirely open. I disagree that just one tiny step away from ‘entirely open’ betrays the wiki principle.
I don't want to argue about principles :-). What matters is just how users perceive things. If they come to the site and want to make a change, and they cannot, you have to make sure that they understand why and what to do to fix it. The more you require them to learn and do before they are allowed to contribute, the more of them you will lose along the way. If a statement is not editable, then the (new or old) user has to:
(1) be told why this is the case (2) be told what to do to change it anyway or at least to tell somebody to have a look at it (because there will always be errors, even in the "fixed" statements)
These things are difficult to get right.
There is a lot of discussion in recent years as to why new editors turn their back on Wikipedia after a short time, and one major cause is that many of their first edits get reverted very quickly, often by automated tools. I think the reasons for the reverting are often valid, so it is a short-term improvement to the content, yet it severely hurts the community. Therefore, whenever one discusses new measure to stop or undo edits, one should also discuss how to avoid this negative effect.
I completely agree that there is a lot of middle ground to consider, without having to go to an extreme lock-down. However, things tend to develop over time, and I think it is fair to say that many Wikipedias have become more closed as they evolved. I am not eager to speed up this (natural, unavoidable?) process for Wikidata too much.
The pros and cons of flagged revisions have been discussed in breadth on several Wikipedias, with diverse outcomes, so it is probably a tricky thing to settle on a conclusion here.
Best regards,
Markus
+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 hundreds of thousands of items on Wikidata with bots that import data about genes, drugs, and diseases from a large variety of 'trusted authorities'. We have also experienced some frustrations when users make changes that don't fit our views (e.g. there was a thread here about people merging gene and protein items that caused some major headaches for us). But, we resolved it by engaging with the people doing the problematic edits via the talk pages and by adapting our bot code in various ways - both by automatically fixing things that we judged to be clearly broken (producing edits that could be tracked and argued with), by educating community members about why things were modeled the way they were, and by fixing processes that led to the confusion. 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.
Looking ahead, we see that there will be an increasing challenge to keep things in order as more and more people get involved. Figuring out this process will entail a lot of work for us - much more than if the 3 _total_ people that are writing the gene, disease, drug bots currently were left to their own devices to create our own little data warehouse. We are here because we want to be a small part of something much more profound than that - that will take not 3 people in a closed room, but 30,000 people collaborating and fighting it out together. We are a long way from 30,000 here (at least in our part of this). Lets keep the gates as open as possible.
-Ben
p.s. In terms of 'making our data more reliable for re-use'. The formula for me here is (1) get references on statements (2) develop code that automates the processes of checking them, (3) provide the re-user with straightforward ways to filter the data based on the combination of 1 and 2. This can even be accomplished directly inside of Lua code that builds Wikipedia templates from Wikidata - we have already started prototyping that.
On Fri, Jun 10, 2016 at 4:26 AM, Markus Kroetzsch < markus.kroetzsch@tu-dresden.de> wrote:
On 10.06.2016 12:53, Sandra Fauconnier wrote:
On 10 Jun 2016, at 12:39, Yellowcard yellowcard@wikipedia.de 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 to obtain them and use them directly in Wikipedia. What would be the disadvantage of this, given that slightly experienced users can still edit them and the lock is only a protection against anonymous vandalism?
I agree 100%, and would like to add (again) that this would also make our data more reliable for re-use outside Wikimedia projects.
There’s a huge scala of possibilities between locking harshly (no-one can edit it anymore) and leaving stuff entirely open. I disagree that just one tiny step away from ‘entirely open’ betrays the wiki principle.
I don't want to argue about principles :-). What matters is just how users perceive things. If they come to the site and want to make a change, and they cannot, you have to make sure that they understand why and what to do to fix it. The more you require them to learn and do before they are allowed to contribute, the more of them you will lose along the way. If a statement is not editable, then the (new or old) user has to:
(1) be told why this is the case (2) be told what to do to change it anyway or at least to tell somebody to have a look at it (because there will always be errors, even in the "fixed" statements)
These things are difficult to get right.
There is a lot of discussion in recent years as to why new editors turn their back on Wikipedia after a short time, and one major cause is that many of their first edits get reverted very quickly, often by automated tools. I think the reasons for the reverting are often valid, so it is a short-term improvement to the content, yet it severely hurts the community. Therefore, whenever one discusses new measure to stop or undo edits, one should also discuss how to avoid this negative effect.
I completely agree that there is a lot of middle ground to consider, without having to go to an extreme lock-down. However, things tend to develop over time, and I think it is fair to say that many Wikipedias have become more closed as they evolved. I am not eager to speed up this (natural, unavoidable?) process for Wikidata too much.
The pros and cons of flagged revisions have been discussed in breadth on several Wikipedias, with diverse outcomes, so it is probably a tricky thing to settle on a conclusion here.
Best regards,
Markus
-- Markus Kroetzsch Faculty of Computer Science Technische Universität Dresden +49 351 463 38486 http://korrekt.org/
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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 another question for me: How, if at all, are the downstream edits being communicated back to the source databases? Although in some cases the edits will be annotations that the source mightn't care about for their particular user base. But what about factual corrections? Wouldn't they want to know these things and correct them at the source? Perhaps this question belongs in a different thread. I defer to you on that.
Julie
Hoi, 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? Thanks, GerardM
On 10 June 2016 at 19:37, Julie McMurry mcmurry.julie@gmail.com wrote:
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 another question for me: How, if at all, are the downstream edits being communicated back to the source databases? Although in some cases the edits will be annotations that the source mightn't care about for their particular user base. But what about factual corrections? Wouldn't they want to know these things and correct them at the source? Perhaps this question belongs in a different thread. I defer to you on that.
Julie
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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 about the careful lock of only single statements (!) that are not subject to any further changes?
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 specific value in this specific statement?
Of course, what Markus says is important: New users have to be informed properly and in an easy-to-understand way why they cannot change this value, and there has to be a possibility to report errors in "semi-locked statements" (e.g. on a central page).
Locking whole items with infinite length, though, is rarely a good idea, I think there is no dissent about that.
Cheers Yellowcard
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 specific value in this specific statement?
Small wrinkle here: one may want to change it by adding a reference or removing a reference that went stale, or replacing it with an archived version. It is also not out of the question we may add qualifier to it (e.g. if we introduce new qualifier that didn't exist before) or remove one (if we deprecate it, for example). So while the value is not likely to change, other components of the claim very well might.
Hi Stad,
Stas Malyshev schrieb:
Small wrinkle here: one may want to change it by adding a reference or removing a reference that went stale, or replacing it with an archived version. It is also not out of the question we may add qualifier to it (e.g. if we introduce new qualifier that didn't exist before) or remove one (if we deprecate it, for example). So while the value is not likely to change, other components of the claim very well might.
Absolutely – that's why I really mean the value only. Everything else should be easy to be edited by everyone, even though the value might be locked.
Cheers Yellowcard
2016-06-11 1:50 GMT+07:00 Yellowcard yellowcard@wikipedia.de:
Hi Stad,
Stas Malyshev schrieb:
Small wrinkle here: one may want to change it by adding a reference or removing a reference that went stale, or replacing it with an archived version. It is also not out of the question we may add qualifier to it (e.g. if we introduce new qualifier that didn't exist before) or remove one (if we deprecate it, for example). So while the value is not likely to change, other components of the claim very well might.
Absolutely – that's why I really mean the value only. Everything else should be easy to be edited by everyone, even though the value might be locked.
+1
Cheers Yellowcard
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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' mentality that is the underlying cause of many Wikipedia problems. Wikidata can do this.
On Sat, 11 Jun 2016 01:41 Stas Malyshev, smalyshev@wikimedia.org wrote:
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 specific value in this specific statement?
Small wrinkle here: one may want to change it by adding a reference or removing a reference that went stale, or replacing it with an archived version. It is also not out of the question we may add qualifier to it (e.g. if we introduce new qualifier that didn't exist before) or remove one (if we deprecate it, for example). So while the value is not likely to change, other components of the claim very well might.
-- Stas Malyshev smalyshev@wikimedia.org
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Il 10 giu 2016 17:53, "Benjamin Good" ben.mcgee.good@gmail.com 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 also for this exact sentence, which I find truly heartwarming.
I'm dead serious, this is something I try to explain to the many people I meet about how Wikipedia and related projects work. I'm happy to see that I'm not alone - please Markus, don't be offended, but I already knew about you. :)
L.
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 Navino Evans that includes referencing everything to the official site descriptions on the UNESCO website (he's been doing all the actual work, I mainly offer manual labour and make the tea). People have been replacing the official statistics e.g the coordinates submitted to UNESCO as part of the inscription process with coordinates with no references and also merging sites that are not the same thing (usually similar sounding sites in China and Russia). This is annoying for two reasons:
1. Its making Wikidata less accrurate 2. Its breaking our import spreadsheets meaning we have to use queries to guess at possible reasons why things have broken which takes a really long time and then I have to fix them.
Since we completed the import a few days ago the data has already started to drift with manual additions and changes from other users. I wonder if there is some equivalent of the Wikipedia protected page that could be used to reduce this issue? I don't know what this would look like but it seems as though it may be needed. Perhaps another model to use would be the proofreading mechanism from Wikisource?
Thanks
John
On 9 June 2016 at 15:25, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git: jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Or a new right, required to alter a statement that has a citation? On 9 Jun 2016 20:41, "john cummings" mrjohncummings@gmail.com 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 not and merging items that are not the same thing. I have recently been importing information on the UNESCO Biosphere Reserves to Wikidata with Navino Evans that includes referencing everything to the official site descriptions on the UNESCO website (he's been doing all the actual work, I mainly offer manual labour and make the tea). People have been replacing the official statistics e.g the coordinates submitted to UNESCO as part of the inscription process with coordinates with no references and also merging sites that are not the same thing (usually similar sounding sites in China and Russia). This is annoying for two reasons:
- Its making Wikidata less accrurate
- Its breaking our import spreadsheets meaning we have to use queries to
guess at possible reasons why things have broken which takes a really long time and then I have to fix them.
Since we completed the import a few days ago the data has already started to drift with manual additions and changes from other users. I wonder if there is some equivalent of the Wikipedia protected page that could be used to reduce this issue? I don't know what this would look like but it seems as though it may be needed. Perhaps another model to use would be the proofreading mechanism from Wikisource?
Thanks
John
On 9 June 2016 at 15:25, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git: jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Or maybe instead of locking things down, we could do things the wiki way and just make it easier to patrol changes. Value changes to sourced statements could be tagged by AbuseFilter, for example.
-- Yair Rand
On Thu, Jun 9, 2016 at 12:03 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Or a new right, required to alter a statement that has a citation? On 9 Jun 2016 20:41, "john cummings" mrjohncummings@gmail.com 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 not and merging items that are not the same thing. I have recently been importing information on the UNESCO Biosphere Reserves to Wikidata with Navino Evans that includes referencing everything to the official site descriptions on the UNESCO website (he's been doing all the actual work, I mainly offer manual labour and make the tea). People have been replacing the official statistics e.g the coordinates submitted to UNESCO as part of the inscription process with coordinates with no references and also merging sites that are not the same thing (usually similar sounding sites in China and Russia). This is annoying for two reasons:
- Its making Wikidata less accrurate
- Its breaking our import spreadsheets meaning we have to use queries to
guess at possible reasons why things have broken which takes a really long time and then I have to fix them.
Since we completed the import a few days ago the data has already started to drift with manual additions and changes from other users. I wonder if there is some equivalent of the Wikipedia protected page that could be used to reduce this issue? I don't know what this would look like but it seems as though it may be needed. Perhaps another model to use would be the proofreading mechanism from Wikisource?
Thanks
John
On 9 June 2016 at 15:25, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git: jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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, yyairrand@gmail.com wrote:
Or maybe instead of locking things down, we could do things the wiki way and just make it easier to patrol changes. Value changes to sourced statements could be tagged by AbuseFilter, for example.
-- Yair Rand
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 18:03, John Mark Vandenberg jayvdb@gmail.com wrote:
Or a new right, required to alter a statement that has a citation? On 9 Jun 2016 20:41, "john cummings" mrjohncummings@gmail.com 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 not and merging items that are not the same thing. I have recently been importing information on the UNESCO Biosphere Reserves to Wikidata with Navino Evans that includes referencing everything to the official site descriptions on the UNESCO website (he's been doing all the actual work, I mainly offer manual labour and make the tea). People have been replacing the official statistics e.g the coordinates submitted to UNESCO as part of the inscription process with coordinates with no references and also merging sites that are not the same thing (usually similar sounding sites in China and Russia). This is annoying for two reasons:
- Its making Wikidata less accrurate
- Its breaking our import spreadsheets meaning we have to use queries to
guess at possible reasons why things have broken which takes a really long time and then I have to fix them.
Since we completed the import a few days ago the data has already started to drift with manual additions and changes from other users. I wonder if there is some equivalent of the Wikipedia protected page that could be used to reduce this issue? I don't know what this would look like but it seems as though it may be needed. Perhaps another model to use would be the proofreading mechanism from Wikisource?
Thanks
John
On 9 June 2016 at 15:25, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git: jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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 to prevent merges of known-incompatible items - link them to each other (using P1889, not the same as, if in doubt, but any crosslink will work). This will cause attempted merges to fail until the links are removed by hand, which is a fairly good way of making someone have to sit down and consider what they're doing.
If you know that, for example, Nature Reserve X is contained within Administrative District X, and is not the same as Town X, then a good way to prevent accidental merges is to include such statements (and it'll improve the overall data quality as well). It would be awkward (but practical) to throw in a dozen P1889 entries for anything with the same name at the time of upload, if you're confident they're not duplicates...
Andrew.
On 9 June 2016 at 14:40, john cummings mrjohncummings@gmail.com 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 not and merging items that are not the same thing. I have recently been importing information on the UNESCO Biosphere Reserves to Wikidata
with
Navino Evans that includes referencing everything to the official site descriptions on the UNESCO website (he's been doing all the actual work, I mainly offer manual labour and make the tea). People have been replacing
the
official statistics e.g the coordinates submitted to UNESCO as part of the inscription process with coordinates with no references and also merging sites that are not the same thing (usually similar sounding sites in China and Russia). This is annoying for two reasons:
- Its making Wikidata less accrurate
- Its breaking our import spreadsheets meaning we have to use queries to
guess at possible reasons why things have broken which takes a really long time and then I have to fix them.
Since we completed the import a few days ago the data has already started
to
drift with manual additions and changes from other users. I wonder if
there
is some equivalent of the Wikipedia protected page that could be used to reduce this issue? I don't know what this would look like but it seems as though it may be needed. Perhaps another model to use would be the proofreading mechanism from Wikisource?
Thanks
John
On 9 June 2016 at 15:25, Julie McMurry mcmurry.julie@gmail.com 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
protected,
but not locked. Eg implementing a requirement for confirmation by
multiple
editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 it was happened in 2014!
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: language (Q315). Or we just let the Wikidata always
open for
everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (Chair) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git:
jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
-- - Andrew Gray andrew.gray@dunelm.org.uk
+1 for Julie's reply.
I noticed that some Wikidata pages are semi-protected, e.g., Barack Obama. Perhaps, this can be a solution for Biyanto Rebin?
Regards, Fariz
On Thu, Jun 9, 2016 at 3:25 PM, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git: jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
That will be great, I only need some lock in some statement, because I'm planning to add language (700+), place (90.000+) and ethnicity code (+400) in Indonesia. It would be cool if only trusted user can edit the specific statement. I don't need the whole page should be protected, but some specific statement.
IMHO, vandalism in Wikidata is really different with Wikipedia, because if you change one statement, delete or even merge it, it'll be awful.
Best,
2016-06-10 3:29 GMT+07:00 Fariz Darari fadirra@gmail.com:
+1 for Julie's reply.
I noticed that some Wikidata pages are semi-protected, e.g., Barack Obama. Perhaps, this can be a solution for Biyanto Rebin?
Regards, Fariz
On Thu, Jun 9, 2016 at 3:25 PM, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Julie
On Wednesday, June 8, 2016, Biyanto Rebin biyanto.rebin@wikimedia.or.id wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else and it was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi--
mcmurry.julie@gmail.com +1 805 455 5877 skype: mcmurry.julie git: jmcmurry
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 09 Jun 2016, at 15:25, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the measurement of the mass of the electron took years to perfect.
Correct. But then, also, for the history of science it is valuable to know how that measurement has evolved over the years. So you could have something like - mass of the electron has <some imperfect value> / statement with reliable reference and ‘deprecated status' / valid from a certain date till a later date / <- statement protected - mass of the electron has <some imperfect value> / statement with reliable reference and ‘deprecated status' / valid from that later date till an even later date / <- statement protected - etc - (current situation) mass of the electron has <today’s accepted value> / statement with reliable reference and ‘preferred status' / valid from a certain date / <- statement protected as soon as it has its reliable reference - New research? Add a new statement, give it ‘preferred’ status, give the previous one ‘deprecated’ value. Awesome stuff for science historians.
I have seen many frustrating cases of merges and changes to ‘good’ statements too; not all are due to vandalism, some can also be attributed to lack of experience or to agendas, for instance. And having a hard time to keep track of it via my watchlist. I’m very much in favour of a system where we have semi-protection of statements with reliable references, approved by a certain number of trustworthy editors, and editable only by trustworthy editors. (I know this is a very tricky thing to organise…..)
I have a hunch that this would also make Wikidata much more attractive for external parties. In informal discussions with GLAMs, for instance, this issue comes up all the time: how can we really trust that the data on Wikidata is good? Why should we link our own databases to Wikidata and re-use its data if anyone can add nonsense there? Is there a way to indicate that certain stuff on Wikidata is reliable?
Best, Sandra
Yes I agree with this. It would be nice if you could alert the user when a statement is being changed to a previous value. Sometimes people "correct" stuff that needs to be reverted again and again. Some of this is even done semi-automatically by bots (!). So it would at least be nice if bot owners could see these problems, which they can't now.
On Fri, Jun 10, 2016 at 8:46 AM, Sandra Fauconnier < sandra.fauconnier@gmail.com> wrote:
On 09 Jun 2016, at 15:25, Julie McMurry mcmurry.julie@gmail.com 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 protected, but not locked. Eg implementing a requirement for confirmation by multiple editors before it is published. A lock would be too likely to thwart legitimate edits and could be abused by moderators.
Some ostensibly hard facts do in fact change over time. Even the
measurement of the mass of the electron took years to perfect.
Correct. But then, also, for the history of science it is valuable to know how that measurement has evolved over the years. So you could have something like
- mass of the electron has <some imperfect value> / statement with
reliable reference and ‘deprecated status' / valid from a certain date till a later date / <- statement protected
- mass of the electron has <some imperfect value> / statement with
reliable reference and ‘deprecated status' / valid from that later date till an even later date / <- statement protected
- etc
- (current situation) mass of the electron has <today’s accepted value> /
statement with reliable reference and ‘preferred status' / valid from a certain date / <- statement protected as soon as it has its reliable reference
- New research? Add a new statement, give it ‘preferred’ status, give the
previous one ‘deprecated’ value. Awesome stuff for science historians.
I have seen many frustrating cases of merges and changes to ‘good’ statements too; not all are due to vandalism, some can also be attributed to lack of experience or to agendas, for instance. And having a hard time to keep track of it via my watchlist. I’m very much in favour of a system where we have semi-protection of statements with reliable references, approved by a certain number of trustworthy editors, and editable only by trustworthy editors. (I know this is a very tricky thing to organise…..)
I have a hunch that this would also make Wikidata much more attractive for external parties. In informal discussions with GLAMs, for instance, this issue comes up all the time: how can we really trust that the data on Wikidata is good? Why should we link our own databases to Wikidata and re-use its data if anyone can add nonsense there? Is there a way to indicate that certain stuff on Wikidata is reliable?
Best, Sandra
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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" 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 extreme cases (unresolvable disputes, repeated vandalism, etc.) -- never as a precaution to keep out "untrusted" editors from a large number of pages. This would send a completely wrong signal.
The power to edit is the foundation of all Wikimedia projects. It confers to every literate person the capacity to participate actively. Any attempt to shut out some "undesired" users will also reduce the inflow of competent, well-meaning users. It will make our life easier for a while, but it will deeply hurt our progress in the mid and long term. Wikipedia and Wikidata alike are built upon the bet that there are more things to be gained than to be lost by being open. Are we going to win this bet? -- I don't know. But it is our very business model and the thing we are good at. Closing off editing in large scales, even in part (e.g., on all ethnicity codes in Indonesia), would make us gradually change our model to that of a curated database with strong editorial control. There are such databases, and they are doing a good job, but is it not our strength to try to be like them.
Large-scale protection would also create new positions of power and require more governance. Gatekeepers and policies would be needed to ensure that these rights are used "correctly". The control will not be with the people who are asking for protection now (if you are the main editor, you should not also have the power to shut down editing for others). So who knows who will be allowed to edit in the end? Once you have introduced domain-wide statement protection as a valid means to prevent accidental modification by people who are not in a white-list, you can use this instrument for basically everything. They won't need much of a reason to shut you out, since this is the default (everybody but a few experts are blocked) and since a wikisystem always experiences some noise from unwanted edits (so there is always a reason). Such a system would not be a wiki any more.
Similarly, a system where multiple approvals are needed to make a change in a statement would only work if such approvals happen very quickly and reliably. If we can solve this, we can probably solve the vandalism problem too (the thread started with a case of vandalism not noticed since 2014 -- a legit edit that remains unapproved for such a long time would be just as bad). Without speedy approval, editors would again be repelled and our community would suffer.
So with all these issues surrounding protection, how can we still guard our system against random noise and support our expert users in focussing on the content (rather than on keeping off misguided users and vandals)? Here are some ideas of things that could be realised in software:
(1) Statement- and property-level watching for changes (seeing problematic changes should come before disallowing them) (2) Statement- and property-level history (it's currently really hard to find out who last changed a property, e.g., to contact the person or to look at their other edits) (3) Statement- and property-level protection (for the hard cases, mostly temporarily, same policies as for page-level protection) (4) Statement-level patrolling (can I approve a more recent change to P31 without approving an older change to P580?) (5) Query-based watching: if you want to watch all property changes for a large set of articles, you need better tools (6) More work on edit filters (preventing some edits based on content, e.g., the use of shortened URLs as a homepage) (7) Better UIs to prevent accidental edits (e.g., I can see a lot of cases where people have entered qualifier information as new statement values) (8) Further work on easy-to-customise quality analysis and display of related results (the constraint service is great, but hard to use in a targeted way to find errors in a specific area). While data-vandalism can have far-reaching consequences, it also is much harder to hide if the community has the right tools at hand. (9) Better data importing infrastructures (some problems mentioned in this thread seem to be caused by a multi-stage data import approach that only works if nothing changes in the meantime; I am sure one could get this fixed without relying on user-editable data).
Many of these could also be built in external apps. Some of these might give us inspiration for what to do in SQID, for example. Others are quite challenging and may not be so easy to do for technical reasons.
Best regards,
Markus
On 09.06.2016 06:42, Biyanto Rebin wrote:
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 https://www.wikidata.org/wiki/Q879704, the label, description and alias in Indonesian (ID) is vandal into something else andit was happened in 2014 https://www.wikidata.org/wiki/Special:Contributions/202.67.33.46!
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
PS: I'm making WikiProjects Languages in Indonesia https://www.wikidata.org/wiki/Wikidata:WikiProject_Languages_in_Indonesia, anyone who want to join please let me know :)
Best regards,
--
Biyanto Rebin | Ketua Umum (/Chair/) 2016-2018 Wikimedia Indonesia Nomor Ponsel: +62 8989 037379 Surel: biyanto.rebin@wikimedia.or.id mailto:biyanto.rebin@wikimedia.or.id
Dukung upaya kami membebaskan pengetahuan: http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Dear all
I confirm this view:
the way in which Wikipedia is working: The power to edit is the foundation of all Wikimedia projects. Any attempt to shut out some "undesired" users will also reduce the inflow of competent, well-meaning users. Wikipedia and Wikidata alike are built upon the bet that there are more things to be gained than to be lost by being open.
Best regards, Markus
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 warning is sent to the good faith editor who makes the same mistake for the nth time. We should be investigating ways to build tooling to address this issue, as I believe a lot of the mistakes are caused by Wikidata beginners who don't understand Wikidata. Don't forget, the matters are complicated by the fact that most editors don't speak a common language except for the labels on the items and properties they are "edit warring" over. I expect that eventually the need for this will decrease as the number of wikipedians in all language versions slowly get onboarded in the proper use of Wikidata.
On Fri, Jun 10, 2016 at 12:01 PM, Markus Bärlocher < markus.baerlocher@lau-net.de> wrote:
Dear all
I confirm this view:
the way in which Wikipedia is working: The power to edit is the foundation of all Wikimedia projects. Any attempt to shut out some "undesired" users will also reduce the inflow of competent, well-meaning users. Wikipedia and Wikidata alike are built upon the bet that there are more things to be gained than to be lost by being open.
Best regards, Markus
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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 reversions on Wikidata could be avoided when a warning is sent to the good faith editor who makes the same mistake for the nth time. We should be investigating ways to build tooling to address this issue, as I believe a lot of the mistakes are caused by Wikidata beginners who don't understand Wikidata. Don't forget, the matters are complicated by the fact that most editors don't speak a common language except for the labels on the items and properties they are "edit warring" over. I expect that eventually the need for this will decrease as the number of wikipedians in all language versions slowly get onboarded in the proper use of Wikidata.
Hopefully. We also need some stronger inter-language coordination to support this (on a non-technical level). For example, the "allowed" values for P21 (sex or gender) as given in the description and usage guides (P2559) are different from language to language, and do not agree with the values actually used:
http://tools.wmflabs.org/sqid/#/view?id=P21
The usage notes (which exist only in few languages) have more agreement than the descriptions. For example, German is stricter in that it's description asks editors to use the given values *exclusively* but it is more inclusive in that it allows Genderqueer (Q48270) as a value. I wonder if there are even editors who check these discrepancies in the "soft" part that the labels and descriptions constitute.
Markus
On Fri, Jun 10, 2016 at 12:01 PM, Markus Bärlocher <markus.baerlocher@lau-net.de mailto:markus.baerlocher@lau-net.de> wrote:
Dear all I confirm this view: > the way in which Wikipedia is working: > The power to edit is the foundation of all Wikimedia projects. > Any attempt to shut out some "undesired" users will also reduce the > inflow of competent, well-meaning users. > Wikipedia and Wikidata alike are built upon the bet that there are > more things to be gained than to be lost by being open. Best regards, Markus _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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 extreme cases (unresolvable disputes, repeated vandalism, etc.) -- never as a precaution to keep out "untrusted" editors from a large number of pages.
This is not really correct -- it always depends on the critical value of who is considered auch a "trustworty" / "experienced" user.
In my personal view, there should be two different thresholds: The first (high) one for users who can actively lock statements (keep in mind: single statements, not iteams as a whole) and the second one regarding users who are affected by this lock. The second one should be rather low; I'm thinking of the border like semi-protection in Wikipedia (which is, I believe, IPs and users who registered less than four days ago). So everyone who starts to become active on Wikidata reaches the second threshold easily and quickly and will therefore be able to edit also those "locked" statements.
Such proactive limitations are widely used in various Wikimedia projects, thinking of flagged revisions and the possibility of uploading files for example. It wouldn't contradict the wiki principle.
Yellowcard
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 is stored together, so you are actually always edit the whole entity. Which means additional code is needed to filter the watches. Though if the number of watches is small it may be fine.
Additional question is what exactly is "statement"? We do not have any user-exposed identity for statement, and internal identity can change with each edit. So if you edit the statement - for how long it is the same statement as before? (Ship of Theseus problem :)
(2) Statement- and property-level history (it's currently really hard to find out who last changed a property, e.g., to contact the person or to look at their other edits)
Again, due to the above two it may be a bit hard to construct - though we do have diffs, relating diffs to specific statement may be tricky. Property, though, probably is much easier since they have clear identity.
It should be possible at least to have some code allowing to answer questions like "which edit was the last one to touch this property" and "which edits changed this property's statements" though it is not trivial and I don't think it exists now.
(3) Statement- and property-level protection (for the hard cases, mostly temporarily, same policies as for page-level protection) (4) Statement-level patrolling (can I approve a more recent change to P31 without approving an older change to P580?)
This may be possible but I'm not sure it's necessary. The watch approach below may be more effective and more consistent with the project spirit, I think.
(5) Query-based watching: if you want to watch all property changes for a large set of articles, you need better tools
I think a tool that takes a query and creates a list, and allows to: 1. See how the list changes over time 2. Mark some items on the list as "ok" and some as "not ok" 3. Alert people on changes in the list
would make watching for such changes much easier.
(6) More work on edit filters (preventing some edits based on content, e.g., the use of shortened URLs as a homepage) (7) Better UIs to prevent accidental edits (e.g., I can see a lot of cases where people have entered qualifier information as new statement values)
That's a good case for watching too - we have properties that are predominantly used in qualifiers, and even marked so. It should not be hard to make auto-lists with violations and have people to look at it.
(8) Further work on easy-to-customise quality analysis and display of related results (the constraint service is great, but hard to use in a targeted way to find errors in a specific area). While data-vandalism can have far-reaching consequences, it also is much harder to hide if the community has the right tools at hand. (9) Better data importing infrastructures (some problems mentioned in this thread seem to be caused by a multi-stage data import approach that only works if nothing changes in the meantime; I am sure one could get this fixed without relying on user-editable data).
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: language (Q315). Or we just let the Wikidata always open for everyone to edit?
An alternative to "locking" statements is to allow them to be signed by an authority (or, less usefully, anyone). See https://phabricator.wikimedia.org/T138708 for a proposal.
2016-06-30 0:37 GMT+07:00 Daniel Kinzler daniel.kinzler@wikimedia.de:
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:
language (Q315). Or we just let the Wikidata always open for everyone to
edit?
An alternative to "locking" statements is to allow them to be signed by an authority (or, less usefully, anyone). See https://phabricator.wikimedia.org/T138708 for a proposal.
+1 great, thank you for your info :)
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata