[mb-style] Lets put GettingRidOfFeaturingArtistStyle to the vote.

[g0llum]

> The point is if they exists individually there is no need to create a new
> entity to describe them AND again describe them using AR. From a database
> design perspective that is a loss in data integrity. All that proposal

The idea is, to add the AR's to the compound artists such that they will be
easier to identify. The Peter & Garfunkel example has band members linked,
but collaborations have "collaborated on" artists linked. you can assume
that most of the collaborations could be split to "Artist 1" "Compound
character" "Artist 2", whereas compound character is a list of "&" "+"
"presents" "and" "vs." etc. disocgs has a good, and clear guideline covering
this, and the goal is to have a similar way of entering collaborations:
http://help.discogs.com/wiki/SubmissionGuidelinesArtist

> I think you have the wrong assumptions. I'm talking about the very
> relationships YOU mentioned on the dev list where track level AR is
> visible.
> I'm also talking about these relationships being usable by taggers.

ok, but the AR's which describe what artist performed what on a track are
not the same thing as artist-artist relationships. If one were to enter all
the "performed on" relationships on all the tracks of a certain
collaboration which were released on all kinds of VA-albums, that's
redundant and nobody ever does that. (i have yet to see an _single artist_
album, where the different releases (us/europe/jp) have the same ARs defined
on the tracks)

g0llum

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[g0llum]

>> <warning -- grumpy sweary scotsman ahead>

hehe, you let off some steam, which i tried to refrain from ;-)

> Artist B' there are numerous duplicate possible variations of the same
> entity.
>
> Artist A & Artist B, Artist A and Artist B, Artist A feat. Artist B,
> Artist B & Artist A, Artist B and Artist A, Artist B feat. Artist A

first, i expect some level of sanity of the users of the system. if we have
a intermediate solution, the editing and voting would have to respect this.
i'd vote strongly against creating new artists for every permutation of some
artist names (and usually they don't use many), but only one, and
merging/adding alias with the permutations to it. Secondly, artists with
feat. in them is just plain wrong, and will be voted down upon sight. it's
possible that some different permutations from your example might occur, but
not in a regular fashion. in the realistic timeline of several months until
we're able to handle it, this would not lead into huge amounts of wrong data
IMO (not wronger than splitting up tracks as to SG5, which is not done
consistently as well)


_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Cristov Russell]

> >> <warning -- grumpy sweary scotsman ahead>
>
> hehe, you let off some steam, which i tried to refrain from ;-)
>
> > Artist B' there are numerous duplicate possible variations
> of the same
> > entity.
> >
> > Artist A & Artist B, Artist A and Artist B, Artist A feat.
> Artist B,
> > Artist B & Artist A, Artist B and Artist A, Artist B feat. Artist A
>
> first, i expect some level of sanity of the users of the
> system. if we have a intermediate solution, the editing and
> voting would have to respect this.
> i'd vote strongly against creating new artists for every
> permutation of some artist names (and usually they don't use
> many), but only one, and merging/adding alias with the
> permutations to it. Secondly, artists with feat. in them is
> just plain wrong, and will be voted down upon sight. it's
> possible that some different permutations from your example
> might occur, but not in a regular fashion. in the realistic
> timeline of several months until we're able to handle it,
> this would not lead into huge amounts of wrong data IMO (not
> wronger than splitting up tracks as to SG5, which is not done
> consistently as well)

This was in reference to the statement that new users just add Artist A &
Artist B already. If they already exist in the database but someone searches
on another variant then users will still enter another variation. How is
that helpful? It isn't. It exacerbates the issue.

Those who are pro "what's on the cover" would disagree with Artist A feat.
Artist B being wrong as well. It's also from a tagging perspective, the most
logical place to put the information at the track level.

________________________________
Cristov (wolfsong)

BorgDOS 5.0: Assimilate another (Y/N)?


_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Jan van Thiel-2]

On 11/8/05, Cristov Russell <wolfsong@...> wrote:
> This was in reference to the statement that new users just add Artist A &
> Artist B already. If they already exist in the database but someone searches
> on another variant then users will still enter another variation. How is
> that helpful? It isn't. It exacerbates the issue.

Of course, if there are two collaborations "A & B" and "A and B" they
will be merged, just like this is done for groups at the moment. I
don't expect users to go and rename them to exactly what's listed on
the cover; that doesn't happen with groups either. Users probably only
want to see reflected in the artist field that A and B collaborated.

If collaborations are treated the same as groups in the SG (of course
'feat.' entries still will be split up), I don't foresee any new
problems. Implementation cost is none and users will be satisfied
(well, apparently not all...). And if an extra artist type
'Collaboration' would be implemented as an interim solution, these new
collaboration artists can be automatically transformed to the correct
style when Picard AR (The Next Generation) has been implemented.

Jan

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Robert (Jamie) Munro]

