History talk:Next Generation Schema/Track Relationships Conversion: Difference between revisions
From MusicBrainz Wiki
Jump to navigationJump to search
BrianFreud (talk | contribs) No edit summary |
Reosarevok (talk | contribs) m (Talk:Next Generation Schema/Track Relationships Conversion moved to History talk:Next Generation Schema/Track Relationships Conversion) |
(No difference)
|
Latest revision as of 18:33, 4 November 2011
New work-work ARs to create
If we're talking about obvious ones that'll be needed, the most obvious, to me, would seem to be some way to support real "works" and opuses; ie, a 1:n "real work":works (Mozart's Requiem:movement 1, Mozart's Requiem:movement 2, etc) and opuses (a collection of "real works"). That may include lkWork entities for "real works" and opuses, rather than just work-work ARs. Additionally, the former would need some sort of attribute for optional movements, and perhaps some attribute for position within the overall "real work". BrianFreud 03:05, 6 September 2010 (UTC)
- Could you define again "lkWork"? Murdos 06:27, 6 September 2010 (UTC)
- As I understood them from the list's discussions, those were the "thingie" entities which would share an entity-space with "Works" in the database, linking the same types of things (work-work, perhaps work-other as well) but with different purposes. So I'm imagining a "Composition" pseudo-entity (ie lkWork) which would be strictly work-work and lkWork-lkWork, rather than work-recording:
- Composition (lkWork): 'Requiem in D minor, K. 626' --'has movement'--> Work (real 'Work'): I. Introitus: "Requiem aeternam"
- Composition (lkWork): 'Requiem in D minor, K. 626' --'has movement'--> Work (real 'Work'): II. "Kyrie eleison"
- Composition (lkWork): 'Requiem in D minor, K. 626 (Maunder completion)' --'is a completed version of'--> Composition (lkWork): 'Requiem in D minor, K. 626 (fragment) Fr 1791h'
- Thus, you have Works, with "parent" entity Composition (lkWorks also stored as Works), and then the one higher step from there, Opuses, also as lkWork Works; Opus being a collection of Compositions, (real) Works, and/or other Opuses:
- Opus 'Trio for Piano, Violin, and Cello No. 1 in E-flat major, Op. 1' --'has (member?) composition'--> 'No. 1 - Piano Trio'
- Composition 'No. 1 - Piano Trio' --'has movement'--> Work: I. Allegro
- Opus 'Sonata for 2 Pianos in D major, Op. 6' --'has movement'--> Work: 'I. Allegro molto'
- Opus 'Sonata for 2 Pianos in D major, Op. 6' --'has movement'--> Work: 'II. Rondo. Moderato'
- Opus 'Foo' --'has (member?) opus'--> Opus: 'Bar'
- I can't think of any example offhand for opus containing other opuses, but when I was working on clean up CSG, I recall someone - symphonik perhaps? - coming up with several such cases that needed to be worked into CSGv2 somehow. BrianFreud 18:33, 6 September 2010 (UTC)
- As I understood them from the list's discussions, those were the "thingie" entities which would share an entity-space with "Works" in the database, linking the same types of things (work-work, perhaps work-other as well) but with different purposes. So I'm imagining a "Composition" pseudo-entity (ie lkWork) which would be strictly work-work and lkWork-lkWork, rather than work-recording: