Re: [mb-style] Merging multi-language releases?
On Sun, May 22, 2011 at 22:53, Kuno Woudt k...@frob.nl wrote: Hello, On 22/05/11 15:53, Philip Jägenstedt wrote: Before NGS I added some releases where both English and Chinese titles appear on the cover. I created one release for each language. http://musicbrainz.org/release/0a4a71ed-b7d9-44f9-91dd-5cacec86060e and http://musicbrainz.org/release/a78902cf-4ed1-414b-ae34-80076f6142f9 is one such pair. With NGS it feels unclear to have multiple releases where there is only one physical release, so I've tried to merge these in http://musicbrainz.org/edit/14491834 and http://musicbrainz.org/edit/14491847 Is this an approach that people agree with? The languages are joined in a very peculiar manner here, with _. What should one do when two languages appear on the cover in a more independent fashion, as in http://musicbrainz.org/edit/7588058 (I only added the Chinese variants for this, see cover at http://www.114bt.com/btimg/2007/1/6/682751.jpg)? In that cover image one of the languages is clearly the main tracklist, with the other just supplemental. IF you were to merge those my suggestion would be to use this format: 1. Primary Language (Secondary Language) That seems the most common format used elsewhere. It seems sane tagging will be made harder by merging these, because almost no one will want both languages, I'm guessing. Should we perhaps just use pseudo-releases for tracklists on a usable form and leave the official releases in their original true-to-the-cover form? I wouldn't strongly object to combining both languages in a single release, but I would prefer not to start doing that just yet. I think we should just keep doing what we've been doing before NGS, so two releases in our database - link them with translation relationships and mark both official. And formulate how we think translations _should_ work, then I can start coding that feature and we can have this sorted properly soonish :D Since I wasn't very happy with the result, I reverted the change in http://musicbrainz.org/edit/14503147 Going forward, I think that it would be nice if perhaps recordings could have aliases by language. Perhaps there should be some attribute for official translations, if there is such a thing. With such a scheme, we could get rid of lots of pseudo-releases and wouldn't have to duplicate release events or any AR:s on those. Or should translations be on the tracklist level perhaps? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Separate works for instrumental version?
On Sun, May 22, 2011 at 20:45, Nikki aei...@gmail.com wrote: Philip Jägenstedt wrote: That sounds pretty good, but it wouldn't really be accurate for karaoke tracks where the background singers are usually left in and only the lead singer is left out. Perhaps a karaoke attribute would work, but I'm not sure if it's going to be possible to draw a line between the two in general. By the way, we have a recording-recording relationship for linking karaoke tracks to the corresponding vocal track, so we do already have a way to identify those. Thanks, I didn't know that! I've started using that now. I like the idea of an instrumental attribute for the performance relationship for things which aren't karaoke versions. It's one of the things I was already thinking would be nice to have. I don't really know what to do about proper instrumental performances, karaoke versions without backing vocals and karaoke versions with backing vocals though... It seems difficult to make a distinction without confusing people. Indeed, the distinction between karaoke is not clear at all, in many cases the distinction would seem to be only what it's *for* rather than what it *is*, and I'm not sure how those debates could be resolved. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging multi-language releases?
Hello, On 24/05/11 09:28, Philip Jägenstedt wrote: Going forward, I think that it would be nice if perhaps recordings could have aliases by language. Perhaps there should be some attribute for official translations, if there is such a thing. With such a scheme, we could get rid of lots of pseudo-releases and wouldn't have to duplicate release events or any AR:s on those. Or should translations be on the tracklist level perhaps? Translations at the tracklist level sounds sensible. I think it's OK to keep a single canonical name at the recording level. -- kuno / warp. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG: research for Release names artists
Thanks. I voted for it, although I don't know if the votes are taken into account. 2011/5/23 Nikki aei...@gmail.com By the way, there's a ticket here http://tickets.musicbrainz.org/browse/MBS-684 Nikki Brant Gibbard wrote: Sorry, I mis-spoke. I was testing with the annotation, and I had forgotten about the existence of the comment field for releases (as distinct from the annotation). The comment field DOES show up. This will indeed work as a temporary workaround, however, since the label and catalogue number are already present in the records it seems a wasteful duplication to re-add the same information to yet another field. It is well worthing using this as a work-around for the time being though. Brant Gibbard Toronto, ON http://bgibbard.ca http://bgibbard.ca/ From: musicbrainz-style-boun...@lists.musicbrainz.org [mailto:musicbrainz-style-boun...@lists.musicbrainz.org] On Behalf Of caller#6 Sent: May-23-11 11:54 AM To: musicbrainz-style@lists.musicbrainz.org Subject: Re: [mb-style] CSG: research for Release names artists On 05/23/2011 04:58 AM, Brant Gibbard wrote: From: musicbrainz-style-boun...@lists.musicbrainz.org [mailto:musicbrainz-style-boun...@lists.musicbrainz.org] On Behalf Of Frederic Da Vitoria Sent: May-23-11 4:47 AM To: MusicBrainz Style Discussion Subject: Re: [mb-style] CSG: research for Release names artists 2011/5/22 Brant Gibbard bgibb...@ca.inter.net Another issue that would require a UI change to resolve. If you do a an add of a TOC from a disc, the list of potential hits for your chosen artist gives only the title and a list of tracks, no other information. Not even the comment? Or the Release Artists? -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Capitalization in NGS
On Tue, May 24, 2011 at 01:52, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: On 23 May 2011 07:21, Frederic Da Vitoria davito...@gmail.com wrote: 2011/5/22 Dr Andrew John Hughes gnu_and...@member.fsf.org I really don't see why we want to retain all covers verbatim; I thought MusicBrainz was a database, not a cover archive. Maybe because the MB database could store what IS as well as what users would want to be? Or because what you want is not necessarily what other users want. And because NGS is able to store both the standardized and the printed titles. So that tracks would capture as much information as possible from the physical release (no, no color info :-) ) while the recording and the release would contain a standardized title. Also, sticking to the cover has the advantage that it minimizes the amount of knowledge needed to enter new releases in MB. And if you want to speak technically of databases, wouldn't normalizing track titles make them identical to recording titles, which would be data redundancy, one of the bad things database designers are advised to avoid as much as possible? Just because it can doesn't mean it should. I really don't see a great value in keeping lots of data about covers. I get that apparently some 'other users' want this, but I haven't seen a convincing argument from them yet. Users have always managed to enter releases without following guidelines, and more experienced users have just ended up cleaning them up, so I don't see how this would suddenly make things easier for the novices. The extra recording layer makes things more complicated, and they are still going to enter the titles there in a non-standard way. Write what's on the cover is quite obviously easier than read these guidelines about capitalization, feat. style, extra title information, etc. People who care can then standardize the recordings, not the tracklists. Usually, a database is created to not only store information, but to allow it to be used for some purpose. It makes it very hard to get useful information from MusicBrainz if titles are varying based on what someone chose to do on the cover. Wait until the next Picard release and then you can (allegedly) chose if you want normalized titles or not. How does MusicBrainz become less useful by storing both standardized titles and the as-on-cover titles? It does become harder to verify that the titles are correct if you don't have the physical release, but if you worry about that you can just use the (normalized) recording titles. Yes, track titles are superfluous if they are standardised to be the same as recording titles. This is why I would just use the recording titles in tracklists and not have separate track titles. All I'm seeing so far is a lot of additional work being created by these track titles (every title change now needs two edits and the new interface isn't very speedy) and no advantages. If you think that we just shouldn't have the separation between tracklist titles and recording titles, will you file a bug to remove the feature from MusicBrainz? If they should really be the same, then having the separation is actively harmful and a waste of time. IMO, we should put tracklists to good use by storing as-on-cover titles in them. While variations in capitalization usually isn't interesting, there are cases where it is and it is simpler to say write what's on the cover than write what's on the cover but normalize capitalization taking artist intent and consistent original data into consideration. To give an example where merging track and recording names would be harmful is the Hong Kong group my little airport: http://musicbrainz.org/artist/ea6185ea-0138-4b8c-a81a-e8fb90d7c680 This group consistently uses lower case letters in their name and release/track titles, both on the physical releases and their website. This is reflected in the official releases already. However, on the compilation/VA releases from outside Hong Kong that capitalization has not been followed. Someone who only has the compilation will almost certainly not want the capitalization to be lowercased just because that's the way they are on the original releases. Likewise, people who only have the original release will want that capitalization, not the bastardized capitalization from a foreign compilation. The only way to allow this while still merging recordings is of course to have separate titles in the tracks and recordings. (It's almost as if NGS was designed specifically to solve this problem...) -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging multi-language releases?
On Tue, May 24, 2011 at 09:48, Kuno Woudt k...@frob.nl wrote: Hello, On 24/05/11 09:28, Philip Jägenstedt wrote: Going forward, I think that it would be nice if perhaps recordings could have aliases by language. Perhaps there should be some attribute for official translations, if there is such a thing. With such a scheme, we could get rid of lots of pseudo-releases and wouldn't have to duplicate release events or any AR:s on those. Or should translations be on the tracklist level perhaps? Translations at the tracklist level sounds sensible. I think it's OK to keep a single canonical name at the recording level. I guess that one downside of tracklist level translations is that you don't get translations of the same recordings if they appear on multiple releases for free. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging multi-language releases?
On 24/05/11 10:37, Philip Jägenstedt wrote: On Tue, May 24, 2011 at 09:48, Kuno Woudtk...@frob.nl wrote: Hello, On 24/05/11 09:28, Philip Jägenstedt wrote: Going forward, I think that it would be nice if perhaps recordings could have aliases by language. Perhaps there should be some attribute for official translations, if there is such a thing. With such a scheme, we could get rid of lots of pseudo-releases and wouldn't have to duplicate release events or any AR:s on those. Or should translations be on the tracklist level perhaps? Translations at the tracklist level sounds sensible. I think it's OK to keep a single canonical name at the recording level. I guess that one downside of tracklist level translations is that you don't get translations of the same recordings if they appear on multiple releases for free. That doesn't necessarily seem like a bad thing. For certain kinds of releases there are many translations, both official and unofficial. I don't want those mixed up, so it seems easier to consider the entire tracklist as a unit. Releases with identical tracklists use the same tracklist entry in the database, so translating the tracklist on one release would already make that translation available to other releases for free. -- kuno. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Capitalization in NGS
2011/5/24 Dr Andrew John Hughes gnu_and...@member.fsf.org On 23 May 2011 07:21, Frederic Da Vitoria davito...@gmail.com wrote: 2011/5/22 Dr Andrew John Hughes gnu_and...@member.fsf.org I really don't see why we want to retain all covers verbatim; I thought MusicBrainz was a database, not a cover archive. Maybe because the MB database could store what IS as well as what users would want to be? Or because what you want is not necessarily what other users want. And because NGS is able to store both the standardized and the printed titles. So that tracks would capture as much information as possible from the physical release (no, no color info :-) ) while the recording and the release would contain a standardized title. Also, sticking to the cover has the advantage that it minimizes the amount of knowledge needed to enter new releases in MB. And if you want to speak technically of databases, wouldn't normalizing track titles make them identical to recording titles, which would be data redundancy, one of the bad things database designers are advised to avoid as much as possible? Just because it can doesn't mean it should. I really don't see a great value in keeping lots of data about covers. I get that apparently some 'other users' want this, but I haven't seen a convincing argument from them yet. Just as we would probably have difficulties convincing them our way of seeing things is better :-) This is precisely my point: we can have both, we can make both categories of users happy, so let's do it. There are two kinds of democracy: either the biggest group wins and minorities just shut up or each groups manages to have it's way without stepping on other group's toes. I prefer the second way, although it is much more difficult to manage. Users have always managed to enter releases without following guidelines, and more experienced users have just ended up cleaning them up, so I don't see how this would suddenly make things easier for the novices. If NGS did not enable new things, then what would be the point? Entering data as printed seems obviously easier than delving in variously official style guides. Many users (me included) followed SGs because they thought they were official. Or missed others for lots of good reasons. I believe the Release level should be kept simple so that even novice users can enter data without having to transform much apart from capitalizations, obvious misspellings and so on. Release Group and Recording would be for more experienced users, and Work level of course for the most experienced. Note that I am not suggesting that access should be regulated. The extra recording layer makes things more complicated, and they are still going to enter the titles there in a non-standard way. Sometimes, yes, you can't avoid it entirely, but saying as printed has much more chances of being followed by novice users who are not yet fully aware of the advantages of standardization than as the ### Style Guides say. Usually, a database is created to not only store information, but to allow it to be used for some purpose. It makes it very hard to get useful information from MusicBrainz if titles are varying based on what someone chose to do on the cover. Please don't mix Release titles and Recording titles. I agree we need standardization. But I am convinced this standardization can and should be limited to the more abstract levels. Yes, track titles are superfluous if they are standardised to be the same as recording titles. This is why I would just use the recording titles in tracklists and not have separate track titles. All I'm seeing so far is a lot of additional work being created by these track titles (every title change now needs two edits and the new interface isn't very speedy) and no advantages. Aha, now we get to your real issue. Sorry, but I guess NGS is here to stay :-) Do you have an example of where information is lost? No, but I could try to find one, although it would be difficult. I guess in the case of tracks which were issued lots of times, there could be releases where track titles mentioned interesting but unique information. I think I remember a Jazz sampler with very detailed info, but there could be other examples. Or some release could use a separate spelling which would be normalized per ConsistentOrigilanData but might still be an expression of ArtistIntent. Sometimes we will not know if the variations, extra informations and so on are really relevant, but having the different names that a Recording or a Work was released under could be quite meaningful. Once again, I am not speaking of case variations or misspellings. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org
[mb-style] IMDb relationship
Hello I just noticed that the link name for the AR to relate a (soundtrack) release group to its movie's URL at IMDb has been somehow merged with the AR to indicate a recording uses samples from a movie (by linking to its IMDb URL). Was this intentional / discussed at a previous time? Because this [1] can not be wanted behaviour? [1] http://musicbrainz.org/release-group/80fe84a4-b606-3491-a170-f2ca17501493/relationships -- azertus ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] NGS guidelines
For a few reasons, I've been silent here for the past while. However, I feel I have to at least comment on the change in guidelines that has taken place. I may not be commenting on the list, but I do still at least skim the style list to see what's happening. Thus, when I saw an edit note citing something in an entirely rewritten guideline, I was rather surprised. Based on nikki's announcement ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ), it looked like a rewrite in progress, not a RFC, let alone a RFC that changed every single style guideline. I looked at the time with the understanding that this was a work in progress, not something just days away from being official. Yet the change to the pages from being available for review at User:kuno/Style to those same pages suddenly being the official guidelines took place only 6 days later and with no RFC/RFV/etc, only http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html . So how did such a major and complete rewrite skip RFC/RFV, and become official within 6 days of being announced (if you count nikki's May 10 email as being the RFC, though not mentioned in the email's subject). I won't email again, but this is important enough that I couldn't not say something. Every single style guideline has been changed, and there's more than a few of the new guidelines which have dropped important items and/or changed things counter to how they were decided back during RFCs for the individual guidelines. Brian ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On Tue, May 24, 2011 at 14:34, Brian Schweitzer brian.brianschweit...@gmail.com wrote: For a few reasons, I've been silent here for the past while. However, I feel I have to at least comment on the change in guidelines that has taken place. I may not be commenting on the list, but I do still at least skim the style list to see what's happening. Thus, when I saw an edit note citing something in an entirely rewritten guideline, I was rather surprised. Based on nikki's announcement ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ), it looked like a rewrite in progress, not a RFC, let alone a RFC that changed every single style guideline. I looked at the time with the understanding that this was a work in progress, not something just days away from being official. Yet the change to the pages from being available for review at User:kuno/Style to those same pages suddenly being the official guidelines took place only 6 days later and with no RFC/RFV/etc, only http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html . So how did such a major and complete rewrite skip RFC/RFV, and become official within 6 days of being announced (if you count nikki's May 10 email as being the RFC, though not mentioned in the email's subject). I won't email again, but this is important enough that I couldn't not say something. Every single style guideline has been changed, and there's more than a few of the new guidelines which have dropped important items and/or changed things counter to how they were decided back during RFCs for the individual guidelines. Brian I'll let nikki and kuno speak for themselves, but just wanted to note that I support the complete overhaul and that the normal process has been circumvented. Most of the old guidelines don't make sense with NGS, and doing such a big change by RFC/RFV would have been extremely painful. I think we're much better off taking the rewrite and working from there. Getting people in sync with the changes is another matter, but I expect we'll sort it out. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Bonus discs?
http://musicbrainz.org/edit/14491791 azertus is asking if we should have a way to record the fact that a disc is considered bonus. It does seem that this ability was lost in the move to NGS, but I'm not sure I think it's important. Thoughts? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
I support the complete overhaul and that the normal process has been circumvented. Most of the old guidelines don't make sense with NGS, and doing such a big change by RFC/RFV would have been extremely painful. I think we're much better off taking the rewrite and working from there. I couldn't agree more. (I know, I've tried). ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Works and remixes/covers
2011/5/18 Lukáš Lalinský lalin...@gmail.com: The original NGS documentation which was written by me [1] says that works with different remixes should be merged together. The Work page [2] however says that they should be kep separate. All people I've discussed this with agree that they should be merged. Can I change the Work page to remove the mention of remixes? Lukas [1] http://wiki.musicbrainz.org/Next_Generation_Schema#Work [2] http://wiki.musicbrainz.org/Work ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style Can we please come to a decision on this? I now have a number of merges being voted down (e.g. http://musicbrainz.org/edit/14496213) due to this dumb guideline. It makes no sense to have remixes as separate works, especially when the remix AR is at recording level and covers are not separate works but are more different (new vocals, new production, etc.). I really don't see the point in works if we're going to allow an artist's work catalogue to be filled with five or ten remixes of each song. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On 24 May 2011 13:34, Brian Schweitzer brian.brianschweit...@gmail.com wrote: For a few reasons, I've been silent here for the past while. However, I feel I have to at least comment on the change in guidelines that has taken place. I may not be commenting on the list, but I do still at least skim the style list to see what's happening. Thus, when I saw an edit note citing something in an entirely rewritten guideline, I was rather surprised. Based on nikki's announcement ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ), it looked like a rewrite in progress, not a RFC, let alone a RFC that changed every single style guideline. I looked at the time with the understanding that this was a work in progress, not something just days away from being official. Yet the change to the pages from being available for review at User:kuno/Style to those same pages suddenly being the official guidelines took place only 6 days later and with no RFC/RFV/etc, only http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html . So how did such a major and complete rewrite skip RFC/RFV, and become official within 6 days of being announced (if you count nikki's May 10 email as being the RFC, though not mentioned in the email's subject). I won't email again, but this is important enough that I couldn't not say something. Every single style guideline has been changed, and there's more than a few of the new guidelines which have dropped important items and/or changed things counter to how they were decided back during RFCs for the individual guidelines. Brian ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style I couldn't agree more and I've raised this issue in at least one discussion. I didn't expect NGS to be an excuse to change the guidelines by dictate rather than discussion. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] IMDb relationship
I have tried to find some examples to work out what is wrong and what is right. It seems that only the current release-group-URL IMDb AR is wrong. See a summary at http://wiki.musicbrainz.org/User:Azertus/Potential_IMDb_Relationship_Type_Problem Of course, this might be just a bug? azertus On Tue, May 24, 2011 at 12:38 PM, azertus azer...@skynet.be wrote: Hello I just noticed that the link name for the AR to relate a (soundtrack) release group to its movie's URL at IMDb has been somehow merged with the AR to indicate a recording uses samples from a movie (by linking to its IMDb URL). Was this intentional / discussed at a previous time? Because this [1] can not be wanted behaviour? [1] http://musicbrainz.org/release-group/80fe84a4-b606-3491-a170-f2ca17501493/relationships -- azertus ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
2011/5/24 Philip Jägenstedt phi...@foolip.org On Tue, May 24, 2011 at 14:34, Brian Schweitzer brian.brianschweit...@gmail.com wrote: For a few reasons, I've been silent here for the past while. However, I feel I have to at least comment on the change in guidelines that has taken place. I may not be commenting on the list, but I do still at least skim the style list to see what's happening. Thus, when I saw an edit note citing something in an entirely rewritten guideline, I was rather surprised. Based on nikki's announcement ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ), it looked like a rewrite in progress, not a RFC, let alone a RFC that changed every single style guideline. I looked at the time with the understanding that this was a work in progress, not something just days away from being official. Yet the change to the pages from being available for review at User:kuno/Style to those same pages suddenly being the official guidelines took place only 6 days later and with no RFC/RFV/etc, only http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html . So how did such a major and complete rewrite skip RFC/RFV, and become official within 6 days of being announced (if you count nikki's May 10 email as being the RFC, though not mentioned in the email's subject). I won't email again, but this is important enough that I couldn't not say something. Every single style guideline has been changed, and there's more than a few of the new guidelines which have dropped important items and/or changed things counter to how they were decided back during RFCs for the individual guidelines. Brian I'll let nikki and kuno speak for themselves, but just wanted to note that I support the complete overhaul and that the normal process has been circumvented. Most of the old guidelines don't make sense with NGS, and doing such a big change by RFC/RFV would have been extremely painful. I think we're much better off taking the rewrite and working from there. Getting people in sync with the changes is another matter, but I expect we'll sort it out. If we had followed the usual process even for only a minimal set of guides, we would have had to delay NGS for maybe a few months, which would have been a pity, because installing such a big change without upgrading the guides would have been madness and probably resulted in lots of bad data. I also feel that the 2011-05-10 post actually said what was going to happen. I did not realize it when I read it at that time, but it's there. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bonus discs?
On Tue, May 24, 2011 at 5:41 PM, Philip Jägenstedt phi...@foolip.org wrote: http://musicbrainz.org/edit/14491791 azertus is asking if we should have a way to record the fact that a disc is considered bonus. It does seem that this ability was lost in the move to NGS, but I'm not sure I think it's important. Thoughts? I would say if it is important it can be added in an annotation. I mean, before we didn't really show if a disc was considered bonus, it just indicated that a release was available with and without another (and we also used it for linking boxsets also published as standalone releases and stuff like that). Now we have two different releases, with and without the bonus disc, so I wouldn't say it is something worth stating in most cases. But maybe someone thinks it is? -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bonus discs?
Well, we could simply add it to the name of the bonus medium in the release? Nicolás Tamargo de Eguren reosare...@gmail.com ha scritto: On Tue, May 24, 2011 at 5:41 PM, Philip Jägenstedt phi...@foolip.org wrote: http://musicbrainz.org/edit/14491791 azertus is asking if we should have a way to record the fact that a disc is considered bonus. It does seem that this ability was lost in the move to NGS, but I'm not sure I think it's important. Thoughts? I would say if it is important it can be added in an annotation. I mean, before we didn't really show if a disc was considered bonus, it just indicated that a release was available with and without another (and we also used it for linking boxsets also published as standalone releases and stuff like that). Now we have two different releases, with and without the bonus disc, so I wouldn't say it is something worth stating in most cases. But maybe someone thinks it is? -- Philip Jägenstedt _ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren_ 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] NGS guidelines
On 24 May 2011 15:38, Philip Jägenstedt phi...@foolip.org wrote: snip.. I'll let nikki and kuno speak for themselves, but just wanted to note that I support the complete overhaul and that the normal process has been circumvented. Most of the old guidelines don't make sense with NGS, and doing such a big change by RFC/RFV would have been extremely painful. I think we're much better off taking the rewrite and working from there. Getting people in sync with the changes is another matter, but I expect we'll sort it out. Sorry, but a process taking time or being painful is not a reason to impose the views of a few people on everyone else. -- Philip Jägenstedt ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Andrew :-) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bonus discs?
2011/5/24 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, May 24, 2011 at 5:41 PM, Philip Jägenstedt phi...@foolip.org wrote: http://musicbrainz.org/edit/14491791 azertus is asking if we should have a way to record the fact that a disc is considered bonus. It does seem that this ability was lost in the move to NGS, but I'm not sure I think it's important. Thoughts? I would say if it is important it can be added in an annotation. I mean, before we didn't really show if a disc was considered bonus, it just indicated that a release was available with and without another (and we also used it for linking boxsets also published as standalone releases and stuff like that). Now we have two different releases, with and without the bonus disc, so I wouldn't say it is something worth stating in most cases. But maybe someone thinks it is? -- Philip Jägenstedt -- Nicolás Tamargo de Eguren Well, I'd be surprised if no-one would think it worthwile to keep that info. I agree now that putting something like 'bonus disc' in the medium title (as I first suggested) is not something we'd want to be doing. Just when we've got rid of ' (disc x)'... Perhaps I lament the loss of ' (bonus disc)' because I've been brought up on the MusicBrainz way of thinking? Dare I suggest it: a 'bonus check' per medium? In any case we had good guidelines that determined if ' (bonus disc)' could be added to a release pre-NGS, so if a bonus check was added, those same guidelines could police its use... -- azertus ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: Sorry, but a process taking time or being painful is not a reason to impose the views of a few people on everyone else. I don't think that the intent of the NGS guideline updates was to impose someone's view on everyone else. But the NGS changes are huge, and IMHO it would have been impossible to get the guidelines right in advance. People have to actually work with the new data model. I see the updated NGS guidelines as a starting point. What we now need is the discussion here on the mailing list to improve the guidelines and to work out how to handle all the style issues in NGS. -- Philipp ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
and IMHO it would have been impossible to get the guidelines right in advance I think it would have been possible, but we would still be waiting for NGS two or three years down the line. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On 24/05/2011 16:59, Philipp Wolfer wrote: On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes gnu_andrew-igugqlvvqircv4ilt04...@public.gmane.org wrote: Sorry, but a process taking time or being painful is not a reason to impose the views of a few people on everyone else. I don't think that the intent of the NGS guideline updates was to impose someone's view on everyone else. But the NGS changes are huge, and IMHO it would have been impossible to get the guidelines right in advance. People have to actually work with the new data model. I see the updated NGS guidelines as a starting point. What we now need is the discussion here on the mailing list to improve the guidelines and to work out how to handle all the style issues in NGS. I'm sure it wasn't the intent, and I agree that it's important for the editor population to have some guidelines in place from the start. It's very important, certainly to me and I think also to others, that it is an open project that I am contributing to, and it's not good enough to have guidelines written by two dictators, however benign. So now that we've reached this point, what will be the formal process by which the current provisional guidelines are validated and approved, and the arguments considered when developing previous guidelines not forgotten? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On Tue, May 24, 2011 at 7:13 PM, monxton musicbra...@jordan-maynard.org wrote: On 24/05/2011 16:59, Philipp Wolfer wrote: On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes gnu_andrew-igugqlvvqircv4ilt04...@public.gmane.org wrote: Sorry, but a process taking time or being painful is not a reason to impose the views of a few people on everyone else. I don't think that the intent of the NGS guideline updates was to impose someone's view on everyone else. But the NGS changes are huge, and IMHO it would have been impossible to get the guidelines right in advance. People have to actually work with the new data model. I see the updated NGS guidelines as a starting point. What we now need is the discussion here on the mailing list to improve the guidelines and to work out how to handle all the style issues in NGS. I'm sure it wasn't the intent, and I agree that it's important for the editor population to have some guidelines in place from the start. It's very important, certainly to me and I think also to others, that it is an open project that I am contributing to, and it's not good enough to have guidelines written by two dictators, however benign. So now that we've reached this point, what will be the formal process by which the current provisional guidelines are validated and approved, and the arguments considered when developing previous guidelines not forgotten? Well, this is the basic NGS set, and of course it is open to modifications. If you don't agree with something and think it should be done in other way, why am I not seeing any RFC about it? ;) Go propose stuff! ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Works and remixes/covers
On 05/24/2011 08:02 AM, Dr Andrew John Hughes wrote: 2011/5/18 Lukáš Lalinskýlalin...@gmail.com: The original NGS documentation which was written by me [1] says that works with different remixes should be merged together. The Work page [2] however says that they should be kep separate. All people I've discussed this with agree that they should be merged. Can I change the Work page to remove the mention of remixes? Lukas [1] http://wiki.musicbrainz.org/Next_Generation_Schema#Work [2] http://wiki.musicbrainz.org/Work Can we please come to a decision on this? I now have a number of merges being voted down (e.g. http://musicbrainz.org/edit/14496213) due to this dumb guideline. It makes no sense to have remixes as separate works, especially when the remix AR is at recording level and covers are not separate works but are more different (new vocals, new production, etc.). I really don't see the point in works if we're going to allow an artist's work catalogue to be filled with five or ten remixes of each song. For the sake of consistency, I'd rather see the entire list of derivative works[1] addressed, rather than just re-mixes. But this is a good first step. Putting most re-mix/mashup/medley/ Relationships at the Recording level makes sense to me[2]. Or, put another way, some distinctiveness belongs at the Performance level. Alex / caller#6 [1] http://wiki.musicbrainz.org/Work#Distinctiveness ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
On May 24, 2011, at 8:04 AM, Dr Andrew John Hughes wrote: I couldn't agree more and I've raised this issue in at least one discussion. I didn't expect NGS to be an excuse to change the guidelines by dictate rather than discussion. I'd like to remind folks that Nikki and Warp are your BDFLs for all things style. That said, I applaud their efforts (and financially supported them as well!) for making NGS style guidelines happen. At some point you have to put a few people together, get out of the way and let them revamp everything. This was one of those times and I support Warp and Nikki in their work -- thank you, you two! This isn't to say that the NGS style guidelines didn't get at least a modicum of review by others -- they did. Nor is their work saying that we're going to ignore the input from the community -- we aren't. If something is broke now, lets use the community process to fix it. -- --ruaokThe answer to whether or not something is a good idea should not be taken as an indication of whether I want to do it. Robert Kaye -- r...@eorbit.net --http://mayhem-chaos.net ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS guidelines
Hello, So how did such a major and complete rewrite skip RFC/RFV, and become official within 6 days of being announced (if you count nikki's May 10 email as being the RFC, though not mentioned in the email's subject). I think this misrepresents what nikki and I have done. No major changes were made to the guidelines. In all cases where I wanted to remove a guideline or change a guideline I have posted an RFC to mb-style. What we did do is: 1. remove guidelines which no longer apply due to changes in NGS 2. add first versions of new guidelines for new elements of NGS 3. restructure everything so that it is no longer a jumble of tiny documents spread out over the wiki, but a set of guidelines with at least some structure to them. This whole process started in january 2010, and I think everyone has had enough time to participate in it or voice their objections. If you (or anyone else) think either nikki or I have not acted properly here I suggest you discuss that with ruaok. None of the new guidelines we've written are intended to be final. But we needed to have a starting point, and now that NGS has been release and everyone is using it, we have a better foundation to discuss all of this properly, and we can RFC/RFV any changes needed. -- kuno / warp. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Add CD-r to the format list
I was surprised when I saw this was not on the list. We have lots of those (see http://musicbrainz.org/tag/format-cd-r for a sample) and I would say it is distinctive enough to have it as an option under CD (or, if not, to have another way of indicating it). -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add CD-r to the format list
On 24/05/11 19:50, Nicolás Tamargo de Eguren wrote: I was surprised when I saw this was not on the list. We have lots of those (see http://musicbrainz.org/tag/format-cd-r for a sample) and I would say it is distinctive enough to have it as an option under CD (or, if not, to have another way of indicating it). agreed. I have a couple of purchased CD-r's, both 12cm and 8cm. -- kuno. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG: research for Release names artists: Missa solemnis
2011/5/22, caller#6 meatbyproduct-musicbra...@yahoo.com: On 05/21/2011 03:34 PM, symphonick wrote: First version of my research page for CSG release names artists. http://wiki.musicbrainz.org/User:symphonick/Unofficial_CSG_release_names 2. It seems to me (and I guess you agree) that listing /all/ the artists from the cover would be overkill. Yes. I'd recommend using primary artists, but maybe it can be left to the editor to decide which artists to include as long as they are listed on the cover. 3. Latin capitalization would (I think) be capital M, lowercase s. An obvious example of graphic artist caps. Saw the other thread, it woulld be great if we can follow MB-wide style. 4. Where the liner gives the key in French / English / German, I'd use French as the default, simply because it's a French label. Could that logic be applied to the Release Group title? That is, should the label's country be a factor in deciding which is the default language? I don't understand why you want a default title? I was hoping that was a pre-NGS issue. I should have been more clear in my multilang. example - the release title should be consistent with the entered tracklist. or should I say with the chosen release language. But I suppose it could happen that the tracklist has 4 languages while the title only has 2 or the other way around. /symphonick ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG: research for Release names artists: Missa solemnis
On 05/24/2011 02:29 PM, symphonick wrote: 2011/5/22, caller#6meatbyproduct-musicbra...@yahoo.com: 4. Where the liner gives the key in French / English / German, I'd use French as the default, simply because it's a French label. Could that logic be applied to the Release Group title? That is, should the label's country be a factor in deciding which is the default language? I don't understand why you want a default title? I was hoping that was a pre-NGS issue. I should have been more clear in my multilang. example - the release title should be consistent with the entered tracklist. or should I say with the chosen release language. But I suppose it could happen that the tracklist has 4 languages while the title only has 2 or the other way around. /symphonick Sorry. I can see now that I was using default in two different senses. What I mean was, if were entering that release, I'd (personally) default to the French since it's a French label. But that's not a very important decision, since pseudo or transl*tion releases can always be added. But for the Release Group (as you note on the wiki page) we need to choose *one* language (that will be displayed by default). Does it make sense to use the label country as one of the determining factors? Alex / caller#6 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
