I’m pleased to announce our upcoming schema change release on 18 May, 2015. In this release we will implement each of the tickets listed in this fix version:
- MBS-1347: Implement aliases for release groups, releases and recordings.
- MBS-4145: Up/down vote for tags — This feature will be our first attempt at getting into “genres”. People have expressed that our tags are vaguely useful for genres, but expressed frustration at not being able to give feedback about the tags. Voting on tags will allow us to find the tags that people find useful, which will allow us to develop a list of tags that we consider to be “genres”.
- MBS-7489: Artist Credits for Relationships — This feature will allow MusicBrainz to store an alternate artist display name (Artist Credit) for a given credit (Advanced Relationship).
- MBS-8266: Make medium titles VARCHAR NOT NULL — Fixes a database inconsistency that should have little to no impact on end users.
- MBS-8279: Remove empty_artists etc. database functions — Another database/code refactoring that should also have little impact on end users.
- MBS-8283: Remove DB constraint that disallows empty event names — This allows event names to be blank, since many events do not have a proper name.
- MBS-8287: Log deleted entities that were in a subscribed collection — This feature will give users a notification if one of their subscribed entities is deleted.
- MBS-8302: Add Live Data Feed access token support — Add support for using access tokens. See below for more details.
UPDATE: We forgot to list the following change, which is already almost ready to go – apologies for the slightly late addition!
UPDATE 2: This change will not affect users of our replicated data at all, since the changes are to non-replicated tables. This is the only reason we decided to sneak this change in after the official announcement.
- MBS-8004: Extend collections to other entities — This extends the current ability to create collections (user-made lists) to other entities apart from releases and events. That means users can make arbitrary lists (“Artists I’ve seen live”, or “Songs I can play on the piano”), and also subscribe to them to get notified when anything on the collection is being edited.
Finally, I’m not describing MBS-8278, since that is an internal housekeeping reminder and will not really affect downstream users. All in all this is fairly light schema change for us, since we currently have a number of other projects that we wish to undertake in the medium term.
Important Live Data Feed change: After 10+ years of our Live Data Feed being available to anyone on the honor system, we are going to require Live Data Feed users to have an access token to fetch the replication packets for the Live Data Feed.
At the beginning of May we are going to release a new MetaBrainz web-site that will allow all of our current Live Data Feed users to create an account and to generate themselves an access token. Non-commercial users and existing commercial users will be immediately approved and will receive an access token. This access token will need to be add to your MusicBrainz-server (or mbslave) configuration in order for the Live Data Feed to continue to work as expected. Any new commercial users will need to sign up to one of the support tiers that the new web-site will present.
NB: If you are currently using the Live Data Feed legitimately, you should see no disruption to your use of the feed.
MetaBrainz Blog 
How can I be sure that I currently use the Live Data Feed legitimately?
What will change for me as a (private) user of your “MusicBrainz Server Virtual Machine” with sporadic manual download of your replication packets (using “bin/replicate now”)?
Are you running a business with the Live Data Feed data? If no, you’re in the clear.
You’ll need to log into the new MetaBrainz site, state that you are non-commercial and you will be given an access token. Enter that access token into your configuration and that is it.
What constitutes running a business with the data here? For instance, if I was to sell an app that looks up MB data, and wanted to provide a mirror so that it isn’t rate-limited, would that count?
Also, will there be a grace period between provision of the sign-up server, and requirement of the token?
I presume there will be another post to notify users when the sign-up server goes live?
If there is a fee for the app, then yes that is commercial use.
People will have 2 weeks from when the site goes live until the token is required. And yes, there will be plenty more blog posts.
MBS-4145’s goal is mis-stated here — it’s not about specifying which tags are genres or not, but about allowing better management of tags on a particular entity. At present tags function only by a (very implicit and somewhat hidden) up-vote system: if you tag an entity the same thing as someone else did, then the count of people who tagged it that way is incremented, and your tag can be removed. MBS-4145 intends to both add a way to “vote against”/down-vote a tag as a user, and to improve the interface so the existing sort of “upvote” is less hidden and obviously the opposite of the newly-supported bit (and the “remove your vote” option is more clearly intermediate between the two). This way tags can actually be properly collaborated on, which applies to more than genres, e.g. the common ‘fixme’ tag problem where once fixed the tag remains until the original tagging editor(s) come back and deem it finished; after this change, those who fixed it could simply downvote the tag themselves.
Non-schema-change related (and thus further afield) details:
As far as moving toward a more useful genre system built on tags, some extra bits will be needed, but they aren’t schema changes. Specifically, an assertion of which tags should be considered genres (initially, in code — if useful and once refined, it can at a later schema change be moved into a database table) and a way of collating tags into a useful summary of an entity’s genre (where the initial proposal is, if I can state it clearly: for all tags specified to be genres by the aforementioned list, for a given entity, call the sum of their votes (+1 per upvote, -1 per downvote) A and each tag’s number of votes B, C, etc., ordered in descending order of number of votes (equal numbers in arbitrary order). Some sum of B + C + D + … corresponds to the closest sum greater than or equal to A/2 — say that the last entry in that sum is N. Given this, include in the summary every genre-designated tag whose number of votes is N or more. In practice, this’d mean if an entity has e.g. 1 vote for rock, 1 for hip-hop, 1 for metal, all three would be included (A = 3, A/2 = 1.5, first sum is A+B=2, B=1, include all tags >= 1 vote); with 2, 1, 1 only rock would be (A=4, A/2=2, first sum is A alone = 2, A=2, include all tags >= 2 votes); with 2, 2, 1 rock and hip-hop would be included (A=5, A/2=2.5, first sum is A+B=4, B=2, include all tags >= 2 votes); etc.).
Excellent, thank you so much for implementing the pen‐names ticket MBS-7489, woohoo we will be able to merge those artists for the betetr while keeping their names of choice ! 🙂
the idea that MBS-7489, is might finally be worked on makes me a very happy kitty. expect Norwegian chocolate!
The blog post has been updated to include another ticket (MBS-8004) that was missing from the first version.
So glad I subscribed to this blog 🙂
Incredible ongoing work and organisation by a non-profit… admirable. MBS-7489 is going to be a real treat, same with genre tags coming towards the horizon, as last.fm continues to fade away MB can fill yet another space!
Will the style guidelines – especially https://musicbrainz.org/doc/Style/Artist/With_multiple_names be updated to prevent the potential edit war between “guidelines say separate artists” and “artist credits allow merging them”?
Yes, that’s already an open style ticket and I’ll definitely be looking into it soon given this change 🙂