Paul C. Bryan | 1 Aug 2009 03:00
Gravatar

Re: RFC: Release Groups guideline

I think the "different-enough-ness" of which you speak is when there is
artistic merit in differentiating one release from another. The example
cited in edit #10956897 -- the McCartney remix of "Let It Be" entitled
"Let It Be... Naked" warrants a separate release group through this
distinction.

Your argument leads us down the path of having several release groups
for every concert a popular band performs. Theoretically, if 100 people
record and publish a concert, by your logic every recording deserves to
be its own release group. IMO, it should be a single release group
(representing the work of the *artist* -- in this case the band
performing the concert) with potentially 100 versions listed within the
group.

As was also pointed-out, we're not losing information here. We're not
merging releases. We're grouping them in a way that makes their listing
and consumption manageable.

Paul

On Fri, 2009-07-31 at 20:40 -0400, Brian Schweitzer wrote:
> On Fri, Jul 31, 2009 at 6:32 PM, Aurélien Mino <a.mino <at> free.fr> wrote:
>         Nikolai Prokoschenko wrote:
>         > Dear fellow Brainerz,
>         >
>         > it seems that my earlier mail got lost in the depths of
>         Gmane gateways :( I
>         > won't repeat everything I've written in the last mail, you
>         know how it works
>         > better than me. So here it goes again: we are now ready to
(Continue reading)

Brian Schweitzer | 1 Aug 2009 03:34
Picon

Re: RFC: Release Groups guideline

On Fri, Jul 31, 2009 at 9:00 PM, Paul C. Bryan <email-Xf9ZKMLjR+qsTnJN9+BGXg@public.gmane.org> wrote:
I think the "different-enough-ness" of which you speak is when there is
artistic merit in differentiating one release from another. The example
cited in edit #10956897 -- the McCartney remix of "Let It Be" entitled
"Let It Be... Naked" warrants a separate release group through this
distinction.

Your argument leads us down the path of having several release groups
for every concert a popular band performs. Theoretically, if 100 people
record and publish a concert, by your logic every recording deserves to
be its own release group. IMO, it should be a single release group
(representing the work of the *artist* -- in this case the band
performing the concert) with potentially 100 versions listed within the
group.

As was also pointed-out, we're not losing information here. We're not
merging releases. We're grouping them in a way that makes their listing
and consumption manageable.

We're not losing some specific bit of data, no.  But what we are losing is the semantic concept of a "release group" being consistently "a group of releases with the same audio".  Each entity type in the database describes some consistent "something".  The proposed change, making RGs conceptual groupings, rather than groupings based on "same audio", changes that.  Now you have one "sameness" for albums, a different one for remixes, a different one for audiobooks, yet another for soundtracks, and still yet at least two others for live releases, depending on if they're bootleg, or official.

Thus, we are losing information, in losing the specific meaning of a basic entity type.  We're not doing it for any real benefit, either.  It doesn't help those who collect bootlegs, as now they have all recordings for a show dumped in together, even though they are entirely different.  It only serves to gain "cleaner looking artist listings".  Honestly, since when did we ever decide to actually change data, the meaning of entity types, or decide to make an objective field into a subjective field simple because it made one view of the data look "cleaner"?  If people want session entities, to group all tracks/releases recorded on a given date together, they ought to support the SessionProposal after NGS, not try to change RG's in a manner which lessens the utility of RGs.

Brian
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Paul C. Bryan | 1 Aug 2009 06:40
Gravatar

Re: RFC: Release Groups guideline

I can't accept your argument that we're "losing the semantic concept" as
you put it because such a concept is not yet generally accepted. The
purpose of this thread as I see it is to define the meaning of RGs in
context of different types of releases.

While grouping bootleg releases for the same event doesn't "help those
who collect bootlegs", but I'd argue that it better serves the community
as a whole, by not listing every possible recording of the same concert.

Again, I base this on the principle that a release group should be meant
to logically group the works of the artist, not those recording. In the
case of bootlegs and official live releases, the logical work is the
live performance of the primary artist.

On Fri, 2009-07-31 at 21:34 -0400, Brian Schweitzer wrote:
> On Fri, Jul 31, 2009 at 9:00 PM, Paul C. Bryan <email@...>
> wrote:
>         I think the "different-enough-ness" of which you speak is when
>         there is
>         artistic merit in differentiating one release from another.
>         The example
>         cited in edit #10956897 -- the McCartney remix of "Let It Be"
>         entitled
>         "Let It Be... Naked" warrants a separate release group through
>         this
>         distinction.
>         
>         Your argument leads us down the path of having several release
>         groups
>         for every concert a popular band performs. Theoretically, if
>         100 people
>         record and publish a concert, by your logic every recording
>         deserves to
>         be its own release group. IMO, it should be a single release
>         group
>         (representing the work of the *artist* -- in this case the
>         band
>         performing the concert) with potentially 100 versions listed
>         within the
>         group.
>         
>         As was also pointed-out, we're not losing information here.
>         We're not
>         merging releases. We're grouping them in a way that makes
>         their listing
>         and consumption manageable.
> 
> We're not losing some specific bit of data, no.  But what we are
> losing is the semantic concept of a "release group" being consistently
> "a group of releases with the same audio".  Each entity type in the
> database describes some consistent "something".  The proposed change,
> making RGs conceptual groupings, rather than groupings based on "same
> audio", changes that.  Now you have one "sameness" for albums, a
> different one for remixes, a different one for audiobooks, yet another
> for soundtracks, and still yet at least two others for live releases,
> depending on if they're bootleg, or official.
> 
> Thus, we are losing information, in losing the specific meaning of a
> basic entity type.  We're not doing it for any real benefit, either.
> It doesn't help those who collect bootlegs, as now they have all
> recordings for a show dumped in together, even though they are
> entirely different.  It only serves to gain "cleaner looking artist
> listings".  Honestly, since when did we ever decide to actually change
> data, the meaning of entity types, or decide to make an objective
> field into a subjective field simple because it made one view of the
> data look "cleaner"?  If people want session entities, to group all
> tracks/releases recorded on a given date together, they ought to
> support the SessionProposal after NGS, not try to change RG's in a
> manner which lessens the utility of RGs.
> 
> Brian
> _______________________________________________
> Musicbrainz-style mailing list
> Musicbrainz-style@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Brian Schweitzer | 1 Aug 2009 08:35
Picon

Re: RFC: Release Groups guideline

On Sat, Aug 1, 2009 at 12:40 AM, Paul C. Bryan <email-Xf9ZKMLjR+qsTnJN9+BGXg@public.gmane.org> wrote:
I can't accept your argument that we're "losing the semantic concept" as
you put it because such a concept is not yet generally accepted. The
purpose of this thread as I see it is to define the meaning of RGs in
context of different types of releases.

The problem as I see it is that there would not be a single semantic meaning to the RG entity, were this proposed change to pass.  "Same audio" (in the sense of having a shared raw audio source at the recording level) is a concept that works no matter the type+status. 

On the opposing side, "same book", "same movie", "same concert", "same album", etc, all are samenesses - but not the _same_ sameness.  There's no semantic meaning inherent, then, in the mere fact of some random releases being grouped together; determining whether to merge 2 RGs then also has a semantic test based on what the status and/or release is, and voting no longer is factually based around a shared recording source, but is instead subjective, based on both voters deciding if they agree with whatever sameness rationale, *and* if they also agree that this is the one *most* important sameness rationale (given that RG:release would remain 1:1, not n:1, even if this proposal passes).

While grouping bootleg releases for the same event doesn't "help those
who collect bootlegs", but I'd argue that it better serves the community
as a whole, by not listing every possible recording of the same concert.

Again, I base this on the principle that a release group should be meant
to logically group the works of the artist, not those recording. In the
case of bootlegs and official live releases, the logical work is the
live performance of the primary artist.

 Yet, as others have said many a time, we aren't a tour-ography.  We're a database of releases and such.  While I agree that we definitely have a need for an ability to track tour dates, performances, setlists, and then to link those to tracks/releases, I disagree that turning RGs into "pseudo-sessions" is the right way. 

Brian
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Paul C. Bryan | 1 Aug 2009 09:41
Gravatar

Re: RFC: Release Groups guideline

On Sat, 2009-08-01 at 02:35 -0400, Brian Schweitzer wrote:

> The problem as I see it is that there would not be a single semantic
> meaning to the RG entity, were this proposed change to pass.  "Same
> audio" (in the sense of having a shared raw audio source at the
> recording level) is a concept that works no matter the type+status.  

