Re: [mb-style] NGS and Duos

[Alex Mauer]

On 6/9/2011 10:57 PM, monxton wrote:
> Now I know nothing about metal, but I don't see why you say a short term
> collaboration between Motorhead and Girlschool would not be a good
> example of a collaboration.

I wouldn't; it absolutely *is* a collaboration.  I'm not talking about 
collaboration relationships here, and maybe that's the root of our 
disagreement.  I'm talking about situations where it is appropriate to 
use artist credits instead of creating separate artists, and Headgirl is 
not such a situation.

>> * The group is known by a different name when performing together.  (how
>> different? is “First&   First” sufficiently different?  How about “First
>> &   First Last”?  What about nicknames?)
>> * The necessity of an AR to the group.
>> * Some kind of notability requirement? (Wikipedia?  Official home page
>> under the group name? both are really AR requirements, but maybe some
>> other notability requirement like google search suggestions??)
>
> Yes, those three are all useful criteria, but you have omitted the
> criterion which is actually cited in the definition at the top of your
> post, that is, durability. This is the very essence of the distinction,
> you can't just ignore it.

It's a criterion for collaborations, but as we see with Headgirl, not 
all collaborations are given multi-artist credits, and it seems to me 
that the converse is also true: not all multi-artist credits must be 
collaborations.

> I agree this is a possible measure of notability - my reservation is
> that many "folk" bands get very little attention in MBz compared to
> rock/pop, specially former bands which were defunct before the CD was
> introduced, and because nobody has given their ARs a going over doesn't
> mean they are not notable. Yours is very much a Wikipedian argument.

I think it's a very straightforward, clear way to decide: If there is a 
need for a standalone artist, make it a standalone artist.  If there's 
not and it's possible, use artist credits.

That sounds a lot less subjective than your example of:
> if the group's recordings
> comprise only a few tracks on a compilation, they are definitely a
> collaboration. If they have released at least two studio albums over
> time then they are/were definitely a band. Between lies a grey area...

That is just as much a notability requirement as mine, and a lot harder 
to decide, especially without being intimately familiar with the group 
in question.

If you're curious, I added "number of albums" to the spreadsheet: Only 
three or four artists have fewer than two albums: meatgirl (0 albums!); 
beck, bogert and appice (1 album); Ashley Hutchings et al. (maybe); and 
Norma and Lal Waterson (1 album).

> Well, Waterson:Carthy has always had four members AFAIK, the fourth
> having equal billing but not named either Waterson or Carthy.

Wikipedia says it was initially Norma Waterson and Martin and Eliza 
Carthy.  It's academic to our discussion though.

> Of the others outside your green area Martin Carthy and Bert Jansch is
> clearly a collaboration, and was probably just entered wrong in the
> first place.

I believe it was missing collaboration relations.  Doesn't matter, 
that's a migration problem and not relevant to its current status of 
"auto-edited out of the database".

> Similarly Ashley Hutchings-and-all-those-other-names
> probably just blew the mind of the migration tool,

Nah, it was just in MB as "Ashley Hutchings & Friends" and with one 
collaboration relations, so the converter didn't do anything with it.

> but that is also just
> a collaboration.

Really?  There are five albums (Morris On, Son of Morris On, Grandson of 
Morris On, Great Grandson of Morris On, and Morris On the Road), 
spanning 30 years, though the lineup varies somewhat and the latter 
three are credited as "various artists".  That's firmly on your 
"definitely a band" side.

My purpose, though, isn't to go through a list and decide whether or not 
each group on the list is or is not a collaboration.

It's not to decide whether a given artist is worthy of being considered 
a band or is somehow not a "real" band.

It's not to destroy all recognition of folk bands, or of bands whose 
names happen to be lists of their members, or of bands that stopped 
existing before 1982.

My purpose is to find a good, preferably objective, set of guidelines 
for whether a group (collaboration or not) should be entered as a 
standalone musicbrainz-artist, or as a set of artist credits.  And to 
measure those guidelines to see how well they work.


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

Re: [mb-style] NGS and Duos

[monxton]

On 10/06/2011 05:08, Nikki wrote:
> monxton wrote:
>> You'll have noted Nikki's response where he says that the distinction
>> between collaboration and member-of-band has not changed with NGS.
>> Short-term or one-off projects are collaborations.
>
> I'm not the same person as Nicolás. ;)

Excuse me, sorry.


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

Re: [mb-style] VolumeNumberStyle in NGS?

[jacobbrett]

Lukáš Lalinský wrote:
> 
> 2011/6/7 Nicolás Tamargo de Eguren :
>> On Tue, Jun 7, 2011 at 3:09 PM, Frederic Da Vitoria
>>  wrote:
>>> 2011/6/7, Lukáš Lalinský :
 I think that the guidelines regarding release/track titles should be
 based on the previous guidelines, white-listing things that don't have
 to be applied to recording/track titles. If we want to allow people to
 submit releases "as on cover" without reading the release
 group/recording guidelines, we will end up with a FreeDB clone.
>>>
>>> I really don't think so. IMO the problem with FreeDB is redundancy and
>>> mistakes, so that it is very difficult to decide which is the correct
>>> information when offered more than one answer and when you get only
>>> one release, you're not even sure it is error-free. What we are
>>> suggesting has nothing to do with these issues. Allowing to enter
>>> titles as printed would not create redundancy (in a way, it would be
>>> the contrary), and requiring to enter it as printed does not make it
>>> harder to check or correct.
>>
>> "What is actually printed is a piece of information which has it's
>> value. I already said this before: if I had to choose between as
>> printed and normalized, I wouldn't hesitate and choose normalization.
>> But we can have both, and I know some (many?) users want the printed
>> data."
>>
>> My thoughts exactly.
> 
> My only concern is that we are losing some kind of information that I
> happened to like. In the old MB, we used to have normalized titles
> that were still release-specific. With the approach, we either have
> "as on cover" titles, which are useless to me, or we have globally
> normalized titles that don't directly correspond to the release that I
> have. Maybe this is only a minority of the data, but it makes
> MusicBrainz less useful to me. I think that abbreviations fall into
> the category of things that we should make consistent.
> 
> Lukas
> 
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> 
Agreed, though in regards to abbreviations, Artist Intent/Foreign (Japanese)
volume names with odd capitalisation should override style.

I take issue with having track titles/release titles as strictly "what's on
the cover".

Track/Recording Titles:
I see no use in recording typos or poor capitalisation (and if either are
important for identifying a particular release, it can be put in the release
annotation).

Recording Titles can additionally differ from Track Titles in the form of
normalisation/consistency (between Recording Titles); "with X Artist" can be
normalised to "feat. X artist" and principles like Consistent Original Data
may be applied (so that extra title information, such as "album version" can
be appended or removed, for example).

Release/Release Group Titles:
As pointed out above by Lukas, in some cases Release Groups may contain
Releases which have completely different titles to one-another. This can
occur with a differently titled re-release, or even promotional sampler
Releases. Release Titles should be treated in a similar fashion to Track
Titles; Release Group Titles being the most common/appropriate name for a
group of Releases.

--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/VolumeNumberStyle-in-NGS-tp3573712p3588251.html
Sent from the Musicbrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] NGS and Duos

[Nicolás Tamargo de Eguren]

On Fri, Jun 10, 2011 at 12:53 PM, monxton
 wrote:
> On 10/06/2011 05:08, Nikki wrote:
>> monxton wrote:
>>> You'll have noted Nikki's response where he says that the distinction
>>> between collaboration and member-of-band has not changed with NGS.
>>> Short-term or one-off projects are collaborations.
>>
>> I'm not the same person as Nicolás. ;)
>
> Excuse me, sorry.
>
We are both awesome, so the mistake is understandable though ;)

I see having a dedicated page for established bands as a benefit
bigger than having releases appear in both artists' lists. Of course,
that might be just me, and of course, that's kinda arbitrary.
> ___
> 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] RFC: Concept of works group

[Lemire, Sebastien]

One possible issue with the workgroup concept is that happens when the
work doesn't have any subgroups?
The workgroup will need to behave and have the exact same attributes
and relationships for this work. Or do we create a single subgroup
within the workgroup. It's getting complicated

To be honest, I wasn't too hot of the idea of simply linking work
parts together at first, but I've come around to think it's probably
the best scenario because:
- if the mast work and subgroup are the same type of data, they can be
linked directly (and independently) from the recordings.
- We could theoretically have multiple layers of subgroups (as
mentioned prior for opera)

This as long as:
- The sub-work inherits details from the master work,(Composer name,
work type, date information), but changes to the subgroups will need
to overwrite the master group (Sometimes parts will have different
composition dates, etc...) But if we're confident the information in
the master group is accurate, we should have the option to overwrite
the subgroups. Would inheriting through ARs between works involve
important rewrites to the code and structure of MB? Does the system
already allow for this possibility?

- We can at some point remove the master work name from the subgroup
ie: Master group: Chopiniana, Op. 46: and subgroup: II. Nocturne
(we'll need some a different more flexible method to display the data)

Anyway my thoughts, sorry for rehashing what I and others have already
said here and in other places, putting my thoughts together on this :)

Sebastien

On Thu, Jun 9, 2011 at 8:41 AM, caramel  wrote:
>
>
>>
>> Not only it is not easy, I believe it also is not desirable. The semantic
>> difference between a work and a work part / sub-work is tiny. The history of
>> some movements shows that some composers conceive the movements
>> independently and later assemble them into a main work. And also, in the
>> other direction, some works are themselves parts of bigger works. I am
>> convinced that no stable, strict ontology is possible and that putting
>> everything in the same table, but marking in some way to which"level" each
>> work belongs is the best way to manage this, because it is the most painless
>> way to have everything we want (putting main works into the Works table
>> wouldn't necessarily generate any loss in functionality) and at the same
>> time it offers flexibility.
>>
> I agree that there is an underlying discussion about what we can consider as
> a work or a part of work... It is why I present the workgroup  as a
> "container" for subworks of a composition as well as works of a collection.
> But at the final, the important thing is that all the individual works are
> relied together.
> Back to the paradigm:
> As a MB editor, I would like to edit easily and fast the works to populate
> the database with the right information... but without doing the same tens
> of time (for each subworks).
> As a scientific OO coder in the "real life", I like to get order the
> information and to get it only once. I hate maintaining..
> The concept of composition/collection exists.
>
> Today it is not easy to implement and main work could be entered and new
> "has part" ARs set to link the main work to the sub works. But there are
> still missing the possible ordering of subworks and the inheritance of the
> ARs.
>
> ___
> 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] RFV-321: Work parts relationship

[Lemire, Sebastien]

One thing about this, I think it would be important to also be able to
assign an order to the parts so that the movements/parts are
displayed/listed in the correct order. While Symphony movements should
be easy to sort as they should all have I. II. III., etc, some other
work types (particularly Opera) wouldn't be sorted properly.

This should probably be done as an attribute at the time of link the two works.

Sebastien

On Wed, Jun 8, 2011 at 2:20 PM, Simon Reinhardt
 wrote:
> Alex Mauer wrote:
>> The RFC period has ended for this proposal[1], with no major objections.
>> I have updated the proposal with some more guidelines for its use based
>> on the list response, and so bring this to RFV status.
>>
>> 1. http://wiki.musicbrainz.org/Proposal:Work_Parts_Relationship
>
> +1
>
> ___
> 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] feat. style and track/recording artist

[jacobbrett]

Kuno Woudt wrote:
> 
> Hello,
> 
> On 05/06/11 21:06, Philip Jägenstedt wrote:
>> 2011/6/5 Nicolás Tamargo de Eguren:
>> 
>> The problem is in interpreting the cover. What is the distinction
>> between an artist being mentioned in a comment on the sleeve and being
>> credited as an artist. Consider these (fictional) examples:
>> 
>>   * "Song A (feat. Artist Y)"
>>   * "Song A (Artist X + Artist Y)"
>>   * "Song A (rap by Artist X)"
>>   * "Song A (Artist X on keyboard)"
>>   * "Song A (Artist X合唱)"
>> 
>> How is one supposed to create a combined artist credit in the last 3
>> cases? There needn't be much difference between the nature of the
>> collaborations in these examples, just a difference in how it's
>> presented on the cover.
> 
> The 'rap by' and 'on keyboard' examples are basically relationships.  
> 
> The track title retains how they are credited on the cover, for 
> recording I think those should not appear on either the recording 
> title or the artist credit, they should just be relationships.
> 
> Alternatively, add the relationships but still credit those artists
> in the artist credits, example:
> 
> on cover:  "Song A (Artist X on keyboard) - Artist Y"
> 
> recording title:  Song A
> artist credit:Artist Y, Artist X
> relationship: Artist X performs keyboard on Song A
> 
> Again, I see no need to retain the 'rap by' or 'on keyboard' in
> either recording title or artist credit when we have a good
> relationships for that information.
> 
> The other examples seem quite suitable for artist credits already.
> 
> -- kuno / warp.
> 
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> 
I would consider "Song A (Artist X on keyboard)" to simply be a more
specific form of "Song A (feat. Artist X)". Generally, I think in both cases
such a phrase would be intentionally displayed on the tracklist by the
artist/label.

Thus, for tracks, either could be applicable, whereas, for recordings, all
variances may be normalised to "feat. Artist X".

--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/feat-style-and-track-recording-artist-tp3574695p3588517.html
Sent from the Musicbrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] RFV-321: Work parts relationship

[Nicolás Tamargo de Eguren]

On Fri, Jun 10, 2011 at 4:58 PM, Lemire, Sebastien  wrote:
> One thing about this, I think it would be important to also be able to
> assign an order to the parts so that the movements/parts are
> displayed/listed in the correct order. While Symphony movements should
> be easy to sort as they should all have I. II. III., etc, some other
> work types (particularly Opera) wouldn't be sorted properly.
>
> This should probably be done as an attribute at the time of link the two 
> works.

For this we would need an attribute that went from 0 to n, because we
don't know what the limit is going to be. I can see how ordering is
useful but I think we should talk with the devs and look for a better
way.
> Sebastien
>
> On Wed, Jun 8, 2011 at 2:20 PM, Simon Reinhardt
>  wrote:
>> Alex Mauer wrote:
>>> The RFC period has ended for this proposal[1], with no major objections.
>>> I have updated the proposal with some more guidelines for its use based
>>> on the list response, and so bring this to RFV status.
>>>
>>> 1. http://wiki.musicbrainz.org/Proposal:Work_Parts_Relationship
>>
>> +1
>>
>> ___
>> 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
>



-- 
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] RFC-324 v2: Official Website and Discography Entry ARs for Releases/Release Groups

[jacobbrett]

Calvin Walton-2 wrote:
> 
> Now with infinitely more wiki page templates, and its very own RFC
> number!
> 
> This proposal is to add or change two ARs:
> 
>   * Official Homepage
> http://wiki.musicbrainz.org/User:Kepstin/Official_Homepage_Relationship_Type_Proposal
> 
> A new Release Group → URL relation will be added to the Official
> Homepage relationship type, to allow linking releases groups to
> an official website published by the artist or label.
> 
>   * Discography Entry
> http://wiki.musicbrainz.org/User:Kepstin/Discography_Entry_Relationship_Type
> 
> A new Release → URL relationship type, to allow linking
> individual versions of releases to sub-pages of discography
> sites.
> 
> I'm still not entirely sure what to do with the wording on the Official
> Homepage relation: should I use a different wording for release groups
> than the other types? Or should I change them all to be consistent?
> 
> Discuss!
> 
> -- 
> Calvin Walton 
> 
> 
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> 
Perhaps "has an official homepage at" (and vice versa) should be used
instead, as:

Firstly, IMO "website" isn't consistent terminology with "homepage"; it
should be "webpage".

Though, then my concern is that "official webpage" may be confused with any
release listing on an artist's website.

Thus, "official homepage" is probably more apt than "official website". 

Is that too pedantic? :P

--
View this message in context: 
http://musicbrainz.1054305.n4.nabble.com/RFC-324-v2-Official-Website-and-Discography-Entry-ARs-for-Releases-Release-Groups-tp3585730p3588549.html
Sent from the Musicbrainz - Style mailing list archive at Nabble.com.

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

Re: [mb-style] RFC-324 v2: Official Website and Discography Entry ARs for Releases/Release Groups

[Yin Izanami]

What happens if a label changes the URL structure of their website?  I'm
concerned this will eventually lead to a countless number of dead links, if
said changes aren't fixable by a simple script.

On Fri, Jun 10, 2011 at 10:21 AM, jacobbrett  wrote:

>
> Calvin Walton-2 wrote:
> >
> > Now with infinitely more wiki page templates, and its very own RFC
> > number!
> >
> > This proposal is to add or change two ARs:
> >
> >   * Official Homepage
> >
> http://wiki.musicbrainz.org/User:Kepstin/Official_Homepage_Relationship_Type_Proposal
> >
> > A new Release Group → URL relation will be added to the Official
> > Homepage relationship type, to allow linking releases groups to
> > an official website published by the artist or label.
> >
> >   * Discography Entry
> >
> http://wiki.musicbrainz.org/User:Kepstin/Discography_Entry_Relationship_Type
> >
> > A new Release → URL relationship type, to allow linking
> > individual versions of releases to sub-pages of discography
> > sites.
> >
> > I'm still not entirely sure what to do with the wording on the Official
> > Homepage relation: should I use a different wording for release groups
> > than the other types? Or should I change them all to be consistent?
> >
> > Discuss!
> >
> > --
> > Calvin Walton 
> >
> >
> > ___
> > MusicBrainz-style mailing list
> > MusicBrainz-style@lists.musicbrainz.org
> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> >
> Perhaps "has an official homepage at" (and vice versa) should be used
> instead, as:
>
> Firstly, IMO "website" isn't consistent terminology with "homepage"; it
> should be "webpage".
>
> Though, then my concern is that "official webpage" may be confused with any
> release listing on an artist's website.
>
> Thus, "official homepage" is probably more apt than "official website".
>
> Is that too pedantic? :P
>
> --
> View this message in context:
> http://musicbrainz.1054305.n4.nabble.com/RFC-324-v2-Official-Website-and-Discography-Entry-ARs-for-Releases-Release-Groups-tp3585730p3588549.html
> Sent from the Musicbrainz - Style mailing list archive at Nabble.com.
>
> ___
> 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] RFC-324 v2: Official Website and Discography Entry ARs for Releases/Release Groups

[Nicolás Tamargo de Eguren]

On Fri, Jun 10, 2011 at 5:29 PM, Yin Izanami  wrote:
> What happens if a label changes the URL structure of their website?  I'm
> concerned this will eventually lead to a countless number of dead links, if
> said changes aren't fixable by a simple script.

The changes should at least be *detectable* with a script, even if
they have to be fixed by hand (that's what we do now when Wikipedia
deletes / merges pages, for example)

> On Fri, Jun 10, 2011 at 10:21 AM, jacobbrett  wrote:
>>
>> Calvin Walton-2 wrote:
>> >
>> > Now with infinitely more wiki page templates, and its very own RFC
>> > number!
>> >
>> > This proposal is to add or change two ARs:
>> >
>> >       * Official Homepage
>> >
>> > http://wiki.musicbrainz.org/User:Kepstin/Official_Homepage_Relationship_Type_Proposal
>> >
>> >         A new Release Group → URL relation will be added to the Official
>> >         Homepage relationship type, to allow linking releases groups to
>> >         an official website published by the artist or label.
>> >
>> >       * Discography Entry
>> >
>> > http://wiki.musicbrainz.org/User:Kepstin/Discography_Entry_Relationship_Type
>> >
>> >         A new Release → URL relationship type, to allow linking
>> >         individual versions of releases to sub-pages of discography
>> >         sites.
>> >
>> > I'm still not entirely sure what to do with the wording on the Official
>> > Homepage relation: should I use a different wording for release groups
>> > than the other types? Or should I change them all to be consistent?
>> >
>> > Discuss!
>> >
>> > --
>> > Calvin Walton 
>> >
>> >
>> > ___
>> > MusicBrainz-style mailing list
>> > MusicBrainz-style@lists.musicbrainz.org
>> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>> >
>> Perhaps "has an official homepage at" (and vice versa) should be used
>> instead, as:
>>
>> Firstly, IMO "website" isn't consistent terminology with "homepage"; it
>> should be "webpage".
>>
>> Though, then my concern is that "official webpage" may be confused with
>> any
>> release listing on an artist's website.
>>
>> Thus, "official homepage" is probably more apt than "official website".
>>
>> Is that too pedantic? :P
>>
>> --
>> View this message in context:
>> http://musicbrainz.1054305.n4.nabble.com/RFC-324-v2-Official-Website-and-Discography-Entry-ARs-for-Releases-Release-Groups-tp3585730p3588549.html
>> Sent from the Musicbrainz - Style mailing list archive at Nabble.com.
>>
>> ___
>> 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
>



-- 
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] RFC: Concept of works group

[caramel]

2011/6/10 Lemire, Sebastien 

> One possible issue with the workgroup concept is that happens when the
> work doesn't have any subgroups?
> The workgroup will need to behave and have the exact same attributes
> and relationships for this work. Or do we create a single subgroup
> within the workgroup. It's getting complicated
>
> To be honest, I wasn't too hot of the idea of simply linking work
> parts together at first, but I've come around to think it's probably
> the best scenario because:
> - if the mast work and subgroup are the same type of data, they can be
> linked directly (and independently) from the recordings.
> - We could theoretically have multiple layers of subgroups (as
> mentioned prior for opera)
>
*The concept of a master work linked to subworks is just a possible
implementation of the concept of workgroup. There are no difference if the
hierarchy is included too. To get multiple layers suppose to enter the
concept of work tree in MB... so to group work leafs on a same branch (and
so on for opera !).
*

>
> This as long as:
> - The sub-work inherits details from the master work,(Composer name,
> work type, date information), but changes to the subgroups will need
> to overwrite the master group (Sometimes parts will have different
> composition dates, etc...) But if we're confident the information in
> the master group is accurate, we should have the option to overwrite
> the subgroups. Would inheriting through ARs between works involve
> important rewrites to the code and structure of MB? Does the system
> already allow for this possibility?
>
*About the ARs inheritance, the proposal was to inherit ARs from a parent
work if the corresponding AR field is left blank at subwork level. That
permits to change a composition date of a subpart if necessary. A script
should permit to clear the subworks ARs.*

>
> - We can at some point remove the master work name from the subgroup
> ie: Master group: Chopiniana, Op. 46: and subgroup: II. Nocturne
> (we'll need some a different more flexible method to display the data)
>
*The removal of master work name (Part, act, scene,...) should be possible
if the notion of work tree is introduced. *

>
> Anyway my thoughts, sorry for rehashing what I and others have already
> said here and in other places, putting my thoughts together on this :)
>
> Sebastien
>
> On Thu, Jun 9, 2011 at 8:41 AM, caramel  wrote:
> >
> >
> >>
> >> Not only it is not easy, I believe it also is not desirable. The
> semantic
> >> difference between a work and a work part / sub-work is tiny. The
> history of
> >> some movements shows that some composers conceive the movements
> >> independently and later assemble them into a main work. And also, in the
> >> other direction, some works are themselves parts of bigger works. I am
> >> convinced that no stable, strict ontology is possible and that putting
> >> everything in the same table, but marking in some way to which"level"
> each
> >> work belongs is the best way to manage this, because it is the most
> painless
> >> way to have everything we want (putting main works into the Works table
> >> wouldn't necessarily generate any loss in functionality) and at the same
> >> time it offers flexibility.
> >>
> > I agree that there is an underlying discussion about what we can consider
> as
> > a work or a part of work... It is why I present the workgroup  as a
> > "container" for subworks of a composition as well as works of a
> collection.
> > But at the final, the important thing is that all the individual works
> are
> > relied together.
> > Back to the paradigm:
> > As a MB editor, I would like to edit easily and fast the works to
> populate
> > the database with the right information... but without doing the same
> tens
> > of time (for each subworks).
> > As a scientific OO coder in the "real life", I like to get order the
> > information and to get it only once. I hate maintaining..
> > The concept of composition/collection exists.
> >
> > Today it is not easy to implement and main work could be entered and new
> > "has part" ARs set to link the main work to the sub works. But there are
> > still missing the possible ordering of subworks and the inheritance of
> the
> > ARs.
> >
> > ___
> > 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
>
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[mb-style] [CSG] joined movements in works

[lorenz pressler]

often short movements/scenes are joined together to one track on releases.
should we link them to the two or more apropriate works?

eg.:
Concerto for Piano, Violin, Cello, and Orchestra in C major, Op. 56  
"Triple Concerto": II. Largo / III. Rondo alla Polacca [1]
has its own work now and i would like to link it to the 2 seperate works  
and delete the joined one.


[1] http://musicbrainz.org/work/22dd7c60-dee2-3936-a097-abb955898793

-- 
lorenz pressler
PGP 0x92E9551A

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

Re: [mb-style] RFV-321: Work parts relationship

[Frederic Da Vitoria]

2011/6/10, Nicolás Tamargo de Eguren :
> On Fri, Jun 10, 2011 at 4:58 PM, Lemire, Sebastien  wrote:
>> One thing about this, I think it would be important to also be able to
>> assign an order to the parts so that the movements/parts are
>> displayed/listed in the correct order. While Symphony movements should
>> be easy to sort as they should all have I. II. III., etc, some other
>> work types (particularly Opera) wouldn't be sorted properly.
>>
>> This should probably be done as an attribute at the time of link the two
>> works.
>
> For this we would need an attribute that went from 0 to n, because we
> don't know what the limit is going to be. I can see how ordering is
> useful but I think we should talk with the devs and look for a better
> way.

This was already discussed a few months ago, I remember that someone
noted that numbering could be dificult to handle because of
overlapping splits, which happens for example in operas. I don't read
music, so I never saw an opera score, but I believe that there are not
always clear separations in the score. Maybe we should use the bar
number in those cases? Anyhow, if we handle numbers (I think of course
that we should), we must be very careful about how we number the
sub-parts because it will not always be as easy as with movements.

-- 
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] [CSG] joined movements in works

[Nicolás Tamargo de Eguren]

On Fri, Jun 10, 2011 at 6:14 PM, lorenz pressler  wrote:
>
> often short movements/scenes are joined together to one track on releases.
> should we link them to the two or more apropriate works?
>
> eg.:
> Concerto for Piano, Violin, Cello, and Orchestra in C major, Op. 56
> "Triple Concerto": II. Largo / III. Rondo alla Polacca [1]
> has its own work now and i would like to link it to the 2 seperate works
> and delete the joined one.

Please do that. It should be linked to both II and III.

> [1] http://musicbrainz.org/work/22dd7c60-dee2-3936-a097-abb955898793
>
> --
> lorenz pressler
> PGP 0x92E9551A
>
> ___
> 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] [CSG] joined movements in works

[caramel]

2011/6/10 Nicolás Tamargo de Eguren 

> On Fri, Jun 10, 2011 at 6:14 PM, lorenz pressler  wrote:
> >
> > often short movements/scenes are joined together to one track on
> releases.
> > should we link them to the two or more apropriate works?
> >
> > eg.:
> > Concerto for Piano, Violin, Cello, and Orchestra in C major, Op. 56
> > "Triple Concerto": II. Largo / III. Rondo alla Polacca [1]
> > has its own work now and i would like to link it to the 2 seperate works
> > and delete the joined one.
>
> Please do that. It should be linked to both II and III.
>
*I agree too since the join works is just resulting from the recording and
has no meaning. *


> > [1] http://musicbrainz.org/work/22dd7c60-dee2-3936-a097-abb955898793
> >
> > --
> > lorenz pressler
> > PGP 0x92E9551A
> >
> > ___
> > 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] RFV-321: Work parts relationship

[symphonick]

On Fri, 10 Jun 2011 17:16:38 +0200, Frederic Da Vitoria  
 wrote:

> This was already discussed a few months ago, I remember that someone
> noted that numbering could be dificult to handle because of
> overlapping splits, which happens for example in operas. I don't read
> music, so I never saw an opera score, but I believe that there are not
> always clear separations in the score.

& that's not only for opera. (this is another reason why it's a bad idea  
to add movement numbers if the composer didn't write any)

I don't know if a next/previous movement AR like the part of set-AR would  
work. What to do with alternative versions, revisions and such?

/symphonick

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

Re: [mb-style] RFV-321: Work parts relationship

[Lemire, Sebastien]

I agree it will be difficult, another possible headache is that there
are various variations of the same movement that of course need to
have the same number and be part of the same work. In regards to
Opera, I always hated the way they were separated and named on albums,
so when I was tagging my Opera music, I would actually merge all the
tracks by Act, Scene  or some other more logical convention.

Tracks (and even discs) are so artificial when it comes to classical
music. For example Mahler's Symphony #2 is usually split on 2 CDs
because of length.

I don't have or edit Opera, but aren't tracks separated and named
almost arbitrarily? Sometimes certain parts are merged, sometimes not.
It would almost be best to not have the Opera parts as separate and
distinct works in the MB database and simply have them in the track
listings. Perhaps large parts of Opera could be in, such as Act I, Act
II, Act III, etc... Can anyone think why we'd want the individual Aria
or Recitavo as a distinct work? The Overtures should definitely be as
they are often recorded independently of the Opera

There are, however, albums of famous Arias, where they are
recorded/sang/released independently of the Opera or Act. Perhaps they
could be treated as partial performances of the larger work be tagged
as such at the recording level (how partial classical performances
should also be tagged, they definitely should not be a unique work)

Sebastien

On Fri, Jun 10, 2011 at 11:16 AM, Frederic Da Vitoria
 wrote:
> 2011/6/10, Nicolás Tamargo de Eguren :
>> On Fri, Jun 10, 2011 at 4:58 PM, Lemire, Sebastien  wrote:
>>> One thing about this, I think it would be important to also be able to
>>> assign an order to the parts so that the movements/parts are
>>> displayed/listed in the correct order. While Symphony movements should
>>> be easy to sort as they should all have I. II. III., etc, some other
>>> work types (particularly Opera) wouldn't be sorted properly.
>>>
>>> This should probably be done as an attribute at the time of link the two
>>> works.
>>
>> For this we would need an attribute that went from 0 to n, because we
>> don't know what the limit is going to be. I can see how ordering is
>> useful but I think we should talk with the devs and look for a better
>> way.
>
> This was already discussed a few months ago, I remember that someone
> noted that numbering could be dificult to handle because of
> overlapping splits, which happens for example in operas. I don't read
> music, so I never saw an opera score, but I believe that there are not
> always clear separations in the score. Maybe we should use the bar
> number in those cases? Anyhow, if we handle numbers (I think of course
> that we should), we must be very careful about how we number the
> sub-parts because it will not always be as easy as with movements.
>
> --
> 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
>

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

Re: [mb-style] RFV-321: Work parts relationship

[Lemire, Sebastien]

There might not be numbers, but they were definitely composed with an
order in mind.
I absolutely don't want MB to add 1. 2. 3. in front of movements, but
somehow it would be best for the order to preserved

Sebastien

On Fri, Jun 10, 2011 at 11:42 AM, symphonick  wrote:
> On Fri, 10 Jun 2011 17:16:38 +0200, Frederic Da Vitoria
>  wrote:
>
>> This was already discussed a few months ago, I remember that someone
>> noted that numbering could be dificult to handle because of
>> overlapping splits, which happens for example in operas. I don't read
>> music, so I never saw an opera score, but I believe that there are not
>> always clear separations in the score.
>
> & that's not only for opera. (this is another reason why it's a bad idea
> to add movement numbers if the composer didn't write any)
>
> I don't know if a next/previous movement AR like the part of set-AR would
> work. What to do with alternative versions, revisions and such?
>
> /symphonick
>
> ___
> 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] RFV-321: Work parts relationship

[Frederic Da Vitoria]

2011/6/10, Lemire, Sebastien :
> It would almost be best to not have the Opera parts as separate and
> distinct works in the MB database and simply have them in the track
> listings. Perhaps large parts of Opera could be in, such as Act I, Act
> II, Act III, etc... Can anyone think why we'd want the individual Aria
> or Recitavo as a distinct work? The Overtures should definitely be as
> they are often recorded independently of the Opera

Yes, this could be a solution.


> There are, however, albums of famous Arias, where they are
> recorded/sang/released independently of the Opera or Act. Perhaps they
> could be treated as partial performances of the larger work be tagged
> as such at the recording level (how partial classical performances
> should also be tagged, they definitely should not be a unique work)

I agree this would be consistent with the first suggestion.

Maybe we should indeed stop at the borders clearly defined by the
composer himself.

-- 
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] RFV-321: Work parts relationship

[Simon Reinhardt]

Lemire, Sebastien wrote:
> There might not be numbers, but they were definitely composed with an
> order in mind.
> I absolutely don't want MB to add 1. 2. 3. in front of movements, but
> somehow it would be best for the order to preserved

I liked what Christopher Key proposed: Having a sort name field on works that 
will be used for ordering relationships.
I meant to say that before but for some reason I sent my reply only to him and 
not the list. :-)

Regards,
   Simon

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

Re: [mb-style] NGS and Duos

[monxton]

On 10/06/2011 08:24, Alex Mauer wrote:

> I'm not talking about collaboration relationships here,

OK. Look in the corner of the room. See that big grey thing with the 
flappy ears?

> I'm talking about situations where it is appropriate to
> use artist credits instead of creating separate artists

AFAIK, the history of the collaboration artist relationship is that it 
was created as a stopgap solution to provide multiple primary artists 
where necessary. See 
http://wiki.musicbrainz.org/Getting_Rid_Of_Featuring_Artist_Style. The 
MBz guidelines tell us to use a productivity/ longevity criterion to 
decide whether to use a collaboration relationship or a member-of-band 
relationship.

Now we have NGS, which is  the happy state towards which the stopgap was 
put in place. So, if all the editors did the right thing, then the 
groups joined by a collaboration relationship should be precisely those 
to be split using ARs, and those by a member-of-band relationship should 
be those to be left alone. The collaboration relationship should now be 
effectively obsolete.

At the start of this thread I asked whether this criterion had changed, 
and the only response was that no, it had not changed.

Of course not all editors did do the right thing, and it's fine to 
re-examine the relationships and adjust them where they are wrong. 
However it's not fine arbitrarily to discount the productivity/ 
longevity criterion for doing so, since this is the one criterion laid 
out in the guidelines.

Some refinement of this guideline along the lines you suggest may be 
desirable. This is probably less significant than some other things in 
the RFC/RFV process right now though.


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

Re: [mb-style] NGS and Duos

[Alex Mauer]

On 06/10/2011 11:38 AM, monxton wrote:
> Now we have NGS, which is  the happy state towards which the stopgap was 
> put in place. So, if all the editors did the right thing, then the 
> groups joined by a collaboration relationship should be precisely those 
> to be split using ARs, and those by a member-of-band relationship should 
> be those to be left alone. The collaboration relationship should now be 
> effectively obsolete.

Well, it’s not. (See Meatgirl, and I’m sure there are others.)

> At the start of this thread I asked whether this criterion had changed, 
> and the only response was that no, it had not changed.

Fascinating.  That’s absolutely wonderful for deciding whether an artist
is a collaboration or not.  But that’s still Not What We’re Talking About.

When we look at the guidelines, can we please look at the Artist Credit
guideline, which applies to the situation we’retalking about[1]?  That
guideline certainly does refer to collaborations as an example of
something which can be done with artist credits.  But it doesn’t say
anything like “These are the only situations to which artist credits
apply, do not ever use them otherwise”

> Some refinement of this guideline along the lines you suggest may be 
> desirable. This is probably less significant than some other things in 
> the RFC/RFV process right now though.

