[mb-style] RFC-321: Work parts relationship

2011-06-01 Thread Alex Mauer
After some discussion on IRC[1], there seems to be some agreement that it would be useful to have a work-work relationship type to indicate that one work is part of another. This holds especially true for classical works where a piece is often divided into movements. As such, this is the RFC for

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

2011-06-01 Thread Frederic Da Vitoria
2011/6/2 Alex Mauer > After some discussion on IRC[1], there seems to be some agreement that > it would be useful to have a work-work relationship type to indicate > that one work is part of another. This holds especially true for > classical works where a piece is often divided into movements.

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

2011-06-01 Thread Alex Mauer
On 06/01/2011 06:29 PM, Frederic Da Vitoria wrote: > What would be the meaning of the start and end dates? Er, nothing. That’s just the wiki template talking — there doesn’t seem to be a way to disable the display of start/end date. —Alex Mauer “hawke” _

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

2011-06-01 Thread Frederic Da Vitoria
2011/6/2 Alex Mauer > On 06/01/2011 06:29 PM, Frederic Da Vitoria wrote: > > What would be the meaning of the start and end dates? > > Er, nothing. That’s just the wiki template talking — there doesn’t seem > to be a way to disable the display of start/end date. > Ok. +1, then :-) -- Frederic

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

2011-06-02 Thread Aurélien Mino
On 06/02/2011 12:34 AM, Alex Mauer wrote: > After some discussion on IRC[1], there seems to be some agreement that > it would be useful to have a work-work relationship type to indicate > that one work is part of another. This holds especially true for > classical works where a piece is often divi

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

2011-06-02 Thread Alex Mauer
On 06/02/2011 07:10 AM, Aurélien Mino wrote: > 2. Make a clear distinction with the medley work-work AR: it may sound > obvious, but I think it should be clarified. Any suggestions on wording? I think “where the composer split a work into multiple parts” covers that, because a medley is not (eve

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

2011-06-04 Thread Simon Reinhardt
Hi, Wow, it's been a long time since I've been signed up here. :-) +1 on this proposal, it is much needed for progressive rock, some metal etc. Reading the guidelines section I think later on we might also need an attribute for the "recording performance of work" relationship so that we can have

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

2011-06-06 Thread caramel
This AR could be useful but mostly when there are only few works related together. I would prefer the concept of "Work group" instead with the possibility for the works to inherit the ARs at the work group level. For CSG, the number of sub-works can be several tens.

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

2011-06-06 Thread Simon Reinhardt
Hi caramel wrote: > This AR could be useful but mostly when there are only few works related > together. I would prefer the concept of "Work group" instead with the > possibility for the works to inherit the ARs at the work group level. > For CSG, the number of sub-works can be several tens. I'

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

2011-06-06 Thread Alex Mauer
On 06/04/2011 07:36 PM, Simon Reinhardt wrote: > Hi, > > Wow, it's been a long time since I've been signed up here. :-) > > +1 on this proposal, it is much needed for progressive rock, some metal etc. > > Reading the guidelines section I think later on we might also need an > attribute for the "

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

2011-06-06 Thread Christopher Key
On 06/06/2011 19:05, Alex Mauer wrote: > On 06/04/2011 07:36 PM, Simon Reinhardt wrote: >> Hi, >> >> Wow, it's been a long time since I've been signed up here. :-) >> >> +1 on this proposal, it is much needed for progressive rock, some metal etc. >> >> Reading the guidelines section I think later o

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

2011-06-06 Thread Frederic Da Vitoria
2011/6/6 Christopher Key > On 06/06/2011 19:05, Alex Mauer wrote: > > On 06/04/2011 07:36 PM, Simon Reinhardt wrote: > >> Hi, > >> > >> Wow, it's been a long time since I've been signed up here. :-) > >> > >> +1 on this proposal, it is much needed for progressive rock, some metal > etc. > >> > >>

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

2011-06-06 Thread Alex Mauer
On 06/06/2011 02:02 PM, Christopher Key wrote: > On 06/06/2011 19:05, Alex Mauer wrote: >> On 06/04/2011 07:36 PM, Simon Reinhardt wrote: >>> One last point: What are we going to do about ordering of the parts? You >>> can't do it with the relationship so should the titles of the part works >>> hav

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

2011-06-06 Thread symphonick
On Mon, 06 Jun 2011 21:41:35 +0200, Alex Mauer wrote: > On 06/06/2011 02:02 PM, Christopher Key wrote: >> On 06/06/2011 19:05, Alex Mauer wrote: >>> On 06/04/2011 07:36 PM, Simon Reinhardt wrote: One last point: What are we going to do about ordering of the parts? You can't do

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

2011-06-06 Thread Frederic Da Vitoria
2011/6/6 Alex Mauer > On 06/06/2011 02:02 PM, Christopher Key wrote: > > On 06/06/2011 19:05, Alex Mauer wrote: > >> On 06/04/2011 07:36 PM, Simon Reinhardt wrote: > >>> One last point: What are we going to do about ordering of the parts? > You > >>> can't do it with the relationship so should th

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

2011-06-06 Thread caramel
2011/6/6 Simon Reinhardt > Hi > > > caramel wrote: > >> This AR could be useful but mostly when there are only few works related >> together. I would prefer the concept of "Work group" instead with the >> possibility for the works to inherit the ARs at the work group level. >> For CSG, the number

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

2011-06-07 Thread Maurits Meulenbelt
I don't know if this has been mentioned before (in that case I've missed it), but I think we should be careful about inheriting ARs from the aggregate work to the subworks. Some works are left unfinished by a composer and finished by another, which leads to different composers on different parts

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

2011-06-07 Thread Frederic Da Vitoria
2011/6/7, Maurits Meulenbelt : > I don't know if this has been mentioned before (in that case I've missed > it), but I think we should be careful about inheriting ARs from the > aggregate work to the subworks. > Some works are left unfinished by a composer and finished by another, > which leads to

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

2011-06-07 Thread caramel
I propose to switch to the right discussion thread (RFC Works group) not to change too much the original subject of this proposal even if they are related. 2011/6/7 Frederic Da Vitoria > 2011/6/7, Maurits Meulenbelt : > > I don't know if this has been mentioned before (in that case I've missed >

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

2011-06-07 Thread Simon Reinhardt
Christopher Key wrote: > On 06/06/2011 19:05, Alex Mauer wrote: >> On 06/04/2011 07:36 PM, Simon Reinhardt wrote: >>> One last point: What are we going to do about ordering of the parts? You >>> can't do it with the relationship so should the titles of the part works >>> have numbers in them? >

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

2011-06-07 Thread Simon Reinhardt
symphonick wrote: > And, as Rob suggested, not having to repeat the main work title for all > the subparts. > http://lists.musicbrainz.org/pipermail/musicbrainz-users/2011-May/020578.html Hmm, good point. This sounds like something that should be covered by the guidelines for the relationship as

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

2011-06-07 Thread Frederic Da Vitoria
2011/6/7 Simon Reinhardt > symphonick wrote: > > And, as Rob suggested, not having to repeat the main work title for all > > the subparts. > > > http://lists.musicbrainz.org/pipermail/musicbrainz-users/2011-May/020578.html > > Hmm, good point. This sounds like something that should be covered by