I believe we can achieve a fairly uniform semantic meaning: a logical
grouping of the body of work of the primary artist.

Raw audio source just seems like a red herring to me. Remixes, mashups,
compilations, dual albums, multi-album box sets: these already break the
model you're arguing for, to which we've already made exceptions.

I'm just suggesting we go one exception further in the case of
recordings of live performances.

> On the opposing side, "same book", "same movie", "same concert", "same
> album", etc, all are samenesses - but not the _same_ sameness.
> There's no semantic meaning inherent, then, in the mere fact of some
> random releases being grouped together; determining whether to merge 2
> RGs then also has a semantic test based on what the status and/or
> release is, and voting no longer is factually based around a shared
> recording source, but is instead subjective, based on both voters
> deciding if they agree with whatever sameness rationale, *and* if they
> also agree that this is the one *most* important sameness rationale
> (given that RG:release would remain 1:1, not n:1, even if this
> proposal passes).
> 
>         While grouping bootleg releases for the same event doesn't
>         "help those
>         who collect bootlegs", but I'd argue that it better serves the
>         community
>         as a whole, by not listing every possible recording of the
>         same concert.
>         
>         Again, I base this on the principle that a release group
>         should be meant
>         to logically group the works of the artist, not those
>         recording. In the
>         case of bootlegs and official live releases, the logical work
>         is the
>         live performance of the primary artist.
> 
>  Yet, as others have said many a time, we aren't a tour-ography.
> We're a database of releases and such.  While I agree that we
> definitely have a need for an ability to track tour dates,
> performances, setlists, and then to link those to tracks/releases, I
> disagree that turning RGs into "pseudo-sessions" is the right way.
>   
> 
> Brian
> 
> _______________________________________________
> Musicbrainz-style mailing list
> Musicbrainz-style@...
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Olivier | 1 Aug 2009 08:54
Picon

