Search:

New Entities Proposal

Status: This page is a collective proposal for new entities that have not yet been implemented, their behaviour and how to present them.

See DataElementsForAdvancedRelationships for an older proposal.

Idea

At the moment we have the following CoreEntities:

• Artist

  • related concepts: Group, Band, Orchestra, Person, LegalName, PerformanceName, RoleName, FictionalPerson/Character

• Album

• Track

We already have the following AdvancedEntity:

• URL

The following entities with the described behaviour are proposed:

• Label

  For record labels, subdivisions of labels and distributors

  • field: LabelCode

  • AR to URL possible (label website (use "official website"?), Discogs entry, Wikipedia, discography site)

  • AR to Artist ("is/was signed to from ... to ...")

  • AR to Series

  • AR to Label ("is sub-division of", "is distributor of"?)

  • album listing with all albums which have the id of this label in a release

  • "View Mods" for related edits

• Series

  For compilation series

  • examples: Café del Mar, Ministry of Sound, Kontor, Hed Kandi, ...

  • AR to URL possible (series website (use "official website"?), Wikipedia, discography site)

  • lists all albums belonging to this series. Linkage through AR or through album attribute?

  • Some attribute for the volume number an album has in a series, which makes sorting easier for inconsistent numbering styles

  • AR to other series: "is subseries of" - for example Ministry of Sound consists of several sub series that have their own numbering

  • "View Mods" for related edits

• Studio

  For recording studios

  • AR to Album/Track ("has [instrument] recordings from ... to ... in")

  Alternatively an entity Location could be used for both recording studios and concert venues.

• MetaEntities

  We currently have problems linking entities of type Artist, Album or Track together. The reason is: all of them represent a concrete object. A track is a concrete performance, recording and release of the abstract idea of a song. If you want to link a track being a cover of another one you don't want to link it to another track by the original performer but to the song of that performer. In the same way an album as in the database is an actual release and not the abstract idea of an album (the music industry uses the same word for both). But often you don't want to link information to one release of an album but to all of them as a group.

  We have some pages describing these problems. FundamentalMismatchOfMusicBrainzEntitiesAndReality describes the difference between the abstract objects and what we have in the database. LinkingDifferentArtistNames and DontMakeRelationshipClusters list linking problems and try to give some solutions like linking to the earliest objects and such. Though meta entities / groups could solve problems magically I think. Compare the graphics in DontMakeRelationshipClusters to the following to see what I mean:

  

  • ArtistGroups

    Imagine a group representing a real live person. The group then contains Artist entities representing all names the person performs under - also if the person performs under his LegalName you have an entity for that in the group - or if the person performs under a short version of his LegalName ("Paul Peter Dingbat" -> "Paul Dingbat"). Still a problem: what do about legal name changes? Add them as entities to the group?

    A great advantage would be that the entities could easily inherit information like birth date, Wikipedia links, ... from their group.

    One could also use these groups for bands (some bands use aliases for some works or think about line-up changes and band name changes). But here you could get overlapping problems.

  • AlbumGroups

    These would be called differently depending the proposal, so I just list the proposals here:

    • ReleaseGroups -- This was written before AdvancedRelationships and therefore is conceived as a new CoreEntity, but should not be one, would we implement this now.

    • ReleaseHandlingPhilosophy -- This proposal could be implemented without an additional entity, but an explicit album group would not really hurt.

    Additionally one could think of different types of AlbumGroups like:

    • ReleaseGroup/EditionGroup for different variants of one idea of an album

    • BoxSet for different albums belonging to one set

    One AlbumEntity could be member of several groups - like Apocalyptica's "Cult: Special Edition (disc 1)" is in the same EditionGroup like the original "Cult" release but also in a BoxSet together with "Cult: Special Edition (disc 2)" (but that could lead to multi-inheritance problems if you also want to use an inheritance mechanism like for ArtistGroups). And you have to differentiate between a group of albums representing the same abstract album idea and groups of albums representing the same recording (important for linking recording information to the group).

  • TrackGroups

    Track groups would be the equivalent to the abstract idea of a Song while the Track entity stores data for one version/release of a track (which perhaps still could be used for several albums - so one Track entity could be on an album and a compilation).

    • Easier to link covers, participating artist infos and so on

    Like for albums you have to separate between groups of tracks representing the same abstract song (of one artist!) and groups of tracks representing the same recording of a song.

  For new more detailed proposals for such groups see AlbumRework and TrackGrouping.

