On Fri, Sep 16, 2016 at 10:05 PM Luca Martinelli <martinellil...@gmail.com>
> 2016-09-15 14:09 GMT+02:00 Jan Dittrich <jan.dittr...@wikimedia.de>:
> > 2016-09-14 11:47 GMT+02:00 Magnus Manske <magnusman...@googlemail.com>:
> >> I found people opposed to Listeria lists (in article namespace) for two
> >> reasons:
> >> * The list is wikitext, so it /looks/ like one can edit it, but then it
> >> 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
> > 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 <nav...@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
> Wikidata mailing list
Wikidata mailing list