Open main menu

Wikidata:Project chat

(Redirected from Wikidata:Project chat/bjn)

Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Requests for deletions can be made here. Merging instructions can be found here.
IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2019/02.


Q57879255: shouldn't items about the same topic or same name be merged?Edit

Recently somebody keeps demerging Q57879255 into different items (including Q174098, Q57878989, Q57879426 and Q61057659). I've checked the 9 entries (bar:Nationalpolizei, ca:Policia Nacional, de:Nationalpolizei, en:National police, es:Policía Nacional, fr:Police nationale, ja:国家警察, pt:Polícia Nacional and zh:國家警察) merged into Q57879255, and I've found that all of the 9 entries are disambiguation pages (Wikimedia disambiguation page (Q4167410)) about the exact same topic (National police, translated into several languages including German, France, Spanish, Portuguese, Japanese and Chinese language). Is there anything wrong to merge items with the exact same topic? Why should these entries be split into different items? --Howard61313 (talk) 14:38, 29 January 2019 (UTC)

@Howard61313 : Generally speaking, I have to say I think it's good practise to split them up and using "said to be the same as" to interlink where appropriate - same as we do for given names and family names. The reason being there are other items, like (titles of) books, films, band names, night clubs, fashion brands, etc. that might need to be "different from" one language disambiguation page but not the others. Moebeus (talk) 15:57, 29 January 2019 (UTC)
@Moebeus: These are not the most appropriate examples here, "national police" is not like the name of works or people, but government agencies shared by several countries instead. The example of Q20901295 (Ministry of Foreign Affairs) would be better, which doesn't need to be "different from" other pages although they have different ways to be referred to in different languages, for example, "Außenministerium" (roughly "Ministry of the Exterior" in German) and "Ministério das Relações Exteriores" (roughly "Ministry for Foreign Relations" in Portuguese) are called differently in their respective languages, but they're still the same thing as "Ministry of Foreign Affairs". Instead of "said to be the same as", they're "already the same as".--Howard61313 (talk) 04:02, 30 January 2019 (UTC)
They are all different items: the french page is a list, all the other page are disambiguation, but all these disambiguation have different spelling so they are different disambiguation that we must keep separated. If next time you ping me I can answer more quickly --ValterVB (talk) 18:17, 29 January 2019 (UTC)
@ValterVB: They are all the same items, for Christ's sake. The French page is a "page d’homonymie " (disambiguation page) instead of a list, didn't you read it on the top of the page? And different spelling in different languages doesn't make things different. For example, Police nationale (France) on fr.wikipedia is exactly the same as National Police (France) on en.wikipedia and Policía Nacional (Francia) on es.wikipedia, which are all referring to the national police force of France. By the way, your reason doesn't justify your act to split 国家警察 on ja.wikipedia and 國家警察 on zh.wikipedia into different items, which are both disambiguation pages about national police, even written in almost the same way with Han characters ("Hànzì" in Chinese/"Kanji" in Japanese. By the way, this is another good case showing that different spelling makes the same topic, which are not separated. Another good example can be seen above, concerning "Ministry of Foreign Affairs" in different languages. The difference between the spelling of "Außenministerium" and "Ministério das Relações Exteriores" is even larger than the difference between "National police", "Nationalpolizei", "Police nationale" and "Policia Nacional"!) And this act doesn't justify your edition to remove labels in other languages as well (for example, "Polis Kebangsaan" in Malay, "Cảnh sát Quốc gia" in Vietnamese and "국가경찰" in Korean, which are all corresponding translations for "national police". There's no point to remove them).--Howard61313 (talk) 03:44, 30 January 2019 (UTC)
See Wikidata:WikiProject Disambiguation pages/guidelines, and discussions on its Talk page. Ghouston (talk) 05:06, 30 January 2019 (UTC)
Disambiguation pages aren't about a topic but about multiple separate topics that have the same name. As a result, we merge Disambiguation pages when they have the same name and not by topic (by definition each Disambiguation page is about more then one topic). You could create a redirect ":en:Nationalpolizei" that points to ":en:National police" and link that ":en:Nationalpolizei" item from the same item as ":de:Nationalpolizei". This redirect creation at the moment isn't as comfortable as possible but it gives you interwiki-links if your intention is to have interwiki-links on the corresponding Wikipedia pages. ChristianKl❫ 11:00, 30 January 2019 (UTC)
Thank you for correcting my words. Compare to "same topic", now I think that "same name" is more appropriate for the case of "national police" (which are disambiguation pages for police forces in several countries that can be translated as "national police" from their respective languages).--Howard61313 (talk) 04:22, 31 January 2019 (UTC)

Sorry for late replay, I was busy in RL.
The page in French is not a page of disambiguation, in fact you can not find it in fr:Spécial: DisambiguationPage. it is more like a "(en) set index" page where the meaning of words is crucial. All the other pages are, instead, real disambiguation page, the meaning is irrelevant.
The rules for the disambiguations are clear: the only thing that matters is the spelling, the meaning is irrelevant, so if the spelling is different, different elements will be created.
For different alphabets there is not a precise rule, normally it is linked to the English one because it's the biggest wiki and it's normally done this way, if I have separated Chinese and Japanese it was a mistake but with all the movements you did it is difficult to reconstruct how the elements were before.
Now I restore the situation to before your changes. If you want to change the situation first look for consent then you can make that kind of changes. --ValterVB (talk) 09:38, 1 February 2019 (UTC)

Not only fr:Police nationale, nothing can't be found in fr:Spécial: DisambiguationPage as we speak. Anyway, the page is categorized under fr:Catégorie:Homonymie (corresponding page for en:Category:Disambiguation pages) with a template called fr:Modèle:Internationalisation on the top, which is set for disambiguation pages. I think that there's no doubt that the page is a disambiguous one. Besides, the precedent of Q20901295 (Ministry of Foreign Affairs) and Q223603 (Republican Party, differently spelled as "Republikanische Partei" "Parti républicain", etc.) already justified that interlanguage link between disambiguation pages concerning organizations can be existed based on their meaning instead of the consistency on spelling. I'm sorry that I just don't see why the reasons you mentioned can ever stop the interlanguage link between them, and those reasons didn't justify why labels in other languages (for example, "Cảnh sát Quốc gia" in Vietnamese and "국가경찰" in Korean) should be removed.--Howard61313 (talk) 06:13, 8 February 2019 (UTC)
There's a slight typo in the link. You'll get the correct link if you lose the blank space after Spécial: i.e. fr:Spécial:DisambiguationPages. Then again that page is capped to only list 10,000 pages and fr:Police nationale isn't one of them, so I guess it doesn't really matter... Tommy Kronkvist (talk), 07:40, 8 February 2019 (UTC).
There're 130,247 pages contained in fr:Catégorie:Homonymie, and fr:Police nationale is one of them. It's obvious that fr:Spécial:DisambiguationPages contains only a part of all disambiguation pages on fr.wikipedia.--Howard61313 (talk) 11:49, 10 February 2019 (UTC)
No,fr:Police nationale isn't in fr:Catégorie:Homonymie because it isn't a disambiguation. Maybe isn't clear what is a disambiguation page for mediawiki software. I suggest you to read mw:Extension:Disambiguator and Wikidata:WikiProject Disambiguation pages/guidelines and stop to revert, until you don't understand this simple rules used in Wikidata. --ValterVB (talk) 17:03, 13 February 2019 (UTC)
The reason you provide didn't persuade. It's indeed in fr:Catégorie:Homonymie, see here for Christ's sake. Besides, different spelling, which is a weak reason in this case, can't stop interwiki-links between items with the same meaning, otherwise precedents like Q353135, Q20901295, Q223603 wouldn't have been existed. I strongly suggest you to stop blocking interlinks based on irrelevant grounds. --Howard61313 (talk) 12:37, 15 February 2019 (UTC)

Expanding what a property can be used on?Edit

I opened a discussion on Wikidata talk:WikiProject Video games but didn't get a response, so I figured I'd ask here. How does one go about expanding the types of Wikidata items a property can be used to cover? I'd like to expand PCGamingWiki ID (P6337) to include game engines, game series', and companies. How should I propose that? Should these be under the same property or should they be new properties?

Thanks, Nicereddy (talk)

