[mb-style] RFV: Add cover art type for watermarks
This is the RFV for the proposal to add watermark as a cover art type, to be used when images contain a watermark. It should expire on the 11th. Nikki Am 01.03.14 18:25, schrieb Nikki: Hello mb-style, Right now watermarked images are a grey area. They're technically allowed, in that there are no guidelines saying they aren't, but in practice they get removed or voted down for being watermarked. Sometimes though, the best (or only image) we can find of some part of a release is watermarked and in those cases it would be nice to be able to store them somehow. For some people, including me, it really doesn't feel right to just upload watermarked images. I can't really explain why, but I would feel much better about it if there were a way of detecting that an image is watermarked. Therefore I'm proposing that we add a cover art type watermark which should be used when an image also contains a watermark, so that we can upload them, but anyone not wanting to use watermarked images can use the data to filter them out. How this would affect things: - In cases where the best image we can find is not watermarked, this would change nothing. There is no reason to keep a watermarked image which is also poorer quality. - In cases where the only image we can find is watermarked, this would let us upload that image instead of having nothing. - In cases where we have a poorer quality image without a watermark and a better quality image with a watermark, which one is best depends on what you want to use it for, so my recommendation would be to upload both images, so that people can use whichever image best suits their purposes. This RFC should expire on the 8th. Ticket: http://tickets.musicbrainz.org/browse/STYLE-297 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Add cover art type for watermarks
Hello mb-style, Right now watermarked images are a grey area. They're technically allowed, in that there are no guidelines saying they aren't, but in practice they get removed or voted down for being watermarked. Sometimes though, the best (or only image) we can find of some part of a release is watermarked and in those cases it would be nice to be able to store them somehow. For some people, including me, it really doesn't feel right to just upload watermarked images. I can't really explain why, but I would feel much better about it if there were a way of detecting that an image is watermarked. Therefore I'm proposing that we add a cover art type watermark which should be used when an image also contains a watermark, so that we can upload them, but anyone not wanting to use watermarked images can use the data to filter them out. How this would affect things: - In cases where the best image we can find is not watermarked, this would change nothing. There is no reason to keep a watermarked image which is also poorer quality. - In cases where the only image we can find is watermarked, this would let us upload that image instead of having nothing. - In cases where we have a poorer quality image without a watermark and a better quality image with a watermark, which one is best depends on what you want to use it for, so my recommendation would be to upload both images, so that people can use whichever image best suits their purposes. This RFC should expire on the 8th. Ticket: http://tickets.musicbrainz.org/browse/STYLE-297 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-233: New cover art types
I somehow missed this. I don't object to having a type for it, but I think liner is the wrong word for it, or at best a very bad word to use. To me (and also https://en.wiktionary.org/wiki/liner so apparently I'm not the only one), it means the booklet. Go ahead and add it with the current name if you like, but I will be really surprised if people don't start misusing it for things like the folded pieces of paper often found in the front of CD cases that aren't really booklets. Nikki Am 03.09.13 15:08, schrieb Ben Ockmore: This has now passed - these cover art types need to be added to MB and the docs. On 29 Aug 2013 05:15, Rachel Dwight hibiscuskazen...@gmail.com wrote: Hey y'all, I allowed an extra week in the RFC because I thought the mailing list had slowed to a crawl. Turns out I was wrong. Plus school just started up for me and I got addicted to Tales of Xillia, so now it's RFV time! Ticket: http://tickets.musicbrainz.org/browse/STYLE-233 Expected expiration date: 2013-9-1 (I'm allotting for time zone differences) ___ 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] RFV: STYLE-97: Move medley to an attribute of recording of
I'm sorry, but I can't support this as it is. You don't seem to have provided any reason for getting rid of the existing relationship type. What does merging the relationship types give us that adding attributes to the existing relationship type does not? The link phrases are longer and IMO worse than what we currently have (recordings in a medley? that doesn't even make sense to me) and I'm also concerned that they will be very difficult to translate. You say this requires convincing someone to run a bot to migrate the existing relationships, but given how little success we've had in the past in removing deprecated relationship types, I would really like something more concrete than that *before* we decide to get rid of things (i.e. who is going to do it? have they got any code they can use? how will it be migrated? (see next section...)). Merging the two relationship types means that the partial attribute will be combinable with the medley attribute, but there seems to have been no consideration of the effects of that. e.g. I would not expect to have to select the partial attribute every time I pick medley but I'm sure some people will select it. Then it's inconsistent... Nikki Am 30.08.13 09:33, schrieb Tom Crocker: Expected expiration for RFV: 2013-09-02 12:00 UTC This is a proposal to add a medley attribute to the Performance Relationship Type, so that there is no need to have both a performance and medley relationship between a recording and a work. There have been no changes to the proposal during the RFC process: http://musicbrainz.1054305.n4.nabble.com/RFC3-STYLE-97-Move-quot-medley-quot-to-an-attribute-of-quot-recording-of-quot-tc4657153.html Wikis: http://wiki.musicbrainz.org/User:Tommycrock/Performance_Relationship_Type http://wiki.musicbrainz.org/User:Tommycrock/Medley_Relationship_Type Ticket: http://tickets.musicbrainz.org/browse/STYLE-97 ___ 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] RFV: Rights society relationship
There were no objections to this, so it's passed. Nikki Am 26.04.13 15:00, schrieb Nikki: This proposal is for a new label type Rights Society and a relationship between labels and releases, which will give the existing entries a real meaning and also give us a more structured way to enter rights society information. Wiki page for the relationship: http://wiki.musicbrainz.org/User:Nikki/Rights_society_relationship Ticket: http://tickets.musicbrainz.org/browse/STYLE-209 RFC thread: http://musicbrainz.1054305.n4.nabble.com/RFC-Rights-society-relationship-STYLE-209-td4651285.html Note: I'm not extending this to any other entities as part of this RFC, but that doesn't mean I'm opposed to someone else doing it later if they want to. Expiration date: 28th of April Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Rights society relationship
This proposal is for a new label type Rights Society and a relationship between labels and releases, which will give the existing entries a real meaning and also give us a more structured way to enter rights society information. Wiki page for the relationship: http://wiki.musicbrainz.org/User:Nikki/Rights_society_relationship Ticket: http://tickets.musicbrainz.org/browse/STYLE-209 RFC thread: http://musicbrainz.1054305.n4.nabble.com/RFC-Rights-society-relationship-STYLE-209-td4651285.html Note: I'm not extending this to any other entities as part of this RFC, but that doesn't mean I'm opposed to someone else doing it later if they want to. Expiration date: 28th of April Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Rights society relationship (STYLE-209)
Although rights societies aren't technically labels, there are a bunch entered as labels already, which we deliberately don't delete so that people can subscribe to them, e.g. the ones listed on http://wiki.musicbrainz.org/Label/Non-Labels Some people have already been putting the information in the annotation, e.g. https://musicbrainz.org/search?query=rights+society+societiestype=annotationlimit=25method=indexed and Discogs already stores this info, e.g. http://www.discogs.com/release/420251 This proposal is for a new label type Rights Society and a relationship between labels and releases, which will give the existing entries a real meaning and also give us a more structured way to enter rights society information. Wiki page for the relationship: http://wiki.musicbrainz.org/User:Nikki/Rights_society_relationship Ticket: http://tickets.musicbrainz.org/browse/STYLE-209 Expected RFV date: 17th of April Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC2 STYLE-121: Track numbering
Am 21.03.13 17:33, schrieb Alex Mauer: On 03/07/2013 05:33 PM, Alex Mauer wrote: After a long interval, I am reviving the RFC for STYLE-121, track numbering. Ticket: http://tickets.musicbrainz.org/browse/STYLE-121 Proposal: http://wiki.musicbrainz.org/?title=User:Hawke/Proposal/Track_numbering Expiration: 2013-03-14 Is anyone willing to give this a new +1, with the removal of the of the line regarding how to handle sides with only a single track (A1 vs. just A) I'm still willing to give it a -1 while it contains the bit about alternate audio tracks. As you're already aware, I disagree that your proposal is the best way to handle those and your proposal also breaks disc IDs, so I certainly disagree with making it an official guideline. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Update artist sortname guidelines to clarify that alias sortnames don't need to be latin
The RFC got multiple +1s, so here's the RFV. Expected expiration date: 2013-02-03 Wiki page - http://wiki.musicbrainz.org/User:Nikki/Aliases Jira ticket - http://tickets.musicbrainz.org/browse/STYLE-179 RFC thread: http://musicbrainz.1054305.n4.nabble.com/RFC-Update-artist-sortname-guidelines-to-clarify-that-alias-sortnames-don-t-need-to-be-latin-td4646828.html Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Chinese releases
Am 21.01.13 10:46, schrieb jesus2099: nikki the problem with without-space is that you have to define which composed words will come without-space and which won’t. Putting space everywhere looks more like the style of original writing in the sense as it is more systematic too. Just my quick thought, foreseeing possible discussions like « hey I would not have split this word but would have split this one » kind of discussions between an editor who thinks weekend shouldn’t split but Jesus Christ should but the other editor thinks JesusChrist and week end. You see? Word spacing is a problem with Japanese too. Nobody has proposed to solve that by writing spaces between every character instead. In fact, Japanese pseudo-releases are rather common but I don't remember seeing any arguments about what is/isn't a word. I have no reason to believe Chinese would be any different. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Chinese releases
Am 17.01.13 12:00, schrieb CARO REPETTO, RAFAEL: 2. For the transliteration of titles and tracks, and since there is no official consensus about it, we are planning to transliterate every single hanzi separately: 音乐 = yīn yuè, and not yīnyuè. As for capitals in titles and tracks, we think that only first syllables in the phrase, and those for proper names for people and places should be in capitals. I wouldn't call myself a Chinese speaker, but I would rather see words written without spaces (i.e. yīnyuè). I'm not aware of anything that says the proper way to write pinyin is with spaces between every syllable... What you proposed for capitalisation matches what we have on https://musicbrainz.org/doc/Style/Language/Chinese, so that's fine. 3. There are some Chinese traditional music instruments, basic for Beijing Opera, that doesn't appear in the Instrument Tree, like 板鼓, or that appear with an inconsistent format, like jing hú, èrhú, zhonghu, or Moon lute. We suggest to establish a consistent format for all the Chinese traditional instruments: always in pinyin (avoid translations!), writtentogether, and without tone marks: jinghu, erhu, zhonghu, yueqin. Translations, tone marks and further information can be added in the description of the instrument. I agree that that would make sense to write the names consistently and I've been wondering whether to change èrhú to erhu for a while already. I went ahead and changed erhu, jinghu, sanxian and yangqin so that it's more consistent, but I want to look at moon lute a bit more closely before I change that. Were there any others? Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Update artist sortname guidelines to clarify that alias sortnames don't need to be latin
The whole reason I asked for alias sortnames was because we had no way to store Japanese sortnames. The main artist sortname should still be latin for compatibility reasons, but the alias sortnames were intended to use the appropriate script. This change is designed to clarify that alias sortnames should use the appropriate script. I changed a few other things while I was at it: I replaced last name with family name and first name with given name. I think that clarifies what we intend there a bit. First/last name is a bit vague for names where the family name is written first (e.g. Hungarian or East Asian names). I also tried to remove the bits which didn't really apply to many artists to try and simplify the guidelines a bit (they're guidelines, not rules, after all). - The bit about stylistic ligatures in #7 doesn't apply to a single artist. The bit about non-stylistic ligatures seems clear enough from #5. - #8 only applies to 13 artists. - I merged exception 1 into #4. I'm not sure how many artists that really applies to, but it doesn't seem significant enough to need two sections. - Exception 2 only applies to two artists. Wiki page - http://wiki.musicbrainz.org/User:Nikki/Aliases Jira ticket - http://tickets.musicbrainz.org/browse/STYLE-179 Expected expiration date: 2013-01-25 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] STYLE-177, add Digital Download to medium formats.
-1 from me. Digital media was originally added for downloads and is almost exclusively used for downloads. It's our second most common format, so adding a new format will mean we end up needing to migrate tens of thousands of releases for very questionable benefits. Using it for non-downloads is far from being a standard practice. The hierarchy might suggest that's our preferred way to interpret it, but the hierarchy never went through the style list. IMO digital media *is* digital download. I don't think it should be used for non-downloads (the examples I've been shown so far I would put under CD or Other). I would rather see that part of the hierarchy flattened. Nikki Am 07.01.13 20:42, schrieb Kuno Woudt: Hello, This proposal is for adding a Digital Download option in the medium format list, under the Digital Media entry. (so at the same level as USB Flash Drive). I will quote what Alastair said on the ticket: There is no explicit medium format for digital downloads. They seem to have to be bundled in 'Digital media', which also encompasses things like USB keys. It'd be nice to specifically indicate that a medium was downloaded. http://tickets.musicbrainz.org/browse/STYLE-177 -- kuno / warp. ps. I guess http://wiki.musicbrainz.org/Release/Format is the only relevant page on the wiki, I don't know how useful that page is but the value should be added there if this passes. ___ 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] RFC STYLE-163: deprecate [dialogue] artist
I think this proposal goes a bit too far. It doesn't seem to take into account the non-soundtrack usages of [dialogue] and seems to imply that we should invent artist credits. The current guideline gives us a way to mark non-music tracks on what is otherwise a music release, which will be lost if this passes. I find that useful and I'd be interested in knowing how you'd suggest I filter out those tracks if this were to pass. I've used it and seen other people use it for tracks which contain bits of conversation (often on live releases, but not always) which are not credited to anyone at all on the release. Since we're talking about artist credits here and no artists are credited, I think [dialogue] works perfectly well for these. If we can figure out who is talking, then we already have relationships to capture that information, we don't need to invent artist credits for it. I would be less opposed to changing it so that it's only used for uncredited tracks and if the track is actually credited to someone, they go in the artist credit, but I don't see any need to get rid of [dialogue] entirely and I don't see any benefit to merging it into [unknown] either. Nikki Am 13.11.12 18:37, schrieb Alex Mauer: This RFC is to move the [dialogue] artist guidelines, and move it to the “subset of unknown” section. The guideline appears to be obsolete after NGS since we have Artist Credits. The RFC will expire 2012-11-20. It was previously discussed on this list, under the topic “Deprecate [dialogue] artist?” http://tickets.musicbrainz.org/browse/STYLE-163 ___ 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] RFV: Officially deprecate the cover art relationship
It's been 48 hours without a veto, so this has passed. Nikki On 8 November 2012 02:37, Nikki aei...@gmail.com wrote: On 7 November 2012 09:29, Staffan Vilcans lift...@interface1.net wrote: Perhaps depend on http://tickets.musicbrainz.org/browse/MBS-4641 as well to make it easier to add cover art. I definitely agree that that would be nice to have (I already voted for it :)), but I don't think it should be a dependency of this proposal unless we have a reason to believe a lot of people are preferring to add covers using the cover art relationship rather than the CAA because they only have to paste a URL for the cover art relationship. That's not the conclusion I would come to looking at the numbers[1] though, since the number of CAA uploads completely dwarfs the number of new cover art relationships. Nikki [1] In the last eight weeks, according to the edit search: - 21 open/accepted edits to add cover art relationships (2 or 3 per week) - 27,972 open/accepted edits to add images to the CAA (~4,000 per week) - 4,897 open/accepted edits to add Amazon links (~610 per week) i.e. for every single new cover art relationship, ~1,330 CAA images and ~230 ASINs are added. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Officially deprecate the cover art relationship
From the RFC: Now that we've officially released the Cover Art Archive, I'd like to propose that we also officially deprecate the cover art relationship. The existing relationships can stay of course until covers have been added to the Cover Art Archive, it would just mean that no new relationships could be added. It would also not affect the Amazon relationship. As far as I can tell, the concerns that were brought up were already addressed. In particular, as Nicolás mentioned, people are not actually using the cover art relationship to add GIFs and PNGs and support for them in the Cover Art Archive is already planned. Ticket: http://tickets.musicbrainz.org/browse/STYLE-158 Expected expiration date: 2012-11-08 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Officially deprecate the cover art relationship
Now that we've officially released the Cover Art Archive, I'd like to propose that we also officially deprecate the cover art relationship. The existing relationships can stay of course until covers have been added to the Cover Art Archive, it would just mean that no new relationships could be added. It would also not affect the Amazon relationship. There aren't many new cover art relationships being added these days (if there ever were) - just 18 open/applied in the last 8 weeks and all except one is for CD Baby. Most CD Baby releases are also available (with bigger images) on Amazon anyway. The cover art relationship is also problematic because we have no control over external sites - http://musicbrainz.org/edit/19322606 is a perfect recent example of that. Deprecating the relationship would reduce the number of ways cover art can be added, making it less confusing for users, easier for us (both users and developers) to maintain and easier to work with for other developers wanting access our cover art. Ticket: http://tickets.musicbrainz.org/browse/STYLE-158 Expected expiration date: 2012-11-05 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add inlay to the album art types
David Gasaway wrote: Ah, my bad. :) But if the intention is to add the new type for *only* the front/inside then using the term inlay is going to confuse people (as it did me), since the whole thing is the inlay by my understanding. I had a similar conversation with someone else - http://musicbrainz.org/edit/17771863 It seems some people use inlay to mean the entire thing while most people (from what I've seen) use it to mean specifically the inside part. With that in mind, maybe something like Inlay (inside tray) would be better? Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add inlay to the album art types
David Gasaway wrote: On Thu, Jun 7, 2012 at 12:21 PM, Nikki aei...@gmail.com wrote: It seems some people use inlay to mean the entire thing while most people (from what I've seen) use it to mean specifically the inside part. With that in mind, maybe something like Inlay (inside tray) would be better? Technically, it's behind the media tray, not inside it. By that, I actually meant the inside part, not inside the actual tray. I hadn't noticed you could read it differently. :) Extra-bonus points if the Types page explicitly mentions Back+Spine. By my count, you have to follow three links to get from a Cover Art edit to that how-to page that only mentions this in passing. (Yes, the description for Spine says that it's usually part of the back cover scan, but I initially took this to mean that I should *only* select Back for such a scan.) We can/should just edit the definition of Back to mention that it will often need to be combined with Spine for jewel case scans, since it's so common. Although it wouldn't hurt to mention in the definition of Inlay that the other side is (normally) Back+Spine. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-114: Soundtrack style
I'm not happy with the separators for artist credits *always* being comma (comma ...) ampersand. Punctuation varies by language and script, so what works fine for your Western soundtracks will look horribly unnatural in other places. Japanese, for example, doesn't write lists in that way, so I wouldn't want to see that style forced on a list of Japanese names (unless transliterated). I believe Chinese is the same, although foolip would be a better person to ask about that. It also doesn't seem to take into account recordings which already have an artist credit for the performer, e.g. because they appear on other releases or because the track is already credited to the performer. In those cases, I would expect the recording artist credit to remain unchanged. Alex Mauer wrote: This is the RFC for a new Soundtrack style guideline. This proposal is to make soundtrack style official, and similar to the newer Classical guidelines. It also documents existing practice for soundtrack works. Significant points: * details on show or film go in the disambiguation comment — e.g. the name is “Main Titles”, other information is not part of the title. From the proposal, it seems like *any* song which ever appears on a soundtrack ends up with stuff added to the work disambiguation comment. I don't like that, but I'm afraid I can't really explain properly why it feels wrong. It just doesn't feel like the right place for the info (except when it is actually disambiguating two similar works), especially when the proposal explicitly says you can create a work for the whole soundtrack. That seems more appropriate and easier to maintain. Things I’m still not totally happy with: “roles”: where the song has a descriptive name for its position/purpose in the soundtrack: “love theme”, “main theme”. For some stuff it seems like it would work better in the title somehow. This works well: * Imperial March (Darth Vader’s Theme) [Star Wars, Episode V: The Empire Trikes Back] This doesn’t: * Boss of Me (theme) [Malcolm in the Middle] Suggestions here are more than welcome. I’m also not too happy about the word “role”, so other ideas would be good. As I was reading the proposal (before reading this email), I thought it would surely make more sense to put the name of the thing it's from in the title when it's only a descriptive title like Main Title... Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
I was wondering about that actually. How do Chinese speakers normally sort Chinese names? Nikki Philip Jägenstedt wrote: On Wed, May 2, 2012 at 7:28 PM, caller#6 meatbyproduct-musicbra...@yahoo.com wrote: Hi all, as discussed recently[1], there are a few problems with the logic of sort names. I'd like to identify them before starting in on a guideline revision. I haven't read all of the previous thread(s) on this topic so I'm not sure what kind of solution you're consider, but if you're looking for problems, Chinese artists have them. For Chinese, the sort name is in fact Latin-script name with added commas and is not at all useful for sorting. I have to set up Picard to use the artist name as the sort name, since Unicode order at least keeps similarly named artists together. Examples: These 3 artists with the same family name (周) end up in 3 different places because of the different romanization systems used on the mainland, in Taiwan and in Hong Kong: 周杰倫 Chou, Jay 周潤發 Chow, Yun-Fat 周迅 Zhou, Xun Here's a sample of groups with random sort order: 水木年华 Age of Water and Wood 壞女兒 Bad Daughter 黑名單工作室 Black List Studio 董事長樂團 Chairman 冷血动物 Cold Blooded Animal 冷酷仙境 Cold Fairyland 可米小子 Comic Boyz 深白色2人組 Deep White 飛輪海 Fahrenheit 鐵竹堂 Iron Bamboo 五月天 Mayday 南拳媽媽 Nan Quan Mama 自然捲 Natural Q 新裤子 New Pants 團契遊樂園 Playground 動力火車 Power Station 果味VC Super VC 超级市场 Supermarket 女子十二乐坊 Twelve Girls Band I image that any non-Latin script would have the same problems, at least those with multiple romanization systems or where the romanization does not produce the correct order anyway. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
jacobbrett wrote: Another issue, which (at this point) just requires guidelines, is sorting of names that use phrases such as de la ([First name] de la [Surname]) and von. Might they sort as [Surname], [First name] [Phrase] or [Surname] [Phrase], [First name] and does the expression differ in different cultures? How they sort depends on the language/country. As far as Dutch is concerned, we currently use Bar, van, Foo. http://wiki.musicbrainz.org/Talk:Style/Artist/Sort_Name http://musicbrainz.1054305.n4.nabble.com/Sortingorder-Dutch-tussenvoegsel-td1088511.html Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
Calvin Walton wrote: I think that a future goal for some schema-change release should be to have per-locale sort names. In this case, The Doors would get sort names like: English: Doors, The Turkish: The Doors Japanese: ドアーズ The next schema change (due on the 15th) will include extra attributes for aliases so that we can capture information like that. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
Kuno Woudt wrote: When dealing with names which are already in the correct order, e.g. Lee Jung Hyun: http://musicbrainz.org/release/119fe913-acca-4931-8e6e-47e22a933cba/cover-art I'm always inclined to just copy the name, as it already would sort correctly. But perhaps I should add a comma anyway, so: name: Lee Jung Hyun, sort-name: Lee, Jung Hyun I think the comma should be there. Even though the name is already in the right order, we don't know which part is the surname, so if someone wants to group names together by surname, they can't. (picard used to be able to use the sort name as a translated name, which would've been a reason to leave the comma off to prevent picard from swapping names which are already in the correct order -- does picard still do that?). The option is still there but has been updated for NGS. It first looks for an alias with the correct locale. If there isn't anything usable, it falls back to reversing the sortname. Korean artists tend to use the family name, given name order even when writing their names in latin script. With japanese artists I've seen both (given name, family name seems a bit more common than family name, given name). If picard still does the swapping, I'd be inclined to write Koda Kumi without a comma, because she doesn't use Kumi Koda on album covers so the names shouldn't be swapped, but add Hamasaki, Ayumi with comma, because she does generally use Ayumi Hamasaki on album covers. See the previous comment. You should use aliases to specify the correct name. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC2-320: Revised Sort Name Style - identifying the problems that need fixing
practik wrote: 4. Using comma as a delimiter can give unexpected results. The reason for this is that space sorts before comma Maybe put a space before the comma too? If we need something starting with a space, I'd be more in favour of / . Space comma space looks very weird/unnatural to me and it's also very similar to the current separator. I think if we went with space-comma-space, people would keep trying to change the sortnames back to what we use now because it actually just looks like a mistake/bug. If we change the separator, we will need to update all of the existing sortnames, fix guess case and teach people about the new separator anyway, so there's no reason we would need to keep using a comma. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] TuneCore song IDs
Nicolás Tamargo de Eguren wrote: It is possible by blocking all ISRCs that start with TC, with the problem that it would also block ISRCs from the Turks and Caicos. Which admittedly, being a region with 45k inhabitants, are probably fairly rare. According to http://www.gearslutz.com/board/7354919-post78.html We cannot now issue registrants in the Turks and Caicos with the correct country code because Tunecore has polluted that part of the country code namespace. That sounds like they are not actually giving people in the Turks and Caicos codes starting with TC. There is also an email address in that post - someone could email them asking if they can confirm that there are no valid ISRCs starting with TC. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Founder of a group
Rupert Swarbrick wrote: Your description of a creator doesn't fit many band-like groups I can think of but, as I said, I don't really know anything about NMB48. It's the same sort of way that a number of western pop groups like Boyzone [1], Steps [2], Take That [3] or the Spice Girls [4] were created (I'm sure there are more recent examples, but it's been a long time since I paid any attention to them :P), if that helps. Nikki Quotes from the relevant Wikipedia pages: [1] In 1993 an advertisement appeared in many Irish newspapers calling for auditions to form a new Irish boy band group. The advertisements were sent out by theatrical manager Walsh who was looking to make an Irish Take That following on from their success. [2] Steps were formed by Steve Crosby Barry Upton (writers of 5, 6, 7, 8) alongside Manager Tim Byrne after auditioning hopefuls who answered an ad in The Stage newspaper. [3] In 1989, Nigel Martin-Smith sought to create a British male vocal singing group. Martin-Smith's vision, however, was a teen orientated group that would aim across more than one demographic segment of the music industry. [4] In the mid-1990s, father-and-son management team Bob and Chris Herbert set about creating an all female group to compete with popular boy bands that dominated the pop music scene in the mid- to late-1990s ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Founder of a group
Rupert Swarbrick wrote: Nikki aei...@gmail.com writes: Hello, Prompted by http://musicbrainz.org/edit/17114614, I'm wondering what other people think the definition of a founder is - is it simply any of the original members of the group, or specifically the person/people who decided to create the group? If you think it's the latter definition, does anything change (for cases like that edit) when the person who decided to create the group was never actually a member themselves? (The members were chosen by auditions) Well, people talk of founding members for organisations / societies and just mean members that were there from the start. This is the meaning I always attached to the relation. How does that apply to this case? By start, does that mean when the creator decided to create a group, gave it a name and started organising auditions for members (i.e. there were no members at the start and therefore no founding members) or when the auditions were over and the members had been selected (i.e. there were members at the start and therefore the first set of members selected from the audition become the founding members)? I could understand your answer both ways... Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Founder of a group
Hello, Prompted by http://musicbrainz.org/edit/17114614, I'm wondering what other people think the definition of a founder is - is it simply any of the original members of the group, or specifically the person/people who decided to create the group? If you think it's the latter definition, does anything change (for cases like that edit) when the person who decided to create the group was never actually a member themselves? (The members were chosen by auditions) Someone asked a similar question a couple of years ago, but only got one response - http://musicbrainz.1054305.n4.nabble.com/Founder-of-a-band-relationship-type-td1837775.html - so I'm trying again in the hope of getting a slightly larger response this time. ;) Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-102: Change Performance Relationship Type to Recording Relationship Type
Philip Jägenstedt wrote: On Wed, Mar 28, 2012 at 00:22, Nikki aei...@gmail.com wrote: Note that we're not allowed to rename relationships, so the actual name of the relationship type will need to remain as performance. The link phrases can be updated of course. Do you mean that the names in the XML Web service mustn't change, or even what the dropdown box in our UI says? If only a part of what is visible to users is changed I think that the inconsistency is worse than the problem it fixes. The former (the dropdowns use the link phrases, hence all the curly brackets). The name is shown on http://musicbrainz.org/admin/linktype/recording-work however. I really don't see the point in changing the class, but since I think we should get rid of the whole class concept (whatever it even is) anyway, I don't care enough to argue against it. Can you elaborate on this? Is it recordings we shouldn't have, or a separation between different kinds of recordings? Hmm? The class is just a category in the wiki with a special name. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-102: Change Performance Relationship Type to Recording Relationship Type
Note that we're not allowed to rename relationships, so the actual name of the relationship type will need to remain as performance. The link phrases can be updated of course. I really don't see the point in changing the class, but since I think we should get rid of the whole class concept (whatever it even is) anyway, I don't care enough to argue against it. Nikki practik wrote: OK, here it is at last: The Performance Relationship Type identifies separate recordings of the same work as separate performances of it, though in reality they may not be. Also, it's listed as part of the Performance Relationship Class, but it doesn't fit the class description and has nothing in common with the other relationships in that class. I propose changing the Performance Relationship Type to a Recording Relationship Type and placing it in a more appropriate class. Details in Jira: http://tickets.musicbrainz.org/browse/STYLE-102 Previous discussion: http://forums.musicbrainz.org/viewtopic.php?pid=17589 http://lists.musicbrainz.org/pipermail/musicbrainz-style/2012-March/014842.html Expiration date: 2012-03-29 Did I leave anything out? -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-102-Change-Performance-Relationship-Type-to-Recording-Relationship-Type-tp4496712p4496712.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ 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] RFC STYLE-97: Move medley to an attribute of performance of
Alex Mauer wrote: On 03/09/2012 02:00 PM, Nikki wrote: There already is a work-work medley relationship, so that page needs to be updated too and the text you're referring to won't go away just by getting rid of the recording-work relationship. I don’t see a need to change that, as we don’t have a “performance of” work-work relationship and I can’t see a way that would work very well. http://wiki.musicbrainz.org/Medley_Relationship_Type will still need updating though, because part of your proposal is remove one of the relationship types. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of performance of
Alex Mauer wrote: On 03/09/2012 01:25 PM, practik wrote: Alex Mauer wrote These all agree with my understanding of the attributes as they’d be used with medley. Would specifying the join phrases not be part of the change proposal? I was assuming it would be. Sorry if I went off-topic there. I expect it would be, but I'm not sure that join phrases can be as dynamic as it looks like you were suggesting. Perhaps one of the developers can comment on that? Could you clarify which join phrases you're asking about? Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of performance of
Alex Mauer wrote: Interesting point. I would expect that in such a case the medley itself would be a new work, and we’d need to have a work-work “medley of” relationship. [snip] Good idea, but I’m not sure how that will work with the display system. It may just have to be “medley performances:”, which I think is suitably non-specific while still getting the meaning across. I expect “referred to in medley” would go away in any case. There already is a work-work medley relationship, so that page needs to be updated too and the text you're referring to won't go away just by getting rid of the recording-work relationship. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-358: Allow links to video channels on sites other than Youtube
It's been more than 48 hours with no objections, so this has passed. Nikki Calvin Walton wrote: Since I've finally gotten a +1, and the RFC period has long-passed, here's the RFV! With the standard 2-day RFV, this will expire on March 1, 18:00 UTC. This will add a new artist-url and label-url relationship, Video Channel, to allow linking an artist or label to their channel on a video streaming site like ustream, dailymotion, nicovideo, vimeo, etc. The existing 'Youtube' relationship will become a subtype of this relationship, as it can't be removed or merged without causing incompatibilities for API/data users. Proposal page: http://wiki.musicbrainz.org/Proposal:Allow_links_to_video_channels_on_sites_other_than_Youtube Relationship page: http://wiki.musicbrainz.org/User:Kepstin/Video_Channel_Relationship_Type ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-359: Allow links to video channels on sites other than Youtube
Hm, no +1s from anyone else? Then +1 from me. It's been long enough that you should be able to send an RFV when you're ready. Nikki Calvin Walton wrote: Was RFC-358 - renumbered due to conflicts. Please continue any discussion in this thread! I have made some of the updates suggested by nikki. In particular: * The list of URLs is now in the proposal page, and will be added to Style/Relationships/URLs if the proposal passes. * The wording of the description has been updated - now it's videos curated by the entity, rather than videos published by the entity. This means that things like an artist-curated list of bootleg recordings are allowed - and automatically-generated playlists aren't. At the moment, I'm still waiting to hear back from nikki about whether this would be best as a new AR or as a modification of the Youtube AR; either way the final guidelines will be the same. Please tell me what you think! Proposal page: http://wiki.musicbrainz.org/Proposal:Allow_links_to_video_channels_on_sites_other_than_Youtube Relationship page: http://wiki.musicbrainz.org/User:Kepstin/Video_Channel_Relationship_Type ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-351. auto-cleaning discogs URL
By the way, please make a new thread for RFVs in future. Replying to the RFC thread makes it very easy for people to miss the RFV. Nikki jesus2099 wrote: This goes to RFV today, by popular demand. *RFV-351* http://tickets.musicbrainz.org/browse/MBS-4044 http://musicbrainz.1054305.n4.nabble.com/RFC-351-auto-cleaning-discogs-URL-tp4364085p4364085.html http://wiki.musicbrainz.org/Proposals/History#RFC-351._auto-cleaning_discogs_URL - jesus2099 × Ti = Tristan + patate12 ÷ saucisson7 mb : http://musicbrainz.org/user/jesus2099 mb userscripts : http://userscripts.org/users/31010/scripts IMPORTANT : hta3s836gzac...@jetable.org is a fake e-mail, I don’t receive anything in this (you can contact me through the mb link above). -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-351-auto-cleaning-discogs-URL-tp4364085p4413240.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ 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] RFV-351. auto-cleaning discogs URL
jesus2099 wrote: I like having everythingin one place but I renamed the title. Apparently things are not really clear when using an ML. ;p Wasn’t the title RFV, as on nabble, when you received those ? Yes, but since you replied to an existing email, some clients (including mine) will put it as a reply to the existing email, deep in the middle of a thread. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-346. Style/Language/Vietnamese : Punctuation change
Philip Jägenstedt wrote: Consistency is, IMHO, one of the most valuable aspects of the MB database, and I do not see why this issue should be treated any differently from similar issues like capitalization, abbreviations, etc. In these areas you will find diversity in the wild, but we still have style guidelines. There are also plenty of (much more common) things we don't standardise though and yet they're not seen as a big problem. I don't see any particular *need* to standardise this. It affects a tiny amount of data edited by a tiny number of people and neither style appears to be incorrect anyway. Practically, if you and I look at the same cover scan and have different preferences, in 20% of the cases we will disagree if there is a space there or not. How should such editing conflicts be resolved? That http://wiki.musicbrainz.org/User:jesus2099/Style/Language/Vietnamese#Examples tries to distinguish between 3 different forms (no, narrow and full space) only makes this problem worse. I agree that trying to distinguish between three different forms is problematic (e.g. I don't agree that the space in the second example is narrow). There are however cases where I think we would all agree there is a space on the cover. For cases where it's debatable, we have a voting system. If deemed necessary, I can ask my wife (currently in Hanoi) to contact the ministry of education and ask what style is considered correct in higher education. It's possible that they don't know or care, of course. I leave it as an exercise to the reader to check what style they use on their website http://www.moet.gov.vn/. Although I suspect the answer is that they don't know or care, I would certainly be interested in knowing what they have to say about it, if she'd be willing to ask. At this point I hope that our style leader will interrupt us. Tristan and I have debated this for over 3 years and still don't agree, so this issue will clearly not be resolved by us alone. Style leader*s*. There's still two of us. ;) My summary: There are two people who currently care about the problem. One prefers spaces before the punctuation in question. One prefers no spaces before the punctuation in question. There are very few people editing Vietnamese in general. There are no known native Vietnamese speakers editing (if there are, I don't know who they are :)). There appears to be no official style. Both styles are found both in print and online. We do not know why both styles are used (whether it's generational, regional or simply personal preference). The proportions vary depending on the material being looked at, but the no space style seems to be more common. Both styles are (unsurprisingly) found on CD covers. The number of Vietnamese releases in general is still rather low. The number of releases this affects is tiny (~30). My conclusions: There are not enough people who care to come to a majority decision about which way to standardise it. There are not enough people who care about the issue to maintain the data according to such a guideline anyway. There is not enough data affected to make standardisation particularly useful right now. Therefore I think the best choice right now is a compromise, i.e. to allow both forms, which is effectively what this proposal is. If the authorities in Vietnam ever publish an official style (something which explicitly talks about how to write punctuation) or if we ever have a community of Vietnamese editors who care about which style should be used, then that would be a better time to revisit it. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of performance of
Alex Mauer wrote:
On 02/21/2012 11:30 PM, Nikki wrote:
Currently the displayed phrase is {partial} {live} {instrumental}
{cover} performance of, where would medley go in here?
Probably the new join phrase should be “{partial} {live} {instrumental}
{cover} {performance|medley} of”. Though it seems to me that join
phrases are much less used now, with the “short join phrase” such as
“performances:” being used instead — where is the longer join phrase
still used?
It's not actually relevant since all three join phrases contain the
attributes, but as far as I know the long phrase is only used when
displaying edits. The raw long phrase is also shown in the dropdown
when adding/editing a relationship but there it's ugly as hell no matter
where you put the attributes.
I actually listed one of the short phrases, the long phrase contains is a.
Nikki
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-97: Move medley to an attribute of performance of
http://wiki.musicbrainz.org/Medley_Relationship_Type will also need
updating if the separate recording-work relationship goes away.
Currently the displayed phrase is {partial} {live} {instrumental}
{cover} performance of, where would medley go in here?
This will require one of the devs to write a conversion script, so it
may take some time to be implemented. An alternative would be to add the
attributes to the existing medley relationship.
Alex Mauer wrote:
Expiration: 2012-02-28
This RFC is to move the “medley” relationship to an attribute of the
“performance of” relatonship.
More details in jira, http://tickets.musicbrainz.org/browse/STYLE-97
This was not previously discussed.
You were discussing it on IRC:
http://chatlogs.musicbrainz.org/musicbrainz/2012/2012-02/2012-02-21.html#T22-24-38-528382
At one point there was a discussion about whether partial should be
used or not which may be something people here want to consider.
Nikki
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-345: Extend License Relationship to recordings
It's been more than 48 hours with no objections, so this has passed. Nikki Johannes Weißl wrote: Hello, this is the RFV for proposal 345, to extend the License Relationship to recordings. This is necessary to specify the license for standalone recordings or for mixed-license releases. The proposal is to replace the current wiki page [1] with this one: http://wiki.musicbrainz.org/User:hrglgrmpf/License_Relationship_Type [1] http://musicbrainz.org/doc/License_Relationship_Type Wiki page: http://wiki.musicbrainz.org/Proposal:Extend_License_Relationship_To_Recordings Expiration date: Sat, 18 Feb 2012 18:00:00 UTC Johannes ___ 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] RFC-346. Style/Language/Vietnamese : Punctuation change
It's been a lot more than a few days, you might want to send the RFV now. Nikki jesus2099 wrote: Thanks very much Réo ! I never know if it’s correct to hotlink pics… I will make the RFV email in a day or two… or in a few days. ;) Tristan. - jesus2099 × Ti = Tristan + patate12 ÷ saucisson7 mb : http://musicbrainz.org/user/jesus2099 mb userscripts : http://userscripts.org/users/31010/scripts IMPORTANT : hta3s836gzac...@jetable.org is a fake e-mail, I don’t receive anything in this. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-346-Style-Language-Vietnamese-Punctuation-change-tp4226419p4373497.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ 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] RFC-351 auto-cleaning discogs URL
It's been more than a week and nobody seems to disagree, so feel free to send the RFV now. Nikki jesus2099 wrote: Hello there, However I think it is overly overkill bureaucracy to make a RFC just for that. If anyone has any comments against auto-cleaning the discogs URL in the following way, please say so. :) discogs URL auto-cleaning (by the same javascript that’s cleaning other URL) : **REMOVE ALL THE QUERY PARAMETERS from the URL and leave it as only minimal address with www. sub-domain.** Guideline text would become (please someone fix my english) : « Always use the domain www.discogs.com. The subdomains for genres like techno.discogs.com lead to artist pages that only contain the releases of this genre so you don't get the full discography. **In the same spirit, don’t restrict the page by letting query parameters (like “anv=*”) in the discogs URL.** » Examples : http://discogs.com/artist/Teresa+Teng?anv=%E9%84%A7%E9%BA%97%E5%90%9B becomes http://discogs.com/artist/Teresa+Teng http://rock.discogs.com/artist/陰陽座?anv=WTFtoto=OMFG becomes http://www.discogs.com/artist/陰陽座 http://discogs.com/artist/Ajico?remove=thiscrap=now becomes http://www.discogs.com/artist/Ajico Have a nice day, Tristan. - jesus2099 × Ti = Tristan + patate12 ÷ saucisson7 mb : http://musicbrainz.org/user/jesus2099 mb userscripts : http://userscripts.org/users/31010/scripts IMPORTANT : hta3s836gzac...@jetable.org is a fake e-mail, I don’t receive anything in this. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-351-auto-cleaning-discogs-URL-tp4364085p4364085.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ 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] RFV-348: CSG Recording/Artist Credits
SwissChris wrote: a) which of the following solutions would you prefer? b) which of the options would you veto (if any) and why? 1) Track Artist = Recording Artist = Composer + important/featured performers 1), as said again and again, is bad: mixing composers and performers in the same field with a complex syntax is error prone and discouraging new editors (and simply wrong from a DB-structure point of view). How is it wrong from a DB-structure point of view? The artist credits are for artists credited regardless of the role they played. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-351 auto-cleaning discogs URL
Johannes Weißl wrote: I give two reasons for my approval: * The information that two MusicBrainz entities link to the same Discogs URL is very valuable, and we get it only by normalizing the URL * The anv= parameter doesn't work in cases where there are multiple similar variations, e.g. consider we have two artists Réne and Réne Doe, while Discogs has only Réne Doe, linking to anv=Réne doesn't show us possible releases with anv=Rene (that would be listed under our Réne artist). Two more: * It makes it easier for people to enter, as they can just paste the URL and have it cleaned up automatically (it's quite common for people to accidentally link Foo Bar to Foo Bar?anv=Foo because Discogs doesn't make it obvious how to get a link to the main entity page) * It makes the URLs more stable - the vast majority of the ANV links we have right now are broken because Discogs changed the way they work. So +1 from me too for removing that stuff from the URLs. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-348: CSG Recording/Artist Credits
Frederic Da Vitoria wrote: I feel that we are currently going nowhere on CSG, because there are too many differing views about what CSG should become now and we are trying to achieve perfection at once. I suggest that if we don't believe a proposal could destroy useful information and it goes in a generally correct direction, we should let it pass. After all SGs are modifiable. I really believe that we can't reach correct (I am not even saying perfect) rules from the beginning, this will have to be an incremental process with probably a few bad choices which we will have to correct later. The problem for me is that we have two proposals, one saying to use composers as track artists and another saying to use performers as recording artists. Is that really an improvement? In my opinion, it's not - it makes adding/editing classical releases a lot harder than it currently is. I don't particularly care whether composers and/or performers are used, but I saw all the complaints about having to edit recordings separately from tracks. Now we finally don't have to do that any more, but these proposals will take us straight back there again. It doesn't make sense to me. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-359: Allow links to video channels on sites other than Youtube
Calvin Walton wrote: Ok. So in this case, adding the new generic 'Video Channel' AR as the parent of the existing Youtube AR in the tree would be acceptable? Yes, that would be fine. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-348: Allow links to video channels on sites other than Youtube
Calvin Walton wrote: Since YouTube isn't the only video sharing site around by far, a lot of labels and artists are publishing their videos on sites such as Vimeo, Dailymotion, and Nico Nico Douga. But we don't currently have any way to link to these channels! My proposal is to generalize the current YouTube Relationship Type [1] to turn it into the awesome new Video Channel Relationship Type. I need to find out what I'm supposed to do when we want to generalise things like that, since I was told to never edit relationship names. I'll let you know once I find out. Would this relationship cover Ustream too? Does this mean YouTube playlists will now be OK? If so, how do we determine if they're official? If not, then it's not clear that they're not. The current description/guideline seems like it could be misunderstood as meaning as long as the videos themselves are official, the channel can be anyone's when it's the channel that we actually want to be official. I would personally prefer to just add the URLs to http://wiki.musicbrainz.org/Style/Relationships/URLs#Standardised_URLs and open tickets to standardise them where needed. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-359: Allow links to video channels on sites other than Youtube
Calvin Walton wrote: At the moment, I'm still waiting to hear back from nikki about whether this would be best as a new AR or as a modification of the Youtube AR; either way the final guidelines will be the same. Please tell me what you think! I've been told we should create a new relationship type. If we want to only have one, we can do that but we should still add a new relationship type and then have a script to migrate the existing ones. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-347: CSG update for NGS
Frederic Da Vitoria wrote: We will need at least a plug-in for Picard (if it is realizable by a plug-in). Probably, but not necessarily: the API could return the concatenation of the title and the comment. This may be a bad idea fr other reasons, but at least we should check. The API already returns the title and disambiguation comment separately. I think it's highly unlikely that we'll add a new field to return them combined since it's trivial for a program to do that itself. We can't just append it to the current name field because that changes the meaning of that field. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Add étude to the work type list
It's been more than 48 hours so this has passed. Nikki Nicolás Tamargo de Eguren wrote: See http://en.wikipedia.org/wiki/%C3%89tude (needed for, say, half the works of Chopin, for example) Since most people prefer étude and monxton doesn't strongly oppose it, I'm RFVing. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-347: CSG update for NGS
For those who weren't on IRC when we were talking about it, http://wiki.musicbrainz.org/User:Hawke/Proposal/CSG-mod#Keys has been updated to stop telling people to use the wrong capitalisation for things like German and Spanish. I noticed you changed the ASCII quotes to English-style quotes, even for the non-English examples, e.g. http://wiki.musicbrainz.org/User:Hawke/Proposal/CSG-mod#Common_names I think those should either remain language-independent ASCII quotes or they should be the appropriate Unicode quotes for the language. Since I seem to recall people arguing about what to do when there are multiple languages in a title (e.g. the fourth example), I'm commenting here where hopefully more people will see it. Nikki Alex Mauer wrote: This is RFC-347, expiring 2012-01-19. It updates the CSG for the NGS schema, without trying to do anything too ambitious (cf. CSGv2). http://wiki.musicbrainz.org/User:Hawke/Proposal/CSG-mod This draft has not been specifically discussed on IRC, though I have referred there to the new ideas expressed within many times. (see below) Much of the change is cosmetic (removing weird nested bullet-points, extraneous attention icons, emphasis, etc). It also reorganizes it a bit so as to be more guidelines and less a set of examples. It drops references some out of date things like “featuring artist style”, ConvertReleaseToMultipleArtistsEdit, and lots of CamelCasing. It adds references to new things like Works and Recordings, as well as Work Parts. The substantive changes are as follows: * The “title” section is defined in the Work description, and Track and Recording titles refer to that. * Since the CSG describes using the performers as a disambiguation (“as this is often the only way to distinguish between different releases of the same work.”), this proposal moves that to the disambiguation field in accordance with its intent. * For recordings, it recommends setting the Artist Credits to the performers. It uses the same wording as was used in the “disambiguation” artist-in-title of before, as far as which artists to include. This makes the performances list on the works page useful, because it doesn’t simply list every performance as being by the composer (in many cases long after the composer’s death) and also allows the recordings to show up on the performer’s Recordings tab. ___ 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] RFV: Add zarzuela to the type list
It's been 48 hours with no objections so this has passed. Nikki Nicolás Tamargo de Eguren wrote: I'd like to add zarzuela to the type list - this is not an opera, and it shouldn't be indicated as such.http://en.wikipedia.org/wiki/Zarzuela http://musicbrainz.org/tag/zarzuela/work-- 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] RFV: Add Symphonic poem to the work list
It's been 48 hours with no objections so this has passed. Nikki Nicolás Tamargo de Eguren wrote: See http://en.wikipedia.org/wiki/Symphonic_poem - I've entered a good amount of these and I'm probably not the only one, and none of the current types are correct for it. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add étude to the work type list
Frederic Da Vitoria wrote: So, what do people prefer here, Study or Étude? It's ready for RFV, except that I need to know what name to use! :) I prefer étude since that's what Wikipedia uses. All other work types are in English, aren't they (except for those which are almost exclusively used in one language)? If so I suggest that for consistency's sake we stick to English. Étude is in my Oxford English Dictionary. :) Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-319: Add warning about conductors/choir masters to Member of Band
Christmas and New Year have been and gone without any objections, so this has passed. Nikki Nicolás Tamargo de Eguren wrote: Hi! I am resurrecting an old RFC, because it seems to me that it makes sense. It adds the following paragraph to Member of Band RT: The conductor or chorus master of a group is almost never also a member of that same group. The Member of Band relationship should only ever be used to link a conductor or chorus master to the conducted group if that person is credited as a member of the group; it should never be assumed without such evidence. As I've seen this happen several times in the past, I would like to have it added so there's a guideline to point people about it. A logical next step would be, if we want to store this information, to add the Conductor and Choir Master artist-artist relationships that are also bitrotting on the wiki - but this is a start. http://wiki.musicbrainz.org/Member_of_Band_Relationship_Type http://wiki.musicbrainz.org/Proposal:Member_Of_Band_Relationship_Type_modification This should be applied on Sat, Dec 24, but with it being Christmas, let's keep it open until Mon, Dec 26. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Percussion and string instruments
Christmas and New Year have been and gone without any objections, so this has passed. Nikki Nikki wrote: I'm sending this on Simon's behalf who can't access his email at the moment. --- This is the request for veto for changing percussion instruments to percussion and string instruments to strings in the instrument attribute tree. In the RFC period there was one concern raised about the longer terms being more suitable if they were mostly used as grouping terms and rarely appear in credits but a database query revealed that they get used in credits quite a lot and from personal experience they usually get listed as the shorter variants. This RFV expires on the 24th of December. --- Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Percussion and string instruments
I'm sending this on Simon's behalf who can't access his email at the moment. --- This is the request for veto for changing percussion instruments to percussion and string instruments to strings in the instrument attribute tree. In the RFC period there was one concern raised about the longer terms being more suitable if they were mostly used as grouping terms and rarely appear in credits but a database query revealed that they get used in credits quite a lot and from personal experience they usually get listed as the shorter variants. This RFV expires on the 24th of December. --- Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-343: Add 歌詞タイム to Lyrics Whitelist
Calvin Walton wrote: Well, good news: I have contacted JASRAC, and they have verified that this site is properly licensed for displaying lyrics on the internet. As a result, Rob's given us the go-ahead for adding this AR now. Yep, this has now passed. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Confused by Style/Abbreviations
Nicolás Tamargo de Eguren wrote: So, I was looking once again at the guidelines for Vol. and ended in http://musicbrainz.org/doc/Style/Titles/Abbreviations - and I really don't get the point. I have never gotten the point, but I am tired of it so I thought I might as well ask. Does the rationale make sense for other people, and is it just me who doesn't get it? How does expanding vol. into the Spanish or the English word for it change its ambiguity and help with internationalisation issues? It still means exactly the same, and now if you want to match it automatically you need more searches than a simple Vol. I completely agree. The rationale doesn't make sense to me. I could understand if it said to use the expanded version when a track is inconsistently labelled or if an individual series is inconsistent... Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Genre support
Lukáš Lalinský wrote: The idea for now is just to define the genre lists and relations between them. It does not deal with the problem of assigning entities like artists to genres (I think that SoundUnwound has a nice solution to this though). Perhaps you should briefly explain their solution. :) Does any of this make sense? Do you think it's a good idea? I couldn't care less about genres personally so I can't really comment on the best way to implement it, but I know it's been requested by a lot of people and people already put genres in artist disambiguation comments so I don't see why we shouldn't have a real genre field if it's implemented in a decent way. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Add Multiple Scripts to scripts list
It's been more than 48 hours so this has passed. Nikki Nicolás Tamargo de Eguren wrote: Aaaand, I just was reminded I forgot to RFV this. We already have a Multiple Languages option, but we lack Multiple Scripts, which applies to several of the same places where we use multiple languages (it's not too strange to have Japanese scripts, Cyrillic or Arabic in the same release as Latin). So this is just asking for us to add that to the script list. For an example of a clear Multiple Scripts release, see http://musicbrainz.org/release/575f1987-e61c-49cb-8c95-92b6b42b6700 This will pass on Wed Dec 7 around 13:00 GMT. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Add Multiple Scripts support to Style/Release
Nicolás Tamargo de Eguren wrote: Jesus, I am not proposing to remove the *rest* of that paragraph, which reads however, as the Latin script is common in many languages that primarily use another script, Latin should only be chosen if there are no more than one or two titles (or a few characters) in other scripts. For example, a Japanese release with a mix of English and Japanese titles should normally use 'Japanese' as the script. This is exactly why changing the wording of something should have a wiki page with the new version. It's been more than 48 hours though so this has passed. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV2-340: Improve CC-license links
It's been more than 48 hours so this has passed. Nikki Johannes Weißl wrote: Hello, this is the second RFV to improve license links, by: 1. Introducing a new License Relationship Type 2. Obsoleting the Creative Commons Licensed Download 3. Providing a possibility to enter both download location and license at the same time (e.g. a drop-down list of some often used licenses to the Free Download and Paid Download Relationship) The only thing that has changed since the first RFV is the text of the AR and the generalization of the third point. Wiki page: http://wiki.musicbrainz.org/Proposal:Improve_CC-license_links Expiration date: Thu, 08 Dec 2011 10:00:00 UTC Johannes ___ 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] RFC2-340: Improve CC-license links
Jim DeLaHunt wrote: Oh, I get it. You are proposing text to be added to http://wiki.musicbrainz.org/Category:External_Information_Relationship_Class to describe the new License Relationship. I think the change to Category:External_Information_Relationship_Class should be another bullet point in the list at http://wiki.musicbrainz.org/Proposal:Improve_CC-license_links#Proposal . We're now up to 4 parts to the proposal. I agree this wording is fine for Category:External_Information_Relationship_Class . It's not complete, though. You also need to have some examples of the Relationship text, e.g. Release is licensed under URL . This shouldn't be necessary. The text on category pages is generated by a template. Also, you have an attribute description for License_Relationship_Type, and say it should be empty. I see that other Relationships in the External_Information_Relationship_Class also have an attribute description but say it should be empty. Does anybody know why we can't simply hide this attribute instead? It would be possible when adding a URL, but since URLs can be shared by multiple relationships, there's no easy way to prevent people from ever entering descriptions. A number of people think we should get rid of the field entirely: http://tickets.musicbrainz.org/browse/MBS-3791 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Remove Travel Agent Relationship Type
It's been more than 48 hours so this has passed. Nikki Nicolás Tamargo de Eguren wrote: Another not-truly-musical, pretty random relationship. Used a grand total of SIX times. I think it's pretty safe to merge this one into miscellaneous roles (and maybe extend that one to artist-RG, as it's not available at that level now) or just remove it completely. http://wiki.musicbrainz.org/Travel_Agent_Relationship_Type This will pass in two days - around Nov 26, 15:00 GMT ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Are string quartets chamber orchestras?
Rupert Swarbrick wrote: First, there's instrument, which presumably means someone incorrectly used the performed instrument relationship and didn't get work out how to put the magic vln/vln/vla/cello into the box... It's not actually possible to use the performed instrument relationship without an instrument, so they do actually have instruments set. It's just that the artist relationships page doesn't display attributes yet. There's a ticket at http://tickets.musicbrainz.org/browse/MBS-1117 Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording times
Oliver Charles wrote: Really you can put any value here, because recording duration is fairly meaningless. I think the most sensible might actually be the mode. But I'm in the camp of getting rid of it, too. We can't get rid of it entirely because it's needed for standalone recordings (and what would be shown on an artist's recordings page and in recording search results?). Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-340: Improve CC-license links
Johannes Weißl wrote: 3. Adding a drop-down list of some often used licenses (= license URLs) to the Free Download and Paid Download Relationship By this, do you mean it must be implemented this way and nothing else is acceptable, or just that it should be possible to 1) add download and license URLs at the same time and 2) have a way to select common licenses, *for example* by having a section that shows up when adding download relationships? If it's the former, I imagine it would make http://tickets.musicbrainz.org/browse/MBS-1468 a won't fix. If it's the latter, then that ticket could possibly be the easiest way to implement it. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging [silence] with different duration from different albums
MeinDummy wrote: Me too. But what are the side effects? E.g. will Picard set the compilation flag for a single artist album that contains silent tracks? How about tracklists? There is no reason not to apply the same rule there as well unless the side effects are different. It imagine it will if you change the track artist. I don't think it will if only the recording artist is changed. It would make sense to me to still use the release artist as the track artist for single artist releases so that a release with [silence] tracks remains a single artist release on the website and in Picard. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging [silence] with different duration from different albums
Johannes Weißl wrote: Hello, I know this has been discussed before [1], but has this ever been decided? Do we merge pure [silence] recordings from different albums with different duration? See http://musicbrainz.org/edit/15613386 http://musicbrainz.org/edit/15542655 I guess nobody (at least not now) wants to merge [silence] from different artists... I do :P Nikki [1] http://musicbrainz-mailing-lists.2986109.n2.nabble.com/silence-data-track-recordings-in-NGS-td6199874.html Johannes ___ 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] RFC-341 CSG Recording parts Relations
Lemire, Sebastien wrote: I propose here an RFC to create a hierarchy in recordings similar as we have in the works tables. It expires in 7 days on Novemer 24th 2011. Because I haven't thought the consequences through for non-classical music, this RFC only applies with CSG. The proposal can be found here: http://wiki.musicbrainz.org/Proposal:Recording_Parts_Relationship NOTE: This is the first time I created a wiki page (I shamelessly copied from the similar http://wiki.musicbrainz.org/Parts_Relationship_Type). Please feel 100% to make modifications to it or let me know what I need to modify, change or add. Since relationships are available for all types of music and can't just be restricted to CSG, I think the consequences for non-classical music need to also be considered. I'm not convinced that it should be a separate page from the existing parts relationship page and right now I'd prefer to see a single page which explains when to use which version. Some things I'm still not clear on: Do we expect people to create standalone recordings to represent the entire recording? Do we expect people to copy the part relationships already on works to recordings, or is this only for cases where the recordings would all be linked to the same work? I don't understand what the link to Performance_Relationship_Type is supposed to mean either. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Add orchestrator and instrumentation at recording level
It's been more than 48 hours, so this has passed. Nikki Nikki wrote: This proposal is to add orchestrator and instrumentation at recording level. The RFV should expire on the 20th. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Multiple Scripts to the script list
Jim DeLaHunt wrote: But we don't really appear to have a style guideline for the Release Language and Release Script fields. http://wiki.musicbrainz.org/How_to_Use_the_Release_Editor mentions the fields in passing. There is a red link to a non-existant page http://wiki.musicbrainz.org/?title=How_To_Add_Script_And_Language . But no real good place to write this down, at the moment. Style guidelines are either under Style/ or on relationship type pages: http://wiki.musicbrainz.org/Style/Release#Language_and_script Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Add orchestrator and instrumentation at recording level
This proposal is to add orchestrator and instrumentation at recording level. The RFV should expire on the 20th. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Reduce the requisites for Live Performance Relationship Type
Nicolás Tamargo de Eguren wrote: Works for me, let's see what Nikki thinks too (she's surely able to find a way to break the rules after all! ;) ) It's fine for me :P Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-338: Clarification of gender=other
It's been more than 48 hours so this has passed. Nikki Johannes Weißl wrote: Hello, this is the RFV for proposal 338, to clarify the other gender option. Wiki page: http://wiki.musicbrainz.org/Proposal:Gender_other_clarification Expiration date: Tue, 08 Nov 2011 04:00:00 UTC Johannes ___ 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
[mb-style] RFC: Add orchestrator and instrumentation at recording level
Since I only got comments in favour when I asked, here's an official proposal to add orchestrator and instrumentation at recording level. It will expire on the 16th November. Those two relationships currently have wiki pages at http://wiki.musicbrainz.org/Orchestrator_Relationship_Type http://wiki.musicbrainz.org/Instrumentator_Relationship_Type This proposal is to add the same relationship at recording level, like arranger already is, since these two types are subtypes of the arranger relationship. Nikki P.S. I haven't made new wiki pages since it would only involve adding recording to the list of entities, but if someone really wants me to, I can do. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-rato: Add DJ-mix to the RG type list
Andii Hughes wrote: What's the status with this? I don't recall seeing an RFV. When I asked Nicolás about it, he said he wanted to wait until we get types and attributes. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-336: Add Voice Actor Relationship Type
There were no vetoes, so this has passed. Nikki Johannes Weißl wrote: Hello, one week has passed, so I'm sending the RFV for proposal 336, which is about adding a new Voice Actor relationship. Since the RFC the link text was changed to performed the voice of. Initial discussion: http://chatlogs.musicbrainz.org/musicbrainz/2011/2011-08/2011-08-08.html Wiki page: http://wiki.musicbrainz.org/Proposal:Voice_Actor_Relationship_Type Expiration date: Wed, 2 Nov 2011 00:01:00 UTC Johannes ___ 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] Sidebar links
Johannes Weißl wrote: As style leader, can you establish a new guideline? I think the discussion died, and I got asked by Kuno Woudt what the status of this is in [1]. [snip] I think the previous show all named relationships and all URLs from domains with more than 1000 links would be well suited and I guess nobody would really object to that. At least until a better UI solution is found when e.g. a band has 5 fanpages. I'm not going to write a formal proposal for something that is really just a data display issue, but I will tell the developers that there's no reason why sites with more than 1000 links and the named relationships shouldn't already be displayed in the sidebar. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sidebar links
jesus2099 wrote: Why on Earth don’t we add ALL the bloody URLs in the sidebar ? So far nobody has suggested a way to do it which shows enough context while still being concise. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Remove Merchandising Provider Relationship Type
It's been more than 48 hours so this has passed. Nikki Nicolás Tamargo de Eguren wrote: As the RFC said: The sheer uselessness of this relationship amazes me (and surely also the people -who only used it 55 times- AND even its proposer, seeing that The purpose of this Relationship Type is unknown.) I'd gladly see it removed. Alternatively, if someone feels this should be kept, please counter-proposal this with an update with description, purpose and examples :) http://wiki.musicbrainz.org/Merchandising_Provider_Relationship_Type ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Recording-level orchestration/instrumentation
Hello Right now we have arranger on both works and recordings, but the sub-types for orchestration and instrumentation only exist on works. Should those relationships be added to recordings too? Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
Jim DeLaHunt wrote: Is there a way to measure how good the data is? For instance, do we have a count of how many Works have both multiple levels using the Parts Relationship, and have Relationships for things like composer? I looked for a way to test this using MB Search, and http://musicbrainz.org/doc/Text_Search_Syntax, but I couldn't find a way to looks for Relationships. There are, as I write this, 4440 parts relationships. If my queries were correct, there are: 4028 cases where both the parent and the child have a composer relationship. 202 cases where the parent does but the child doesn't. 100 cases where the parent doesn't but the child does. 110 cases where neither the parent nor the child have a composer relationship. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-339: Partial Works Relationship Inheritance
I don't think your proposed Style/Work/Partial Works Relationship Inheritance page belongs under Style as it's currently written. The Style pages are intended to simply be guidelines saying how editors should enter data and nothing more. From what I understood of the proposal, that could written as one sentence along the lines of When a work has parts, any relationships that apply to all sub-works should only be added to the parent work. I also agree with Calvin and think we need server support before inheriting relationships before adding a guideline like this. Instead of attempting to get the server, the search server and anything else using MusicBrainz data to implement the same version of inheritance, perhaps what we really need is a better way of adding/editing relationships. Would this still be a problem if we improved relationship editing so that, for example, we were able to add/edit relationships for a work and all its sub-works at the same time? Regarding your Artist Role Inheritance question on the wiki page, I wasn't the one who deleted it, but it was marked as a failed proposal and we already have http://wiki.musicbrainz.org/Style/Relationships#Crediting_an_artist.27s_role_at_the_track_vs._the_release_level as part of the official guidelines. By the way, please make actual pages for the pages you're proposing rather than embedding the changes you want to make within a single page. Nikki Jim DeLaHunt wrote: Hi, everyone: I would appreciate review and comments on RFC-339: Partial Works Relationship Inheritance. The full proposal is at http://wiki.musicbrainz.org/Proposal:Partial_Works_Relationship_Inheritance http://wiki.musicbrainz.org/Proposal:Partial_Works_Relationship_Inheritance . Comments welcome at that Wiki page, or on its Talk page, or here in this thread. This RFC is open at least 7 days, until November 5 GMT or later. I consider what I have there a first draft, and I'll want to polish the text at least before it becomes a solid RFC. Summary: I propose defining an inheritance of relationships between any two Works joined by a Parts Relationship Type. This makes explicit the logical consequence of the Parts Relationship Type's meaning: that one Work entity is a part of another Work entity. Any Relationship which in any of the Work-relatedRelationship Family has its meaning inherited (except Parts Relationship Type, that would be too recursive). This proposal is implemented by three changes: 1. Adding a new page Style/Work/Partial Works Relationship Inheritance, with the text below 2. Adding a stub entry (below) to Style/Work (presently empty) to point to Style/Work/Partial Works Relationship Inheritance 3. Adding text (below) to Parts Relationship Type, summarising and referring to Style/Work/Partial Works Relationship Inheritance Motivation The composer, and sometimes librettist and arranger, are hugely important pieces of metadata for classical, opera, and musical theatre music. It's why we refer to Beethoven's 9th Symphony, or Gilbert and Sullivan operettas. These compositions are frequently recorded many times by many different performers, so more than other genres of music it will be common to have many Recordings point to a single Musicbrainz Work entity. And these compositions are large and long enough that a) the the composer breaks them into smaller pieces (movements, acts, scenes, arias, numbers), and b) Releases frequently break the recorded performance into multiple Tracks of a Release. Hence, there's great value for MusicBrainz in having a way to store metadata about musical compositions in a tree structure, with a single Work entity to represent the entire composition, and child Work entities to represent the composer or the Release publishers divisions of that composition. The Parts Relationship Type provides a way to represent a musical composition in MusicBrainz as a tree structure. Right now it is the only relationship between a whole composition and a partial composition. In the future, other relationship types may be added, but for now, it's the only one. The Parts Relationship Type description is silent about what meaning a relationship with the Work at one end of the Parts relationship has for the Work at the other end. At the same time, it's important to be clear to which Work entities Advanced Relationships like Composer and Librettist should be attached. In the past, there has been similar confusion about when Release-Artist relationship types should be used, when Track-Artist, for roles like Performer and Producer. This led to an extensive debate in 2007-2008; the tip of this iceberg can be seen at Talk:Artist Role Inheritance. Work entities are something of a blank slate. We should state principles now, before there are too many confounding entires in the database. Behind these reasons lurks a larger one. MusicBrainz ability to handle metadata
Re: [mb-style] RFC: Remove Merchandising Provider Relationship Type
Well, since nobody else seems to care either way, I'll give this a +1 :P Nikki Nicolás Tamargo de Eguren wrote: The sheer uselessness of this relationship amazes me (and surely also the people -who only used it 55 times- AND even its proposer, seeing that The purpose of this Relationship Type is unknown.) I'd gladly see it removed. Alternatively, if someone feels this should be kept, please counter-proposal this with an update with description, purpose and examples :) http://wiki.musicbrainz.org/Merchandising_Provider_Relationship_Type ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Reduce the requisites for Live Performance Relationship Type
jacobbrett wrote: * Radio, TV, and internet-streamed performances are considered to be 'live'. * This relationship type should not be used to link from compilations of live performances, nor should it be linked to box sets. * The song order of the live release does not have to match the song order of the studio release. * At least 80% of the tracks from the studio release must be present on the live release. * At least 80% of tracks on the live release must be present on the studio release. * For either of the above two guidelines, the 80% requirement may be lowered if sufficient reason exists, subject to agreement by voters. I think it may be worth keeping the above guidelines, though the 80% rules are a bit superflous. What about something like The original and live releases should contain mostly the same songs? (instead of the last three bullet points) Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-228: Style/Language/Japanese
It's been more than 48 hours without any objections, so this has passed. Nikki Calvin Walton wrote: On Fri, 2011-10-21 at 14:15 -0400, Calvin Walton wrote: The current (barely modified) version is at http://wiki.musicbrainz.org/User:Kepstin/Capitalization_Standard_Japanese Given that I've barely made any changes to this, and the original RFC /did/ get a +1 within its running time, I've decided to take this straight into RFV. Please make sure to read my previous email regarding some of my reasoning behind the things (not) changed. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-336: Add Voice Actor Relationship Type
Alex Mauer wrote: Also, how would the relationships be displayed on the relationship tab for each artist[1,2]? I suggest: “voice of:” and “voice:” for the real and the fictitious artist, respectively. I'd prefer voiced by rather than voice. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Add video attribute to Streaming Music
It's been more than 48 hours, so this has passed. Nikki Nicolás Tamargo de Eguren wrote: As per the previous RFC discussion. See http://wiki.musicbrainz.org/User:Reosarevok/Streaming_Music_Relationship_Type_update ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add video attribute to Streaming Music
You can send an RFV now. Nikki Nicolás Tamargo de Eguren wrote: As per the previous RFC discussion. See http://wiki.musicbrainz.org/User:Reosarevok/Streaming_Music_Relationship_Type_update ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Label sortnames
It's been more than 48 hours, so this has passed. Nikki Nikki wrote: It's been more than a week so here's the RFV. :) Original email: We don't have any official guidelines for labels so I'm proposing http://wiki.musicbrainz.org/User:Nikki/Style/Label for label sortnames. It was based on some unofficial stuff I found on http://wiki.musicbrainz.org/Label_Sort_Name This should expire on the 9th October. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Untitled hidden song
I would still enter it in the track title too. It'd seem weird to me to distinguish between songs which are separate tracks on the CD and ones which aren't. Nikki Frederic Da Vitoria wrote: Hello, This question came up in a recent thread, so I thought it useful to discuss it separately. When a track contains a listed song and an unlisted one (such as in http://musicbrainz.org/release/c2cc70af-45f3-4702-825f-1b647315b9fa ), the documentation http://musicbrainz.org/doc/Style/Unknown_and_untitled/Special_purpose_track_titlesuggests to use the printed titled followed by [unknown] for the hidden song. But this guide was written pre-NGS. Nicolás Tamargo de Eguren suggests that the track title should actually stay as printed and the [unknown] mention should only appear in the recording. What to other users think? ___ 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] RFV: Remove release group - URL has score at
It's been more than 48 hours so this has passed. The relevant edits before it can be removed are: http://musicbrainz.org/edit/15330023 http://musicbrainz.org/edit/15330022 http://musicbrainz.org/edit/15330020 Nikki Nicolás Tamargo de Eguren wrote: http://wiki.musicbrainz.org/Has_Score_At_Relationship_Type applies to works and RGs. This might have made sense before NGS, when it was at track or release level (although it has been used three times [1] so probably not that much sense...) but it does none now, when we can add scores to works (and create parent works to add scores at too). I'd suggest removing the RG-URL score link then, and leave only the work-URL one. [1] http://mb.lmfao.org.uk/reltype ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Label sortnames
It's been more than a week so here's the RFV. :) Original email: We don't have any official guidelines for labels so I'm proposing http://wiki.musicbrainz.org/User:Nikki/Style/Label for label sortnames. It was based on some unofficial stuff I found on http://wiki.musicbrainz.org/Label_Sort_Name This should expire on the 9th October. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Cover relationship Recording-Recording
Lemire, Sebastien wrote: In regards to translated Covers, it's kind of odd though that those get their own works but not if the cover is of the same language. Again, if it was possible to do 3-way ARs, couldn't we then link a Recording (Translated Cover) - Original work - Translator so that the AR would look like Song name in Russian is a cover of song name in English translated in Language attribute by Translator If changing the entire lyrics doesn't count as a derivative work, I'm not sure what does... Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] About Do not cluster
I wouldn't want to delete the content of the page - it's good advice when designing new relationships. I do agree though that in its current state, it's not a very good guideline and I'm sure we could come up with something shorter and more up to date and then move this page somewhere else. Are there any other relationships where we create clusters like the siblings one? As far as I can tell it's an exception... Nikki Nicolás Tamargo de Eguren wrote: http://wiki.musicbrainz.org/Style/Relationships/Do_not_cluster is terribly outdated. Some cases just don't apply anymore (individual releases in a boxset, various recordings). Others, like the Jackson sibling example, are actually clustered (is not clustering siblings really a good idea anyway?). This should probably be rewritten or removed. I'd just remove it, but I imagine there are fans of the guideline around, so maybe one of these fans wants to update it? :) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Cover relationship Recording-Recording
SwissChris wrote: You'll have to ask the developers that decided to launch NGS when it was far from beta yet :( Works *had* artist credits originally, but they were removed after people on this very mailing list decided they didn't want them. Couple of threads (there are probably more): http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-April/009355.html http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2010-September/004070.html Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
