On Fri, Oct 10, 2008 at 11:37 PM, Kerensky97 <[EMAIL PROTECTED]> wrote: > Big huge reminder here. Like I said this is not a typical AR. It will NOT > sit alongside existing 'Earliest release of' and 'Remaster of' ARs or any > other ARs for that matter. Nor will it replace them. > [...] > Furthermore, Robert has said that EXISTING ARs CANNOT BE ADAPTED FOR THIS > PURPOSE.
Why market them as ARs then? Can't we just have a concept separate from release for this? "Album" is the first term that comes to mind (it's "musical-centric" rather than "release-centric"), though it seems a bit to restrictive. (If I understand correctly, we might have CIs that group releases based on the same "single" song but widely different in terms of B-sides. Similar for concerts.) I see no reason why we wouldn't have a separate object only for that. It could be done with only a few attributes—MBID, name & annotation are the only three that seem to me absolutely necessary. Then we could have a separate set of ARs between "it" and releases; something like "R is a release of A". This avoids any instinctive mental mix between the other ARs and CIs, and rids us of clustering problems too. It could even be something specific: a 'release' of an 'album' would more like a release date than an AR. Everything else (type, as in album or single; date of first release; "typical" tracklist) would be generated automatically depending on what releases are listed for a CI. (A bit like how label pages use info from releases' release dates, only smarter.) And if everything works nicely we might even have a "smart" artist page view which groups releases automatically under "foldable" CIs. > Please move beyond the discussion of whether other ARs can be used for this > or if it's a duplicate of existing ARs; it is irrelevant and doesn't apply > because the top dog said... EXISTING ARs CANNOT BE ADAPTED FOR THIS PURPOSE But if CIs will look even superficially like I what mentioned above (even if based on ARs), I see no reason why we couldn't use those existing ARs to pre-populate the database with CI. Together with the CIs going live on the server we should also run a script that automatically creates CIs (or whatever we'll call them) for existing releases, with a few heuristics: 0. only create CIs for official releases, with the same name as each release's; 1. if two releases are linked by "later release of" or "remaster of" (probably transliterations, too), they get the same CIs; 2. if a presumptive CI's name ends with "([bonus] disc #*[:.+])" then remove that part; 3. if several releases would give the same CI name, they're checked for similarity on track names. If they're not sufficiently alike, don't create a CI for them. (This only if there's no AR to guide us in step 1.) 4. I'm sure others can imagine other such heuristics. Since we'll have a beta-test period, we'd be able to run this script several times on the test copy of the database and get it to a reasonable level of conservativeness; and when we get the feature, we'll already have the database populated with much of the info. We already have a lot of machine-readable info for releases, I see no reason why we shouldn't make use of it. The editors will then be able to focus on the interesting cases. (BTW, we could have a specific "machine-generated" quality level for things like this, in case people want to filter-out things that haven't been verified. It would go automatically to "normal" the first time someone makes an edit on the CI; one could also explicitly change it to "normal".) Am I making any sense? -- Bogdan Butnaru — [EMAIL PROTECTED] "I think I am a fallen star, I should wish on myself." – O. _______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
