I’ve started creating events for an upcoming festival and I could use some feedback on what I already did before continuing.
Here are some things that especially puzzle me:
I didn’t know how to properly credit the musicians of the first act of this concert as they don’t have a band name. I ended up just putting all of them, including the lead, as “support acts”, but I’m afraid it lacks in clarity.
Speaking of credits, should I have credited the band Saving Grace as “ROBERT PLANT presents ‘‘SAVING GRACE’’ feat. SUZI DIAN” since it’s the way the festival does it?
You can see on one the venue’s website that it will host several shows every day. Putting them all inside a single “Festival, Day X: Venue Z” event seems wrong as they will have different tickets. What should I do here? Create an event for each performance instead?
Feel free to chime in if you have more general comments too. It’s the first time I’m working on such big project, and I could use some guidance.
What I would do (I won’t go so far as to say it’s what you should do) is create a separate event for each separately-ticketed lineup.
If there were multiple events at the same time (something like “Show A in room X at 7PM” and “Show B in room Y at 7PM”) I’d be creating separate sub-venues for room X and room Y. My impression from the link you provided is that that isn’t the case here.
What seems to be going on at this event is something more like “Show A in venue Z at 5PM for $15” and “Show B in venue Z at 8PM for $20” I’d also have separate events for Show A and Show B.
“event for each performance” sounds like creating one event for “Artist M at Show A in Venue Z” and another event for “Artist N at Show A in Venue Z”, and, assuming that both performances came under the same tickets, I wouldn’t be in favor of having those be separate events. I don’t think that level of granularity is commonly done here at Musicbrainz.
Hopefully, at some point in the future, Musicbrainz will have a “Set” Entity in the database for that level of granularity.
The style guidelines for events say that “Each level of the festival should be linked to the most precise place of area possible.”, whereas the style guidelines for relationships say “If you have a relationship that applies to a series of events link to the series.”. Is it me or are those two guidelines contradicting one another?
Based on the event guidelines and the STYLE-747 ticket, I linked both the festival series, the festival itself and all the its constitutive days to the master location. But I wonder if this not needlessly cluttering the area.
The aforementioned style guidelines for events say “When available, use the official, advertised start time for the event as a whole (commonly “door time”).”. So, for something like this concert, I should set the time to 21:00 as it is the one advertised and not bother adding a start time to each performer relationship?
This is the way that I do it, since someone might just land on a part of the event and want to see the location - But I think you are correct that these two guidelines contradict each other? @reosarevok?
I think the guidelines here might be confusing because they use the word “event”, but they are talking about stuff like live recording relationships, rather than actual “Events”?
Yes re. 21:00 event start time, but if you know performer start times I’m not sure why you would not add them? If you are not sure when the act/s actually started though, then leave them blank.
I will keep it that way then. But I’m wondering if that problem wouldn’t be more elegantly solved by displaying a “related events” section, like MB already do for series.
Ah, sorry, my wording was rather poor here. Let me explain.
The venue only communicate one time, 9p.m. It’s probably the time at which the actual performance starts, not the time at which the doors will be opening. So, should I use that time as both the time for the event and the performers?
Yes, this is about what data to add to a recording. So, a recording that says “Recorded at Festival X”. It has nothing to do with whether to add the data to the events themselves.
If there are more precise guidelines for a relationship type, they take precedence. For instance, for Events please follow the event guidelines, which say to add the event location relationship at every level.