Re: [mb-style] CSG: research for Release names & artists: Missa solemnis

2011-05-24 Thread caller#6


On 05/24/2011 02:29 PM, symphonick wrote:
> 2011/5/22, caller#6:
>> 4. Where the liner gives the key in French / English / German, I'd use
>> French as the default, simply because it's a French label.  Could that
>> logic be applied to the Release Group title? That is, should the label's
>> country be a factor in deciding which is the default language?
> I don't understand why you want a "default" title? I was hoping that
> was a pre-NGS issue.
>   I should have been more clear in my multilang. example - the release
> title should be consistent with the entered tracklist. or should I say
> with the chosen release language.
>
> But I suppose it could happen that the tracklist has 4 languages while
> the title only has 2 or the other way around.
>
> /symphonick

Sorry. I can see now that I was using "default" in two different senses.

What I mean was, if  were entering  that release, I'd (personally) 
"default" to the French since it's a French label. But that's not a very 
important decision, since "pseudo" or "transl*tion" releases can always 
be added.

But for the Release Group (as you note on the wiki page) we need to 
choose *one* language (that will be displayed by "default"). Does it 
make sense to use the label country as one of the determining factors?

Alex / caller#6


___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] CSG: research for Release names & artists: Missa solemnis

2011-05-24 Thread symphonick
2011/5/22, caller#6 :
>
>
> On 05/21/2011 03:34 PM, symphonick wrote:
>> First version of my research page for CSG release names&  artists.
>>
>> http://wiki.musicbrainz.org/User:symphonick/Unofficial_CSG_release_names
>>

> 2. It seems to me (and I guess you agree) that listing /all/ the artists
> from the cover would be overkill.
>
Yes. I'd recommend using "primary" artists, but maybe it can be left
to the editor to decide which artists to include as long as they are
listed on the cover.

> 3. Latin capitalization would (I think) be capital "M", lowercase "s".
>
An obvious example of "graphic artist" caps. Saw the other thread, it
woulld be great if we can follow MB-wide style.

> 4. Where the liner gives the key in French / English / German, I'd use
> French as the default, simply because it's a French label.  Could that
> logic be applied to the Release Group title? That is, should the label's
> country be a factor in deciding which is the default language?

I don't understand why you want a "default" title? I was hoping that
was a pre-NGS issue.
 I should have been more clear in my multilang. example - the release
title should be consistent with the entered tracklist. or should I say
with the chosen release language.

But I suppose it could happen that the tracklist has 4 languages while
the title only has 2 or the other way around.

/symphonick

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] RFC: Add CD-r to the format list

2011-05-24 Thread Kuno Woudt
On 24/05/11 19:50, Nicolás Tamargo de Eguren wrote:
> I was surprised when I saw this was not on the list. We have lots of
> those (see http://musicbrainz.org/tag/format-cd-r for a sample) and I
> would say it is distinctive enough to have it as an option under CD
> (or, if not, to have another way of indicating it).

agreed.

I have a couple of purchased CD-r's, both 12cm and 8cm.

-- kuno.

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


[mb-style] RFC: Add CD-r to the format list

2011-05-24 Thread Nicolás Tamargo de Eguren
I was surprised when I saw this was not on the list. We have lots of
those (see http://musicbrainz.org/tag/format-cd-r for a sample) and I
would say it is distinctive enough to have it as an option under CD
(or, if not, to have another way of indicating it).

-- 
Nicolás Tamargo de Eguren

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Kuno Woudt

Hello,

> So how did such a major and complete rewrite skip RFC/RFV, and become
> official within 6 days of being announced (if you count nikki's May 10 email
> as being the RFC, though not mentioned in the email's subject).

I think this misrepresents what nikki and I have done.  

No major changes were made to the guidelines.  In all cases where I wanted
to remove a guideline or change a guideline I have posted an RFC to mb-style.

What we did do is:

1. remove guidelines which no longer apply due to changes in NGS
2. add first versions of new guidelines for new elements of NGS
3. restructure everything so that it is no longer a jumble of
   tiny documents spread out over the wiki, but a set of guidelines
   with at least some structure to them.

This whole process started in january 2010, and I think everyone has had
enough time to participate in it or voice their objections.

If you (or anyone else) think either nikki or I have not acted properly
here I suggest you discuss that with ruaok.


None of the new guidelines we've written are intended to be final.  But we
needed to have a starting point, and now that NGS has been release and 
everyone is using it, we have a better foundation to discuss all of this
properly, and we can RFC/RFV any changes needed.

-- kuno / warp.

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Robert Kaye

On May 24, 2011, at 8:04 AM, Dr Andrew John Hughes wrote:

> I couldn't agree more and I've raised this issue in at least one
> discussion.  I didn't expect NGS to be an excuse to change the
> guidelines by dictate rather than discussion.


I'd like to remind folks that Nikki and Warp are your BDFLs for all  
things style.

That said, I applaud their efforts (and financially supported them as  
well!) for making NGS style guidelines happen. At some point you have  
to put a few people together, get out of the way and let them revamp  
everything. This was one of those times and I support Warp and Nikki  
in their work -- thank you, you two!

This isn't to say that the NGS style guidelines didn't get at least a  
modicum of review by others -- they did. Nor is their work saying that  
we're going to ignore the input from the community -- we aren't. If  
something is broke now, lets use the community process to fix it.

--

--ruaokThe answer to whether or not something is a good idea  
should not be taken as an indication of whether I want to do it.

Robert Kaye -- r...@eorbit.net --http://mayhem-chaos.net




___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Works and remixes/covers

2011-05-24 Thread caller#6


On 05/24/2011 08:02 AM, Dr Andrew John Hughes wrote:
> 2011/5/18 Lukáš Lalinský:
>> The original NGS documentation which was written by me [1] says that
>> works with different remixes should be merged together. The Work page
>> [2] however says that they should be kep separate. All people I've
>> discussed this with agree that they should be merged. Can I change the
>> Work page to remove the mention of remixes?
>>
>> Lukas
>>
>> [1] http://wiki.musicbrainz.org/Next_Generation_Schema#Work
>> [2] http://wiki.musicbrainz.org/Work
>>
> Can we please come to a decision on this?  I now have a number of
> merges being voted down (e.g. http://musicbrainz.org/edit/14496213)
> due to this dumb guideline.  It makes no sense to have remixes as
> separate works, especially when the remix AR is at recording level and
> covers are not separate works but are more different (new vocals, new
> production, etc.).  I really don't see the point in works if we're
> going to allow an artist's work catalogue to be filled with five or
> ten remixes of each song.
For the sake of consistency, I'd rather see the entire list of 
"derivative works"[1] addressed, rather than just re-mixes. But this is 
a good first step.

Putting most re-mix/mashup/medley/ Relationships at the Recording level 
makes sense to me[2]. Or, put another way, some "distinctiveness" 
belongs at the Performance level.

Alex / caller#6


[1] http://wiki.musicbrainz.org/Work#Distinctiveness




___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] NGS guidelines

2011-05-24 Thread Nicolás Tamargo de Eguren
On Tue, May 24, 2011 at 7:13 PM, monxton  wrote:
> On 24/05/2011 16:59, Philipp Wolfer wrote:
>> On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes
>>   wrote:
>>> Sorry, but a process taking time or "being painful" is not a reason to 
>>> impose
>>> the views of a few people on everyone else.
>>
>> I don't think that the intent of the NGS guideline updates was to
>> impose someone's view on everyone else. But the NGS changes are huge,
>> and IMHO it would have been impossible to get the guidelines right in
>> advance. People have to actually work with the new data model.
>>
>> I see the updated NGS guidelines as a starting point. What we now need
>> is the discussion here on the mailing list to improve the guidelines
>> and to work out how to handle all the style issues in NGS.
>
> I'm sure it wasn't the intent, and I agree that it's important for the
> editor population to have some guidelines in place from the start.
>
> It's very important, certainly to me and I think also to others, that it
> is an open project that I am contributing to, and it's not good enough
> to have guidelines written by two "dictators", however benign.
>
> So now that we've reached this point, what will be the formal process by
> which the current provisional guidelines are validated and approved, and
> the arguments considered when developing previous guidelines not forgotten?

Well, this is the basic NGS set, and of course it is open to
modifications. If you don't agree with something and think it should
be done in other way, why am I not seeing any RFC about it? ;) Go
propose stuff!

> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>



-- 
Nicolás Tamargo de Eguren

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread monxton
On 24/05/2011 16:59, Philipp Wolfer wrote:
> On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes
>   wrote:
>> Sorry, but a process taking time or "being painful" is not a reason to impose
>> the views of a few people on everyone else.
>
> I don't think that the intent of the NGS guideline updates was to
> impose someone's view on everyone else. But the NGS changes are huge,
> and IMHO it would have been impossible to get the guidelines right in
> advance. People have to actually work with the new data model.
>
> I see the updated NGS guidelines as a starting point. What we now need
> is the discussion here on the mailing list to improve the guidelines
> and to work out how to handle all the style issues in NGS.

I'm sure it wasn't the intent, and I agree that it's important for the 
editor population to have some guidelines in place from the start.

It's very important, certainly to me and I think also to others, that it 
is an open project that I am contributing to, and it's not good enough 
to have guidelines written by two "dictators", however benign.

So now that we've reached this point, what will be the formal process by 
which the current provisional guidelines are validated and approved, and 
the arguments considered when developing previous guidelines not forgotten?


___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Pete Marsh
>and IMHO it would have been impossible to get the guidelines right in
advance 

I think it would have been possible, but we would still be waiting for
NGS two or three years down the line.

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Philipp Wolfer
On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes
 wrote:
> Sorry, but a process taking time or "being painful" is not a reason to impose
> the views of a few people on everyone else.

I don't think that the intent of the NGS guideline updates was to
impose someone's view on everyone else. But the NGS changes are huge,
and IMHO it would have been impossible to get the guidelines right in
advance. People have to actually work with the new data model.

I see the updated NGS guidelines as a starting point. What we now need
is the discussion here on the mailing list to improve the guidelines
and to work out how to handle all the style issues in NGS.

-- 
Philipp

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Bonus discs?

2011-05-24 Thread azertus
2011/5/24 Nicolás Tamargo de Eguren :
> On Tue, May 24, 2011 at 5:41 PM, Philip Jägenstedt  wrote:
>> http://musicbrainz.org/edit/14491791
>>
>> azertus is asking if we should have a way to record the fact that a
>> disc is considered "bonus". It does seem that this ability was lost in
>> the move to NGS, but I'm not sure I think it's important. Thoughts?
>
> I would say if it is important it can be added in an annotation. I
> mean, before we didn't really show if a disc was considered "bonus",
> it just indicated that a release was available with and without
> another (and we also used it for linking boxsets also published as
> standalone releases and stuff like that). Now we have two different
> releases, with and without the bonus disc, so I wouldn't say it is
> something worth stating in most cases. But maybe someone thinks it is?
>> --
>> Philip Jägenstedt
>
>
>
> --
> Nicolás Tamargo de Eguren

Well, I'd be surprised if no-one would think it worthwile to keep that
info. I agree now that putting something like 'bonus disc' in the
medium title (as I first suggested) is not something we'd want to be
doing. Just when we've got rid of ' (disc x)'...

Perhaps I lament the loss of ' (bonus disc)' because I've been brought
up on the MusicBrainz way of thinking?
Dare I suggest it: a 'bonus check' per medium? In any case we had good
guidelines that determined if ' (bonus disc)' could be added to a
release pre-NGS, so if a bonus check was added, those same guidelines
could police its use...

--
azertus

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Dr Andrew John Hughes
On 24 May 2011 15:38, Philip Jägenstedt  wrote:

snip..

> I'll let nikki and kuno speak for themselves, but just wanted to note
> that I support the complete overhaul and that the normal process has
> been circumvented. Most of the old guidelines don't make sense with
> NGS, and doing such a big change by RFC/RFV would have been extremely
> painful. I think we're much better off taking the rewrite and working
> from there.
>
> Getting people in sync with the changes is another matter, but I
> expect we'll sort it out.
>

Sorry, but a process taking time or "being painful" is not a reason to impose
the views of a few people on everyone else.

> --
> Philip Jägenstedt
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>



-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org

PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Bonus discs?

2011-05-24 Thread Maurits Meulenbelt
Well, we could simply add it to the name of the bonus medium in the release?

"Nicolás Tamargo de Eguren"  ha scritto:

On Tue, May 24, 2011 at 5:41 PM, Philip Jägenstedt  wrote: > 
http://musicbrainz.org/edit/14491791 > > azertus is asking if we should have a 
way to record the fact that a > disc is considered "bonus". It does seem that 
this ability was lost in > the move to NGS, but I'm not sure I think it's 
important. Thoughts? I would say if it is important it can be added in an 
annotation. I mean, before we didn't really show if a disc was considered 
"bonus", it just indicated that a release was available with and without 
another (and we also used it for linking boxsets also published as standalone 
releases and stuff like that). Now we have two different releases, with and 
without the bonus disc, so I wouldn't say it is something worth stating in most 
cases. But maybe someone thinks it is? > -- > Philip Jägenstedt > 
>_
> MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > 
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style > -- Nicolás 
> Tamargo de Eguren_
MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org 
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style 

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Bonus discs?

2011-05-24 Thread Nicolás Tamargo de Eguren
On Tue, May 24, 2011 at 5:41 PM, Philip Jägenstedt  wrote:
> http://musicbrainz.org/edit/14491791
>
> azertus is asking if we should have a way to record the fact that a
> disc is considered "bonus". It does seem that this ability was lost in
> the move to NGS, but I'm not sure I think it's important. Thoughts?

I would say if it is important it can be added in an annotation. I
mean, before we didn't really show if a disc was considered "bonus",
it just indicated that a release was available with and without
another (and we also used it for linking boxsets also published as
standalone releases and stuff like that). Now we have two different
releases, with and without the bonus disc, so I wouldn't say it is
something worth stating in most cases. But maybe someone thinks it is?
> --
> Philip Jägenstedt
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>



-- 
Nicolás Tamargo de Eguren

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Frederic Da Vitoria
2011/5/24 Philip Jägenstedt 

> On Tue, May 24, 2011 at 14:34, Brian Schweitzer
>  wrote:
> > For a few reasons, I've been silent here for the past while.  However, I
> > feel I have to at least comment on the change in guidelines that has
> taken
> > place.  I may not be commenting on the list, but I do still at least skim
> > the style list to see what's happening.  Thus, when I saw an edit note
> > citing something in an entirely rewritten guideline, I was rather
> surprised.
> >
> > Based on nikki's announcement
> > (
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html
>  ),
> > it looked like a rewrite in progress, not a RFC, let alone a RFC that
> > changed every single style guideline.  I looked at the time with the
> > understanding that this was a work in progress, not something just days
> away
> > from being official.  Yet the change to the pages from being available
> for
> > review at User:kuno/Style to those same pages suddenly being the official
> > guidelines took place only 6 days later and with no RFC/RFV/etc, only
> >
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html
>  .
> > So how did such a major and complete rewrite skip RFC/RFV, and become
> > official within 6 days of being announced (if you count nikki's May 10
> email
> > as being the RFC, though not mentioned in the email's subject).
> > I won't email again, but this is important enough that I couldn't not say
> > something.  Every single style guideline has been changed, and there's
> more
> > than a few of the new guidelines which have dropped important items
> and/or
> > changed things counter to how they were decided back during RFCs for the
> > individual guidelines.
> > Brian
>
> I'll let nikki and kuno speak for themselves, but just wanted to note
> that I support the complete overhaul and that the normal process has
> been circumvented. Most of the old guidelines don't make sense with
> NGS, and doing such a big change by RFC/RFV would have been extremely
> painful. I think we're much better off taking the rewrite and working
> from there.
>
> Getting people in sync with the changes is another matter, but I
> expect we'll sort it out.
>

If we had followed the usual process even for only a minimal set of guides,
we would have had to delay NGS for maybe a few months, which would have been
a pity, because installing such a big change without upgrading the guides
would have been madness and probably resulted in lots of bad data. I also
feel that the 2011-05-10 post actually said what was going to happen. I did
not realize it when I read it at that time, but it's there.

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] IMDb relationship

2011-05-24 Thread azertus
I have tried to find some examples to work out what is wrong and what is right.
It seems that only the current release-group-URL IMDb AR is wrong.
See a summary at
http://wiki.musicbrainz.org/User:Azertus/Potential_IMDb_Relationship_Type_Problem
Of course, this might be just a bug?

azertus

On Tue, May 24, 2011 at 12:38 PM, azertus  wrote:
> Hello
>
> I just noticed that the link name for the AR to relate a (soundtrack)
> release group to its movie's URL at IMDb has been somehow merged with
> the AR to indicate a recording uses samples from a movie (by linking
> to its IMDb URL). Was this intentional / discussed at a previous time?
> Because this [1] can not be wanted behaviour?
>
> [1] 
> http://musicbrainz.org/release-group/80fe84a4-b606-3491-a170-f2ca17501493/relationships
>
> --
> azertus
>

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Dr Andrew John Hughes
On 24 May 2011 13:34, Brian Schweitzer  wrote:
> For a few reasons, I've been silent here for the past while.  However, I
> feel I have to at least comment on the change in guidelines that has taken
> place.  I may not be commenting on the list, but I do still at least skim
> the style list to see what's happening.  Thus, when I saw an edit note
> citing something in an entirely rewritten guideline, I was rather surprised.
>
> Based on nikki's announcement
> ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ),
> it looked like a rewrite in progress, not a RFC, let alone a RFC that
> changed every single style guideline.  I looked at the time with the
> understanding that this was a work in progress, not something just days away
> from being official.  Yet the change to the pages from being available for
> review at User:kuno/Style to those same pages suddenly being the official
> guidelines took place only 6 days later and with no RFC/RFV/etc, only
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html .
> So how did such a major and complete rewrite skip RFC/RFV, and become
> official within 6 days of being announced (if you count nikki's May 10 email
> as being the RFC, though not mentioned in the email's subject).
> I won't email again, but this is important enough that I couldn't not say
> something.  Every single style guideline has been changed, and there's more
> than a few of the new guidelines which have dropped important items and/or
> changed things counter to how they were decided back during RFCs for the
> individual guidelines.
> Brian
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

I couldn't agree more and I've raised this issue in at least one
discussion.  I didn't expect NGS to be an excuse to change the
guidelines by dictate rather than discussion.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org

PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Works and remixes/covers

2011-05-24 Thread Dr Andrew John Hughes
2011/5/18 Lukáš Lalinský :
> The original NGS documentation which was written by me [1] says that
> works with different remixes should be merged together. The Work page
> [2] however says that they should be kep separate. All people I've
> discussed this with agree that they should be merged. Can I change the
> Work page to remove the mention of remixes?
>
> Lukas
>
> [1] http://wiki.musicbrainz.org/Next_Generation_Schema#Work
> [2] http://wiki.musicbrainz.org/Work
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

Can we please come to a decision on this?  I now have a number of
merges being voted down (e.g. http://musicbrainz.org/edit/14496213)
due to this dumb guideline.  It makes no sense to have remixes as
separate works, especially when the remix AR is at recording level and
covers are not separate works but are more different (new vocals, new
production, etc.).  I really don't see the point in works if we're
going to allow an artist's work catalogue to be filled with five or
ten remixes of each song.
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org

PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] NGS guidelines

2011-05-24 Thread Pete Marsh
>I support the complete overhaul and that the normal process has been
circumvented. Most of the old guidelines don't make >sense with NGS, and
doing such a big change by RFC/RFV would have been extremely painful. I
think we're much better off >taking the rewrite and working from there.

I couldn't agree more. (I know, I've tried).
 

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.


___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


[mb-style] Bonus discs?

2011-05-24 Thread Philip Jägenstedt
http://musicbrainz.org/edit/14491791

azertus is asking if we should have a way to record the fact that a
disc is considered "bonus". It does seem that this ability was lost in
the move to NGS, but I'm not sure I think it's important. Thoughts?

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] NGS guidelines

