About the whole Wikidata / Wikipedia situation

Tags: #<Tag:0x00007fe3cfccd160> #<Tag:0x00007fe3cfcccfd0>


All of this can be achieved with a WD to WP feature MBS-9771 in the sidebar.

And WD pages will always be maintained remotely.
I have had enough WP page rot in my MB editing life to fully support the move to WD while keeping up to date WP links dynamically displayed in the sidebar.


My point is about the MusicBrainz database rather than the MusicBrainz website, it would be useful if the wikipedia urls were stored in the database.


  1. I have to use the wikipedia script as user requires meaning which can cause unacceptable lookup delays similar to the problems with the AcousticBrainz Api.


  1. I have to run script over complete database and store the results, however log that will take.

That is just my situation, but my point is that MusicBrainz decision causes hassle for most using Musicbrainz and interested in Wikipedia, it only benefits MusicBrainz editors who have the occasional dead wikipedia link. Therefore it seems to have been done mainly for the benefit of MusicBrainz editors rather than MusicBrainz users.


I’m a MB editor because I’m a MB user.
I’m here to manage my humble collection, mostly and to discover stuff that could be linked to what I like.
So I’m an editor just because I want to add my CD in my collection, add missing things and fix things.
The links in the sidebar, I am glad to have them dynamically up to date as a user.
I am glad to have all available WP pages in languages I want rather than only those added by editors (in most cases, only English).


Oh but I see, you mean users as in remote users, taggers, etc.
In that perspective, yes indeed, MB will give them the best available reference: WD.
From that reference, you will, as @paulakreuzer explained, retrieve all the current WP pages, that are available at that time.


As I explained, it is too slow having to make these extra calls to wikipedia really.


It’s “only” one extra call to Wikidata that gives you all WP pages at once.
But I understand that it still takes more time…
But moreover, having scripts in all possible ways making various parallel calls to this and that when I browse pages, it doesn’t change much and I think WD is built strong to be able to handle lots of calls to its API. Probably stronger than MB.


To illustrate that it is fast, when I load an MB artist page, the artist photo (that also comes from Wikidata or something like that) usually finishes loading after my WD to WP feature in the sidebar.


Its fine if you are just looking up one thing, but if fixing thousands of files it does have an impact or total time, especially if have slow internet connection.


My evidence is fixing multiple thousands of these over a one year period a few years back, before we decided that it was way too annoying and Wikidata is better.

Wikidata has a lower requirement for notability, so if the Wikidata page still links to, say, entries in library catalogs and has some extra info, it’s more likely to not get removed. If there’s no info though I would expect the page to get removed too :slight_smile:

Anyway, I do see the issues with the Wikidata extra query - I wonder if there’d be some way to at least cache a link MB-side and serve it when requested, since we’re already loading them for page loads as it is…


THIS ^^^

The Wikipedia info is being loaded for the Artist page. So please just sneak it into the right hand side links for the noobie idiots like me who have never heard of Wikidata.

Make this place as inclusive as possible. :slight_smile:


I agree. :+1:

I don’t think this kind of language is the way to achieve that. :wink:


I was meaning people like me who had never heard of WD before this conversation (even though I am an old git on the interwebs).

I’ll tweak the words to be more accurate - lolz.



Who gave you the OK to delete Wikipedia-URLs including the english one?

You start a topic here and don’t wait to reach an concensus?
Actually you have over 2’270 open “remove relationsship edits”.

Do I really have to down-vote them all manually until we reach an acceptable solution? With acceptable I mean, a solution that doesn’t only fits your idea?

Of course you can add as much Wikidata links you like, but there is no official policy so far that prohibits Wikipedia-Links. So please stop deleting them!


There’s no consensus to reach - removing Wikipedia links is fine (that’s the official MusicBrainz position), and these edits should not be voted down.

If we want those links in the sidebar they should be autogenerated from Wikidata. That’s something that can be talked about and we can ask the dev team to implement it. They should not be stored separately risking them to become outdated.

