History:Location Proposal

From MusicBrainz Wiki
Jump to navigationJump to search

Status: This page describes an active proposal and is not official.

Proposal number: RFC-24
Champion: BrianFreud
Current status: post-NGS

This is a page describing as enhancement proposal for the MusicBrainz server. It is paralleled by trac ticket 2371. It is related to the Performances and Recordings Proposal.


We found it is often useful to record a physical location related to tracks and releases in MusicBrainz. For example, we would like to record the studio where an album was recorded, or the venue where a concert was performed. The "location" object resulting from this proposal will be used similarly to the Label objects used in the "release" fields of a release.


Enter below a list of features such an object will need.


The name is an identifier similar to what the Artists and Labels have. It will certainly need a "comment" to distinguish between same-named objects.

  • We'll probably need some styleguides to rationalize names for places known only by their addresses. As well, for things like "John Doe home", which we'll probably have in quantity, we'll need some styleguide also. -- dmppanda 21:53, 09 May 2007 (UTC)
  • We should have also aliases because some locations are certainly known under multiple names. --Pabouk 21:26, 2 February 2012 (UTC)
    • All in all, it should be a full entity. One of the suggestions for the Summer of Code is full location support, which would probably help quite much to be able to later add entities for recording and live venues for example.--Reosarevok 21:37, 2 February 2012 (UTC)


There are many kinds of possible "locations" we need to enter, so it is important that this field be well thought out.


  • "Recording Studio" -- this is probably going to be used often for the recording place of "normal" albums, singles and EPs.
  • "Venue" -- this is for places usually specialized for "artistic events" like concerts. This includes concert halls, theaters & amphitheaters, stadiums, clubs. We may want a list of options or use an annotation to be more precise.
  • "Festival" -- often many concerts are performed in a certain location that doesn't have any specific use outside the concert's duration. Since many concerts are performed in such places, it is necessary to be able to retain everything together.
  • Sometimes a "festival" is performed in a location of the other kinds, for example on a stadium where other concerts were held independently of the festival. We should consider if we need location-to-location relationships, to say that "Festival X" happened at "Stadium X"; this could cause, for instance, the address to be copied/linked from one location to another.
    • I don't think this is a good idea. This is obviously redundant information: a festival taking place in stadium A will already have that as its address. Furthermore, a festival could change place, making the "auto-linking" you suggest somewhat moot (unless you want the address field to allow multiple entries). Furthermore, giving a special "status" to festivals allowing them to be "linked" to other types like that would be IMHO confusing and a deranging exception (though, also see below for a proposal about an AR "changed place", somewhat related). -- dmppanda 21:53, 09 May 2007 (UTC)
    • IMHO the relationship is useful because minor variation in the address could cause that you will not be able to see that the festival happened at the stadium. Also with the relationship you will be able to easily list all festivals which happes/happened at the location. --Pabouk 21:26, 2 February 2012 (UTC)
  • "TV Station" -- For live recordings in a TV show.
  • "Radio Station" -- For live recordings in a Radio show.
  • "Stadium" -- Big concerts are often given in a stadium.
  • "Other" -- I've seen things recorded in hotel rooms (there's a Roxette album for instance), private homes, and other funny places like this. We'll need to use annotations to explain some of these.
  • Suggesting to add something like "Flat" (or "Home"). What do you think? -- dmppanda 21:53, 09 May 2007 (UTC)
  • You're really opening a can of worms here. I think we should only include the most used locations. If we start including places like this, it will only be a matter of time before people want a "Toilet" or "Bathtub" included as well. There are always artist crazy enough to find ridicules places to perform and/or record. -- Prodoc 09:20, 10 May 2007 (UTC)
    • Hé, bathtubs :D You have an argument, sure, and I won't insist too much on that if this really is problematic. Just a few thoughts: bathtubs and toilets are not "locations", they are inside a location. On the other hand, an artist's house/home/appartment is a location. Again, I'm not obsessed. Feel free to move this to old discussion if I don't make sense ;). -- dmppanda 09:39, 10 May 2007 (UTC)
      • I would agree that the lowest level really would be the physical address, in most cases - flats wouldn't need their toilets listed. However, there is an exception - large locations only have a single address, but we most likely would want to support sublocations for these - the various stages at the farm for the original Woodstock, etc. (I can think of many festival concerts where there is one address and 3+ stages). On regular homes and flats, though, I can think of many demos which would have a flat as the location, and for concert bootlegs, we actually already have at least two such bootlegs in the database. -- -- BrianSchweitzer 03:20, 22 October 2007 (UTC)


Similar to creation date for Labels, birth/death date for [Artist]s, etc. It's less important for studios and venues -- though by no means completely irrelevant -- but it's very important for festivals and similar events.

  • Maybe consider date ranges to support a phrase like: "Recorded at Olympic Studios, London, UK (Studio A) from 10-02-1973 through 11-23-1973' davygrvy


Of course we're most interested in where a location is. I suggest a specialized country field that works exactly like the one for the Releases, and a free-form text field for the address (as the format can be different for different countries). We can also add an (automatically-generated) URL to the Google Maps location of the address.

  • An edit note I saw someone make the point that individual elements for the address might be useful in separate search fields. The reason is that this would allow somewhat easier looking for venues, and thus concerts, in a certain area. However, I think that completely dividing the address would be overly complex (for the rewards) and confusing. (Consider that address elements are different in different countries.) We might consider, though, adding a third field between address and country; in most countries that would be the city, in the US it would be "City, ST[ate]" -- the point is that it's free-form enough to allow for each country's organization. Anyone who needs more should probably use a mash-up with Google Maps and the web services... -- Bogdanb 22:43, 02 May 2007 (UTC)
    • The way we provide people to specify an address should be separated from the level of detail we store and display. Many sites (including Google Maps) seem to get away with just one input field where users can enter parts of an address. We could do this as well and provide a list of matching results to select from. -- Prodoc 09:20, 10 May 2007 (UTC)
  • I'd like to see at least a city field, in addition to country. We could use the data from http://www.geonames.org/ for this. GeoNames also contains coordinates for each location so we can easily link to Google Maps, calculate how far are two locations from each other, etc. -- LukasLalinsky 10:02, 28 June 2007 (UTC)
  • I agree with Lukas. We should have at least the city field separate. And what about coordinates for locations far from cities? (concerts at fields, woods, under bridges) --Pabouk 21:26, 2 February 2012 (UTC)


This is certainly going to be useful for many locations, especially for concerts and festivals.


Add any relationships here

  • URL relationships:
    • official home page -- Many locations will have an official home page; this includes studios, venues, and festivals.
    • other -- Especially for festivals there will be both official and unofficial sites. Bootleg sites may also have pages with bootlegs organized by location.
    • suggesting "has a picture at url" -- dmppanda 21:53, 09 May 2007 (UTC)
    • suggesting "has a wikipedia page" -- dmppanda 21:53, 09 May 2007 (UTC)
    • suggesting "has its history presented at" -- dmppanda 21:53, 09 May 2007 (UTC)
    • suggesting "tickets can be purchased at url" equivalent to the release purchase ARs -- -- BrianSchweitzer 03:20, 22 October 2007 (UTC)
  • Location to location AR:
    • "has moved place to": a studio can move. A personal artist apartment can move as well. We'll need two entries in such a case, and we should relate them using this AR. Even more important for Festivals IMO, which are likely to move more. -- dmppanda 21:53, 09 May 2007 (UTC)
  • Location to Artist AR: not too sure about all these yet, but they have interest
    • "was the home of": obviously should be used for personal appartments -- dmppanda 21:53, 09 May 2007 (UTC)
    • "was created by": for festivals, maybe for studios and venues -- dmppanda 21:53, 09 May 2007 (UTC)
  • Location to Label AR: idem
    • "was owned by": for studios, and possibly venues/festivals as well. -- dmppanda 21:53, 09 May 2007 (UTC)
  • Recording events: of course we'll need to link the venues with many release events; perhaps we need a separate wiki page for discussing those.
  • Agreed that we need a separate page for that. I really don't like at all the idea of a core relationship between releases and locations. IMO, using AR makes much more sense. -- dmppanda 21:53, 09 May 2007 (UTC)


Personally I don't think the description in the Rationale section should be the way to do it but I might be misinterpreting the last line. At the moment it seems you want to link a location to a release event. A release event, however, doesn't have much to do with the location. Instead, what I mean in the initial ticket was to basically be able to specify a location with the different available AR's. This will provide much more flexibility than to link it to a release event and reduce the amount of duplicate data. When you enter e.g. a Recorded By AR, there can be a location section where you can specify where it was recorded. At the same place you can already give the date when it was recorded. The idea to add the locations as a new entity next to Artist and Label remains the same. -- Prodoc 13:14, 02 May 2007 (UTC)

  • On second thought, it's not always as easy to determine the person who did the recording, mixing, etc. Adding locations to those existing ARs might not be the best idea. This will also cause duplicate location to be added when e.g. the mixing has been done by more than one person since you can add the location to each 'Mixed By' AR. We could introduce a series of new ARs just for the locations like 'Recorded At', 'Mixed At', 'Produced At', etc. with a date field again. Yes, people might add the dates to both the 'Recorded By' and 'Recorded At' AR but do note that the dates might differ (multiple recoding locations, multiple people recording). The question is is it acceptable to introduce a whole series of new ARs just to achieve this? -- Prodoc 08:44, 03 May 2007 (UTC)
    • Yes I think it's acceptable, and I definitely agree with this. IMO much better than a core relationship. -- dmppanda 21:53, 09 May 2007 (UTC)
    Your proposal was (in my head) related to something else I wanted to have, see the PerformancesAndRecordingsProposal (which I forgot to link the first time). However, once we have the Location object, it'll be relatively easy to link it to ARs, though I don't know if current ARs allow more than two objects to be linked. -- Bogdanb 10:30, 03 May 2007 (UTC)
    • AR don't allow more than two objects to be linked using one relation as far as I know. -- dmppanda 21:53, 09 May 2007 (UTC)

The Address is a tricky but very valuable part of this concept but should not be limited to just being used for the locations. I'm almost tempted to say that the address part should be the first thing we should implement separately from this location concept. The location concept can also be implemented without the address part at first. The reason for this is that, as stated above, the address part is very tricky to do right and a lot of work to collect information from different resources (lists of states, provinces, municipalities, cities, towns, etc. for each country). I got the hint to contact Russ about this since he worked on this for last.fm as well. It could save a lot of time. When we have the address functionality figured out we can implement this as part of the Artist information. This would be a smaller step and allow us to test it on a smaller scale first. By including the address functionality in the artist information you can specify the 'birth' place of an artist or group. I am, however, reluctant to allow users to specify a very accurate address in this situation. It should only be until town/city level to prevent any privacy issues. In case of a location address it can and should be as accurate as possible down to the street name and number. -- Prodoc 13:14, 02 May 2007 (UTC)

  • I agree that the addresses are tricky, but I don't see why they're that valuable for MusicBrainz. Actually, to be more precise, I don't see why we'd need to use tightly defined fields for addresses, more than for country and city. Those are useful for sites that have some geographic function, which is when you actually need to analyze the elements of the address programmatically. It's always a trade-off between usefulness and complexity. Is there a good reason why we need to present the user with seven different entry boxes if we don't need them separately. For most things users are only interested in the city. For the rest, a simple text field would be enough for the address; we can very well add a few explanations on how to fill it, if the user wants, but that's pretty much it. Consider that just having many fields does not mean better info automatically. Actually, if users put things in the wrong place, or if we forget a field that's needed for some addresses, the information quality actually goes down. Many fields will be be filled with blanks, too. You have to remember that addresses can be very different in different countries. There may be municipalities and other divisions (more than just state/city), even in small countries. Japanese addresses usually don't contain street names: Japanese_addressing_system My point is not that it's not possible, is that (1) it's hard to implement, (2) it's hard to use, and (3) it's not necessary. We have few resources as it is (both developers and good users), we shouldn't waste them on things we don't need. -- Bogdanb
    • I certainly agree with that: the only relevant part IMO are indeed the country and possibly *one* text field that should be used for the city/country. I absolutely fail to see the point in specifying street number and such - eg: we are not a geographical database. -- dmppanda 21:53, 09 May 2007 (UTC)
      • While in most cases just the country and village/town/city name is enough, in some cases you do need to include the state or province since some village or town names occur multiple times in a country. In the Netherlands there's even a case where the same village name occurs twice in the same province so the only way you can make a distinction is to be able to specify the municipality as well. I bet this won't be the only case we will encounter. While we do not need to force the user to specify all this, we do need to have such a level of breakdown in the db. Like stated earlier on this page, for the user we can provide one input field allowing them to specify bits of the address. A list of matching results can be provided allowing the user to specify the correct village/town/city. What is actually displayed to the user in the end can be made dependant on the village's/town's/city's situation. Of there's only one occurrence in a country, only the country and village/town/city name is displayed. If it's exists in a country multiple times we could automatically display an additional level. As for the street name and number, true, in most cases it's not needed but why should we limit ourself to only the village/town/city? Like Bogdanb stated, we might as well add a different input field for this. It's up to the user if we wants to add the information. It can be useful when we have different venues in the same city. Suppose we add the functionality to enter a complete tour with dates and places an artist performed and provide a visual graph of this. When an artist played in the same city more than ones but in different venues, you wouldn't be able to see this in the graph any more. -- Prodoc 09:20, 10 May 2007 (UTC)

