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

View: New views
15 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 - 4 - 5 | Next >

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

by g0llum :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> But database neatness is what is important in the long term. The user
> interface can (and will) be fixed.
no, database neatness is not a goal by itself, but a state that is more
easily achieved (read: less edits, less wrong add moderations) if we have
reasonable styleguidelines.

> It's not at the expense of the other artist - it shows up in their VA.

no it does not, it's only in the relationships listing if the user bothers
to add the feat. AR.

sorry to be that blunt, but you have lost the bearing on the reality of
MusicBrainz a bit (Have you been doing editing/voting lately?) relationships
are nice, and relationships are used by people who care alot about metadata
of certain artists/albums. but most people don't add them, one of the
reasons is the clunky relationships interface, which prevents a widespread
use IMO. we'll have to solve relationships inheritance and track merging
until they really will be useful. before that, we'll have the SG5 changed,
because it is messy, and wrong (append all the other reasons people came up
with during this discussion) The goal we have is not about a perfectly
normalized database with no redundancy whatsoever, it's about storing data,
and making it accessible to the taggers and users browsing the data. (and
there are lot's of website which provide more information, if one only wants
to browse discographies -- but that's offtopic now) ... we're currently
about to implement MB V2.0 (if you want to nickname it like that), where
we'll be able to specify much more information, make the add/edit
relationships interface more accessible (read: less clicks) and have n:m
core-data. once everything is in place, this will be very nice - but it just
takes to long to let the SG5 live on in the state it's currently in.


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

Re: [mb-style] Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!

by orion-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Don Redman wrote:
> 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.

I hadn't really thought of it in those terms, but you are correct.  I've
never been as interested or enthusiastic about AR as most people in the
community since there still is a fair amount of information important to
me that if stored by MB should probably be in AR but can't be stored via
it as yet.  I've also always been more interested in the i18n and l10n
efforts, where AR seems to have some design issues that are likely to
present road blocks due to the assumption of English gramar that seems
to underly the way most of the links are constructed.  It should be
interesting to see what happens when we hit the point of doing site
interfaces in multiple languages and the link a -> b as "a did b" needs
to be a -> b as "b a did" or similar.  That implicit order of
directionality in most AR links was oddly a turn off to me.

Not sure how much specific music cultures had to do with that - with
myself it's more simply the number of them that I've gone through.  I've
been listening to and collecting music for about 10 years now, and have
gone through phases of alt rock, punk and indie rock, all sorts of
electronic music, big band/bossa nova/swing, and for the last 5 years
have concentrated on pretty much the entire output of Japan (with the
exceptions of instrumental soundtracks, male vocal R&B, boypop bands,
and visual rock since everyone has their personal dislikes) and large
parts of the rest of East/South East Asia.  When you're holding
information on 25-30k songs from dozens of genres in your active memory
it's probably easier to notice the number of cases that rub raw against
the database's ability to store them than if you concentrate on a couple
genres or a smaller amount of songs...

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

Thank you for that extended metaphor, that puts it quite well.  A fair
number of my favorite artists are quite frankly collaboration-whores
that makes tracing out all their connections look more complicated than
the interlinking done by scientology sites...  It's easy to forget that
others might never have to deal with seeing collaborations other than
the occasional "David Bowie and Queen" and therefore find it silly or
undesirable to allow that as an entry.

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

Thank you.  I also like that a fair amount of it could be populated as
Rod said by a script if the collaboration aritst is there with the ARs
added.  If you have m-flo loves melody.&山本領平 as an artist with the
collaboration ARs to m-flo, melody., and 山本領平 added then it should
be able to populate the freetext blocks with the "loves" and "&" parts
automagically while putting the three artists in the proper order around
them.  Doing the same correctly from m-flo - Miss You (feat. melody. and
山本領平) would be impossible.  Obviously not every artist would be
doable automatically like that, but a fair portion of them should be if
they have the "collaborated on" ARs added.

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

You lost me with the "rhizomes and not for trees" part.  To me this is a
step towards that - a fix for now that also smooths the transition
towards then by making it easier to automate the process of changing
them over.  Of course, that's predicated on the assumption that a system
like what I outlined will eventually be implemented, but one can always
hope...

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

RE: [mb-style] Let's get rid of theGettingRidOfFeaturingArtistStylediscussion NOW!!

by Cristov Russell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> 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&s
> earch=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/ ::

So to offer my own metaphor, you feel that because there are some people who
ignore the posted speed limit it should be raised to accommodate them
because they haven't yet caused an accident even though there are still
safety issues.

________________________________
Cristov (wolfsong)

A fanatic is one who can't change his mind and won't change the subject. -
Sir Winston Leonard Spencer Churchill


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

Re: [mb-style] Let's get rid of theGettingRidOfFeaturingArtistStylediscussion NOW!!

by Rod Begbie :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/9/05, Cristov Russell <wolfsong@...> wrote:
> So to offer my own metaphor, you feel that because there are some people who
> ignore the posted speed limit it should be raised to accommodate them
> because they haven't yet caused an accident even though there are still
> safety issues.

Yes, but only if the roadsigns are printed in Belgian, all drivers are
talking on cellphones, the roads are paved with broken glass and
twigs, and don't go anywhere near the city you're trying to get to,
but there are plans to vulcanise tyres in the next year or so, and
everyone will drive hybrid cars.

Where the twigs represent SG5.

"People who talk in metaphors outta shampoo my crotch." -- Jack
Nicholson, As Good As It Gets

Rod.

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

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

Re: [mb-style] Let's get rid of theGettingRidOfFeaturingArtistStylediscussion NOW!!

by Jan van Thiel-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/9/05, Rod Begbie <rodbegbie@...> wrote:
> Yes, but only if the roadsigns are printed in Belgian

OT: There is no such thing as Belgian ;) Dutch or French are your
options in Belgium.

