Dynamic Lists, Was: Re: List generation input

List overview All Threads
Download

newer

older

Weekly Summary #227

Deleting properties / items in...

Jan Dittrich

5 Sep 2016 5 Sep '16

11:42 a.m.

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(a)gmail.com> To: "Discussion list for the Wikidata project." <wikidata(a)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

Attachments:

attachment.htm (text/html — 2.4 KB)

Show replies by date

Magnus Sälgö

5 Sep 5 Sep

12:08 p.m.

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/Ho… A-2) Norra_begravningsplatsen<https://en.wikipedia.org/wiki/Norra_begravnings… and in Swedish<https://sv.wikipedia.org/wiki/Norra_begravningsplatsen#K.C3.A4nd… 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) P119<https://www.wikidata.org/wiki/Property:P119> place of burial pq:P965<https://www.wikidata.org/wiki/Property:P965> burial plot reference pq:P625<https://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/isUieG<https://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.de<mailto: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.com<mailto:gerard.meijssen@gmail.com>> To: "Discussion list for the Wikidata project." <wikidata@lists.wikimedia.org<mailto:wikidata@lists.wikimedia.org>> Subject: Re: [Wikidata] List generation input Message-ID: <CAO53wxWaQ2vyVwg5f94X3G0E3T91gFAuA27uzCYo793RXApEBQ@mail.gmail.com<mailto: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.org<mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata

Luca Martinelli

14 Sep 14 Sep

11:06 a.m.

New subject: Dynamic Lists, Was: Re: List generation input

Il 05 set 2016 11:43, "Jan Dittrich" <jan.dittrich(a)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.

Magnus Manske

11:47 a.m.

New subject: Dynamic Lists, Was: Re: List generation input

On Wed, Sep 14, 2016 at 10:07 AM Luca Martinelli <martinelliluca(a)gmail.com> wrote:

...

Il 05 set 2016 11:43, "Jan Dittrich" <jan.dittrich(a)wikimedia.de> ha scritto:

- What are current workflows with Listeria? I think I remember that

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

Jan Dittrich

15 Sep 15 Sep

2:09 p.m.

New subject: Dynamic Lists, Was: Re: List generation input

...

I found people opposed to Listeria lists (in article namespace) for two main reasons:

Navino Evans

4:53 p.m.

New subject: Dynamic Lists, Was: Re: List generation input

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(a)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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

-- ___________________________ The Timeline of Everything www.histropedia.com Twitter <https://twitter.com/Histropedia> Facebo <https://www.facebook.com/Histropedia>ok <https://www.facebook.com/Histropedia> Google + <https://plus.google.com/u/0/b/104484373317792180682/104484373317792180682/posts> L <http://www.linkedin.com/company/histropedia-ltd>inke <http://www.linkedin.com/company/histropedia-ltd>dIn <http://www.linkedin.com/company/histropedia-ltd>

Luca Martinelli

16 Sep 16 Sep

10:04 p.m.

New subject: Dynamic Lists, Was: Re: List generation input

2016-09-15 14:09 GMT+02:00 Jan Dittrich <jan.dittrich(a)wikimedia.de>de>:

...

2016-09-14 11:47 GMT+02:00 Magnus Manske <magnusmanske(a)googlemail.com>om>:

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(a)histropedia.com>om>:

...

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? -- Luca "Sannita" Martinelli http://it.wikipedia.org/wiki/Utente:Sannita

Magnus Manske

18 Sep 18 Sep

9:50 p.m.

New subject: Dynamic Lists, Was: Re: List generation input

On Fri, Sep 16, 2016 at 10:05 PM Luca Martinelli <martinelliluca(a)gmail.com> wrote:

...

2016-09-15 14:09 GMT+02:00 Jan Dittrich <jan.dittrich(a)wikimedia.de>de>:

2016-09-14 11:47 GMT+02:00 Magnus Manske <magnusmanske(a)googlemail.com>om>: > 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.

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(a)histropedia.com>om>:

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

John Erling Blad

19 Sep 19 Sep

11:06 a.m.

New subject: Dynamic Lists, Was: Re: List generation input

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

Gerard Meijssen

11:19 a.m.

New subject: Dynamic Lists, Was: Re: List generation input

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(a)gmail.com> wrote:

...

Luca Martinelli

3:45 p.m.

New subject: Dynamic Lists, Was: Re: List generation input

2016-09-18 21:50 GMT+02:00 Magnus Manske <magnusmanske(a)googlemail.com>om>:

...

*facepalm*

...

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(a)gmail.com>om>:

...

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

2787

days inactive

2801

days old

wikidata@lists.wikimedia.org

Manage subscription

10 comments

7 participants

tags (0)

participants (7)

Gerard Meijssen
Jan Dittrich
John Erling Blad
Luca Martinelli
Magnus Manske
Magnus Sälgö
Navino Evans