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(a)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(a)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(a)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(a)wikimedia.or.id
>> ~~~~
>>
>> Dukung upaya kami membebaskan pengetahuan:
>>
http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi
>
>
>
> --
> ----------------------------------
> mcmurry.julie(a)gmail.com +1 805 455 5877 skype: mcmurry.julie git:
jmcmurry
----------------------------------
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
--
- Andrew Gray
andrew.gray(a)dunelm.org.uk