[mb-devel] Re: MusicBrainz-devel Digest, Vol 43, Issue 9

[Frederic Da Vitoria]

2007/3/23, Bogdan Butnaru <bogdanb at gmail.com>:
> 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.

So do I, but you are right, it is worth reminding.


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

I agree and disagree: True, our primary goal is and should stay the
objective data. But I disagree in two points:
- one... subjective: if I collaborate to MB, it is because I love
music. And I love music for entirely subjective reasons. Please
understand that the subjective nature of this remark does not make it
less important to me. It is just the opposite, this is the single most
important motivation for me, and this motivation is entirely
subjective. So asking me (and others users) to work only on the
objective aspect of what is a subjective passion is not very logical
IMO.

- one objective: we do need more collaborators. Many editors complain
there is too much work. The best (only?) way to address the problem
IMO is to gather more editors. I don not say as many editors as
possible, just more editors.


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

Quite, but
- there is so much work to do that many editors feel compelled to work
on everything at the same time (I know, I did at one time).
- many specialized shops sell some articles which are a little out of
their domain. There is a difference between a supermarket and a
bookshop who sells only dictionaries. Even bookshops often sell a few
sweets to attract children, and children's parents... Again, I agree
we should keep our main objective (a little confusing word, here, I
meant of course "aim"), but why not make things a little more
attractive. Dryness isn't necessarily good, especially when the
subject is art!


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

You are right, I hadn't thought of all the technical implications. I
believe most of these issues aren't issues at all or could be easily
solved. But I agree the user interface must indeed be carefully
prepared.


-- 
Frederic Da Vitoria