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:
>
> 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, 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