On Fri, Sep 16, 2016 at 10:05 PM Luca Martinelli <martinelliluca@gmail.com> wrote:
2016-09-15 14:09 GMT+02:00 Jan Dittrich <jan.dittrich@wikimedia.de>:
> 2016-09-14 11:47 GMT+02:00 Magnus Manske <magnusmanske@googlemail.com>:
>> I found people opposed to Listeria lists (in article namespace) for two main
>> reasons:
>>
>> * The list is wikitext, so it /looks/ like one can edit it, but then it gets
>> overwritten by a bot. If the wikitext representation of a list were just a
>> parser function or extension tag, that problem would not appear (nothing to
>> edit)
>
> Thanks! This is very helpful for me.
>
> The wikitext overwriting is a good point and it is easy to understand that
> this leads to confusion.

Still, there's a notice that warns people that "Edits made within the
list area will be removed on the next update!". Moreover, this is not
entirely "new" to, say, Italian Wikipedia, where we already have
"automated pages", i.e. lists filled in by bots. I'm not
underestimating the possible confusion, I'm just weighing pros and
cons, and the former outweigh the latter IMHO.

Let me do an example: do we *really* think this is a problem, say,
with the list of Prime Ministers of the Kingdom of Sardinia (a title
bestowed from 1848 to 1861)? Editing such list would be virtually
useless, except for a bunch of coherence edit (adding an image, fixing
a link) that ListeriaBot can do on its own every $time. Not just on
one wiki, but on ALL wikis.

The only problem that comes to my mind is a table with wrong data in
it -- this is not a problem that ListeriaBot can solve, but a problem
that can help bring to the surface, so again... profit?

The overwriting of human edits was the main "violation of the rules" that led to the banning of Listeria bot on German Wikipedia for the article namespace. I think someone actually made an IP edit just to have it overwritten on the next update, then point to the "evil bot action". Ah, such is luddites.
 

2016-09-15 16:53 GMT+02:00 Navino Evans <navino@histropedia.com>:
> The main issue that comes up for me with Listeria is with the 'section by property' feature. There is currently no control over how it deals with multiple values, so a simple list of people sectioned by occupation can lead to very misleading results.
> Every item appears only once on the list, so someone with two occupations will just end up in one section or the other.

I found another problem: if I do a query on query.wikidata about, say,
ministers of Transport of the Kingdom of Italy, the query would show
the exact list of ministers, repeating correctly how many times John
Smith has been minister, with data and all. But with the automated
list, ALL John Smith's multiple terms would be "compressed" in just
one entry. Is it possible to "convince" ListeriaBot that the same
value may occur more than once?
I *think* you could do that if you use the SPARQL variables directly instead of the properties in the column headings, but you'd need to make "fake" item IDs (e.g. Q123.a, Q123.b or something). Internally, everything is wired to list one item per row, and it would be hard to fiddle with it. It was always a first attempt, not the final product... 

--
Luca "Sannita" Martinelli
http://it.wikipedia.org/wiki/Utente:Sannita

_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata