On 07/02/2012 20:20, Nicolás Tamargo de Eguren wrote: > > We're expecting to have a summit during 2012 in which we (well, "we" > as in MusicBrainz + BBC + a few more people, I doubt I'll be there) > will try to work on a good way to do classical in databases, see > http://wiki.musicbrainz.org/MusicBrainz_Summit/2012_Mini-Summit/Notes#Classical_schema_summit_.28contributors_from:_Last.fm.2C_Naxos.3F.2C_Universal.2C_BBC.2C_IMSLP.3F.29 > > So if we can't right now reach any good decision on how to fix this > (and it looks that way to me), it'd make sense to instead make a few > proposals that we think would be the best way to represent this data > (not necessarily based on current UI, if UI is what blocks the best > options) for them to be evaluated and built upon on said summit. Also, > it'd be great if people gave some thorough examples of how they would > expect their classical to be tagged - to see how we could process the > data to make that possible. And please, please, please, let's compile > a list of edge cases as hard and strange as you can get, too - just > put it somewhere in the wiki I guess :) > > Speaking of which, we would need a representative of the community for > those talks. I was thinking symphonick or rswabrick or monxton maybe, > but that's something the community should clearly have a say on.
These are very hard problems to solve, as this debate is demonstrating. I'm seeing a lot of plunging into detail when we are a long way from consensus on what is a "good" outcome. This summit may be a good thing, but I am concerned that the interests of these big and wealthy consumers of the data may not always align with the community that produces the data, or at least that their priorities are different. Here are my current two-penn'orth: - People are saying that incremental change is good, and I agree. Each incremental style change tends to make migration more difficult however, and we should consider this as a factor when making these changes. - Wasn't one of the key propositions for NGS the elimination of special formatting in a text field to represent structured data? I'm quite sad to see proposals which include introducing such things. - There's lots of heated debate about Artist Credit, but we already have the mechanism for including that data in ARs. Some people are dismissing those because they are too difficult to edit. So the problem we should be tackling is the editor. If all this information is added to the AC, is that a tacit agreement that ARs are not going be used? Duplicating data is generally a Bad Thing. - I've mentioned before that ARs and ACs are not symmetrical, because ARs have a role (e.g. conductor, cello ...) and ACs do not. I like to see the role. Conversely, ACs have performance credits and ARs do not, for example the AC could be for Stephen Bishop or Stephen Kovacevich, or Stephen Bishop-Kovacevich, but the AR can only be for Stephen Kovacevich. I'd like to see this limitation removed. - At the simplest level, I really want my music player to tell me that I am listening to Beethoven, not to the performers (though I'd like to know who they are). This is perhaps the USP that brought me to MBz in the first place. For non-classical music, I want the opposite. I'm reluctantly coming round to the idea that we're going to need a "style" field, which may be CSG, popular or maybe others, that the taggers can employ. _______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