1. http://musicbrainz.org/doc/Artist_Credit


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

Re: [mb-style] RFV-321: Work parts relationship

[symphonick]

On Fri, 10 Jun 2011 17:53:02 +0200, Frederic Da Vitoria  
 wrote:

> 2011/6/10, Lemire, Sebastien :

>> Perhaps large parts of Opera could be in, such as Act I, Act
>> II, Act III, etc... Can anyone think why we'd want the individual Aria
>> or Recitavo as a distinct work? The Overtures should definitely be as
>> they are often recorded independently of the Opera
>
> Yes, this could be a solution.
>
I strongly disagree. I can't see why Opera should be treated differently  
to the rest of (classical) MB? Recordings with several movements are not  
an issue, just relate to all relevant works. Overlapping recordings can  
(and will) be a pain everywhere. A "partial performance" AR maybe can help.

/symphonick

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

[mb-style] Passed: Work parts relationship

[Alex Mauer]

The RFV period of this has passed with no objections and several +1s.

I have entered ticket #MBS-2701 to get this implemented[1].

Hopefully once the work part is there, guidelines can be created for
naming conventions on the works vs. their parts.


1. http://tickets.musicbrainz.org/browse/MBS-2701


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

Re: [mb-style] RFV-321: Work parts relationship

[Lemire, Sebastien]

Aren't the tracks in on a Opera release more an object convenience and that
it would be rather unwieldy to have 30-40 minute tracks on a CD rather than
anything else?
I think we can we assume that the composer never intended his opera to be
split in 85 different parts.
To be frank, I don't really think that movements should themselves be a
separate entity. the 2nd movement of Beethoven's symphony No. 5 should not
be recorded or performed on it's own. The same can be said of Haydn's 3rd
movement in his 93rd Symphony...

But I can see advantages for them to be individual works. In particular
certain work parts have come over time to either be part of a larger work or
to become famous on their own. I can think of Vivaldi's 4 seasons here. Are
the 4 concertos 4 independent works? Are they part of a grand work that
includes all 4? In fact, when I was tagging these works using allmusic.com,
it was inconsistent, both entities existed (at least they did 4-5 years
ago), and depending on the album, they were used interchangeably.

Like I mentioned earlier, I'm no expect in Opera, or in Classical music, but
that's how it looks to me.

Sebastien


> I strongly disagree. I can't see why Opera should be treated differently
> to the rest of (classical) MB? Recordings with several movements are not
> an issue, just relate to all relevant works. Overlapping recordings can
> (and will) be a pain everywhere. A "partial performance" AR maybe can help.
>
>
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] NGS and Duos

[monxton]

I'm done with this thread unless another editor has new points to make. 
If you're still here, thanks for reading so far.



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

Re: [mb-style] RFC: Collaboration Relationship Type update

[Alex Mauer]

On 06/07/2011 09:15 AM, Nicolás Tamargo de Eguren wrote:
> Just a (fairly straightforward, I expect) update to limit the
> collaboration relationship to cases where we can't use artist credits.
> 
> See 
> http://wiki.musicbrainz.org/User:Reosarevok/Collaboration_Relationship_Type_update
> (vs. the current
> http://wiki.musicbrainz.org/Collaboration_Relationship_Type )

+1

—Alex Mauer “hawke”


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

Re: [mb-style] RFV-321: Work parts relationship

[Frederic Da Vitoria]

2011/6/10 symphonick 

> On Fri, 10 Jun 2011 17:53:02 +0200, Frederic Da Vitoria
>  wrote:
>
> > 2011/6/10, Lemire, Sebastien :
>
> >> Perhaps large parts of Opera could be in, such as Act I, Act
> >> II, Act III, etc... Can anyone think why we'd want the individual Aria
> >> or Recitavo as a distinct work? The Overtures should definitely be as
> >> they are often recorded independently of the Opera
> >
> > Yes, this could be a solution.
> >
> I strongly disagree. I can't see why Opera should be treated differently
> to the rest of (classical) MB? Recordings with several movements are not
> an issue, just relate to all relevant works. Overlapping recordings can
> (and will) be a pain everywhere. A "partial performance" AR maybe can help.
>

I'm not sure I understand what you are saying or that you understood
Sebastien's suggestion (which was already made by someone else IIRC): Don't
split an opera in smaller parts than acts if the composer did not clearly
define lower-level split points. This would not really be treating opera
differently from the rest of classical music, after all we don't advise
dividing movements into sub-parts either! This suggestion seems sound
because if there is no clear partition of the acts, we will probably end up
with overlapping sub-works partitions, which will be quite difficult to
handle. If the composer did clearly indicate the limits of the airs,
recitavos and so on, then we can add the composer's partition as sub-works,
it will ensure that there is only one set of sub-works.

-- 
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] RFV-321: Work parts relationship

[symphonick]

On Fri, 10 Jun 2011 22:30:58 +0200, Frederic Da Vitoria  
 wrote:

> I'm not sure I understand what you are saying or that you understood
> Sebastien's suggestion (which was already made by someone else IIRC):  
> Don't
> split an opera in smaller parts than acts if the composer did not clearly
> define lower-level split points.

You're right, I didn't understand.
"Don't split works in smaller parts if the composer did not clearly define  
lower-level split points" sounds like good starting point. Which means  
we'll have to check works against good sources, urtext editions where  
possible. Otherwise it's going to be guesswork.

/symphonick

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

Re: [mb-style] RFV-321: Work parts relationship

[Frederic Da Vitoria]

2011/6/10 symphonick 

> On Fri, 10 Jun 2011 22:30:58 +0200, Frederic Da Vitoria
>  wrote:
>
> > I'm not sure I understand what you are saying or that you understood
> > Sebastien's suggestion (which was already made by someone else IIRC):
> > Don't
> > split an opera in smaller parts than acts if the composer did not clearly
> > define lower-level split points.
>
> You're right, I didn't understand.
> "Don't split works in smaller parts if the composer did not clearly define
> lower-level split points" sounds like good starting point. Which means
> we'll have to check works against good sources, urtext editions where
> possible. Otherwise it's going to be guesswork.
>

