History:Advanced Relationship Type Development

Status: This Page is Glorious History! The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

About the Development of Advanced Relationship Types

Status: The following text and discussion documents the work of setting up an initial set of AdvancedRelationshipTypes. It contains some valuable information about the logic of the system, but is unfortunately a bit messy. Current improvement of AR types is happening on Advanced Relationship Type Proposal. --DonRedman

---

List of Relationship types for AdvancedRelationships

Following recent discussion about implementing AdvancedRelationships, here is an initial listing of proposed relationship types.

Note: Please take some time to read and understand the AdvancedRelationships proposal and the SimpleAdvancedRelationshipsInterface that will be implemented before proposing new relationships. --DonRedman

Relationship types are to be given in a full sentence in both directions. (Though I did not finish this for all).

While I agree with Tarragon, that we should eventually split Artist into Performer and Person, I disregard this now because the main goal is to get AR implemented quickly. --DonRedman

Link designers: Please keep in mind that all links now have a begin and an end date. We need to incorporate that into this document. I've started to do that in a few places. -- RobertKaye

---

I removed URL - URL from the AR link features since its pointless, so I removed it from the table above as well -- RobertKaye

---

Release - Release relationship types

• translation
  • Release1 is translation of Release2
  • what is this named the other way round?: Release2 is the original language version of Release1?

• Note: If it is not clear what the "original" language is, e.g. if the same release is released in multiple countries/multiple languages, then do not make "translation" relationships.

• set (pointing to the first release)
  • Release1 is the first release of a set with Release2
  • Release2 is in a set with (first release) Release1

• Note: In order to avoid knots in the relationships link all releases of the box to the first release of the box.

• set (alternative pointing to an empty release)
  • EmptyRelease is a box containing Release
  • Release is contained in the box\es EmptyRelease

• If we allow releases without tracks (representing the box), we can link all releases to this one. This would get us pretty close to Tarragons ReleaseGroups proposal. --Don

Release - Artist relationship types

Most of these relationship types should be valid for Track - Artist as well

• performer
  • Release is performed by Artist
  • Artist performs on Release

• this should have sub types by instrument:

• • performer (guitar)

• having "instrument" relationships seems like a bad idea, since people will start wanting performer (toy piano) etc. etc. @alex I'd like to capture instruments fairly precisely if we can. See my suggestions below. -- RobertKaye I thought that there is a pretty static set of common instruments and would use that. "toy piano" would fall under the category other. for classical music and Jazz this is actually the most important aspect of AR: bassoon, brass, cello, choir, clarinet, clavichord, computer, doublebass, english horn, flute, guitar, guitar (electric), harp, harpsichord, horn, keyboard, mandoline, marimba, oboe, organ, percussion, piano, piano (electric), piccolo flute, sampler, saxophone, saxophone (alt), saxophone (barritone), saxophone (soprano), saxophone (tenor), sequencer , soprano (voice), speaker, recitor, strings, synthesizer, timpano(i), trombone , trumpet, vibraphone, viola, violin, voice, voice (alto), voice (baritone), voice (bass), voice (countertenor), voice (mezzo-soprano), voice (soprano), voice (tenor), xylophone, other

• • performer (orchestra)
    • (on) Release has the performing orchestra\s Artist
    • Artist is the the performing orchestra on Release

• composer
  • Release is composed by Artist
  • Artist composed Release

• conductor
  • Release is conducted by Artist
  • Artist conducts Release

• arranger
  • Release is arranged by Artist
  • Artist arranged Release
  • Artist produced Release

• version (see discussion below)
• remaster (see discussion below)

Artist - Artist relationship types

• member of band
  • Artist1 is|was a member of the band\s Artist2 from <date> to present|<date>
  • Artist2 is a band consisting of the member\s Artist1

• is person
  • Artist1 is a performance name of the person\s Artist2
  • Artist2 is a real person behind the performance name\s Artist1

There is a lot to do here. Actually AR will change the StyleGuidelines. With AR it seems to be much more convenient to encourage something like "John Scofield & Mike Stern" (for a single CD) if we can then say:

