Re: [mb-style] RFC: Dealing with translations and transliterations
On Tue, Jun 13, 2006 at 08:17:05PM -0600, Dustin B wrote: > I think we need an AR to bind transliterations and translations of the > same album together currently so we can more easily combine them when we > have full solution for multiple languages. I fully agree, which is why I bugged you to send an email about it! ;) An example I bought up, which I think illustrates the problem well, is Faye Wong [1]. The majority of her albums are listed in MusicBrainz as English/Latin, Chinese/Latin and Chinese/Han (Traditional). There's no way to work out which album is a transliteration or translation of another, you just have to compare release dates and the number of tracks and hope it's right. With a relationship, [2] in Chinese/Han (Traditional) would become the official tracklist. [3] would become a Chinese (Mandarin)/Latin transliteration and [4] would become a Chinese (Cantonese)/Latin transliteration. [5] would be an English translation. One advantage of it is that when we eventually have support for album/track transliterations or translations (which I've been told will be part of NGS), the unofficial translations can be automatically merged into the official tracklist without the need for hundreds of manual merges. I also agree with Gecks (regarding 'official' or 'unofficial') and Don (regarding being able to avoid clusters). Does anyone disagree with adding it? --Nikki 1 http://musicbrainz.org/artist/692e367d-2846-442d-b13d-1177c3681c65.html 2 http://musicbrainz.org/album/d95466e6-d38c-4577-b6dd-894e1b8faa57.html 3 http://musicbrainz.org/album/c2130588-5c1d-4c22-bec2-63445cb0c849.html 4 http://musicbrainz.org/album/94e3c79b-2908-4a7e-9443-777d800475fa.html 5 http://musicbrainz.org/album/1d3f1239-73c1-46eb-b961-86536a189026.html P.S. > Perhaps we can debate the issue of whether MB should have trans... albums, > but on another thread. It's not even worth the effort of a debate, it's far too late to even attempt to stop the flow of transliterations into the database. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Amazon Relationship Type
2006/6/14, Stefan Kestenholz <[EMAIL PROTECTED]>: > displaying the cover art is nice (I wouldn't really say useful ;-) ). Of course it is... -- i for one am a visual type, and it helps tremendously to see a cover art (even more in classical, where the entry in MB often does have not much resemblance to whats on the cover) Well, yes and no. Especially in classical, the cover art changes even more often than the title. -- Frederic Da Vitoria ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Tracking RFCs and RFVs
On 6/14/06, Bogdan Butnaru <[EMAIL PROTECTED]> wrote: On 6/14/06, Don Redman <[EMAIL PROTECTED]> wrote: > We drop the RFC and RFV from the subject line. Instead, somebody who > starts a new RFC (i.e. who raises an issue which they want to get solved), > adds "" to the body of their mail. This line _must > not_ be cited in replies. > We do the same for RFVs > > This way anybody can add a filter to their email program that will show > them exactly when which RFC and RFV have been raised. This will probably be useful for at least some of the users. But why drop the marker in the subject? The subject is, after all, supposed to describe the email, isn't it? [...] Also, this will make it harder for me to separate the RFVs from other MB-related messages. I could of course add a label and a filter, but that will raise complexity instead of lowering it (because it's easier to check things with one quick look than with a click). -- Bogdan Butnaru — [EMAIL PROTECTED] "I think I am a fallen star, I should wish on myself." – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Tracking RFCs and RFVs
On 6/14/06, Don Redman <[EMAIL PROTECTED]> wrote: We drop the RFC and RFV from the subject line. Instead, somebody who starts a new RFC (i.e. who raises an issue which they want to get solved), adds "" to the body of their mail. This line _must not_ be cited in replies. We do the same for RFVs This way anybody can add a filter to their email program that will show them exactly when which RFC and RFV have been raised. This will probably be useful for at least some of the users. But why drop the marker in the subject? The subject is, after all, supposed to describe the email, isn't it? That said, I'd think a large section of the users (even on the style list) don't know how to create a filter, and I'm sure we'll often forget deleting the list. That said, those using GMail don't really need this: all replies to a mail are grouped under a "conversation". I have a label which is attached automatically (or manualy sometimes) to everything related to MB, which works like a folder. I click on it and see all subjects, and when I click on a subject I see all replies, neatly folded, with unread ones open. Isn't that possible for other mail clients too? -- Bogdan Butnaru — [EMAIL PROTECTED] "I think I am a fallen star, I should wish on myself." – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
On 6/14/06, Simon Reinhardt <[EMAIL PROTECTED]> wrote: Btw: and interesting case is Dream Theater who released older demos *after* they changed their name from Majesty to Dream Theater and thus the demos contain both band names: there were compilation appearances as "majesty", too. i remember seeing at least one CMJ compilation from the college radio days. so, they still fall under this umbrella, i think. -- --dj empirical-- - http://www.myspace.com/djempirical hey, look what i wrote: http://i-see-sound.com/?q=author/15 http://www.flickr.com/photos/dj_empirical/ ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Tracking RFCs and RFVs
First, I have to say that I am very impressed with some of the last postings on mb-style. There were some very disciplined, process-aware posts. If we continue this way, the job of the secretary will be a no-brainer. The secretary would only have to jump in in strange or very disputed cases and moderate. I think that I could do this for another year without suffering burnout. While marvelling about the self-organization of the Style Council, I thought about how this cold be facilitated even more. And then I came up with a very simple hack. What about this: We drop the RFC and RFV from the subject line. Instead, somebody who starts a new RFC (i.e. who raises an issue which they want to get solved), adds "" to the body of their mail. This line _must not_ be cited in replies. We do the same for RFVs This way anybody can add a filter to their email program that will show them exactly when which RFC and RFV have been raised. The benefit over a tracker is that this is not a tool which reminds you of issues that have to be fixed. It is just a "map" of recent activity. I think this fits better to the nature of style issues and the way the Style Council works. What do you think? DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
Wow, the book is forgiven. That was a very precise and detailed summary of the problem and the possible sollutions. I think that the cluster problem can be minimized, if the ARs point to the original album in the artist's original language. This will not remove all clusters but many. Additinally we should be able to differentiate beteween real releases and virtual releases. This can be done with an AR attribute, but that's a hack. The information belongs to the rleease. But will we find a developer who will add another release attribute? DonRedman On Wed, 14 Jun 2006 04:17:05 +0200, Dustin B wrote: Apparently this didn't make it onto the list the first time I sent it. Forgive, the book. I try not to post too much because it ends up being a bit long, but as a lot of the transliterations recently have been mine I think I should chime in. I think we need an AR to bind transliterations and translations of the same album together currently so we can more easily combine them when we have full solution for multiple languages. Transliterations and Translations (trans... albums) have been cropping up a lot on the edits recently. And while many are mine even more are from new moderators wanting to flesh out the database with useful information. I've seen first hand by adding an official album and a transliterated version that the transliterated version gets more attention and editing; considering MB is an English site, go figure. And with a bit of quick scanning through these edits you'll see that there's a bit of confusion and debate as to how these should be handled. Partly because a lot of the people voting and editing are new, but mostly because there's no documentation and almost no official way to tie these together. Examples. http://musicbrainz.org/album/08229f60-a117-4d7f-b3a7-03533267eeb2.html http://musicbrainz.org/album/1a18e14a-de59-415e-9abd-1e644cd58dc6.html The issue has already been brought up on the mailing list a few times but nothing has ever come of it; so now that this is growing I think we need to come up with a solution. The following threads are some of the best discussions thus far about the issue but are 6-12 months out of date. http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-July/000254.ht ml http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-July/000252.ht ml http://lists.musicbrainz.org/pipermail/musicbrainz-users/2005-December/01042 6.html Long and short of it is that there are more and more trans... albums going up, and under the current wiki rules for VirtualDuplicateRelease they are to be kept in the database. This creates a lot of duplicate albums that need to be tracked and edited because if they are the same a change on one album should affect the others. Some people's answer to this is to eliminate trans... albums completely but I don't think they'll go away considering that: 1. The wiki currently approves or it B. The database is already full of them III. MB has a stated goal to have further internationalization so it's not an "English Speaker Only" club. Perhaps we can debate the issue of whether MB should have trans... albums, but on another thread. This tread is about a solution to bring a little more order to the database rather than throwing it into further chaos. Alexander Dupuy came up with an excellent summary of the issue and how to deal with it in on of the previous threads: In general, I see the roadmap for this aspect of i18n as follows 0. entry of transliterations - as Orion notes, there are a lot of these already for Asian artists, where they are the most useful/needed, and they will continue to be entered on an ongoing basis 1. addition of AR linktype for transliterations - the issues with clusters are tricky, but this seems the best way to go; some design is needed to coordinate with other "same as" type relationships (e.g. re-release, remaster, etc.) 2. elaboration of style guidelines for transliterations - there are some best practices, but it's true they haven't really been well codified 3. enhancement of album display to "hide" unwanted transliterations - this is part of a much larger project, which would be the follow-on to the artist page redesign, adding special display support for album-album AR links I anticipate a lot of griping from people who find transliterated entries "unreadable and simply wrong" until the final roll-out of step 3, but I'm convinced that this is the right direction for us to go. #3 is the best and final solution but will take time to get something running; banning good information till then just creates a bigger workload later when we have a solution and MB becomes a truly international site. There's no reason to throw away good info right now just because we're confused with what to do with it, or worse disagree with it because i
[mb-style] Freetext crediting (Was: RFV: Adding some AR attributes)
Chris Bransden wrote: On 14/06/06, Simon Reinhardt <[EMAIL PROTECTED]> wrote: Of course since we don't have freetext crediting like Discogs we can only render liner notes to a certain extent and I'd normally say try to find those types which are nearest to what they really did - but since in most of the cases we can't know what they really did, we can only go with the liner notes for those smaller roles and therefore I also prefer to see it as close to the liner notes as possible. That does not apply for all AR types though - in some cases you *can* know what the credited persons really did. For example liner notes for rock albums mostly say "guitars by ..., bass by ..." where they mean electric guitar and electric bass guitar. Of course it's not wrong to let it as "guitars" as those are generalisations. i agree. i'd still like to have free-text qualifiers (pipe dream...), for the occasions when a new AR isn't appropriate, but it's still nice to show the written credit as well as the actual role - eg http://www.discogs.com/release/535757 (look at some of those convoluted track credits!) Ok, I decided to open a new thread since this is interesting but off-topic from the RFV. :) The big advantage of AR compared to freetext crediting is that we can clearly define the semantics of every type. The disadvantage is that we cannot cover every possible case. Perhaps a combined solution would make sense: selecting a general AR type and having a free text field for the details (*). I often state the exact details of the credit in the moderation note or use the album annotation for cases we can't cover exactly yet. I also use the annotation for things we can't describe at all with AR - for example "drums recorded at studio XY by YZ from T to S" or "engineer for studio A: X, engineer for studio B: Y" or "choir/strings/orchestra arranged by ..., conducted by ...". Some of them need additional types / type extensions, some would need three-directional AR types, some are just strange. :) (*) http://bugs.musicbrainz.org/ticket/1142 would make that possible. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
Chris Bransden wrote: On 14/06/06, derGraph <[EMAIL PROTECTED]> wrote: For cases where an artist only changed it's name we might use a more general "renamed to"/"was previously known as" AR. i'm not so sure such cases would be indexed as seperate artists anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html and related discussion Ok, stepping in a bit late again, sorry. I would prefer a general type which can mean both simple name changes and name changes combined with line-up / style changes (I don't like that "style" thing though since it is subjective, so I don't think it should go into the style description for that type). And right as Don said it, we don't need any rules then which cases this is allowed for and which not but simply delegate this problem to the question "Are those different band names allowed to have separate entries or not?". If they are, we use this relationship, if they are not then they are to be merged - you see, the problem is solved very simply by moving the discussion to another place. ;) Then my reasoning for why I think we need one type only: One reason is that I think the types get too diverse and complex - we would expect too much from the users. And for those who're going to say "that's a lame reason", here's the other one: I'm not sure if you can clearly separate those two types in every case, I think they overlap too much. Some bands changed their name several times before they became popular under a certain name and often you don't have enough info about style changes / line-up changes. I know several cases offhand where the bands released demos or even official albums under their older names and *I'd* prefer having those as separate artist entries to be more accurate (not only for tagging) - even if the line-up stayed the same. Btw: and interesting case is Dream Theater who released older demos *after* they changed their name from Majesty to Dream Theater and thus the demos contain both band names: http://dt.qrayg.com/bootlegs/pre-dream-theater/the-official-1986-demo - http://www.ytsejamrecords.com/ProductCart/pc/viewPrd.asp?idcategory=6&idproduct=11 I'll stop before I'm going too off-topic. ;) Oh and: I'll not veto, see this as a too late answer to the discussion phase. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
On 14/06/06, Simon Reinhardt <[EMAIL PROTECTED]> wrote:
Chris Bransden wrote:
> only one i thing is a bit bizzare is "adding
> ExecutiveRelationshipAttribute to EngineerRelationshipType" - i'm not
> sure what that would mean?
Well, similar to the producer type, the phrase would change from "{additionally}
engineered" to "{additionally} {co-}{executive }engineered" and you would be able to
select whether those attributes apply or not.
yeah i understand that, but i mean what does the role actually entail?
an executive producer is someone who funds the production of a
release, and/or organises the macro aspects, like studios, who is
involved in it, etc (there's a better definition on the wiki). it
seems strange to have someone purely involved in the executive aspects
of engineering - it's like having an executive session guitarist :)
but i guess it's possible. maybe i've answered my own question there
:)
> also i've never seen it before so i'm
> inclined to think it's perhaps a very rare occurance. was it 5
> appearences we needed for an AR to be valid for inclusion? personally
> i think if it appears once it's worth including, so i'm not vetoing :)
You're right, we had such a rule for instruments (was it 5 or 3?). I'm also not
against changing it for one occurance since those attributes sound logical
whereas a vacuum cleaner is no typical music instrument and thus needed enough
cases to justify we need it in the tree. But if someone insists on seeing
examples, here is mine:
The liner notes of Posthumous Silence
(http://musicbrainz.org/showrel.html?id=501368&type=album) say: Engineered and
mixed by Jens Lück, Co-engineered and mixed by Matthias Harder.
And Schika had the examples for executive engineered he said. :)
these i'd like to see, maybe it makes more sense in context!
> this is also possible, eg when the recorder (read: producer) has a
> assisting engineer. of course you could bodge this by crediting them
> as additional recorded by, but personally i'd prefer to see it as
> close to the liner notes as possible, so i'd be ok with this being
> added.
I used additional for all credits saying "assistant" so far.
i meant that i think 'recording engineered by' appearing along side
'recorded by' probably means a secondary engineer assisting the main
'recorder' of the work, and that this could be bodged as '{additional}
recorded by', though i'd prefer not to as you can't be sure what's
going on - maybe they did more engineering work than the 'recorder'
who simply pressed 'REC' (not an 'engineer').
Of course since we don't have freetext crediting like Discogs we can only render liner notes to a
certain extent and I'd normally say try to find those types which are nearest to what they really
did - but since in most of the cases we can't know what they really did, we can only go with the
liner notes for those smaller roles and therefore I also prefer to see it as close to the liner
notes as possible. That does not apply for all AR types though - in some cases you *can* know what
the credited persons really did. For example liner notes for rock albums mostly say "guitars
by ..., bass by ..." where they mean electric guitar and electric bass guitar. Of course it's
not wrong to let it as "guitars" as those are generalisations.
i agree. i'd still like to have free-text qualifiers (pipe dream...),
for the occasions when a new AR isn't appropriate, but it's still nice
to show the written credit as well as the actual role - eg
http://www.discogs.com/release/535757 (look at some of those
convoluted track credits!)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
On 6/14/06, Chris Bransden <[EMAIL PROTECTED]> wrote: On 14/06/06, Aaron Cooper <[EMAIL PROTECTED]> wrote: > On 6/14/06, Chris Bransden <[EMAIL PROTECTED]> wrote: > > On 14/06/06, derGraph <[EMAIL PROTECTED]> wrote: > > > For cases where an artist only changed it's name we might use a more > > > general "renamed to"/"was previously known as" AR. > > > > i'm not so sure such cases would be indexed as seperate artists > > anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html > > and related discussion > > > > There are many examples in the database of groups which have changed > their name and are entered as separate artists. > > For example: > Inearthed -> Children of Bodom according to the annoation, this seems to be show a stylistic change, not just a name change. these kind of groups would be seperated (ie you'd want them tagged seperate/on seperate artist pages) The annotation does document a change in "style" (which I think is primarily interpreted on an individual basis - they don't sound significantly different to me), however the band as a collective did change their name - not form a new band. Are "stylistic" changes worth splitting up a group? Metallica obviously has played several different "styles" of music which (IMO) are much more noticable than the difference between Inearthed and Children of Bodom releases. But I didn't throw up these examples to discuss them here, I was just trying to show that we do have occurrences that are indexed separately. > Burn the Priest -> Lamb of God i don't know the artist, so perhaps this is also a stylistic change. if not as far as i'm aware it should be an alias of lamb of god, not a seperate artist. Just for the record, there is very little stylistic change (if any) in this specific example. Lamb of God even re-issued their self-titled album released under the name "Burn the Priest". ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] other commercial relationships (emusic)?
well, AM G and Discogs have links to several other shops, in addition to amazon. therefore it should be possible to add urls which have a certain longevity to them. even the amazon urls can change, if a release is not sold anymore. I'd rather see this feature be implemented such that the other URLs wouldn't show up anymore in the relationships box. the urls are usually quite long and unpresentable. --- keschte PS. please use mb-users for this kind of disussions. spread the word about what the style mailing list is for, please: http://wiki.musicbrainz.org/StyleMailingList In the meantime I think there's a "can be bought from" relationship that iirc can be used for exactly that. Amazon has a separate relationship mostly because of the covers, afaik, and we have a sort of contract with them to allow us to do that. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Chris Bransden wrote:
only one i thing is a bit bizzare is "adding
ExecutiveRelationshipAttribute to EngineerRelationshipType" - i'm not
sure what that would mean?
Well, similar to the producer type, the phrase would change from "{additionally}
engineered" to "{additionally} {co-}{executive }engineered" and you would be able to
select whether those attributes apply or not.
also i've never seen it before so i'm
inclined to think it's perhaps a very rare occurance. was it 5
appearences we needed for an AR to be valid for inclusion? personally
i think if it appears once it's worth including, so i'm not vetoing :)
You're right, we had such a rule for instruments (was it 5 or 3?). I'm also not
against changing it for one occurance since those attributes sound logical
whereas a vacuum cleaner is no typical music instrument and thus needed enough
cases to justify we need it in the tree. But if someone insists on seeing
examples, here is mine:
The liner notes of Posthumous Silence
(http://musicbrainz.org/showrel.html?id=501368&type=album) say: Engineered and
mixed by Jens Lück, Co-engineered and mixed by Matthias Harder.
And Schika had the examples for executive engineered he said. :)
this is also possible, eg when the recorder (read: producer) has a
assisting engineer. of course you could bodge this by crediting them
as additional recorded by, but personally i'd prefer to see it as
close to the liner notes as possible, so i'd be ok with this being
added.
I used additional for all credits saying "assistant" so far. Of course since we don't have freetext
crediting like Discogs we can only render liner notes to a certain extent and I'd normally say try to find
those types which are nearest to what they really did - but since in most of the cases we can't know what
they really did, we can only go with the liner notes for those smaller roles and therefore I also prefer to
see it as close to the liner notes as possible. That does not apply for all AR types though - in some cases
you *can* know what the credited persons really did. For example liner notes for rock albums mostly say
"guitars by ..., bass by ..." where they mean electric guitar and electric bass guitar. Of course
it's not wrong to let it as "guitars" as those are generalisations.
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] other commercial relationships (emusic)?
On 6/14/06, Dave Smey <[EMAIL PROTECTED]> wrote: Hi all, I'm a newbie here.. Is there a chance of adding other commecial relationships? I for one would like to see an emusic link. I've been driven into musicbrainism partly because the data at eMu is often very sloppy and incomplete - it would be awesome to think that people could eventually use MB to "shop" at their outlet of choice. This would be nice, but really, I doubt we could do this very well on our own: there are quite a few shops (and probably there will be more in the future), which probably change their data often, so links will always be spotty and sloppy. What would be nice would be shops that use our web-service to present or at least to initially load the data. But I doubt that'll happen very quick. In the meantime I think there's a "can be bought from" relationship that iirc can be used for exactly that. Amazon has a separate relationship mostly because of the covers, afaik, and we have a sort of contract with them to allow us to do that. -- Bogdan Butnaru — [EMAIL PROTECTED] "I think I am a fallen star, I should wish on myself." – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] other commercial relationships (emusic)?
Hi all, I'm a newbie here.. Is there a chance of adding other commecial relationships? I for one would like to see an emusic link. I've been driven into musicbrainism partly because the data at eMu is often very sloppy and incomplete - it would be awesome to think that people could eventually use MB to "shop" at their outlet of choice. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
On 14/06/06, Aaron Cooper <[EMAIL PROTECTED]> wrote: On 6/14/06, Chris Bransden <[EMAIL PROTECTED]> wrote: > On 14/06/06, derGraph <[EMAIL PROTECTED]> wrote: > > For cases where an artist only changed it's name we might use a more > > general "renamed to"/"was previously known as" AR. > > i'm not so sure such cases would be indexed as seperate artists > anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html > and related discussion > There are many examples in the database of groups which have changed their name and are entered as separate artists. For example: Inearthed -> Children of Bodom according to the annoation, this seems to be show a stylistic change, not just a name change. these kind of groups would be seperated (ie you'd want them tagged seperate/on seperate artist pages) Burn the Priest -> Lamb of God i don't know the artist, so perhaps this is also a stylistic change. if not as far as i'm aware it should be an alias of lamb of god, not a seperate artist. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
On 6/14/06, Chris Bransden <[EMAIL PROTECTED]> wrote: On 14/06/06, derGraph <[EMAIL PROTECTED]> wrote: > For cases where an artist only changed it's name we might use a more > general "renamed to"/"was previously known as" AR. i'm not so sure such cases would be indexed as seperate artists anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html and related discussion There are many examples in the database of groups which have changed their name and are entered as separate artists. For example: Inearthed -> Children of Bodom http://musicbrainz.org/artist/561070ee-289e-49d9-95e3-c82ff5cc24c6.html http://musicbrainz.org/artist/f57e14e4-b030-467c-b202-539453f504ec.html Burn the Priest -> Lamb of God http://musicbrainz.org/artist/b27c15ef-b146-41f4-b1ac-c8ac50713e8e.html http://musicbrainz.org/artist/298909e4-ebcb-47b8-95e9-cc53b087fc65.html ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Amazon Relationship Type
displaying the cover art is nice (I wouldn't really say useful ;-) ). Of course it is... -- i for one am a visual type, and it helps tremendously to see a cover art (even more in classical, where the entry in MB often does have not much resemblance to whats on the cover) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Amazon Relationship Type
I wasn't clear enough. I was not meaning the cover art shouldn't be a link, just that we could implement a specialized kind of AmazonRelationship that would be specifically for the amazon links that can display the cover art. Part of the discussion is that displaying the cover art is nice (I wouldn't really say useful ;-) ). So a way to ensure this could be to create a specialized AR for it. Not a hack, it would be exactly the same as the current AmazonRelationship, it would work the same, but modders would be asked to use only Amazon pages that will bring back the cover art to MB. Oh, it could have a small difference: since we have only one place to display the cover art, entering more than one AmazonCoverArt would be useless. But you are right, my suggestion has a flaw. Maybe another (and better) way of doing it could be to add an attribute to the AmazonRelationship to differentiate the occurrences which allow displaying the cover art from those which don't. This would avoid entering the same link twice. 2006/6/14, azertus <[EMAIL PROTECTED]>: This will not happen; it's a very ugly hack IMO. Besides, I don't think Amazon allows use of their cover art without a link, so you would have two links to Amazon using your proposal, and one of them would be wrong... Ugh! ;) Frederic Da Vitoria schreef: > I think we need what is covered in the wiki page about AmazonLinks (a > stable way to link to the cover art) and a way to express other links > (commercial for example). IMO, the AmazonRelationships are ill-named. > We should have two distinct link types: AmazonCoverArt which should be > as stable as possible (and maybe we would need other types of cover > art links), and AmazonBuy (or whatever) for other links. -- Frederic Da Vitoria ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
On 14/06/06, derGraph <[EMAIL PROTECTED]> wrote: For cases where an artist only changed it's name we might use a more general "renamed to"/"was previously known as" AR. i'm not so sure such cases would be indexed as seperate artists anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html and related discussion ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
On 6/14/06, derGraph <[EMAIL PROTECTED]> wrote: Aaron Cooper wrote: > In the case where a band literally *just* changes its name for legal > reason or because they are about to break into the commercial market, > "predecessor/successor" doesn't seem to apply. In all respects, the > band is identical and so the AR seems to be implying more than what is > needed. Will this AR only be used to link groups that change their > name AND change the lineup? Right, I forgot about that... The idea for this AR arose from a post explaining a band's history with several name, style and lineup changes. And as far as I recall we had some kind of silent agreement that this AR type should only be used for such cases where either the band's lineup or style did change along with the name. But as name + style changes in most cases are a result of a lineup change, we might also limit this to lineup changes. For cases where an artist only changed it's name we might use a more general "renamed to"/"was previously known as" AR. Alright, that sounds great. :) -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
On 14/06/06, Simon Reinhardt <[EMAIL PROTECTED]> wrote: Hi again, to sum it up so far: there have been no vetoes but some discussion that put parts of this back to the RFC stage, so I'll split it as follows... I propose adding CoRelationshipAttribute to EngineerRelationshipType (the main type, not all sub types) and within that to the sub type for mixers, and adding ExecutiveRelationshipAttribute to EngineerRelationshipType (again the main type only) as proposed by Schika. For this I let the veto phase open for another 48 hours. If someone thinks we need to clarify those two sub roles first (that is to write the wiki pages for those attributes to exactly describe them), feel free to veto. only one i thing is a bit bizzare is "adding ExecutiveRelationshipAttribute to EngineerRelationshipType" - i'm not sure what that would mean? also i've never seen it before so i'm inclined to think it's perhaps a very rare occurance. was it 5 appearences we needed for an AR to be valid for inclusion? personally i think if it appears once it's worth including, so i'm not vetoing :) Note that the following discussion arose from this: Schika had examples of liner notes which differentiate between a mixer and a mix engineer. Do we need that separated? well i think you have to be careful as the example (system 7) might mean DJMix when they say "Mixed By" and "Mixed By" where they say "Mix Engineer". if anyone can find an example where that's definitely not the case then it's probably worth adding seperately. Also he stated a difference between "recorded by" and "recording engineered by" again. I think all this needs a new thread so feel free to start one. ;) this is also possible, eg when the recorder (read: producer) has a assisting engineer. of course you could bodge this by crediting them as additional recorded by, but personally i'd prefer to see it as close to the liner notes as possible, so i'd be ok with this being added. i think ultimately we're going to end up with lots of engineering ARs with a lot of overlap, but personally i don't see this as a problem. For the proposed changes of adding GuestRelationshipAttribute to OrchestraRelationshipType and ConductorRelationshipType I feel there definitely is need for more discussion to clarify what this attribute is about in general (wiki page needs to be written) so I abandon the request for those changes. i think it would be ok to include these to be honest as i'm sure there are valid situations for it, even if you applied my logic (which probably stinks :P) however i do think 'guest' needs some explanation/clarification for its general use. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
Aaron Cooper wrote: In the case where a band literally *just* changes its name for legal reason or because they are about to break into the commercial market, "predecessor/successor" doesn't seem to apply. In all respects, the band is identical and so the AR seems to be implying more than what is needed. Will this AR only be used to link groups that change their name AND change the lineup? Right, I forgot about that... The idea for this AR arose from a post explaining a band's history with several name, style and lineup changes. And as far as I recall we had some kind of silent agreement that this AR type should only be used for such cases where either the band's lineup or style did change along with the name. But as name + style changes in most cases are a result of a lineup change, we might also limit this to lineup changes. For cases where an artist only changed it's name we might use a more general "renamed to"/"was previously known as" AR. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
In the case where a band literally *just* changes its name for legal reason or because they are about to break into the commercial market, "predecessor/successor" doesn't seem to apply. In all respects, the band is identical and so the AR seems to be implying more than what is needed. Will this AR only be used to link groups that change their name AND change the lineup? Regards, -Aaron (cooperaa) On 6/14/06, derGraph <[EMAIL PROTECTED]> wrote: Michelle . wrote: > The only problem I can see is that the word "predecessor" can be > misinterpreted to mean someone performing earlier, with a similar > style. If you look up "musical predecessor" (with quotation marks) on > Google, you'll see what I mean. So "A is a musical predecessor of B" would mean that B's style is influenced by A. Right? We had also discussed the wording "evolved into" and "evolved from". If you think this wording is a problem, then you should veto now. But in this case, I'll send another RFV for the alternate wording. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Hi again, to sum it up so far: there have been no vetoes but some discussion that put parts of this back to the RFC stage, so I'll split it as follows... I propose adding CoRelationshipAttribute to EngineerRelationshipType (the main type, not all sub types) and within that to the sub type for mixers, and adding ExecutiveRelationshipAttribute to EngineerRelationshipType (again the main type only) as proposed by Schika. For this I let the veto phase open for another 48 hours. If someone thinks we need to clarify those two sub roles first (that is to write the wiki pages for those attributes to exactly describe them), feel free to veto. Note that the following discussion arose from this: Schika had examples of liner notes which differentiate between a mixer and a mix engineer. Do we need that separated? Also he stated a difference between "recorded by" and "recording engineered by" again. I think all this needs a new thread so feel free to start one. ;) For the proposed changes of adding GuestRelationshipAttribute to OrchestraRelationshipType and ConductorRelationshipType I feel there definitely is need for more discussion to clarify what this attribute is about in general (wiki page needs to be written) so I abandon the request for those changes. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type "is the predecessor of"
Michelle . wrote: The only problem I can see is that the word "predecessor" can be misinterpreted to mean someone performing earlier, with a similar style. If you look up "musical predecessor" (with quotation marks) on Google, you'll see what I mean. So "A is a musical predecessor of B" would mean that B's style is influenced by A. Right? We had also discussed the wording "evolved into" and "evolved from". If you think this wording is a problem, then you should veto now. But in this case, I'll send another RFV for the alternate wording. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] RFV: new AR type "is the predecessor of"
The only problem I can see is that the word "predecessor" can be misinterpreted to mean someone performing earlier, with a similar style. If you look up "musical predecessor" (with quotation marks) on Google, you'll see what I mean. Michelle From: derGraph <[EMAIL PROTECTED]> Reply-To: MusicBrainz style discussion To: MusicBrainz style discussion Subject: [mb-style] RFV: new AR type "is the predecessor of" Date: Wed, 14 Jun 2006 13:21:25 +0200 I've realized that the discussion on this issue has _just recently_ ebbed out ... Okay, I did forget about it. Don Redman and I proposed to introduce a new AR type for linking artist groups which changed their name along with a lineup change. The style council obviously favours the following wording. [group1] is a predecessor of [group2] [group2] is a successor of [group1] The date of this change (if known) should be entered as the start date. As we don't want to bug our developers with creating additional restrictions (link group to group only, disallow entering end date), these restrictions have to be enforced by guidelines and voting only. Whoever sees a problem arise in this change shall veto it now. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style _ realestate.com.au: the biggest address in property http://ninemsn.realestate.com.au ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: new AR type "is the predecessor of"
I've realized that the discussion on this issue has _just recently_ ebbed out ... Okay, I did forget about it. Don Redman and I proposed to introduce a new AR type for linking artist groups which changed their name along with a lineup change. The style council obviously favours the following wording. [group1] is a predecessor of [group2] [group2] is a successor of [group1] The date of this change (if known) should be entered as the start date. As we don't want to bug our developers with creating additional restrictions (link group to group only, disallow entering end date), these restrictions have to be enforced by guidelines and voting only. Whoever sees a problem arise in this change shall veto it now. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Amazon Relationship Type
This will not happen; it's a very ugly hack IMO. Besides, I don't think Amazon allows use of their cover art without a link, so you would have two links to Amazon using your proposal, and one of them would be wrong... Ugh! ;) Frederic Da Vitoria schreef: I think we need what is covered in the wiki page about AmazonLinks (a stable way to link to the cover art) and a way to express other links (commercial for example). IMO, the AmazonRelationships are ill-named. We should have two distinct link types: AmazonCoverArt which should be as stable as possible (and maybe we would need other types of cover art links), and AmazonBuy (or whatever) for other links. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] RFC: Dealing with translations and transliterations
That makes great sense, I agree. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bransden Sent: Wednesday, June 14, 2006 2:32 AM To: MusicBrainz style discussion Subject: Re: [mb-style] RFC: Dealing with translations and transliterations On 14/06/06, Dustin B <[EMAIL PROTECTED]> wrote: > There's no reason to throw away good info right now just because we're > confused with what to do with it, or worse disagree with it because it > doesn't make the database "pretty". Remember the goal is the ultimate > repository of music releases my concern is that these *aren't* music releases. infact i've never really seen the point of transliterations, as i feel the english (or other) version of the trackname is trivia, rather than something you'd want to look at. after all, all other aspects of the release (lyrics etc) will presumably be in the offending language, so i'm not sure it's worth doing. plus i prefer seeing things in the language of origin, even if it is all squiggles to me :) but i appreciate that other people want them, so fair enough in them being added, and i agree that the next steps need to be to make an AR to link them to the original, and then hide, or otherwise seperate unofficial transliterations from official releases. also i think the transliteration AR should have an 'official' or 'unofficial' attribute, to seperate releases that have different titles on the sleeve depending on what market they are in. 'official' transliterations shouldn't be hidden/seperated from the official releases. chris / gecks ___ 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: Dealing with translations and transliterations
On 14/06/06, Dustin B <[EMAIL PROTECTED]> wrote: There's no reason to throw away good info right now just because we're confused with what to do with it, or worse disagree with it because it doesn't make the database "pretty". Remember the goal is the ultimate repository of music releases my concern is that these *aren't* music releases. infact i've never really seen the point of transliterations, as i feel the english (or other) version of the trackname is trivia, rather than something you'd want to look at. after all, all other aspects of the release (lyrics etc) will presumably be in the offending language, so i'm not sure it's worth doing. plus i prefer seeing things in the language of origin, even if it is all squiggles to me :) but i appreciate that other people want them, so fair enough in them being added, and i agree that the next steps need to be to make an AR to link them to the original, and then hide, or otherwise seperate unofficial transliterations from official releases. also i think the transliteration AR should have an 'official' or 'unofficial' attribute, to seperate releases that have different titles on the sleeve depending on what market they are in. 'official' transliterations shouldn't be hidden/seperated from the official releases. chris / gecks ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
