History:Display Inheritance Proposal

This proposal which tries to solve redundancy problems is based on an idea (don't remember who it was) had in the discussion around redundancy of Björk's birth date (see also DateOfBirthStyle).

The problem is: we have multiple entities which share equal data - or should share it, at the moment we can only store it multiple times. This produces unwanted DataRedundancy.

Examples

• Björk is a performance name for the person Björk Guðmundsdóttir (actually it isn't but that's another discussion). A user browsing Björk's artist page wants to see her birth date. If it's not present he will probably try to add it. But the date is present on the artist page of Björk Guðmundsdóttir so here we have redundancy.
• Jeanette is a performance name for the person Jeanette Biedermann. Though the german Wikipedia article is under http://de.wikipedia.org/wiki/Jeanette_Biedermann so I stored it under her LegalName. But it would be nice if it is also visible under the performance name. But if it would be called http://de.wikipedia.org/wiki/Jeanette and she had another performance name I didn't want it to appear under the other performance name.
• Album reviews are normally about albums in general and not about certain releases or editions, so I want a review link to be visible to all albums but don't want to store it under all of them. But sometimes articles are only about a certain release/edition so I really want the review link only to be about this edition and not about others.
• An album consisting of two discs is stored as two separate AlbumEntities in the db. But I don't want to store the release date twice. And I don't want to link to the Discogs entry twice (they have only one page for albums consisting of several discs).

How can this be solved? Using the PowerOfAR!

Idea

Let's look at it more abstract.. We have some entities which are linked in different ways through AR. Each entity has data fields in the db and AR links to additional information. You can identify one entity as the MainEntity (for artists: the LegalName or BirthName, for albums: the earliest release) and the others as SubEntities. Store all information which is also valid for SubEntities under the MainEntity (this does not have to be the root of the whole tree but can also be the root of a sub set). When building the page for a SubEntity try to lookup data from the linked MainEntity under certain rules (for example depending on the relationship type) and with a certain search depth (also lookup data from the parent of the parent node?) and display it on the page as if it belonged to the SubEntity (the SubEntity inherits data of its MainEntity only in the display - therefore DisplayInheritance).

This sounds rather technical. An example? Of course:

Jeanette Biedermann is the MainEntity, Jeanette is its SubEntity. When building the page for Jeanette the birth date of Jeanette Biedermann and her links are looked up and displayed as if they were stored under Jeanette. The same would apply for other PerformanceNames if she had any. But if you store a link under Jeanette it will only be shown under this entity. Only if it had further children they would inherit this data.

If you have an earliest release of an album and then linked a remaster or re-release and a special edition (link type for this is yet to be invented) then you can use the link type as a rule for deciding if a SubEntity should inherit data. For example the earliest release has a review page. Then you decide: all linked re-releases and remasters inherit this review page. Linked special editions do not.

So this will require a well-thought-out model for what will be inherited and what not. And it will require some more link types which link SubEntites to MainEntities.

Discussion

So basically what you are proposing is that AdvancedRelatinshipTypes get a direction of inheritance. There would be a set of directional inheritance rules attached to each AR type. I like this idea, but do sou realize the dependencies that this will build up? These inheritance rules and the database fields will be so tightly linked that changing something in the datapase schema will probably become quite a nightmare. --DonRedman

• These dependencies already exist in the upcomming ArtistPageRedesign which makes use of the different types of ARs to build views depending on this. Also AlbumGroups using ARs to link to albums would depend on the used type. And I think this is exactly what AR is for: to make use of the different types to represent the data in different ways. This is what I then call the PowerOfAR. ;) --Shepard

---

| Original author: Shepard