2012/2/9 monxton <musicbra...@jordan-maynard.org> > 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. > > Yup. I had (approximately) "as printed" & "most highlighted performer first" & "top to bottom" in previous versions, but I assume we have to introduce a second delimiter if you want to tag by composer and we only have one field for artists (performers and composer).
> - 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. > > No, a future solution should definitely be based on ARs IMO. Then we can search for roles, for example. These suggestions is about making use of the current UI, not about going back to pre-AR MB. Some of the limitations of the artist fields (only one artist possible or create a new collaboration artist) were removed in NGS, so I want to update the guidelines to reflect this. But the artist concept just doesn't fit classical, and I'm hoping for a solution eventually where you can enter all ARs when entering a release, and the artist fields will get populated automatically. But we still need to decide what data these fields should contain. - 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. > > In that case you can't really avoid duplicating data, can you? You need an alias for this performer at release level. > - 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. > > That can be done without breaking searching if we put performers as recording artist and the composer as track artist. Or try a "CSG" genre & some scripting in Picard? /symphonick
_______________________________________________ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