Re: RFC: Release Groups guideline

2009/8/1 Brian Schweitzer <brian.brianschweitzer <at> gmail.com>:
> On Sat, Aug 1, 2009 at 12:40 AM, Paul C. Bryan <email <at> pbryan.net> wrote:
> The problem as I see it is that there would not be a single semantic meaning
> to the RG entity, were this proposed change to pass.  "Same audio" (in the
> sense of having a shared raw audio source at the recording level) is a
> concept that works no matter the type+status.
>

Not true.

The same recording can be printed as is, then later overdubbed with a
new part (see Quintet of the Year vs Debut) and released again. This
is the same sound by your definition ("(in the
sense of having a shared raw audio source at the recording level)"),
yet a (very) different release.

Not going that far, a specific release may appear as a disc in a
boxset, with the exact same content. Still not part of the same
Release Group.

IMHO, you try to present things as "clear" and unambiguous in this
definition (and as unclear and ambiguous in the other), while they are
not.

All in all, I'm not shocked by the suggestion that the same concert
should belong to the same release group. This makes a lot of sense,
and even add some interesting "semantic" in the artist page (eg: by
grouping all variants of the same concert).

2 cents,

Cheers,

- Olivier

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style <at> lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Chad Wilson | 1 Aug 2009 04:06
Picon
Gravatar