2011-05-24 Thread Philip Jägenstedt
On Tue, May 24, 2011 at 14:34, Brian Schweitzer
 wrote:
> For a few reasons, I've been silent here for the past while.  However, I
> feel I have to at least comment on the change in guidelines that has taken
> place.  I may not be commenting on the list, but I do still at least skim
> the style list to see what's happening.  Thus, when I saw an edit note
> citing something in an entirely rewritten guideline, I was rather surprised.
>
> Based on nikki's announcement
> ( http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html ),
> it looked like a rewrite in progress, not a RFC, let alone a RFC that
> changed every single style guideline.  I looked at the time with the
> understanding that this was a work in progress, not something just days away
> from being official.  Yet the change to the pages from being available for
> review at User:kuno/Style to those same pages suddenly being the official
> guidelines took place only 6 days later and with no RFC/RFV/etc, only
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html .
> So how did such a major and complete rewrite skip RFC/RFV, and become
> official within 6 days of being announced (if you count nikki's May 10 email
> as being the RFC, though not mentioned in the email's subject).
> I won't email again, but this is important enough that I couldn't not say
> something.  Every single style guideline has been changed, and there's more
> than a few of the new guidelines which have dropped important items and/or
> changed things counter to how they were decided back during RFCs for the
> individual guidelines.
> Brian

I'll let nikki and kuno speak for themselves, but just wanted to note
that I support the complete overhaul and that the normal process has
been circumvented. Most of the old guidelines don't make sense with
NGS, and doing such a big change by RFC/RFV would have been extremely
painful. I think we're much better off taking the rewrite and working
from there.

Getting people in sync with the changes is another matter, but I
expect we'll sort it out.

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


[mb-style] NGS guidelines

2011-05-24 Thread Brian Schweitzer
For a few reasons, I've been silent here for the past while.  However, I
feel I have to at least comment on the change in guidelines that has taken
place.  I may not be commenting on the list, but I do still at least skim
the style list to see what's happening.  Thus, when I saw an edit note
citing something in an entirely rewritten guideline, I was rather surprised.


Based on nikki's announcement (
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011267.html
),
it looked like a rewrite in progress, not a RFC, let alone a RFC that
changed every single style guideline.  I looked at the time with the
understanding that this was a work in progress, not something just days away
from being official.  Yet the change to the pages from being available for
review at User:kuno/Style to those same pages suddenly being the official
guidelines took place only 6 days later and with no RFC/RFV/etc, only
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-May/011369.html
 .