Stefan Kestenholz wrote:

>
>
>>>Cocker & Jennifer Warnes" is in the database at the moment,
>>>since some releases have been added with this artist after my
>>>'cleanup'. Which is proof for the fact that it's more
>>>intuitive to list such a track as if the new proposal was the rule.)
>>
>>Apples and oranges Jan. We're not really talking about the
>>people that make
>
>
> No it's not! A NAMED collaboration is a group artist entity (does not matter
> if members are linked with collaborated on/member of relationships), and a
> collaboration between some artists is "Artist A & Artist B". All we have to
> do is allow to store these artists as a new entitiy in the database, and
> take care of them once we support N:M relationships between artist <->
> (album|track) like discogs does. We'll support all the different names to
> glue them together (vs., and, presents, + ...) and solve this once and for
> all. This has been discussed and approved with lukz and ruaok, and consensus
> is we'll do that. But now, we do not have to break up the collaboration
> artists into "artist a" - "track (feat. Artist B)" anymore. It doesn't even
> matter on how many tracks they collaborated on, just store it how it is.
>
>
>>that the style needs updating. We know that there are flaws
>>in the UI, we
>>just updated it to make improvements but we haven't yet
>>updated to make some
>>AR relationships clearly visible.
>
>
> The AR's will never be visible in a way you're assuming it will! There will
> always be the distinction between core data (artist-album-track) and
> advanced relationships,

That was proposed by ruaok, because he thought the database could not
cope with it. I have argued that the database should cope no problem,
and it may even reduce database access if we do the opposite and turn
everything into AR (currently we look at the AR and the primary data for
an entity whenever we show it in the UI - we could /just/ look at the
AR). What will increase database load uneccesarily is if you have to go
and add every track performed by an artist linked by AR to the list of
tracks performed by an artist - e.g. Under pressure should show up in
the listing for Queen, and the listing for David Bowie. If it is stored
under a separate "David Bowie and Queen" artist, that causes a lot more
work for the interface to attempt to integrate.

Looking longer term the other major database change that needs to
happen, and is kind-of therem in the underlying data, but not in the UI
is that the same track should be the same track no matter which / how
many albums it is on. One of the problems with it at the moment is that
the identical track on "David Bowie's greatest hits" and the album
"Queen's greatest hits" (hypothetical albums - I haven't checked they
really exist), it has two different performers ("David Bowie" and
"Queen" respectively) and two different names ("Under pressure (feat.
Queen)" and "Under pressure (feat. David Bowie)" respectively). My
proposal resolves all this nonsense and helps the database improve in
the long view.

The other thing is that I don't want style guidelines to diverge from
classical music whenever possible. I don't think anyone would argue that
we should have horrible colaboration artsts like "Beethoven sung by
Pavaroti, played by the London Philarmonic Orchestra with Nigel Kennedy
on lead violin" for classical music, so I don't see why we need the same
for non-classical. Getting rid of non-AR primary artists also means that
classical music would no longer be filed under it's composer as a
primary artist. It would be filed under it's composer as a composer and
only as a composer, and it would all get a lot simpler.

The (feat. ) in track titles is only there until we put the information
in AR. It can go away now, but there is a good argument to leave it
until we fix taggers to get the information from AR and tag it into the
artist field.

Robert Munro


_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

On Tue, 08 Nov 2005 03:07:52 +0100, Rod Begbie wrote:

> <warning -- grumpy sweary scotsman ahead>

<germans seem to have a different form of getting angy> :-)

> On 11/7/05, Cristov Russell <wolfsong@...> wrote:
>> The point is if they exists individually there is no need to create a  
>> new entity to describe them AND again describe them using AR. From a  
>> database design perspective that is a loss in data integrity.
>
> Bollocks.

No it's not. That is the point you do not see: The revised proposal still  
has the problem, that the information about performing artists is moved  
away from an 'integer' state, in which all these relationships are stored  
on an artist-(album/track) level, to a less 'integer' state, in which some  
are stored on the artist-(album/track) and others on the artist-artist  
level.

> It doesn't affect data integrity *in the slightest*.  Everything is
> still stored in relational tables,

Of course the AR tables are still 'integer'. But the AR tables define  
datastructures. They are meta-tables. Chrstov and me are referring to the  
datastructure which is _defined_ in the AR tables and the guidelines. That  
is why I am so opposed to changing the guidelene, becuase THE GUIDELINE  
DEFINES DATA STRUCTURE. Here is the difference:

== Method 1 ==

Track1 is performed by Artist1
Track1 is performed by Artist2

== Method 2 ==

Track1 is performed by Artist1AndArtist2
Artist1AndArtist2 is a collaboration of Artist1
Artist1AndArtist2 is a collaboration of Artist2

