Frederic: Thank you for your ideas about this issue. It's valuable to hear a lot of different perspectives about how MusicBrainz should deal with "works".
I think you and I agree about many things. However, I have a slight disagreement with you about two points: Frederic Da Vitoria wrote: > > I believe that as Calvin pointed out, simply applying this idea to the > data > would make the data partially unusable. OTOH, very few users would be > willing to enter the level of data duplication which would be needed, so > that the data quality in classical music would become very poor because > too > many useful AR duplications would not be entered. > Let me highlight the words "would become very poor". That seems to imply that the data quality -- of Works entities with Parts relationships, and Relationships on those entities, that's the topic here -- is good now. I believe that the number of Works entities with both sub-parts and Relationships is quite small. This is because the editing tools for multi-part Works and Relationships are very poor. I entered just the child Works for one opera, and it was a very long and tedious process. Is there a way to measure how good the data is? For instance, do we have a count of how many Works have both multiple levels using the Parts Relationship, and have Relationships for things like composer? I looked for a way to test this using MB Search, and http://musicbrainz.org/doc/Text_Search_Syntax, but I couldn't find a way to looks for Relationships. I argue that the data quality, i.e. the number and importance of Relationships on Works entities which also have Parts Relationships, is poor in the MusicBrainz database right now. I base this on perceptions, not facts. Can anyone cite facts, search results, etc., to prove otherwise? If we have no proof that the data quality is currently good, then RFC-339 will either have no effect, or will make bad data bad in a different way. I believe the data quality here will remain poor until we have better editing tools, and we have to make design choices like RFC-339 before the editing tools can improve. RFC-339 won't improve the data greatly. It will just be a brick in the bridge leading to better data. We need many other bricks also. Frederic Da Vitoria wrote: > > There is a discrepancy between making input user-friendly and keeping the > data retrieval efficient... > I agree. A "distinction" might be an even better word than "discrepancy", but I understand your meaning. Frederic Da Vitoria wrote: > > 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. > As a software engineer, I do not completely agree with this statement. The database should physically make retrieval efficient /enough/ to accomplish its purpose. But design is about tradeoffs, and efficiency is not the only factor we are trying to balance. Once the retrieval is efficient enough, then other factors -- like data consistency and clarity of meaning -- should get greater weight. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Partial-Works-Relationship-Inheritance-tp6939661p6944751.html Sent from the Style discussions mailing list archive at Nabble.com. _______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
