[mb-devel] Re: MusicBrainz-devel Digest, Vol 43, Issue 9
Bogdan Butnaru
bogdanb at gmail.com
Fri Mar 23 13:43:44 UTC 2007
I'm not sure I should continue the discussion here (it's maybe a bit
too long-term for devel) but here goes:
First, don't get me wrong: I don't use the term "subjective data" as
in "flawed data", but in the literal sense, as the antonym of
"objective". I'd very much like to have access to both kinds, in
different situations.
> Date: Thu, 22 Mar 2007 13:48:22 +0100
> From: "Frederic Da Vitoria" <davitofrg at gmail.com>
> 2007/3/22, Bogdan Butnaru <bogdanb at gmail.com>:
> > > I have been dreaming of this for a long time too. I believe this would
> > > give new aspect to MB, which is currently purely technical.
> > I think entering the subjective area (genres, ratings, comments) would
> > be detrimental, because it would dilute the focus. It is better, I
> > think, that MusicBrainz retains its objective focus, and a separate
> > project would handle the subjective aspect, using the MusicBrainz data
> > through the web service (or a more direct link) to anchor user input.
>
> I believe you think this because you view the users as a finite set.
> True, it would distract current users, but it would certainly bring
> new users which would also bring their objective contribution. Just
> like a shop: if you sell only one limited category of products, true
> you are a specialist, but you will have few customers.
Not quite. I am aware of the "other" users (though I myself would use
the subjective parts of the database). As far as you metaphor goes, I
don't think it's an obviously good trade-off to distract current users
in order to gain more users. It's a classic error (IMO) to annoy your
current user-base trying to gain a larger one. After all, MusicBrainz
(at the moment) doesn't have the purpose to have as many users as
possible, but to be a good music database. (Otherwise, we'd do myspace
or something.)
Don't rush to answer. I tend to exaggerate a bit, and I probably did
above. What I mean is that you should consider seriously that in our
case it might be better to be a specialist rather than simply have
more users. A mall with many small but well-focused shops is sometimes
preferable to a huge hall with everything in it. Not always, I know.
Supermarkets have their purpose, too. I just think that MusicBrainz is
more akin to a specialist boutique than to a market. We have rules,
guidelines, users with very particular tastes, and we put quality
above quantity (that's why we have the voting system).
> > Actually, the ideal case would be IMO something like last.fm, but
> > using the MB data. [...] Doing all this within MB would
> > complicate things enormously and muddy every decision we'll have to
> > take from now on.
>
> Physically separating the subjective part from the objective part
> could be a good idea. But I don't think the subjective part would be
> very complicated: comments and votes, nothing difficult here! I am not
> saying it is easy, but there is nothing "enormous" here, and I know
> our developers have much more urgent matters to address, nor that we
> should do it tomorrow, but I think this is definitely an idea worth
> exploring.
>
> And I really don't see how it could affect the objective work: The
> fact I like or don't like a track or release does not change the way I
> would store objective information about it not my votes about it.
I said they should be separated because I think small tools that do a
few things well are better than one that does everything but not so
well. Robert proposed (see below) that they can exist one without the
other, which pretty much means they are separate projects.
First of all, consider that the two types of editing are mostly
separated: many people will tag or vote on an album or a single track
(which is an "edit" type of operation), while in MB only a few do,
until it's well-recorded. This means that they're separate operations,
so we'll need different interfaces for them, or a big clunky interface
for both. In the first case, we might as well have two sites, in the
second, we'll have the detrimental things I referred to: when trying
to do one kind of edit, you'll encounter the other, which means more
stuff to download, the screen filled with more buttons and boxes, less
focus, more confusion, more errors.
It'll be harder to make updates (because more can break in case of
errors). And there are harder issues, too. Consider simple operations
like moving or deleting or merging albums. From just the objective
point of view, it's (usually, I know we have flames too) a simple
thing: this track should not be here, this is from the other artist of
the same name, etc.
But when the item in question has tags and votes (subjective data)
from, say 5000 people who like the song/album/artist in question, the
problem is very different and rather hard. I don't mean that it can't
be solved, but that we need to separate the issues, and to have
different teams that handle the different kind of problems. 500 (say)
tags in the database for the 10% most liked artists is not necessarily
huge from the computers' point of view, but it means a _lot_ of user
input, which is valuable, and which will change a lot how we see
things. We'll need changes to the database, which are risky, so with
two services in the same place one will delay the other's updates.
Now, I didn't express myself very well in the last mail: Just because
they're separated doesn't mean they can't be both presented on the
same site. Robert says he'd like to make sure the two don't affect
each other, and in fact one can run with the other:
> Date: Thu, 22 Mar 2007 22:16:10 -0700
> From: Robert Kaye <rob at eorbit.net>
> On Mar 22, 2007, at 5:21 AM, Bogdan Butnaru wrote:
>
> > I think entering the subjective area (genres, ratings, comments) would
> > be detrimental, because it would dilute the focus. It is better, I
> > think, that MusicBrainz retains its objective focus, and a separate
> > project would handle the subjective aspect, using the MusicBrainz data
> > through the web service (or a more direct link) to anchor user input.
>
> Searching, music discovery, listener discover are all fun things that
> can be made possible with subjective data. I agree that we'll have to
> make sure that people who want a objective experience can have that
> without having to participate in the subjective. And vice versa. The
> same goes for the hosting side of things. I want to make sure that
> one can exist without the other -- for instance, if the tag server
> gets bogged down, the objective data server should still do its job.
But actually I think the best way to do that would be actually to have
two "sites". This doesn't mean that the subjective thing won't be
called MusicBrainz, too --- actually, it would make a lot of sense to
be called that, and accessible through the same home page. But I think
that the two kinds of navigation/editing will be separate (because it
will be done by different people at different times), so each should
be presented in the best way.
It also doesn't mean they'll be cleanly separated. I imagine the site
(HTML pages people use to access it) will connect many items. I think
they'll connect often, and perhaps with other sites, too:
We (or someone else) may have a site that specializes in music-related
images. It would have a database that associates MusicBrainz IDs (for
albums, artists, songs) with images (covers, photos, etc). Another
site might specialize in lyrics, again using the MB IDs to represent
the songs. The separation allows each site to be very good at what it
does, it allows interfaces (sites or music programs) that present the
info in aggregate, and that are pluggable. So if one of the modules
fails (from legal problems to server crash) the rest works,
independently, and the failed one can be replaced.
All this is dependent on a single high-quality repository that does
approximately what MB does: gives unique IDs to music concepts
(artists and songs), and records the objective relations between them.
This is very important, because it will allow other services to
interact. Otherwise, we get unpleasant messes like last.fm has with
same-named artists, etc. The rest can be added separately, and it
should be, exactly because the 'central classification system' needs
to be as good as can be.
-- Bogdan Butnaru — bogdanb at gmail.com
"I think I am a fallen star, I should wish on myself." – O.
More information about the MusicBrainz-devel
mailing list