On Tue, 07 Mar 2006 14:08:19 +0100, wrote:
this into a factual 1:1 relationship (via SoftStructure) and have an Album for every Release in the DB. Without a real grouping object this is totally insane.NO, that's not the point. And accusing me of proposing insane changes is not very nice.
On the Summit Robert made very clear that AR cannot and will not replaceNO, and NO! I have never suggested to replace the primary relationships with ARs, where does this even come from?.
Where do you fear we would risk havingrelationship clusters, I cannot follow you. It looks to me like some tactic for keeping the status quo, even if it does not satisfy theneed for a resolution.
Sorry, I did not want to accuse you of being insane at all. I think we are simply misunderstanding each other.
We are discussing the boundary, when two albums are considered different enough to represent two album entities in the database, right?
It was my impression that you (among others) wanted to push the boundary so far, that completely identical album entities would exist. I do not want that to happen.
You wrote:
Yes, for all the examples you have listed, and even more: Enter everyrelease as a different entry in the database, where we have enough backing data to support that. These resources might include:- Proof of releases as part of BoxSets, as well as standalone, e.g. all the examples you have provided - There is a different coverart available on AZ - Were released in different packaging - " in different Countries, on different dates (ie. not days, but months or years apart) (Is this a rerelease already?)
The NIN debate was about the first point only. I am still undecided what to think here. I strongly disagree with all the other points, especially with the last one. Let's start with this one:
I read the above that you want to enter releases as different album entities into the database that were released in different countries on different dates (years apart).
Do you mean that, or was I misunderstanding you?If you mean that, the this is the part, I referred to as being "nonsense". Please let me rephrase this. The current schema is built to represent this situation. an album entity can have 0-n release entities, and each release entity has a date and a region. Therfore the database structure that should represent the same album being released in different countries on different dates (ceteris paribus), should be represented as one album entity with several release entities.
Do you disagree? If so why?My impression was that you did disagree, that you really wanted one album entity for each release. I have attached a graph to this mail.
On the left you see one album with three releases. This is the way we currently have it.
If a re-release a few years later should now represent a new album entity, this will give one of the cases to the right. In the middle there is a new grouping core relationship entity. This is the planned AlbumObject in NadelnderBambus (in which the current album entity is called ReleaseObject and the current release entity is called ReleaseEventObject).
But we do not have such a grouping entity right now. Therfore your proposal would lead us to the case to the right, in which only an AR cluster (or ARs to the first entity) relates the different releases together.
IMO this means factually replacing a core relationship by advanced relationships. I am very strongly opposed to this.
Now, I might have misunderstood you someway through this argument. If so please tell me why. I'll wait for your reply before I continue. Let's get a common base first.
DonRedman -- Words that are written in CamelCase refer to WikiPages:Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-)
NIN-Debate-Graph.png
Description: PNG image
_______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
