Hi Gerard (and everyone interested in list generation)
Dynamic lists are an interesting point since currently most (manually generated) Lists of Wikipedia are static. I would love to hear more about the issues and workflows around dynamic lists to understand their use better. Some things that are on my mind:
- What are things that a dynamic lists helps you with? (do you have some real-life examples?) - Where might a static list be a better approach? (do you have some real-life examples?) - What are current workflows with Listeria? I think I remember that people in our interviews (thanks to everyone who participated!) mentioned that the generation process currently needs to be triggered manually. Is that just because there is no automatic way or does it provide you with advantages, too?
If there are any other things that might help us to understand your needs better, please share, ideally with an example (in my experience, this makes it much easier to understand the workflow, motivation and it’s context)
Jan
Message: 6 Date: Fri, 2 Sep 2016 11:18:13 +0200 From: Gerard Meijssen gerard.meijssen@gmail.com To: "Discussion list for the Wikidata project." wikidata@lists.wikimedia.org Subject: Re: [Wikidata] List generation input Message-ID: <CAO53wxWaQ2vyVwg5f94X3G0E3T91gFAuA27uzCYo793RXApEBQ@mail. gmail.com> Content-Type: text/plain; charset="utf-8"
Hoi, I learned that for writing about gender issues the list generated by Listeria are used. The big advantage is that these lists are not fixed. Regularly people write new articles about women and consequently these lists change.
It is this functionality that is really needed and I do not get from the lists examples that need such regular updates. Thanks, GerardM
I am looking into people buried at some cemeteries and think a dynamic list plus also the list displayed on a map would be interesting
Today I have seen: A) Static lists of people examples A-1) Holy_Cross_Cemetery_(Colma,_California)https://en.wikipedia.org/wiki/Holy_Cross_Cemetery_(Colma,_California) A-2) Norra_begravningsplatsenhttps://en.wikipedia.org/wiki/Norra_begravningsplatsen and in Swedishhttps://sv.wikipedia.org/wiki/Norra_begravningsplatsen#K.C3.A4nda_begravda_personer_i_urval
Those list could rather easy be created using a Query ?person wdt:P119 wd:Q8509540;
What also would be interesting
B) Get the cemetery displayed on a map with graves using B-1) P119https://www.wikidata.org/wiki/Property:P119 place of burial pq:P965https://www.wikidata.org/wiki/Property:P965 burial plot reference pq:P625https://www.wikidata.org/wiki/Property:P625 coordinate location B-2) In the map also see my current location so that I can find what grave is next to me….
Example of map queries:
Holy Cross Cemetery http://tinyurl.com/gm7xx5p
Norra Begravningsplatsen https://goo.gl/isUieGhttps://goo.gl/gSbyPN
[cid:E5DADFE6-FFDE-4F58-946F-8353AF689571@zyxel.com]
Also Displaying A list with Gravestones in a ImageGrid could be of interest
Example of Picture of Graves using ImageGrid http://tinyurl.com/zdyk5nr
Regards Magnus Sälgö Sweden
On 05 Sep 2016, at 11:42, Jan Dittrich <jan.dittrich@wikimedia.demailto:jan.dittrich@wikimedia.de> wrote:
Hi Gerard (and everyone interested in list generation)
Dynamic lists are an interesting point since currently most (manually generated) Lists of Wikipedia are static. I would love to hear more about the issues and workflows around dynamic lists to understand their use better. Some things that are on my mind:
- What are things that a dynamic lists helps you with? (do you have some real-life examples?) - Where might a static list be a better approach? (do you have some real-life examples?) - What are current workflows with Listeria? I think I remember that people in our interviews (thanks to everyone who participated!) mentioned that the generation process currently needs to be triggered manually. Is that just because there is no automatic way or does it provide you with advantages, too?
If there are any other things that might help us to understand your needs better, please share, ideally with an example (in my experience, this makes it much easier to understand the workflow, motivation and it’s context)
Jan
Message: 6 Date: Fri, 2 Sep 2016 11:18:13 +0200 From: Gerard Meijssen <gerard.meijssen@gmail.commailto:gerard.meijssen@gmail.com> To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.orgmailto:wikidata@lists.wikimedia.org> Subject: Re: [Wikidata] List generation input Message-ID: <CAO53wxWaQ2vyVwg5f94X3G0E3T91gFAuA27uzCYo793RXApEBQ@mail.gmail.commailto:CAO53wxWaQ2vyVwg5f94X3G0E3T91gFAuA27uzCYo793RXApEBQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
Hoi, I learned that for writing about gender issues the list generated by Listeria are used. The big advantage is that these lists are not fixed. Regularly people write new articles about women and consequently these lists change.
It is this functionality that is really needed and I do not get from the lists examples that need such regular updates. Thanks, GerardM _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.orgmailto:Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Il 05 set 2016 11:43, "Jan Dittrich" jan.dittrich@wikimedia.de ha scritto:
- What are current workflows with Listeria? I think I remember that
people in our interviews (thanks to everyone who participated!) mentioned that the generation process currently needs to be triggered manually. Is that just because there is no automatic way or does it provide you with advantages, too?
Just one thing on this issue. Based on my short experience, the necessity of a manual trigger is half true: ListeriaBot updates every 24 hours or so every automated list. If you change things and you want to see those changes immediately THEN you can ask manually to update now. I don't see this much of a disadvantage actually.
L.
On Wed, Sep 14, 2016 at 10:07 AM Luca Martinelli martinelliluca@gmail.com wrote:
Il 05 set 2016 11:43, "Jan Dittrich" jan.dittrich@wikimedia.de ha scritto:
- What are current workflows with Listeria? I think I remember that
people in our interviews (thanks to everyone who participated!) mentioned that the generation process currently needs to be triggered manually. Is that just because there is no automatic way or does it provide you with advantages, too?
Just one thing on this issue. Based on my short experience, the necessity of a manual trigger is half true: ListeriaBot updates every 24 hours or so every automated list. If you change things and you want to see those changes immediately THEN you can ask manually to update now. I don't see this much of a disadvantage actually.
Yes, that's how I set it up.
I contemplated having a bot look through recent changes to update manually changed lists (e.g. query was changed) but it would probably be a few minutes for some lists until they update, which might be more confusing.
A proper extension would likely regenerate the list as part of the edit, so this wouldn't be an issue.
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)
* Handcrafted lists. A lot of time went into some of the lists, and while the raw data can often be regenerated from Wikidata, some manually curated lists have fields for notes, special formats for coordinates etc. that are hard to replicate. Allowing custom templates can solve the bespoke rendering, but especially the "notes" column is essentially not reproducible with Wikidata, as it is. A tag-based MediaWIki extension could offer notes per item, maybe, in wikitext.
My 2 Eurocent, Magnus
I found people opposed to Listeria lists (in article namespace) for two main reasons:
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.
For handcrafted lists: For now, we only have some rather vague ideas how to supplement lists with custom data, but it is something that turned out to be very important for users and I'll continue working on this.
Jan
Hi Jan,
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.
Ideally you need some way to specify how to choose between multiple vales. Some possible options that would help a lot :
1. Just take the most recent value (according to a time qualifier) 2. Just take the highest ranked value 3. Use an arbitrary variable from the sparql query instead of just a property 4. Allow items to appear in multiple sections
The idea being that the list-creating user can choose between a set of possible methods for consolidating multiple values. Obviously with some logical default set for when no selection has been made.
Cheers,
Nav
On 15 September 2016 at 13:09, Jan Dittrich jan.dittrich@wikimedia.de wrote:
I found people opposed to Listeria lists (in article namespace) for two main reasons:
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.
For handcrafted lists: For now, we only have some rather vague ideas how to supplement lists with custom data, but it is something that turned out to be very important for users and I'll continue working on this.
Jan
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
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?
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?
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
Either the list should just be a an entry point for a list structure or table that is completely created outside the editors realm, or it should be possible to merge any user edit with content from the bot. There should be no in-between where the user needs additional knowledge about how to edit the bot-produced content or even that (s)he can't edit the bot-produced content. From the user (editors) point of view there should be no special precautions to how some pages should be edited.
At the moment there are two pages in the main space at nowiki using listeria bot; Bluepoint Games [1] and Thatgamecompany [2]. It is a (weak?) consensus on not using the bot, so if a discussion is started they will probably be removed. The main argument why it should not be used is because it overwrites edits made by other users.
[1] https://no.wikipedia.org/wiki/Bluepoint_Games [2] https://no.wikipedia.org/wiki/Thatgamecompany
Hoi, I have a list of Dutch people who died in 2015. There is a list of fields associated with them and regularly new facts are added. So I am very happy with the result. the point is that there is a lot of content that is not well maintained (including in Wikidata) they are things like awards. When Wikidata has done its job it is a better job. The trick is to keep them updated and that is where it is easier to do this at Wikidata than doing it on 280+ Wikipedias.
It is fine for some to prevent progress. The problem is that their solution is not one that scales or where they make a positive difference. It is easy enough to update lists and categories on any Wikipedia with content that is of high quality and that is not considered on that Wikipedia.
Why only two exceptions, when there is an obvious opportunity for much more quality? Thanks, GerardM
On 19 September 2016 at 11:06, John Erling Blad jeblad@gmail.com wrote:
Either the list should just be a an entry point for a list structure or table that is completely created outside the editors realm, or it should be possible to merge any user edit with content from the bot. There should be no in-between where the user needs additional knowledge about how to edit the bot-produced content or even that (s)he can't edit the bot-produced content. From the user (editors) point of view there should be no special precautions to how some pages should be edited.
At the moment there are two pages in the main space at nowiki using listeria bot; Bluepoint Games [1] and Thatgamecompany [2]. It is a (weak?) consensus on not using the bot, so if a discussion is started they will probably be removed. The main argument why it should not be used is because it overwrites edits made by other users.
[1] https://no.wikipedia.org/wiki/Bluepoint_Games [2] https://no.wikipedia.org/wiki/Thatgamecompany
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
2016-09-18 21:50 GMT+02:00 Magnus Manske magnusmanske@googlemail.com:
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.
*facepalm*
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...
Thanks for the suggestion. By the way, it's a great start, believe me. :)
2016-09-19 11:06 GMT+02:00 John Erling Blad jeblad@gmail.com:
Either the list should just be a an entry point for a list structure or table that is completely created outside the editors realm, or it should be possible to merge any user edit with content from the bot. There should be no in-between where the user needs additional knowledge about how to edit the bot-produced content or even that (s)he can't edit the bot-produced content. From the user (editors) point of view there should be no special precautions to how some pages should be edited.
I think this depends on and varies among communities. As I said, on it.wp all lists of people who were born and died on a particular date or year are automatically updated by a bot taking data from [1] since years, and nobody is batting an eye on this.
This doesn't rule out some sort of "user creativity" in doing lists, but in my opinion a bot-made list at the moment is better than no list at all. Moreover, the bot-made list can be a starter for users to think what to include in the future in those lists, and to make those list better.
Oh, no offence, but let's not forget that usually creating a table like [2] is difficult for an experienced user, let alone a newbie.
L.
[1] https://it.wikipedia.org/wiki/Template:Bio [2] https://it.wikipedia.org/wiki/Ministri_della_Marina_del_Regno_d%27Italia
