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

[DonRedman]

On Mon, 07 Nov 2005 01:01:29 +0100, Rod Begbie wrote:

> Thanks for all the comments and patience so far.
>
> As people have rightly pointed out, there are really two issues here,
> munged into one confusing spiralling argument.  It's my fault for not
> trying the separate them more.
>
>
> Firstly, the "Person A & Person B" issue.   (eg.  Ice-T and Slayer).
>
> My suggestion that this be treated as a new artist seems to be getting
> mostly positive feedback (RJMunro being the main dissenter).
>
>
> The second, separate-but-connected issue are cases of "Person A"
> guesting on a track by "Person B"  (eg. Macy Gray doing vocals on a
> Fatboy Slim track).
>
> My original proposal said that the secondary artist should not be
> included in the title field, but as AR only, and this seems to be the
> clause that's generally making people (Michelle and DonRedman in
> particular) unhappy, and I fully understand their reasons.
>
> I'd be more than happy for now to go with the first fix, and leave the
> second until a future time when we can improve the website and tagger.
>
>
> Would anyone's vote change if I suggested changing SG5 to the following:
>
> When two artists collaborate on a track or release, file the
> track/release under the primary artist, and then append the name of
> the secondary artist to the name of the track/release as follows:
>
>     * "Put Your Lights On (feat. Everlast)"
>
> 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.

Funny, that is exactly my Propsal(B). But since I have bees sleeping when  
you were in midst a heated discussion, and heve read this in thread-mode,  
yours is the last post of this thread I read.

To summarize the few mails I scattered all over this thread:

I still do not like this, since it uses a cludge. It uses collaborations  
to display two equally 'primary' artist names as one ArtistName, because  
there is no interface that can display AR-artists.

These collaborations create a pretty sub-optimal data structure. The  
optimal data structure would be to use performing ARs only, except for  
collaborations which use or have become _names_.

But people seem to be so massively frustrated by SG5 that I change my vote  
(from --1, to +1) to -0.1, SG member.

I would be even happier if we could find a way to tag these  
cludge-collarborations, so that a scipt could later differentiate them  
 from real collaborations. This could be solved with a new artist type.  
Another cludge, I admit, but then it shold be possible to walk on two  
cludges (or is it crutches?) :-)

   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

[Jan van Thiel-2]

On 11/7/05, Don Redman <donredman@...> wrote:
> To summarize the few mails I scattered all over this thread:
>
> I still do not like this, since it uses a cludge. It uses collaborations
> to display two equally 'primary' artist names as one ArtistName, because
> there is no interface that can display AR-artists.

Of course there is: on the artist page! (
http://musicbrainz.org/showrel.html?id=212630&type=artist )

> These collaborations create a pretty sub-optimal data structure. The
> optimal data structure would be to use performing ARs only, except for
> collaborations which use or have become _names_.

Please define optimal. We're discussing an option that doesn't put any
more strain on the system than the present SG5 does.

> But people seem to be so massively frustrated by SG5 that I change my vote
> (from --1, to +1) to -0.1, SG member.

BTW, I voted ++1 as SG member.

> I would be even happier if we could find a way to tag these
> cludge-collarborations, so that a scipt could later differentiate them
>  from real collaborations. This could be solved with a new artist type.
> Another cludge, I admit, but then it shold be possible to walk on two
> cludges (or is it crutches?) :-)

This is already proposed (
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-October/000484.html
) and seems like a good companion to the second proposal by Rod Begbie
and fairly easy to implement (easy to say for me, of course ;).

People do *not* want to wait for AR to be fully implemented in a way
everything can be easily entered and displayed; that just takes too
long. This entire discussion again points that out. The annoyance with
the present SG5 is just too big; with a small change, a lot of people
will be very happy (including me). I'll take it for granted that to
find all releases or all tracks by A & B, I have to follow the artist
relations for A or B. Then at least the way to find them is always the
same. Right now I'd have to go through all releases by A and by B to
find them all. Which is more illogical than looking up 1 separate
artist that represents a collaboration between 2 artists.

And almost all new users create these collaboration artists anyway;
leaving them also takes away a lot of necessary editing.

Jan (zout)

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

[Cristov Russell]

> ++1 for the new proposal.
>
> A question for people opposing the new proposal:
>
> What if a group of artists do a one time collaboration under
> a single name that does not include their respective names
> (e.g. Band Aid)? The only reason this isn't listed under
> ArtistA - TrackName (feat.
> ArtistB, ArtistC,...) is because of the new name. But then
> why should a collaboration between ArtistA and ArtistB
> released as e.g. "ArtistA & ArtistB" or "ArtistA and ArtistB"
> be split up? If Joe Cocker and Jennifer Warnes would've
> released Up Where We Belong under the name JJ (as an
> example), this would be a separate entry. (Actually, "Joe
> 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.)
>
> Jan (zout)