Do you see the difference? Do you see that the entity Artist1AndArtist2 is  
pretty unusable for a lot of relational operations? Do you see that you  
need two runs to find out which single entities performed Track1? Do you  
see that users will have to "swing from tree-to-tree (literally) until  
[they]'ve found the artist linked over god knows how many different  
performance names/groups/artists" (quoting Stefan)?

   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@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

On Tue, 08 Nov 2005 14:16:48 +0100, Robert (Jamie) Munro wrote:

>> The AR's will never be visible in a way you're assuming it will! There  
>> will
>> always be the distinction between core data (artist-album-track) and
>> advanced relationships,
>
> That was proposed by ruaok, because he thought the database could not
> cope with it. I have argued that the database should cope no problem,
> and it may even reduce database access if we do the opposite and turn
> everything into AR (currently we look at the AR and the primary data for
> an entity whenever we show it in the UI - we could /just/ look at the
> AR). What will increase database load uneccesarily is if you have to go
> and add every track performed by an artist linked by AR to the list of
> tracks performed by an artist - e.g. Under pressure should show up in
> the listing for Queen, and the listing for David Bowie. If it is stored
> under a separate "David Bowie and Queen" artist, that causes a lot more
> work for the interface to attempt to integrate.
>
> Looking longer term the other major database change that needs to
> happen, and is kind-of therem in the underlying data, but not in the UI
> is that the same track should be the same track no matter which / how
> many albums it is on. One of the problems with it at the moment is that
> the identical track on "David Bowie's greatest hits" and the album
> "Queen's greatest hits" (hypothetical albums - I haven't checked they
> really exist), it has two different performers ("David Bowie" and
> "Queen" respectively) and two different names ("Under pressure (feat.
> Queen)" and "Under pressure (feat. David Bowie)" respectively). My
> proposal resolves all this nonsense and helps the database improve in
> the long view.
>
> The other thing is that I don't want style guidelines to diverge from
> classical music whenever possible. I don't think anyone would argue that
> we should have horrible colaboration artsts like "Beethoven sung by
> Pavaroti, played by the London Philarmonic Orchestra with Nigel Kennedy
> on lead violin" for classical music, so I don't see why we need the same
> for non-classical. Getting rid of non-AR primary artists also means that
> classical music would no longer be filed under it's composer as a
> primary artist. It would be filed under it's composer as a composer and
> only as a composer, and it would all get a lot simpler.
>
> The (feat. ) in track titles is only there until we put the information
> in AR. It can go away now, but there is a good argument to leave it
> until we fix taggers to get the information from AR and tag it into the
> artist field.

So the crazy german socilogue[1] does not seem to be the only person  
thinking in this direction. :-)

   DonRedman

[1]  
http://www.nabble.com/-mb-experts-Some-lateral-thoughts-on-feat-t440333c2885.html#a1203914

--
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@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Jan van Thiel-2]

On 11/8/05, Don Redman <donredman@...> wrote:

> == Method 1 ==
>
> Track1 is performed by Artist1
> Track1 is performed by Artist2
>
> == Method 2 ==
>
> Track1 is performed by Artist1AndArtist2
> Artist1AndArtist2 is a collaboration of Artist1
> Artist1AndArtist2 is a collaboration of Artist2
>
> Do you see the difference? Do you see that the entity Artist1AndArtist2 is
> pretty unusable for a lot of relational operations? Do you see that you
> need two runs to find out which single entities performed Track1? Do you
> see that users will have to "swing from tree-to-tree (literally) until
> [they]'ve found the artist linked over god knows how many different
> performance names/groups/artists" (quoting Stefan)?

Yes, I see the difference. But
1) The only non-human users of the database at the moment are taggers.
None of them supports any AR. So the two necessary 'runs' mentioned
above are of no interest right now.
2) The tagger will only be enhanced with AR functionality *after* the
database scheme has been changed. Which will render the present SG5
and the proposal obsolete. Applying the proposal might actually reduce
the amount of editing necessary after the new AR functionality has
been deployed.

So although the Collaboration proposal isn't good for the long run, it
is good for now. Even better than the present SG5.

Jan

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Robert (Jamie) Munro]

Rod Begbie wrote:

> <warning -- grumpy sweary scotsman ahead>
>
> On 11/7/05, Cristov Russell <wolfsong@...> wrote:
>
>>The point is if they exists individually there is no need to create a new
>>entity to describe them AND again describe them using AR. From a database
>>design perspective that is a loss in data integrity.
>
>
> Bollocks.
>
> It doesn't affect data integrity *in the slightest*.  Everything is
> still stored in relational tables, with no more duplication that
> occurs now,

Your saying that adding "David Bowie and Queen" to a table that has
"David Bowie" and "Queen" already in it isn't duplication? That's
obviously rubbish.

> where we have some users enter "Artist 1  (feat. Artist
> 2)", some enter "Artist 2 (feat. Artist 1)"

