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

[Rod Begbie]

OK folks, it's been a couple of weeks since anyone has added anything
to http://wiki.musicbrainz.org/GettingRidOfFeaturingArtistStyle

Because I'm fed up with 'mo' dicking around with my moderations, I'd
like to try putting this to a (completely non-binding) vote, using the
Apache Lazy Concensus rules.

Reply to this thread, and simply say +1 if you agree, -1 if you
disagree, or a number in between if you're opinion is in between (see
bottom of this mail for examples).  Also say if you're a member of the
Style Council, or just a mailinglist participant.  Next Saturday
(12th), I'll tot-up the votes.

PROPOSAL: We change FeaturingArtistStyle to read: "When two or more
artists collaborate on a track or release, file the track/release
under the primary artist, and then add "performed on" relationships to
the secondary artists. If no artist can be considered secondary,
create a new artist in the form 'Artist 1 & Artist 2' and add
"collaborated on" relationships to the artists."

I vote +1, but I'm not a Style Council member.

Rod.

-----
Expressing Votes: +1, 0, -1, and Fractions

The voting process in Apache may seem more than a little weird if
you've never encountered it before. Votes are represented as numbers
between -1 and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'

The in-between values are indicative of how strongly the voting
individual feels. Here are some examples of fractional votes and ways
in which they might be intended and interpreted:

    * +0: 'I don't feel strongly about it, but I'm okey with this.'
    * -0: 'I won't get in the way, but I'd rather we didn't do this.'
    * -0.5: 'I don't like this idea, but I can't find any rational
justification for my feelings.'
    * ++1: 'Wow! I like this! Let's do it!'
    * -0.9: 'I really don't like this, but I'm not going to stand in
the way if everyone else wants to go ahead with it.'
    * +0.9: 'This is a cool idea and i like it, but I don't have
time/the skills necessary to help out.'

                       -- http://www.apache.org/foundation/voting.html
--
:: Rod Begbie :: http://groovymother.com/ ::

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

[Cristov Russell]

> OK folks, it's been a couple of weeks since anyone has added
> anything to
> http://wiki.musicbrainz.org/GettingRidOfFeaturingArtistStyle
>
> Because I'm fed up with 'mo' dicking around with my
> moderations, I'd like to try putting this to a (completely
> non-binding) vote, using the Apache Lazy Concensus rules.
>
> Reply to this thread, and simply say +1 if you agree, -1 if
> you disagree, or a number in between if you're opinion is in
> between (see bottom of this mail for examples).  Also say if
> you're a member of the Style Council, or just a mailinglist
> participant.  Next Saturday (12th), I'll tot-up the votes.
>
> PROPOSAL: We change FeaturingArtistStyle to read: "When two
> or more artists collaborate on a track or release, file the
> track/release under the primary artist, and then add
> "performed on" relationships to the secondary artists. If no
> artist can be considered secondary, create a new artist in
> the form 'Artist 1 & Artist 2' and add "collaborated on"
> relationships to the artists."
>
> I vote +1, but I'm not a Style Council member.
>
> Rod.
>
> -----
> Expressing Votes: +1, 0, -1, and Fractions
>
> The voting process in Apache may seem more than a little
> weird if you've never encountered it before. Votes are
> represented as numbers between -1 and +1, with '-1' meaning
> 'no' and '+1' meaning 'yes.'
>
> The in-between values are indicative of how strongly the
> voting individual feels. Here are some examples of fractional
> votes and ways in which they might be intended and interpreted:
>
>     * +0: 'I don't feel strongly about it, but I'm okey with this.'
>     * -0: 'I won't get in the way, but I'd rather we didn't do this.'
>     * -0.5: 'I don't like this idea, but I can't find any
> rational justification for my feelings.'
>     * ++1: 'Wow! I like this! Let's do it!'
>     * -0.9: 'I really don't like this, but I'm not going to
> stand in the way if everyone else wants to go ahead with it.'
>     * +0.9: 'This is a cool idea and i like it, but I don't
> have time/the skills necessary to help out.'
>
>                        -- http://www.apache.org/foundation/voting.html
> --
> :: Rod Begbie :: http://groovymother.com/ ::

Sorry I haven't gotten back to everyone on a process yet; I've been taking
care of my mom post surgery. I have a few things from work to catch up on
but hopefully will have something soon.

