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