That was always meant as a temporary solution until AR worked. AR works.
The links have largely been made. That's only still there because people
expressed a preference to keep it until

>>All that proposal
>>really does is surplant one problem with a new one. I would rather resources
>>be invested in solutions that resolve issues not substitute them for new
>>ones.
>
> Resources?  What bloody resources?  I'm asking someone to change a
> wiki page to a new guideline.  A change which currently has a great
> deal of support from the "community".

Users Editing time is a resource. There's no point having users edit to
the wrong solution.

I've realised that people don't know the big picture that I explained in
my other post.

Namely, the same recording should be in the database once, no matter how
many albums it appears on. This is pretty important for TRM and it's
replacement - a lot of "errors" on the TRMs that map to more than one
track report are actually TRMs mapping to the same track on different
albums.

Secondly, Classical and Non-Classical music should be filed the same
way. Not one under composer and one under performer.

Ideally, we would separate pieces of music from their recordings, so
that you could find cover versions of songs easily, and tie the composer
to the piece and conductor to the performer etc., but that is several
more steps down the road.

Robert (Jamie) Munro

Ps. I don't know about other people, but I came to MB as a musical
version of IMDB (see imdb.com). You should be able to click on someone
who was involved in something in any role, and see what else they were
involved in, then click on that thing and see who else was involved. AR
allows that.

The fact that software like the tagger and CD rippers can use it is only
a bonus, albeit a pretty important one.


_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Rod Begbie]

On 11/8/05, Robert (Jamie) Munro <rjmunro@...> wrote:
> Your saying that adding "David Bowie and Queen" to a table that has
> "David Bowie" and "Queen" already in it isn't duplication? That's
> obviously rubbish.

No, I'm saying that the database *already has* David Bowie and Queen
(http://musicbrainz.org/newsearch.html?limit=25&table=artist&search=david+bowie)
so changing the style guide to reflect and expect that is pragmatic.

Users are entering it because it's what they expect.

Users will continue to enter it that way (hell, I know I will),
whatever SG5 says.

Some may be caught and modded by mo.

Most will probably be ignored.

Hence, no loss of data integrity by changing SG5.

Rod.

--
:: Rod Begbie :: http://groovymother.com/ ::

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Rod Begbie]

On 11/8/05, Don Redman <donredman@...> wrote:
> Do you see the difference? Do you see that the entity Artist1AndArtist2 is
> pretty unusable for a lot of relational operations? Do you see that you
> need two runs to find out which single entities performed Track1?

How.  Is.  That.  Any.  Different.  From.  "Named.  Collaborations."?

To find out that Paul McCartney performed "Come Together" on the Help
compilation, you need to know that he was a "member" for the day of
"The Smokin' Mojo Filters".

> Do you
> see that users will have to "swing from tree-to-tree (literally) until
> [they]'ve found the artist linked over god knows how many different
> performance names/groups/artists" (quoting Stefan)?

If we force users to *literally* swing from tree-to-tree, then we've
made advancements in software design far exceeding simple metadata.

How do users get the tree/PC interface?  Are trees USB-2.0 compliant?
Are there any patents on wood-based or swinging-controlled user
interfaces?

(Sorry!  Misuse of the word "literally" is a pet peeve of mine)

Rod.

--
:: Rod Begbie :: http://groovymother.com/ ::

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[g0llum]

> Yes, I see the difference. But
> 1) The only non-human users of the database at the moment are taggers.
> None of them supports any AR. So the two necessary 'runs' mentioned
> above are of no interest right now.
> 2) The tagger will only be enhanced with AR functionality *after* the
> database scheme has been changed. Which will render the present SG5
> and the proposal obsolete. Applying the proposal might actually reduce
> the amount of editing necessary after the new AR functionality has
> been deployed.
>
> So although the Collaboration proposal isn't good for the long run, it
> is good for now. Even better than the present SG5.

this is the definitive statement, there is nothing more to say from the
supporters. if there ever was a benevolent dictator, this is where one
should come in an get this issue decided ;-)

g0llum

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Gecks]

----- Original Message -----
From: "Cristov Russell" <wolfsong@...>
To: "'MusicBrainz style discussion'" <musicbrainz-style@...>
Sent: Tuesday, November 08, 2005 4:28 AM
Subject: RE: [mb-style] Let's get rid
oftheGettingRidOfFeaturingArtistStylediscussion NOW!!
> Another problem I have with the proposal is that it potentially increases
> the number of Various Artist releases to the point where release
> duplication
> will increase or data will be inaccurate because EVERY time a guest artist
> appears on the release a new entity would need to be entered

well, not every time - infact, hardly ever. most (i think it's fair to say
that) instances of (feat. x) are correct. it is only the true 50:50
collaborations that will end with a new 'x & y' artist, under the new
system.

> and the only
> way to have entity appear on a single track is to convert to VA. That is a
> nightmare!

