For me it’s the same as links can be ordered if we want.
I don’t see the nuance…
The relationship (link) text can be « … includes … »
Still you don’t get a simple playlist either with sessions as you can keep each track as a separate recording (drums, piano, bass, etc.), not only the full mix.
I would be in favour of adding missing session related data to existing events.
For me, a recording session is an event in a studio.
Event even already have time, not only date, and can be linked to studios (we can already even add sub‐studio if we want to specify in which room it was held).
You and me, we talk about different sessions and maybe about different things.
The traditional sessions of 20s-30s-40-50s don’t contain separate recordings (tracks) for each instrument. Them contain a range of different recordings (takes) of a song or of some songs.
So, I don’t understand your phrase…
Then why the Release has not a relationships with its tracks, but simply includes them?
Why the Release Group has not a relationships with its Releases, but simply includes them?
We have to cover all types of sessions.
Both full mix takes and also tracks (that can be used in later remixes, etc.).
The second type is used to overdub live recordings or to swap musicians, etc.
Thanks to the discussion, I just understood the analogy between the session and the release.
The release contains the tracks.
The session contains the recordings.
The track is an implementation of the recording in this particular release. That is, one recording is represented by a large number (sometimes hundreds) of tracks.
And the session contains unique recordings. There is no other session for this particular recording.
In other words, a session is the same container for the recordings it contains as a release for the tracks it contains.
The session will be also a sole possible container for standalone and never-released recordings (that are known to have been made).
Thus, the session and the release are non-overlapping entities.
This confirms the need for the introduction of the “session” as entity.
I think it’s more accurate to say that recording sessions contain performances. Most recordings as they exist in Musicbrainz will likely not have been finalized at the recording session, but at a later mixing session. And there may be many MBz recordings (mixes) produced from the one performance.
How about this:
A release contains recordings (represented as tracks).
An event contains performances.
So, you suggest to introduce in MB one more new entity called “performance”?
I’m afraid, our two proposals have not a chance to be accepted together…
And, for be serious:
Any recording session produces always the recordings. Them can be issued as them are, or not as them are (then these new recordings become edits or remixes of original one), or never issued. In all cases them still recordings. And you say about remixes. Any remix can’t “annihilate” original recording, which remains always.
Excuse me, but your attempt at a demonstration seems be against Style Guidelines (look at Remixes). If a remix or many remixes exist, this does not deprive the original recording of its status and does not turn it into a “performance”.
I liked @Kid_Devine’s explanation but I think it can be improved. Here’s my version:
A recording session produces a performance. A performance is raw in a way that it only consists of what the microphones captured.
An issued performance becomes a recording (in MB sense). MB recording is a final product and may or may not have been edited or mixed.
A release is a group of recordings in an order. Lone recordings may be singles or standalone recordings (MB guidelines define where the line is).
An event can contain all MB recordings which contain a part of a performance.
Late edit: I don’t mean to create any new entities to MB. There is no need. The term performance is used here to illustrate the relationship between a recording session and a MB recording.
First of all, almost all the recordings issued in the first half of 20th century did consist of “what the microphones captured”.
And most of all, until there is a new entity called “performance” in the database, I will argue that the session is generating recordings, and not unknown “performances”.
So, please, we will return to this conversation at this happy time. But for now I can not consider this as an argument against my proposal.
Sorry I should not have used the term tracks, it’s misleading.
Releases contain tracks linked to recordings.
Session events/series/collections contain or are linked to recordings
Session recording can be just the piano take 2, for instance.
Session recording can be a rough mix of that song, for instance.
Release commercial recordings are indeed more refined but still no need to have another entity like performance IMO, we can reuse recordings for those as we can reuse either events or series for recording sessions.
Sorry, I see nothing in common between “recording session”, on the one hand, and “series” or “collection” (of releases?), on the other hand. This is like comparing green with soft.
Searching in MB documentation, I found neither “collection of recordings”, nor “series of recordings”. What is it? Why turn a session in a collection or in a series (or in a lot)?
I think Event is good solution over creating new Entity.
I don’t like those solutions at all, it was just to illustrate that we already have plenty of ways, but here is how to create a recording series (shared stuff like the rest of MB) and create a recording collection (personal, not really MB content, rather like a list of favourites).
So, is this an event or not? I want to be clear here.
When a musician starts playing, in the studio or in public, it is always an event. But I mean the material fixation of this event - for example, on a magnetic tape. In the same way as we call a concert not only this event, but also records or tapes with the recording of this concert. Thus, the proposed concept of a recording session as entity is the whole set of recordings made during this event (studio session or concert).
If the concert or session took place, but the recording of this event did not take place or the tape was lost, then the event is, and its material fixation is not.
There is a real example of recording session as a set of available recordings:
1955-09-13 - Cosimo J & M Recording Studio, 525 Gov. Nicholls St., New Orleans, LA – Little Richard [vocal, piano on some takes], Justin Adams [guitar], Frank Fields [bass], Earl Palmer [drums], Lee Allen [tenor sax], Alvin “Red” Tyler [baritone sax], Huey Smith [piano on some takes], unknown male chorus*.
LONESOME AND BLUE (take 3)*
LONESOME AND BLUE (false start 4, take 7)*
LONESOME AND BLUE (probably take 5 – master)*
WONDERIN’ (version 1) (take 8 – master)*
WONDERIN’ (version 1) (take 9)*
ALL NIGHT LONG (version 2) (take 3)
ALL NIGHT LONG (version 2) (takes 6 & 7 – composite master)
ALL NIGHT LONG (version 2) (take 10)
KANSAS CITY (version 1) (take 1)
KANSAS CITY (version 1) (take 2)
So, in most cases a complete set of recordings of a session is not available. That’s why this entity can’t be called “event”. But available recordings from this session can be grouped in the entity “recording session”.
I don’t see why we couldn’t call the recording session an event. It is an event.
And available recordings are just… recordings.
And unavailable recordings are… not in MB, as we don’t need to link them to anything by the way.
Update
And sessions would be rare, it’s rather rare, compared to the number of release recordings, to know from which session exactly it is from.
For instance SWEET HEAD (take 4) comes from one of the late 1971 album sessions, but which?
If we knew, we could rightly create an event for it.
Waiting for a specific entity is no need and seems overkill to me.
Unavailable recordings could be recorded (no pun intended) using the setlist of the Event entity. That could also provide an order of Event→Recordings without changing anything on the current/existing Event–Recording relationships.