Apples and oranges Jan. We're not really talking about the people that make
up a name (it's members) but the name itself. There are no additional
artists in the name Band Aid. The name describes a project just as USA for
Africa was a project. Sonny & Cher, Brooks & Dunn and Simon & Garfunkel are
names that describe duos, they simply used the names of it's members. Some
examples of why were talking about names versus members: Matt Bianco, Danny
Wilson and Aphex Twin. All 3 are simply names. The first two describe groups
and the last describes a single person. There are members in 1 and 2 but
none in 3. When Queen and David Bowie recorded Under Pressure did they
become members of something? Not in my mind. They only worked together. A
temporary relationship.

What is an isn't intuitive is a question of interface design not usage. Take
Discogs interface for example. When entering data, you have the option of
adding other artists and describing their relationship. That isn't proof
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.

________________________________
Cristov (wolfsong)

If someone betrays you once, it's his fault; if he betrays you twice, it's
your fault.


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

[Cristov Russell]

> Yes, very good point. Basically that pushes for what I sad
> before: The MusicBrainz summit is close. SG5 is the top point
> on the agenda (at least that is my impression). The problem
> we have is not a data storage problem but an interface
> problem. Let us fix the interface problem. Then SG5 will just
> _vanish_.
>
> This is the reason why SG5 has not been changed after the
> past discussins, and why I think it should not be changed
> now: It _is_not_ an issue of data storage. It is a symptom af
> a massive lack of interfaces for AR.
>

> > But you see how hard this is to describe.  You're using words like
> > "one-off", "entity" and "name", none of which appear in the current
> > SG5 rule, leaving this all up to individual moderator decisions.
> > Surely better to make this all unambigious and consistent?
>
> The most unambigous method would be: File all as
> AdvancedRelationships and let MusicBrainz do the rest. The
> problem is that MusicBrainz is not able to do the rest, which
> would be: Display the artists, make them searchable etc.
>
>    DonRedman
>
> --
> Words that are written in CamelCase refer to WikiPages:
> Visit http://wiki.musicbrainz.org/ the best MusicBrainz
> documentation around! :-)

Absolutely true. I completely agree here. All the complaints can be resolved
by fixing the UI and the tagger's use of AR. There are just a lot of hurdles
to jump to get everything fixed.

________________________________
Cristov (wolfsong)

The faster you go, the shorter you are. - Albert Einstein


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

[g0llum]

 
> > 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, and if you want to browse for artists, you don't
want to  swing from tree-to-tree (literally) until you've found the artist
linked over god knows how many different performance names/groups/artists
until you found the one you're looking for.

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

[DonRedman]

On Mon, 07 Nov 2005 14:28:35 +0100, Jan van Thiel wrote:

> On 11/7/05, Don Redman <donredman@...> wrote:
>> To summarize the few mails I scattered all over this thread:
>>
>> I still do not like this, since it uses a cludge. It uses collaborations
>> to display two equally 'primary' artist names as one ArtistName, because
>> there is no interface that can display AR-artists.
>
> Of course there is: on the artist page! (
> http://musicbrainz.org/showrel.html?id=212630&type=artist )

You seem to misunderstand me. see below

>> These collaborations create a pretty sub-optimal data structure. The
>> optimal data structure would be to use performing ARs only, except for
>> collaborations which use or have become _names_.
>
> Please define optimal. We're discussing an option that doesn't put any
> more strain on the system than the present SG5 does.

I was refering to Robert Munroe's criticism, which I believe is very valid.

We can _store_ that two equally primary artist performed an album together  
by saying:
   >>"Nashville 1969" was {primarily} performed by "Bob Dylan"<< and
   >>"Nashville 1969" was {primarily} performed by "Johnny Cash"<<.
But we cannot _display_ nor _use_ this information.
Instead of arguing for an adaption of the display and usage mechanism, you  
argue for a change in the way things should be stored. Furthermore your  
argument is not based on thoughts about optimal data storage or optimal  
usage mechanisms, but on thoughts about hwo to use existing features to  
get a result _now_.

We can talk about optimal data strucuteres if you want to. BUT WE HAVE NOT  
DONE THAT, which IMVHO is *the* problem we have with AR: We do not  
understand how to use that feature. Instead we are trying to adapt our  
usage of AR to the exitent features. It should be the other way around,  
IMO.

Here are some aspects about data structure:
  * Why should some informatoin about performance be stored on album/track  
level, why other information about the same type of performance should be  
stored on artist level? E.g. unequal collaborations are stored wiht  
artist-album/track ARs but equal collaborations are stored with a new  
artist entity and artist-artist ARs.
  * Which option is optimal regarding usage, i.e. queries, display scripts  
etc: Storing information on the album/track level or on the artist level?  
I believe the former, since it spares you one depth in crawling the data.

Or some aspect about UI, you pointed at:
> And almost all new users create these collaboration artists anyway;
> leaving them also takes away a lot of necessary editing.
Which is an argument to change the UI and not to change the guidelines IMO.


Even the revised Proposal(B) is a kludge. People are asking for a short  
term solution. That's one. If it makes use of a new artist type, it can be  
reversed when the rest of AR will have been implemented. OK, but please do  
not claim that it is a good way of using AR.

The sad fact is that we do not know how to use AR well. I have written  
this post on lateral thought on feat  
( http://www.nabble.com/-mb-experts-Some-lateral-thoughts-on-feat-t440333c2885.html#a1203914 
) but have gotten no response. I do not know if I am the only person to  
feel that the way we are dealing with AR is pretty pathetic.

Yes, intertwingling is the way to go. I am happy that I had to admit that.  
But thinking in trees, and queries and tables is in no way adapted to an  
intertwingled body of data. I believe that SQL is a bad metaphor for  
AdvancedRelationships, A much better metophor would be the web and Google.  
Let AR be the web and MusicBrainz be Google.

But, yes for a short term solution the revised proposal is acceptable even  
to me, that's what -0.1 means, does'n it?

> This is already proposed (
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-October/000484.html
> ) and seems like a good companion to the second proposal by Rod Begbie
> and fairly easy to implement (easy to say for me, of course ;).

Cool, I was not aware of that.

   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

[Fuchs]

On 11/7/05, Stefan Kestenholz <g0llum@...> wrote:
> 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.

Full ACK.

> 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, and if you want to browse for artists, you don't
> want to  swing from tree-to-tree (literally) until you've found the artist
> linked over god knows how many different performance names/groups/artists
> until you found the one you're looking for.

I aggree 100%. I'd never suggest handling some AR data as special
cases. The reason for AR was, that it is a nice idea that allows
adding non-core data without the need of DB and UI changes for any
addition/deletion of a new relationship types.

If we changed the interface to handle the performs/collaborated AR in
such a special way that it integrates linked entities into the album
list etc. then we would break the whole concept of AR. Special
handling of AR data is not only harder to implement, but the worse
performing and uglier (from a perspective of implementation design)
solution as well.


#Fuchs


PS: On the matter of voting for the proposal, I don't know. For A & B
I decide for each case wether it is a real group or just an "A feat.
B" already. The same for similar constructs. I even remember adding "A
feat. B" as an artist, because the group had this name with A and B
never performing alone. So my vote is -.5 for changing the guideline
and ++1 for explaining the correct interpretation of the current
guideline.

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

[Jan van Thiel-2]

On 11/7/05, Don Redman <donredman@...> wrote:
> Or some aspect about UI, you pointed at:
> > And almost all new users create these collaboration artists anyway;
> > leaving them also takes away a lot of necessary editing.
> Which is an argument to change the UI and not to change the guidelines IMO.

True. A way to indicate all artists that perform on a track, including
their role, would be best. But that's a lot of work.

> But, yes for a short term solution the revised proposal is acceptable even
> to me, that's what -0.1 means, does'n it?

A negative number to me implies you're somewhat against.

But again: I know we're not using AR the best way, and the
intermediate solution does not work towards good use of AR. But it
doesn't work in the other direction either.

Jan

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

[RUDOY CALLEJAS MICHEL DAVID]

Count a +1 from me.

Cheers!

Michel Rudoy aka mcymd

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

[g0llum]

> True. A way to indicate all artists that perform on a track, including
> their role, would be best. But that's a lot of work.

Not really, if I understand you correctly that's already running on my dev
box:
http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2005-November/00148
7.html

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

[DonRedman]

On Mon, 07 Nov 2005 17:54:44 +0100, Stefan Kestenholz wrote:

>> True. A way to indicate all artists that perform on a track, including
>> their role, would be best. But that's a lot of work.
>
> Not really, if I understand you correctly that's already running on my  
> dev
> box:
> http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2005-November/001487.html

Another reason not to change SG5 now. The proposed change would move  
artist away from where the code can grab them.

   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]

> Another reason not to change SG5 now. The proposed change would move
> artist away from where the code can grab them.