Another problem we'll need to address (we missed that for labels) is what to do for the rare but plausible situations where the city & country are known, but not the venue. In such cases we may need some special "[unknown venue], City, Country" venues. The problem is that we'll probably need a lot of these -- potentially, one for every city. We might want a shortcut or some other special trick on the server that creates these automatically when needed, and deletes them automatically when not used anymore (because they were replaced with a precise venue). Or we could have a separate "special-case" type of "performed at" link that simply has no venue. -- Bogdanb 11:21, 04 May 2007 (UTC)

  • I just had another thought. We could simply have separate fields for country/city in the "performed at" line, the same way that release locations are not auto-populated with the label country. This would allow traditional cases where a concert is officially in "Tokyo, Japan", but in fact the venue is in a suburb or other close-by town. This will allow us to have a simple "[unknown]" venue that can be used everywhere. We'll need strong warnings, though, to avoid errors. Obviously a very strong one against venues in a different country than the concert (it may still be possible close to borders), and maybe one that can judge distances between locations (using Google maps or something). -- Bogdanb 11:26, 04 May 2007 (UTC)
    • I rather think we should live with that and use SpecialPurposeLocations, with a very simple style for the names like [unknown, Country], or [unknown, City, Country]. While I agree the city and country part will be redundant (as they will be set in the corresponding fields), and while your argument about the quantity of them is definitely valid, I think that may work decently (and has the advantage of not requiring extra dev work). As for the "auto-creation/destruction" of such Locations, I don't understand what you mean... The user create the entry, fine. If it's not linked to anything (anymore), it will be deleted by modbot. -- dmppanda 21:53, 09 May 2007 (UTC)
      • Well, since we're throwing around ideas, I would rather thank balkanize [unknown venue]. I would rather there be some way to store the entire location per event, but still keep all the unknown venues together. One master list of [unknown venue] is easier to clean up than potentially thousands of single-show "[unknown venue], city, state, country" listings. Or perhaps better, thinking about it, we have those thousands, but also some way to simply see "all [unknown venue]", "all [unknown venue] in New York State", "all [unknown venue] in the Netherlands" (and if we're storing continents? "all [unknown venue] in Africa"). -- BrianSchweitzer 03:44, 22 October 2007 (UTC)

Is there any possibility of leveraging Upcoming.yahoo.com's API for pulling and pushing data? I'm willing to contact Andy Baio (who started Upcoming.org before it was bought by Yahoo!, and AFAIK still works there) about it. I think that he'd be a fan of something like this... -- gfmorris 01:15, 22 October 2007 (UTC)

Expansion of LocationProposal / Benefits of LocationProposal

This is rather long, so setting it apart from the above comments...

Something Prodoc and I were tossing around in IRC the other day... Given Locations, there's also another level we could setup, massively leveraging the data we have, and allowing perhaps some potential revenue for MusicBrainz. Ok, let's say we add Locations. We already have artists and bootlegs. If we also add setlists and tourlists - perhaps from such sources as Upcoming (as gfmorris mentioness above), or perhaps user entered (or both) - we then have the structure to allow something like this:

  • Artist is going on tour. We have a tourdates/locations list.
  • Each location can link somewhere where users can purchase tickets for the event. (Also, perhaps we would want a "was/will be streamed by" or "was/will be broadcast by" pair of ARs? The same radio stations, etc, that are locations above would apply, so it ought not to entail adding otherwise unused locations.)
  • Once shows have been played, setlists can be added. (A "setlistography", if you like.)

Now we have everything we need to eliminate LiveBootlegStyle and LiveTrackStyle. Tracks in bootleg (and promo/official) releases can now be linked to that track in the particular setlist. Currently, if you have 4 bootlegs, each a different recording of the same concert, perhaps also a few official releases - and all different recordings - no AR allows us to say "these are all the same performance of the same song", so these tracks end up isolated from each other. Linking them back to the setlist listing would allow them to all be related to each other, via the setlist track. Benefits: Revenue for MB from ticket referals, better and cleaner representation of the relationships between different tracks from the same show, elimination of LBS and LTS - and very useful for the music fan. One additional data leveraging that could be done: Given tourlists, given artist tags, given personal artist tags, and given the "related artists" data, we can now also present "What artists similar to this tag are touring?" "What artists like the current artist are touring" - and using the physical location info from Locations, you could then filter down to "What artists like the one I like here are going to be touring near me soon, and where can I buy tickets (and in the process, help contribute referer $$ to MB)?" -- BrianSchweitzer 03:35, 22 October 2007 (UTC)

  • I think that this is all very exciting, but how do we even begin to verify setlists without the attendant recordings? What would our objective evidence be? -- gfmorris 02:26, 23 October 2007 (UTC)
    • Quite often these days, artists are making that information available on their websites. Many fan sites now also have setlists posted within an hour or two of the end of the concert - take a look at the better Pearl Jam or They Might Be Giants fan setlist sites, for example - it's all there, confirmed from 4-5 different attendees, within hours. And, were it to be discovered we'd missed a track's having been performed, just like we can add tracks, we could add there as well. I think the standard for setlists would have to be a little more flexible that for releases, however, in that if the editor was at the show, they may not have an actual site they can link to for verification. -- BrianSchweitzer 16:06, 19 February 2008 (UTC)

Archived Discussion