Database Relationships - when to use TOUR and why can't a recording both be IN a town and AT an arena?

MusicBrainz Style
1

Can someone who understand JSON \ database lookups \ and all that jazz help me understand these NO votes.

To be clear - these are both questions about database lookups. Not what a human can work out when looking at a written page, but the results returned to an external user querying the MB database.

1\ If a live recording happens in an arena then we have music being performed both “at dm-arena” (a building) and “in Karlsruhe” (a town).

Why can we not state both of these facts?

If the relationship for “in Karlsruhe” is removed will a database query for “what recording were made in Karlsruhe” still return this recording because the arena is at that address? Or are these fields very separate?

These are two different relationships returning to different types of answers.

This has upset an editor and is trying to “delete duplicate information”, but all I see it a different type of relationship. If a database lookup saying “which town” still works on that recording with only the arena location, then I’ll remove my no votes.
https://musicbrainz.org/edit/67153245

image
image728×448 53 KB

2\ This Peter Gabriel tour has produced officially released CDs for every gig. So I put those into a Release Group Series. I then found the Series relationship to link to a “Tour by Peter Gabriel”.

Again I am being told to delete that relationship, even though it seems to be allowed by the GUI.

Surely there is nothing more sensible for MUSIC database to link the MUSIC to the tour? The idea was anyone who lookup on details on that TOUR relationship would be lead to the Release Groups holding the music.
https://musicbrainz.org/edit/67158069

image
image777×701 230 KB

Yes, I can see that an Event could be created for every one of these releases. And then a series made of those events. And then those events linked to the tour - but that is not realistic. I don’t have that time available to do that level of research and editing.

Surely it is common sense to allow the actually relevant music to be connected to a Tour type?

3\ On a side note to this, before someone says “you have to make events for all of these before you can link to a tour”, I have tried creating events before but can see that the interface is not used often as it is a huge text field editor without any kind of preview. So one mistake… and then the whole editing process is lost into the seven day limbo of edit changes…

2 Likes
2

Adding the event itself isn’t so bad; you’re probably thinking of the setlist (and, optionally, performers) box which is a little clunky. However, you can create events without a setlist.

6 Likes
3

Regarding #1, I don’t know the answer regarding the database query, but I can see the logic to the “only add the most specific” principle. Otherwise, should we have rels for “Recorded in Baden-Württemberg, Germany” and “Recorded in Germany” in case someone wants to query directly on the state or country? Duplicating information that can be derived is not best practice.

Regarding #2, the relationship seems confusing to me (and, it seems, to other editors commenting in the edit notes as well). The RG series is not a tour. I suppose if the same rel existed but the text said “…documents a tour by…” it would make more sense.

It also seems like we don’t have an option for a “recordings from” Series-Series relationship. Ideally we could have an event series representing the tour and link it to the RG series.

1 Like
4

The problem IIRC is that you have to follow a certain syntax and there is no preview and the edit is not autoedit so you don’t really know if you got it right or wrong.

3 Likes
5

The biggest trouble I had was the weird formatting rules. Trying to work out how to get highlighting to work. How to get the track list in to place correctly. And once the first attempt has been tried, that is all you get. Every other attempt is then in a seven day queue and you then have no idea if your correction is even correct or not.

I think this may well have been the setlist, but that is an important part of the event.

The event I was editing was even more of a mess due to there being multiple artists with multiple setlists.

I am used to all the bold, italic, and stuff like that using ’ but there are other unique codez in that edit box that are a bit too confusing.

And in this case we are talking about 30+ concerts and counting. That really is way too much work. Especially for an artist I am not even interested in! I only stepped in to help tidy up a mess of the data that was already there. I’ve ended up down a rabbit hole of chaos here way deeper that I ever meant to get involved.

But we are OT from my main questions…

6

Much of these questions came from “guidelines are not rules”. And I am kicking the guidelines to see why they seem to be restricted in certain ways that seem illogical for a database.

This is why I am hoping a database person will stand up and say “Yes, if the concert is at XYZ arena, then a database request for City, State or Country will be extracted from that arena’s location”.

To me that would then be truly related data.

If deleting the city means no one can find out about concerts in that city any more - then that is bad design. And a bad guideline if a valid relationship then has to be removed due to be not specific enough.

Surely it is interesting to someone to ask a database “How many tracks has Peter Gabriel recorded in Germany?”

Maybe I understand a tour in a different way? A tour is a series of concerts. And this RG I created is a series of the audio of those concerts. Official releases, not bootlegs.

I can see I am probably pushing definitions in a different way, but the relationship is there to be used.

If it was not allowed, why can I select it as a relationship for a RG Series? Even more confusing as the only guideline being quoted at me is one that clearly states that my linking of the tour should be allowed. Relationship type / Tour - MusicBrainz That only mentions “entity” and nothing in there says “only event type is valid”.

I guess this is another one of those where the documentation is lacking the usage?

Much of my point is we have so many bits of quality data in this database which could be linked in brilliant ways. And I feel in this case I am being stomped on by someone quoting “guidelines” without looking at the bigger picture.

Surely it makes sense to link Event, Arena, City and Release together? Would it not be more useful to people to be able to click between all those different items to find out about all the relations that this database could know about?

7

A bit unrelated, but if I understood the voters correctly their main concern was that the dm‐arena is not in Karlsruhe but in Rheinstetten. And while Rheinstetten is in Karlsruhe and belongs to the administrative district of Karlsruhe it still is a separate city.

