> > A related thing that might fit here as it is also somehow an > inheritance issue: there's still not a firm guideline for whether the > work type (e.g. "symphony") should be set only for the full work or > also for its parts / movements. I am pretty much on favour of using it > only for full works, but what do other people think?
This is a perfect example as to why we need inheritance and this should only be stored at the super-work level. I know personally, I've followed this guideline when adding new works. In any case, there's so many work types missing that I actually seldom use that field, but that's another discussion ;) ... I was also thinking about this inheritance concept dicussued here. The same inheritance could perhaps be used for Release Group -> Release (IE Wikipedia URLs, other RG Level ARs). And also, perhaps also from Release Level -> Recordings (Essentially removing the really confusing distinction between a release-level AR and a Track-level AR that applies to all tracks in a release. The Release-level AR would therefore become more useful and could be used to simplify AR addition/editing. Sebastien 2011/11/1 Nicolás Tamargo de Eguren <reosare...@gmail.com> > A related thing that might fit here as it is also somehow an > inheritance issue: there's still not a firm guideline for whether the > work type (e.g. "symphony") should be set only for the full work or > also for its parts / movements. I am pretty much on favour of using it > only for full works, but what do other people think? > > On Tue, Nov 1, 2011 at 12:02 AM, Frederic Da Vitoria > <davito...@gmail.com> wrote: > > 2011/10/30 Rupert Swarbrick <rswarbr...@gmail.com> > >> > >> Frederic Da Vitoria <davito...@gmail.com> > >> writes: > >> > There is a discrepancy between making input user-friendly and keeping > >> > the > >> > data retrieval efficient. I believe that since data retrieval is after > >> > all > >> > the justification of data entry, then the database should physically > >> > make > >> > retrieval as efficient as possible, which means that ARs should be > >> > duplicated. The input interface should simplify this duplication so > that > >> > the editing user would have the impression that the data is stored in > a > >> > hierarchical manner although the user's edits will end up being > >> > duplicated. > >> > So, as Calvin suggested, I think that the best way is to implement a > >> > smart > >> > input interface. > >> > >> Surely this is a decision one doesn't have to make. Can't ARs be stored > >> in the database with a flag saying whether they were created > >> automatically as a result of inheritance? In that case, you'd solve the > >> problem of retrieval speed but also keep the semantic flexibility that > >> Calvin is arguing for. > > > > I like this idea. > > > > -- > > Frederic Da Vitoria > > (davitof) > > > > Membre de l'April - « promouvoir et défendre le logiciel libre » - > > http://www.april.org > > > > > > _______________________________________________ > > MusicBrainz-style mailing list > > MusicBrainz-style@lists.musicbrainz.org > > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style > > > > > > -- > Nicolás Tamargo de Eguren > > _______________________________________________ > MusicBrainz-style mailing list > MusicBrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style >
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