Re: RFC: Release Groups guideline

Brian Schweitzer wrote:
> Honestly, since when did we ever decide to actually change data, the 
> meaning of entity types, or decide to make an objective field into a 
> subjective field simple because it made one view of the data look 
> "cleaner"?  If people want session entities, to group all 
> tracks/releases recorded on a given date together, they ought to 
> support the SessionProposal after NGS, not try to change RG's in a 
> manner which lessens the utility of RGs.
>
> Brian
Firstly, there's nothing subjective about a possible guideline to merge 
different recordings of the same live show.

Secondly, we're not "changing" the meaning of anything. The feature is 
new; we're defining it for the first time. So don't paint it as if 
someone is skewing the original developer intention of the concept - 
that's not the case, and you're weasel wording.

 From my perspective - you're trying to skew it to fit your own obscure 
view of what an RG is which lessons the utility to everyone else with 
respect to their view. Your argument is that what we are losing is a 
concept of an RG that is different than most others define it as, which 
is pointless when those disagreeing with you are arguing that your ideas 
lessen the utility for them.

This whole discussion is pointless IMO until one side accepts that what 
they want an RG to be is not what the majority of people want it to be. 
Sorry to state the obvious, but given the likelihood of anyone backing 
down being very low, as usual, this will go nowhere without an executive 
ruling and the guideline will be left in the confused state it is, just 
like the rest of the guidelines.

Chad / voiceinisdeyou
Brian Schweitzer | 1 Aug 2009 04:38
Picon

Re: RFC: Release Groups guideline

On Fri, Jul 31, 2009 at 10:06 PM, Chad Wilson <chad.wilson <at> gmx.net> wrote:
Brian Schweitzer wrote:
> Honestly, since when did we ever decide to actually change data, the
> meaning of entity types, or decide to make an objective field into a
> subjective field simple because it made one view of the data look
> "cleaner"?  If people want session entities, to group all
> tracks/releases recorded on a given date together, they ought to
> support the SessionProposal after NGS, not try to change RG's in a
> manner which lessens the utility of RGs.
>
> Brian
Firstly, there's nothing subjective about a possible guideline to merge
different recordings of the same live show.

Secondly, we're not "changing" the meaning of anything. The feature is
new; we're defining it for the first time. So don't paint it as if
someone is skewing the original developer intention of the concept -
that's not the case, and you're weasel wording.

"Bring together variant versions of an album into a single listing" was the original intent.  The proposed guideline respected this, even to the point of specifically stating that different recordings of the same show shouldn't have their RGs be merged.  So how am I then skewing anything?  The wording in the guideline is quite clear, and nothing in "variant versions of an album" encompasses "same concert", "same book", etc.
 
  From my perspective - you're trying to skew it to fit your own obscure
view of what an RG is which lessons the utility to everyone else with

Obscure?  My view is exactly what is written in the guideline, now.
 
respect to their view. Your argument is that what we are losing is a
concept of an RG that is different than most others define it as, which

Define it then.  "Same somethingness" is not a consistent definition, and we've never defined any entity type using a different basis depending on the type or status of the entity.

"Artist" - "same (group of) performer(s) using some constant name"
"Label" - "same imprint releasing mediums"
etc.

So, how is "Release Group" - "collection of releases of the same audio" obscure or hard to comprehend?

If anything, "Release Group" - "1) If type is audiobook, then same book.  2) If type is live AND status is bootleg, then same concert.  3) If type is album, then versions of the same album. 4) ..." is the self-satisfying and obscure definition of what a "Release Group" should be.
 
is pointless when those disagreeing with you are arguing that your ideas
lessen the utility for them.