i disagree. this page is about showing the tracklevel AR's on the albumpage,
nothing else. tracks which were released in collaboration with another
artist don't _necessarily_ have to be displayed on the same artist page, but
on the artist page of the collaboration, if we adapt the SG5. (= if a person
was part of many groups during his career, you would not want the tracks of
all this groups listed under the artist, but under the groups they were
released)


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

Rod Begbie wrote:

> Would anyone's vote change if I suggested changing SG5 to the following:
>
> When two artists collaborate on a track or release, file the
> track/release under the primary artist, and then append the name of
> the secondary artist to the name of the track/release as follows:
>
>     * "Put Your Lights On (feat. Everlast)"
>
> 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.

My vote for this is ++1 (I'm not a SC member). I'd still prefer M:N artist-track
relationships, but this compromise is, in my opinion, the best what we can do
without any code changes.

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

[DonRedman]

On Mon, 07 Nov 2005 19:12:55 +0100, Stefan Kestenholz wrote:

>
>> Another reason not to change SG5 now. The proposed change would move
>> artist away from where the code can grab them.
>
> i disagree. this page is about showing the tracklevel AR's on the  
> albumpage, nothing else. tracks which were released in collaboration  
> with another artist don't _necessarily_ have to be displayed on the same  
> artist page,

Well IMO that is exactly the purpose of such a listing. But then neither  
me nor you has written the code. And we simply disagree.

   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

[Gecks]

mailinglists are useless, period :) they are the domain of linux kiddies and
this place needs a web forum, if only for the user chat, else it's always
going to have that bedroom project feel for me :/ mind you last time i
talked of such a thing i think the end solution was to create *more*
mailinglists :P anyway, not the time or the place i guess...

and i will of course review my vote, however the non-realtime nature of
mailinglists means i didn't get that till after i posted that response :/
but i read every message here so yeah...

Cheers,
Chris B
----- Original Message -----
From: "Stefan Kestenholz" <g0llum@...>
To: "MusicBrainz style discussion" <musicbrainz-style@...>
Sent: Monday, November 07, 2005 12:34 AM
Subject: Re: [mb-style] Lets put GettingRidOfFeaturingArtistStyle to the
vote.

> please review your vote, once you've read the updated proposal, and gosh!
> the mailing list archive is rather useless, if people do not answer to
> mails at the end of the thread or if their mail client does not support
> the in-reply-to headers.
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-November/000542.html
>
>> i think this blanket removal of (feat. x) is not useful. SG5 shouldn't be
>> removed, it should be adapted. we do need a rule to cover the
>> presentation
>
> that's how i understand the proposal now.
>
> _______________________________________________
> 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

[Gecks]

----- Original Message -----
From: "Don Redman" <donredman@...>
To: "MusicBrainz style discussion" <musicbrainz-style@...>
Sent: Monday, November 07, 2005 11:04 AM
Subject: Re: [mb-style] Lets put GettingRidOfFeaturingArtistStyle to the
vote.

> The proposal changes SG5 only for cases in which there is no primary
> artist. and requires ARs to be added in all cases. That means that once AR
> is more mature, the "feat." parts can just be scrapped. Since there is
> already a script that generates ARs from these entries, it should be easy
> to write one that just deletes them.


I realise it's not being under discussion now, but i dont' see why we should
ever get rid of (feat. x) parts, even when the tagger can 'create' that from
the relevant ARs. if an artist deems it neccesary to include (feat. x) in
the tracklisting, I consider that part of the track name, and would expect
to see that written as such, not hidden amongst all our ARs (on the website
level, nevermind what goes on with the tagger). it should be an AR as well,
but not instead of, I feel.

Cheers,
Chris B

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

[Gecks]

----- Original Message -----
From: "Don Redman" <donredman@...>
To: "MusicBrainz style discussion" <musicbrainz-style@...>
Sent: Monday, November 07, 2005 11:23 AM
Subject: Re: [mb-style] Lets put GettingRidOfFeaturingArtistStyle to the
vote.

