Wikidata:Property proposal/setlist

setlist

Originally proposed at Wikidata:Property proposal/Generic

Done: setlist (P9793) (Talk and documentation)

Description	performances of songs or other music at an event; concert program
Data type	Item
Domain	event (Q1656682) or subclass of event (Q1656682), such as concert (Q182832), award ceremony (Q4504495), or recital (Q1446621)
Allowed values	any instance of performance (Q35140) or instance of a subclass of performance (Q35140), such as an instance of performed music (Q106805967) representing a live performance of a song
Example 1	Post-Moderns at the Rat (Q106716072) → YMG (Q106806280)
Example 2	2009 MTV Video Music Awards (Q643937) → Paparazzi (Q106806371), We Will Rock You (Q108138199), You Belong with Me (Q108073705)
Example 3	funeral of Diana, Princess of Wales (Q2918374) → Candle in the Wind (Q106807719)
Planned use	Will manually add property to concert items as they are encountered or created
See also	tracklist (P658)
Distinct-values constraint	yes

Motivation

We hope to use this property, if created, to add partial or complete setlists to concert items, particularly significant events related to our project about Boston punk bands https://www.wikidata.org/wiki/Wikidata:WikiProject_Linked_Data_for_Production/Arthur_Freedman_Collection_Project for which we are organizing a public editathon later this month. It may be worth noting that we are focused on creating concert items manually and are not considering a batch import of items using the proposed property at this time. Fernsebner (talk) 02:01, 12 May 2021 (UTC)[reply]

Discussion

Strong support Very happy to see this, a key property for working with concerts. EDIT: Changing from "support" to "strong support"; as someone who edits music every day I think this is crucial, we have already had a disastrous import of concert data (Montreux) that we're still cleaning up after, much of the mess could have been avoided had this property been in place at the time. This is needed. Moebeus (talk) 00:28, 25 May 2021 (UTC) (talk) 09:59, 12 May 2021 (UTC)[reply]
- @Moebeus: as you are one of contributors with the most experience in the field, can you help complete the samples (see my comment below)? Currently, the proposal can be read as one should make 15 items for every concert. --- Jura 09:35, 26 May 2021 (UTC)[reply]
Support Great to have this property for live events, as tracklist would be used for recordings. Sradovsk (talk) 13:10, 12 May 2021 (UTC)[reply]
Support --Emwille (talk) 13:11, 12 May 2021 (UTC)[reply]
Support --Jala360 13:57, 12 May 2021 (UTC)[reply]
Support -Yupik (talk) 15:41, 12 May 2021 (UTC)[reply]
Support Wskent (talk) 15:42, 12 May 2021 (UTC)[reply]
Support --Sheilatb (talk) 15:45, 12 May 2021 (UTC)[reply]
Support UWashPrincipalCataloger (talk) 15:58, 12 May 2021 (UTC)[reply]
Support --Bethpc (talk) 16:02, 12 May 2021 (UTC)[reply]
Support --Dbigwood
Support -- Lrobare (talk) 18:46, 12 May 2021 (UTC)[reply]
Support -- Hildebrand.R (talk) 18:47, 12 May 2021 (UTC)[reply]
Support -- Uncommon fritillary (talk) 19:06, 12 May 2021 (UTC)[reply]
Disagree - Hmm, it might not always be a "musical" work, I'm thinking slam poetry, comedy routines/skits, etc. A "set" at some event type could be described as "a group of works, musical or otherwise". So I'd like to see the description improved with something like that before I would support this. So let's expand that constraint for only "musical works" to my suggestion. --Thadguidry (talk) 19:21, 12 May 2021 (UTC)[reply]
- Comment -- The currently-specified allowed values are musical performances (which can be linked to works) rather than musical works themselves, parallel to how P658 uses recordings rather than works; I've tweaked the description slightly to make this clearer. But, to your point: would it suffice to allow any instance of a subclass of "performance" (Q35140)? Fernsebner (talk) 20:52, 12 May 2021 (UTC)[reply]
- Comment -- Yes, then since you want performances (of some work), then a subclass of performance (Q35140). However, this will cause a uniqueness constraint for data to be captured on a performance entity created (which could then link to the work performed). But that would be expected, and on the flip-side makes querying easier for the consumer(query all performances of "China Girl" by David Bowie), but harder for the publisher to add all the data into separate performance entities

performance of "China Girl" by David Bowie on 1987-11-09 in Sydney, Australia
performance of "China Girl" by David Bowie on 1990-05-16 in Tokyo, Japan

- And furthermore perhaps "setlist" could simply be renamed "performances"? --Thadguidry (talk) 14:19, 13 May 2021 (UTC)[reply]
  - Comment -- I've edited the proposal such that allowed values are now instances of performance (Q35140) and its subclasses. While "performances" should certainly be among the proposed property's aliases, I'm reluctant to change its label, as "setlist" reflects its primary use case. Fernsebner (talk) 18:30, 18 May 2021 (UTC)[reply]
Support I support this property, and think that allowing any subclass of performance (Q35140) would be the best move unless it's necessary to distinguish between setlists for musical and non-musical performances. Naming it "performances" rather than "setlist" makes the meaning and intended usage of the property vague, in my opinion. --Crystal Clements, University of Washington Libraries (talk) 14:57, 13 May 2021 (UTC)[reply]
- Comment -- Agreed: I don't want this to be unrecognizable to music-focused editors. As I said above, I've edited the allowed values. Fernsebner (talk) 18:30, 18 May 2021 (UTC)[reply]
Oppose given the proposed values. This seems too granular for Wikidata --- Jura 17:18, 13 May 2021 (UTC)[reply]
- Comment -- I've edited the proposal to accommodate a broader range of proposed values, as Thad suggested. Fernsebner (talk) 17:46, 19 May 2021 (UTC)[reply]
- Comment -- Hi Fernsebner, on further reflection, I'm not confident in the scalability of the modeling I proposed as an alternative because it hinges as I said on the notion of a "performance" which is nearly always implied. I think this can be even more abstractly expressed to cover diverse needs. Let's talk on [LD4 Slack chat thread] with you about this further then come back here to write it up for all to ponder further. --Thadguidry (talk) 18:41, 19 May 2021 (UTC)[reply]
- Comment The granular argument went out the window a long time ago or we wouldn't have properties like blood type (P1853). Setlist is parallel to tracklist and as such is fine. Setlists can be more than just about music, so there is no need to change the property name to the more generic, more ambiguous, and more easily misunderstood performance (which can easily be misunderstood to be the venue or performance date(s) and not the setlist itself). I particularly like that this encompasses more than just concerts, which means it can be used for poetry readings, standup comedy, etc. too. All in all, a good property to have. -Yupik (talk) 05:57, 20 May 2021 (UTC)[reply]
Comment To review, I think the samples should be completed. The three current ones are incomplete in the sense that none is a full setlist. This may have lead some user(s) supporting the proposal to mistaken it for single valued properties. Also, we are missing samples that cover what is called "broader range of proposed values". You are probably aware that the tendency at Wikidata is to avoid multi-valued inverse properties (This can be queried). --- Jura 07:02, 20 May 2021 (UTC)[reply]
@Fernsebner, Moebeus, Jura1, Thadguidry, Yupik, Sradovsk: @Emwille, Jala360, Wskent, Sheilatb, Bethpc, Dbigwood: @Lrobare, Hildebrand.R, Uncommon fritillary, Clements.UWLib: Done as setlist (P9793). UWashPrincipalCataloger (talk) 18:13, 13 August 2021 (UTC)[reply]