[scott967]

So I wanted to better understand what MB is doing with classical, since it seems like MB is something like authoritative as a structure as far as Kodi music db is concerned. My goal is to both understand the proper style of the tag data, as well as the entity relationships.

What I see is in MB, a "track" is an instance of a "recording" (many to one). A "recording" is an instance of a "work" (many to one). Other relationships are created at the highest logical level. For example, a "composer" relationship exists between an "artist" and a "work". A "performer or conductor" relationship exists between an "artist" and a "recording".

In Kodi we don't have a notion of "recording" or "work", so there is a problem of mapping our relationships.

We could probably live without the "recording" concept, as I don't how often users would have multiple examples of a single recording ("best of London Symphony Orchestra"? Probably not).

But the lack of a "work" entity does make it difficult, since users probably are in fact interested in specific works. If we use the MB style guidelines, the work title is embedded within the track title, but that makes it a bit cumbersome to search on, plus often we are interested in metadata about the work (such as its history or composition) and that would have to be repeated for every track in Kodi db representing a work (or part-of).

I don't do Picard but I see "work" is supported in tags. I don't see exactly how Picard handles relationships though.

scott s.
.

[DaveBlake]

Also remember that the data Kodi uses in the future is not limited to what Picard (or any other tagger) puts into tags, anything MB holds can be fetched later by a scraper providing we have the fundamental mbids (which we do).

Kodi already has those relationships between artist and track that it can get from current tagging held as roles. In MB these are a mix of artist to work and artist to recording relationships, both denormalised up to song.

I don't think Kodi will ever get into recordings - even the MB datbase has many duplicates where those submitting have not managed to identify the recording was already entered for another release.

But "work" is a possibility. It has meaning for pop music too, if it is enetered, although a song is often identifiable by name alone, that is not always true. Since MB has a work ID, the work title does not have to be embedded in the title, or at least if we have a work table (self relating for parts of a work e.g. movemnets) then the song title could be a shortened version. However I have not given this any great thought yet.

One place where MB entries are mixed in style is classical guitar music (there are many equivalents I'm sure) where there is a famous guitarist playing music by various composers. The gutarist is album artist, but sometimes the composer is given as the artist and sometimes the guitarist. I guess this is because so many media players do not list composer that was a way to make it visible (the other being add composer to track title). Then some have composer as a (work) relationship, some have performer (on guitar) as a (recording) relationship, some both, and many have neither (although they could be edited of course).

I don't see exactly how Picard handles relationships though.

It varies, not all relationships are present. Some "Artist" to "recording" relationships are handled using the performer, conductor, arranger and producer tags, while Artist" to "work" as "composer" gets into composer tag. But that is just from inspection, I have not seen a complete map.

[Dan Gravell]

This is an interesting question and it comes down to the interplay between your tags and Kodi, and also how you choose to structure your tags.

I think the default in most people's libraries is to approach it from a release perspective - i.e. releases of albums, which have tracks on them which are recordings. These have more of a temporal nature to them. You can get multiple releases for an album, and multiple recordings for a work. I say "default"; what I mean by that is that it's the default many software tools impose.

It would be interesting to invert it and consider it from a work/opus point of view. One problem with that, from MB's perspective, is that the data is not so complete.

Of course, with MBIDs populated, Kodi could provide its own layer on top, without tags being involved.