2006/5/24, Don Redman <[EMAIL PROTECTED]>:
On Mon, 22 May 2006 23:53:34 +0200, Lars Aronsson wrote:
> Alexander Dupuy wrote:
>
>> I'm afraid that I agree with mudcrow on this; there are a number
>> of reasons that it makes sense for the composer to be credited
>> as the primary artist for soundtracks in most cases (with an
>> exception for non-classical music included
>
> To a newcomer like me, it seems absurd that the archaic notion of
> "primary artist" (i.e. the artist column of the album and track
> tables) wasn't removed when AdvancedRelationships were introduced
> in April 2005. Was this a deliberate decision, and was the reason
> documented? Or was it just forgotten by mistake? Is it too late
> to do it now?
The main reason is of course historical. MB has grown slowly, AR have been
added _on_top_ of the old unchanged database, and many clients expect a
single 'archaic' artist field.
The development of MB is very "heritage aware" and backwards compatible,
because "MusicBrainz" is much more than just the database. It is a pretty
huge system made up of many different parts that should all be taken into
account.
Yes, and I am not complaining about this. Part of why is MB is what it
currently is (and why it can become what I dream it will) is because
it started by trying to address the popular mp3 tagging problem. This
attracted users which in turn input the data which is currently here.
So I recognize the mp3 heritage and I welcome it and I wouldn't want
it to disappear. But to take a musicological analogy, archaic music
probably started with percussion instruments. We still use these
instruments. But rythmic indication is now only a part of how we
consider music, often a minor part, and this is how it should be.
Artist was a fundamental field in the mp3 period (which we are still
pretty much in) but if we want to evolve to a full-fledged music
database, we will have to relegate the Artist to it's true place: a
mp3 field. Period. And if (when?) mp3 disappears (who knows what will
happen 10 years from now?) the Artist will may very well have no
meaning anymore.
One example for this is the Aspect Model of NadelnderBambus: There are
different aspects of the data and different clients or users expect
different ones. We have identified the "What is is" and the "What it is
called" aspect as two that we want to retain.
What you suggest only deals with the "What it is" aspect. I believe the
Primary Aritst is the current way of serving the "What it is called"
aspect. It does so very pooly --agreed -- but it cannot simply be dropped.
Not in the current database schema. But the NextGenerationSchema seems
to take this direction (though I am not sure I understand the limits
of all the relations there).
> The table l_album_artist would grow from 17K rows to 408K rows and
> the l_artist_track would grow from 55K rows to 4.7M rows. In the
> plaintext database dump, these tables average 45 bytes per row,
> and a little less (5 integers and 2 dates) in the binary database.
> The amounts of data are quite manageable.
A second reason is performance. I do not know the technical details (and I
know this is disputed) but Robert said that AR are not powerful enough for
the database to rely mainly on them, and that there will always be
powerful and relatively fixed "Core Relationships" and flexible but less
powerful AdvancedRelationships.
I didn't check for specifics (I don't see how ARs are implemented in
the current schema, I even have a feeling they are not in
http://wiki.musicbrainz.org/DatabaseSchema/FullSize), but I can guess
why Robert says this. But we don't Artist need the Artist as a Core
Relationship, we can use Composer and Performer, for example.
Where would IMDb be if it had tried to use Artist instead of actors
and directors :-D Note that in the end, IMDb is able to say that
someone directed a film and played in another, but the two roles are
always clearly indicated. Never does IMDb use such a fuzzy concept as
Artist.
--
Frederic Da Vitoria
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
