History:Location Proposal: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
(Prodoc's home as a location? ;) (Imported from MoinMoin))
(comment about the Address field (Imported from MoinMoin))
Line 47: Line 47:
<ul><li style="list-style-type:none">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. -- [[User:Prodoc|Prodoc]] 09:20, 10 May 2007 (UTC)
<ul><li style="list-style-type:none">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. -- [[User:Prodoc|Prodoc]] 09:20, 10 May 2007 (UTC)
</ul>
</ul>
</ul>
<ul><li style="list-style-type:none">I'd like to see at least a city field, in addition to country. We could use the data from [http://www.geonames.org/ http://www.geonames.org/] for this. [[Geo Names|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. -- [[User:LukasLalinsky|LukasLalinsky]] 10:02, 28 June 2007 (UTC)
</ul>
</ul>



Revision as of 10:02, 28 June 2007

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.

Rationale

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.

Description

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

Name

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)

Type

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

Examples:

  • "Recoding 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)
  • "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)

Dates

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.

Address

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)

Annotation

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

Relationships

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)
  • 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)

Discussion

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)

Archived Discussion