> On 10/18/05, Cristov Russell <
wolfsong@...> wrote:
> > 1st: I can find nothing wrong with mo's mods, he followed the SG
> > exactly and corrected your incorrect use of the Artist field data.
>
> I agree that he followed the SG. However, I consider the SG
> broken, and I want it changed, so that this doesn't keep happening.
>
> > 2nd: I see no data loss whatsoever.
>
> Explain to me how, at a SQL level, I can identify Ice-T as a
> performer on this track:
>
http://musicbrainz.org/track/481a78d2-0524-45c9-b094-29d1ed750ff7.html>
> Before mo mangled it, it was possible to use the
> collaboration ARs on the "Slayer & Ice-T" artist to make the
> join. Now, it isn't. This moderation *reduced* the
> usefulness of MB data.
I don't think that's exactly true. There is a already a script that runs
that creates AR links based parsed from titles containing feat. Further it's
bad data design to consolidate unique data (each artist) that exists
separately elsewhere in the database to create what is essentially not
unique data.
> > 3rd: Railing away and making demands probably won't get the
> support of
> > myself or other members of the SC. This is a long standing problem
> > that no one really likes but for which there is no simply solution.
> > This has already been reiterated in each thread you
> mentioned by several members of the SC.
>
> In May, I was told to "give it time". It's been four and a
> half months, and I see no improvement.
>
> Squeaky wheel, etc.
>
> I find "we'll get to it after AR can deal with it".... "we'll
> get to it when Picard can deal with it"... "We'll get to it
> when our alien overlords can deal with it"... an
> unsatisfactory answer.
Squeaking is fine but be productive about. Email by the was is a fairly
inefficient means of "squeaking", it can be ignored and deleted.
Contributing via development of ideas or financially however is far more
productive.
> >> 2) The "put (feat.) in the title" hack was only in place because
> >> there was no way to link artists to collaborations.
> >> Now there is.
> >> It's AR. It works.
> > Wrong. AR does NOT work ANY tagger...yet.
>
> Read my statement again. I say nothing about tagging. I'm
> talking about data storage.
>
> MB is oh so much more than just a way to tag MP3s.
You've missed MB's primary purpose. Read the About page.
http://musicbrainz.org/wd/AboutMusicBrainz. What else do you believe this
data is currently or in the foreseeable future going to be used for?
> > Until it can, the hack is
> > necessary.
>
> Why? Why is it necessary? Are there any users who are
> saying "Please put artist information in the title field of my MP3s"?
>
> Re-reading the "no mean (feat.)" thread, the concensus from
> Style Guide members seemed to be that putting it in Title was
> wrong, and that "the" tagger should be putting them in the
> artist field in the future.
Moving all the information to AR when the tagger can't access AR info is bad
for tagging. When the tagger can support it, changing this rule will make
more sense.
> Personally, I'd like my MP3 tags to resemble the information
> from the back of the CD sleeve.
So using MB for tags IS important to you as well. You always have the option
to change the tags to whatever you want but MB isn't about you personally.
One of the long term questions MB faces is "how can members of the MB
community utilize the data to fit there own preferences?". Again, one of the
things that has been envisioned is an updated tagger that allows the user to
decide how their tags should look. Some people will want different things.
Wouldn't it be better if EVERYONE gets what they want?
What you're describing is not so much a problem with the SG but a problem
with the way the data can be used.
> Either way, the database isn't going to be able to do that
> without a lot of editing in the future, and the current state
> of the SG will just keep compounding this. The more crap we
> pour in now, the more we'll need to sift in "The Future" to
> find the nuggets of corn.
This same argument came up last year when there was a huge push for getting
AR out the door. The developers looked at it, reprioritized it, and worked
really hard to get it out the door ASAP. When it arrived, everyone was
thrilled that we had this long long long awaited feature but as days went
by, people noticed a flaw in the design. AR isn't that easy to use. The
interface can be a bit cumbersome when it comes to entering large amounts of
metadata. Almost as soon as AR was out, everyone was complaining again. I'm
willing to bet that hardly any AR data is being created at the track level
at all and that's the only way place that your SQL could return the kind of
results you're looking for. Are you saying that you're willing to commit to
entering AR links to every track for the mods you enter? Chew on that a
while before you answer.
> > > 3) In "The Future", we may have smarter taggers, or a
> different DB
> > > schema that can assign more than one artist to a track.
> But we're
> > > not in the future, we're in the present.
> > > And presently, the best way to store this data, SO THAT IT CAN BE
> > > ADAPTED TO FUTURE WHIMS is to use AR to specify collaborations.
> >
> > The initial release of AR was never intended to replace the
> SG, only
> > to add more functionality.
>
> You're missing my point. I know that AR isn't a replacement for a SG.
> You need both. But the SG needs to change to take into
> account the existence of AR.
>
> To quote myself from five months ago:
> ---
> So since there is a clear plan, namely that In The Future, "the"
> tagger (and, let's not forget, any other app powered by the
> MB data) will allow the user to customize how the data will
> be used to populate "artist" and "title" fields, why don't we
> start cleaning the data
> *now* by changing the styleguide?
> ---
>
> No-one answered that question satisfactorily. Jamie Munro
> made some excellent points about future directions the
> database could go, but nothing that precluded this SG change
> as an intermediary event.
That was not first time the issues with SG5 have been raised. Believe me,
there was a time not long ago (a year and 3 days to be exact
http://lists.musicbrainz.org/pipermail/musicbrainz-users/2004-October/018505.html) when I rallied behind Tarragon to kill it but my opinions on this
change over time and not long after AR's launch had an entirely different
perspective on why we can't rush to change it.
> > > 4) Deleting collaborative artists, picking one at
> random, stuffing
> > > the other in the text Title field ONLY MAKES IT HARDER
> FOR THIS TO
> > > HAPPEN in "The Future".
> >
> > It's what makes sense with the current schema.
>
> I disagree. It's what made sense with the schema a year ago.
> It's inappropriate for the current schema.
The current SG is more than a year old so it has made sense for some time
now. There has not been a significant event to justify changing SG5 in
particular...yet.
> > > Please, for my sanity's sake, can we change the styleguide?
> >
> > Not yet.
>
> Do you now speak on behalf of the entire Style Council? Is
> there a musicbrainz-cabal list where you've discussed this
> proposal in detail before giving your official ruling?
>
> Or could we perhaps get a vote from the Style Council members?
>
> [ ] Leave as is until Picard is finished (in about 12-18
> months) [ ] Change SG5 now [ ] Other
>
> Rod.
No that was solely my own point of view. However, it's been proposed that
you'll need the consensus of at least 3 council members and I believe the
primary minister of the area it touches. Depending on how you look it at,
that may mean myself or Gecks and personally I'm not convinced the time is
now. That in no way means it still can't happen but I also think Robert Kaye
is in agreement with me on this and while not a member of the SC, as primary
coder and founder, his opinion is influential.
________________________________
Cristov (wolfsong)
Feel the power of team work; If you know that a drop of water easily gets
dried And a pool of water hardly gets dried. - Brian Hu
_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users