> On Mon, 07 Nov 2005 00:08:53 +0100, Robert (Jamie) Munro wrote:
>
>> If you really don't like to make one primary, file the track under the
>> "Various Artists" artist, and add "performed on" relationships" to all
>> artitsts.
>>
>> On database modifications, we don't need to allow multiple artists per
>> track as they are ALREADY ALLOWED! That's what AR is. If anything we
>> should abolish the legacy track - single artist links. We do need
>> improvements to the interfaces, but not to the database.
>
> Yes, very good point. Basically that pushes for what I sad before: The
> MusicBrainz summit is close. SG5 is the top point on the agenda (at least
> that is my impression). The problem we have is not a data storage problem
> but an interface problem. Let us fix the interface problem. Then SG5 will
> just _vanish_.
>
> This is the reason why SG5 has not been changed after the past discussins,
> and why I think it should not be changed now: It _is_not_ an issue of data
> storage. It is a symptom af a massive lack of interfaces for AR.
>
> My counter-Proposal(B) Is as bad as Rod's regarding Robert's criticism: It
> creates new redundant artists, just because there is no interface that
> displays the artists which are attached to tracks by AR.
> Do you realize that if we had that feature, your proposal (and mine too)
> would be stupid? And I believe we _will_ have this feature. And I hope
> this will not take too long, and when we have it, all these collaborations
> will have to be removed from the database again, and be replaced by
> performance ARs.
>
> Do you realize that _this_ is the problem, _this_ is what we should
> discuss, not SG5?
>
> The question is: How can we, and should we _use_ AR? What interfaces to AR
> do we need (what searces, queries, displays, tagging scripts, etc)?
> Of course, this question is so huge, that it will take about a year to
> find and implement the solutions. But in this process SG5 will be removed,
> and removed for good.
>
> I think it is stupid to make a small patchy change to SG5 now that we will
> regret later. Although I proposed one myself, just out of frustration.

I agree, though to be honest i think the need for AR data access has been
there the second AR came into being. it was like "great, AR! except...no
point using it cos i can't see it". i don't see this issue highlighting
anything we didn't already know, really.

i doubt such a solution will appear anytime soon, as is the work load of the
People Who Can, so i vote +0.5 for the (revised) proposal, if it keeps
people happy :)


Cheers,
Chris B

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

[Cristov Russell]

> > 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.

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
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.

> > 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, and if you
> want to browse for artists, you don't want to  swing from
> tree-to-tree (literally) until you've found the artist linked
> over god knows how many different performance
> names/groups/artists until you found the one you're looking for.

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.
________________________________
Cristov (wolfsong)

George Banks:  And don't forget to fasten your condoms!  ...Seatbelts, I
mean seatbelts.


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

[Rod Begbie]

<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, where we have some users enter "Artist 1  (feat. Artist
2)", some enter "Artist 2 (feat. Artist 1)", and yet users (new and
old) *still* add a new artist called "Artist 1 & Artist 2" because
that's what the CD listing says, and the current styleguide rule is
colossaly counterintuitive and incredibly fucking dumb.

> 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".

Hell, once we're done wasting time arguing about "the process", I'll
make the change myself, and save the StyleCouncil the bother.

You can then invest all the "resources" you want in coming up with a
"better" solution.  And in the six/twelve/twentyfour months that it
takes for that solution to appear, I'll not want to punch mo for
dicking around with my mods.

Rod.

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

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

[Cristov Russell]

> <warning -- grumpy sweary scotsman ahead>

I love you Scots. You make-a-me laugh. ;-)

> 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, where we have some users enter
> "Artist 1  (feat. Artist 2)", some enter "Artist 2 (feat.
> Artist 1)", and yet users (new and
> old) *still* add a new artist called "Artist 1 & Artist 2"
> because that's what the CD listing says, and the current
> styleguide rule is colossaly counterintuitive and incredibly
> fucking dumb.

If I knew how to write ASCII models I would but I don't. One of the things
relational database models resolve is duplication of data which leads to
inaccuracies. By adding a rule like "create a new artist called 'Artist A &
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

And so on.
That doesn't resolve the problem. The problem we have is that

SG5 is confusing
SG5 conflicts with what most people would want their tags to look like
SG5 exists because the current schema and interface can not handle multiple
artists
Users still want data to "appear" in a specific but customizable format.

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 and the only
way to have entity appear on a single track is to convert to VA. That is a
nightmare!

> > 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".
>
> Hell, once we're done wasting time arguing about "the
> process", I'll make the change myself, and save the
> StyleCouncil the bother.
>
> You can then invest all the "resources" you want in coming up
> with a "better" solution.  And in the six/twelve/twentyfour
> months that it takes for that solution to appear, I'll not
> want to punch mo for dicking around with my mods.
>
> Rod.
>
> --
> :: Rod Begbie :: http://groovymother.com/ ::

Again, I'm saying lets tackle root causes and not SYMPTOMS. SG5 is only the
symptom of another issue. I am in no way against rewriting to clarify what
it should really mean to reduce confusion but I have yet to see a proposal
that:

1. addresses the root cause
2. does not create more work long term

________________________________
Cristov (wolfsong)

I have nothing to offer but blood, toil, tears and sweat. - Sir Winston
Leonard Spencer Churchill


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