This whole discussion is pointless IMO until one side accepts that what
they want an RG to be is not what the majority of people want it to be.
Sorry to state the obvious, but given the likelihood of anyone backing
down being very low, as usual, this will go nowhere without an executive
ruling and the guideline will be left in the confused state it is, just
like the rest of the guidelines.

Well, I honestly feel that the Release Group concept is broken if we decide it to be something which is subjective, and where the definition differs, depending on the particular type, status (and voters voting on that RG merge edit).  I feel RGs can be quite useful, and I see them as useful already, using the "same audio" defintion, for albums.  As of yet, I've seen no rationale provided for the proposed confusing definition you want to use, except that it makes the artist listing "cleaner".  IMHO, "cleaner listings" vs "clearly defined entity" and "easy and consistent applicability of the entity definition, no matter the release type and status"...  easy choice.

Brian
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Chad Wilson | 1 Aug 2009 05:16
Picon
Gravatar

Re: RFC: Release Groups guideline

Brian Schweitzer wrote:
>
>     Secondly, we're not "changing" the meaning of anything. The feature is
>     new; we're defining it for the first time. So don't paint it as if
>     someone is skewing the original developer intention of the concept -
>     that's not the case, and you're weasel wording.
>
>
> "Bring together variant versions of an album into a single listing" 
> was the original intent.  The proposed guideline respected this, even 
> to the point of specifically stating that different recordings of the 
> same show shouldn't have their RGs be merged.  So how am I then 
> skewing anything?  The wording in the guideline is quite clear, and 
> nothing in "variant versions of an album" encompasses "same concert", 
> "same book", etc.

Shall I remind you that _I_ wrote most of the guideline incorporating 
pronik, gioele and navap's work? The term "variant" isn't even on that 
page, so I don't know what you're talking about. The bootleg clause was 
inserted by navap, IIRC, based on maybe one or two people's comments on 
IRC or a talk page. That clause was never part of some "grand plan for RGs".

>    >From my perspective - you're trying to skew it to fit your own obscure
>
>     view of what an RG is which lessons the utility to everyone else with
>
>
> Obscure?  My view is exactly what is written in the guideline, now.
I'm talking about your argument about why recordings should be separate; 
that somehow they are not what an RG is for. It's foolish to invoke the 
current guideline as some sort of backup. The only reason that clause is 
still there in the guideline is because of your bitching on the talk 
page at the time. I didn't remove it because I wanted to write a 
guideline that had a hope in hell of passing initially; to be augmented 
and tidied up later. So much for that.

>  Define it then.  "Same somethingness" is not a consistent definition, 
> and we've never defined any entity type using a different basis 
> depending on the type or status of the entity.
Look brian, others have told you what it means to them about a thousand 
times. You don't listen. It's fundamentally subjective - it's music!?

As for "we've never defined any entity type"; absolutely untrue. We 
debate often about whether a set of mp3s on an artist's website are NATs 
or a Release. We debate endlessly about whether a remaster should be a 
separate release to the original, or merged. This is no different an 
argument.

 From the other side's perspective, it's /you/ who are trying to treat 
live bootlegs differently. Trying to introduce now that you have to take 
into account the "recording". THAT's obscure to most people.

> Well, I honestly feel that the Release Group concept is broken if we 
> decide it to be something which is subjective, and where the 
> definition differs, depending on the particular type, status (and 
> voters voting on that RG merge edit).  I feel RGs can be quite useful, 
> and I see them as useful already, using the "same audio" defintion, 
> for albums.  As of yet, I've seen no rationale provided for the 
> proposed confusing definition you want to use, except that it makes 
> the artist listing "cleaner".  IMHO, "cleaner listings" vs "clearly 
> defined entity" and "easy and consistent applicability of the entity 
> definition, no matter the release type and status"...  easy choice.
I'm quite happy for you to think it's broken; since you flatly reject 
everyone else's arguments. Saying "no rationale provided" is plainly 
offensive to others who've actually bothered trying to debate with your 
brick wall.

Chad
Brian Schweitzer | 1 Aug 2009 08:19
Picon

Re: RFC: Release Groups guideline

On Fri, Jul 31, 2009 at 11:16 PM, Chad Wilson <chad.wilson <at> gmx.net> wrote:
Brian Schweitzer wrote:
>
>     Secondly, we're not "changing" the meaning of anything. The feature is
>     new; we're defining it for the first time. So don't paint it as if
>     someone is skewing the original developer intention of the concept -
>     that's not the case, and you're weasel wording.
>
>
> "Bring together variant versions of an album into a single listing"
> was the original intent.  The proposed guideline respected this, even
> to the point of specifically stating that different recordings of the
> same show shouldn't have their RGs be merged.  So how am I then
> skewing anything?  The wording in the guideline is quite clear, and
> nothing in "variant versions of an album" encompasses "same concert",
> "same book", etc.

Shall I remind you that _I_ wrote most of the guideline incorporating
pronik, gioele and navap's work? The term "variant" isn't even on that

The term "variations" does, however, and "variant" is a singular form of "variations".

page, so I don't know what you're talking about. The bootleg clause was
inserted by navap, IIRC, based on maybe one or two people's comments on
IRC or a talk page. That clause was never part of some "grand plan for RGs".

And yet, 3 months and several significant revisions to the draft later, it remains part of the draft.
 
>    >From my perspective - you're trying to skew it to fit your own obscure
>
>     view of what an RG is which lessons the utility to everyone else with
>
>
> Obscure?  My view is exactly what is written in the guideline, now.

I'm talking about your argument about why recordings should be separate;
that somehow they are not what an RG is for. It's foolish to invoke the
current guideline as some sort of backup. The only reason that clause is
still there in the guideline is because of your bitching on the talk
page at the time. I didn't remove it because I wanted to write a

Make up your mind.  It was in there from the start, as is shown by the early versions of the guideline.   My first comment on the talk page about ANYTHING was 2 WEEKS later, stating agreement with that part of the guideline as ALREADY WRITTEN.
 
guideline that had a hope in hell of passing initially; to be augmented
and tidied up later. So much for that.

>  Define it then.  "Same somethingness" is not a consistent definition,
> and we've never defined any entity type using a different basis
> depending on the type or status of the entity.
Look brian, others have told you what it means to them about a thousand
times. You don't listen. It's fundamentally subjective - it's music!?

How is the concept of "it comes from the same recording" a subjective grouping?  And I don't actually see any answer in your comment, only rhetoric...
 
As for "we've never defined any entity type"; absolutely untrue. We
debate often about whether a set of mp3s on an artist's website are NATs
or a Release. We debate endlessly about whether a remaster should be a
separate release to the original, or merged. This is no different an
argument.

If you're going to quote me, try to quote me such that you don't only quote half the sentence and create a straw man argument.  "...we've never defined any entity type using a different basis depending on the type or status of the entity" was what I actually said.  NAT vs release and master vs remaster have nothing to do with this, as they have nothing to do with "using a different basis depending on the type or status of the entity".
 
 From the other side's perspective, it's /you/ who are trying to treat
live bootlegs differently. Trying to introduce now that you have to take
into account the "recording". THAT's obscure to most people.

Ignroing that the RG proposed guideline actually ALREADY makes this distinction, and as mentioned, I myself had nothing to do with writing that text, nor did I have anything to do with getting it added into the draft?  How am I, then, introducing that concept, given that it's been a written part of the draft for 3 1/2 months now?

> Well, I honestly feel that the Release Group concept is broken if we
> decide it to be something which is subjective, and where the
> definition differs, depending on the particular type, status (and
> voters voting on that RG merge edit).  I feel RGs can be quite useful,
> and I see them as useful already, using the "same audio" defintion,
> for albums.  As of yet, I've seen no rationale provided for the
> proposed confusing definition you want to use, except that it makes
> the artist listing "cleaner".  IMHO, "cleaner listings" vs "clearly
> defined entity" and "easy and consistent applicability of the entity
> definition, no matter the release type and status"...  easy choice.

I'm quite happy for you to think it's broken; since you flatly reject
everyone else's arguments. Saying "no rationale provided" is plainly
offensive to others who've actually bothered trying to debate with your
brick wall.

The only rationale given has been "it makes a cleaner artist listing".  That's not a reason, that's trying to turn data into poetry.   I've not provided a brick wall.  I am arguing an entirely point of view, one clearly supported by at least a few others, given the few no votes on that edit, and the fact that that line of text in the draft was entirely written by others.  It also is supported by every single bootleg trading site, all of which strongly encourage the provision of source and lineage info, as well as most of the good large bootleg sites (including many of the ones I see you yourself using frequently in edit notes) which include separate listings per recording, not just per show.

However, Chad, to be honest, you're just coming across as offensive at this point.  Between "bitching", "obscure", "weasel wording", and other terms you've used in edit notes and comments to the lists to describe me, it's clear that, while I've been attempting to have a reasonable discussion, you're simply interested in insulting me, my comments, or merely belittling me, without even attempting to work towards some common point.

So consider this my last reply to you, unless you actually are interested in discussing things at a mature level.  While I'm interested in working towards a common point through reasoned debate, I'm not interested in continuing to read personal insults, directed at me, aimed by you.  Perhaps if you actually read my replies, and attempted to try, as I have been, to find some commonalities, you'd have more luck, and we might actually get somewhere with all this.

Brian
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Atedos | 1 Aug 2009 14:10
Picon
Gravatar

Re: RFC: Release Groups guideline

2009/8/1 Brian Schweitzer <brian.brianschweitzer <at> gmail.com>
That's not a reason, that's trying to turn data into poetry.

Offtopic:
Music is not a data, it is poetry, wouldn't you agree?
Or are we all here robotized data collectors? Well, some of us look so.
However, I tend to agree with Chad on almost every point.
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Brian Schweitzer | 1 Aug 2009 04:53
Picon

Re: RFC: Release Groups guideline

Secondly, we're not "changing" the meaning of anything. The feature is
new; we're defining it for the first time. So don't paint it as if
someone is skewing the original developer intention of the concept -
that's not the case, and you're weasel wording.

"Bring together variant versions of an album into a single listing" was the original intent.  The proposed guideline respected this, even to the point of specifically stating that different recordings of the same show shouldn't have their RGs be merged.  So how am I then skewing anything?  The wording in the guideline is quite clear, and nothing in "variant versions of an album" encompasses "same concert", "same book", etc.
 
  From my perspective - you're trying to skew it to fit your own obscure
view of what an RG is which lessons the utility to everyone else with

Obscure?  My view is exactly what is written in the guideline, now.
 
respect to their view. Your argument is that what we are losing is a
concept of an RG that is different than most others define it as, which

Just a followup; digging through the proposed guideline's history brings up some interesting details.  In direct contradiction to your comment, Chad, if you go all the way back to almost the very first version of this guideline, the notion that "Release groups that should not to be merged ... Different bootleg recordings of a live show" is present.  http://wiki.musicbrainz.org/?title=Release_groups_usage_guideline&diff=30074&oldid=30073

Also, I would note, it was *you* yourself, Chad, who copied over that guideline's contents to incorporate that page into the current page, including the language: "When Not to Group Releases together  ... Different bootleg recordings of a live show, e.g. bootleg 1 and bootleg 2 of a 1970 Pink Floyd concert in San Francisco. " http://wiki.musicbrainz.org/?title=Release_Group&diff=30170&oldid=30169

So...  how again am I weasel wording, given that this was present just about from the very beginning of this guideline?  How is my view that different recordings of the same show should not be merged so obscure, given that, right from the very first, that viewpoint was part of the earliest drafts of the guideline?

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

Gmane