Uploaded image for project: 'MusicBrainz Server'
  1. MusicBrainz Server
  2. MBS-7469

edit_$entity tables and derived interface lack details of type of relation




      At present, the edit_$entity (edit_release, edit_artist, etc.) tables are very simple – they have an edit and an entity, and occasionally an edit status or such materialized from the edit table. This stores the information: this edit is related to this entity. But this says nothing about what manner of relation exists between the two. Categories of relation I can think of include:

      • direct edits, e.g. changing an entity's name or type, adding external identifiers (ISRC, ISWC, etc.), aliases, annotations, etc
      • edits linking together an entity with another, e.g. any relationship edit, release labels (in at least edit_label, possibly also edit_release though they might be considered direct there), artist/label areas (in edit_area – they'd be direct in edit_artist), etc
      • edits to entities considered subordinate, e.g. release edits in label histories (other than release_label edits), recording edits in work histories (other than linking to that work), edits to cities in the parent subdivision's history.

      These categories may actually be several, or may be combinable, since direct edits to subordinates and edits linking entities to subordinates might be separate categories, as may several depths of subordination, e.g. for a subdivision: changing a city's name (direct edit to subordinate), linking an artist to a city (link edit to subordinate), changing an artist's name for an artist linked to the city (direct edit to a subordinate, but arguably one further removed than the subdivision-city subordination).

      The hierarchies that I see include (noting that some also apply even excluding some of the links):

      • area -> area/work -> work part-of
      • artist (e.g. writer, performer or recording AC (skipping work)) -> work -> recording -> track (i.e., release edits concerning this track)
      • artist -> release group -> release
      • label -> release
      • area -> release, artist, label (weaker link, but still arguable)

      It's also possible that some applications of this data would care about which hierarchy was relevant, e.g. if a tracklist-changing edit is included because the artist is the composer of a work whose recording is linked to the track vs. the artist appearing in the release AC. This may or may not be easily expressible in terms of classifying hierarchies in terms of how far removed they are as I mention above.

      Due to the complexities of the categorization I'm not totally sure of the best way to encode this. However, there's lots of useful applications of the data:

      • On entity edit listings or subscriptions, showing detail of why this edit is shown here (e.g. "This edit is shown because you are subscribed to Estonia, which has a part Tartumaa, which has a part Tartu, which is set as the birth area for Heino Jürisalu, who is a composer for the work Flöödikontsert, which has a part Flöödikontsert: II. Commodo, which is a work for the recording Concerto for flute and orchestra: II. Commodo, which appears as track 1.9 of the release being edited", to provide a really pathological/insane example )
      • More control over what exactly is displayed on any page with an entity context of this sort (e.g. an entity edit history), via links such as "show only edits to this entity directly", which can also help a lot with filtering down to relevant edits
      • Similarly, control over the exactitude of subscriptions, e.g. subscriptions only to direct edits to an entity vs. subscriptions only to linked/subordinate entities (such as "show me all edits having to do with artists set to this area or one of its subordinate areas")




            • Assignee:
              ianmcorvidae Ian McEwen
            • Votes:
              1 Vote for this issue
              0 Start watching this issue


              • Created:


                Version Package