RFC: Concept of works group

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: Concept of works group

caramel31
I discussed in other threads about the concept of works, super-works and sub-works. It is specially relevant for classical works but may be not reduced to them.
Actually there is a work type (with aggregate attribute) but seems not to work...

1. If we consider the Bach's St John Passion. There are 68 individual pieces with the first sentence of lyrics as (sub-)work names.  All the ARs given for the first piece (composer, year, lyricist,...) have to be set for the 67 other works. The score is for all the composition too, not only a small piece of few bars.

2. There is no ARs between the (sub-)works of one composition. Nor ARs between works of one collection (super-work, eg. (the three) Gymnopédies)

ARs given to a "Works group" should be derived to the works entities...except if an individual ARs at work level is set.

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Concept of works group

Frederic Da Vitoria
2011/5/19 caramel <[hidden email]>
I discussed in other threads about the concept of works, super-works and sub-works. It is specially relevant for classical works but may be not reduced to them.
Actually there is a work type (with aggregate attribute) but seems not to work...

1. If we consider the Bach's St John Passion. There are 68 individual pieces with the first sentence of lyrics as (sub-)work names.  All the ARs given for the first piece (composer, year, lyricist,...) have to be set for the 67 other works. The score is for all the composition too, not only a small piece of few bars.

2. There is no ARs between the (sub-)works of one composition. Nor ARs between works of one collection (super-work, eg. (the three) Gymnopédies)

ARs given to a "Works group" should be derived to the works entities...except if an individual ARs at work level is set.

This is indeed an important matter. There was a discussion about it a few months ago : http://musicbrainz.1054305.n4.nabble.com/Granularity-of-works-td3078828.html#a3080472

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org


_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Concept of works group

Lukáš Lalinský
In reply to this post by caramel31
On Thu, May 19, 2011 at 12:29 PM, caramel <[hidden email]> wrote:
> I discussed in other threads about the concept of works, super-works and
> sub-works. It is specially relevant for classical works but may be not
> reduced to them.
> Actually there is a work type (with aggregate attribute) but seems not to
> work...

The work type doesn't work because we didn't define what would be
useful to have there, but it was intended precisely for having
multiple layers of works as you describe.

> 1. If we consider the Bach's St John Passion. There are 68 individual pieces
> with the first sentence of lyrics as (sub-)work names.  All the ARs given
> for the first piece (composer, year, lyricist,...) have to be set for the 67
> other works. The score is for all the composition too, not only a small
> piece of few bars.
>
> 2. There is no ARs between the (sub-)works of one composition. Nor ARs
> between works of one collection (super-work, eg. (the three) Gymnopédies)

All this still has to be defined. Adding work-work AR types as well as
work types is easy to do technically, but hard to define what exactly
do we want to track. NGS was meant to mainly improve on the
release/recording model, the minimalistic work model was added to
experiment with the data and see how to make it useful.

Lukas

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Concept of works group

caramel31
UP .... not to pollute the other (but related) thread.
To answer to Maurits, yes, the inheritance of the work group ARs is the default in the model proposed... unless an AR (of the same type) is set at work level. That could permit to change locally the name of the librettist or other information specific to a (sub)work.


_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Concept of works group

Frederic Da Vitoria
2011/6/7, caramel <[hidden email]>:
> UP .... not to pollute the other (but related) thread.
> To answer to Maurits, yes, the inheritance of the work group ARs is the
> default in the model proposed... unless an AR (of the same type) is set at
> work level. That could permit to change locally the name of the librettist
> or other information specific to a (sub)work.

I am not saying your idea is wrong, but I fail to see why there should
be 2 concepts, sub-works and work groups. Or did I misunderstand you?

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Concept of works group

caramel31


2011/6/7 Frederic Da Vitoria <[hidden email]>
2011/6/7, caramel <[hidden email]>:
> UP .... not to pollute the other (but related) thread.
> To answer to Maurits, yes, the inheritance of the work group ARs is the
> default in the model proposed... unless an AR (of the same type) is set at
> work level. That could permit to change locally the name of the librettist
> or other information specific to a (sub)work.

I am not saying your idea is wrong, but I fail to see why there should
be 2 concepts, sub-works and work groups. Or did I misunderstand you?

We already discussed but it is needed to clarify.