So how did such a major and complete rewrite skip RFC/RFV, and become
official within 6 days of being announced (if you count nikki's May 10 email
as being the RFC, though not mentioned in the email's subject).

I won't email again, but this is important enough that I couldn't not say
something.  Every single style guideline has been changed, and there's more
than a few of the new guidelines which have dropped important items and/or
changed things counter to how they were decided back during RFCs for the
individual guidelines.

Brian
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] IMDb relationship

2011-05-24 Thread azertus
Hello

I just noticed that the link name for the AR to relate a (soundtrack)
release group to its movie's URL at IMDb has been somehow merged with
the AR to indicate a recording uses samples from a movie (by linking
to its IMDb URL). Was this intentional / discussed at a previous time?
Because this [1] can not be wanted behaviour?

[1] 
http://musicbrainz.org/release-group/80fe84a4-b606-3491-a170-f2ca17501493/relationships

--
azertus

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Capitalization in NGS

2011-05-24 Thread Frederic Da Vitoria
2011/5/24 Dr Andrew John Hughes 

> On 23 May 2011 07:21, Frederic Da Vitoria  wrote:
> > 2011/5/22 Dr Andrew John Hughes 
> >>
> >> I really don't see why we want to retain all covers verbatim; I
> >> thought MusicBrainz was a database, not a cover archive.
> >
> > Maybe because the MB database could store what IS as well as what users
> > would want to be? Or because what you want is not necessarily what other
> > users want. And because NGS is able to store both the standardized and
> the
> > printed titles. So that tracks would capture as much information as
> possible
> > from the physical release (no, no color info :-) ) while the recording
> and
> > the release would contain a standardized title. Also, sticking to the
> cover
> > has the advantage that it minimizes the amount of knowledge needed to
> enter
> > new releases in MB. And if you want to speak technically of databases,
> > wouldn't normalizing track titles make them identical to recording
> titles,
> > which would be data redundancy, one of the bad things database designers
> are
> > advised to avoid as much as possible?
> >
>
> Just because it can doesn't mean it should.  I really don't see a
> great value in keeping lots of data about covers.  I get that
> apparently some 'other users' want this, but I haven't seen a
> convincing argument from them yet.
>

