[STYLE-747] Event guidelines

Ticket: [STYLE-747] Event guidelines - MetaBrainz JIRA

I started this ticket because of edit #44182108 which could completely upend how we handle Events.
In short, I made some draft guidelines to standardize how Events are entered in MB. It covers things like title format, splitting up festivals, setlist order, etc. Discussion and suggestions are welcome.

2 Likes

I think most of the proposals here are reasonable enough that this is a good start for a proper “official” discussion on the topic, that I agree is overdue.

The one thing I’m personally not too convinced of is having per-stage events on festivals, because it feels to me that festivals aren’t usually watched on a per-stage basis, but a per-concert basis: most festivals are designed so that the attendees move between stages picking specifically what concerts they want to see. In that way, I’d prefer to either have only an event per festival day or have one event per festival concert (as part of the day).

I’d like to see other people comment on this issue, but also on any other issues they see with the proposed guidelines above :slight_smile:

3 Likes

That festival set-up is the basis behind the edit I linked in the OP.

well I generally agree with this (as I also voted on that edit. but I’ve got to put myself into the proposed guidelines more thoroughly to make a definitive answer, in general what Hibiscus and reosarevok are saying makes good sense.)

I don’t have much experience with this side of MB yet (I’ve mostly stuck to albums so far), but reading up on it I actually think that having per-stage events is crucial, unless we add support for multiple setlists on the same event. The format is inherently linear and doesn’t support multiple things happening at once, so for festivals where multiple venues all have things happening, an event per day would lose some of that information (not to mention that the only ways to tell what stage a performance was on would be to either include an “additional info” line or to go to the recording page, though the disambiguation might also include it). Yeah, people wander from one to another freely, but my impression of events isn’t “what did people hear” but “what was played” – a small distinction at times, but a distinction nonetheless.

My biggest question is about artists performing multiple times at the same venue. Do we rely on the date field to distinguish each, or note it in the disambiguation? And what if they play distinct concerts in the same day? Not hard questions to answer, but should probably be made explicit in the proposal and writeup.

I think my oppinion on this is clear given my notes on the linked edit. By the way, I’m not 100% sure about how we should handle some parts of the information:

Option 1:

  • A festival should be split on individual events, one for each day.
  • Each day event can be split further, creating one event for each stage.

Option 2:

  • A festival should be split on individual events, one for each stage, if more than one.
  • Each stage event can be split further, creating one event for each day.

Option 3:

  • Don’t add events for individual stages, and rely on the event location instead if desired (i.e. creating “place” entities for each stage and an AR to in from the individual events, but that would create n additional ARs instead of one).

By the way, the part I’m sure about is how we should handle each artist performance:

  • Each individual artist performance should have it own separate event.
  • Band lineup when the event took place, guest artists, recordings should be linked to the individual artist performances wherever possible.
  • URL relationships (reviews, videos etc) should be linked to the individual artist performances wherever possible.
  • If an individual artist performance is cancelled, its sub-event should reflect this info instead of cancelling the whole parent event (common sense).
  • The ideal case would be to create a sub-event for supporting acts.

I think we should allow the guideline to be “relaxed”, i.e. it is allowed to add each artist to a single event that spans the whole festival, add all artists from a single day to per-day events, or adding supporing artists to the main event instead of creating individual events etc but as a way to ease editing and keeping it clear that the correct way is to add data as fine-grained as possible

3 Likes

The problem with fine-graining that data to the extent you’ve described is that it flies in the face of how events are organized in the real world. It is my understanding that MB’s main goal is to represent facts as accurately (i.e. close to the original) as possible, and I do not see how altering these facts to suit some arbitrary data model (which may or may not actually exist) meets that goal.

Mind explaining a bit more? Thinking of the fair schedules I’ve seen (which are admittedly not music festivals), There’s obviously the schedule as a whole – which would be the festival-level event – and that’s split into a page for each day with, typically, a chart of “venues” along one axis and time along the other, where each performance or competition is filled in as a range of time in a particular place. That seems to pretty directly map to @ChurruKa’s Option 1, and I think I remember seeing schedules matching Option 2 as well (though my vote is for the former).