Jan

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

RE: [mb-style] Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!

by Beth-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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.

[Beth]
This would be great, if indeed it was the same song. (same time, no rips
from copied discs to change it off by a few seconds. No added musical notes
and added choruses from the artist.)  However, where do you find the actual
time of a song, the first release, how the song evolved? Some artists are
simple, all of their songs obviously are the same song exactly, by second
mark and everything, easily seen with the time remaining the same for each
VA work that is listed as well. Other artists however are much more
difficult, they have released many promo tracks via the web, or a prerelease
album. The name may appear the same, but when it's remastered the track
sounds different, and when they have actually changed the structure of the
song, then it becomes a "new song" even if the ear can't immediately note
the difference, or if fingerprinting claims they are the same song. (case in
point, an acoustic version of a song with only the acoustic guitar being the
difference.)

I have come upon many instances where times don't match, yet the cd is to be
entered or saved as the exact one with the exact track names but incorrect
times representing those tracks. Which is fine by me as far as tagging goes,
however, it is incorrect by the artist's rendering and an accurate music
database.

Example right off the top of my head is Pushmonkey's Advanced release and
the production album. There as well were some Queen albums the same was true
of.
Pushmonkey's Production CD http://musicbrainz.org/showcdtoc.html?id=14098
Pushmonkey's Advance Release http://musicbrainz.org/showcdtoc.html?id=137469
Specifically Track;
3 4:21 for production and 3:51 for advanced
4 4:30 production, 5:04 Advanced

Now, I haven't gotten the purchased CD yet to see if it comes up with those
times, or how the songs differ. But, I can stand behind the advance release
as a sure thing, seeing as I own it and input the TRM. These then would need
their own entries for data correctness in my opinion.

There is also the case of Garth Brook's CD in the Ltd edition where the
times on the back of the cover (for tracks) do not match the actual play
times of the tracks. I'm not sure which album, however I can dig it out if
wanted.