Just as we would probably have difficulties convincing them our way of
seeing things is better :-) This is precisely my point: we can have both, we
can make both categories of users happy, so let's do it. There are two kinds
of democracy: either the biggest group wins and minorities just shut up or
each groups manages to have it's way without stepping on other group's toes.
I prefer the second way, although it is much more difficult to manage.



> Users have always managed to enter releases without following
> guidelines, and more experienced users have just ended up cleaning
> them up, so I don't see how this would suddenly make things easier for
> the novices.
>

If NGS did not enable new things, then what would be the point? Entering
data as printed seems obviously easier than delving in variously official
style guides. Many users (me included) followed SGs because they thought
they were official. Or missed others for lots of good reasons. I believe the
Release level should be kept simple so that even novice users can enter data
without having to transform much apart from capitalizations, obvious
misspellings and so on. Release Group and Recording would be for more
experienced users, and Work level of course for the most experienced. Note
that I am not suggesting that access should be regulated.



> The extra recording layer makes things more complicated, and they are
> still going to enter the titles there in a non-standard way.
>

Sometimes, yes, you can't avoid it entirely, but saying "as printed" has
much more chances of being followed by novice users who are not yet fully
aware of the advantages of standardization than "as the ### Style Guides
say".



> Usually, a database is created to not only store information, but to
> allow it to be used for some purpose.  It makes it very hard to get
> useful information from MusicBrainz if titles are varying based on
> what someone chose to do on the cover.
>

Please don't mix Release titles and Recording titles. I agree we need
standardization. But I am convinced this standardization can and should be
limited to the more "abstract" levels.



> Yes, track titles are superfluous if they are standardised to be the
> same as recording titles.  This is why I would just use the recording
> titles in tracklists and not have separate track titles.
> All I'm seeing so far is a lot of additional work being created by
> these track titles (every title change now needs two edits and the new
> interface isn't very speedy) and no advantages.
>

Aha, now we get to your real issue. Sorry, but I guess NGS is here to stay
:-)



> Do you have an example of where information is lost?
>

No, but I could try to find one, although it would be difficult. I guess in
the case of tracks which were issued lots of times, there could be releases
where track titles mentioned interesting but unique information. I think I
remember a Jazz sampler with very detailed info, but there could be other
examples. Or some release could use a separate spelling which would be
normalized per ConsistentOrigilanData but might still be an expression of
ArtistIntent. Sometimes we will not know if the variations, extra
informations and so on are really relevant, but having the different names
that a Recording or a Work was released under could be quite meaningful.
Once again, I am not speaking of case variations or misspellings.

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.

Re: [mb-style] Merging multi-language releases?

2011-05-24 Thread Kuno Woudt
On 24/05/11 10:37, Philip Jägenstedt wrote:
> On Tue, May 24, 2011 at 09:48, Kuno Woudt  wrote:
>> Hello,
>>
>> On 24/05/11 09:28, Philip Jägenstedt wrote:
>>> Going forward, I think that it would be nice if perhaps recordings
>>> could have aliases by language. Perhaps there should be some attribute
>>> for official translations, if there is such a thing. With such a
>>> scheme, we could get rid of lots of pseudo-releases and wouldn't have
>>> to duplicate release events or any AR:s on those. Or should
>>> translations be on the tracklist level perhaps?
>>
>> Translations at the tracklist level sounds sensible.  I think it's OK
>> to keep a single canonical name at the recording level.
>
> I guess that one downside of tracklist level translations is that you
> don't get translations of the same recordings if they appear on
> multiple releases for free.

That doesn't necessarily seem like a bad thing.  For certain kinds of
releases there are many translations, both official and unofficial.

I don't want those mixed up, so it seems easier to consider the entire 
tracklist as a unit.  Releases with identical tracklists use the same 
tracklist entry in the database, so translating the tracklist on one
release would already make that translation available to other releases 
"for free".

-- kuno.

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Merging multi-language releases?

2011-05-24 Thread Philip Jägenstedt
On Tue, May 24, 2011 at 09:48, Kuno Woudt  wrote:
> Hello,
>
> On 24/05/11 09:28, Philip Jägenstedt wrote:
>> Going forward, I think that it would be nice if perhaps recordings
>> could have aliases by language. Perhaps there should be some attribute
>> for official translations, if there is such a thing. With such a
>> scheme, we could get rid of lots of pseudo-releases and wouldn't have
>> to duplicate release events or any AR:s on those. Or should
>> translations be on the tracklist level perhaps?
>
> Translations at the tracklist level sounds sensible.  I think it's OK
> to keep a single canonical name at the recording level.

I guess that one downside of tracklist level translations is that you
don't get translations of the same recordings if they appear on
multiple releases for free.

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Capitalization in NGS