Rod I don't think this voting system will work. Mainly because there are
multiple solutions proposed and your system seems to be predicated on a
single change. I do think it's an interesting idea to allow for "levels" of
feeling but it doesn't seem applicable.

Also, if a consensus can be reached with the Style Ministers involved a vote
shouldn't be necessary. There still needs to be a process and control to the
implementation of changes as well which I will include in my proposal.
________________________________
Cristov (wolfsong)

Stay close young hobbits! They say there's a great sorceress lives in these
woods. An elf-witch of terrible power. All who look upon her fall


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

[Gecks]

i'd prefer to keep it, but to only use it when that's how it actually
appears on the tracklisting. a lot of 'bad' edits have been done under the
current guideline - eg putting (feat. x) on stuff like the chemical brothers
use of famous guest vocalists on a lot of tracks - in my experience they
don't credit them beyond a mention in the liner, not on the tracklisting. so
i don't think the SG5 should be applied.

i want the guidelines to organise data found on tracklistings, not
add/remove stuff (within reason). not by default, anyway. once AR info is
transferred to tags, this could all be user preferences in the tagger (eg
you could have 'SomeDudes - FunkyShit (feat. Dave [Bass], Steve [Kazoo])' or
whatever)

not got round to adding this as an alternative on the wiki yet, though.

Cheers,
Chris B
----- Original Message -----
From: "Rod Begbie" <rodbegbie@...>
To: "MusicBrainz style discussion" <musicbrainz-style@...>
Sent: Saturday, November 05, 2005 11:01 PM
Subject: [mb-style] Lets put GettingRidOfFeaturingArtistStyle to the vote.

> OK folks, it's been a couple of weeks since anyone has added anything
> to http://wiki.musicbrainz.org/GettingRidOfFeaturingArtistStyle
>
> Because I'm fed up with 'mo' dicking around with my moderations, I'd
> like to try putting this to a (completely non-binding) vote, using the
> Apache Lazy Concensus rules.
>
> Reply to this thread, and simply say +1 if you agree, -1 if you
> disagree, or a number in between if you're opinion is in between (see
> bottom of this mail for examples).  Also say if you're a member of the
> Style Council, or just a mailinglist participant.  Next Saturday
> (12th), I'll tot-up the votes.
>
> PROPOSAL: We change FeaturingArtistStyle to read: "When two or more
> artists collaborate on a track or release, file the track/release
> under the primary artist, and then add "performed on" relationships to
> the secondary artists. If no artist can be considered secondary,
> create a new artist in the form 'Artist 1 & Artist 2' and add
> "collaborated on" relationships to the artists."
>
> I vote +1, but I'm not a Style Council member.
>
> Rod.
>
> -----
> Expressing Votes: +1, 0, -1, and Fractions
>
> The voting process in Apache may seem more than a little weird if
> you've never encountered it before. Votes are represented as numbers
> between -1 and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'
>
> The in-between values are indicative of how strongly the voting
> individual feels. Here are some examples of fractional votes and ways
> in which they might be intended and interpreted:
>
>    * +0: 'I don't feel strongly about it, but I'm okey with this.'
>    * -0: 'I won't get in the way, but I'd rather we didn't do this.'
>    * -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>    * ++1: 'Wow! I like this! Let's do it!'
>    * -0.9: 'I really don't like this, but I'm not going to stand in
> the way if everyone else wants to go ahead with it.'
>    * +0.9: 'This is a cool idea and i like it, but I don't have
> time/the skills necessary to help out.'
>
>                       -- http://www.apache.org/foundation/voting.html
> --
> :: Rod Begbie :: http://groovymother.com/ ::
>
> _______________________________________________
> Musicbrainz-style mailing list
> Musicbrainz-style@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

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

[Rod Begbie]

On 11/5/05, Cristov Russell <wolfsong@...> wrote:
> Rod I don't think this voting system will work. Mainly because there are
> multiple solutions proposed and your system seems to be predicated on a
> single change. I do think it's an interesting idea to allow for "levels" of
> feeling but it doesn't seem applicable.

I'm only putting one single proposal to the vote.  Changing the style
guide entry from what it is currently, to the one I proposed.

There was a lot of discussion, on the list and on the wiki, covering a
huge number of different options and issues of varying complexity.