All of this is sort of a moot point when you have end tagging users
inputting unchecked mp3's to get the name and structure down for their
preferred directory structure, share list and music program or what have
you. Unchecked mp3's even one's ripped by the person with the album could
have skips or lossy data conflict, a scratched cd that makes a pop in the
song. Bearing that in mind, you are going to have additional TRM's no matter
what.  (which I know leads to pruning one off TRM's and I wish I could help
more with that.) There is the case of a song that sounds nothing like the
song you are trying to identify showing up in the list, and if I knew more
about how to tell the "appropriate" TRM, I would gladly begin trying to take
care of those.

So, as I would appreciate the "big picture" solution as well, and I wish my
tagger could pick up the advanced relations too might I add. ;) and be able
to tell my hard drive "this is the playlist for this album even though you
only have the mp3 on your hard drive once, and it's listed on four albums
you currently own." The only solution I can see is trying to figure out
where the songs are indeed duplicates and beginning to form some type of
flag pointing them to the various albums they appear on. (much akin to a
playlist, how you can pull it from a single directory, yet it appears on
multiple albums.)

Once that big picture is reached, I am willing to take the time with the
artists I know, to do exactly that (with a few tutorials from someone that
can help me with one or two in the beginning. :D ). At the moment however,
even using the AR, and seeming to have a knack for it. I still have a
difficult time tagging a song so it appears Artist A & Artist B from AR with
SG5's explanation (therefore, it went untitled by both artists and remained
under the first artist as it was listed on the cd.). However l do not feel I
know enough to make an educated vote for change, or to weigh feat. vrs AR
tagging. Personally I liked the feat. and learning which artists performed
on the track, but, I as well do my mp3 tags up with as much information as I
can. IE: producer, performance etc. even if it doesn't show in the name of
the song on the hard drive.  So, I can see where doing away with the feat.
Is better for having the labels of the songs, but where you would still want
a tagger to put the information in the id3 tag and the information not to be
lost.

In the end it comes down to; do you want data that may be inaccurate for the
style guide, yet fully accurate beyond the style guide entered or do you
want to lose some end users that are not as technically savvy, or simply
feel they have better things to do with their time than to commit a long
amount of precious time to learning the various do this and do not do
that(s). I still have not added in the Korean album I have, due to lack of
knowledge with the character set, and am loathe to enter in a classical disc
due to being unsure of the best way to format the entry. Plus have a
multitude of VA discs I am still looking at. At some point, even when you
are trying to do as the SG says, it's daunting to (think you) have it all
down, and then input it in, and hope others will accept, teach (for when you
have messed up) and be practical with their voting and in the end have it
all tossed away to a no vote being made and not reversed, simply because you
didn't put (disc 1) instead of CD1 or, those various things. Where do you
maintain user friendly and build the data base, or make this a project of
"know how to's" and more limited input for the database? Just something to
consider, sorry for the verbosity.

Just a perspective of an end user that has attempted to learn, and been
discouraged and confused but is still plugging away at it, trying to make
sense of it, and feels this is a great project. Where do you maintain user
friendly and build the data base, or make this a project of "know how to's"
and more limited input for the database? Just something to consider, sorry
for the verbosity.
 [Beth]



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

[mb-style] Same track on different albums (was: Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!)

by Matthew Exon :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Beth wrote:

(Robert Munro wrote:)

> 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.
>
> [Beth]
> This would be great, if indeed it was the same song. (same time, no rips
> from copied discs to change it off by a few seconds. No added musical notes
> and added choruses from the artist.)  However, where do you find the actual
> time of a song, the first release, how the song evolved? Some artists are
> simple, all of their songs obviously are the same song exactly, by second
> mark and everything, easily seen with the time remaining the same for each
> VA work that is listed as well. Other artists however are much more
> difficult, they have released many promo tracks via the web, or a prerelease
> album. The name may appear the same, but when it's remastered the track
> sounds different, and when they have actually changed the structure of the
> song, then it becomes a "new song" even if the ear can't immediately note
> the difference, or if fingerprinting claims they are the same song. (case in
> point, an acoustic version of a song with only the acoustic guitar being the
> difference.)
>
> I have come upon many instances where times don't match, yet the cd is to be
> entered or saved as the exact one with the exact track names but incorrect
> times representing those tracks. Which is fine by me as far as tagging goes,
> however, it is incorrect by the artist's rendering and an accurate music
> database.