It is already a 'nightmare' - take this:
http://musicbrainz.org/album/c8bfe5fe-8bc0-43da-8d19-8f37c1acbb15.html -
dinosaur jr 'greatest hits' - it's a VA release because it features some
solo j mascis songs. stupid :/

There should be a way of 'forcing' a VA album to be credited under a
particular artist(s). might be useful for remix albums, too, when an artist
remixes all the tracks present.

Cheers,
Chris B (Gecks)

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

On Tue, 08 Nov 2005 15:50:40 +0100, Rod Begbie wrote:

> On 11/8/05, Don Redman <donredman@...> wrote:
>> Do you see the difference? Do you see that the entity Artist1AndArtist2  
>> is
>> pretty unusable for a lot of relational operations? Do you see that you
>> need two runs to find out which single entities performed Track1?
>
> How is that any different from "named collaborations"?
[slight appeasement reformatting applied]
>
> To find out that Paul McCartney performed "Come Together" on the Help
> compilation, you need to know that he was a "member" for the day of
> "The Smokin' Mojo Filters".

There is some additional information in this statement: The collaboration  
between Johnny Depp, Noel Gallagher, Paul McCartney and Paul Weller is  
called "The Smokin' Mojo Filters".

There is no additional information in this one though: The collaboration  
between David Bowie and Queen is called "David Bowie and Queen".

That's a difference that makes a difference to me.

But it does not make a difference to you, it seems. The reason is, I  
believe, that we are discussing different things. You care about the way  
data is displayed in the current interface. I care about the way data is  
stored and will be handled.

So, to prove that we don't need a dictator here (benevolent or not): If  
the proposal contains an additional artist type, whose main purpose is to  
tag collaborations as something that will be dissolved in the future, I  
will be happy with it.

I would still like to wait for the Summit. Mainly because I feel that the  
ideas Robert Munroe and me have been proposing have not made their way to  
Robert Kaye or Lukas yet, but these guys should at least know about them  
and reject them on solid grounds, before they design new m:n core  
relationships.

My fear is that if the database can be based on AR as we say, then the  
proposed replacement of SG5 will be a pain in the ass to get over.

But this is a long shot from your very concrete and pragmatic problems, so  
I do not expect you to have any sympathy for this.

   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@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

On Tue, 08 Nov 2005 15:42:25 +0100, Rod Begbie wrote:

> On 11/8/05, Robert (Jamie) Munro <rjmunro@...> wrote:
>> Your saying that adding "David Bowie and Queen" to a table that has
>> "David Bowie" and "Queen" already in it isn't duplication? That's
>> obviously rubbish.
>
> No, I'm saying that the database *already has* David Bowie and Queen
> (http://musicbrainz.org/newsearch.html?limit=25&table=artist&search=david+bowie)
> so changing the style guide to reflect and expect that is pragmatic.
>
> Users are entering it because it's what they expect.
>
> Users will continue to enter it that way (hell, I know I will),
> whatever SG5 says.
>
> Some may be caught and modded by mo.
>
> Most will probably be ignored.
>
> Hence, no loss of data integrity by changing SG5.

That argumentation is stupid, sorry. You are arguing like this: We have a  
user interface that is not adapted to the datastructures. Hence people are  
confused by the interface and enter data in a way that creates duplication  
(you did not object to the statement that this is duplication). Therefore  
we should adapt the guidelines to the way users enter data.

To me this calls for a redesign of the interface, not an adaption of the  
style guides to the sysmptoms.

   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@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Rod Begbie]

On 11/8/05, Don Redman <donredman@...> wrote:
> But it does not make a difference to you, it seems. The reason is, I
> believe, that we are discussing different things. You care about the way
> data is displayed in the current interface. I care about the way data is
> stored and will be handled.

Not true *at all*.  I'm really very passionate about MB having a good
solid database.

My primary viewpoint:  My full-time job is as a software engineer for
a company which produces consumer electronics.  We currently have
products out there that use embedded databases of music metadata.  My
research role specifically relates to using music metadata to enhance
the listening experience.  And I'd love to bring MB into the mix here.

So a large part of my viewpoints on MB things come from:  How can MB
be more competitive with established databases like AMG, Muse,
Gracenote, etc.?

This part of me thinks that the long-term plan as discussed in this
thread and ones like it is spot-on.


My secondary viewpoint:  I'm re-ripping my CD collection at the moment
to FLAC, and using MB metadata extensively.  I would like the Album,
Artist and Title ID3 tags to contain the Album, Artist and Title
information for the track in question.  I don't want one of the artist
names in the Title field, and it pissed me off when I add an album --
with the CD sleeve in front of me, and with contextual knowledge of
the artist and performance in question -- and mo comes along and
removes the data with no evidence, because it's what he thinks is
right, based on SG5.