I think my proposed style change mitigates a large number of the
current issues which are hurting the data, and leaves the door open to
improvements in the longer term.  There may be room for wordsmithing,
but I think it's fairly solid.

That's why I put this to a vote -- So i know whether to continue
barking up this particular tree.

> Also, if a consensus can be reached with the Style Ministers involved a vote
> shouldn't be necessary. There still needs to be a process and control to the
> implementation of changes as well which I will include in my proposal.

My vote isn't intended to be binding.  Just a way of personally
testing the waters of public opinion and seeing if there *is*
concensus.  Because despite all the talk, I can't tell who is for,
against, or completely indifferent to such a change.

Rod.

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

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

[g0llum]

> There was a lot of discussion, on the list and on the wiki, covering a
> huge number of different options and issues of varying complexity.

* As an editor, and a member of the StyleCouncil i can't emphasize enough
that i agree with you... but it's not unexpected that this is a stony road
you've taken on. since the tagger support for AR, and other database changes
won't happen in the next few months, and people take the SG5 _too_
literally, i'm voting +1 to adapt it to the collaboration thingies.

regards, g0llum

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

[Cristov Russell]

> On 11/5/05, Cristov Russell <wolfsong@...> wrote:
> > Rod I don't think this voting system will work. Mainly
> because there
> > are multiple solutions proposed and your system seems to be
> predicated
> > on a single change. I do think it's an interesting idea to
> allow for
> > "levels" of feeling but it doesn't seem applicable.
>
> I'm only putting one single proposal to the vote.  Changing
> the style guide entry from what it is currently, to the one I
> proposed.

However that is not what the structure of the page implies. The page states
"Proposed Solutions" with 3 sub headings. Your intent here is to vote on
your proposition and not all the options.

> > Also, if a consensus can be reached with the Style
> Ministers involved
> > a vote shouldn't be necessary. There still needs to be a
> process and
> > control to the implementation of changes as well which I
> will include in my proposal.
>
> My vote isn't intended to be binding.  Just a way of
> personally testing the waters of public opinion and seeing if
> there *is* concensus.  Because despite all the talk, I can't
> tell who is for, against, or completely indifferent to such a change.
>
> Rod.
>
> --
> :: Rod Begbie :: http://groovymother.com/ ::

Probably all voting should be done by the SC which again is why there needs
to be a process on how to determine consensus or lack thereof, the voting
process and the implementation process.

________________________________
Cristov (wolfsong)

A man of learning is never bored. - jean paul richter


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

[Michelle .]

Can't we have both feat. and AR on the same track? Then we can have both
searchable infomation and relationship levels for now until the new tagger's
done.

Also, relationship levels are sometimes difficult to figure out, so this
lets you stick a "feat." in for now and wait for someone else with more
expertise to add in supplementary information. Then there's no information
loss, and we can modify SG5 in the meantime to stop the "compounding
problems".

-0.75, SC member. (for now, until someone explains to me why we can't have
both.)

> >     * +0: 'I don't feel strongly about it, but I'm okey with this.'
> >     * -0: 'I won't get in the way, but I'd rather we didn't do this.'
> >     * -0.5: 'I don't like this idea, but I can't find any
> > rational justification for my feelings.'
> >     * ++1: 'Wow! I like this! Let's do it!'
> >     * -0.9: 'I really don't like this, but I'm not going to
> > stand in the way if everyone else wants to go ahead with it.'
> >     * +0.9: 'This is a cool idea and i like it, but I don't
> > have time/the skills necessary to help out.'
> >
> >                        -- http://www.apache.org/foundation/voting.html
> > --
> > :: Rod Begbie :: http://groovymother.com/ ::
>
>Sorry I haven't gotten back to everyone on a process yet; I've been taking
>care of my mom post surgery. I have a few things from work to catch up on
>but hopefully will have something soon.
>
>Rod I don't think this voting system will work. Mainly because there are
>multiple solutions proposed and your system seems to be predicated on a
>single change. I do think it's an interesting idea to allow for "levels" of
>feeling but it doesn't seem applicable.
>
>Also, if a consensus can be reached with the Style Ministers involved a
>vote
>shouldn't be necessary. There still needs to be a process and control to
>the
>implementation of changes as well which I will include in my proposal.
>________________________________
>Cristov (wolfsong)
>
>Stay close young hobbits! They say there's a great sorceress lives in these
>woods. An elf-witch of terrible power. All who look upon her fall
>
>
>_______________________________________________
>Musicbrainz-style mailing list
>Musicbrainz-style@...
>http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

