History:Advanced Relationship Type Development

From MusicBrainz Wiki
Revision as of 10:03, 22 November 2005 by Zout (talk | contribs) ((Imported from MoinMoin))
Jump to navigationJump to search

Historical Information

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 AdvancedRelationshipTypeProposal. --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 splitArtist intoPerformer andPerson, 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


Album - Album relationship types

  • translation
    • Album1 is translation ofAlbum2
    • what is this named the other way round?:Album2 is the original language version ofAlbum1?
  • Note: If it is not clear what the "original" language is, e.g. if the same album is released in multiple countries/multiple languages, then do not make "translation" relationships.
  • set (pointing to the first album)
  • Note: In order to avoid knots in the relatinships link all albums of the box to the first album of the box.
  • If we allow albums without tracks (representing the box), we can link all albums to this one. This would get us pretty close to Tarragons ReleaseGroups proposal. --Don

Album - Artist relationship types

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

  • 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 categoryother. 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)
  • version (see discussion below)
  • remaster (see discussion below)

Artist - Artist relationship types

  • member of band

There is a lot to do here. Actually AR will change the StyleGuideliness. 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
    • [[[Artist:John|John]] Scofield] is a member of the cooperation\s / project\s [[[Artist:John|John]] Scofield & Mike Stern]
    • [[[Artist:John|John]] Scofield & Mike Stern] is a cooperation / project consisting of the member\s [[[Artist:John|John]] Scofield], [[[Artist:Mike|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?

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.

Album - Track relationship types

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

Artist - Track relationship types

Most of the Album - 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.

  • performer (in the same fashion as album-artist)
  • conductor
  • arranger
  • version
  • remaster

There seems to be a whole sub tree with album-artist 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 (eg same track on album & 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\sTrack2
    • Track2 is identical to and was first released asTrack1
  • other version (see discussion below)
  • covers (see discussion below)

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

Album - URL relationship types

  • Download for free
  • Purchase to Download
  • Purchase for Mail Order
  • Purchase for (?) Retail
  • Informational web page

These are all adequately handled by the existing AlbumAnnotations; 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

  • official homepage
  • 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 Album - 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 that have no album and not track will not be deleted if they have a relationship. or
  2. There will be additional elements likePerson and perhapsPerformer (unless this is done with theArtist 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, Albums 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


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 Album - Album 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 albums or tracks, but I'm not sure that's the best way to handle it. The current hacks of selecting a "first album" (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 NewEntities to the database. For instance: 'grouping' entities for albums/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

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

Retrieved from "https://wiki.musicbrainz.org/index.php?title=History:Advanced_Relationship_Type_Development&oldid=13894"