Istanbul was Constantinople, If you've a date in Constantinople she'll be waiting in Istanbul

MusicBrainz Style
, , ,
1

So… MusicBrainz uses "XG as the ISO 3166-1 code for East Germany (DDR), rather than “DD”, and it seems that since the ISO officially deleted the “DD” code from ISO 3166-1, it’s available for reuse. (Contrasted with a “Transitional” registration, where they won’t reuse it for at least 50 years. (Netherlands Antilles or Yugoslavia, for example))

So… That makes sense… But I started wondering how MusicBrainz handles events, and releases from countries which no longer exist. And, I can’t seem to find any official documentation or style guild policy of anything about it. Examining the actual data in MusicBrainz, usage appears to be inconsistent. Most of the time the current, Gregorian year 2020, area name is used, rather than the name of the area at the time of the event.

MusicBrainz does have artists and events in “East Germany”, and “East Timor”, and a bunch of countries which no longer exist. But it also uses current locations for stuff prior to WWII.

For example, Antonín Dvořák was born on September 8,1841 in the Austrian Empire… but MusicBrainz says that he was born in the Czech Republic AND that the Czech Republic began in 1993


https://musicbrainz.org/area/51d34c28-61bf-3d21-849f-7492672a9d44

Wolfgang Amadeus Mozart was born January 27, 1756 at No. 9 Getreidegasse in Salzburg… in the Holy Roman Empire. Musicbrainz says he was born in Austria, which isn’t exactly the same thing as the Archduchy of Austria