• cooperation
  • John Scofield is a member of the cooperation\s / project\s John Scofield & Mike Stern
  • John Scofield & Mike Stern is a cooperation / project consisting of the member\s John Scofield, Mike Stern

For cooperation do we want to attempt to indicate the level of cooperation? (e.g. back-up singing vs composing the song and lyrics are two different levels of cooperation.) -- RobertKaye

• similarity

• I suppose we can afford to have real clusters here, so this relationship would not be directional. Robert: is this a problem?
  • That should be fine -- RobertKaye
  • Artist1 is similar in style to Artist2

I would attempt to stick to objective measures (same record label, shared personnel, duets, covers of same songs, on same compilations etc.) rather than rely on a vague and totally subjective 'similarity', particularly if it is totally binary on-off rather than a rating with degrees of similarity.

• non-musical relationships
  • Artist1 married Artist2
  • Artist1 is the sibling of Artist2 (the male/female could be part of the person, not the relationship)
  • Artist1 is the parent of Artist2
  • Artist1 is the grandparent of Artist2
  • Artist1 dates Artist2

Release - Track relationship types

• Track was originally released on Release (could be figured out by 'same track' + 'release date')
• Release is a single release based on Track

Artist - Track relationship types

Most of the Release - Artist relationships apply here as well.

Covers should not be done as Artist - track relationships. A song is a cover of another song but a song is composed by an artist.

• composer
  • Artist composed Track
  • Track is composed by Artist

• remixes
  • Artist remixed Track
  • Track is remixed by Artist

• performer (in the same fashion as ReleaseArtist)
• conductor
• arranger
• version
• remaster

There seems to be a whole sub tree with ReleaseArtist in common here. That should be exploited or it will be a pain in the ass to take advantage of. -- RobertKaye

Track - Track relationship types

In descending order of similarity:

• identical (e.g. same track on release & compilation)

• We cannot do a simple "is identical to" relatinship because AR need a clustering element. Otherwise the backend would have to search the table multiple times to get the whole cluster. I propose the first track released as clustering element:

• • Track1 is the first-time release of the following identical track\s Track2
  • Track2 is identical to and was first released as Track1

• other version (see discussion below)
• covers (see discussion below)
  • Track2 is a cover of the original version Track1
  • Track1 is the original of cover version\s Track2

Can we display the artist names along with the track names?

Because something like "More Than This is a cover of More Than This" isn't very informative. "More Than This (by Bill Murray) is a cover of More Than This (by Roxy Music)" would be nicer. Or is this something for the FancyAdvancedRelationshipsInterface? --ZeroGravitas

Release - URL relationship types

• Download for free
• Purchase to Download
• Purchase for Mail Order
• Purchase for (?) Retail
• Informational web page
  • Is the soundtrack to this Film (link to InternetMovieDatabase)

These are all adequately handled by the existing ReleaseAnnotations; I don't think we should add relationships for these until we see what kind of URL annotations are common. @alex

Artist - URL relationship types

• fanpage
  • Artist has fanpage\s at URL
  • URL is a fanpage of Artist

• official homepage
  • Artist has official homepage\s at URL
  • URL is the official homepage of Artist

• informational resource (like WikiPedia) These are all adequately handled by the existing ArtistAnnotations; I don't think we should add relationships for these until we see what kind of URL annotations are common. @alex

Track - URL relationship types

Same as Release - URL

---

Discussion

AR will incur a very drastic change to the database schema. Even if we try to keep the impact minimal (and I try very hard) there will have to be one of these changes:

1. Artists with no attributed release and tracks will not be deleted if they have a relationship. or
2. There will be additional elements like Person and perhaps Performer (unless this is done with the Artist field), and (less important) Country, Language etc. These need a table for themselves but do not necessarily be part of the current schema (which links Artists, Releases and Tracks). However add and delete edits would have to be written and integrated into the system.

I know that Tarragon favors the second way and I favor the first for the short term future. I think this decision is up to Robert. --DonRedman