This is a big problem, and I hope that Robert and everyone realises that
the concept of "the same recording" is a real can of worms.  The problem
is that there isn't just a binary answer "this is the same recording" or
"this is a different recording" in the real world until we impose one.
In real life there's a full spectrum between two tracks being more or
less the same, depending on a range of factors including the precise
track length, whether the spectrum has been manipulated at all (e.g. LPs
and RIAA equalization), whether it's been digitally encoded and back
again, whether it's distributed on the same physical medium, and so
forth.  Even when recordings generate the same TRM and CD TOC, there may
well be users who consider them different enough to warrant separate
entries.

I think Beth's examples are a little extreme: new sections in a song or
acoustic versions should be tagged as different by any reasonable
fingerprinting system.  But I'd also note that the new fingerprinting
algorithm being discussed on -devel would have an entire configuration
file full of hundreds of knobs and buttons that allow the definition of
"same" to be tweaked ad inifinitum.

We already do have just one database entry for the same recording.  It's
just that we have a very tight definition of "the same recording":
namely, two recordings are the same only if they appear on identical
physical media.  Robert's proposal is to loosen this definition.
Loosening the definition involves combining existing entries, and that
means throwing away information.  Some people consider the information
redundant, others don't, and that's where controversy lies.

The GettingRidOfFeaturingArtistStyle is, at core, an analogous problem,
as pointed out by Orion.  The question is, is the artist attribution
"Simon and Garfunkle" the same as "Paul Simon" and "Art Garfunkle"?  Is
the artist attribution "Queen and David Bowie" the same as "Queen" and
"David Bowie"?  If you have both styles in the database, is either of
them redundant?  In fact every situation is unique, so coming up with
general rules to decide what's redundant and what isn't is always going
to be controversial.

So yeah, if you want to go down this road, better be prepared for some
stormy weather...
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!

by Robert (Jamie) Munro :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Rod Begbie wrote:

> On 11/8/05, Don Redman <donredman@...> wrote:
>
>>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.
Maybe he meant you will literally swing between figurative trees (i.e.
trees of data), not trees of the wooden variety. :-)

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

When I was young, no one had ever told me what "literally" meant, so I
had just assumed it meant figuratively, because it was always (as
answers.com puts it) "Used as an intensive before a figurative
expression". I only found out when I tried to correct my Mum when she
was explaining to someone something that had happend to me. I
interrupted her and said "No, that didn't just literally happen, it
ACTUALLY happend".

Robert (Jamie) Munro


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

signature.asc (261 bytes) Download Attachment

RE: [mb-style] Same track on different albums (was: Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!)

by Beth-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



-----Original Message-----
From: musicbrainz-style-bounces@...
[mailto:musicbrainz-style-bounces@...] On Behalf Of Matthew Exon
Sent: Wednesday, November 09, 2005 4:12 AM
To: MusicBrainz style discussion
Subject: [mb-style] Same track on different albums (was: Let's get rid of
the GettingRidOfFeaturingArtistStylediscussion NOW!!)

Beth wrote:

(Robert Munro wrote:)

> 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.
>
> [Beth]
> This would be great, if indeed it was the same song. (same time, no rips
> from copied discs to change it off by a few seconds. No added musical
notes
> and added choruses from the artist.)  However, where do you find the
actual
> time of a song, the first release, how the song evolved? Some artists are
> simple, all of their songs obviously are the same song exactly, by second
> mark and everything, easily seen with the time remaining the same for each
> VA work that is listed as well. Other artists however are much more
> difficult, they have released many promo tracks via the web, or a
prerelease
> album. The name may appear the same, but when it's remastered the track
> sounds different, and when they have actually changed the structure of the
> song, then it becomes a "new song" even if the ear can't immediately note
> the difference, or if fingerprinting claims they are the same song. (case
in
> point, an acoustic version of a song with only the acoustic guitar being
the
> difference.)
>
> I have come upon many instances where times don't match, yet the cd is to
be
> entered or saved as the exact one with the exact track names but incorrect
> times representing those tracks. Which is fine by me as far as tagging
goes,
> however, it is incorrect by the artist's rendering and an accurate music
> database.