2011-05-24 Thread Philip Jägenstedt
On Tue, May 24, 2011 at 01:52, Dr Andrew John Hughes
 wrote:
> On 23 May 2011 07:21, Frederic Da Vitoria  wrote:
>> 2011/5/22 Dr Andrew John Hughes 
>>>
>>> I really don't see why we want to retain all covers verbatim; I
>>> thought MusicBrainz was a database, not a cover archive.
>>
>> Maybe because the MB database could store what IS as well as what users
>> would want to be? Or because what you want is not necessarily what other
>> users want. And because NGS is able to store both the standardized and the
>> printed titles. So that tracks would capture as much information as possible
>> from the physical release (no, no color info :-) ) while the recording and
>> the release would contain a standardized title. Also, sticking to the cover
>> has the advantage that it minimizes the amount of knowledge needed to enter
>> new releases in MB. And if you want to speak technically of databases,
>> wouldn't normalizing track titles make them identical to recording titles,
>> which would be data redundancy, one of the bad things database designers are
>> advised to avoid as much as possible?
>>
>
> Just because it can doesn't mean it should.  I really don't see a
> great value in keeping lots of data about covers.  I get that
> apparently some 'other users' want this, but I haven't seen a
> convincing argument from them yet.
> Users have always managed to enter releases without following
> guidelines, and more experienced users have just ended up cleaning
> them up, so I don't see how this would suddenly make things easier for
> the novices.
> The extra recording layer makes things more complicated, and they are
> still going to enter the titles there in a non-standard way.

"Write what's on the cover" is quite obviously easier than "read these
guidelines about capitalization, feat. style, extra title information,
etc." People who care can then standardize the recordings, not the
tracklists.

> Usually, a database is created to not only store information, but to
> allow it to be used for some purpose.  It makes it very hard to get
> useful information from MusicBrainz if titles are varying based on
> what someone chose to do on the cover.

Wait until the next Picard release and then you can (allegedly) chose
if you want normalized titles or not. How does MusicBrainz become less
useful by storing both standardized titles and the as-on-cover titles?

It does become harder to verify that the titles are correct if you
don't have the physical release, but if you worry about that you can
just use the (normalized) recording titles.

> Yes, track titles are superfluous if they are standardised to be the
> same as recording titles.  This is why I would just use the recording
> titles in tracklists and not have separate track titles.
> All I'm seeing so far is a lot of additional work being created by
> these track titles (every title change now needs two edits and the new
> interface isn't very speedy) and no advantages.

If you think that we just shouldn't have the separation between
tracklist titles and recording titles, will you file a bug to remove
the feature from MusicBrainz? If they should really be the same, then
having the separation is actively harmful and a waste of time.

IMO, we should put tracklists to good use by storing as-on-cover
titles in them. While variations in capitalization usually isn't
interesting, there are cases where it is and it is simpler to say
"write what's on the cover" than "write what's on the cover but
normalize capitalization taking artist intent and consistent original
data into consideration".

To give an example where merging track and recording names would be
harmful is the Hong Kong group my little airport:
http://musicbrainz.org/artist/ea6185ea-0138-4b8c-a81a-e8fb90d7c680

This group consistently uses lower case letters in their name and
release/track titles, both on the physical releases and their website.
This is reflected in the official releases already. However, on the
compilation/VA releases from outside Hong Kong that capitalization has
not been followed. Someone who only has the compilation will almost
certainly not want the capitalization to be lowercased just because
that's the way they are on the original releases. Likewise, people who
only have the original release will want that capitalization, not the
bastardized capitalization from a foreign compilation. The only way to
allow this while still merging recordings is of course to have
separate titles in the tracks and recordings. (It's almost as if NGS
was designed specifically to solve this problem...)

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] CSG: research for Release names & artists

2011-05-24 Thread Frederic Da Vitoria
Thanks. I voted for it, although I don't know if the votes are taken into
account.

2011/5/23 Nikki 

> By the way, there's a ticket here
> http://tickets.musicbrainz.org/browse/MBS-684
>
> Nikki
>
> Brant Gibbard wrote:
> > Sorry, I mis-spoke. I was testing with the annotation, and I had
> forgotten
> > about the existence of the comment field for releases (as distinct from
> the
> > annotation). The comment field DOES show up. This will indeed work as a
> > temporary workaround, however, since the label and catalogue number are
> > already present in the records it seems a wasteful duplication to re-add
> the
> > same information to yet another field. It is well worthing using this as
> a
> > work-around for the time being though.
> >
> >
> > Brant Gibbard
> > Toronto, ON
> > http://bgibbard.ca 
> >
> >
> > From: musicbrainz-style-boun...@lists.musicbrainz.org
> > [mailto:musicbrainz-style-boun...@lists.musicbrainz.org] On Behalf Of
> > caller#6
> > Sent: May-23-11 11:54 AM
> > To: musicbrainz-style@lists.musicbrainz.org
> > Subject: Re: [mb-style] CSG: research for Release names & artists
> >
> >
> > On 05/23/2011 04:58 AM, Brant Gibbard wrote:
> >
> >
> > From: musicbrainz-style-boun...@lists.musicbrainz.org
> > [mailto:musicbrainz-style-boun...@lists.musicbrainz.org] On Behalf Of
> > Frederic Da Vitoria
> > Sent: May-23-11 4:47 AM
> > To: MusicBrainz Style Discussion
> > Subject: Re: [mb-style] CSG: research for Release names & artists
> >
> >
> > 2011/5/22 Brant Gibbard 
> >
> >
> > Another issue that would require a UI change to resolve.
> >
> > If you do a an add of a TOC from a disc, the list of potential hits for
> your
> > chosen artist gives only the title and a list of tracks, no other
> > information.
> >
> >
> > Not even the comment? Or the Release Artists?
>