The proposal here is to add a workgroup level (with the parallel with releasegroup). The objective of this structure is "to group":
  1. All movements, parts,... of one composition
    • The "classical" four movements of a symphony, the 68 "songs" of St John Passion",....
    • The actual works are in fact artificial split (sub)works of one real work.
  2. All parts of a collection
    • It is the same as above but the frontier between a composition and a set of composition is not well defined
    • eg. the 21 pieces of "Sports et divertissements" from Satie
    • eg. the 9 parts of "Shine On You Crazy Diamond" from Pink Floyd
It should be better if there is a possibility to number (==> to order) the works belonging to a workgroup. About ARs, it should be great to set the same kind of AR at workgroup than at work level and to have a default inheritance of the ARs to the works. If an AR should be removed or updated for one or several works, it is done manually at the work level.

Same workgroup could be used too for covers/remixes/different orchestrations/instrumental versions of a work. (a non-ordered set of works)

It should be possible to group both numbered and not numbered works in a workgroup.

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Frederic Da Vitoria
    2011/6/7, caramel <[hidden email]>:

    > 2011/6/7 Frederic Da Vitoria <[hidden email]>
    >
    >> 2011/6/7, caramel <[hidden email]>:
    >> > UP .... not to pollute the other (but related) thread.
    >> > To answer to Maurits, yes, the inheritance of the work group ARs is the
    >> > default in the model proposed... unless an AR (of the same type) is set
    >> at
    >> > work level. That could permit to change locally the name of the
    >> librettist
    >> > or other information specific to a (sub)work.
    >>
    >> I am not saying your idea is wrong, but I fail to see why there should
    >> be 2 concepts, sub-works and work groups. Or did I misunderstand you?
    >>
    >> We already discussed but it is needed to clarify.
    >
    > The proposal here is to add a workgroup level (with the parallel with
    > releasegroup). The objective of this structure is "to group":
    >
    >    1. All movements, parts,... of one composition
    >       - The "classical" four movements of a symphony, the 68 "songs" of St
    >       John Passion",....
    >       - The actual works are in fact artificial split (sub)works of one real
    >       work.
    >    2. All parts of a collection
    >       - It is the same as above but the frontier between a composition and a
    >       set of composition is not well defined
    >       - eg. the 21 pieces of "Sports et divertissements" from Satie
    >       - eg. the 9 parts of "Shine On You Crazy Diamond" from Pink Floyd
    >
    > It should be better if there is a possibility to number (==> to order) the
    > works belonging to a workgroup. About ARs, it should be great to set the
    > same kind of AR at workgroup than at work level and to have a default
    > inheritance of the ARs to the works. If an AR should be removed or updated
    > for one or several works, it is done manually at the work level.
    >
    > Same workgroup could be used too for covers/remixes/different
    > orchestrations/instrumental versions of a work. (a non-ordered set of works)
    >
    > It should be possible to group both numbered and not numbered works in a
    > workgroup.
    >


    --
    Frederic Da Vitoria
    (davitof)

    Membre de l'April - « promouvoir et défendre le logiciel libre » -
    http://www.april.org

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Frederic Da Vitoria
    2011/6/7, Frederic Da Vitoria <[hidden email]>:

    > 2011/6/7, caramel <[hidden email]>:
    >> 2011/6/7 Frederic Da Vitoria <[hidden email]>
    >>
    >>> 2011/6/7, caramel <[hidden email]>:
    >>> > UP .... not to pollute the other (but related) thread.
    >>> > To answer to Maurits, yes, the inheritance of the work group ARs is
    >>> > the
    >>> > default in the model proposed... unless an AR (of the same type) is
    >>> > set
    >>> at
    >>> > work level. That could permit to change locally the name of the
    >>> librettist
    >>> > or other information specific to a (sub)work.
    >>>
    >>> I am not saying your idea is wrong, but I fail to see why there should
    >>> be 2 concepts, sub-works and work groups. Or did I misunderstand you?
    >>>
    >>> We already discussed but it is needed to clarify.
    >>
    >> The proposal here is to add a workgroup level (with the parallel with
    >> releasegroup). The objective of this structure is "to group":
    >>
    >>    1. All movements, parts,... of one composition
    >>       - The "classical" four movements of a symphony, the 68 "songs" of
    >> St
    >>       John Passion",....
    >>       - The actual works are in fact artificial split (sub)works of one
    >> real
    >>       work.
    >>    2. All parts of a collection
    >>       - It is the same as above but the frontier between a composition and
    >> a
    >>       set of composition is not well defined
    >>       - eg. the 21 pieces of "Sports et divertissements" from Satie
    >>       - eg. the 9 parts of "Shine On You Crazy Diamond" from Pink Floyd
    >>
    >> It should be better if there is a possibility to number (==> to order)
    >> the
    >> works belonging to a workgroup. About ARs, it should be great to set the
    >> same kind of AR at workgroup than at work level and to have a default
    >> inheritance of the ARs to the works. If an AR should be removed or
    >> updated
    >> for one or several works, it is done manually at the work level.
    >>
    >> Same workgroup could be used too for covers/remixes/different
    >> orchestrations/instrumental versions of a work. (a non-ordered set of
    >> works)
    >>
    >> It should be possible to group both numbered and not numbered works in a
    >> workgroup.

    (Sorry, wrong button :-P )

    I still am not sure, do you think that Work Groups would be enough to
    handle all we need? I am asking you this because I think that as much
    as possible we should limit the number of different relations.

    BTW, I believe that Work Groups are different from Release Groups and
    I feel comparing them could be misleading. Release Groups include
    different releases of a single-medium Release, which is quite
    different from what we are trying to achieve here.

    --
    Frederic Da Vitoria
    (davitof)

    Membre de l'April - « promouvoir et défendre le logiciel libre » -
    http://www.april.org

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    caramel31

    I still am not sure, do you think that Work Groups would be enough to
    handle all we need? I am asking you this because I think that as much
    as possible we should limit the number of different relations.
     
    I am not against having work-work relationships too. It works when there are a small number of related works (covers/remixes...). Now if we try to get under control the number of features...
    Let' see with other examples to stress the concept and to understand its limitations.

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Nikki-3
    In reply to this post by caramel31
    caramel wrote:
    > The proposal here is to add a workgroup level (with the parallel with
    > releasegroup). The objective of this structure is "to group":

    Unfortunately this proposal would involve changing the database schema,
    and that's unlikely to happen for quite a while (we only just released a
    huge schema change).

    I also don't really see why parent/child works can't work for this. Some
    improvements would be needed, sure, but less than implementing a whole
    new entity.

    Nikki

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Frederic Da Vitoria
    2011/6/7, Nikki <[hidden email]>:

    > caramel wrote:
    >> The proposal here is to add a workgroup level (with the parallel with
    >> releasegroup). The objective of this structure is "to group":
    >
    > Unfortunately this proposal would involve changing the database schema,
    > and that's unlikely to happen for quite a while (we only just released a
    > huge schema change).
    >
    > I also don't really see why parent/child works can't work for this. Some
    > improvements would be needed, sure, but less than implementing a whole
    > new entity.

    I am not sure caramel's suggestion would need a database modification.
    Maybe it could be implemented with Works and through ARs. The
    different "levels" of works would all be stored in the Works table and
    ARs would express the relation between main Works and sub-Works. This
    of course is quite close to parent-child Works, the main difference
    would be in the semantics. But maybe there is no real difference and
    maybe they are indeed two formulations of the same (future) feature.

    --
    Frederic Da Vitoria
    (davitof)

    Membre de l'April - « promouvoir et défendre le logiciel libre » -
    http://www.april.org

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Simon Reinhardt
    In reply to this post by caramel31
    Hi,

    If there really was a separate entity for work groups, then how would you deal with the case of several hierarchical levels?

    Using an example that was posted earlier: http://musicbrainz.org/work/b3b1e2b3-cbb8-4b46-a7d0-0031ec13492c

    Il dissoluto punito, ossia il Don Giovanni
            Ouverture. Andante - allegro molto
            Act I
                    Scene I.
                            No. 1 Introduzione "Notte e giorno faticar" (Leporello)
                    Scene II.
                            Recitativo "Leporello, ove sei?" (Don Giovanni, Leporello)
                            Recitativo "Ah del padre in periglio" (Donna Anna, Don Ottavio)
    ...

    Would only the leave nodes in the tree be work entites and all the others would be work groups? In that case work groups would have to be able to contain work groups as well as works.
    Or should we not have several levels at all?

    Regards,
       Simon

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Frederic Da Vitoria
    2011/6/7 Simon Reinhardt <[hidden email]>
    Hi,

    If there really was a separate entity for work groups, then how would you deal with the case of several hierarchical levels?

    Using an example that was posted earlier: http://musicbrainz.org/work/b3b1e2b3-cbb8-4b46-a7d0-0031ec13492c

    Il dissoluto punito, ossia il Don Giovanni
           Ouverture. Andante - allegro molto
           Act I
                   Scene I.
                           No. 1 Introduzione "Notte e giorno faticar" (Leporello)
                   Scene II.
                           Recitativo "Leporello, ove sei?" (Don Giovanni, Leporello)
                           Recitativo "Ah del padre in periglio" (Donna Anna, Don Ottavio)
    ...

    Would only the leave nodes in the tree be work entites and all the others would be work groups? In that case work groups would have to be able to contain work groups as well as works.
    Or should we not have several levels at all?

    Yes, I forgot about this, but I feel this is a good argument against implementing Work groups in a separate table. One day, a Work group (can someone think of a better name?) may be recorded as a whole (some conductor may decide to play all movements of a symphony without stopping, for example), so that the Work group would be a Work too. Now that I think of it, it has already happened. There is a release of Prokofiev's 3rd piano concerto where the variations are split in several tracks, so that we'd need to say that this movement is a Work group in order to group the variations into one movement, which itself would of course be a Work since it has also been released as a whole.

    --
    Frederic Da Vitoria
    (davitof)

    Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org


    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    symphonick
    On Tue, 07 Jun 2011 22:28:26 +0200, Frederic Da Vitoria  
    <[hidden email]> wrote:

    > Yes, I forgot about this, but I feel this is a good argument against
    > implementing Work groups in a separate table. One day, a Work group (can
    > someone think of a better name?) may be recorded as a whole (some  
    > conductor
    > may decide to play all movements of a symphony without stopping, for
    > example), so that the Work group would be a Work too. Now that I think of
    > it, it has already happened. There is a release of Prokofiev's 3rd piano
    > concerto where the variations are split in several tracks, so that we'd  
    > need
    > to say that this movement is a Work group in order to group the  
    > variations
    > into one movement, which itself would of course be a Work since it has  
    > also
    > been released as a whole.
    >

    You lost me there :-)
    Generally, IMO, what happens @ recording level has to be separated from  
    the work level. A tracksplit doesn't mean a new work by Prokofiev, & we  
    can connect several recordings to one work (& maybe use the "partial  
    performance" AR we've been discussing).

    Did you mean relating a recording to a work group won't work?

    /symphonick

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Simon Reinhardt
    In reply to this post by Frederic Da Vitoria
    Frederic Da Vitoria wrote:
    > Yes, I forgot about this, but I feel this is a good argument against implementing Work groups in a separate table. One day, a Work group (can someone think of a better name?) may be recorded as a whole (some conductor may decide to play all movements of a symphony without stopping, for example), so that the Work group would be a Work too. Now that I think of it, it has already happened. There is a release of Prokofiev's 3rd piano concerto where the variations are split in several tracks, so that we'd need to say that this movement is a Work group in order to group the variations into one movement, which itself would of course be a Work since it has also been released as a whole.

    It happens for Progressive Rock all the time. See e.g. http://musicbrainz.org/recording/183dde22-04e3-48b0-a3f3-06903e1df047 which was first recorded and released as a whole track with the parts mentioned in the booklet and then later some of the parts were performed individually live: http://musicbrainz.org/release/c3da44dc-199f-3645-8f31-1e49a747e272

    Having a separate entity for a group would mean all relationship types that can apply to works would potentially have to apply to work groups as well.

    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.

    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 (just like "relate to all recordings" there could be a "relate to all sub-works"; even if in the former case it relies on a hard-coded database link and in the latter the interface code would rely on the existance of a relationship type).

    Sorry, went a bit off on a tangent there. :-)

    Regards,
       Simon

    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Frederic Da Vitoria
    In reply to this post by symphonick
    2011/6/7 symphonick <[hidden email]>
    On Tue, 07 Jun 2011 22:28:26 +0200, Frederic Da Vitoria
    <[hidden email]> wrote:

    > Yes, I forgot about this, but I feel this is a good argument against
    > implementing Work groups in a separate table. One day, a Work group (can
    > someone think of a better name?) may be recorded as a whole (some
    > conductor
    > may decide to play all movements of a symphony without stopping, for
    > example), so that the Work group would be a Work too. Now that I think of
    > it, it has already happened. There is a release of Prokofiev's 3rd piano
    > concerto where the variations are split in several tracks, so that we'd
    > need
    > to say that this movement is a Work group in order to group the
    > variations
    > into one movement, which itself would of course be a Work since it has
    > also
    > been released as a whole.
    >

    You lost me there :-)
    Generally, IMO, what happens @ recording level has to be separated from
    the work level. A tracksplit doesn't mean a new work by Prokofiev, & we
    can connect several recordings to one work (& maybe use the "partial
    performance" AR we've been discussing).

    Did you mean relating a recording to a work group won't work?

    You mean that 1 recording can be split in n tracks? If so, yes, my example is not a good argument.

    --
    Frederic Da Vitoria
    (davitof)

    Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org


    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    RFC: Concept of works group

    caramel31
    In reply to this post by Simon Reinhardt

    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... including for classical compositions, and to link all the recordings to the unique work as "partial performance".... and most of the problems will be disappear.

    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 (just like "relate to all recordings" there could be a "relate to all sub-works"; even if in the former case it relies on a hard-coded database link and in the latter the interface code would rely on the existance of a relationship type).
    You pointed out the problem: the amount of work. Since it is not possible to use libmusicbrainz2 to add ARs or simply to modify a title, I can not write some python script to do the job and the only possibility is to use the interface that is not designed for this work.
    The second consideration is more works, titles, links we have in the database, harder it is to clean and to maintain the database (All the code writers will understand very well !) If I enter a wrong composition date (or not so precise) for all the 78 subparts of Matthew Passion, after I have to correct it again for all the 78 works entities. Hierarchical works can be a solution too not to repeat the name of the composition at the beginning of each entity title (I already had to cut titles because the track names were too long to fit in the field).
    We had the problem for the box set adding the ARs to the previous and following media. Now it is solved in the NGS. But a box set of 100 CD is exceptional. In Classical, every opera, messe, long composition is split into several CDs leading to tens of tracks and subparts even if we can group some tracks to link to a bigger work part.

    The concept of "works group" exists physically and means "Composition" or "Collection" [eg. "
    Le nozze di Figaro, ossia la folle giornata" from Mozart, "Shine On You Crazy Diamond" (9 parts) from Pink Floyd, "Mikrokosmos" (153 piano pieces but one cat #) from Bartok,  "Gymnopédies" (3) from Satie,...]

    Ok, now it is not easy to create a new physical entity in the NGS, so may be it could be set virtually using relationships, why not if it is presented simple, clear and fast to the editors through an UI...



    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    CallerNo6


    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 the problem: the amount of work...

    Is this the sort of task that could be delegated to a modified JeroenBot[1]?

    Alex / caller#6

    [1] http://wiki.musicbrainz.org/User:Jeroen




    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    Frederic Da Vitoria
    In reply to this post by caramel31
    2011/6/8 caramel <[hidden email]>

    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... including for classical compositions, and to link all the recordings to the unique work as "partial performance".... and most of the problems will be disappear.

    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 (just like "relate to all recordings" there could be a "relate to all sub-works"; even if in the former case it relies on a hard-coded database link and in the latter the interface code would rely on the existance of a relationship type).
    You pointed out the problem: the amount of work. Since it is not possible to use libmusicbrainz2 to add ARs or simply to modify a title, I can not write some python script to do the job and the only possibility is to use the interface that is not designed for this work.
    The second consideration is more works, titles, links we have in the database, harder it is to clean and to maintain the database (All the code writers will understand very well !) If I enter a wrong composition date (or not so precise) for all the 78 subparts of Matthew Passion, after I have to correct it again for all the 78 works entities. Hierarchical works can be a solution too not to repeat the name of the composition at the beginning of each entity title (I already had to cut titles because the track names were too long to fit in the field).
    We had the problem for the box set adding the ARs to the previous and following media. Now it is solved in the NGS. But a box set of 100 CD is exceptional. In Classical, every opera, messe, long composition is split into several CDs leading to tens of tracks and subparts even if we can group some tracks to link to a bigger work part.

    The concept of "works group" exists physically and means "Composition" or "Collection" [eg. "
    Le nozze di Figaro, ossia la folle giornata" from Mozart, "Shine On You Crazy Diamond" (9 parts) from Pink Floyd, "Mikrokosmos" (153 piano pieces but one cat #) from Bartok,  "Gymnopédies" (3) from Satie,...]

    Ok, now it is not easy to create a new physical entity in the NGS, so may be it could be set virtually using relationships, why not if it is presented simple, clear and fast to the editors through an UI...

    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.

    --
    Frederic Da Vitoria
    (davitof)

    Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org


    _______________________________________________
    MusicBrainz-style mailing list
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    Reply | Threaded
    Open this post in threaded view
    |

    Re: RFC: Concept of works group

    caramel31



    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
    [hidden email]
    http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
    12