[mb-style] BoxSetNameStyle
Right, we've all read the 'still' debate on mb-users, so lets discuss the key issue: _whether or not different configurations of the same release(s) should be indexed_ examples: - Seperately released EPs (or singles, etc) included as a bonus with Albums. Should it be AlbumTitle + EPTitle, or AlbumTitle + AlbumTitle (bonus disc: EPTitle) - Seperately released Albums being compiled together in a single release. Should it be AlbumTitle1 + AlbumTitle2, or AlbumTitle1 + AlbumTitle2 + AlbumTitle (disc 1) + AlbumTitle (disc 2) - Different configurations of BoxSets. Popular artists may have many boxsets compiling their release, so should we just list the original releases, or should we list every boxset configuration? currently, BoxSetNameStyle supports the fomer. so do i - i think the latter doesn't really fit with how we do things. i think it would fit better in a MBz where we index by PRODUCT, not ALBUM. ie, where very seperate pressing of a release gets its own entry (like discogs). points to consider: - perhaps 'boxset' is a bad name - IMO anything that compiles 2 (or more) seperately available releases, should come under these rules (ie, is a 'BoxSet'), but boxset perhaps implies that it's a big fancy box or whatever. not always the case - might just be a normal cd jewel case (or double gatefold vinyl, etc). - should the earliest release be the 'master' configuration? eg, if something is released as a boxset FIRST, then seperately later, then 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. ok then, lets have it :) chris / gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] add instrument request: vacuum cleaner
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Gurtler Sent: Monday, March 06, 2006 9:20 AM To: MusicBrainz style discussion Subject: Re: [mb-style] add instrument request: vacuum cleaner Don Redman wrote: On Mon, 06 Mar 2006 15:38:11 +0100, derGraph wrote: I've found a nice definition of musical instruments on http://en.wikipedia.org/wiki/Instrument: Musical instruments are devices designed to produce music [...] Maybe we could use this definition to not end up with hundreds of percussive instruments like book, coffee mug, matchbox, oil barrel, briefcase, table (oak), table (plastic), ... And we will end having such instruments if we add everything someone uses to make music. I think this plus Robert's criterion for at least 5 artist using that instrument seems like a good rule of thumb. With this rule, adding new instruments should be quicker and need less discussion. he said N references to this instrument being used on albums. not 5 different artists. all there rules for adding instruments that artist USE are getting quite ridiculous! Just add the frigging things to an alphabetical list as people find the need to use them in a relationship! [Beth aka Nyght] Wasn't there a comment about an other field, or, perhaps a fill in the blank type field? This seems to be perhaps the best solution. Especially with the albums listed. I am in support of the instruments being listed, however I can see why some people are wanting a bit of restraint too. (I know one of the artists I listen to has created their own instrument and I don't even know the name, but, you wouldn't find it anywhere else and yet he uses it a lot in his music.)[/beth aka nyght] What we need to do now, is test Mo's new instrument tree and figure out how to move the old data to the new tree. the main problem is mapping the old instruments to the new ones. Does somebody want to write a script for this? Should we start doing this by hand? for example Mo's tree could be added as a second tree to the test server (a new attribute instrument2), and people could try to move things by hand, in order to figure out how trivial/notrivial this is. I realy have no idea how to start. DonRedman --Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ 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 ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Additional square brackets Guideline request/suggestion
Age Bosma wrote: Hi, Have a look at the following release by Deep Purple: http://musicbrainz.org/showalbum.html?albumid=259007 The 'Deep Purple in Rock: Anniversary Edition' release contains extra bonus tracks with studio chats in between as separate tracks. On the album cover they are listed with the name 'Studio Chat' for each track without the number. Imo these 'Studio Chat' titles should be treated as special names since they aren't actual track titles. The closest current guideline would be to use square brackets like '[studio chat]' for each track. What do you think? Is there already a guideline for such special cases present in the wiki? It appears that this issue is a bit more problematic. Have a look at the following discussion: http://musicbrainz.org/showmod.html?modid=4350406 Even though the text 'Studio Chat' is listed on the cover of the album I still don't agree with mo that these should be treated as actual track titles like any other. This makes me wonder what the actual purpose of style guideline number 3 for untitled tracks is: http://wiki.musicbrainz.org/UntitledTrackStyle If this isn't a case that applies to that guideline, what is? Yours, Age ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] BoxSetNameStyle
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
Re: [mb-style] BoxSetNameStyle
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
Re: [mb-style] Veto - DVD in album titles
On Mar 5, 2006, at 2:39 PM, Don Redman wrote: like i said my opinion is if it's a DVD of a concert or performance, it doesn't belong in MB unless it's added as a bootleg. Right, I observe dissensus. Now we can either ask Robert, or decide to leave the issue without a guideline (that was Fuchs' proposal). I'm currently mulling it over -- I'll re-read the threads and figure out our next step later today/tomorrow. -- --ruaok Somewhere in Texas a village is missing its idiot. Robert Kaye -- [EMAIL PROTECTED] --http://mayhem-chaos.net ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] BoxSetNameStyle
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. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] AR-link ReQuest WasPreviousReleased / IsACompilationOf
According to the moderations [1] , [2] [3] I had to browse thru the all the AR related wiki pages http://wiki.musicbrainz.org/AdvancedRelationshipType and haven't found anything which fits in this case. Could we add a AR link was previous released / is a compilation of for albums? So far I've added such info into the album annotations - like here [4] For sure such a link has to be definied for : * maybe just one artist - like [1], [2], [3] [4] or * complete releases - like the FreeZone 3 sampler [5], which was previous released as 5 seperate Various Artists vinyls months before the complete package (2xCD/5xLP) was available. Schika [1] http://musicbrainz.org/showmod.html?modid=4390654 [2] http://musicbrainz.org/showmod.html?modid=4390657 [3] http://musicbrainz.org/showmod.html?modid=4390661 [4] http://musicbrainz.org/showalbum.html?albumid=187063 [5] http://www.discogs.com/release/6640 ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
