headers
Frederik 'Freso' S. Olesen | 2 Nov 2006 12:47
Picon

Re: RFV: How to handle band/artist name changes

2006/11/1, Age Bosma <agebosma@...>:
>Arturus Magi wrote:
>>The general proprosal, I have no problem with, but there are a lot of
>>artists whose legal name is not their primary entry, or for whom we
>>have a significant number of aliases and no legal name.  I have
>>significant doubts about the usefulness of automatically assuming
>>every existing AR points to a legal name.
>
>The existing AR should have only be used for this purpose since it's
>only intend was to create a legal name relation. I think it's saver to
>assume that most links are correct than non are.

I disagree:
Wrongly adding the "legal name" attribute to a bunch of ARs would be
wrong information.
Not adding the "legal name" to another bunch of ARs would be missing
information.
Missing information is much, much better than wrong information since
wrong information is so hard to kill (in some cases impossible).

--

-- 
Frederik 'Freso' S. Olesen <http://freso.dk/>
Permalink | Reply |
headers
Lauri Watts | 2 Nov 2006 14:08
Picon

Re: RFV: How to handle band/artist name changes

On 11/2/06, Frederik 'Freso' S. Olesen <freso.dk@...> wrote:
> 2006/11/1, Age Bosma <agebosma@...>:
> >Arturus Magi wrote:
> >>The general proprosal, I have no problem with, but there are a lot of
> >>artists whose legal name is not their primary entry, or for whom we
> >>have a significant number of aliases and no legal name.  I have
> >>significant doubts about the usefulness of automatically assuming
> >>every existing AR points to a legal name.
> >
> >The existing AR should have only be used for this purpose since it's
> >only intend was to create a legal name relation. I think it's saver to
> >assume that most links are correct than non are.
>
> I disagree:
> Wrongly adding the "legal name" attribute to a bunch of ARs would be
> wrong information.
> Not adding the "legal name" to another bunch of ARs would be missing
> information.
> Missing information is much, much better than wrong information since
> wrong information is so hard to kill (in some cases impossible).
>
"legal name" is problematic.  People get married. People get divorced.
 Some people have more than one legal name. People change their names
legally.  People have legal names they have never and will never use.
At best we can know what someone's legal name probably was during a
particular period.

Whatever the stated intent may have been initially, the fact is that
the AR very often does not point to any specific currently legal name
at either end.  I'm not just talking about corner cases here either,
(Continue reading)

Permalink | Reply |
headers
Kerensky97 | 3 Nov 2006 20:49

Re: RFV: How to handle band/artist name changes


Add me as another person who really likes this idea but not the wording of
"legal".  If we can just think of a different way to word it I think it
would be great.

Offtopic:  RFV already?
--

-- 
View this message in context: http://www.nabble.com/RFV%3A-How-to-handle-band-artist-name-changes-tf2538639s2885.html#a7166287
Sent from the Musicbrainz - Style mailing list archive at Nabble.com.
Permalink | Reply |
headers
Age Bosma | 6 Nov 2006 12:07
Picon
Favicon

Re: RFV: How to handle band/artist name changes

Kerensky97 wrote:
> Add me as another person who really likes this idea but not the wording of
> "legal".  If we can just think of a different way to word it I think it
> would be great.
> 

Who are the other people who don't like the wording of 'legal'? ;-)

> Offtopic:  RFV already?

Yeah, there was no response on the other thread any more and this RFV 
was the consensus of that discussion. It's a bit strange that people 
start to object to the 'apply attribute automatically' bit now instead 
of earlier.

I have to agree with the arguments given and we shouldn't apply the 
'legal' attribute to the existing ARs automatically for the reasons they 
pointed out. I do, however, see no reason to leave the 'legal name' 
attribute out or change it. I can't think of any other way of naming it 
and I think we all agree that we should be able to make the distinction.

We could change the AR even more to allow it to be used for all these 
relations:
- 'legal name <-> legal name'
- 'performance name <-> performance name'
- 'legal name <-> performance name'

It will get complicated but at least it will allow us to specify 
multiple legal names where it's needed.
(Continue reading)

Permalink | Reply |
headers
Don Redman | 6 Nov 2006 20:38
Picon
Picon