Even in recent history (my lifetime) there’s a lot of this kind of stuff going on. The breakup of the USSR, Yugoslavia, Czechoslovakia, etc. Here’s a list of some: http://www.statoids.com/w3166his.html
(And here some more stuff about trying to keep ISO 3166-1 up to date https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 in fact… Whenever a country needs a new code, because it changed names, split up, or merged, it goes into ISO 3166-3 https://en.wikipedia.org/wiki/ISO_3166-3 )

So… because countries are just a made up thing that doesn’t really exist…

I think the way to simply this, is to store the space-time coordinates, a center point and radius, of an event, and then look that up in a gigantic table of place names, to see what humans called it at that time.

So, Mozart was born at 47°48′0″N 13°2′36″E plus or minus 24 meters, on 1756-01-27Z plus or minus 24 hours. You look this up in your big GIS database, and out pops “Holy Roman Empire”.

(And I checked, this area was using the Gregorian Calendar by the 1750’s)

If you only know a country, then you can point to its approximate center, and say, it’s here plus or minus 123 km, or however large the area is.

Existing place and area stuff can just do the reverse transform to get WGS 1984 coordinates.

There’s got to be an existing database like Open Street Map with most of this data already… right?

–
Update: Being able to enter GPS coordinates for an area (not place) helps if the particular town or village doesn’t exist in MusicBrainz yet, and so you need to file a bug report to add it, or just leave it as the next largest named area that does exist in MusicBrainz. Then MusicBrainz can catch up later and put a human recognizable name on the coordinates.

12 Likes
2

Why they changed it I can’t say, people just liked it better that way…

4 Likes
3

Totally agree. Countries have changed constantly over the centuries. Especially the borders within Europe. The more we can nail someone down to a town\city the better. Towns may change name, but tend to stay in the same place. A co-ordinate would be even better.

I have tripped over this at times as the MB places list is not complete. I may have the actual town or village for someone’s birth but cannot select it. Or the district within that town. Being able to add co-ordinates for them would be an ideal solution. And yes - OpenStreetMap is a good source for these narrower areas.

It would then be interesting to see that an Artist was born within a few metres of a famous location. Or in the “posh end” or “rough end” of the town.

I also really don’t like having to select “Germany” for a CD that was “Made in West Germany”. Not only is it wrong, but it misses the point of dating that time in history.

2 Likes
4

I forget if you were involved in that conversation, but we’ve had it already: it was officially the same country, so separating it would actually be kinda wrong. Same as if Ireland at some point incorporated Northern Ireland or something, it wouldn’t stop being Ireland.

For other historical issues: this is also a discussion we’ve had in general. It would be nice to have, but it won’t happen unless we get to a point where we can just make it happen automatically without us having to deal with all these areas. Lowering stuff to city is ideal, and if some we need are missing we should just add them.

8 Likes
5

Hypothetically, how should someone add this recording to MusicBrainz?

It was recorded on September 24, 1900 in Berlin, in the Kingdom of Prussia, in the German Empire.

The current state of Brandenburg was established in 1990 when the GDR and FRG merged. Prior to that Berlin was in the District of Potsdam, established in 1952.

In 1900, when this recording was made, the Kingdom of Prussia included parts of what is now Poland and Lithuania. The German Empire ended in 1918. The FRG (West Germany) began in 1949

Are these al the same area?

This is “Germany” in 1900 https://en.wikipedia.org/wiki/German_Empire#Map_and_table
And today… https://en.wikipedia.org/wiki/German_Empire#Territorial_legacy

1 Like
6

You can set it to Berlin or even an area within Berlin if that is known. Regardless of the various states Berlin has been a part of, the city remains the same. A user or machine can combine the area, recording date and information from other databases like Wikidata to derive things like the country of the recording (and decide whether to use historic or current country names). This doesn’t have to involve MusicBrainz, because these things are simply out of scope for the project.

The only feature that requires a fixed list of countries is the release country. It could be useful to have certain release countries that no longer exist because releases were explicitly released there, like the USSR or Czechoslovakia.

2 Likes
7

The wax cylinder phonograph was invented in 1877, and the flat disc “Gramophone” was first marketed in Europe in 1889.

The Volta Graphophone company was founded in 1886
The Edison Phonograph Company was founded in 1888
Columbia Records was founded in 1889
Pathé Records was founded in 1890
RCA Victor Records was founded in 1901

… So, that’s how far back the list of release countries will need to go.

But… like… There’s more than just commercially released sound recordings in MusicBrainz…

For example,

Queen Lydia Liliʻu Loloku Walania Kamakaʻeha, was the literal queen of the Hawaiian Kingdom, and was not born in the United States. The Kingdom of Hawaiʻi was very much not a part of the United States prior to 1893.

This work, https://musicbrainz.org/work/37664112-6b65-32df-80d6-a0837451b6f8, was composed in 1878… in the Kingdom of Hawaiʻi, not in the United States.

There are record companies that have existed for longer than Hawaii has been a US territory.

5 Likes
8

All of these can be added to a smaller area independent of the country they are a part of now.

2 Likes
9

Just a note from Wikipedia: Music of Hawaii

… the beginning of the Hawaiian recording industry was in 1906, when the Victor Talking Machine Company made the first 53 recordings in the state.

That would have been in the Territory of Hawaii in 1906

1 Like
10

Totally agree! The idea of using a GIS database instead of in-house maintained areas has been suggested as a GSoC project for two years already. (See 2020.)

Good question, probably yes.

4 Likes
11

Linking to a geographical database seems like the best option, if it is possible.

In lieu of that, can anyone explain why “areas” are treated differently in MusicBrainz than most every other piece of data? If I want to add a venue, I can just do so, but if I wanted to add an area, I need to submit a ticket and have it languish for years until a very harried area editor gets around to doing it (or not). Why not have areas editable by the general community, and voted upon and all the rest? That way if foxgrrl wanted to create a Kingdom of Hawaii area to more properly cite the birthplace of Queen Liliʻuokalani, she’d be free to do so (assuming it was voted upon favorably).

1 Like
12

Overall, it works much better than that:

  • 96% of requested areas have been added.
  • 9 days is the average time of resolution over the last year.
  • 276 tickets have been resolved for 282 tickets created during the same period of time.

Big thanks to @drsaunde for his continuous support to make it work!

That is a good question, and I did not find any documentation that answers it. My guess is that it was the most efficient way to support areas at first., to the cost of soliciting the dedication of a specialized editor. Benefits are that areas always have references, the structure of related areas is fairly homogeneous, and only needed areas are entered in the database. Downsides are it take time to the area editor, it delays the time of creation of an area. @reosarevok, @drsaunde: Do you have more history/rationale about this?

The answer to this is probably (going to be) in the (upcoming) answer to your previous question.
But potential downsides can be already expected, see current benefits in the above paragraph.
Plus, it would require editors/voters to be knowledgeable enough about editing/reviewing areas.

5 Likes
13

Mostly that. It being editor-added was always intended as a stopgap until we got a bot to add them again, but we haven’t gotten to that yet after god knows how many years :confused:

4 Likes
14

Thanks for the stats on area editing. I was being a bit hyperbolic, I seem to recall in times past it would take a while, but it seems to have greatly approved (especially with the help of the always awesome @drsaunde)

2 Likes
15

This approach seems likely to result in separate entries for “Vienna, Austria” and “Vienna, Austro-Hungarian Empire” and “Vienna, Holy Roman Empire”. The city is the same city regardless of the various political entities it’s been a part of.

4 Likes
16

Areas would need to have dates of when they are valid. All “Vienna” entries would be the same, but the location would change by year.

17

I guess I don’t know how that would work from a data model perspective. Currently you have an area (Vienna) that has a part-of relation to the country it’s currently within (Austria) - or in other cases to a state or province, which in turn has a part-of relation to a country. If there are separate area entities for the Austro-Hungarian Empire and Holy Roman Empire, Vienna would have to be “part-of” those areas as well.

18

That remaining 4% is stuff that’s either been completed or is out of scope, i could go back and close those 4% if that’s something that people really want, i just haven’t been bothered to do so.

The 9 days is more a process thing for me, adding 1 area take a little time with my process, adding 10 areas doesn’t take much longer, so what I do is that I wait until i usually have at least 5-6 open requests to make better use of my time, I can of course change this if this is actually an issue, I could easily do a 24/48 hour turnaround for these, i just didnt realize there was a demand for this.

The intention was and always has been, to make areas 100% automated from someone elses database. Someone who can easily handle all these changes in ownership of a specific area over time. Area’s are not our expertise and they shouldn’t be, they are only tangentally related to music.

Everything so far has been stopgap, which is one reason i have refused historical areas as it adds a huge layer of complexity for very little payoff.

As far as I know we’ve been unable to co-opt another database to serve our needs so we continue on in a stopgap scenario. I had to beg and plead to be allowed to add areas, before I was allowed to start adding them, no areas were added for a period of a few years.

10 Likes
19

From my experience, having requested a couple of area adds, I have no problem with the timeliness of @drsaunde’s process.

3 Likes
20

This would quickly spiral out of control, with different editors having different needs and preferences and the need to review all of these edits, which takes a lot of effort that’s being diverted from what MusicBrainz is meant for: music. Feature creep is real, people. :slight_smile:

The delay in adding areas is fine by me. I never need anything in a hurry, because areas are always end points: additional information to add to entities, but never entities that need to be built on themselves. I always leave a link to the entity that needs the area in the area request ticket, so that when I get the automatic e-mail saying that the area is added I can quickly add the missing information.

4 Likes