That said, I feel removing them by hand is kind of a waste of time, honestly, since eventually they’ll just be bot-removed anyway.


You say: First we delete all Wikipedia-Links (“risking them to become outdated”) and maybe - in 5 years or never - we will autogenerate them from Wikidata?

Is this the new way on MB? First to delete visible data (which at least some of us like to see) and hope that no one will ever insists?

And BTW: If that’s the (new) official MusicBrainz position please adjust all the style guides accordingly and
as fast as possible.


The position is that people can add them, but if there’s a Wikidata link present there’s no reason they need to be kept. So nobody should vote No if someone adds one, but if someone has checked the WD link is present, they can be removed.

The only reason we haven’t done much in the way of guidelines about this interim period is that originally the idea was to get rid of all of them automatically in around 6 months (from the blog post announcement) - when that didn’t happen because nobody had the time, we got stuck with this in-between situation. But the goal is still very much to remove them.

The links are already being generated, and already linked from the overview page. If we want to show them on the sidebar too, that takes a developer around 20 minutes of coding max, and it’s not a reason to block the already decided removal - because no data is being lost with it.


That phrase captures and expresses my level of technical expertise pretty well - I am like a tech deficient goldfish - one more circle of the goldfish bowl and everything is new and unfamiliar.

Scripts? LOL
Modify the INI file of a plugin? Hohoho.

And here is the bad part - I am more tech capable than say 90 % of the globe’s population. Or and least I am silly enough to think so.


@InvisibleMan78 now that you heard from a MB style leader that my edit is not against the guidelines could you please revert your no-vote on it? Thanks.

@all: I rewrote my suggestion in STYLE-1003 to better reflect that adding Wikipedia links is fine and to include that removing/replacing them is accepted too.

Since the decision that they should be removed is 3 years old and a bot-solution doesn’t seem any closer now than it did then I think manually removing them is a viable thing to do. I’d say I removed about 15% of WP links already and by doing that I raised awareness and lots of people now add WD links instead of WP links.
I would also prefer if a bot did it, but a bot might not find errors as easily as I do. I’m also fixing some errors on the WD side along the way - I doubt a MB bot could do that.
Also I like to have a monotonous task I can do while e.g. watching TV or tanning. Before this I moved featured artists from titles to the artist credits, but I’m pretty much done with that for hip hop.


I’ll tag this question on here instead of making a new thread.

Why does the Wikidata link on the right hand side of the page get a title of an ID number instead of “Wikidata” like all the other links?
I refer to my previous points that a large majority of people don’t recognise that Wikidata logo. If it at least said Wikidata instead of Q909006 then it would let those who are unaware of Wikidata click on it as it sounds Wikipedia like.

It would also be more consistent with all the other external links that name the website they are heading for and not some obscure meaningless number. :slight_smile:


To be fair, we also have US: B0017PCMX0 for Amazon and VIAF: 12304462 for VIAF. Which suggests a middle ground here could be Wikidata: Q909006. I would like to keep the Q ID (because it’s the basis of Wikidata and quite important if you care about Wikidata as a user) but I agree it’s sadly not yet obvious to everyone how the Wikidata logo looks like and what it is :slight_smile:


I guess Wikidata: Item/Artist Name (Q-ID) would be too long?


This would be better. It would also help people get to associate the wiggly line logo with Wikidata.

I can see why some people would need that ID number to be easily readable on the page. We always need to balance the need of the geek with the needs of the public. Wave something recognisable at them and it is more likely to be clicked.

If the Wikidata title is added to the icon then at least the new users can look up what Wikidata is and therefore more likely to add those links themselves.

And a side question. Any chance someone who understands Wikidata could update the MB help page a bit? Currently there is no explanation there as to how to get from Wikidata to Wikipedia. Or how to find a Wikidata page to add it to MB. Some good little nuggets of explanation in these forum threads that should be added to the help page.