RFC: How to handle band/artist name changes (Was a RFV)

On Mon, 06 Nov 2006 12:07:03 +0100, Age Bosma wrote:

> Kerensky97 wrote:
>> Add me as another person who really likes this idea but not the wording  
>> of
>> "legal".  If we can just think of a different way to word it I think it
>> would be great.
>>
>
> Who are the other people who don't like the wording of 'legal'? ;-)

I do not think we need a rewording, but I believe that we should state  
very clearly that the common world definition of the term differs from the  
MB definition.

Could it be that we just have to *define* that in MB a person has *one and  
exactly one* LegalName?

>> Offtopic:  RFV already?
>
> Yeah, there was no response on the other thread any more and this RFV  
> was the consensus of that discussion. It's a bit strange that people  
> start to object to the 'apply attribute automatically' bit now instead  
> of earlier.
>
> I have to agree with the arguments given and we shouldn't apply the  
> 'legal' attribute to the existing ARs automatically for the reasons they  
> pointed out. I do, however, see no reason to leave the 'legal name'  
> attribute out or change it. I can't think of any other way of naming it  
> and I think we all agree that we should be able to make the distinction.
(Continue reading)

Permalink | Reply |
headers
Kerensky97 | 4 Dec 2006 22:41

Re: RFC: How to handle band/artist name changes (Was a RFV)


I want to bring this thread back to life.  It's a good idea, we just need to
wrap up a few loose ends.
In response to Don's questions:

1.  I think the release should be placed under whatever name is on the cover
as we usually do, so no big changes.  If we don't have the cover for
reference we place it under the name the artist was using at the time of
release.  Obviously some re-issues could pose problems, I don't see any good
solution other than to deal with it as it comes.  Perhaps just go with the
most popular or most current of the two names that the release is officialy
under.

2. I don't see much problem of relationship clusters as long as we keep
things linear and dated.
So artist A became artist B in 1999, artist B became artist C in 2001,
artist C became artist D in 2002.  There might be some issue if artist D
decides to become artist A again in 2005, but if the dates matchup it
shouldn't be a problem should it?