In general, is there some consensus/guideline on whether it is better to have “wide” or “narrow” properties? To stay in the topic of video games, sometimes we have several narrow properties for one source website (eg 4 properties for Linux Game Database (Q56462477) or GameFAQs (Q693757), 5 for MobyGames (Q612975)…), sometimes one wide property for one source website (Giant Bomb ID (P5247) covers 10 different concepts, Metacritic ID (P1712) 5 concepts…)
Some of the downsides of “wide” properties, in my view, are harder to make and less-actionable property constraints (having tried to clean-up P5247 constraint violations, it’s a bit of a pain ^_^), but I guess that’s not necessarily a good argument. The downside of narrow properties is a proliferation of properties, but I wonder how frowned-upon that actually is (or the opposite).
Has there been previous discussions on that topic?
Jean-Fred (talk) 08:46, 8 February 2019 (UTC)
I guess the problems with constraints for Giant Bomb ID (P5247) might be because of me to quite some extent, since I've been adding lots of IDs from Giant Bomb while working my way through various franchises, including characters, locations, concepts and objects. The latter two categories include such a vast array of topics that it's probably very difficult to come up with fitting class constraints.
In general, I think in the past, properties were often created with a broader scope (like IMDb ID (P345) for films, people, companies and characters). But more recently, creating separate properties for the same external source instead seems to be preferred. Depends of course on how the source is structured, sometimes it's unfeasible or doesn't provide an advantage. I think it's most often done when there's no real ID and a part of the URL is used instead. When it's the same kind of ID with the same formatter URL for all types of topics, then usually only one property is used. With Giant Bomb ID (P5247) and its cousin Comic Vine ID (P5905), only two digits in the ID differ for different types of topics (character, work, person, etc.), while the formatter URL is the same. So in theory you could separate them into a handful of distinct properties (games, franchises, companies, people, characters, locations, concepts and objects). But maybe complex constraint might also do the trick instead. --Kam Solusar (talk) 22:19, 11 February 2019 (UTC)
@Kam Solusar: For PCGamingWiki specifically the URLs are all$1, where $1 is “Half-Life” or “Series:Half-Life”, or “Company:Valve”. So series, companies, and engines have different but similar URLs. Would you say that’d fit better as a generic property or various specific properties? Nicereddy (talk)
@Nicereddy:: Personally, I lean a bit towards creating separate properties - even though there's no strict technical need for it. Something else worth considering: PCGamingWiki uses MediaWiki (Q83), just like Wikipedia, which means every page has a stable Page ID: Half-Life (Q279744)467. That ID doesn't change when a page is moved/renamed, so it would require less maintenance. --Kam Solusar (talk) 09:25, 14 February 2019 (UTC)
@Kam Solusar: I think there's an argument to be made for ease of adding the PCGW ID to a Wikidata item. Similarly, I'm fairly certain only keeps the page at the full-name URL rather than the MediaWiki ID, so there's also that downside to consider. Ideally it'd be a perfectly stable ID, but I'm not sure the benefits outweigh the drawbacks.
Regarding the separate IDs/monolith ID, it seems like there's not a solid consensus on this. I lean toward a monolithic ID just because that'd be easier to get started with than needing to open 3 new property proposals, plus the IDs are similar enough that it shouldn't matter RE: URL formatting, although it would have the downside of requiring the user to add, e.g. "Company:" at the start of every company ID. Nicereddy (talk) 20:02, 15 February 2019 (UTC)
I’d lean towards having 3 additional properties as well ; but I can go either way.
Regarding MediaWiki IDs: when creating Wikidata:Property_proposal/RegiowikiAT_ID, I had a look through all MediaWiki-powered properties, and using the Page title was the most common case.
Jean-Fred (talk) 20:19, 17 February 2019 (UTC)

Wikidata used by Jura1, MisterSynergy, Succu, Mahir256 as a tool to spread fake informationEdit

The current label for Property:P2580 is "Baltisches Biographisches Lexikon Digital ID (former scheme)".

  1. The name "Baltisches Biographisches Lexikon Digital ID" has never been used by the BBLD nor any other source, prior to Wikidata editors making it up
  2. The claim "(former scheme)" as part of the name has never been used by the BBLD nor any other source, prior to User:MisterSynergy making it up 2019-01-04 [1]
  3. The claim "(former scheme)" as part of the description for the ID has never been used by the BBLD nor any other source, prior to User:Jura1 making it up 2018-09-12 [2]
  4. "[A-Za-z0-9][-.0-9A-Za-z]+" reference URL - The stated reference URL returns 404, and that regex has never been used by the BBLD nor any other source, prior to Wikidata editors making it up.

The two most recent insertions of fake information are by User:Succu [3] and User:Mahir256 [4], the latter invoked by Jura1 at the Admininistrators' noticeboard [5]

The authoritative and primary source is stating

  1. name = "BBLD ID" and
  2. regex = "/^[A-Z0-9][-.0-9A-Za-z]{1,62}[.0-9Xa-z]$/".

There is no credible secondary source for these IDs.

The users that inserted the fake information or helped to keep it all have more than 1 million edits on, two are admins, one a rollbacker and propertycreator:

In a recent discussion in the project chat (Wikidata:Project_chat/Archive/2019/01#BBLD claims Wikidata contains false info) 2019-01-19 User:Strobilomyces wrote:

"These parenthetic comments do not come from the BBLD and have now been removed. So as long as those changes are OK, I think that the allegation in the link that Wikimedia is spreading false information about the BBLD should now be answered." That was only true for seven more days.

User:Jura1 has not been editing for 18 days [6] and on resume the second edit with the edit summary "Vandalism" was statement including a libelous claim about IP contributors ("problem IPs") and using that to have the fake information restored and protected.

User:Mahir256 protected the property page [7] and the property talk page [8].

Additionally the rights to edit the values have been taken away for IPs in 2018.

What can be done to correct the information and prevent users from re-adding and protect fake information? 17:34, 6 February 2019 (UTC)

I guess blocking this IP would be a good start.--Ymblanter (talk) 21:49, 6 February 2019 (UTC)
For the people new here, let me introduce the user known as Tobias Conradi here also known as Tamawashi. His modus operandi: Contribute from an Telefónica Deutschland (Q2401561) ipaddress. Usually quite constructive for a while and at some point the user derails completely and starts attacking people. We seem to be at this point now. Looks like it's time for some blocks. Multichill (talk) 21:59, 6 February 2019 (UTC)
Content at de:Baltisches Biographisches Lexikon Digital is not trustable. --Succu (talk)
FWIW forwarded to dewiki talk BHK, but as we know they do tolerate obscure (student) fraternities and similar topics. 15:58, 13 February 2019 (UTC)
Uhps: de:Diskussion:Baltisches_Biographisches_Lexikon_Digital#Vandalismus durch Benutzer:Succu. --Succu (talk) 22:23, 13 February 2019 (UTC)
  • Maybe we should delete the existing property as well: even the website thinks the globally banned user had swamped us with fake information. ISNI is generally available anyways. --- Jura 17:31, 15 February 2019 (UTC)

MWAPI against de.wikipedia.orgEdit

The following is working:

    SERVICE wikibase:mwapi {
     bd:serviceParam wikibase:api "Categories" .
     bd:serviceParam wikibase:endpoint "" .
     bd:serviceParam mwapi:titles "Albert Einstein" .
     ?cat wikibase:apiOutput mwapi:category .

Try it!

The following is not working (or at least unstable):

    SERVICE wikibase:mwapi {
     bd:serviceParam wikibase:api "Categories" .
     bd:serviceParam wikibase:endpoint "" .
     bd:serviceParam mwapi:titles "Albert Einstein" .
     ?cat wikibase:apiOutput mwapi:category .

Try it!

The following is also working:

-- Luitzen (talk) 17:24, 7 February 2019 (UTC)

@Smalyshev (WMF): --Pasleim (talk) 17:59, 7 February 2019 (UTC)
Very weird, it looks like any MWAPI query against doesn’t work? But it’s working on my local query service install. --Lucas Werkmeister (WMDE) (talk) 11:04, 8 February 2019 (UTC)
Just tried it, worked just fine for me. Temporary issue? Smalyshev (WMF) (talk) 19:30, 8 February 2019 (UTC)
@Smalyshev (WMF): This still doesn't work for me: -- Luitzen (talk) 18:22, 11 February 2019 (UTC)
Now it works. Thanks! -- Luitzen (talk) 08:51, 12 February 2019 (UTC)

"Dual linking" Commonswiki linksEdit

"Dual linking"

Maybe this could also open the doors for what I'd like to call "Dual linking" where a Commonswiki category page could be both linked on the main subject's page and the "Wikimedia category" page, this could increase the discoverability of both Wikimedia categories (including related subjects) and help organise related pages which are about the same subject. Let's say that two (2) panamed "Numerius Negidius" one links to "the main subject" including Wikipedia pages and Wikisource entries related to it while the other links to its Wikimedia category, Commonswiki galleries are typically placed on the former while Commonswiki categories are typically placed on the latter, as the set of images relates to both (including related subjects), would this technically possible? The benefits is the discoverability of images for subjects. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 20:30, 7 February 2019 (UTC)

I would merge every "commons category" item with the item of the topic of the category. There is no reason for have an item just for the category and one item that describes the content and topic of the category. --GPSLeo (talk) 08:17, 8 February 2019 (UTC)
So what would be the item for the topic "2019 in Seattle"? - Jmabel (talk) 16:22, 8 February 2019 (UTC)
@Donald Trung: I had a similar idea (that I called "one link per Wikimedia project, per namespace"). No thecnical possible right now but it is definitely something we should look into!
@Jmabel: in this idea, there wouldn't be any more items for topic and items for category. So "2019 in Seattle" (that doesn't exist?) and Category:2019 in Seattle (Q60971509) would be merged into one item.
That make some sense; maybe I'm just not correctly understanding what you originally wrote. I'm especially thrown by "panamed" (not a word I've ever seen). Could you maybe reword?
Also, if there "wouldn't be any more items for topic and items for category" wouldn't that have major effects beyond Commons? E.g. Gilbert du Motier, Marquis de Lafayette (Q186652) vs. Q9013148, the latter being on de-wiki and fr-wiki as well as Commons. - Jmabel (talk) 17:41, 9 February 2019 (UTC)
Cdlt, VIGNERON (talk) 10:52, 9 February 2019 (UTC)
what about category contains (P4224); category's main topic (P301)...? Those ones would be merged into the topic items? What a mess. The solution that makes more sense to me is deleting every commonsgallery sitelink from wikidata (after migrating them to Commons gallery (P935). Then, storing commonscategory sitelinks in the "topic-item" when a "category-item" doesn't exist, and with the "category-item" when it does. strakhov (talk) 18:40, 9 February 2019 (UTC)
  Weak oppose Where there are categories on both Wikipedias and Commons for a particular subject, they should be sitelinked. I don't believe the dev team is going to go out of its way to allow sitelinks from the same item to multiple namespaces on the same wiki -- too much is hardwired with the assumption "1 wiki - 1 sitelink". Also, as per comments above, I don't think we probably want to have regular items for typical complex/intersection categories, though it is useful to have category-type items for them here. IMO the existing category's main topic (P301) / topic's main category (P910) mechanism works well enough, so I don't see an existing problem here that really needs to be solved. Jheald (talk) 22:41, 9 February 2019 (UTC)
  Support This is what Wikimedia Incubator users e.g. @Liuxinyu970226, Koavf, StevenJ81: also want. -- 06:37, 11 February 2019 (UTC)
Don't presume what I want. StevenJ81 (talk) 11:32, 11 February 2019 (UTC)
  Weak oppose This is necessary at incubator: or mul:ws: but really the solution here in my opinion is that a bot should mass-create galleries to mirror the category structure. On (e.g.) en.wp, there is both R.E.M. and Category:R.E.M. Those two pieces of the encyclopedia have two different items at d: and so the content at c: should mirror that structure. —Justin (koavf)TCM 07:15, 11 February 2019 (UTC)
  Support This should be considered as "we can", not "we can't". --Liuxinyu970226 (talk) 14:49, 11 February 2019 (UTC)

Labels with bracketsEdit

There are so many labels with brackets, f. e. in Q4386089: nl = Pjat nevest (film, 2011) or ru = Пять невест (фильм, 2011). How can we transform them into valid labels, is there a workflow for that? Queryzo (talk) 23:51, 8 February 2019 (UTC)

@Queryzo: quick answer. The workflow is simple: find them and remove them. To find them, you can use any tool like the Wikidata Query Service (query of all films with a label in English ending with a bracket) or more broadly Quarry (list of all labels in English ending with a bracket). Then you can remove the brackets on this list (you can use with any tool you want; I use LibreOffice Calc, it works fine), you check the correction (in some rare case, brackets are correct, see ( ) (Q4544935) for example) and finally you import these corrected label back on Wikidata (again, with any tool you want, I use QuickStatements). Cdlt, VIGNERON (talk) 10:46, 9 February 2019 (UTC)
yes, I know these tools, but in fact this is a general problem. I thought this might be included into a bot routine or sth. Queryzo (talk) 12:59, 9 February 2019 (UTC)
Just a point about these: brackets should not be removed from labels of category items. Thank you very much, --Epìdosis 13:07, 9 February 2019 (UTC)
I usually recommend removing it AND adding a description. Because presence of such a label means there's a need to disambiguate. Matěj Suchánek (talk) 19:34, 9 February 2019 (UTC)
The problem is that not all the brackets must be deleted, ex. (Pronounced 'Lĕh-'nérd 'Skin-'nérd) (Q276827) or Snow ((Hey Oh)) (Q2068337). On we have a template used to mark pages that need brackets: what's link --ValterVB (talk) 08:43, 10 February 2019 (UTC)
Indeed, but we have Module:WLink (Q19363224) and function getArticleBase() retrieving generic page title, with no fragment nor brackets. Adapted to the given wikilink it could be compared with the current label set. This would be great within a bot routine. Queryzo (talk) 10:19, 15 February 2019 (UTC)

Wikidata, Txikipedia and VikidiaEdit

Hello! This was discussed in 2016, but there have been some changes since then. In Basque Wikipedia we have developed Txikipedia, the Encyclopedia version for 8-12 years old. Currently we have more than 1.400 articles but this can't be linked in a logical way to Wikidata. They describe exactly the same thing as the Wikipedia item, but we can't get directly the data from Wikidata, as the item's Q is not the same. Also, there are some external websites with the same goal: Vikidia, Klexikon, Wikikids... linking all this information could be a great way to make our projects more interesting for different ages. There are some other languages that have contacted us in the euwiki to analyze how Txikipedia was built, and this issue could afect more languages in the future. I don't have a solution, but I would be interesting in having some comments about how to link this items. Thanks. -Theklan (talk) 15:43, 10 February 2019 (UTC)

It sounds similar to simple Wikipedia that has it's own namespace. I think the way to go would be to write an RfC on WikiMedia that strips langcom from being able to withhold namespaces from projects like this. ChristianKl❫ 18:08, 10 February 2019 (UTC)
Would a property for "topic in children's online encyclopedia" be appropriate? That way, any url (regardless of if it's a namespace of an established Wikipedia edition (as is the case for Txikipedia([9]), or a separate wiki (as is the case with Vikidia([10]), or potentially a non-wiki website, could all be added as different statements to the same property to the relevant item. With a qualifier for language. Wittylama (talk) 18:25, 10 February 2019 (UTC)
@Wittylama: Interesting idea... that would give the possibility to add automatically something like the interwiki links with the language code in it. I don't think it would be possible to add to the proper interwiki page, isn't it? -Theklan (talk) 18:54, 10 February 2019 (UTC)
@ChristianKl: the language committee does not involve itself in namespaces like this. It is not its remit. What is its remit is the creation of new projects, the use of standards to identify language content. Content in the same language is the same language. When a new project is suggested for the same language, the requirements are in localisation of the software and continued activity in the specific area. The last time this was considered was for Hindi Wikisource. Thanks, ~~
You can create a separate item and link it from there. The separate item can be linked to the main item with the "permanent duplicate" property. --- Jura 19:23, 10 February 2019 (UTC)
@Jura1: But that solution wouldn't create a Txikipedia item with links to Vikidia, isn't it? -Theklan (talk) 19:49, 10 February 2019 (UTC)
Indirectly, it would. --- Jura 19:50, 10 February 2019 (UTC)
@Jura1: Want to learn more about this solution. -Theklan (talk) 20:09, 10 February 2019 (UTC)

I have been thinking on the proposed solutions and noted that none of them would give access to the information stored in Wikidata. -Theklan (talk) 13:22, 11 February 2019 (UTC)

@Theklan: Why wouldn't a namespace that works analogous to :simple: provide access to information stored in Wikidata? ChristianKl❫ 16:01, 12 February 2019 (UTC)
@ChristianK1: Because a namespace inside Wikipedia is not technically the same as :simple:. Simple has interwikis in the left, but Txikipedia doesn't. -Theklan (talk) 08:07, 13 February 2019 (UTC)
I use the term namespace to refer to what :simple: is. :simple: is technically a namespace. If Txikipedia would get a namespace in the same form as :simple: that would allow it to be easily integrated with Wikidata. ChristianKl❫ 09:57, 15 February 2019 (UTC)
@Jura1: No, look at the interwikis it has now. They are not links to children Encyclopedias. Is not a duplicated item, is an item in another format. -Theklan (talk) 08:07, 13 February 2019 (UTC)

Wikipedia idsEdit

Is there the way to add Wikipedia id by names of languages (by "Language" column)? For example if there is label in "English", "German" and "French" there could be shown their ids "en", "de" and "fr". Currently on language name is shown on the left side and language id is shown on the right side (interwiki list). In case of pages with labels in many languages and/or many interwikis it's impossible to realise if both match. Eurohunter (talk) 18:29, 10 February 2019 (UTC)

There were rumors of development work being done on that labels & descriptions entry box, there are a number of issues there. You might want to try the "Contact the Developers" page for this. ArthurPSmith (talk) 15:14, 11 February 2019 (UTC)

Question regarding Commons CategoriesEdit

I notice that when a Commons category is moved/retitled on Commons (e.g "Category:John Smith to "Category:John P. Smith"), the "other sites" item here on Wikidata automatically updates immediately, yet the property Commons category (P373) does not. Does this get automatically fixed by a bot within a short time, or does it need to be manually updated? For a recent example, see Maxi Schafroth (Q1608370). Animalparty (talk) 19:55, 10 February 2019 (UTC)

I think it needs to be updated manually. I haven't noticed any bot doing it. Ghouston (talk) 06:08, 11 February 2019 (UTC)
That is very, very unfortunate if true. Seems like something that should be made automatic, in the same fashion as Wikipedia articles and Commons categories. The ever-present, ever-growing Wikidata infobox on Commons apparently uses Commons category (P373) for navigation: when I moved c:Category:John Alexander McDougall to c:Category:John Alexander McDougall (artist), turning the former into a disambiguation page, incoming links (e.g. from c:Category:Walt McDougall) were not updated accordingly until I manually changed the property in Wikidata. Since the WikiD-infobox is on over 2 million categories, who knows how many dead ends this has created? Animalparty (talk) 08:12, 11 February 2019 (UTC)
If anything does it, it would be Pi bot by Mike Peel. I vaguely remember there's some reason why it doesn't. Ghouston (talk) 08:57, 11 February 2019 (UTC)
Pi bot runs a query to find cases where P373 and the sitelink don't match, and checks to see if that's because the P373 value is a category redirect to the sitelink - and if so, it fixes the P373 value. That will not work for cases like c:Category:John Alexander McDougall where the old category is now a disambiguation category, though, those need to be sorted out manually. Also, it looks like the query's been timing out, so the bot hasn't been running this task recently, I'll investigate this. Thanks. Mike Peel (talk) 09:45, 11 February 2019 (UTC)
It's running again, but only for the first 5,000 items that the query returns (it seems there are a lot of discrepant values...). I'll rework the code soon to split the query up into multiple ones. Thanks. Mike Peel (talk) 10:00, 11 February 2019 (UTC)
Great! I think it may have trouble with cases where the sitelink is on a category item and the bad P373 on a main item? One of the first items it fixed was Piarist High School, Timișoara (Q1413977), where the Commons category was renamed back in 2015. Ghouston (talk) 10:34, 11 February 2019 (UTC)
@Ghouston: In that case, the problem was that there were two P373 values until 25 November 2018, see [11] and the next edit. The bot excludes any cases with multiple P373 values. You're probably right that it has problems with the sitelink being in a category item, though. The bigger issue is that there's still quite a lot of bad P373 values around that aren't linked to a redirect, try running this query:
SELECT ?item ?commonscat ?sitelink ?name WHERE { ?item wdt:P373 ?commonscat. ?sitelink schema:about ?item; schema:isPartOf <>; schema:name ?name . FILTER( CONTAINS(STR(?sitelink), 'Category:') = true ) . FILTER( ?commonscat != SUBSTR(STR(?name), 10) ) .} LIMIT 1000
Thanks. Mike Peel (talk) 11:25, 11 February 2019 (UTC)
@Ghouston, Mike Peel: Pardon my ignorance, but why doesn't P373 update automatically following moves on Commons? If I move a category or a Wikpedia article, the connectivity to all other linked entities (foreign language articles, etc.) is corrected within seconds. Why not P373? And for that matter, why does the value for Commons category appear twice, once as the property and once as an "other site"? If there's a 1:1 correlation between the two, but only one does its job linking entities, it seems like a hugely inefficient redundancy. Animalparty (talk) 20:02, 11 February 2019 (UTC)
@Animalparty: P373 is basically a bit of text, it's not actually attached to the category. While the link under 'other sites' is a sitelink, which links commons to wikidata (and is what the infobox uses to find the topic for that category). The advantage of P373 is that it lets you link multiple items to a single commons category, while the sitelink is one-to-one. The disadvantages of it are legion, but we're stuck with it for now, for a variety of reasons as discussed at Wikidata:Properties_for_deletion#Commons_category_(P373). Thanks. Mike Peel (talk) 20:42, 11 February 2019 (UTC)
@Mike Peel: So, just so I'm clear, does the Wikidata infobox use P373 or the 'external link' when displaying links on Commons? From anecdotal experience it appeared that the infobox was relying on P373 (thus linking to the wrong category until P373 was manually updated), but perhaps there was just a lag in cache clearing. Animalparty (talk) 20:54, 11 February 2019 (UTC)
I think both are currently used, I'm not sure about the ordering. @RexxS: can you help? Thanks. Mike Peel (talk) 21:30, 11 February 2019 (UTC)
@Mike Peel, Animalparty: The logic in Module:WikidataIB when used on Commons for any linked item is to first look for values of Commons category (P373) for that item. If any are found, it uses the first value to construct the link to the category, and uses the item's label as its sort key. If there's no P373 value, it tries to construct a link using the item's sitelink to Commons, and uses the label as its displayed text. If there's no sitelink, it just displays the label unlinked. If there's no label either, it displays the Wikidata entity-id (Qnnnn) and puts the page in a tracking category for missing Wikidata label. All of that does require some manual maintenance on Wikidata to keep the information useful, as I've yet to find a way of automating those processes. HTH --RexxS (talk) 01:04, 12 February 2019 (UTC)
This is getting a bit specific, so I've followed up on this at c:Template_talk:Wikidata_Infobox#Linking. Thanks. Mike Peel (talk) 09:39, 12 February 2019 (UTC)

Apostasy in Catholicism/Apostasy in ChristianityEdit

Hi, could someone please merge back Special:Contributions/Dlom's edits to Apostasy in Christianity and Apostasy in Catholicism. These are two mutually exclusive acts. Furthermore, there was a long list of people included in Apostasy in Catholicism. - 07:27, 11 February 2019 (UTC)

It seems you already undid the merge. Esteban16 (talk) 16:43, 11 February 2019 (UTC)

The reverts did not work properly since the original edits were merges. Could someone merge them back to the original? - 21:51, 11 February 2019 (UTC)

There is really nothing to revert now. Matěj Suchánek (talk) 09:11, 12 February 2019 (UTC)

@Matěj Suchánek: Whoops, I see what the problem is now. The Special:Contributions/KrBot moved all of the uses of Apostasy in Catholicism (Q55004488) to apostasy in Christianity (Q864968). Could you please run a bot to revert these changes back? - 2600:1702:31B0:9CE0:7CD0:212A:BD0C:7A47 14:52, 12 February 2019 (UTC)

  Done Matěj Suchánek (talk) 15:56, 12 February 2019 (UTC)

ISO 639-3 Change RequestsEdit

I’d like to add Wikidata items for Change Requests on ISO 639-3 language codes. These are useful references for claims on language items, especially for rare languages. See ISO 639-3 change request 2008-040 (Q61639834) for an accepted request, and ISO 639-3 change request 2014-053 (Q61686517) for one that has been rejected. See number of speakers (P1098) of Romagnol (Q1641543) for an example claim backed by Request for New Language Code Element [rgn] in ISO 639-3 (Q61685511) which is part of an ISO 639-3 Change Request. Before writing a bot to create the ~1500 items, I’d like to get people’s feedback on the general modeling. (For the request IDs, I’ve proposed a new property, but there’s other aspects beyond the ID). Thanks for having a look at the two example items, and for pointing out things to improve. — Sascha (talk) 13:08, 11 February 2019 (UTC)

+1 --Liuxinyu970226 (talk) 14:51, 11 February 2019 (UTC)
@Sascha: I’m not sure if has effect (P1542) is the right property to use for the outcome – perhaps use significant event (P793) instead? (I think this also fits well with the point in time (P585) qualifier.) --Lucas Werkmeister (talk) 15:15, 11 February 2019 (UTC)
@Lucas Werkmeister: Thank you! Like this? Acceptance: significant event (P793) of ISO 639-3 change request 2008-040 (Q61639834); Refusal: significant event (P793) of ISO 639-3 change request 2014-053 (Q61686517)Sascha (talk) 15:32, 11 February 2019 (UTC)
@Sascha: yes, that looks good to me :) --Lucas Werkmeister (talk) 18:27, 11 February 2019 (UTC)

Wikidata weekly summary #351Edit

> There is now an experimental SPARQL service to query Wikidata history
Great! Thanks!! -- Luitzen (talk) 08:43, 12 February 2019 (UTC)
Out of curiosity, at how many thousands of weird wannabe-IDs will folks here decide that this is a massive DDOS link spam attack, or is it only me? All IDs y of the form x/y at site x should be left to search engines. – 16:22, 13 February 2019 (UTC)

Watch new links to an itemEdit

Is there a way to be notified whenever new links are made to an item? Evolution and evolvability (talk) 03:20, 12 February 2019 (UTC)

Evolution and evolvability, it is not possible to do that. You still can watch general changes made (not just links added) and even watch those changes on other wikis. Esteban16 (talk) 04:19, 12 February 2019 (UTC)
@Esteban16: Thanks for the info. A pity it's not possible, since it'd be a useful to check new items related to an interest. I get such notifications for Wikipedia articles that I created, but no idea how to add/remove items from that list! Evolution and evolvability (talk) 04:25, 12 February 2019 (UTC)
@Evolution and evolvability, Esteban16: Perhaps it might be possible by using ListeriaBot/{{Wikidata list}} to automatically generate a list? It wouldn't generate notifications but you would still be able to keep track of changes. Jc86035 (talk) 11:47, 14 February 2019 (UTC)
@Jc86035: Interesting idea! I also asked over at MediaWiki (link) and it turns out that there's a Phab task open for pretty much this (link), so there is some interest in the capability. Evolution and evolvability (talk) 22:29, 14 February 2019 (UTC)


prisoner of war (Q179637) is listed as a military classification of death. But it is also used to label ordinary prisoners of war. Should I separate the two? Should we have "prisoner of war" and "death while prisoner of war"? --RAN (talk) 17:57, 12 February 2019 (UTC)

It's listed as a casualty classification, not a death one - "casualty" is a broad term and can indicate people who are wounded or missing as well as killed; see w:Casualty (person). So it doesn't really imply "died in captivity", I think.
Looking at how it's currently used, there are 100 items using {{P|1347)):prisoner of war (Q179637), of which the majority (86) have a time qualifier (start/end/point-in-time), which seems to make sense - it is used to indicate that they had a status of POW between dates X and Y. See eg Otto Kretschmer (Q57253). There's potentially some conflict between using this and using place of detention (P2632) (which IIRC is the normal model for civilian prisoners), though. Andrew Gray (talk) 23:37, 13 February 2019 (UTC)

Request for Comment regarding the notability of Commonswiki categoriesEdit

Please see "Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)" for a discussion related to the inclusion of Wikidata items whose only (Wikimedia) sitelinks link yo Wikimedia Commons. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 19:18, 12 February 2019 (UTC)

CMS Collaboration as authorEdit

Observation of a new boson at a mass of 125 GeV with the CMS experiment at the LHC (Q21481859) and Q42302346 seem to be duplicates, however the authors in the first item are listed in full (there are thousands of them), but are stated as only "CMS Collaboration" in the second. I assume only one should be kept: either the first, with authors linked in the conventional way, or the second, with a new item created for "CMS Collaboration" as a pseudo-organization and authors added as members of that. I think the first would be preferred? Ghouston (talk) 01:11, 13 February 2019 (UTC)

This "CMS Collaboration" or "The CMS Collaboration" can also be found as the author of other articles, not all of which have duplicates. Ghouston (talk) 01:14, 13 February 2019 (UTC)
These had identical DOI's and arXiv id's. I have merged them (after removing the collaboration "author name string", also the wrong publication date). What to do with collaborations as authors is an interesting question; I think we should try to follow whatever the original source does, but it might actually be useful to have a new property for this ("collective author" or something?) In this case we do have an item that represents the collaboration (as an "experiment") - Compact Muon Solenoid (Q659478). ArthurPSmith (talk) 15:41, 13 February 2019 (UTC)

Wikidata:Notability is outdated?Edit

Reading Wikidata:Notability I wonder how up to date is that page and how well does it reflect the current state of wikidata? Most items I've come across don't seem to satisfy the notability requirements(are they requirements or more like guidelines) described on that page. I'm aware that wikidata doesn't want to host every person's data who may want the world to know about them. Though I have seen no wikidata:self-promotion page nor any kind of wikidata:npov page so maybe we can edit data without necessarily needing a neutral point of view or maybe there's nothing against self-promotion. Also btw, I'm in need of a mentor so if you're interested please post on my talk page, I'd be happy to be tutored. Btqfshfst (talk) 12:34, 13 February 2019 (UTC)

Can you give examples of items that don't meet the notability requirements? If that's the case, we just need more people with a broom. Sjoerd de Bruin (talk) 13:02, 13 February 2019 (UTC)
  • @Btqfshfst: In general no you shouldn't create a page about yourself; self-promotion items get routinely deleted. When you look at an item and wonder why it exists, check the sitelinks (generally anything that has a Wikipedia page in any language will have a Wikidata item) and check the "What links here" link, which will tell you if it is being used by other items. Also check the external id's section - many items exist here because they have been described in some authoritative external source, which (in many cases) is sufficient to meet our notability guidelines. ArthurPSmith (talk) 15:51, 13 February 2019 (UTC)
Maybe the policy should explicitly permit items corresponding to existing redirects, that was my excuse for two record labels here. For a third record label it was an existing enwiki draft and a Wikidata ukwiki category in need of a main topic. – 16:37, 13 February 2019 (UTC)
@ When you say "items corresponding to existing redirects", are you talking about the case where some concept does not merit a Wikipedia article in itself, but is well-covered in a Wikipedia article about a related concept and so gets redirects to that article? Bovlb (talk) 19:21, 13 February 2019 (UTC)
Not sure where that goes, but it's about Rockwerk Records (Q60609062) for dewiki, RWG Records (Q60492205) for enwiki, and Pendu Sound Recordings (Q61523615) for a draft or for a ukwiki category Pendu Sound (Q32464776). – 12:52, 17 February 2019 (UTC)
There are 3 main criteria for Wikidata notability, and the linking to any existing article or page in another Wikimedia project is only the first one. A Wikipedia non-notable musician or company can still fulfill criterion 2: It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references. "Serious" is vague, but heck I can probably find local businesses in my own town with enough public data to warrant Wikidata inclusion (websites and business registration records are publicly available). And yes, Wikidata can link to redirected entities, the redirect must simply be broken momentarily to allow synching. This is good, as there are many joint biographies on Wikipedia and other articles that discuss two or more distinct but related entities, but have been merged for Wikipedia-specific matters of style, notability, etc. Wikidata should never dictate how articles on Wikipedia are structured, and the reverse is true. -Animalparty (talk) 23:20, 13 February 2019 (UTC)

In my opinion, yes, notability is outdated if for nothing more than it relies on other site's to tell us that something is notable. While that seems like a good thing, you have to consider their policies. What makes someone notable on site-x, that makes them notable enough for us. For example, if you look at ISNI and VIAF, they admit to wanting to expand their numbers. One of the things they are looking for is to use a musician's Youtube page to help identify them. IMO, that may be good for royalty payments and Top 40 ratings. But should we consider a musician notable because they have an ISNI if all it takes to have an ISNI is a Youtube account? Currently, ISNI and VIAF are not yet using "just the Youtube account" as identification, but they have stated that to be a goal. Lazypub (talk) 13:45, 17 February 2019 (UTC)

Redirects and labelsEdit

When a redirect exist, it does not follow that the label for the redirect is appropriate for an item. It has to be the same thing.. Typically, redirects require there own item. Thanks, GerardM (talk) 12:58, 17 February 2019 (UTC)

A good example is the redirect to Heywood Broun for the Heywood Broun Award.. There is nothing in the article on that award.. There is in Wikidata.. GerardM (talk) 13:38, 17 February 2019 (UTC)

Tool to extract from Wikipedia categoriesEdit

I am looking for tools that leverage Wikipedia categories to add structured information into Wikidata. Example: Categories such as "All companies in <this sector of activity> in this <country>" contain a lot of information about which industry a company is operating in. Can anyone point me to such a tool? Thanks! Pdehaye (talk) 13:21, 13 February 2019 (UTC)

You can use PetScan for this, be sure to select Wikidata as "use wiki" under "other sources". Sjoerd de Bruin (talk) 13:29, 13 February 2019 (UTC)
Would Harvest templates tool meet your expectations ? Kpjas (talk) 21:03, 14 February 2019 (UTC)

Wikipedias and use of wikidataEdit

I have been asked what language wikipedia is using information/templates from wikidata most into their wikipedia. (if possible to measure???) Pmt (talk) 20:29, 13 February 2019 (UTC)

You can see some charts at Grafana. Moreover, some wikis track this via Category:Templates using data from Wikidata (Q11985372). Matěj Suchánek (talk) 08:52, 14 February 2019 (UTC)
In addition also have a look at It shows you the percentage of articles on a wiki that make some use of Wikidata's data. --Lydia Pintscher (WMDE) (talk) 18:24, 14 February 2019 (UTC)
@Lydia Pintscher (WMDE): Hello! Would it make sense to have references to use on other Wikimedia projects of data from an item on the item itself on Wikidata? This is no different from what we have on Commons, where uses of media files on other projects are listed. Thanks! --Joalpe (talk) 18:44, 14 February 2019 (UTC)
That already exists :) You just have to go to "page information". It's linked in the sidebar of every Item. There at the bottom you will see which wikis use data from that Item. And if you do the same on a Wikipedia article you will see which Items it takes data from. --Lydia Pintscher (WMDE) (talk) 19:40, 14 February 2019 (UTC)
@Lydia Pintscher (WMDE):. Cool! I didn't know :p One thing we might consider is to have some sort of warning when a change is made on an item that will reverberate on another project. Just to give an example, today a mass change on items have had a huge impact on a table on Wikipedia in Portuguese, as information was being queried and fed via Listeria on a table: [12]. As I was watching the page, I could just change the query [13], and no lasting damage was made, but a way to signal caution, i.e. a warning notice, could be helpful in situations like this one. Is this feasible? Thanks! --Joalpe (talk) 15:00, 15 February 2019 (UTC)

Duplicate links to Commons categoriesEdit

I've noticed that there are two places in a Wikidata item where there could be a link to Commons category - in the 'statements' section and in the 'other sites' section at the end. Example: Q61710295. I think it's redundant to have the same information twice on the same page. Is there any (practical) reason for this? Could the tools/projects that use this info just get it from a single entry? JiriMatejicek (talk) 21:04, 13 February 2019 (UTC)

  • Yes there are practical reasons for this, yes it is redundant and annoying but it isn't going to change soon. If you put a Commons category in the sitelink, a bot will eventually fill in the property; it's a long story.
  • Question to others: is there some one place where there is a good summary of this? I certainly don't have the patience to rehash it all. - Jmabel (talk) 01:20, 14 February 2019 (UTC)

Empty entries?Edit

Q61717459 and Q61707372 appear to have no significant content at all: they have birth date, birth place, occupation, title (for the first one), and Instagram account name (for the second one), plus a photograph, but no pages on any other WMF sites are associated with either one, and they obviously aren't some sort of intermediate part of any data structure/thesaurus/etc. Can these be deleted, or does WD accept items like this? I almost never come here, so I'm not familiar with the process. Nyttend (talk) 00:04, 14 February 2019 (UTC)

The first seems to be the mayor of a town in Turkey, and it looks OK (I fixed it up a bit). The second is a user who created the two items (and the photos on Commons.) Ghouston (talk) 01:16, 14 February 2019 (UTC)
c:Commons:Deletion requests/File:Ozguroz2.jpg. – 13:11, 17 February 2019 (UTC)

business vs. enterpriseEdit

Can someone please explain to me the difference between 'business' (Q4830453) and 'enterprise' (Q6881511)? While they are described in different words, I cannot think of anything that would be an instance of one but not the other. More often than not, I see Wikidata items that have both statements (e.g. Q1593113), which seems to me redundant. JiriMatejicek (talk) 08:12, 14 February 2019 (UTC)

business (Q4830453) and enterprise (Q6881511). For some reason, business (Q4830453) is stated to be a subclass of company (Q783794), while enterprise (Q6881511) is an organization (Q43229). However, the real issue with merging them would be that some Wikipedias have articles for both. These would need some study. Ghouston (talk) 10:02, 14 February 2019 (UTC)
I'd say sole proprietorship (Q2912172), general partnership (Q646164), and company (Q783794) would all be subclasses of business (Q4830453) / enterprise (Q6881511). Ghouston (talk) 10:12, 14 February 2019 (UTC)
There's a wikiproject related to this - ArthurPSmith (talk) 12:09, 14 February 2019 (UTC)

Kopiersperre Jklamo ArthurPSmith S.K. Givegivetake fnielsen rjlabs ChristianKl Vladimir Alexiev User:Pintoch Parikan User:Cardinha00 User:zuphilip MB-one User:Simonmarch User:Jneubert Mathieudu68 User:Kippelboy User:Datawiki30 User:PKM User:RollTide882071

  Notified participants of WikiProject Companies

Taking from the related articles in and, business (Q4830453) is defined by the activity of doing business while enterprise (Q6881511) is always a distinct organizational and legal entity. I would assume, that most companies are both, but there are cases, where a business (Q4830453) is not a legal entity and vice versa an enterprise (Q6881511) is not actually doing any business (e.g. Q2534287). --MB-one (talk) 12:20, 14 February 2019 (UTC)
There's actually a separate item for "the activity of doing business", business (Q19862406). Ghouston (talk) 21:54, 14 February 2019 (UTC)
I fear this is one of those cases where the concepts described can potentially have slightly different definitions between different languages and don't necessarily always match 100%. Plus there might be languages where no distinction is made between the two, or languages where it gets more complicated. All of which probably got mashed together during the initial creation of Wikidata via interwiki links. Plus we don't know which language users were using when adding these items as statements to other items. With means changes to the item's statements or to the labels/definitions in major languages could result in incorrect statements in other languages. --Kam Solusar (talk)
Reminds me of creative work (Q17537576) vs work (Q386724) vs artificial entity (Q16686448): work (Q386724) doesn't even have consistent descriptions in different varieties of English. Ghouston (talk) 22:00, 14 February 2019 (UTC)
I guess a telephone book would not be considered a creative work under US copyright law because it only contains facts, and has no creative input or commentary. It would would be a "work" that is just a compilation of facts, effort went into it, but not creative effort. --RAN (talk) 22:22, 14 February 2019 (UTC)
Yeah, I think that's the main distinction. But we have three items for two concepts. And one of the concepts varies depending on which country's laws you use, at which point in time, so isn't really useful for subclassing from. Ghouston (talk) 22:31, 14 February 2019 (UTC)
Overall I'd say its a mess... Back in the days when I tried to sort things out, business (Q4830453) was a commercial term corresponding to this LoC definition which more or less matches with en:Business or de:Unternehmen. enterprise (Q6881511) used to be for "big companies" (enterprise). company (Q783794) was for the abstract legal concept of an association of natural or juridic persons or forms that are neither but "close enough" (en:Company/de:Personenvereinigung), independent of the concrete legal form in a given jurisdiction. At the moment I don't have time or much incentive to clean it up again, because one would have to start at the Wikipedia articles and clean them up from layman concepts based on a solid outside reference and then, once clean definitions exist, match them up in Wikidata. --S.K. (talk) 06:56, 18 February 2019 (UTC)

Marriage end causesEdit

Infoboxes in the English Wikipedia have the reason for the end of marriages (divorce or death of one of the parties), is their any plan to do that here? See for example Elizabeth Taylor (Q34851) with multiple marriages here at Wikidata and at Wikipedia w:Elizabeth Taylor. --RAN (talk) 23:31, 14 February 2019 (UTC)

end cause (P1534)? Circeus (talk) 06:25, 15 February 2019 (UTC)

QuickStatements not workingEdit

QuickStatements is not working for me this afternoon. I got logged out and loging in always get me to with "500 - Internal Server Error". Anybody else is having similar issues? --Jarekt (talk) 03:20, 15 February 2019 (UTC)

You are most certainly not alone, and the problem is not specific to QS as far as I am aware. Mahir256 (talk) 03:37, 15 February 2019 (UTC)
Not only QuickStatements. Listeria is not working either. --Derzno (talk) 05:02, 15 February 2019 (UTC)
@Magnus Manske: for keep him posted on the current issues. --Derzno (talk) 06:03, 15 February 2019 (UTC)
Day 2 of the outage: crickets. --Tagishsimon (talk) 11:05, 16 February 2019 (UTC)

Hide quickstatement edits from the watchlistEdit

Is there a way to remove Quickstatement edits from my watchlist? I fumbled around to try and do b/c while they are good edits... they are useless for me to see and making it dwnright impossible to see the edits I do want to see. Circeus (talk) 06:23, 15 February 2019 (UTC)

Q11940275 and Communist Party of the Balearic Islands (Q5154465)Edit

Same items? 07:45, 15 February 2019 (UTC)

Seems like it. Thank you for letting us know! Mahir256 (talk) 08:03, 15 February 2019 (UTC)

Is this bug already tracked in Phabricator?Edit

  hint:Query hint:optimizer "None"
  SERVICE wikibase:mwapi {
	 bd:serviceParam wikibase:api "Generator" .
     bd:serviceParam wikibase:endpoint "" .
     bd:serviceParam mwapi:gcmtitle "Category:Commons_licensing_help_by_country" .
     bd:serviceParam mwapi:generator "categorymembers" .
     bd:serviceParam mwapi:gcmtype "page" .
     bd:serviceParam mwapi:gcmlimit "max" .
     ?item wikibase:apiOutputItem mwapi:item .
# ?item wikibase:sitelinks [] .
  ?article schema:about ?item 

Try it!

It seems that join is not performed when variable appears in the object position of the nearest triple pattern.

Wrapping ?article schema:about ?item into SELECT helps . -- Luitzen (talk) 13:02, 15 February 2019 (UTC)

Oops, the problem was that ?item is not always bound. One should add FILTER(BOUND(?item)). -- Luitzen (talk) 12:40, 17 February 2019 (UTC)

Violating DRYEdit

What's the point of this nonsense? en:Don't repeat yourself refers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:21, 15 February 2019 (UTC)

Another example: Wikidata:Property proposal/taxon author citation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 18 February 2019 (UTC)

Works in collection (P6379)Edit

User:KrBot has been busy on my watchlist in the last few days, adding works in collection (P6379) statements to lots of artists.

Is this the right thing to be doing? If an artist is known for 40 different works, in 40 different museums, are we going to end up with 40 different P6379 statements?

This seems like a classic case of a one-to-many property, which normally we would try to avoid, usually by instead trying to work with an inverse property that would only have one value (or a handful of values at most) for each item. In this case that might correspond to leaving it to collection (P195) and location (P276) statements on each artwork item to carry the information, then using a query to gather up results for a per-artist report.

Pinging @Hannolans: These edits that KrBot is making, are they what you envisaged when you proposed this property? Jheald (talk) 10:57, 15 February 2019 (UTC)

I tried to stop this, but was a lone dissenter. We need more eyes on property proposals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:33, 15 February 2019 (UTC)
There is no many-to-one connection possible in wikidata, unless we import the works of those creators. This would mean importing all photographs, design, prints, posters, fashion, tableware in wikidata of all archives and museums worldwide. We are talking about huge datasets. Currently we have all paintings in wikidata, but if we want the many-to-one we need a discussion of we should import all collection items of every museum. The need for this property is clear, this is the first time you can query which archive or museum has works of an creator. Our direct use case is to bridge archives and museums to check copyright and licences for photographers. Other use cases are to query 'how many artists are male/female in museum x', which artists in this museum are local, how many artists are from foreign countries. Which local designers have also works in museums in our neighbour country. --Hannolans (talk) 13:09, 15 February 2019 (UTC)
Maybe David can tell us why he supports every proposal without any arguments. Some get appoved with his vote as only interaction. Sjoerd de Bruin (talk) 14:31, 15 February 2019 (UTC)
I support the proposals that I see it useful.We can develop a condition prevents the creation of a property when only one user supports it although the motion was put to a vote for a long time David (talk) 14:42, 15 February 2019 (UTC)
This is a many-to-many, not a one-to-many property, and it was explicitly discussed in the proposal discussion why creating all the individual work items that would allow for many-to-one relations is simply not practical. As to Andy's opposition - if people feel it's important to have "more eyes on property proposals" (this one had more comments and discussion than most - 7 different people in the edit history) it's also important for those who do participate to actually respond to those who try to engage them. Declaring "oppose" without engagement is simply not helpful. I invite anybody to read the proposal discussion and judge for themselves what happened here. ArthurPSmith (talk) 16:00, 15 February 2019 (UTC)
I put some queries on the talk page of the property. Looks like Vincent van Gogh (Q5582) is currently in the most collections for paintings. I added works in collection (P6379) for the collections. It's quite a lot, but doable and this is the painter with the most different collections. Others will be less. Multichill (talk) 12:22, 16 February 2019 (UTC)
190 P6379 statements for Van Gogh?? Is this really what we want to do, or useful to anybody? Jheald (talk) 12:49, 16 February 2019 (UTC)
Same as the number of sitelinks to Wikipedia. The item also has 110+ identifier statements. So about the same in the order of magnitude. Quite different than including every work on an artist.
I have a background in computer science so I don't like redundancy. But I'm pragmatic. We have a lot of redundant data to make it easier to work with our data. This property serves a purpose and doesn't break the order of magnitude. That's more important to me than the redundancy. Or do we have another argument against this property? Multichill (talk) 13:11, 16 February 2019 (UTC)
Redundancy between an identifier statement and a collection statement? That's not really the case, since a person can have an identifier at an institution even if they have no works there. E.g., if they are depicted in a work, or they donated something. Ghouston (talk) 22:03, 16 February 2019 (UTC)

Vandalism in Sergio Goyri (Q2263688)Edit

Due to a controversy, actor's template has been target of a series of vandalism edits by IP users. It must be protected. --Link58 (talk) 22:07, 15 February 2019 (UTC)

Has been protected for two weeks. Sjoerd de Bruin (talk) 22:14, 15 February 2019 (UTC)


The item Q60769107 ist identical to the item Q42650745. They should be merged together.--Carl Ha (talk) 00:01, 16 February 2019 (UTC)

Done!  – The preceding unsigned comment was added by Richard Arthur Norton (1958- ) (talk • contribs) at 01:03, 16 February 2019‎ (UTC).

Separate entities for pseudonyms, alter ego'sEdit

There's been some, well-intentioned I believe, efforts to separate musical artists from their aliases, but unfortunately this has ended up more like duplicates. Aphex Twin and Richard David James is maybe the most glaring example, but there's also Freddie Mercury alias Larry Lurex and quite a few others. Is there a clear policy on this? If separating artistic aliases from "real persons" is something that we want to avoid it would be useful to have a "rule" to point people to, if it's something that's encouraged then a standard way of doing it should maybe be established, so we don't end up with both the alias and the person having instance=human thus counting a two people. Any input appreciated! Moebeus (talk)

If it's simply a pseudonym I don't think it deserves a separate item. But if there are attached attributes - like a fake birth date and location, different nationality, family, gender, etc associated with it then a separate item makes sense to me, as it would otherwise be hard to attach the attributes to just the pseudonym. However, the pseudonymous item should be an instance of person (Q215627) not human (Q5). ArthurPSmith (talk) 17:15, 16 February 2019 (UTC)
@ArthurPSmith: person not human sounds right to me, but the English description for person (Q215627) clearly states "do not use with P31". If there's consensus on this then that should be changed accordingly? EDIT: Could alter ego perhaps work instead of person (Q215627), not having the same restrictions? Moebeus (talk) 12:09, 17 February 2019 (UTC)
Hmm, I guess they want you to be more specific. Q201662 would be fine I expect. ArthurPSmith (talk) 15:07, 18 February 2019 (UTC)

"Bookshop neighbourhood"Edit

Is bookshop neighbourhood (Q27095194) really a valid item? I ran across it because The Ave (Q7715010) was described as being such. Perhaps there is such a thing and it is just poorly applied here. For starters, I live in Seattle, and The Ave—officially University Way NE—is a street, not a neighborhood; the neighborhood is the University District (as shown on the OpenStreetMap map at Q7715010!). Beyond that, though, I know the neighborhood pretty well and I don't think it has as many as five bookshops along the kilometer-long shopping strip, even if we allow for ones that are as much as a block off the street itself. It once had more, probably as many as ten, but that was decades ago. That is in contrast to perhaps 15-20 places serving espresso and/or bubble tea, and well over 30 places to eat, probably more like 50. So what makes a "Bookshop neighbourhood"? And how is a street a "neighbourhood" of any sort? What then is the neighborhood it is in?

This came up because I encountered what seems to me as dubious content in the Infobox generated from this on Commons. - Jmabel (talk) 01:10, 16 February 2019 (UTC)

I assume it was created as the main item for Category:Bookstore neighborhoods (Q8306867). The enwiki category contains a mixture of streets and neighbourhoods. Ghouston (talk) 03:33, 16 February 2019 (UTC)
If The Ave is not best described as a "bookshop neighbourhood", which I guess would be a neighbourhood consisting primarily of bookshops, then it should be fine to remove it from the category in enwiki and change the instance of statement in Wikidata. Ghouston (talk) 03:49, 16 February 2019 (UTC)
I'm not taking on the recategorization in en-wiki, but I will change the instance of (P31) value to shopping street (Q21000333), which has a lot more basis in reality. - Jmabel (talk) 06:08, 16 February 2019 (UTC)

Mentorship, or similarEdit

I'm unaccustomed to Wikidata but have recently created

The last-listed was only intended to provide a reference for assertions in the Eauclaire item. The Eauclaire item was only intended for the American Independents item (although Eauclaire has written other books and might conceivably get a Wikipedia article). The 1st ed item is only there because, rightly or wrongly, I believe that WD mandates a distinction between (i) a book (independent of its publication details) and (ii) a specific edition thereof, even if (a) it is absolutely clear that there has only been one edition and (b) it's inconceivable that there'll ever be a second. I only bother with Independents because I felt a need to provide a reference for various assertions in the Harding item. (And I only created the Harding item because I'd just created an article on him in en:WP.)

All of this was rather tiresome. If it was constructive, then OK, no complaints. But I have a queasy feeling that I might have gone about the whole business in the wrong way, written unnecessarily ambiguous values, used inapplicable properties, etc etc. Would some experienced person like to give these creations of mine a quick look-over and provide me (whether here, on my talk page, or elsewhere) with a sanity check?

As an example, American Independents is a book in which Sally Eauclaire presents the work of 18 photographers. She provides an introduction to the whole book and to each of the 18 sections. Is she an author, the editor, or both? (Or should I just parrot what's on the title and/or copyright page?) Each of the 18 photographers writes nothing but instead provides photos; are they authors? The book both anthologizes and is about then-new American color photography. It's not at all about the techniques thereof; it's instead about the art. (Use of color for "art" photography was then still unconventional, though growing fast.) I thought I'd say that its main subject was 20th century (or postwar) US color photography; however, I could only find color photography as an existing item: no American photography or 20th-century photography. I didn't create the latter pair, not only out of lack of stamina but also because I feared such an effort might be totally misguided. -- Hoary (talk) 03:28, 16 February 2019 (UTC) .....reworded a bit 12:18, 16 February 2019 (UTC)

Wrong instance of Airelle (Q2828703)Edit

Hi all, I created a request in Wikipedia [14] to improve my understanding of the item Airelle (Q2828703) . It seems that the instance of should be changed to metalanguage (Q193983) . How bold should I be here? Thanks for the help. Best regards--Hundsrose (talk) 08:58, 16 February 2019 (UTC)

Be bold. As long as nobody complains, you can assume that your changes are okay, particularly in sparse items such as Airelle (Q2828703). Otherwise you need to discuss… :-) —MisterSynergy (talk) 07:20, 18 February 2019 (UTC)
Thanks a lot, MisterSynergy! --Hundsrose (talk) 07:30, 18 February 2019 (UTC)

Please block User:UUEdit

He vandalised many interwikis about Planet X or Planet Beyond Neptune.  – The preceding unsigned comment was added by 2001:2d8:e290:9990::ba48:af02 (talk • contribs) at 16 February 2019‎ (UTC).

RfC about semi-protection of some Items based on usageEdit

I just opened Wikidata:Requests for comment/semi-protection to prevent vandalism on most used Items. This RfC aims to compile the community's position on using semi-protection as a way of preventing vandalism on the most used Items on Wikimedia pages. Thanks in advance for your comments! --abián 13:44, 16 February 2019 (UTC)

Recycle: Real attackers use throw-away accounts. Recycle: "Edit review" (or its dewiki variant) is less work than semi-protect for all involved parties. – 13:48, 17 February 2019 (UTC)

Bot changing precise date of death with death year because it is better referencedEdit

@Anders-sandholm: Can someone look at this edit and then check to see if the bot is doing this more often. It appears to be changing overwriting a precise date_of_death with a less precise year of death because the year alone has more references. The edit summary seems to say it is adding a more precise date, but it is adding a less precise date. I have restored the more precise date in the most current edit. --RAN (talk) 16:58, 16 February 2019 (UTC)

  • Also, shouldn't we be able to have multiple citations for the (less precise) year as well as having a citation for the (precise) day? - Jmabel (talk) 17:27, 16 February 2019 (UTC)
  • The bot previously did this date refinement from year to day precision in the same item, but concerns were raised and the operator was asked to undo the edits (see topics on User talk:Anders-sandholm). Problem was that (some of) the references provided for the year-precision statement do not support the day-precision date, so a refinement seems inappropriate. You should not undo the bot's edit, but add another, second statement with the day-precision date instead. —MisterSynergy (talk) 20:21, 16 February 2019 (UTC)
When I asked previously, I was told not to keep the year-only date. Keep dates that conflict, but eliminate the year-only date. VIAF and LCCN only use years of birth and years of death, so we would have to populate EVERY person with the year-only date. What purpose would that serve? It gives the appearance that there is some question as to the correct date. Why add the year-only to say George Washington (Q23) --RAN (talk) 21:19, 16 February 2019 (UTC)
You can additionally prefer the more precise date with ranks, assuming you have high confidence in the value (maybe supported by a reference). We do not collect "the one and only correct value"; we map values found in various sources, and if they differ, there are multiple statements to be stored in the item for the different values. Ranks can to a sufficient extent control which values are visible to data users, as they can request "best rank" values (which is kind of the default behavior), all non-deprecated values, or all values. —MisterSynergy (talk) 21:39, 16 February 2019 (UTC)
We could do the same for a lot of facts ... where someone is born in Manhattan, we can import New York City and even New York state or even USA. --RAN (talk) 23:12, 16 February 2019 (UTC)
  • Again that goes back to actual practices and the example of George Washington. We have over 1,000,000 records where we can import the year-of-death from VIAF in addition to the exact date-of-death, but we do not. And in this very specific case the reference for the exact date was the American National Biography which was also one of the references for the year-only date. As always, I will abide by whatever rule we decide on globally, but I do not see any utility in adding in imprecision just because we have it. As I said before, when we have two conflicting dates or years, than yes, we need both. And of course we should not be overwriting the precise dates just because they are currently unreferenced or only referenced to Wikipedia, we should be adding in references, not deleting the data. What do others think? --RAN (talk) 22:20, 16 February 2019 (UTC)
Also look at Victor Clarence Vaughan (Q18912741) where both precise and imprecise have the same ranking so that Wikipedia and Wikimedia Commons do not know which one to use where the infobox imports the data. Go to his Commons page and see where it imports both dates. This should have been more thought out before implemented. --RAN (talk) 23:08, 16 February 2019 (UTC)
Dates and precision is very complicated for humans, let alone for bots. You should generally don't use bots to change the precision of dates. Bots should:
  • Add dates (with sources)
  • Add sources to already added date statements
Changing existing dates will just mess up with the sources. About the year versus more precise date problem. Let's take Michael Jackson (Q2831). Date of birth very well documented and sources. Would be a bit weird to add 1958 just because viaf and friends only document the year. Interesting is that GND just shows the year in their web interface, but if you open the raw data, you'll get the full dates. So I guess the only valid situation to remove the year statement is when you have a very well not-contested more precise statement. Multichill (talk) 21:57, 17 February 2019 (UTC)
I agree, and minimally stop overwriting the precise-date with the year-only date ... do we know how many data points were deleted, and can they be restored? I only noticed because one showed up on my watchlist. --RAN (talk) 04:36, 18 February 2019 (UTC)

Listeria, Quickstatements et al - dead for the next weekEdit

In the absence of any accessible announcement from WMF - because why would you bother informing users on a mainstream noticeboard like this of an outage to a critical service on which heavily used tools depend - let it be known that toolsdb is kaput and will not be repaired until, perhaps, Tuesday 26/02/2019. [15] --Tagishsimon (talk) 18:03, 16 February 2019 (UTC)

Can someone fix Q58620846Edit

The name for Q58620846 is Cryptocurrencies but that clearly isn't what the item is about. It's official name is listed as "Africahead Ipparts" so maybe that's what it's supposed to be? The official website is just odd and doesn't seem to fit anything. Can someone please fix this for me because I am extremely confused on what this item is actually supposed to be. --TB5ivVaO1y55FkAogw1X (talk) 02:00, 17 February 2019 (UTC)

I nominated it at Wikidata:Requests for deletions. Ghouston (talk) 02:50, 17 February 2019 (UTC)

Observe deletetion of statements in itemsEdit

How to monitor the removal of a statement. Example here [16] - after removal of Upper Lusatian house (Q1362233) I can't use my watchlist [17] to observe. Thanks for Help, Conny (talk) 06:06, 17 February 2019 (UTC). (de)

Restriction problemEdit

In Q1588017#P18, we have a problem. The model of the dulcimer (the instrument depicted) is called Dizzy Signature and because of that it activates this restriction, the restriction thinks that the image is actually a signature. Which is the best solution?

  1. Change the restriction?
  2. Rename the file?
  3. Forget about it and let the issue be?

Thanks in advance, Paucabot (talk) 06:20, 17 February 2019 (UTC)

I added an exception for it on Property:P18. Ghouston (talk) 22:10, 17 February 2019 (UTC)

How should sitelinks be updated when a linked page is moved/deleted?Edit

Hi! I talked to Lydia Pintscher about phab:T143486. She would like to know what the community thinks is best for updating sitelinks in those cases where such an update is currently not possible (because the user's account is blocked on Wikidata, because the account isn't yet created locally, because the user account isn't confirmed on Wikidata and therefore can't edit a semi-protected entity, etc.). What do you think? --abián 16:49, 17 February 2019 (UTC)

  • To avoid disrupting Wikidata, please unprotect any items you protected recently. In the meantime, please go through all items you prematurely protected and update manually links that didn't get updated due to your use of inappropriate page protection. --- Jura 17:08, 17 February 2019 (UTC)
  • Do we have numbers of cases how often sitelink updates after page moves fail due to non-existing local accounts, account blocks, and page protections? For me, this does not appear to be an urgent problem at all. —MisterSynergy (talk) 17:31, 17 February 2019 (UTC)
    • The problem is not primarily the lack of update(s), but the second item that ends up getting created with the new page name. Maybe a review of mergers can help. --- Jura 17:37, 17 February 2019 (UTC)

Is item Christian Frates (Q47691741) notable enough?Edit

I was searching on for

  • medical condition = classic autism
  • occupation = YouTuber

and I got 1 hit:

The wikidata item was created by User:Cwf97 who at their talk page is "Christian Frates". Apparently they are related to Pete Frates with 'type of kinship' 'male first cousin'. Pete Frates is given credit for inspiring the ice bucket challenge. Maybe it's at least somewhat notable? Are family members automatically notable for being related to a famous person? I just want to find wikidata notability standards. What do you make of this? --Btqfshfst (talk) 17:28, 17 February 2019 (UTC)

Also adding that others had the concern that the user does not reply frequently enough to messages on their talk page. Now I only waited 3 little days, but I waited until the user made more edits to see if any of those edits would address my messages on their talk page. Apparently not and here's another sign of that but on User_talk:Cwf97#Communication_is_required --Btqfshfst (talk) 17:46, 17 February 2019 (UTC)

Request for mergeEdit

Could someone please merge Q51293965 and Jibril Hodges (Q29002736)? - 2600:1702:31B0:9CE0:8C1E:478D:4467:793E 09:16, 18 February 2019 (UTC)

  OK--Derzno (talk) 13:43, 18 February 2019 (UTC)

Talk to us about talkingEdit

(Some translations are available. Please forward this message to your projects, thanks!)

The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.

We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.

We are currently planning the consultation. We need your help.

  • We need volunteers to help talk to their communities or user groups. You can help by creating a discussion page and hosting a discussion. You can sign up your participant group here.
  • You can also help build the list of the many different ways people talk to each other. Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.

Soon, we will invite you to leave individual feedback about talk pages and other ways that you communicate. Then we will discuss ideas with the group.

You can read more about the overall process on If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you. Trizek (WMF) (talk) 14:59, 18 February 2019 (UTC)

Wikidata weekly summary #352Edit