Now of course all advertisement for a concert will likely say Karlsruhe since nobody would otherwise know where the small city of Rheinstetten is. Hence I’m a bit torn how to treat this really. I mean Karlsruhe is maybe strictly speaking wrong, but if I went to this concert I likely would say it was near Karlsruhe when explaining someone.

2 Likes
8

We could use Rheinstetten, credited as Karlsruhe.

1 Like
9

Bingo. Bang on. :slight_smile: Exacatly the issue I hit.

1 Like
10

Trust me to pick the wrong example - blame Peter Gabriel for that mistake. He thought he was performing in Karlsruhe and I assume that is why he put it onto the cover.

The same editor has set remves for many other similar edits where he thinks it is a “duplicate”. He was quoting guidelines originally. His point is not the German geography. His point is he thinks it is all duplicates and should be banned because a human should already know where the dm-arena is.

I’ll happily remove that single example if the geography is wrong.

It is still missing the point - the editor decided to remove the details because he thinks stating a concert is “at Wembley Stadium” and “in London” is duplicate information. If we have a concert listed as “at Wembley Stadium” then will a database request for “recordings made in London” return the recordings only tagged as at Wembley Statium?

And yes - Wembley town and district within London. But it is still called “London” to the people who visit.

1 Like
11

Yes, but a recording of the concert is not the same thing as the concert itself. Or as Rene Magritte put it:
MagrittePipe

6 Likes
12

I’m confident that that information could be queried from the database using either the Place or the Area relationship, because both the Place dm-arena and the Area of Karlsruhe are linked, ultimately, to the Area called Germany.

However, I am not confident that I, personally, could construct the query that gets you that answer!

4 Likes
13

The events page for the Germany area does show all events set to areas that are part of Germany already, but it does not currently show events in places inside Germany. That would be a reasonable thing to add to it, and was requested by Freso already as MBS-8070 - I’ll try to get to it at some point for sure :slight_smile:

8 Likes
14

Basic database theory includes normalisation, which is basically the idea to not duplicate information. If we link an entity to both an Area and also a Place that in turn links said Area, we have effectively linked the Area twice—which goes contrary to database “logic” as per the practice of normalising the data.

8 Likes
15

Thank you for answering my question. Though the ticket confuses me as that talks about events. I was talking about a building in a town in a country.

And you lost me somewhere in that paragraph - I think you are saying “don’t say the same thing twice.”

Following what @reosarevok says - if only the country can be extracted from the Place then we don’t yet have duplicate data? Is it not only duplicate data once the Town can be extracted from the Place?

-=-=-

Note: On the TOUR question. I am removing all the “TOUR” relationships I added as I now see how that conversation has rolled on pointed out that the GUI is allowing relationships that are not expected. Would be good to get clearer documentation on that as all I was doing was going through the available Relationships on an edit of a RG Series.

-=-=-

With the documentation so vague, can something not be done with the GUI to make sure it doesn’t offer illegal relationships? In both of these cases I just added what the editor offered me. I am now worried that I can’t look through the edit GUI and select other relationships in case they are also not allowed. It does make this place confusing if illegal actions are allowed in an interface.

2 Likes
16

Bizarre argument. Surely a pile of text on a page showing a setlist (or event type) is also not a concert either? :joy:

17

Oooh semniotics. :crazy_face:

And surely pixels on a screen aren’t metadata unless there is agreement that they are.

What is agreed about “metadata of recordings being properly referred to as a tour” is less clear to me than " a pile of text on a page showing a setlist" being agreed to be part of a description of a concert.

As catalogers we have already taken thoroughly to using “the thing” to refer to a description of a thing.

You want to call metadata of specific audio-recordings “a tour”?

I like the idea right now.
And hope someone will point out the downsides clearly.
Charles Sanders Pierce and other enquiring minds want to know.

18

Of course not; it is a record of the concert. And an audio recording is a different kind of record of the concert. And the metadata for the audio recording is a record of a record of the concert. :smile: :upside_down_face:

4 Likes
19

This is not what reo said. What reo was saying was that by your logic we should add relationships for both the city and the country as Area relationships, since you will need to do additional lookups to find the country if only the city is linked.

Places are already located in a city (or whatever is most precise that we know and can represent, so sometimes this will actually be a district within a city, sometimes it will be municipality/region since the city is not in MB or exact city is unknown), so you can find this information by looking up the Place. And then you go from the Area linked to the Place up the chain until you find the country if that’s what you’re interested in. (Going Place→Area→Area→…→Area is really only one more step than Area→Area→…→Area for finding the country, if that’s what you’re after.)

E.g., if you look at the Studio-type Place SB Studio, it has an Area, Vadum, which in turn is linked to another area, Aalborg Municipality, which is then linked to North Denmark Region, which is finally linked to Denmark.

Following your originally proposed logic of linking a Recording recorded at that studio to everything so they can be retrieved with a single lookup you’d have to link both the Studio Place but also four separate Areas, since you can never know which one a requester might be interested in.

2 Likes
20

To amplify (I hope) on what @freso said, linking a recording to the dm-arena with a recorded-at relationship allows one to construct any of the following queries:
“what recordings has Peter Gabriel made at the dm-arena?”
“what recordings has Peter Gabriel made in the city of Rheinstetten?”
“what recordings has Peter Gabriel made in the state of Baden-Württemberg?”
as well as the query “what recordings has Peter Gabriel made in Germany?”.

2 Likes