Yes, guesswork and votes :-)

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

[mb-style] RFC: Add "8cm CD" format (Mini CD / 3" CD) as a subtype of CD format

[Yin Izanami]

Proposal is to add "8cm CD" as a subtype of CD in the medium format list.

http://en.wikipedia.org/wiki/Mini_CD_single
http://ja.wikipedia.org/wiki/8%E3%82%BB%E3%83%B3%E3%83%81CD

I'd prefer seeing "8cm CD" if no one objects to this, since the format was
most successful/used in Japan (it was widely used for over a decade).

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

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

[Paul C. Bryan]

On Thu, 2011-06-09 at 15:48 +0100, Pete Marsh wrote:

> thanks Paul!
>  
> i still think the criteria for a remix becoming a work rather than a
> recording need a bit more discussion. credits for additional lyrics or
> compositions on such things are going to be the exception rather than
> the rule. in fact i would argue that in the vast majority of cases
> remixes will introduce additional material, yet very rarely is the
> remixer given a composition credit. so my feeling is that by default a
> remix a should be a new work (a different duration is usually a
> giveaway).  those cases where we are merely dealing with just a
> rebalancing of the material (ie a remix in the strict sense of the word)
> then could be a recording-recording relationship (in the same way a
> remastered recording might).
> 
> am i being too philosophical here?
> :-) 


You may be, but it's worthy of discussion IMO. Your position calls into
question the issue of covers then. By your definitions, covers should
also be different works:


  * different recording material 
  * rarely a different composition credit 
  * different duration


I find myself resistant to the idea that covers should be different
works. By the same philosophy, I am resistant to the idea that all
remixes should be different works. 

Paul


>  
> 
> 
> From: musicbrainz-style-boun...@lists.musicbrainz.org
> [mailto:musicbrainz-style-boun...@lists.musicbrainz.org] On Behalf Of
> Paul C. Bryan
> Sent: 08 June 2011 23:46
> To: MusicBrainz Style Discussion
> Subject: Re: [mb-style] Works and remixes/covers
> 
> 
> On Tue, 2011-06-07 at 16:16 +0100, Pete Marsh wrote:
> 
> 
> 
>   This makes my head hurt, but here's a couple of questions just
> to make sure I'm kind of understanding it
>   
> 
> 
> Take 2 ARs and call us in the morning. ;-)
> 
> 
> 
>   1) how do we ascertain that a remix has enough new content to
> make it a new work? (it's going to be the exception rather than the rule
> to have new lyricist/composer credits). it would seem to me that most
> contemporary remixes would fall under that category. some are almost
> indistinguishable from the original (Aphex Twin has been known to pass
> off completely original new works as remixes)
>   
> 
> 
> I suggest it be when the derivative work has work attributions that are
> distinct from the original (e.g. additional composer or lyricist).
> 
> 
> 
>   2) wouldn't the relationship be to a recording, not a work?  so
> the remix is a work extrapolated from a recording?
>   
> 
> 
> Yes, it would be too. It wouldn't be a remix if it did not contain
> recordings from the original it is a remix of. The issue is that a remix
> can contain "additional work" of another artist.
> 
> Paul 
> 
> ___
> 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] RFC: Add "8cm CD" format (Mini CD / 3" CD) as a subtype of CD format

[Nikki]

Yin Izanami wrote:
> Proposal is to add "8cm CD" as a subtype of CD in the medium format list.

Yay!! Definitely a +1.

I've already tagged over a thousand releases with "8cm cd" - 
http://musicbrainz.org/tag/8cm%20cd/release-group (the tags were 
migrated to release groups in NGS)

> I'd prefer seeing "8cm CD" if no one objects to this, since the format was
> most successful/used in Japan (it was widely used for over a decade).

I would also prefer 8cm CD for that reason too.

Nikki

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

Re: [mb-style] NGS and Duos

[Nikki]

monxton wrote:
> Now we have NGS, which is  the happy state towards which the stopgap was 
> put in place. So, if all the editors did the right thing, then the 
> groups joined by a collaboration relationship should be precisely those 
> to be split using ARs, and those by a member-of-band relationship should 
> be those to be left alone. The collaboration relationship should now be 
> effectively obsolete.

The collaboration relationship is still needed in some cases - if the 
collaboration has its own name. I suppose we could theoretically merge 
it with the member relationship (removing the distinction between long 
term projects and named short term projects) if we really want to get 
rid of it completely.

Nikki

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

Re: [mb-style] NGS and Duos

[Lemire, Sebastien]

all this arguing over collaboration credits. Say we have a collaboration of
Charles Aznavour and Frank Sinatra. Why can't the following artist credits:
- Charles Aznavour
- Frank Sinatra
- Charles Aznavour & Frank Sinatra (if they've collaborated long enough or
if it's clear enough from the album cover)

Wouldn't this make everyone happy? Is there a technical reason why this
shouldn't be done?

Sebastien
 On 10 Jun 2011 20:36, "Nikki"  wrote:
> monxton wrote:
>> Now we have NGS, which is the happy state towards which the stopgap was
>> put in place. So, if all the editors did the right thing, then the
>> groups joined by a collaboration relationship should be precisely those
>> to be split using ARs, and those by a member-of-band relationship should
>> be those to be left alone. The collaboration relationship should now be
>> effectively obsolete.
>
> The collaboration relationship is still needed in some cases - if the
> collaboration has its own name. I suppose we could theoretically merge
> it with the member relationship (removing the distinction between long
> term projects and named short term projects) if we really want to get
> rid of it completely.
>
> Nikki
>
> ___
> 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] NGS and Duos

[Nikki]

Lemire, Sebastien wrote:
> all this arguing over collaboration credits. Say we have a collaboration of
> Charles Aznavour and Frank Sinatra. Why can't the following artist credits:
> - Charles Aznavour
> - Frank Sinatra
> - Charles Aznavour & Frank Sinatra (if they've collaborated long enough or
> if it's clear enough from the album cover)

Nobody's disputing that. The argument is about *when* we should use one 
and when the other. What counts as "collaborated long enough"?

Nikki

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