BTW:  Does this remind anybody else of Monty Python's "Rock Notes?"
Dead Monkeys are to split up again... :D
(google it if you're confused)

-Kerensky97

DonRedman wrote:
> 
> On Mon, 06 Nov 2006 12:07:03 +0100, Age Bosma wrote:
>
(Continue reading)

Permalink | Reply |
headers
Chris Bransden | 4 Dec 2006 22:55

Re: RFC: How to handle band/artist name changes (Was a RFV)

On 04/12/06, Kerensky97 <kerensky97@...> wrote:
>
> I want to bring this thread back to life.  It's a good idea, we just need to
> wrap up a few loose ends.
> In response to Don's questions:
>
> 1.  I think the release should be placed under whatever name is on the cover
> as we usually do, so no big changes.

sorry i don't think this reflects current practice. some artists
change names all the time, yet we have chosen one artist name to use
as it's the most useful thing to have when tagging.

for example, a silver mt. zion (
http://musicbrainz.org/artist/54a55229-e611-439f-928e-d89919ff9d29.html
) have had at least 4 other names in the past (see aliases  <at> 
http://www.discogs.com/artist/A+Silver+Mt.+Zion ), and they all
reflect actual changes in the lineup/style of the band, yet it would
make finding their albums on, say, my ipod a complete nightmare if we
used all those names.

i know there are other similar and contrary artists in MusicBrainz,
just saying there's definitely no hard rule a the mo :)

chris/gecks
Permalink | Reply |
headers
Jason Bouwmeester | 4 Dec 2006 23:12
Picon

Re: RFC: How to handle band/artist name changes (Was a RFV)

> > 1.  I think the release should be placed under whatever name is on the cover
> > as we usually do, so no big changes.
>
> sorry i don't think this reflects current practice. some artists
> change names all the time, yet we have chosen one artist name to use
> as it's the most useful thing to have when tagging.
>
> for example, a silver mt. zion (
> http://musicbrainz.org/artist/54a55229-e611-439f-928e-d89919ff9d29.html
> ) have had at least 4 other names in the past (see aliases  <at> 
> http://www.discogs.com/artist/A+Silver+Mt.+Zion ), and they all
> reflect actual changes in the lineup/style of the band, yet it would
> make finding their albums on, say, my ipod a complete nightmare if we
> used all those names.

I sorta understand this, I thought this way as well when I first
started using MB. But then I learned that I had to stop thinking of MB
primarily as a tagging tool and start thinking of it as a music data
archiving tool. Too many times I got hung up on edits because of the
way it would "mess up" my tagging ;) - I still fall into that trap
occasionally but hey, that's what manually taggers are for - those
rare instances that MB is slightly different than the way you desire
your items to be tagged. I agree with having the artist releases
entered in MB with the name as it is listed on the cover providing
that the release is an official release by the band/artist, and that
was the band/artist's official name at the time of release.

As an aside, another artist with varying names over the years -
Prince. Prince, Prince and the Revolution, Prince and the New Power
Generation and then of course the ungodly symbol/The Artist Formerly
(Continue reading)

Permalink | Reply |
headers
Chris Bransden | 5 Dec 2006 00:20

Re: RFC: How to handle band/artist name changes (Was a RFV)

On 04/12/06, Jason Bouwmeester <jbouwmeester@...> wrote:
> > > 1.  I think the release should be placed under whatever name is on the cover
> > > as we usually do, so no big changes.
> >
> > sorry i don't think this reflects current practice. some artists
> > change names all the time, yet we have chosen one artist name to use
> > as it's the most useful thing to have when tagging.
> >
> > for example, a silver mt. zion (
> > http://musicbrainz.org/artist/54a55229-e611-439f-928e-d89919ff9d29.html
> > ) have had at least 4 other names in the past (see aliases  <at> 
> > http://www.discogs.com/artist/A+Silver+Mt.+Zion ), and they all
> > reflect actual changes in the lineup/style of the band, yet it would
> > make finding their albums on, say, my ipod a complete nightmare if we
> > used all those names.
>
> I sorta understand this, I thought this way as well when I first
> started using MB. But then I learned that I had to stop thinking of MB
> primarily as a tagging tool and start thinking of it as a music data
> archiving tool. Too many times I got hung up on edits because of the
> way it would "mess up" my tagging ;)

it's not just tagging, though. there's also the fact that if you
represent all names, you lose a cohesive 1 page discography. also,
with ARs being displayed the way they are, the proposed name 2 name
relationship would get hidden, when it really would be the MOST
important relationship and have to be split from all the others. and
finally, we'd get users adding releases to the wrong names/dupes/etc.

another thing is we'd have to start to define the difference between a
(Continue reading)

Permalink | Reply |
headers
Kerensky97 | 5 Dec 2006 22:53

Re: RFC: How to handle band/artist name changes (Was a RFV)


Gecks wrote:
> 
>> > sorry i don't think this reflects current practice. some artists
>> > change names all the time, yet we have chosen one artist name to use
>> > as it's the most useful thing to have when tagging.
> 
I've seen just the opposite happen on the database, many artists have
annotations that specify the artist was once known as something else.  The
lineup didn't even change, they just started producing albums under a
different name (usually due to copyright issues).

http://musicbrainz.org/artist/ef58d4c9-0d40-42ba-bfab-9186c1483edd.html
DragonForce 
http://musicbrainz.org/artist/8bf9b24b-e802-4ab6-b342-b348e20b58d4.html
Rhapsody  

Gecks wrote:
> 
> it's not just tagging, though. there's also the fact that if you
> represent all names, you lose a cohesive 1 page discography. also,
> with ARs being displayed the way they are, the proposed name 2 name
> relationship would get hidden, when it really would be the MOST
> important relationship and have to be split from all the others. and
> finally, we'd get users adding releases to the wrong names/dupes/etc.
> 

This was the argument I used when I brought up the issue in irc that artists
were changing their names and that I should tag them under their new (or in
this particular case their old) popular name.  I was told that the database
(Continue reading)

Permalink | Reply |
headers
Chris Bransden | 6 Dec 2006 10:49

Re: RFC: How to handle band/artist name changes (Was a RFV)

On 05/12/06, Kerensky97 <kerensky97-KziSZbPa8DwnEVtka5Vzhw@public.gmane.org> wrote:



Gecks wrote:
>
>> > sorry i don't think this reflects current practice. some artists
>> > change names all the time, yet we have chosen one artist name to use
>> > as it's the most useful thing to have when tagging.
>
I've seen just the opposite happen on the database, many artists have
annotations that specify the artist was once known as something else.  The
lineup didn't even change, they just started producing albums under a
different name (usually due to copyright issues).


http://musicbrainz.org/artist/ef58d4c9-0d40-42ba-bfab-9186c1483edd.html
DragonForce
http://musicbrainz.org/artist/8bf9b24b-e802-4ab6-b342-b348e20b58d4.html
Rhapsody


yep i said *some* artists. i'd say there's a lot more 'combined' than 'split', but the latter of course is more immediately apparent, whilst you'd have to route around aliases/know the artist to know if the former was taking place.

Gecks wrote:
>
> it's not just tagging, though. there's also the fact that if you
> represent all names, you lose a cohesive 1 page discography. also,
> with ARs being displayed the way they are, the proposed name 2 name
> relationship would get hidden, when it really would be the MOST
> important relationship and have to be split from all the others. and
> finally, we'd get users adding releases to the wrong names/dupes/etc.
>

This was the argument I used when I brought up the issue in irc that artists
were changing their names and that I should tag them under their new (or in
this particular case their old) popular name.  I was told that the database
should most closely reflect the release and that the facts shouldn't be
changed to fit the database; the database should be fixed to best display
the facts.

there's no hard rule. it depends who you ask :)

I don't think we should change their name from what it is on the release we
just need a better way to display information about former names.  I'm not
sure how NGS will or could address this but I thought it would be neat if
the Artist's releases under former names would show on the discography but
be greyed out, in a smaller font, or in a compacted form.

indeed. and the tagger should have functionality to give you the option of using the current, release-specific, or most "popular" (how to define??) name.

Until something better comes along I still think it's best to list the
releases under the name they have on the album; and an AR that links
previous names to their current names would help things alot.

agree with the latter. for artists that are split we need a relationship that links them together, however this shouldn't be used to change the criteria we use to split artists (currently there is none - it is one of the many things that is solved ad hoc by subscribers of that artist). this discussion always seems to come back to that but it is unnecessary at this point.

And until a
better solution comes along we'll just have to keep renaming our personal
libraries to keep an the releases together for an artist who can't decide on
a name (Prince will always be Prince to me, none of that symbol nonsense).

like i said, it's not just about tagging...
 
chris/gecks
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Permalink | Reply |
headers
Jason Bouwmeester | 6 Dec 2006 01:52
Picon

Re: RFC: How to handle band/artist name changes (Was a RFV)

> Until something better comes along I still think it's best to list the
> releases under the name they have on the album; and an AR that links
> previous names to their current names would help things alot.  And until a
> better solution comes along we'll just have to keep renaming our personal
> libraries to keep an the releases together for an artist who can't decide on
> a name (Prince will always be Prince to me, none of that symbol nonsense).
>
> -Kerensky97

I agree!

~jb/haeretik
Permalink | Reply |
headers
Lauri Watts | 6 Nov 2006 13:23
Picon

Re: RFV: How to handle band/artist name changes

On 11/6/06, Age Bosma <agebosma@...> wrote:
> Kerensky97 wrote:
> > Add me as another person who really likes this idea but not the wording of
> > "legal".  If we can just think of a different way to word it I think it
> > would be great.
> >
>
> Who are the other people who don't like the wording of 'legal'? ;-)

Me and Freso at least.

Regards,
--

-- 
Lauri Watts
Permalink | Reply |
headers
Frederik 'Freso' S. Olesen | 7 Nov 2006 07:51
Picon

Re: RFV: How to handle band/artist name changes

2006/11/6, Lauri Watts <krazykiwi@...>:
>On 11/6/06, Age Bosma <agebosma@...> wrote:
>>Kerensky97 wrote:
>>>Add me as another person who really likes this idea but not the wording of
>>>"legal". [...]
>>
>>Who are the other people who don't like the wording of 'legal'? ;-)
>
>Me and Freso at least.

I was about to say Lauri and I, but I guess the above works just as well! :)

--

-- 
Frederik 'Freso' S. Olesen <http://freso.dk/>
Permalink | Reply |

Gmane