-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging multi-language releases?

2011-05-24 Thread Kuno Woudt
Hello,

On 24/05/11 09:28, Philip Jägenstedt wrote:
> Going forward, I think that it would be nice if perhaps recordings
> could have aliases by language. Perhaps there should be some attribute
> for official translations, if there is such a thing. With such a
> scheme, we could get rid of lots of pseudo-releases and wouldn't have
> to duplicate release events or any AR:s on those. Or should
> translations be on the tracklist level perhaps?

Translations at the tracklist level sounds sensible.  I think it's OK
to keep a single canonical name at the recording level.

-- kuno / warp.


___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Separate works for instrumental version?

2011-05-24 Thread Philip Jägenstedt
On Sun, May 22, 2011 at 20:45, Nikki  wrote:
> Philip Jägenstedt wrote:
>> That sounds pretty good, but it wouldn't really be accurate for
>> karaoke tracks where the background singers are usually left in and
>> only the lead singer is left out. Perhaps a karaoke attribute would
>> work, but I'm not sure if it's going to be possible to draw a line
>> between the two in general.
>
> By the way, we have a recording-recording relationship for linking
> karaoke tracks to the corresponding vocal track, so we do already have a
> way to identify those.

Thanks, I didn't know that! I've started using that now.

> I like the idea of an instrumental attribute for the performance
> relationship for things which aren't karaoke versions. It's one of the
> things I was already thinking would be nice to have.
>
> I don't really know what to do about proper instrumental performances,
> karaoke versions without backing vocals and karaoke versions with
> backing vocals though... It seems difficult to make a distinction
> without confusing people.

Indeed, the distinction between karaoke is not clear at all, in many
cases the distinction would seem to be only what it's *for* rather
than what it *is*, and I'm not sure how those debates could be
resolved.

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


Re: [mb-style] Merging multi-language releases?

2011-05-24 Thread Philip Jägenstedt
On Sun, May 22, 2011 at 22:53, Kuno Woudt  wrote:
> Hello,
>
> On 22/05/11 15:53, Philip Jägenstedt wrote:
>> Before NGS I added some releases where both English and Chinese titles
>> appear on the cover. I created one release for each language.
>> http://musicbrainz.org/release/0a4a71ed-b7d9-44f9-91dd-5cacec86060e
>> and http://musicbrainz.org/release/a78902cf-4ed1-414b-ae34-80076f6142f9
>> is one such pair.
>>
>> With NGS it feels unclear to have multiple releases where there is
>> only one physical release, so I've tried to merge these in
>> http://musicbrainz.org/edit/14491834 and
>> http://musicbrainz.org/edit/14491847
>>
>> Is this an approach that people agree with? The languages are joined
>> in a very peculiar manner here, with _. What should one do when two
>> languages appear on the cover in a more independent fashion, as in
>> http://musicbrainz.org/edit/7588058 (I only added the Chinese variants
>> for this, see cover at
>> http://www.114bt.com/btimg/2007/1/6/682751.jpg)?
>
> In that cover image one of the languages is clearly the main tracklist,
> with the other just supplemental.  IF you were to merge those my
> suggestion would be to use this format:
>
> 1. Primary Language (Secondary Language)
>
> That seems the most common format used elsewhere.
>
>> It seems sane tagging will be made harder by merging these, because
>> almost no one will want both languages, I'm guessing. Should we
>> perhaps just use pseudo-releases for tracklists on a usable form and
>> leave the official releases in their original true-to-the-cover form?
>
> I wouldn't strongly object to combining both languages in a single
> release, but I would prefer not to start doing that just yet.
>
> I think we should just keep doing what we've been doing before NGS,
> so two releases in our database - link them with translation
> relationships and mark both official.  And formulate how we think
> translations _should_ work, then I can start coding that feature
> and we can have this sorted properly soonish :D

Since I wasn't very happy with the result, I reverted the change in
http://musicbrainz.org/edit/14503147

Going forward, I think that it would be nice if perhaps recordings
could have aliases by language. Perhaps there should be some attribute
for official translations, if there is such a thing. With such a
scheme, we could get rid of lots of pseudo-releases and wouldn't have
to duplicate release events or any AR:s on those. Or should
translations be on the tracklist level perhaps?

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style