Description

(More detailed description missing...)

Label entities could then be used in extended release infos of albums. Both labels and series help to keep an overview of the related releases and the related mods.

Open question: link albums belonging to a series to the Series entity instead of VariousArtists? Or better leave VA as the artist because a Series entity is not an Artist entity and this could cause implementation problems? So better link it *additionally* to the Series?

Discussion

Me love! Especially I love the series proposal if it would mean that we would dump the volume number style guideline (which is used for keeping releases in a series together even if their names don't really imply it). //bnw

I'm not too sure of the new name of this page. Is this really about Advanced Entities? As I understood it it was just a suggestion for a few new 'normal' entrities. //bnw

• The major difference seems to be that a CoreEntity is part of the CoreSchema, while an AdvancedEntity will be related to other entities by AdvancedRelationships only. Therefore advanced entities can be used in multiple contexts. Their function is not hard-coded in the schema. this is a case of DisentangleInterfacesFromSchema. --DonRedman

  • I'm still not sure if I understand what AdvancedEntity is. From technical point of view it's just a bunch of new tables in database (one for storing main info, others for AdvancedRelationships; e.g.: label, lt_album_label, l_album_label), isn't it? Or did I completely misunderstood it? --LukasLalinsky

Re: Entities, related concepts: what's the difference between "Group" and "Band?" Also, I think it'd be nice to have Collaboration, too. I'd also like to see a UPC and ISBN AR link for releases. ojnkpjg

• A "Group" is a more general term. A band is a group as is an orchestra, but an orchestra is not a band. Though these related concepts list was not meant to be exclusive, I just wanted to list some terms that are used yet and are related to the Artist entity and perhaps could lead to some discussion about more subtypes of this entity. I don't think we need an entity for UPC or ISBNs. In ReleaseDataSet I wrote another proposal that covers this. --Shepard

A few ideas/questions about labels: I think we could have an additional AR to Artist: "Label created by Artist". Also, labels history may be quite complicated, and simple start/end dates are essentially inadequate (labels may have an independent period, then went dormant, then re-emerge as an owned subsidiary...). Also, it's an important information for defunct labels to know who bought (and now owns) their catalog (maybe an AR to label is usable for that?) - though this case may also be complicated (catalog leasing, rights for only a specific region of the world). Not only catalogs, but of course labels may be sold and change hands a few times - I guess we need dates for that (X bought Y in Date), and it may be really hairy in some cases (labels splits, fusion, name change...). I can also think about more AR to artists to describe who does what (Producer, Musical Director, Main Engineer, etc...) though this information may be implicit (as they exist "in" the releases). As a field of experiment, I used a sort of "template" for the jazz labels project (check the Mode Records page) - while I'm sure it may be enhanced/rehauled, it's an attempt at determining what we need for labels. -- dmppanda 2006-09-03 15:35:10

Shepard, this one too - hasn't it been superceeded by NGS, so perhaps no longer a member of CategoryProposal? DeleteWhenCooked -- BrianSchweitzer 2007-08-20 20:36:11

• It contains some stuff in an older form of thinking about the problems, some stuff which isn't covered by NGS completely and some stuff which is already CompletedWork - but as a page with a bit of historical value and to explain why things led to the formulation of NGS in exactly that way (that is to follow the "train of thought") I think this can stay as it is. You may add something saying this is an older proposal if you feel like it but well, it still is a separate facette of the problems to be solved by NGS. Just as we have AdvancedRelationships, we wanted to have "richer" objects. And this page collected them. -- Shepard 2007-08-20 21:48:14

  • Oh, totally understood - I was just referring to the CategoryProposal indicator below - been working with warp on his project to find/track all the (forgotten in many cases) open proposals out there, and figure out which ones are still "live", rather than as you describe. DeleteWhenCooked -- BrianSchweitzer 2007-08-20 23:57:41

---

CategoryDiscussion CategoryDevelopment CategoryProposal | Original author: Shepard