How should venues that have changed their name be handled? Should each name have a separate subject, or should all name variations be combined under a single name and use the "credit name variation" function to distinguish the name at the time of the concert?

For example, The Fillmore Detroit (https://www.posterogs.com/subject/390-The-Fillmore-Detroit) used to be the State Theatre (https://www.posterogs.com/subject/38036-state-theatre-detroit-mi). Should these remain separate subjects or be merged?

This is a good question. I've seen people add older venue names as name variations.

We are considering moving venues into being their own type of entity (as opposed to being a subject like band and artist). Maybe if we do so names through out history should be a part of a venues attributes.

Making venues a stand-alone item adds its own complexity. For example, what do you do with a festival poster where multiple venues are hosting bands? Also, they'd only really be useful for gig posters and event promos, as the rest don't typically have specific venues.

I asked the question, but my preference would be to merge the venues and use name variations. Where that gets tricky is when you don't know the new name of a venue. It would be useful if venues had aliases like artists do in Discogs so that a search for the older name would return the correct venue.

Ding ding ding!
My own thought was/is that venues should be kept separate, even if they are a new name under the same location. Reason is that a poster (of any kind) will only "know" the name that it was at the time of it's issue. Thus the only real use would be if you only know the current name but are trying to search backwards to older shows at the same location but different venue? Don't see a real use for that.

That said, if the different names for the same venue were linked and searchable in some "tied together" fashion as you suggest, paramnesiac, then it would logically work just fine.

Making venues a stand-alone item adds its own complexity. For example, what do you do with a festival poster where multiple venues are hosting bands?

I think we'd allow adding multiple venues (similar to how countries or subjects work now), so that it would still make sense for festival or tour posters as well.

Also, they'd only really be useful for gig posters and event promos, as the rest don't typically have specific venues.

It would not be a mandatory field. So for other types of posters it could easily be omitted.

I think there are lots of other benefits to making venues their own type of thing. We could have an address field and thus avoid putting location in the title. We could make venues browsable on a map and so on.

Would you think the complexity outweighs benefits?

I think location in the title is a MUST for any gig/concert poster. Without it, your search function becomes a bit trickier. But more importantly, the "auto fill" aspect loses almost all worth because you have potential for 40+ posters that say "Pearl Jam 2012" and rely on a long list of possible duplicates when people go to submit where auto filling based on "Pearl Jam CHICAGO 2012" greatly whittles that list of possibles down to just a few.

That said, being able to define a venue by name but also linking to it's address, etc. could be a fun addition. Use google maps or earth to show exactly where something is and possibly a view of what it looks like even.

Being able to add multiple venues would be sufficient, I think.

Also, I agree with yamar3 that locations are a must for poster titles. When I enter titles, I've typically done [headliner/festival name] - [yyyy-mm-dd] - [City], State], [Country]. I don't bother including the venue as it is rare that there would be two gigs in the same city on the same date in different venues.

If venues are a separate entity, then there could be a place on the venue's profile for the address, and maybe other info like capacity or associated venues (like when there's multiple venues in a single building). I don't feel that info would necessarily need to be on the poster page.

Login or Register to post a reply to this topic.