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
On Tue, 2011-06-07 at 07:28 -0400, Calvin Walton wrote:
> One thing that concerns me a bit with a work→work remix ar: Remixes are
> typically based on a specific recording of a work. How do we represent
> this in Musicbrainz? Should we continue to use the recording→recording
> AR alongside the wo
2011/6/8 caramel
>
> I much prefer having just one entity type (and we've already got a type
>> attribute on it to specify groupy things) and linking with relationships to
>> having a group entity and a schema link.
>>
> *Yes, we can decide to have only one "work" for one composition...
> includ
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
__
When tagging, the way I work (I had written a script in The Godfather
and scraped Allmusic.com, which hasn't worked in a few years, from
lack of motivation to update it) was this way:
%WORK_NAME%: String Quartet No. 2 in F major, Op. 22 (In fact I even
split the Work name and Opus in separate tags
On Jun 8, 2011, at 12:35 PM, Alex Mauer wrote:
> On 06/08/2011 12:09 PM, Michael Wiencek wrote:
>> When a work has a hundred different recordings, it makes it much easier to
>> view and manage the list because they are sorted and grouped by the link
>> phrase.
>
> Interesting, I think it makes it
On 06/08/2011 12:09 PM, Michael Wiencek wrote:
> When a work has a hundred different recordings, it makes it much easier to
> view and manage the list because they are sorted and grouped by the link
> phrase.
Interesting, I think it makes it more difficult because you have to look
in several diffe
On 06/08/2011 12:07 PM, Lemire, Sebastien wrote:
> +1 for me as well.
> I just had a thought about this, how about if the subpart works *DO
> NOT* include the linked work in their name.
>
> Example (for classical):
> Currently there's a work under Tchaikovsky: String Quartet No. 2 in F
> major, O
On Wed, 08 Jun 2011 19:11:14 +0200, Nicolás Tamargo de Eguren
wrote:
> On Wed, Jun 8, 2011 at 8:07 PM, Lemire, Sebastien
> wrote:
>> Ideally, the sub-work should only be "III. Andante ma non tanto"
> Anyway, let's pass this RFV like it is for now and changes can be
> proposed later :)
+1
On Wed, Jun 8, 2011 at 8:07 PM, Lemire, Sebastien wrote:
> +1 for me as well.
> I just had a thought about this, how about if the subpart works *DO
> NOT* include the linked work in their name.
>
> Example (for classical):
> Currently there's a work under Tchaikovsky: String Quartet No. 2 in F
>
On Jun 8, 2011, at 11:56 AM, Alex Mauer wrote:
> On 06/08/2011 11:15 AM, Michael Wiencek wrote:
>> This RFC is to add a "live" attribute to the recording<->work "performance
>> of"
>> relationship. It should expire on June 15.
>
> Why a separate attribute rather than just storing it (along with
+1 for me as well.
I just had a thought about this, how about if the subpart works *DO
NOT* include the linked work in their name.
Example (for classical):
Currently there's a work under Tchaikovsky: String Quartet No. 2 in F
major, Op. 22: III. Andante ma non tanto
Ideally, the sub-work should o
On Wed, Jun 8, 2011 at 7:56 PM, Alex Mauer wrote:
> On 06/08/2011 11:15 AM, Michael Wiencek wrote:
>> This RFC is to add a "live" attribute to the recording<->work "performance
>> of"
>> relationship. It should expire on June 15.
>
> Why a separate attribute rather than just storing it (along wit
On 06/08/2011 11:15 AM, Michael Wiencek wrote:
> This RFC is to add a "live" attribute to the recording<->work "performance of"
> relationship. It should expire on June 15.
Why a separate attribute rather than just storing it (along with the
date if available, similar to Live Bootleg Style) in the
On Jun 8, 2011, at 11:23 AM, Frederic Da Vitoria wrote:
> 2011/6/8, Michael Wiencek :
>> This RFC is to add a "live" attribute to the recording<->work "performance
>> of"
>> relationship. It should expire on June 15.
>>
>> There is a current revision at:
>> http://wiki.musicbrainz.org/User:Bitmap
+1 here as well, would be great to differentiate pre-recorded
recording and live recordings (at least for POP, Jazz, Rock, etc...)
With classical, Opera, well, it's almost always Live, but I'm sure
there's exceptions
On Wed, Jun 8, 2011 at 12:23 PM, Frederic Da Vitoria
wrote:
> 2011/6/8, Michael
On Wed, Jun 8, 2011 at 7:19 PM, 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/Proposa
2011/6/8, Michael Wiencek :
> This RFC is to add a "live" attribute to the recording<->work "performance
> of"
> relationship. It should expire on June 15.
>
> There is a current revision at:
> http://wiki.musicbrainz.org/User:Bitmap/Performed_Relationship_Type_Live_Attribute
>
> As you can see, th
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
___
On Wed, Jun 8, 2011 at 7:15 PM, Michael Wiencek wrote:
> This RFC is to add a "live" attribute to the recording<->work "performance of"
> relationship. It should expire on June 15.
>
> There is a current revision at:
> http://wiki.musicbrainz.org/User:Bitmap/Performed_Relationship_Type_Live_Attrib
This RFC is to add a "live" attribute to the recording<->work "performance of"
relationship. It should expire on June 15.
There is a current revision at:
http://wiki.musicbrainz.org/User:Bitmap/Performed_Relationship_Type_Live_Attribute
As you can see, the attribute "indicates that the recording
On 06/07/2011 11:32 PM, caramel wrote:
I still don't understand why a large number of sub-parts would
mean we should have a work group entity. If it's just the amount
of work of adding all the relationships then an interface tweak
should be able to help ...
/You pointed out th
On Wed, Jun 8, 2011 at 5:16 PM, monxton wrote:
> I'd like some clarification please, about Duos and their representation
> in NGS.
>
> I do a lot of editing of traditional folk music, and in this world there
> are many duos. It's always been something of an exercise of judgement to
> decide which
I'd like some clarification please, about Duos and their representation
in NGS.
I do a lot of editing of traditional folk music, and in this world there
are many duos. It's always been something of an exercise of judgement to
decide which to enter as collaborations and which as groups, but I tr
24 matches
Mail list logo
