I agree, and I'm glad you want to go all the way rather than some of the way, which i don't think helps. it's either one or the other for me.
i don't think there is a way of doing this without duplication - even if we could assign multiple 'releases' to one track list (as i seem to recall NextGenerationSchema was going to do, amongst other things?), you'd still have more or less duplicate albums for tracklist variants, artwork variants, etc, etc. there definitely needs to be some way of them inheriting AR (and other things? track names?), but i anticipate this being a track-track relationship, in the long run (for VA albums, compilations, etc), not album-album. i hope people can see where i was coming from with the 'still' thing - i saw it as a bit of a precedent really. On 06/03/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Chris, > > > what do we do? perhaps the fact that it was available seperately at > > any stage, implies that it's a seperate entity. i think this scenario > > might be a bit rare to include in the guidelines, though. > > Yes, for all the examples you have listed, and even more: Enter every > release 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?) > > This way, there might be AR's available to different official homepages, > discogs pages, AZIN links etc. If at one point people start adding > performance relationships like crazy, we'll need a way to attach them to > multiple entities (album/track), or batch copy them from one album to > another. The other idea floating around is to extract meta-objects from the > track entities to attach the ARs to, from which the actual tracklistings are > inherited from. All these concepts are laid down in the > http://wiki.musicbrainz.org/NextGenerationSchema and duplication of data > where needed is an essential part of it. If we want to shift the focus from > tagging (where only one tracklisting of a release is needed) to more > complete discographies, then we'll have to add duplicates for the different > releases of albums at some point. > > The need, it's quite obvious for me, is a already quite strong, the > discussion has proven that. The couple of sentences above regarding ARs are > IMHO an insufficent reason to not start duplicating data where it would make > the discographies more complete, and Björn (Fuchs) said himself that he > generally would support going for duplication, but not now since mbserver is > not being able to support it. I can only say that I don't care, if the > albums have sufficent information (annotation, discogs link, azin) then > we're already better off than most other opensource music databases (and we > have the tagging on top of that). We can live with some duplication until > we're able to fully support it. > > g0llum > > > > _______________________________________________ > Musicbrainz-style mailing list > Musicbrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style > _______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