This part of me is going to get pissed off for the next year or two
every time someone irrevocably fucks up the data in the name of SG5.


When I see this album:
http://musicbrainz.org/artist/89ad4ac3-39f7-470e-963a-56509c546377.html,
I weep.  Because not only is the metadata horrendously mangled,
there's no way to reverse it back out again.

In the same way that you can't turn the handle backwards and get a pig
out of a sausage machine, there's now *no* way to take that album and
automatically get the fact that the performance should be attributed
to "Helmet & House of Pain".  You don't know if the (feat.) artist is
an equal or minor collaborator on the track, or how they should be
attributed.

Whereas, if it were attributed to an artist called "Helmet & House of
Pain", and "Helmet" and "House of Pain" were collaborators on that
artist, a future automatic process would have a fighting chance of
making that association.

I'm so sick to fucking death of repeating this.  There's overwhelming
support for this idea, and it's coming from educated users of the
site, not "random voters".

Rod.

--
:: Rod Begbie :: http://groovymother.com/ ::

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Rod Begbie]

On 11/8/05, Don Redman <donredman@...> wrote:
> To me this calls for a redesign of the interface, not an adaption of the
> style guides to the sysmptoms.

Yay kids, it's pisspoor metaphor time:  Let's imagine I've got the flu.

To treat the symptoms, I can take an aspirin every few hours.

To fix the problem, I have to spend decades researching viruses and cures.

I'd love for the problem to be fixed, and look forward to the day when
it happens.  In the meantime, I'll continue popping aspirin.

I (and lots of other MB users) would like the five-minute fix to
happen while we wait for the cure.

Rod.

--
:: Rod Begbie :: http://groovymother.com/ ::

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[orion-6]

Don Redman <donredman@...> wrote:
 >> In addition to the delay of waiting it also feels a bit exclusionary.
 >> I  realize that's quite obviously not your intent, but not everyone
 >> participating in this debate is in Europe or free to show up on that
 >> date.  It's easy enough to know in my head the value of in person
 >> meetings of an influential portion of a community can have and it's
 >> quite likely that a good solution might come out of it.  That doesn't
 >> stop some part of me seeing it as "thanks for your time, we'll let
 >> you  know what we decide" after everyone's contributed to a
 >> collaborative  discussion like this online.
 >
 >
 >Oh, I did not mean that at all. Nor did I want to promote a summitwhich
 > I  can attent, so that the outcome will be more to my liking(something
 > you  did not accuse me of).

Nor did I really think so, but there was that element to it and I
thought it best to point it out.

Don Redman <donredman@...> wrote:
 > There is no additional information in this one though: The
 > collaboration  between David Bowie and Queen is called "David Bowie
 > and Queen".

Response to this way at the bottom.

Rod Begbie wrote:

> On 11/8/05, Don Redman <donredman@...> wrote:
>
>>Do you see the difference? Do you see that the entity Artist1AndArtist2 is
>>pretty unusable for a lot of relational operations? Do you see that you
>>need two runs to find out which single entities performed Track1?
>
>
> How.  Is.  That.  Any.  Different.  From.  "Named.  Collaborations."?
>
> To find out that Paul McCartney performed "Come Together" on the Help
> compilation, you need to know that he was a "member" for the day of
> "The Smokin' Mojo Filters".

I think this is at the core of the debate, the concept of what
constitutes a name for a collaboration.

Before I go further it feels like I need some concrete examples:
EXILE had tracks on a compilation
http://musicbrainz.org/album/6531b63a-7f36-454f-9a07-986ed631f452.html 
99% Radio Show with several other artists.  The album had an intro, an
outro, and one "actual" track with all the artists on the compilation
together on it, that were credited to "99% Radio Allstars" for the
collaboration.  Later that track appeared on an album by EXILE
http://musicbrainz.org/album/a7ef4551-2d83-483f-ab7d-9c93ed720a32.html 
but was initially added by someone as "EXILE - Be Mine (feat. 99% Radio
Allstars) even though it was the exact same version and was credited on
the album itself as being by 99% Radio Allstars.  I fixed that entry but
a search just now turned up
http://musicbrainz.org/album/a3f34684-7559-46b3-95b0-8b1d78d03cb9.html 
their best album from earlier this year where once again it was added
wrongly as "EXILE - Be Mine (feat 99% Radio Allstars" - same version as
was on the compilation.

As far as I'm aware no one is arguing that "99% Radio Allstars"
shouldn't be added as a group with the tracks under them, but this is
one example of a case where people tend to make mistakes because of that
guideline - since it's on an EXILE album it's easy enough to think the
song is by "EXILE & 99% Allstars" and then change that to "(feat. 99%
Allstars)" even though it's just simply by 99% Radio Allstars.

Next we have m-flo, who have been making music with various artists for
about 3 years now since their singer left (they still have a rapper
(verbal) and a DJ (DJ Taku)) using two formats - m-flo loves <artist(s)>
if it's an m-flo release or artist loves m-flo if it's a release by
someone else with the music produced by DJ Taku and usually featuring
some rapping by Verbal.  From a quick count of the m-flo loves * ones
there have been 2 albums, 2 remix albums, 6 singles, and 3 vinyl only
remix singles plus a DVD.  The level of collaboration varies, some they
pretty much got together in the studio and made the track, others have
been much more extensive.  m-flo loves melody.＆山本領平 - Miss You
single came out in Oct 2003.  It was performed live on several music
shows at the time, appeared on the album and the remix album, had live
and remix versions of it show up as coupling tracks on later singles,
and both melody. and Yamamoto went on m-flo's last couple of tours -
http://melody.at.webry.info/ her blog is full of entries related to it
up until the tour final on the 2nd of this month.

This is one where some would want to change it into "m-flo - song (feat.
artist(s))" and that's how most of them currently are.  To me though
"m-flo loves melody.＆山本領平" is an actual name, and I'd very much
like to see that information recorded, sinec right now we throw it away
completely.  Some of the collaborations have not been very extensive or
long, and while for those ones I can see arguing for changing it to
(feat. artist) you run into consistency issues pretty quickly because of
it.  1 track in the studio versus that 1 track + multiple live
performances on TV and in concerts and a music video over the course of
2 years is obviously different, but since they were named the same it
feels best to keep them that way.

Next there's SEIKO & Crazy.T - Smile on me, a duet collaboration single
between Matsuda Seiko and comedian Ishibashi Takaaki.  By current style
guidelines that would be added under SEIKO - Smile on me (feat.
Crazy.T), a "performed vocals on" AR from both, and then "is a
performance name of" ARs from Matsuda-> SEIKO and Ishibashi -> Crazy.T.
  Or, alternatively, add "SEIKO & Crazy.T" as an artist and then
"collaborated on" ARs from Matsuda and Ishibashi to the name plus the
"performed vocals on" ARs.  The latter makes more inherent sense to me...

Finally, a plain artist1 & artist2 one - MINMI's latest album
"FRIENDS～MINMI featuring works BEST～"
http://www.jvcmusic.co.jp/-/Discography/A017274/VICL-61757.html is a 2
disc compilation of all her work with other artists.  Looking at the
ones with 湘南乃風 (Shonannokaze) in the course of one release you have
(as credited on the album):
MINMI - EVERYDAY feat.湘南乃風
MINMI, 湘南乃風, JUMBO MAATCH, TAKAFIN, BOXER KID, RYO the SKYWALKER,
PUSHIM, MOOMIN, HOME GROWN - FRIENDS
MINMI & 湘南乃風 - SUCK YU MUMA
湘南乃風 - MY WAY feat.MINMI
湘南乃風 - CRY feat.MINMI

Ignoring the 9 artist collaboration in the middle there you have one
credited to her featuring them, 2 credited to them featuring her, and
one credited as her & them.  The artists are distinguishing between 3
different distinct to them levels of collaboration so changing MINMI &
湘南乃風 - SUCK YU MUMA to MINMI - SUCK YU MUMA (feat. 湘南乃風) feels
entirely wrong.  By all means change the feat.artist in the rest to
(feat. artist) but in that case it simply feels wrong to change it.



To me then 99% Radio Allstars, m-flo loves melody.＆山本領平, SEIKO &
Crazy.T, MINMI & 湘南乃風 are all the same - the name of a
collaboration.  The fact that the last one is simply their names
concatenated with an & doesn't mean it doesn't have any additional
information - it stores what symbol they chose to concatenate with and
the order the names are to be concatenated with.  They could have gone
with &, +, と, or any number of others but they chose the character &.
This discrimination of collaborations into types based on what they
called it seems odd to me -  at some future point I'm sure we'll be able
to create the AR relationships "m-flo collaborated on 'Miss You'",
"melody. collaborated on 'Miss You'", and "山本領平 collaborated on
'Miss You'" with an abiltiy to order and name them - ie. a series of
drop down boxes equal to the number of total artists in the
collaboration populated with all their names plus a "leave empty option"
with a freeform text field before and after each one so that you would
have [blank text field][m-flo selected from dropdown list][loves typed
into text field][melody. select from list][&typed into text field][山本
領平][blank text field] set for the collaboration and the track artist
could then be generated from that info, allowing it to be
displayed/tagged as m-flo loves melody.＆山本領平 and still show up on
the pages of all three.  By the same token that would work for named
collaborations you would simply put [99% Radio Allstars] in the first
free text box and leave everything else set to blank for all the artists
collaborating on it.  For MINMI & 湘南乃風 it would be [blank text
box][MINMI selected from drop down][ & typed in text box][湘南乃風]
[blank text box]

That's how I at least envision and expect something collaborations to
eventually be handled which would give you the IMDB like "see everything
they've been involved in" that rjmunro mentioned as long as the ARs are
entered.  From that perspective it's as Rod Begbie said - how is what
DonRedman and wolfsong have been calling "named" collaborations any
different from the other ones?  Dealt with that way there's absolutely
no difference between a collaboration by artist1 and artist2 called "1 &
2's super funtime happy rainbow of love collaboration" and "artist1 and
artist2."  The latter tempts some people to split it up and alter it in
ways that makes it fit the DB a bit better now even though to handle all
those types of collaborations well you'd need a scheme similar to what I
outlined.  I can see how having their names in it makes it tempting to
treat it differently, but since we can only handle one of the cases that
way I'd much rather treat them all as "collaborations" rather than try
to draw up guidelines and argue over what constitutes a "named"
collaboration" and what has "no additional information" in it.



That went long, but I hope I managed to make my point clear.  I didn't
realize it until the last round of emaisl but that appears to be what's
at the root of this discussion: a fairly important difference in
viewpoint as to the information value of a collaboration's name.  I
can't speak for RodBegbie but in my own case I consider "artist1 &
artist2" to have two at least two important pieces of information - the
order of the artists names, which can often be a matter of negotiation
between them (or their record companies or managers or lawyers...) and
the symbol used to indicate the collaborating (I personally have music
in English and Japanese primarily but also French, German, Spanish,
Russian, Thai, Korean, Chinese, and Malaysian so while they might all
signify the same thing the difference between and, with, &, +, y, e, に,
と, ・, ／, etc. becomes more relevant than it may be when your choices
are just "and, &, with")

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Robert (Jamie) Munro]

Tarragon M. Allen wrote:
> ++1. I've always hated SG5's hardline "split all artist pairings" approach. It
> only makes sense in a "database neatness" way, not in a "what the end-user
> expects" way,

But database neatness is what is important in the long term. The user
interface can (and will) be fixed.

> and doesn't achieve anything particularly useful except making
> the track in question appear on one artist's page (_at the expense of the
> other artist, I might add_) and for causing heated arguments in this mailing
> list and in edit notes.

It's not at the expense of the other artist - it shows up in their VA.
As I have already stated it's not about the (feat. ) - that's just a
legacy that can (and probably should) be removed. It's about the AR
being correct.

Jamie


_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

Orion wrote:
> Don Redman wrote:
>  > There is no additional information in this one though: The
>  > collaboration  between David Bowie and Queen is called "David Bowie
>  > and Queen".

> I think this is at the core of the debate, the concept ofwhat  
> constitutes a name for a collaboration.


> That went long, but I hope I managed to make my point clear.  I didn't  
> realize it until the last round of emails but that appears to be what's  
> at the root of this discussion: a fairly important difference in  
> viewpoint as to the information value of a collaboration's name.  I  
> can't speak for RodBegbie but in my own case I consider "artist1 &  
> artist2" to have two at least two important pieces of information - the  
> order of the artists names, which can often be a matter of negotiation  
> between them (or their record companies or managers or lawyers...) and  
> the symbol used to indicate the collaborating.

Yes that was clear. And it also made it clear to me what I believe was the  
other core of the debate: What will and what will not be done with AR.

AR can already store all data _I_ need it to store. It still lacks  
interfaces, but it can store things well. That is the reason why I was  
arguing against something that looks to me like a stupid use of AR, which  
breaks the usability of the stored data for the interfaces to come.  
Furthermore I was arguing so fiercely, because I read the argument of the  
other side as being: Let's just adapt the way of storing data to the  
current interfaces.

Now, you pointed out, that AR _canot_ store all information that _you_  
need. So, to you, it does not matter that much how AR is used to store  
data, because a good solution (good in your eyes) will need a massive  
restructuring of the core DB schema anyway.
I think these different needs stem from the different music subcultures we  
come from.

Or to use Rod's metaphor: Aspirine can give you nosebleed, if you take too  
much of it. To you SG5 is a severe influenza that needs a completely new  
treatement. In that case nosebleed is an acceptable side effect to keep  
the influenza down until the new treatement has been developed.
To me we are experiencing a flu that will pass away once our immune system  
has adapted to the new situation. In this case the benefit of aspirine is  
relatively low and the cost of having nosebleed for a couple of months is  
unacceptable.

The bottom line is, however, that I really do understand your need for  
that complex concatenation system. And your examples show the beauty of  
it: It enables both relational linking of artists _and_ a quasi free-form  
text.

I still believe that MusicBrainz could go for rhizomes and not for trees,  
but that is a different matter and should be discussed in a different  
thread.

For god's sake: Rod can you please go and write up your proposal as an  
alternative on FeaturingArtistStyle? Can we all work to enhance the  
wording and then get over with it?

Or are there other opponents who have an even longer breath than me? ;-)

   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@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style