ZaziLevel1Comments

18:39 to the RecordSession event: because of the existing compositing of events, we may don't need an extra class and can re-use the Recording class and just label a the "parent" Recording instance as "record session" 19:28 I think I got the problem (maybe) - don't be confused - here a my latest ideas described in short comments 19:30 a RecordSession is an event that fetches Recordings for a SignalGroup for a set of Movements (uses as abstract representation for a song/track) 19:30 (I'm not really shure, wether this event is maybe obsolete) 19:32 a SignalGroup is a set of produced songs that means it holds a set of Signal that derived from the related MusicalWork (as the abstract representation for an album/ set of songs) 19:33 therefore is has also the property musicalWork, which relates the SignalGroup to its MusicalWork instance 19:34 a Release event has the time and place of a "release" of a SignalGroup that means the SignalGroup is the input factor of this Release event and the products are one or more RecordPackages 19:35 a RecordPackage has the properties record(s), recordCount and maybe also coverart, libretto etc. 19:37 so it is the container that has one or more records 19:37 so we can keep the Record concept and the Track concept 19:38 and we have now a signal/track mapping (as it exists already) 19:39 so we can map every Signal from a SignalGroup to a Track instance that is part of a Record of a specific medium 19:41 we should re-design the available_as and add it to the Release, so that we know, which ReleaseType are available 19:47 so I hope my opinion is now more in common with yvesr (because of keeping the Record concept as it is)