_________________________________________________________________
MyCareer.com.au: Visit the NEW Salary Survey
http://www.mycareer.com.au/salary-survey/?s_cid=203697

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

[Matthew Exon]

Michelle . wrote:

> Can't we have both feat. and AR on the same track? Then we can have both
> searchable infomation and relationship levels for now until the new
> tagger's done.
>
> Also, relationship levels are sometimes difficult to figure out, so this
> lets you stick a "feat." in for now and wait for someone else with more
> expertise to add in supplementary information. Then there's no
> information loss, and we can modify SG5 in the meantime to stop the
> "compounding problems".
>
> -0.75, SC member. (for now, until someone explains to me why we can't
> have both.)

Another possibility that isn't in the wiki is to abandon the idea of an
official style guideline on this issue altogether.  This is the "even
more pragmatic" option, where FeaturingArtistStyle would give several
possible ways to represent that information ("use 'feat.'", "use AR",
"use both"), and leaves it up to users to guess which they'd rather use.
 The only thing the guideline would officially discourage is changing
existing information to a different style, since that just leads to
pointless edit wars and inflammatory subject lines.

Yes, this makes the database inconsistent and confusing, and yes this
would make it impossible to automatically recover this information when
we finally get a "good" solution.  But the former point is true now, and
will always be true in the future, due to users not reading the
guidelines.  I also think the latter project is doomed anyway: programs
that attempt to parse freetext records into structured databases just
never scale to hundreds of thousands of records (believe me; I've tried).

By letting go of the leash we encourage people to contribute new
information, rather than waste time on editing existing entries.  This
new information will just have to be manually converted over, one record
at a time, to a better representation when the time comes.  At least we
can comfort ourselves in the knowledge that the one resource MusicBrainz
does have in abundance is users.

-0.9, no official status whatsoever.  I'm sympathetic to Rod's cause,
but I think replacing one dubious rule with another dubious rule is just
going to make things worse.

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

[Cristov Russell]

> Can't we have both feat. and AR on the same track? Then we
> can have both searchable infomation and relationship levels
> for now until the new tagger's done.
>
> Also, relationship levels are sometimes difficult to figure
> out, so this lets you stick a "feat." in for now and wait for
> someone else with more expertise to add in supplementary
> information. Then there's no information loss, and we can
> modify SG5 in the meantime to stop the "compounding problems".
>
> -0.75, SC member. (for now, until someone explains to me why
> we can't have
> both.)

Yes we already have both. There are some who for whatever reason feel that
(feat. X) is no longer needed since AR is in place. However, there are
several issues mentioned in the wiki doc that others (myself included) feel
warrant the use (feat. X). An recent example I came across can not be
accurately expressed with AR at all
(http://musicbrainz.org/showmod.html?modid=3622985). Since AR is at the
track level, I had  to associate both performers to the track but each
performer only performs one of the two songs on the track. There's no way in
AR to make that distinction.

________________________________
Cristov (wolfsong)

No folly is more costly than the folly of intolerant idealism. - Sir Winston
Leonard Spencer Churchill


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

[DonRedman]

On Sun, 06 Nov 2005 00:01:27 +0100, Rod Begbie wrote:

> OK folks, it's been a couple of weeks since anyone has added anything
> to http://wiki.musicbrainz.org/GettingRidOfFeaturingArtistStyle
>
> Because I'm fed up with 'mo' dicking around with my moderations, I'd
> like to try putting this to a (completely non-binding) vote, using the
> Apache Lazy Concensus rules.
>
> Reply to this thread, and simply say +1 if you agree, -1 if you
> disagree, or a number in between if you're opinion is in between (see
> bottom of this mail for examples).  Also say if you're a member of the
> Style Council, or just a mailinglist participant.  Next Saturday
> (12th), I'll tot-up the votes.
>
> PROPOSAL: We change FeaturingArtistStyle to read: "When two or more
> artists collaborate on a track or release, file the track/release
> under the primary artist, and then add "performed on" relationships to
> the secondary artists. If no artist can be considered secondary,
> create a new artist in the form 'Artist 1 & Artist 2' and add
> "collaborated on" relationships to the artists."

As I said before I do not think this is a matter of _storing_ data only.  
Since there is no system in place to _use_ the data, should it only be  
stored in ARs (i.e. the website doe not display it on the album view, the  
tagger cannot use it) I am strongly opposed to change the stuile  
guidelines in a way that they render data unusable.

Furthermore I do not think that _any_ proposal is mature enough for  
voting, yet. This inclues yours since it does not adress the issues I  
mention above. Therefore I think voting on anyting is premature.

So, that's a --1.

   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

[g0llum]

> Can't we have both feat. and AR on the same track? Then we can have both
> searchable infomation and relationship levels for now until the new
> tagger's done.

that's the point, to have both. but if it's a collaboration, with 2 artists
providing a similar amount of input, there's the SG5 currently which says to
split the artist anyhow, and attach the track to _1_ artist, and put the 2nd
artist into (feat. ) brackets on the track. therefore, if you search (in the
search box) for tracks with this artist you don't find it unless you search
for the track titles, or try browsing around the AR links.

i don't see why we have to discuss over and over again about non-trivial
solutions to this problem, if we just made the "Artist A & Artist B" artists
(with "collaborated on" AR's) as the intermediate/official solution to the
problem until we're ready to support multiple artists credited directly on
the track/album level like it's done here:
http://www.discogs.com/release/357412

i also have to say i'm a bit frustrated that everytime someone brings up an
issue, it is discussed to kingdom come and is not resolved in a pragmatic
manner.



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

[Marco Sola]

On Sunday, November 06, 2005 12:01 AM,
Rod Begbie <rodbegbie@...> wrote:

> PROPOSAL: We change FeaturingArtistStyle to read: "When two or more
> artists collaborate on a track or release, file the track/release
> under the primary artist, and then add "performed on" relationships to
> the secondary artists. If no artist can be considered secondary,
> create a new artist in the form 'Artist 1 & Artist 2' and add
> "collaborated on" relationships to the artists."

-1, SC memeber

Ciao

MArco / ClutchEr2

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

[orion-6]

>> There was a lot of discussion, on the list and on the wiki, covering a
>> huge number of different options and issues of varying complexity.
>
>
> * As an editor, and a member of the StyleCouncil i can't emphasize
> enough that i agree with you... but it's not unexpected that this is a
> stony road you've taken on. since the tagger support for AR, and other
> database changes won't happen in the next few months, and people take
> the SG5 _too_ literally, i'm voting +1 to adapt it to the collaboration
> thingies.

It was probably pretty clear due to my contributions to the discussion
at the time but I'm also highly in favor of adapting that part.  There's
too much information lost otherwise for my comfort.  Count me as a ++1

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

[Cristov Russell]

> > Can't we have both feat. and AR on the same track? Then we can have
> > both searchable infomation and relationship levels for now
> until the
> > new tagger's done.
>
> that's the point, to have both. but if it's a collaboration,
> with 2 artists providing a similar amount of input, there's
> the SG5 currently which says to split the artist anyhow, and
> attach the track to _1_ artist, and put the 2nd artist into
> (feat. ) brackets on the track. therefore, if you search (in
> the search box) for tracks with this artist you don't find it
> unless you search for the track titles, or try browsing
> around the AR links.

Let's be clear here. Are you talking about tracks with a guest artist or
long term collaborations like Brooks & Dunn? The later should be handled the
same as any group, a single entity where SG5 does not apply. I know we
discussed this at some point when Tarragon was Style Dude and as I recall
that was his feeling as well. It didn't however become official. I would say
that a lot of the problem stems from the use of the word collaboration which
by definition is accurate but SG5 provides no guidance to the intent of the
word's usage.

> i don't see why we have to discuss over and over again about
> non-trivial solutions to this problem, if we just made the
> "Artist A & Artist B" artists (with "collaborated on" AR's)
> as the intermediate/official solution to the problem until
> we're ready to support multiple artists credited directly on
> the track/album level like it's done here:
> http://www.discogs.com/release/357412
>
> i also have to say i'm a bit frustrated that everytime
> someone brings up an issue, it is discussed to kingdom come
> and is not resolved in a pragmatic manner.

All the more reason to formalize the SC a bit more and devise a process to
resolve these issues more clearly.

________________________________
Cristov (wolfsong)

Of course, we are all worms--but I like to think, at least, that I am a
glowworm. - Sir Winston Leonard Spencer Churchill


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

[orion-6]

from wolfsong:
> Let's be clear here. Are you talking about tracks with a guest artist or
> long term collaborations like Brooks & Dunn? The later should be handled the
> same as any group, a single entity where SG5 does not apply. I know we
> discussed this at some point when Tarragon was Style Dude and as I recall
> that was his feeling as well. It didn't however become official. I would say
> that a lot of the problem stems from the use of the word collaboration which
> by definition is accurate but SG5 provides no guidance to the intent of the
> word's usage.

One time (or a just few times, anyway) equal collaborations was what I
thought was being talked about.  What sparked his first email was a
soundtrack album where each song paired a rock/metal artist with a rap
artist and had them make a new song.  It's not a long term collaboration
artist like Brooks & Dunn but neither artist is a guest.  The problem is
the that the style guide doesn't really admit that concept.  It says to
put it under the more primary one or to pick one to assign as primary
even if neither is.  What myself, and I believe Rod and Stefan are
wanting is the changing of that notion that something can't be equal -
as it stands either one is inherently primary or has to be assigned as
primary.

from DonRedman:
 > As I said before I do not think this is a matter of _storing_ data
 > only.  Since there is no system in place to _use_ the data, should it
 > only be  stored in ARs (i.e. the website doe not display it on the album
 > view, the  tagger cannot use it) I am strongly opposed to change the
 > stuile  guidelines in a way that they render data unusable.

I'm still not clear on how the data isn't usable.  What makes the data
unusable if it's stored under Slayer & Ice-T - song instead of Slayer -
song (feat. Ice-T)?  It no longer shows under Slayer's page but it does
now show on artist searches on Slayer or Ice-T, whereas previously it
didn't show on Ice-T's page and didn't show up on an artist search on
Ice-T either.  The data is still completely accesible under Slayer &
Ice-T and can be used in the tagger just fine...

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

[Cristov Russell]

> from wolfsong:
> > Let's be clear here. Are you talking about tracks with a
> guest artist
> > or long term collaborations like Brooks & Dunn? The later should be
> > handled the same as any group, a single entity where SG5 does not
> > apply. I know we discussed this at some point when Tarragon
> was Style
> > Dude and as I recall that was his feeling as well. It
> didn't however
> > become official. I would say that a lot of the problem
> stems from the
> > use of the word collaboration which by definition is
> accurate but SG5
> > provides no guidance to the intent of the word's usage.
>
> One time (or a just few times, anyway) equal collaborations
> was what I thought was being talked about.  What sparked his
> first email was a soundtrack album where each song paired a
> rock/metal artist with a rap artist and had them make a new
> song.  It's not a long term collaboration artist like Brooks
> & Dunn but neither artist is a guest.  The problem is the
> that the style guide doesn't really admit that concept.  It
> says to put it under the more primary one or to pick one to
> assign as primary even if neither is.  What myself, and I
> believe Rod and Stefan are wanting is the changing of that
> notion that something can't be equal - as it stands either
> one is inherently primary or has to be assigned as primary.

I agree that scenario does not have a single "guest artist". It can probably
be argued however that both artists are guests but that doesn't work in our
schema either.

> from DonRedman:
>  > As I said before I do not think this is a matter of
> _storing_ data  > only.  Since there is no system in place to
> _use_ the data, should it  > only be  stored in ARs (i.e. the
> website doe not display it on the album  > view, the  tagger
> cannot use it) I am strongly opposed to change the  > stuile  
> guidelines in a way that they render data unusable.
>
> I'm still not clear on how the data isn't usable.  What makes
> the data unusable if it's stored under Slayer & Ice-T - song
> instead of Slayer - song (feat. Ice-T)?  It no longer shows
> under Slayer's page but it does now show on artist searches
> on Slayer or Ice-T, whereas previously it didn't show on
> Ice-T's page and didn't show up on an artist search on Ice-T
> either.  The data is still completely accesible under Slayer
> & Ice-T and can be used in the tagger just fine...

It's bad data architecture especially since AR can express the same thing.
The problem with AR is it's not mature enough to fully express these
relationships.

________________________________
Cristov (wolfsong)

If guns cause crime, then pencils cause misspelled words.


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

[Cristov Russell]

> Michelle . wrote:
> > Can't we have both feat. and AR on the same track? Then we can have
> > both searchable infomation and relationship levels for now
> until the
> > new tagger's done.
> >
> > Also, relationship levels are sometimes difficult to figure out, so
> > this lets you stick a "feat." in for now and wait for someone else
> > with more expertise to add in supplementary information.
> Then there's
> > no information loss, and we can modify SG5 in the meantime
> to stop the
> > "compounding problems".
> >
> > -0.75, SC member. (for now, until someone explains to me
> why we can't
> > have both.)
>
> Another possibility that isn't in the wiki is to abandon the
> idea of an official style guideline on this issue altogether.
>  This is the "even more pragmatic" option, where
> FeaturingArtistStyle would give several possible ways to
> represent that information ("use 'feat.'", "use AR", "use
> both"), and leaves it up to users to guess which they'd rather use.
>  The only thing the guideline would officially discourage is
> changing existing information to a different style, since
> that just leads to pointless edit wars and inflammatory subject lines.
>
> Yes, this makes the database inconsistent and confusing, and
> yes this would make it impossible to automatically recover
> this information when we finally get a "good" solution.  But
> the former point is true now, and will always be true in the
> future, due to users not reading the guidelines.  I also
> think the latter project is doomed anyway: programs that
> attempt to parse freetext records into structured databases
> just never scale to hundreds of thousands of records (believe
> me; I've tried).
>
> By letting go of the leash we encourage people to contribute
> new information, rather than waste time on editing existing
> entries.  This new information will just have to be manually
> converted over, one record at a time, to a better
> representation when the time comes.  At least we can comfort
> ourselves in the knowledge that the one resource MusicBrainz
> does have in abundance is users.
>
> -0.9, no official status whatsoever.  I'm sympathetic to
> Rod's cause, but I think replacing one dubious rule with
> another dubious rule is just going to make things worse.

Letting the user decide how to apply information is equally dubious and is
one basis in fact for having a style guide, to achieve consistency.

________________________________
Cristov (wolfsong)

If guns cause crime, then pencils cause misspelled words.


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

[g0llum]

> Letting the user decide how to apply information is equally dubious and is
> one basis in fact for having a style guide, to achieve consistency.

exactly... and i've come to think that applying SG5 and breaking up the
collaboration "Slayer & Ice-T" example feels less natural than just storing
this under a new artist called "Slayer & Ice-T", which in turn shows up
under artist searches just fine. If some editor changes tracks on a
compilation album to follow SG5, but doesn't to this consistently to all the
occurences on other releases, it's even worse...


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

[g0llum]

> It's bad data architecture especially since AR can express the same thing.
> The problem with AR is it's not mature enough to fully express these
> relationships.

(...please take no offence, i'm not directing this rant at you personally)

yes, that's what i meant... we can talk about how a future system might
handle the case better, or we can throw away the stupid SG5 part now. Again:
this does not mean we don't store _guest_ artists as (feat. artist x)
anymore! We can even add the AR's to the respective artist entities that
were part of  the collaboration, such that we can write a report to list
such collaborations, or even do some things automatically if/once the system
is ready to store the data in a more sophisticated manner.

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

[Dylan Steinberg]

Orion wrote:

> from DonRedman:
> > As I said before I do not think this is a matter of _storing_ data
> > only.  Since there is no system in place to _use_ the data, should it
> > only be  stored in ARs (i.e. the website doe not display it on the
> album
> > view, the  tagger cannot use it) I am strongly opposed to change the
> > stuile  guidelines in a way that they render data unusable.
>
> I'm still not clear on how the data isn't usable.  What makes the data
> unusable if it's stored under Slayer & Ice-T - song instead of Slayer
> - song (feat. Ice-T)?  It no longer shows under Slayer's page but it
> does now show on artist searches on Slayer or Ice-T, whereas
> previously it didn't show on Ice-T's page and didn't show up on an
> artist search on Ice-T either.  The data is still completely accesible
> under Slayer & Ice-T and can be used in the tagger just fine...

The problem is that the proposal on the table doesn't address your issue
here.  According to Rod's proposal, the track will still be stored under
either Slayer or Ice-T but, instead of (feat. XXX) in the title, we'll
have advanced relationships, which currently aren't searchable at all
(or taggable at all).

Unless I'm misreading the proposal, put me down as -1, Style Council.

--Dylan

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