Difference between revisions of "History:Advanced Entity (Post-NGS) Proposal"
|Line 35:||Line 35:|
== Recording Object ==
== Recording Object ==
[[Object Model/Recording Object]].
Revision as of 08:58, 16 March 2010
This page holds Advanced Entity suggestions which have not already been implemented (or will be, in the NGS release), in some form or another. The initial text on this page all migrated from Advanced Entity.
The following entities with the described behaviour are proposed:
AR to Series
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:
See Location Proposal for something similar to this.
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.
(Note, this came out of the same original proposal which suggested 'Album Groups', now "Release Groups".
for different albums belonging to one set