|
Sort Order:
It's basically http://wiki.musicbrainz.org/Proposal:Release_Type_Restructuring_Proposal I believe the plan is to leave all the types in the main types column until it's actually implemented in the interface. I'm not sure what happens then though. I've seen this just now (linked from the blog post), and I think this requires an RFC/RFV? Here's a proposed data migration scheme. It's very straightforward and obvious. Data Migration:
I would use other + spokenword and other + interview. I would find it really strange to call them albums. For compilation, soundtrack, live and remix, I wouldn't want to blindly turn them all into album. Remix, for example, gets used plenty for singles. I would turn all the ones with more than n tracks into album + compilation/soundtrack/live/remix and then the rest into unset + compilation/soundtrack/live/remix. We can then add a report for release groups which have other types set but no main type. I'd make it a bit more specific. Say: set to album if a) the duration is over 20 minutes AND b) it has more than 6 tracks AND c) the names of the tracks don't all contain the same word (to avoid very long remix singles) Given the current proposal, how are we going to easily identify albums (in the actual definition) on the artist page? I think the most straightforward thing to do right now would be to have sections for:
This ticket is under consideration for the May 15h schema change release. However, it is under specified at this point in time. In order to keep this ticket in consideration for the release, please do the following:
What should happen to "remix single" releases that are currently in a "single" release group? Should they be put into a different RG? Also, how about a "Sampler" attribute? Though, the issue with the proposed update is that "Sampler" can't comfortably fit in either "main" or "other" (e.g. due to conflicting cases "album sampler", "soundtrack sampler"). Perhaps it could be in a third group? @Jacob: ultimately, "Remix Single" should end up in with main type "Single" and additional attribute type "Remix". How it gets there is the question. Under my migration proposal, it would become "Remix album" (and need to be corrected); with nikki's it would be "Remix [none]" and still need to be corrected, but be easier to find. For samplers, I see no reason we couldn't add "Sampler" to the other attributes list (thus making "sampler + soundtrack + album" possible. But that should perhaps wait til we get the type migrated. For the UI I would suggest a <select> list for the main types, and a <select multiple> in place of the single <select> currently used for type. I'm a bit concerned about the content types, and whether it really makes sense to make them all selectable for a single RG; it makes for a lot of nonsensical combinations: Spokenword + Interview, Demo + Soundtrack, Audiobook + Remix, Live + Soundtrack, Live + Interview + Compilation + Remix. Personally I'm tempted to make Compilation an attribute, and the rest of the content types mutually exclusive. I'd imagine it makes UI work a whole lot easier as well if we only have to deal with discrete types instead of n! composite types. We might save ourselves some time if we just make the whole thing hierarchical, like the medium formats. For instance, Interview and Audiobook are both really subtypes of Spokenword. The same really goes for length types, since we're bound to get an inundation of weird types once we start adding new ones. Maxi-singles, Mini-albums, split-singles, etc. Thoughts? Hierarchy makes sense to me. As a starting point, here's an attempt at just the album part, with examples: album This tree is intentionally maximalist, but it could be streamlined: maybe just album + four mutually exclusive subtypes: live, remix, soundtrack and compilation. I would think the migration scheme should be kept much simpler in any case. Two other thoughts: Nikki, you wrote that you'd find it strange to call spokenword releases albums. How about comedy albums? I'd be OK with putting spokenword releases under "other" if that's the way most people view it, but I think there's a case to be made for classing them as either albums or EPs, depending on their length. And while we're at it: Does "spokenword" really have to be one word? Is this a database constraint, or can we call it "spoken word"? If not, would "spoken-word" be an option? A hierarchy makes absolutely no sense to me. Don't forget that this is just the initial list of types. There have been a number of suggestions for new release types which are waiting for this to be implemented before anyone will consider adding them. Implementing this as a hierarchy will end up preventing us from being able to add new things, because the number of combinations would just be insane. The medium formats hierarchy also doesn't work well - that's also got a bunch of things waiting for the hierarchy to be replaced with something similar to what was originally suggested here before they can be considered (if you disagree that it doesn't work well, you're welcome to figure out how to add 8cm HDCD, 8cm VCD, 8cm DVD, etc etc into the hierarchy in a way that doesn't involve doubling the length of the list). I don't think they're all nonsensical (some are a bit far-fetched though), e.g. I can easily imagine a release which uses live + soundtrack. I don't really see why we have to prevent certain combinations. If they don't make sense together, then don't use them together! @Patrick: I was mainly talking about migrating the data. I wouldn't have a problem with things like that being album + spokenword (and that's another example of where a combination that sounded implausible to one person makes sense to another) Does anyone here edit Discogs? Do you know how they handle nonsensical combinations? Is it even a problem for them? IMO they need to be multi-selectable. I'm not aware of any "remix soundtrack compilation" albums, but someone could easily make a "best of ocremix" compilation and that would qualify. In addition, the tree concept results in duplication across everything — you'll end up with "single", "live single", "remix single", "soundtrack single" "soundtrack remix single" ... etc. Much better (and easier to use) to just have two simple lists, even if not every combination makes sense. I agree that spokenword/interview are a little weird/redundant (most every interview would also be spokenword), but I don't see why they wouldn't be albums. Regarding spokenword vs. "spoken word" — it certainly is a lot easier to do an advanced search (for type:spokenword) when it's one word. @nikki: Fair enough, I'll keep it simple. Not like there's going to be much in the way of fuzzy types anyway. The suggested schema is here: http://i.imgur.com/VT3KE.png The precise migration specs have yet to be worked out, thought they're not really important to the schema change itself. Apart from Remix most types should be fairly easy to migrate cleanly. Alex: Sorry, I think my above comments may have confused the issue a little and now I am confused. Will these changes only affect Release Groups or also Releases, to a degree? Currently, I've seen remix singles in release groups that also contain non-remix singles. Now that I think about it, I don't think I've seen a release sampler in a separate Release Group to its main entity (though this could be possible as a separate EP release in its own RG?). So, will we be able to apply any of these attributes on the Release level? @Jacob Brett: That was not the plan, content types need to be at a RG level, otherwise we'd be stuck with a mess of album/ep/single, which isn't very helpful. I think you definitely bring up an interesting point, though I'm not sure if it's worth extending content types to releases as well until we've seen how great the need is. I can for instance easily see release samplers moved to separate Single/EP groups and be linked as supporting release. There's a bug somewhere to list supporting releases in RG-views IIRC. Remix singles are trickier, though I'm not sure it's worth breaking anything over those. @Jacob: Currently the plan is to leave the type where it is, i.e. at RG level. I agree that there's a need for it at the release level as well[1], but exactly how to do it is less clear. For now I think we'll just have to move forward with this and figure out releases later. BTW, here's a standalone sampler[2]and another (not sure if in MB)[3] 1. http://musicbrainz.org/release-group/f66cb5a9-9830-4158-abfc-c5c69cc3f6a5 From http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-04/2012-04-02.html#T14-22-00-931664
I think this ticket is defined enough for inclusion in this set of schema changes. How are we going to show this in the web service? I would be in favour of something structured (ie, more than just intercalating all types with a space). Moving some types from type to secondary type is going to break the logic of some applications. i.e If an application that have logic based on type containing certain values the it will no longer have (have such as Compilation and Live) then that logic will break. Im wondering if type field should be preserved, and we should add a new field primary type field to the database containing the improved version of type, to give applications time to be fixed to take advantage of the new changes. Heres a simple example of the problem, the Jaikoz Tagger (and I think Picard as well) use type="Compilation" to decide whether to set the TCMP field in mp3s tagged. This sraight forward functionality is going to break with new release, of course I can release a new version of Jaikoz but I hadnt planned to and even if I release on the same day as the new schema is released there is going to be a delay in people updating. I expect there are other aplications that do something simailr but do not follow changes in Musicbrainz as closely. So my solution was to add a new element <primarytype> to the xml output which and keep the type attribute storing the old value for a period. May not need to keep the old data in the column, migt be able to derive a suitable value for type from the data stored in primarytype and secondarytype. Does this mean we can finally get 'Mixed' in there? I can think of examples of: Album + Mixed so whatever decisions are made for implementing this need to be able to accommodate these. Also need to consider the release group type filter when browsing entities returned releases with old releasegroup type live, but now allowed with new code because live is not a primary release group type type filter should be almagamation of primarytype and secondarytype for backwards compatability, but also for usefulness because with the current code there is no way to filter by a secondsary type Paul's comment has been implement.d The artist page changed drastically and there was no RFC ! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Closed
Normal
Split release group attributes into two types
Is there a discussion somewhere about this?
Is there's a specification on how current data will be migrated?