Suggestion: join the WikiData and MusicBrainz databases


#1

I know that such a proposal sounds like a fantasy, like a pipe dream yet I think it’s worth considering it, at least as an exercise of imagination.

Both WikiData and MusicBrainz contain a lot of data (mainly links) about the artists (discogs, facebook, twitter, itunes, allmusic, spotify, instagram, worldcat etc). And then, to improve consistency, it would be better to have only one database - at WikiData (for the artists having a WikiData entry). And then, replicate the database at MusicBrainz, say once per month.

It would save a lot of time, since the users won’t introduce the links twice.

Some might say that the vandalism at WikiData would propagate at MusicBrainz. But that won’t be an extra vandalism, since the vandalism at MusicBrainz would not exist anymore. The vandalism at MusicBrainz will be simply replaced with the vandalism at WikiData - which is pretty much the same thing. So it won’t be an additional, increased vandalism, but it will be just a replacement - it will only change the location where the vandalism takes place.
In fact, the vandalism would be reduced, because it would take place only in one location (WikiData). At this moment, the vandalism takes place in both locations (WikiData and MusicBrainz).


#2

Wikidata people have said they don’t actually want to store all the data we have, and would much rather just have some general info and send people to MusicBrainz for things like tracklists of albums :slight_smile: So we should still keep them separate, although I’d love some sort of shared Sparql endpoint which made it possible to ask for data that combines both databases…


#3

SPARQL can theoretically be run in a federated way so you may be able to use the wikidata query service and point it to another endpoint.

There is a third party that runs an endpoint containing musicbrainz data:
http://dbtune.org/musicbrainz/

My sparql skills are limited and i was not able to get it to work but you may have better luck than me.


#4

From my observations, every day WikiData is storing more and more of the data the MusicBrainz server stores. Every day there is another proposal for adding a new property to the WikiData entries.

Of course, MusicBrainz will always have some more data about artists than WikiData - but for the information that is in common, there might be an opportunity to use a single database.

Another idea is to use “propagation” - I don’t know if there is another, established term for this:

  • when someone adds a link to MusicBrainz, then the server can use a MusicBrainz user account on the WikiData server and add the link to the WikiData database too. It would be just like a regular bot.
  • and the other way around too: when someone adds a link to WikiData, the WikiData server can use a user account made on MusicBrainz to add the link to MusicBrainz too.

That would improve a lot the consistency between the two servers.


#5

I also don’t think a real merger between the two databases is possible or desireable. Just think of release groups: MB pretty much always stores deluxe editions in the same RG, WD has a separate item for a deluxe edition if it has its own WP article.
Like that many MB entities have two WD items or the other way around.
More syngergy would be great though. At least if you link a WD item to a MB entity it would be cool if the MB ID is automatically added to the WD item.


#6

True, I was thinking about this mainly for artists. And of a partial merger. Not all artists in the MB database exist in the WD database, but for those that exist (and the kind of links they both keep), the data can be kept only on WD.

So the MusicBrainz server should run a bot on the WikiData server :slight_smile:


#7

In fact, this is something we used to do and have code for - but it seems to have stopped again. I’ll ask around.


#8

Wikidata and Wikipedia are closely related.
I don’t think we would benefit from a closer relationship with WP.
Our editor/contributor cultures are very different and it would be best if they remained so.