This is a big problem, and I hope that Robert and everyone realises that
the concept of "the same recording" is a real can of worms.  The problem
is that there isn't just a binary answer "this is the same recording" or
"this is a different recording" in the real world until we impose one.
In real life there's a full spectrum between two tracks being more or
less the same, depending on a range of factors including the precise
track length, whether the spectrum has been manipulated at all (e.g. LPs
and RIAA equalization), whether it's been digitally encoded and back
again, whether it's distributed on the same physical medium, and so
forth.  Even when recordings generate the same TRM and CD TOC, there may
well be users who consider them different enough to warrant separate
entries.

I think Beth's examples are a little extreme: new sections in a song or
acoustic versions should be tagged as different by any reasonable
fingerprinting system.  But I'd also note that the new fingerprinting
algorithm being discussed on -devel would have an entire configuration
file full of hundreds of knobs and buttons that allow the definition of
"same" to be tweaked ad inifinitum.

[Beth] I am going off of information I've seen in Predixis (another
fingerprinting music program and how it gives duplicates to be weeded out.)
It may be a different method of fingerprinting than musicbrainz uses. Or
perhaps fingerprinting and TRM is still confusing to me and I'm misusing the
terms. [Beth]

We already do have just one database entry for the same recording.  It's
just that we have a very tight definition of "the same recording":
namely, two recordings are the same only if they appear on identical
physical media.  Robert's proposal is to loosen this definition.
Loosening the definition involves combining existing entries, and that
means throwing away information.  Some people consider the information
redundant, others don't, and that's where controversy lies.

The GettingRidOfFeaturingArtistStyle is, at core, an analogous problem,
as pointed out by Orion.  The question is, is the artist attribution
"Simon and Garfunkle" the same as "Paul Simon" and "Art Garfunkle"?  Is
the artist attribution "Queen and David Bowie" the same as "Queen" and
"David Bowie"?  If you have both styles in the database, is either of
them redundant?  In fact every situation is unique, so coming up with
general rules to decide what's redundant and what isn't is always going
to be controversial.

So yeah, if you want to go down this road, better be prepared for some
stormy weather...

[Beth] You summed that up well. Personally I am not pushing for that road, I
imagine I was trying to get a feel for how "technically accurate" the
database was desired to be. Adjusting my thoughts to the database and
attempting to therefore gain a good medium as to editing in the future.
[Beth]
_______________________________________________
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

Re: [mb-style] Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!

by DonRedman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, 09 Nov 2005 01:52:32 +0100, Orion wrote:

>> 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.
>
> You lost me with the "rhizomes and not for trees" part.  To me this is a  
> step towards that - a fix for now that also smooths the transition  
> towards then by making it easier to automate the process of changing  
> them over.  Of course, that's predicated on the assumption that a system  
> like what I outlined will eventually be implemented, but one can always  
> hope...

I was refering to somthing like this:

On Wed, 09 Nov 2005 07:59:34 +0100, Alexander Dupuy wrote:
> So, if the solution to this never-ending discussion is to fix the UI's  
> support for AR, please remember that to *really* solve the problem, it  
> will need to either eliminate the basic, non-AR artist info, or  
> eliminate the second-class treatment of VA albums (perhaps by treating  
> all albums as VA, and allowing VA albums to have an additional "primary"  
> artist (who could be, e.g. a DJ if the album is a mix-album, or a  
> remixer if the album is a remix-album, thereby solving another set of  
> problems).

It seems to me that Robert Munroe and me are the only people here who  
believe that all our current problems in storing data could be solved, if  
we would just use AR the right way. I firmly believe that we do not need  
that major change of core relationships that ruaok and Lukas seem to have  
agreed upon.

BUT the last three mails (between Orion and me) pointed out to me, that I  
want to keep this underlying question out of the FeaturingArtistStyle  
debate.

I am currently very taken by the Uni, but this should get better next  
week. I really want to take some time then and try to explain what I  
believe Robert Munroe and me are anticipating, and what I have summarized  
as "rhizomes not trees". In one sentence (which might be as cryptic) the  
bottom line of AR to me is this:

AR is chaotic, but the net is chaotic to, and Google seems to deal with it  
quite well. Instead of trying to force structure onto the madness (by  
doing core schema changes) we should adapt our way of dealing with the  
madness.

More next week (and on mb-experts).

   DonRedman, who has become pretty light-hearted about  
GettingRidOfFeaturingArtistStyle by now :-)

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

RE: [mb-style] Let's get rid of theGettingRidOfFeaturingArtistStylediscussion NOW!!

by Cristov Russell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> It seems to me that Robert Munroe and me are the only people
> here who believe that all our current problems in storing
> data could be solved, if we would just use AR the right way.

For the record I agree with both of you as well. Unfortunately I can't be at
the summit. It would be nice if you guys could webcast the summit and have
people join but in Europe that could be a lot to ask for since internet
access isn't cheap.

________________________________
Cristov (wolfsong)

A fanatic is one who can't change his mind and won't change the subject. -
Sir Winston Leonard Spencer Churchill


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

Re: [mb-style] Let's get rid of theGettingRidOfFeaturingArtistStylediscussion NOW!!

by DonRedman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, 09 Nov 2005 06:36:12 +0100, Rod Begbie wrote:

> On 11/9/05, Cristov Russell <wolfsong@...> wrote:
>> So to offer my own metaphor, you feel that because there are some  
>> people who
>> ignore the posted speed limit it should be raised to accommodate them
>> because they haven't yet caused an accident even though there are still
>> safety issues.
>
> Yes, but only if the roadsigns are printed in Belgian, all drivers are
> talking on cellphones, the roads are paved with broken glass and
> twigs, and don't go anywhere near the city you're trying to get to,
> but there are plans to vulcanise tyres in the next year or so, and
> everyone will drive hybrid cars.
>
> Where the twigs represent SG5.

Uh, I don't get that? Does that mean that I was pointing at the Flamish  
roadsigns, the use of cellphones, the broken glass etc. But you just want  
the twigs removed?

I do not think you meant to say that, but that is the way I read _your_  
usage of Chrstov's metaphor.

> "People who talk in metaphors outta shampoo my crotch." -- Jack
> Nicholson, As Good As It Gets

Metaphors can bite back. Don't ever let them near you crotch. -- Me, now  
:-)

   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

Re: [mb-style] Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!

by Fuchs :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 11/10/05, Don Redman <donredman@...> wrote:
> It seems to me that Robert Munroe and me are the only people here who
> believe that all our current problems in storing data could be solved, if
> we would just use AR the right way. I firmly believe that we do not need
> that major change of core relationships that ruaok and Lukas seem to have
> agreed upon.

First, it's no major change but a small one, that is necessary for AR
to work at all.

Currently it doesn't, because all this "link to the first release",
using n ARs to link n identical items to a related one (A remixed X, n
identical instances of X in the DB) makes no sense. It creates a1)
inconsistencies or a2) edit "floods" when changing X or b) incomplete
data, because not all the links from all existing X are created.

But doing the core-schema change also helps for non-AR operations.
Think of an updated guideline, that says X should be reformatted. ATM,
we need to find all the n instances of X and then do n changes. After
improving the core-schema, only one change is necessary and the data
is always consistent with the additional benefit, that we need a
smaller amount of memory to store the data in the DB.