• change 1 sounds much simpler. I don't really see the need for a distinction between Performer and Person. Certainly we should get AR working first, and see if change 2 is still wanted then. --ZeroGravitas I made a comment in the section Multi-relationships below on the subject of DataElementsForAdvancedRelationships that could be added to the database to take advantage of AdvancedRelationships. Maybe take this discussion to a new page? --andybak

---

Cover Versions

After further thought... How about instead of Cover Version, we have an AR Track-Track link that says "These are recordings of the Same Song".

Assuming the release date is set on the earlier track, who covered who is calculated automatically. This approach avoids data redundancy. All we need is a report to suggest linking of songs with the same titles. This also maps to re-recordings of a song by the original artist.

Note that The Covers Project defines the original artist as the first person to release a song:

• "apparently Danzig wrote a song ("Thirteen") which Johnny Cash released in 1994. In 1999, Danzig also recorded the song, so technically (for the purpose of The CoversProject) they covered a Johnny Cash song that happened to have been written by him."

Sooner or later we're going to hit this sort of case, so seems like a good idea to think about it now... --ZeroGravitas

---

Multi-relationships

There seems to be a general issue here for the Release - Release and Track - Track relationships, like "in box set with", "same song" and "translation" where the relationship is implicitly commutative (i.e. A <REL> B implies B <REL> A) and transitive (i.e. A <REL> B, and B <REL> C, implies A <REL> C) where the current one-to-one nature of AdvancedRelationships isn't quite what we want, and we would rather have a "collection" of some sort where all the entities are related to all the other ones. This can be implemented by introducing a new entity type (Collection) and using one-to-one relationships between the collection entities and the individual releases or tracks, but I'm not sure that's the best way to handle it. The current hacks of selecting a "first release" (for sets) or "original version" (for translations or covers) are, well, kind of hacky. @alex

• I can see many benefits to be gained by adding a relatively few number of new entities to the database. For instance: 'grouping' entities for releases such as boxed sets. Grouping entities for tracks would allow us to indicate movements within a larger work for classical music. Maybe I should sketch outsome thoughts on the issue of ClassicalAdvancedRelationships --andybak

---

Covers and such

As alex pointed out, you cannot do wild clustering for covers. Therefore you must have a single element to which all other elements relate to. I propose to do this by time. The root relationship would then be

• first version
  • [1] is the first-time release of [2]
  • [2] was first released as [1]

then we can destinguish the sets; i.e. from what set is this the first-time release? sets I can think of:

• Track - Track
  • cover - The same composition
  • version - The same song by the same artist
  • identical - The same recording

• Release - Release
  • version - Mostly the same audio material (and ReleaseTitle and same ArtistName) but different track-listings
  • remaster - Same ReleaseTitle and same ArtistName but different (e.g. remastered) audio material.

What do you think of this? --DonRedman

• The problem is that if I think version A is the first version, but I am wrong, the person who needs to fix that can't just change one relationship to indicate which one is first, they have to change all the relationships to point to the true first version. I would prefer an arbitrary selection, or better, a new entity type (like Collection). @alex Well you could make a batch operation for this. I will discuss this with Robert... --DonRedman

Instruments

I think that for indicating instruments we will want to have a deeper link tree. I would suggest doing something like:

• performer
  • instrument
    • string
      • guitar
        • electric guitar
        • base guitar
        • acoustic guitar
        • double guitar

• • • wind
      • trombone
      • tuba
      • french horn
      • trumpet
      • Saxophone
        • Alto saxophone
        • Tenor saxophone
        • Stinking normal saxophone

• • • piano
      • grand piano
      • upright piano
      • other pianos
        • toy piano

• • vocal
    • lead vocals
    • backup vocals
    • bathtub vocals

We should see if we can find an instrument breakdown that we can use somewhere. For now, lets not worry about how to represent this in the UI -- lets come up with the right datastructure and then we'll figure out how to make it palatable for our users. -- RobertKaye

but then you have to think about what can be done when we run into instances where someone is both BackingGuitar and LeadVocals ~mo (xd, 'bathtub')