Fairs and other non-music events (e.g. conventions) vary. I have split some of them up by day, but I always added each individual concert as a child event of that event. The reason for this is not what ChurruKa described: it’s because often times those individual shows will have an opening act. Ordinarily we do not split regular concerts with opening acts; in fact we have the @ flag in setlist syntax (for delineating artists) so as to prevent people from doing so.

I sorta like where ChurruKa is heading (/trying to take musicbrainz): to a place where individual artist performances can be a “thing” in musicbrainz. I’m not sure whether having them be a subtype of Event is better, or whether it is better for it to be a different type of object (like how Recordings are diffent from Releases).

I would say that the musicbrainz schema doesn’t support such a thing currently, and until such a time as it does (and, I think, until we have a half-decent way of presenting/displaying such things), adding entries for individual artist performances shouldn’t be encouraged (but neither should it be forbidden)

In cases such as ChurruKa mentions, where there’s a lot of details (reviews,recordings,etc…) to provide about an individual performance, the benefits of individual artist performance entries may outweigh the kludginess of doing it in the current schema.

But updating the schema seems to be the ultimate goal.

Also, I would say there’s two questions here:

  1. (How) do we store individual artist performances info in Musicbrainz
  2. How do we display info about individual artist prformance on the website?

I would say the “that’s not how it’s thought about in the real world” argument is mainly about question 2 and not really germane to question 1.

There are a handful of instances where this is the case (e.g. guest performances) but 90% of it is an attempt to solve a problem that does not exist. We already support adding multiple artists’ setlists to a single Event, we support an infinite number of URL relationships and multiple Series links (for linking to artists’ tours). It is not really necessary to specify what entity some of those links are for: usually the text of the URL will give away whose performance it matches with. (This is really only applicable for festival appearances; often times in the case of concerts there will be one review for the whole show that encompasses all acts on the bill.) In the case on intra-MB relationships (recordings, works, etc.) there really is no need to specify which set they were recorded/performed in; the display format for recordings shows the recording artist from the Event page, and any Works that premiered at the show can be visually matched with their position in the setlist.

1 Like

Working on a response to @bsammon, but I’ll put this up while I do.

@HibiscusKazeneko Just to be clear, your dissent is not over their Option 1/2, but over separating artist performances into their own events below stage/day-level, right? The former seems to be a pretty faithful representation of the real structure.

I don’t think this proposal is solely meant to describe the current practice, but to also (re)define what to do in the future. Additionally, it’s focused a bit more on the side of festivals – we definitely have to make sure that whatever decision we make feels just as natural for concerts, but there’s enough small differences in the models that we can’t blindly assume that what works for one does for the other. In this particular case, saying that we don’t split opening acts of concerts (which are given much lower billing and will frequently refer to the primary artist between songs) and so individual performances in festivals (where there might be two or three big draws, but the schedule is otherwise more egalitarian and if artists refer to other acts, it’s because they personally enjoyed/are excited about them) shouldn’t be split either is a false equivalence. Besides, just because we extend correctness to splitting out individual performances doesn’t mean consolidating them into a single setlist would be disallowed.

Off the top of my head, splitting out performances also seems like it would nicely facilitate cases where one artist canceled last-minute and was replaced by someone else without much disruption to the rest of the event, but I’m not sure how often that would come up or what quality of data we’d have about the canceled performance.

Exactly.

It would be disallowed. That’s the whole point of having a guideline for something.

We already have a “cancelled” flag for individual performers on a given Event, so this is (mostly) a moot point. We don’t really have a way to denote that one act replaced another without the use of the annotation field, and splitting artist appearances into individual performances wouldn’t help this matter.

@bsammon I don’t see performances as being inherently different from other events, just on a smaller scale, so I’d advocate for just creating a new subtype. We already have “part of” relationships with perfectly workable language, and I’m not sure if we’ll need many changes beyond a new icon and support (on both sides) for a new entry in the type list.

The biggest question is whether individual artist performances need to be separated out in the first place, and I think that’s where “that’s not how it’s thought about in the real world” comes into play and where the largest difference between concerts and festivals lies. With the former, the acts are all conceived of as a single block and would be most accurately represented with a single setlist. With the latter, the acts are listed individually with their own start and end times, and are a very good fit for separate events. Which one outweighs the other is at the core of this disagreement, but my take is that it’s easier to emulate the former with the latter, and conceptually cleaner than trying to separate a list of twenty links (likely intermingled) between five groups of performers, no matter how clearly they indicate themselves.

I’m thinking of the last paragraph of @ChurruKa’s proposal:

I think we should allow the guideline to be “relaxed”, i.e. it is allowed to add each artist to a single event that spans the whole festival, add all artists from a single day to per-day events, or adding supporing artists to the main event instead of creating individual events etc but as a way to ease editing and keeping it clear that the correct way is to add data as fine-grained as possible

It’s like works: with a few rare exceptions, recordings are encouraged to link to what they’re a recording of. For ease of editing, we don’t require it and given how many people blindly duplicate recordings, that’s probably a good thing. Maybe we even encourage different formatting for concerts than we do for festivals. Either way, just because one is “better” doesn’t mean the other’s “bad”.

It would help, though. We have two individual performances scheduled for the same time. One of them’s displayed as being canceled. If we want to, we use the “rescheduled as” relationship (or a new, similar one) to link the two without going through the enclosing event. Does require the times to be displayed in the “parts” list (and admittedly works best if “parts” and “canceled parts” were listed alongside each other, unlike how they’d actually be separated), but it’s easily possible to represent purely in the database without relying on notes in the annotation and/or setlist.

Finally, to add a couple more edge cases to what needs to be considered for the formal guidelines, what about recitals or other events (“concert” fits well enough) where many artists play one or two songs each, or less formal jam sessions where a likely-limited number of people rotate on and off stage without regard to larger groups? Both probably cases where, even if we settle on separate performance events, we encourage joining them anyway, but we’d want to consider them however this turns out.

2 Likes

That brings to mind another example I forgot to mention: Alice Cooper’s Christmas Pudding, an annual variety show with musical and non-musical acts as well as a host. The “host” relationship cannot be split off, for obvious reasons, and the musical guests only play one or two songs by themselves and they are often joined by other performers for at least one song. There’s no way to split that apart cleanly because there’s so much intersection.

And so do festivals and other music events.

If we know the stage time, both the cancelled act and the replacement act can be set to the same time.

This is where I’m coming from. Even sometimes on festivals, you will see a “block” on one stage with 2–3 (or more artists) in succession, then the stage will have a break and then later have another “block” of performances on the same stage on the same day. Sometimes it will “feel natural” to add one Event for one artist performance, other times you will want to add multiple artist performances together into one Event.

My vote is for “Festival → Day → {whatever feels natural for the particular festival: sometimes per-artist, sometimes per-stage, sometimes a mix(, sometimes something completely different?)}”.

3 Likes

I’d be happy with that. Makes it a bit harder to write the guideline since there’s no distinct line we can point to, but it’s a pretty nice model. If we also standardize on separate events to indicate replacement acts, we may want to make a special case for block performances, though, where the canceled act is stored individually while the replacement is listed as normal in setlist for the larger block, with a comment pointing to the canceled original.

And looking at the structure, “canceled” is an attribute on the event, not the relationship. How visible is it in other entities’ relationship lists? That might be another UI change we need to make if it’s only shown on the page of the particular event that’s been canceled. Does make it easier to see one act replaced another in the “parts” list if they’re right next to each other.

On the concert side of things, I notice we don’t have any way to group an entire tour together. Is that something we want to add?

Finally, to continue listing edge cases, what about events that are meant to span midnight, like New Year’s concerts or some launch parties? Do we use the “Day” level as normal, or save it as a single continuous event, or split in the morning/whenever the next break occurs? My vote’s tentatively on the third.

We have, as a series :slight_smile:

In general, concert “days” don’t correspond to real days - if a concert starts at 23:00 and ends at 2 AM the next day, I would still expect that to be one event “day”. The start and end dates should be clear enough.

1 Like