And, I can only repeat myself, the core-schema is static, the
AR-schema is dynamic. You once told me, that AR is some nice feature,
to expand the db-structure to support storing of additional meta-data
without changing any implementation. By creating special handling of
some AR-types, you break this concept, AR won't be independent of the
server implementation anymore.

This also means, you have to change server code anyway, and modifying
the core-schema and adapting the code is cleaner, faster and IMO even
_easier_ to implement than producing a similar result by doing some
kludgy AR tweaking.


There are other reasons like ARs being unable to represent ordered
relations, which we had to be implemented to solve the current
problem, too. This would break the small and simple concept of ARs
being (entity, predicate, entity) triples, that are _independent_ of
other AR-triples. But even the reasons mentioned above alone are worth
implementing it in the core-structure IMO.


Sorry, for being pretty much OT here, but this discussion has evolved
into a general one already. ;)


#Fuchs

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

[mb-style] What to do with AR (Was: Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!)

by DonRedman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, 10 Nov 2005 18:11:14 +0100, Björn Krombholz wrote:

> On 11/10/05, Don Redman <donredman@...> wrote:
>> It seems to me that Robert Munroe and me are the only people here who
>> believe that all our current problems in storing data could be solved,  
>> if
>> we would just use AR the right way. I firmly believe that we do not need
>> that major change of core relationships that ruaok and Lukas seem to  
>> have
>> agreed upon.
>
> First, it's no major change but a small one, that is necessary for AR
> to work at all.
>
> Currently it doesn't, because all this "link to the first release",
> using n ARs to link n identical items to a related one (A remixed X, n
> identical instances of X in the DB) makes no sense. It creates a1)
> inconsistencies or a2) edit "floods" when changing X or b) incomplete
> data, because not all the links from all existing X are created.

How is the core schema change going to solve this? IIUC this can be solved  
by AdvancedEntities only.

> And, I can only repeat myself, the core-schema is static, the
> AR-schema is dynamic. You once told me, that AR is some nice feature,
> to expand the db-structure to support storing of additional meta-data
> without changing any implementation. By creating special handling of
> some AR-types, you break this concept, AR won't be independent of the
> server implementation anymore.
>
> This also means, you have to change server code anyway, and modifying
> the core-schema and adapting the code is cleaner, faster and IMO even
> _easier_ to implement than producing a similar result by doing some
> kludgy AR tweaking.

Yes and no. It will be dependent on server side interfaces, but in a way  
it is already. The point I see is that interfaces can be modulare and each  
interface can deal with some AR types in a way that is special to _this_  
interface. On the data storage level no AR type will be special.

I'll have more time to explain this in detail next week.

> Sorry, for being pretty much OT here, but this discussion has evolved
> into a general one already. ;)

I just don't think this is OT at all. It is (with the question what is a  
valid entity of its own) one of the core problems of the  
FeaturingArtistStyle debate.

Perhaps we should move this to mb-experts, though. I have cross posted  
this mail in order to achieve 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

Re: [mb-style] What to do with AR (Was: Let's get rid of the GettingRidOfFeaturingArtistStylediscussion NOW!!)

by DonRedman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Fri, 11 Nov 2005 10:01:31 +0100, Don Redman wrote:

> On Thu, 10 Nov 2005 18:11:14 +0100, Björn Krombholz wrote:

>> This also means, you have to change server code anyway, and modifying
>> the core-schema and adapting the code is cleaner, faster and IMO even
>> _easier_ to implement than producing a similar result by doing some
>> kludgy AR tweaking.
>
> Yes and no. It will be dependent on server side interfaces, but in a way  
> it is already. The point I see is that interfaces can be modular and  
> each interface can deal with some AR types in a way that is special to  
> _this_ interface. On the data storage level no AR type will be special.
>
> I'll have more time to explain this in detail next week.

Well I've finally had that time. Here is the result:

http://wiki.musicbrainz.org/ToSchemaOrNotToSchema

   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
< Prev | 1 - 2 - 3 - 4 - 5 | Next >