I disagree very much with this. If I have a concert in the date interval 2001-01-01–2001-01-01 with a performer that goes on stage at 01:30, I would assume that it’s 2001-01-01J01:30, not 2001-01-02J01:30. And it just might be! But what if the concert also has another artist on stage at 23:00? It’s unlikely that there’s a gap of 11½ hours between the two. If I knew that the concert was 2001-01-01–2001-01-02, then I knew that there are 48 potential “hours”, and the 01:30 is likely “spilled over” into the 2nd day.
Also, it’s just technically wrong to say that the 2001-01-02J01:30 performance happened on 2001-01-01.
Sure, and as such “The start and end dates should be clear enough”. It looks kinda silly, but I’m willing to say that “Friday” of a festival starts on Friday and ends on Saturday. What I’m saying is “don’t add a Saturday day event for the people who were marked as Friday but performed after midnight”
Would be great to see this style come into effect.
Some thoughts/possible additions -
"[concert special title]" isn’t that useful if the concert special title doesn’t include the headlining acts name (which is nonetheless prominent on the poster/advertising material in logo form or whatever). In those cases it would be useful to have something like “[headlining act/s]: [special title]”.
Similarly if “[concert special title]” is part of a tour it needs something to distinguish each location. eg “[concert special title], [city]”.
If there’s more than two headliners we should include that in the guide, eg “[Headliner 1], [Headliner 2] … and [Headliner 3] at [Venue]”. We’re going to get some very long event titles for large events where there’s a lot of artists on the poster without anyone being more prominent/ headlining. I personally don’t care, but something to keep in mind.
I don’t have specific recommendations here at this time. I’d have to sit with it a bit more to decide what I think. That said, it seems clear to me that the data model currently lacks some useful distinctions, namely that an event can comprise several individual performances which each have their own relationships.
My general preference would be for guidelines (definitely not hard-and-fast rules) which allow for the best data-level linking of relevant information. For example, I’m currently adding a multi-day festival and can’t specify which day certain performers play on, so multiple events (and presumably the Event-Event parts relationship) could be used to separate these out. Further, individual performances may have links to outside information (setlists, reviews) which don’t apply to other performances on that same day, and so we should strive to represent these in a data-level manner (not by requiring human interpretation of what matches up to which). We make extensive use of Work-Work relationships to indicate that works are a part of a larger work; is there a particular reason this wouldn’t serve as well for Events?
Had to think about it a second, do you mean you don’t know what day they played on?
I’m happy for lower level relationships/data storage etc, but I don’t want to (slash wouldn’t) add an event for every performance x a thousand.
I thought that’s what this proposal would do already? I was assuming that LeftmostCat wants to take it a step further.
Splitting things up into blocks is no problem for me, perhaps even preferred, as long as it’s practical to actually do.
I think assigning relationships to every performace needs to be enabled in the backend somewhere, adding a lot of separate events seems like a hack to make the system do something it’s not capable of otherwise.
But since nobody’s going to care/vote on the events I add, I don’t reeeaaally care
No, just that using a single all-encompassing festival event doesn’t give me a means of saying “this performer played on day one”.
I tend toward thinking that we should be exactly as fine-grained as we need to be. If you can do it in one event, do it in one. If you need to break it out into multiple to include all the information you have, break it into multiple.
Oh ok, then we’re on the same page, and this proposal should take care of it.
“The proper name format is “XYZ Festival”, “XYZ Festival, Day 1” and “XYZ Festival, Day 1: ABC Stage.””
Or am I missing something?
This still seems wrong to me in most cases. I’ve still never met anyone who watches a stage (unless the festival is very specifically designed for that), you’re not usually supposed to stay on a stage all festival, they’re just the places where independent concerts happen. Grouping by that seems strange.
I mean, if it’s an urban festival where each “stage” is a different venue and you’re mostly expected to just pick one and stick to that (like our Tallinn Music Week), then sure, but for the average “each stage is near to each other in a field” kind of festival, I’d much rather just add each performer as its own event.
[quote=“reosarevok, post:31, topic:233154”]
I’ve still never met anyone who watches a stage[/quote]
It’s how festivals tend to group their performances, so I think it makes sense for us to group them that way. In a visual sense it’s just another way to break up the information into manageable pieces.
If you’re thinking about the user case where someone wants to keep track of exactly which artist they saw at a festival, that’s going to be complicated no matter what. I’m not sure we should cater to that using guidelines, I think that should be a new functionality (eg ‘let me mark artist > event relationships as ‘seen’/add them to collections’)
I’m assuming that’s where you’re coming from anyway, thinking about how someone actually acts at a festival?
Partially that, partially things like setlists and whatnot (I imagine every setlist site out there for example does this one per-artist rather than per-stage). I don’t mind having the stage as an intermediate extra step, but I feel it probably makes sense to at least allow adding per-artist events when people want them (be it to mark them as attended, or to link them to external resources as @LeftmostCat mentioned).
One thing I saw here that I don’t think I agree with:
That’s only true of a human with additional context checking the URL list. Ideally, MusicBrainz should allow a machine to serve only the relevant links, and in this case I still feel the most relevant level is often either the artist level or the full festival (or at least day) level, for festivals - reviewing a stage, for example, is rare (although I’m sure it does happen). IMO the main argument for individual artist concerts is that by being as fine-grained as possible it allows us to match to everyone else’s systems and be semantic web glue (for example, setlist.fm has per-artist setlist pages).
I’m somewhat wary of having very specific guidelines for the title, because really event titles are a field that only exists because we needed to have something to fit the database schema. Originally the idea was to allow having events with no title at all unless they had a real title, and base the info (and displayed “title”) on relationships. I still like that concept, and I’d much rather have a way to autogenerate titles for untitled events rather than having a very strongly enforced standard.
I definitely agree with listing the place as it was named at the time of the concert, but I think the best solution for that is to push MBS-9019. I’ve asked and it doesn’t seem to involve a lot of work, so I’m hoping it can be one of the first tickets solved after the May schema change.
I like the idea of generating then automatically, but some events (quite a lot that I add actually) do have title information that’s an important part/a strong creative decision that informs the tour.
I wouldn’t want to lose that information.
Edit: I see that you said “for untitled events” so I think we’re on the same page anyway, sorry
I like the idea of having festivals splitted to separate days. That makes it possible to mark attendance to a specific day. But I would like the “master” event to show a list of all the artists listed on parts of the festival.
In my opinion, a schema change some sort of programming is required. If we add multiple layers to each festival (master, days, stages, concerts), it makes it harder to have an overall look of the festival on the current site. And adding multiple events for the same festival is much more complicated than having just one event. We could have multiple events for festivals, but the creation of them should be semi-automated.
Why? What needs to change on the database level? Most of the things you propose seem to fit into the current schema, just needs additional logic (programming) to do what it is you’re proposing. You can derive all artists (incl. performance times etc.) from looking at “has part” events, and likewise it would be possible to automatically create “part of” events from a bigger one with an interface/widget on the site. Neither of these require any database level changes as far as I can tell.
I think that each Festival stage should be in its own entry, since some festival are venue-wide, with multiple concert venues participating together in a festival. Stages should be treated like venues. However, the Festival listing should ideally be changed and treated like a “Master Release”, with each stage or venue assigned as “Releases” as part of the “Master Release”, within set dates.
I’m going to commit an internet sin and resurrect a thread from December 2018, if that isn’t allowed, mods please split me into a new thread
OK, so I’ve had a bit of a read through of this, and the ticket.
The ticket on JIRA is still status OPEN, although it seems like we all agreed on some things and then this wiki document Event - MusicBrainz was created.
The reason I resurrect this is because this still hasn’t made it into the official guidelines; and that’s what I have ended up looking at, going “oh there’s nothing here” and then tried by best to reverse engineer the logic used in existing event entities; as I didn’t find the above doc until a few days ago.
Is there anything I can do to help get some of these agreed “best practices” moved to the official agreed way of doing things, just so other newbies who care about event documentation (like me) have something to work on?
EDIT: my concern was that there’s no activity at all for this ticket, whereas other ones have at least had something happening in their lifespan, so i’m happy to “pick up the torch and run with it” per se
