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