On 3/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >DonRedman wrote: >>On Tue, 07 Mar 2006 01:38:57 +0100, Jan van Thiel wrote: >>> On 3/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >>> > Enter every >>> > release as a different entry in the database >> > >> > I fully agree with Stefan here. > > > > And I very strongly disagree. The current db schema has the > > Album to store > > the tracklisting and the release to store different releases > > of that same > > audio material. > > It's not about the audio material! [...] > The fact that an > album and the same album released in a boxset have identical audio material, > is circumstantial (If there were track added in the version in the boxset, > it would be listed as a different album in MB too). People want to see this > a 2 different albums, and want to be able to tag against them without having > to correct the tags again afterwards.
There is no _real_ problem with this approach. Don's and me only reacted to the a bit to short cut quoting of your original mail, which I think, you wouldn't agree with as well. Allowing 2 entries for similar albums with different data, that could only be stored in the album annotation, is not the problem; we just need to build some small rule on this and allow people who edit such things to predict the outcome of a voting on their mods. On the other hand, allowing a new entry for every new release of an album in a general way is a problem ATM. > > On the Summit Robert made very clear that AR cannot and will > > not replace > NO, and NO! I have never suggested to replace the primary relationships with > ARs, where does this even come from?. We talked on the summit about this, > that at first, we'd duplicate every part of the Structure in > NadelnderBambus. Later on, we would start developing tools to merge together > objects that are above the level of the tracklisting, to establish the fact > that this is the same element. And to provide a means to attach ARs to > elements, and thus apply to all the elements attached to it. Yep. > > the hard-coded primary relationships in the DB. > > Besides that AR does not offer a grouping object. You would > > trade the > > current situation for an unmaintainable DontMakeRelationshipClusters > I'd propose that performance ARs should be added to the first release, and > that editors abstain from adding un-necessary duplication for other versions > of the same tracklisting. Where do you fear we would risk having > relationship clusters, I cannot follow you. Clustering is not the main problem here, but the parallelization of 1 to n relationships, which store exactly the same information might be. #Fuchs _______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
