Open main menu

Wikidata:Project chat/Archive/2019/01

< Wikidata:Project chat‎ | Archive‎ | 2019

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.


How to structure mountain with two peaks?

I'm new to wikidata after contributing to OpenStreetMap led me here (linking wikidata items with OSM entities is very valuable).

Lately I've been focused on the Scottish Munros (mountains over 3000 feet) and Beinn a' Bheithir (Q4881343) is an interesting case as it has two peaks both classed as Munros: Sgorr Dhearg (Q24677994) and Q24677993. I see that mountain (Q8502) has part (P527) summit (Q207326), but can't figure out if that helps me link these objects correctly or if there's just not a suitable property (or if perhaps it shouldn't technically be classed as a mountain itself, but some structure of two mountains?).

Any advice here is appreciated! --SilentSpike (talk) 20:35, 31 December 2018 (UTC)

  • For what it may be worth, Little Tahoma Peak (Q1367080) is modeled as a mountain in its own right rather than as part of Mount Rainier (Q194057), so if we come up with a solution here, it should apply there as well. - Jmabel (talk) 20:52, 31 December 2018 (UTC)
  • See Kanchenjunga West (Q1723731) for one way to model these, though personally I would also use part of/has part. - PKM (talk) 21:48, 31 December 2018 (UTC)
  • Thanks for the reference, I opted to do the same and make them instances of summit (Q207326) and use the "of" qualifier as well as adding appropriate part of/has part properties (as I like that this connects both ways and not just one way). --SilentSpike (talk) 01:38, 1 January 2019 (UTC)

Suggest a new external identifier

How can I suggest a new external identifier? I was thinking about Google Play app and developer IDs, as 'com.ubercab.driver' here, but I don't understand the process for such suggestion.  – The preceding unsigned comment was added by Pdehaye (talk • contribs) at 20:31, 31 December 2018‎ (UTC).

There are Google Play Store App ID (P3418) and Google Play developer ID (P4486). Unfortunately, not all developers have a suitable (numeric) developer ID for that property. —MisterSynergy (talk) 20:47, 31 December 2018 (UTC)
Thanks! I have a hard time finding properties. Still, the question remains on how to suggest external identifiers. Pdehaye (talk) 22:21, 31 December 2018 (UTC)
You can use namespace searches, such as property: "Google play" for instance. Wikidata:Property proposal is for new property suggestions. —MisterSynergy (talk) 08:24, 1 January 2019 (UTC)
Ah right, so it is simply a matter of proposing a property with data type "external id". Makes sense. Thanks! Pdehaye (talk) 18:29, 1 January 2019 (UTC)

Antony and Cleopatra and Antony and Cleopatra

When I visit commons:Category:Antony and Cleopatra, it tells me that the category is for the play by William Shakespeare, but so does commons:Category:Antony and Cleopatra by William Shakespeare. Stranger still, both categories are linked to the same data item Antony and Cleopatra (Q606830). To clarify: If I am on Commons, and I follow the icon link to Wikidata from either category, I am taken to the same data item here on Wikidata.

As far as I can tell from the contents of the two categories, commons:Category:Antony and Cleopatra should be a general category for the famous historical couple, and commons:Category:Antony and Cleopatra by William Shakespeare should be the category for the play by Shakespeare, but I cannot determine what it is that causes the link to the wrong data item from the first one.

Can anyone help? --EncycloPetey (talk) 22:29, 31 December 2018 (UTC)

They both show the same infobox because one is directly linked, and the second is indirectly linked via Category:Antony and Cleopatra (Q13583316) and its category's main topic (P301). Ahoerstemeier (talk) 00:21, 1 January 2019 (UTC)
So how do I resolve this? The Category's topic is not the Shakespeare play, but the historical couple. Presumably I need to create a data item for the historical couple "Antony and Cleopatra", because there doesn't seem to be one. But how do I create a data item for a historically famous couple? --EncycloPetey (talk) 04:50, 1 January 2019 (UTC)
instance of (P31) married couple (Q3046146). (I've created Antony and Cleopatra (Q60310502).) --Yair rand (talk) 06:56, 1 January 2019 (UTC)
Thanks! --EncycloPetey (talk) 17:24, 1 January 2019 (UTC)

Disappearing comments on this page?

Several comments on this page disappeared - possibly through an edit conflict or something else? See this diff. - PKM (talk) 00:15, 1 January 2019 (UTC)

I just restored the lost comments in Special:Diff/824423245. The user probably edited an old version of the page and somehow didn’t notice it. —MisterSynergy (talk) 00:25, 1 January 2019 (UTC)
Apologies Pdehaye (talk) 06:56, 1 January 2019 (UTC)

Revoke bot User:MatSuBot

I added a request to revoke the bot User:MatSuBot at the page Wikidata talk:Bots. I don't know if this was the right place. If not, please move it to the right place. -- 11:58, 1 January 2019 (UTC)

Setting a date value to None

How do I set a date value to None? What about other data types? Pdehaye (talk) 06:55, 1 January 2019 (UTC)

Help:Statements#Unknown or no values; valid for all data types. —MisterSynergy (talk) 08:26, 1 January 2019 (UTC)
yes, uses for "no value" in dates are somewhat rare though, e.g. immortals, never published works. --- Jura 08:29, 1 January 2019 (UTC)
here it is to mark an end date as no "value" for a membership in an organisation, because those still are members, by opposition to a bunch who no longer are, but it is unknown when they left. Pdehaye (talk) 18:32, 1 January 2019 (UTC)
Unless it's some perpetual membership, you might want to add "point in time" instead. This indicates that they are known to be a member at a given point in time. --- Jura 05:10, 2 January 2019 (UTC)

Version update request

Hi there! Would somebody be a good boy/girl and update the latest version of Krita (Q604945)? Here's the ref. Do remember to set the rank of the latest version to preferred.

Now why do I ask somebody else to make such a trivial change? The reason is I cannot do it myself because editing statements still requires JavaScript, a dangerous technology. --Palosirkka (talk) 12:48, 1 January 2019 (UTC)

That's actually a DIY job, while at it I demoted 4.1.1 to normal instead of preferred. Generally I disallow JS where it's dangerous, e.g., complains about my AdBlock. With your better NoScript approach you could allow JS only here. The mysteries of ranking are still beyond me, I've tested it on Freeciv for some years. – 01:45, 2 January 2019 (UTC)
Thanks mate. Half way there, now if somebody would set 4.1.7 preferred rank it would be wonderful. --Palosirkka (talk) 04:34, 2 January 2019 (UTC)
How about trying to use QuickStatements instead?
Though I'm not entirely sure why we should trust you if you don't trust Wikidata. --- Jura 06:01, 2 January 2019 (UTC)
JS haters one, login haters nil, but there's no ranking on wikidata-todo/quick_statements.php. 09:39, 2 January 2019 (UTC)
Done, but what's better, version ranking or types as used on MediaWiki (software)? – 09:26, 2 January 2019 (UTC)
In a world where Windows now allows you easy sandboxing of a browser out of a box, there are plenty of ways to execute Javascript without much risk. ChristianKl❫ 06:48, 2 January 2019 (UTC)
Things like TAILS - The Amnesic Incognito Live System (Q2801412) exist if you want to use sites you don't trust. Admittedly, it may be inconvenient to reboot to use a Javascript site, and using a VM may use too much memory or not be secure enough for your purposes. Ghouston (talk) 07:27, 2 January 2019 (UTC)

Maps for OSM relations

Since now we have minimaps for geocoordinates, I think it would be nice to have them for OSM relation ID (P402) too. Do you agree? --Micru (talk) 11:41, 2 January 2019 (UTC)

Is the signed statement concept a good idea for data quality improvement ?

To understand this section, please read the development plan for 2019 and especially the section related to the signed statement concept. This concept is a mix of 2 different things: the possibility to add a signature in order to authentify a statement and the addition of a protection to highlight the modification of a value without modifying the corresponding reference. If this proposal is really a help in term of data donation and seems an improvement for the data quality in WD, I really find disrespectful the limitation of this ability to some institutions only. Just to be clear: the signature is not the problem, the signature by institutions is really a huge step to develop data donation and to solve some licence problems by acting like OTRS in Commons to validate some licence questions.

No, the problem is the additional protection again vandalism (the signal that a value was changed and not the reference) reserved to contributions of some special contributors and not available to all contributors. Among the contributors, there are a certain number of people who are working hard to provide good references, to provide complete set of data about references according to help:sources, to curate data and to solve constraint violations by analyzing the data contradictions, and all that work won't be protected in the same way as the data provided by institutions. Why this difference ? Is there any reason to consider differently the work of simple contributors and institutions ? When we see the work done on VIAF data and the important contributions done by Wikidatians to inform the database about its internal errors, I don't think institutions are really better.

If I don't support the proposal in its current form, I understand the motivation behind: increase data quality. But the problem is not the lack of institutions contributions, but the problem is a fondamental error in the Wikidata data model concept: the possibility to add a value without providing a reference and the ability to change a value without any action on the references. Instead of implementing some patches like the signed statement concept, it is time to solve that problem in its roots.

I propose to implement the locked statement concept: when a value is added with a reference, a protection is added to prevent the modification of any part of the statement. The locked statement can only be deleted. If a part of the stament has to be modified (value, qualifier or references), then the statement has to be deleted completely and then created again with the correction included. This is the only way to really deal with the problem of sneaky vandalism.

This tool has to be available to everyone contributing in WD, simple contributors or institutions. I don't know how this concept can be implemented but data quality should not be treated by halfway measures. Snipre (talk) 21:47, 28 December 2018 (UTC)

I don't think "increase data quality" is a good summary of the motivation for this feature. A large part of the motivation is to motivate institutions to contribute to Wikidata. Signed statements make it easier for organizations to analyse how their own involvement impacts Wikidata and they make they create visibility for the contributions of a organization.
Signatures also provide an additional way of trust that's distinct from trusting references.
If a Wikidata editor changes a statement we imported from VIAF, it's important to know for VIAF. If the VIAF value was wrong, a VIAF employee has to change the value at the VIAF side. If the edit is wrong, then it's good if the institution checks it and reverts it. ChristianKl❫ 22:37, 28 December 2018 (UTC)
@ChristianKl: "I don't think "increase data quality" is a good summary of the motivation for this feature" Did you take the time to read the development plan: the signed statement proposal is mentioned under the section "Increase data quality and trust". So why this proposal is mentioned taht section is the main motivation is not the data quality improvement ?
Then if you read my comment you will find that I have no problem with the signed statement proposal: no problem for addition of a signature or any symbol indicating who put that data.
Your example about VIAF data is good but by the way can you explain why VIAF employee can have a better watch system on his data and not all contributors ? Why the system can't be spread to everyone: each time a statement is changed, the person who added the data is informed, or at least each time a value is changed without modification of the corresponding reference, then a signal informs the reader that a potential problem exists with the data ?
Why a VIAF employee should have better tools than me who spent dozen of minutes to create an item for a reference and then spent again some minutes to enter all information to provide a complete and reliable statement ?
Your comment assumes that institutions will monitore their data: do you have any engagement about that ? The reality is that the data integrity of the WD is mainly protected by simple contributors using their watchlist. So why the main contributors to trust in data can't have access to the best tools to perform that job ? Snipre (talk) 11:36, 29 December 2018 (UTC)
I consider trust to be separate from quality.
This is not the first discussion about signed statements, but I don't have links to the previous discussions. There are currently discussions between WikimediaDE and the German National Library about cooperating with each other. It's my impression that the need for signed statements comes out of such discussions. ChristianKl❫ 20:09, 29 December 2018 (UTC)
I found no obvious problem apart from WTF is wikibase? 23:18, 28 December 2018 (UTC)
  • I don't think the questions need all be linked. If I recall correctly, it's still possible to change the rank of signed statements. A potential issue might be the addition of qualifiers. That unsigned referenced statements can be altered is a separate question that can be addressed differently. --- Jura 10:55, 29 December 2018 (UTC)
I already said this on the contact the dev team page but repeating it here for completeness: Signed statements are in my mind focused at institutions because they are the trusted institutions we get this data from. They should stand behind it with their name. Institution X signs a statement with reference to Institution X because they are the authority on that data. It's a signal we give to the outside world that our data is trustworthy. Now that being said we need to hash out the process for figuring out who gets to sign etc with you all. There isn't anything in signed statements that would make it impossible for editors not representing an institution to sign. (Even though I think it kinda sidesteps the initial goal of having the authority over certain data certify that data.) --Lydia Pintscher (WMDE) (talk) 15:24, 30 December 2018 (UTC)

More than one signature and organizations

I find the idea useful, however I would find it better if there could be more than one user or organization signing the statement, that way all of them would get notified when the statement changes (preferably with a justification of the change). As for how organizations/institutions should sign statements, I would prefer if there were user groups where each member is allowed to sign on behalf of the organization, so that all users who are members of that group get notifications when changes happen. Group membership should be managed by group admins. I would allow WikiProjects to be part of this scheme, so that statements can be signed either individually or on behalf of the WikiProject. To me this seems like public watchlists at statement level, with the public display that someone has verified that statement and wants to be notified if it changes.--Micru (talk) 12:30, 29 December 2018 (UTC)

Ooh, yes, support for WikiProjects in this would be immensely helpful! ArthurPSmith (talk) 15:22, 29 December 2018 (UTC)
It'd be a cryptographic key (PGP). I imagine there to be one per institution that would be shared between everyone in that institution. --Lydia Pintscher (WMDE) (talk) 15:24, 30 December 2018 (UTC)
Lydia, would it be possible for WikiProjects to have keys too? Is it technically possible to have more than one signature per statement?--Micru (talk) 19:09, 30 December 2018 (UTC)
Multiple signatures per statement: We still need to sort out the details but from how I have it in mind right now there wouldn't be a technical reason for this not to be possible. As for Wiki projects: in theory yes. Keep in mind though that there'll be a private key that needs to be kept by the people who are allowed to sign with a certain signature. If it is leaked then the public key will need to be revoked and all the signatures become invalid. So that needs some thought when we get to it. --Lydia Pintscher (WMDE) (talk) 19:16, 30 December 2018 (UTC)

What is the advantage of a cryptographic signature?

What exactly is cryptographic signature supposed to give us here, apart from burning more energy and adding to global warming?

We already track who makes every edit, as part of Wikidata being a wiki. That information is already stored in the edit history. If the edit history says that an edit was made by somebody attached to XYZ museum, then that is already recorded, we already know that. What is this need for cryptographic signing? Are we really saying we don't trust Wikidata to maintain an accurate edit history, so we need to burn the energy to create a cryptographic signature for every edit?

Surely, what we really need is a better way to see the edit history of a particular statement -- our own equivalent of the WikiBlame utility that shows who first added particular words to a Wikipedia article -- except that a Wikidata version should be much simpler to implement because of structured data: one would just need a gadget to attach a button to each statement that would filter through the edit history and return the edits relating to the particular statement. IMO such a tool, able to give the edit history statement by statement, would be much more useful then signed statements -- and much easier to implement.

But if we really want to start adding blue ticks next to particular statements, to show they've been made by particular editors, then again: why does that need the computational expense and environmental waste of calculating a cryptographic signature? If a user is a trusted user, we know that from their user ID, and if we want the system to mark a statement they make with some special marker, we can do it on that basis. Does a cryptographic signature give us anything worth having beyond that, other than entirely pointless shiny buzzword compliance, of the sort that makes ignorant politicians slaver whenever they hear the word 'blockchain', regardless of its lack of relevance in context. We already have the edit history, why would a cryptographic signature be worth burning the cycles to compute? Jheald (talk) 19:41, 30 December 2018 (UTC)

Don't all wikis already make a cryptographic signature on every edit, for other reasons? And, you know, run through the operation loads of times every time someone connects to the website or looks at a page or anything? I think you're severely overestimating the expense involved. (I agree that we really do need a Wikidata-Wikiblame, though, regardless of whether signed statements goes through.) --Yair rand (talk) 01:59, 31 December 2018 (UTC)
"more energy" -> overhead (which is pretty small) only comes up when someone initially writes the signature and if someone needs to validate it, not each time data is accessed, but each time data is accessed it would be visible that a particular organization has (or hasn't) vouched for it. - Jmabel (talk) 05:23, 31 December 2018 (UTC)
The problem is unfortunately much more complicated than that. It is not trivial to understand in a machine-readable way which edits had an influence on a certain statement at the level of efficiency/performance we need. In addition all this tells you is that this edit was made - not more. It doesn't tell you if the statement you are seeing is what was intended by a trusted source. Also I'm by no means on the bitcoin hype - quite the opposite for the reasons you mention and more. But this is not what we're talking about here. PGP has been around for more than 25 years for email signing etc. --Lydia Pintscher (WMDE) (talk) 13:11, 31 December 2018 (UTC)
I think there are different aspects to the data: who makes the statement (source), who imports it into Wikidata (history/WikiBlame tool), and who vouches/endorses what the source says (signature). It might raise the credibility of the data, allow to filter it depending on who vouches for each statement, and it might increase the attractiveness of the project for institutions/organizations. Foreseeing a scenario where multiple institutions vouch for the same statement (or conflicting ones), it would be nice if the signatures had their own place in the interface instead of being mixed with the statement or the references. Lydia, do you think an unfoldable section (like the one for references) might be suitable for signatures?--Micru (talk) 13:09, 1 January 2019 (UTC)
It could be.I'll have to think more about the implications. I'll put it on my list of things to consider. --Lydia Pintscher (WMDE) (talk) 14:28, 1 January 2019 (UTC)
Is the idea to sign statements or to sign edits? If you just sign the statement the label of an item might change afterwards and the result will be that the intent of the statement signing isn't clear anymore. ChristianKl❫ 13:49, 2 January 2019 (UTC)
The statement. And yes what you mention needs to be taken into account by for example taking the labels of the other item into the hash in some way. I was thinking to start with statements that do not link to other entities to avoid this issue at the beginning. --Lydia Pintscher (WMDE) (talk) 18:46, 2 January 2019 (UTC)
It's not only the label of the item towards which the link points but also the label of the item on which the statement happens to be. ChristianKl❫ 19:10, 2 January 2019 (UTC)

What makes Wikidata behave this way?

I am trying to understand what makes Wikidata behave in the way it does. It's actually a question about two separate instances, but the answer is probably the same.

  • For *constraints* on properties, they get encoded and formalized through Wikidata entities (Wikidata items and properties), but then they get _displayed_ under a separate header ("Constraints") when viewing the property's page. How does this happen? For instance, how does Wikidata know to put a "Constraints" header at the bottom here instance of (P31)?
  • For external identifiers of a given item, hyperlinks to external sites get produced when viewing that item's page. That requires a lot of information about identifiers and templates, which I can see is encoded through external identifier data types and formatter URLs. However the displaying still requires a substitution. Where does this take place, how does Wikidata know to do that? Pdehaye (talk) 08:32, 2 January 2019 (UTC)
The sections and which datatypes/properties go into which section are defined in the wiki's configuration. The order of the properties within a section is defined at MediaWiki:Wikibase-SortedProperties. --Lydia Pintscher (WMDE) (talk) 10:18, 2 January 2019 (UTC)
Thanks! Can you be a bit more specific where the settings are changed? I don't see that setting in here. Am I looking at the wrong place? Pdehaye (talk) 13:04, 2 January 2019 (UTC)
Also, it looks like my second question is answered here [1] Pdehaye (talk) 13:04, 2 January 2019 (UTC)
See$29 and$17 --Lydia Pintscher (WMDE) (talk) 18:54, 2 January 2019 (UTC)

Quickest way to find instances?

If I am looking at an item C which is a class, what is the quickest way to find all the items that are instances of C? I can use the Query Service, but that requires a bit of annoying manual work (copy/paste). Is there a quicker way I am somehow missing? Pdehaye (talk) 12:10, 2 January 2019 (UTC)

    • It's actually pretty good, it even has more use cases than I originally asked for! Thanks for the tip. Pdehaye (talk) 16:42, 2 January 2019 (UTC)
  • my favorite tool: for example "wdtaxonomy Q5119 -i" --ImreSamu (talk) 16:45, 2 January 2019 (UTC)
  • Special:WhatLinksHere (there’s a link to it in the sidebar on each page) doesn’t just include instance of (P31) statements, but depending on the item it can still be useful. —Galaktos (talk) 19:19, 2 January 2019 (UTC)
  • I tend to go to Reasonator and view the item there. If you haven't got links to Reasonator enabled already, if you click on "Preferences" at the top of the page, then go to the "Gadgets" tab, and then scroll down, you'll see there's a checkbox you can activate for Reasonator. If you do check that checkbox then a link to view the item in Reasonator will be added to the bottom of the sidebar at the left for every item page. Jheald (talk) 20:18, 2 January 2019 (UTC)
  • I use the {{Item documentation}} template on the Talk page of items - one of the useful links it provides is a “List of instances”. - PKM (talk) 02:43, 3 January 2019 (UTC)

Development of Wikidata for Wikidata

  • When I read the yearly development plan, it seems to me like all the items on the list are features that are on the list are valuable. On the other hand, they all them like they are needed for interfacing with the world outside of Wikidata instead of being focused on the issues that the existing editors have expect maybe the citoid integration.
What existing desires do we have? On the recent wishlist discussion there was the desire for a way to add inverse statements once instead of having to do two edits. Allowing one edit to effect to pages would need work on the foundation of Wikidata, but it would make editors twice as productive when adding such items, which makes it very valuable.
The existing time-format has usability problems when it comes to inexact dates. Adopting ISO 8601-2019 as Andy proposed would make it easier to work with the relevant data and prevent such data to be wrongly entered in our system with the complicated way of entering such data that exists at present. ChristianKl❫ 22:38, 29 December 2018 (UTC)
Hey :) I don't think it's the complete picture to see all the Wikibase development as not for Wikidata. One of the main reasons to do it is to take pressure off of Wikidata to take on all the data and get us more external places for references. For inverse properties I looked over the discussion and I am seeing a lot of question marks still when it comes to the details like: It seems clear we don't want the automated adding of inverse properties to always happen. But when do we want it to happen? Does it only depend on the property? How about ranks and changing ranks? References? I think it'd be super valuable for someone to set up a bot to do this for a while so we can figure out all these with real data. --Lydia Pintscher (WMDE) (talk) 15:33, 30 December 2018 (UTC)
Could you expend on what you mean with "pressure on Wikidata to take on all the data"?
I understand the concern as far as there's currently unclarity about the inverse properties. I will open a RfC to discuss the issue. ChristianKl❫ 16:30, 30 December 2018 (UTC)
Thanks! About the pressure on Wikidata: There are simply a lot of people and organisations out there who want to dump their data into Wikidata. They bring different ideas about how to model data, what license it should be under, how this project should be governed and much more. Some of that we want and some of that we don't. On top of that this amount of data is not sustainable both technically and socially given out current conditions. So we need to offer compelling alternatives. The Wikibase ecosystem is that alternative. And it brings a few very nice benefits for us on top ;-) --Lydia Pintscher (WMDE) (talk) 19:03, 30 December 2018 (UTC)
To me it seems strange to see te fact that people and organisations are interested in dumping data into Wikidata as a problem. Socially it means that people who are interested to contribute have to take part in the relevant discussions and having more people at the discussions is helpful. ChristianKl❫ 13:23, 31 December 2018 (UTC)
  • There is lot data that doesn't actually need much maintenance .. maybe we should focus on that and try to get this added as (or to) items with a reasonable number of statements. As we get more items unconnected to Wikipedia, it seems that worse than empty items with a sitelink to Wikipedia is one that has just an external id, a p31 and a label. There are some fields currently covered by Wikidata that might work better in a distinct Wikibase installation. Before we can discuss these though, I think Commons needs to work out. --- Jura 13:41, 31 December 2018 (UTC)
Example for a possible auto-inversion: participant of needs a participant (human), participating team, or something like cast member. The human vs. team detail could be handled automatically (bot job).
Not really related to the 2019 plans, but major spam attractors like described at URL should be nuked or monitored before they get out of hand. – 01:26, 2 January 2019 (UTC)
As far as features go, it would make sense to be able to semi-protect properties like described at URL (P973) which also was one of the wishlist items. ChristianKl❫ 10:16, 3 January 2019 (UTC)
  • When it comes to the point about automatically adding references based on semantic markup I'm skeptical. Incorrect references are a huge problem and automatic adding of references based on what a computer understands can be problematic. To me that issue doesn't seem to be one to be tackled by core Wikidata developers. I would rather give the topic out as a bachlor/master thesis and put the resulting statements into the "Primary sources". ChristianKl❫ 22:38, 29 December 2018 (UTC)
    • Yeah I don't think the actual adding of the references is up to the dev team. What we'll do is provide the references. Then they can either be added by someone with a bot or we throw them into the Primary Sources Tool (or some other way I have not thought of yet). --Lydia Pintscher (WMDE) (talk) 15:33, 30 December 2018 (UTC)

Numerical IDs

Genius artist ID (P2373), Genius song ID (P6218) and Genius album ID (P6217) seem to have numeric alternatives:

All of the numeric IDs can be found in the HTML source code, and the web API can also be used to query for an artist's songs.

Would it be appropriate to replace the current values for some or all of these properties? It seems that it's possible to change song titles (leaving the old title as a redirect – the ID stays the same), but the server admins do it behind the scenes and it doesn't show up in page histories ([2] [3]).

For songs and albums it would be possible to have a bot automatically replace non-numeric values, but artist names can also be entirely numerical (e.g. /artists/3 has ID 25614, but ID 3 is /artists/Fabolous), whereas there's no overlap for the other properties. Jc86035 (talk) 18:57, 30 December 2018 (UTC)

  • In general, rather than making an existing property unreliable, I'd create a new property for the values in the other scheme, at least if these are stable and generally useful. --- Jura 13:19, 31 December 2018 (UTC)
    @Jura1: Thanks. Since there has been no further comment I've created 13 of the property proposals (Genius artist numeric ID). Jc86035 (talk) 17:20, 3 January 2019 (UTC)

Policy on paid editing on Wikidata?

Is there a policy on paid editing on Wikidata? (i.e. editing as part of your job). Pdehaye (talk) 08:39, 3 January 2019 (UTC)

I'm not sure where exactly it's written but it's my understanding that we allow paid editing but require that a person is transparent about it on their user page. ChristianKl❫ 10:12, 3 January 2019 (UTC)
Those sorts of rules are different on WD than WP. It is hard to "sugar coat" items with structured data compared to the free form writing of an encyclopedia.Lazypub (talk)
The policy comes from the Wikimedia foundation - here. See the section on "Paid contributions without disclosure". ArthurPSmith (talk) 16:50, 3 January 2019 (UTC)

Helen Bøsterud (Q4586352) wrong date of birth

There are 2 dates referenced 1 February 1940 (imported from Norwegian Wikipedia) und 15 February 1940 (referenced by external source Storting biography). Funnily the norwegian Wikipedia also shows the 15th as date of birth. Could someone fix this. --Sabine Fischer (talk) 09:55, 3 January 2019 (UTC)

That is the beauty of structured data over the unstructured free form writing on sites like of Wikipedia. We can show multiple dates here. But we need to know where the information came from. Lazypub (talk)
Multiplle dates is fine, but I assume this lady has only been borne once so far. One date is confirmed by external sources (15. Feb.) the other date (1. Deb) claims no-WP as reference, but there you also find 15. Feb. So where does this suspicious date (1. Feb.) come from and what has to be done to ged rid of it? --Sabine Fischer (talk) 14:08, 3 January 2019 (UTC)
Seems to be a typo. If not, it should probably have been kept. I'm not sure which tutorial to suggest to learn how to contribute. Did you look at some? --- Jura 14:17, 3 January 2019 (UTC)

Efforts to engage journalists in Wikidata?

Are there specific efforts to engage journalists in using Wikidata or even contributing to it? For instance training to the European Investigative Collaborations or Global Investigative Journalism Networks. The only relevant mention I could find is in there Pdehaye (talk) 08:28, 3 January 2019 (UTC)

So far, not to my knowledge. Though there is an upcoming Online News Association conference [4] where we may have a chance to bundle in training on Wikidata and Wikipedia, perhaps in conjunction with the Internet Archive. If you have some ideas on what kinds of use cases would be useful for journalists, we can start to assemble them here. - Fuzheado (talk) 05:49, 4 January 2019 (UTC)

Wikidata at 35C3

The Chaos Communication Congress is the biggest yearly hacker event in Germany. There where also an assembly called "WikipakaWG" with two good presentations about Wikidata.

One is an introduction in Wikidata in general and the Query Service:

And on is a live coding of a tool running on Toolforge:

--GPSLeo (talk) 22:35, 3 January 2019 (UTC)

Thanks, my "what do you want to watch on YouTube today" page is again (at this time of the year) flooded by the Chaos Computer Congress, and it's too easy to miss some gems: Wikidata intro, English (01:29:53); Wikidata tool, English (00:49:07); and Datenpumpen Hackathon, Deutsch (00:39:04). For French or German translations (or audio only or even MP4) check out Hashtag #w35c3, on enwiki in references 35C3 (unlike 34c3, but the "redirect for creation" procedure worked :-) – 00:43, 4 January 2019 (UTC)


More tab -> Empty. I want to translate the word Empty but I don't know which one is on Xaris333 (talk) 06:16, 4 January 2019 (UTC)

@Xaris333: Where are you seeing this? Does text appear when you use English (/w/...&uselang=en or /wiki/...?uselang=en) or another language? Jc86035 (talk) 08:18, 4 January 2019 (UTC)
  • You probably mean the button created by MediaWiki:Gadget-dataDrainer.js. Gadget translations are not hosted by but you can write an edit request directly on the gadget's talk page. --Pasleim (talk) 10:05, 4 January 2019 (UTC)

Thanks! Xaris333 (talk) 13:47, 4 January 2019 (UTC)

Add unit with quickstatements2

Trying to add area (P2046) with quickstatements2. How can I add the unit? For example,

QXXXXX P2046 "20" the unit must be km². Xaris333 (talk) 06:54, 4 January 2019 (UTC)

@Xaris333: Help:QuickStatements says it would be QXXX|P2046|20U712226. Jc86035 (talk) 08:16, 4 January 2019 (UTC)

Template issue with value from Wikidata in English Wikipedia

Hi! There's an issue with a template at English Wikipedia where properties with "no value" or properties where the latest value has an end-time in the past are handled incorrectly. I made a discussion about it at the talk page of the template there: Template_talk:Infobox_software#Problems_with_handling_of_repository_information. I'm cross-posting here in case anyone knows how it's done on other projects, or anything; just wanted to give you a heads up. Thanks! Goldenshimmer (talk) 10:59, 4 January 2019 (UTC)

@Goldenshimmer: It doesn't seem to be an issue on the Wikidata end; "none" is linked because Template:Infobox software adds Template:URL for all Wikidata values. Presumably you could fix this by adding an #ifeq: to the infobox. Jc86035 (talk) 15:11, 4 January 2019 (UTC)

Delete instance of (P31)  episode (Q1983062)

Can somebody delete instance of (P31)  episode (Q1983062) from items on this query, in PetScan it won't work for me. thx Queryzo (talk) 17:20, 4 January 2019 (UTC)

  Done --Pasleim (talk) 18:21, 4 January 2019 (UTC)

Can I export a Wikidata Page ?

Thank you for this documentation, is it possible to export an existing Wikidata page to CSV? Olaniyan Olushola (talk) 08:44, 30 December 2018 (UTC)

One thing you could do is to do a Wikidata Query with "DESCRIBE wd:Q7186" or whatever Q number you're interested in. Then take the output of that and choose Download->CSV file. See the following example. -- Fuzheado (talk) 23:58, 4 January 2019 (UTC)
Try it!
@Olaniyan Olushola: Does that solve your question?--Micru (talk) 12:57, 5 January 2019 (UTC)

Two Warp Factors

Is there a difference between Warp Factor (Q53561461)     and Warp Factor (Q53561822)    ? Can they be merged? Laboramus (talk) 01:35, 5 January 2019 (UTC)

According to, they are different. Ghouston (talk) 02:25, 5 January 2019 (UTC)

How to remove a bad "Westernmost" ?

I noticed there were multiple entries for P1335 (coordinates of westernmost point) for Japan,

Q1. The 4th one (24°28'6"N, 123°0'17"E) is clearly wrong. It is the main town on the island, not the westernmost point on that island. But how do I delete it? At the top of the Japan entry I see a padlock.

Q2. The reference just says: "Imported from Wikimedia project Japanese Wikipedia" (P143, Q177837)

 That is not much use: is there a way to find out more about the reference? I was expecting it to link to a URL and page section, such as or

Q3. P143 is described as "Describes claims imported from Wikimedia projects like Wikipedia, either by bots or manually." Were these bots used when Wikidata was first created, or do they still run? I.e. having deleted bad data, how do we stop a bot recreating it?

The 1st one (33°11'2.3"N, 129°20'27.6"E) is also wrong, at least not without qualification, so could be deleted too. It is East of the Cape Irizaki one, which has a reliable reference. It is West of the "main 4 islands" one (which is defined as the connected land of Kyushu island), but East of the Westernmost point in Nagasaki prefecture (32°14′38″N 128°06′16″E) (Ref: top table of, which is therefore also the Westernmost point in Kyushu (the region, not the main island).

BTW, my main interest is how to evaluate/improve Wikidata data quality; taking a deep dive into this particular property was arbitrary. :-)  – The preceding unsigned comment was added by The Darren (talk • contribs).}

  • Different values for these statements are possible. The qualifier criterion used (P1013) can be set to described how they were determined. Some users might just look for the westernmost town. If there is a clear preference, preferred rank can be set. Depending on the level of sourcing you are looking for, you could simply filter statements or add references you think useful. --- Jura 12:14, 5 January 2019 (UTC)

Possible bug - weird intermittent query glitch

I have a query which runs a Listeria report at w:User:Andrew Gray/MPs, from this query. It's conceptually quite simple - it identifies MPs who we have metadata for on Wikidata, but who don't have a Wikipedia article. The bit to do the Wikipedia crosscheck is the OPTIONAL { ?article ... } and FILTER (!BOUND(?article)) section; the earlier fancy filtering is just to generate some useful metadata (the last seat they served in).

The bit that's confusing me is that at various times over the past few months, it's returned George Hume (Q5540844) as the first entry, although that item has a Wikipedia sitelink and has had for years (it was moved in August, but the moved sitelink seems valid and normal). Sometimes it shows up in the query, sometimes it doesn't. eg/ 31 Dec, no Hume. 1 Jan, Hume reappears. 2 Jan, Hume disappears. 3 Jan, Hume reappears. If I run the query myself just now, I get Hume as the first result, so it's not just Listeria being strange.

So... is this a bug? Is there something silly in my filter that means it's not working? I'm completely baffled. Andrew Gray (talk) 21:31, 3 January 2019 (UTC)

Probably caused by phab:T210044. Multichill (talk) 22:14, 3 January 2019 (UTC)
And the instance solution seems to be to remove the troubled value - sitelink in this case - & then reinsert it, on the presumption that this refreshes the report servers. --Tagishsimon (talk) 04:49, 4 January 2019 (UTC)
Perfect - thanks both. That seems to have stopped it reappearing. Andrew Gray (talk) 14:13, 6 January 2019 (UTC)

->Removal<- of items using blacklisted domains is blocked by the blacklist

There seems to be a weird editing implementation in our editing process. I was attempting to remove a url that is in the blacklist where it had been added against "official website" property, and it fails as it says I am trying to add a domain in the blacklist. D'oh! In the end the solution to do this was change it to a junk url, and then delete that url. Seems weird that a remove action checks against the blacklist.  — billinghurst sDrewth 06:54, 6 January 2019 (UTC)

How to indicate that "item of property constraint" should allow recursion?

(Pinging @Ivan A. Krestinin: for input)

In a property constraint (P2302) : item requires statement constraint (Q21503247) / property (P2306) / item of property constraint (P2305) set-up, is there any way to indicate that traversal via multiple steps of the property to reach the target item is also okay?

e.g. Canmore ID (P718) currently has the requirement of located in the administrative territorial entity (P131) Scotland (Q22).

How to indicate that P131/P131 Q22, or P131/P131/P131 Q22, etc, are also okay? Jheald (talk) 23:31, 5 January 2019 (UTC)

This can only be done with complex constraints but maybe it could be added as an extension to type constraint (Q21503250). @Lucas Werkmeister (WMDE):. --Pasleim (talk) 20:04, 6 January 2019 (UTC)

Structure for the president of Communal Council

Which one is correct?



Xaris333 (talk) 03:12, 6 January 2019 (UTC)

I think that the best option is number 4 - new item President of Communal Council of Ayios Yeoryios. As second best I use the first one.--Jklamo (talk) 12:06, 6 January 2019 (UTC)

Then I should create items for all communities like President of Communal Council of Ayios Yeoryios? Is that worth it? Some of them have population less than 100 people. Of course I will do what ever wikidata structure demands. Just asking to know for sure... Xaris333 (talk) 19:03, 6 January 2019 (UTC)

I wouldn't say that #4 is the only possible way to do this, but I'd agree that it's the best option. --Oravrattas (talk) 21:44, 6 January 2019 (UTC)

Wikidata weekly summary #345


  Comment It seem that this grant is really interesting and relevant for Wikidata. It’s focused on data conflicts and reconciliation between the wikipedias, and the differences with Wikidata and how to address them. author  TomT0m / talk page 11:55, 7 January 2019 (UTC)

Is someone working on European call INFRAEOSC-02-2019?

Is anyone working on European call INFRAEOSC-02-2019, as a follow up to the failed 2015 proposal Enabling Open Science: Wikidata for Research (Wiki4R) (Q26707522)? Any idea User:Lydia_Pintscher_(WMDE), User:Daniel_Mietchen? There is ongoing work to prepare a Jupyter-centered proposal to INFRAEOSC-02-2019, as a follow up to the OpenDreamKit project. I think there is strong convergence between the two around PAWS. I personally was in OpenDreamKit, but have now founded a nonprofit (PersonalData.IO (Q59695802)) that could really benefit from this intersection. Pdehaye (talk) 09:10, 3 January 2019 (UTC)

Cantonese Wiktionary linking problem

Wikidata linking at Cantonese Wiktionary has been enabled, but every time I try to Wikidata link its main page to the other main pages, I get an error message that reads: "Error: $1. Either provide the Item "ids" or pairs of "sites" and "titles" for corresponding page" when I hit the button to confirm the linking. I suspect that the reason for this may be a language code conflict, since Cantonese Wikipedia is at zh-yue while Cantonese Wiktionary is at yue. Is this the case, and how could this issue be fixed? DraconicDark (talk) 15:24, 6 January 2019 (UTC)

Hello, and thanks for your report. The issue is known and we hope to solve it very soon. Lea Lacroix (WMDE) (talk) 15:18, 7 January 2019 (UTC)

Wikidata weekly summary #346

Please delete : Q60484360

Hello, sorry I'm not familiar with Wikidata. I made an item and it already exists. Could you please delete ? Q60484360

Kind regards, --Bédévore (talk) 20:18, 7 January 2019 (UTC)

  Done--Ymblanter (talk) 20:22, 7 January 2019 (UTC)
When accidentally creating a duplicate item, can also just merge it into the already existing one instead of requesting the deletion. Ahoerstemeier (talk) 21:51, 7 January 2019 (UTC)

Is a master's thesis notable enough?

I stumbled upon Larvae of Sarcophagidae (Insecta: Diptera) and Their Relationship with the Pitcher Plants (Sarraceniaceae: Sarracenia) of Southeastern U.S. Bogs (Q56695871). Is a master's thesis (Q1907875) notable enough? --Succu (talk) 21:40, 7 January 2019 (UTC)

On its own I'd be doubtful, but being used as a source (as it is here) I don't see any problems. Andrew Gray (talk) 21:49, 7 January 2019 (UTC)

Current issues with the Query Service

Hello all,

The Wikidata Query Service is currently encountering some data corruption issues that impact the results you can see when running a query. It's being investigated. You can read the full announcement or check the ticket. Thanks for your understanding. Lea Lacroix (WMDE) (talk) 11:12, 8 January 2019 (UTC)

How to question

I am trying to add copyright status (P6216) statements to some old publications. Something like:

copyright status
  public domain   edit
applies to jurisdiction countries with 100 years pma or shorter
determination method 100 years pma
▼ 0 reference
+ add reference
  public domain   edit
applies to jurisdiction United States of America
determination method published more than 95 years ago
▼ 0 reference
+ add reference
+ add value

QuickStatements is usualy a go-to tool for most of my needs on Wikidata, but unfortunatelly QuickStatements code

Q70784	P6216	Q19652	P1001	Q30	P459	Q59693547
Q70784	P6216	Q19652	P1001	Q60332278	P459	Q29940705

gives me

copyright status
  public domain   edit
applies to jurisdiction countries with 100 years pma or shorter
United States of America
determination method 100 years pma
published more than 95 years ago
▼ 0 reference
+ add reference
+ add value

Anybody knows how to batch add many such statements to a list of item IDs using QuickStatements or any other tool? So far the best approach I found was using User:Matěj Suchánek/moveClaim.js to add claims to individual items. --Jarekt (talk) 14:46, 8 January 2019 (UTC)

@Jarekt: I ran into this with adjacent station (P197) in August. I created placeholder 1 (Q55560743) and placeholder 2 (Q55560744) for that and changed all the values manually afterwards, although for your use case creating new placeholder items and temporarily turning them into redirects (so a bot fixes the links to them) might work. Jc86035 (talk) 15:45, 8 January 2019 (UTC)
Jc86035, Thanks for your help. I was thinking about creating Wikimedia permanent duplicate item (Q21286738) for public domain (Q19652) and than use some separate process to teplace the duplicate with the original. Temporarily turning such items into redirects seems like a great way to do it, if it works. --Jarekt (talk) 16:12, 8 January 2019 (UTC)
@Jarekt: you could also use OpenRefine to upload these statements - they would not be merged into one statement as OpenRefine considers qualifiers when comparing statements. − Pintoch (talk) 18:01, 8 January 2019 (UTC)
Pintoch I was trying to learn OpenRefine, which I still find quite confusing, but maybe I should spend more time to understand it. --Jarekt (talk) 18:57, 8 January 2019 (UTC)
@Jarekt: if I can be of any help let me know! I can also recommend StackOverflow where you should get high quality answers quite quickly. If you find anything confusing in the tutorials about the Wikidata integration in OpenRefine I would be very interested to know so I can fix that, too. − Pintoch (talk) 19:01, 8 January 2019 (UTC)

What is the difference between Q9646072 and Q7866116?

What is the difference between these two:

They're both called "Category:People's Artists of Russia" and both have existed for a while. One difference I see is in the info for French Wikipedia:

This came up because I was researching whether c:Category:Valentin Dikul should have two categories that look the same. Thanks. --Auntof6 (talk) 22:58, 7 January 2019 (UTC)

On the Russian Wikipedia, ru:Категория:Народные артисты России is a parent of ru:Категория:Народные артисты Российской Федерации. It think the subcategory may be for "federal" people's artists, but there are other possibilities such as people's artists of particular regions. Ghouston (talk) 01:33, 8 January 2019 (UTC)
Indeed, ru:Категория:Народные артисты России contains ru:Категория:Народные артисты Российской Федерации (which is for Russia after 1991, when it was an independent state) and also category for Peoples Artists of the Russian Soviet Federative Socialist Republic (until 1991, when it was part of the Soviet Union).--Ymblanter (talk) 20:40, 8 January 2019 (UTC)

@Ymblanter, Ghouston: Thanks, both of you. I've adjusted the entry for the USSR one to reflect that. --Auntof6 (talk) 02:12, 9 January 2019 (UTC)

I don't think ru:Категория:Народные артисты России is Soviet as such, but is apparently a container for both pre and post Soviet times. Ghouston (talk) 07:21, 9 January 2019 (UTC)

Wrong name

Immaculate Conception of El Escorial (Q11770877) has a real name and a wrong name. The wrong name was used for a while, and it's possible that someone might search for it, but it's definitely wrong (it says that the painting came from the city of Granja, which isn't true). Is there a property for "wrong name"? WhatamIdoing (talk) 10:28, 8 January 2019 (UTC)

@WhatamIdoing: I think you would set the rank of the "wrong" native label (P1705)(?) statement to deprecated and add a reason for deprecation (P2241) qualifier. If an appropriate Wikidata reason for deprecation (Q27949697) doesn't exist yet you would probably have to create a new item describing the reason for deprecation. Jc86035 (talk) 10:37, 8 January 2019 (UTC)
This sounds complicated. WhatamIdoing (talk) 12:34, 8 January 2019 (UTC)
@WhatamIdoing: I agree. I've tried adding something. Jc86035 (talk) 14:52, 8 January 2019 (UTC)
And I've added a reference for the incorrect statement. - PKM (talk) 23:55, 8 January 2019 (UTC)
Thank you both. I really appreciate it. WhatamIdoing (talk) 07:29, 9 January 2019 (UTC)

How to batch edit?

I would like to batch edit (by hand) a few 100s entries. I am looking for a tool that could help me do this. I am assuming this tool exists, but can't find it.

This would apply in circumstances where the data model is clear enough that basically all the relevant data could be entered into a CSV. The display would be some interactive spreadsheet. The rows would be produced with a (known) SPARQL query, and each column in my CSV would correspond to a specific path of statements -> property -> qualifiers*. If the entry for a row/column combination exists, it appears already filled in (and maybe editable). If the entry does not exist, then it is editable, according to options defined on a per column basis (possibly a subselection is done according to a given SPARQL query).

Does such a tool exist? Pdehaye (talk) 11:31, 9 January 2019 (UTC)

QuickStatements is the most used tool when it coms to batch edit. For checking the results against what is already existing in Wikidata, you can look at OpenRefine. Lea Lacroix (WMDE) (talk) 11:48, 9 January 2019 (UTC)

Appointed by

Can someone help to change the restraints on Property:P748, currently it is to only be used as a qualifier. See New York City Commissioner of Parks and Recreation (Q60492702) where it needs to be able to be used for positions that are appointed by a specific person where we have an entry for that position. We need both. --RAN (talk) 13:22, 8 January 2019 (UTC)

The "instance of": "wikidata qualifier" says "usually should be used as qualifier". It's no constraint on appointed by. Background, I recall the related "position held", where I confused an "occupation" (as director, qualified with "of" "company") with a "position" (public office). Your use looks good for me. – 11:01, 10 January 2019 (UTC)


Could videos from YouTube Music (Q28404534) be indicated through a qualifier to YouTube video ID (P1651)? None of online service (P2361), platform (P400), distributor (P750), and content deliverer (P3274) seem to fit very well. Jc86035 (talk) 13:47, 8 January 2019 (UTC)

Distribution lists lots of examples (Steam, Microsoft Store, Google Play, etc.), and Distribution: YouTube Music (Q28404534) makes sense (for me). I'm not so sure about YouTube video ID (P1651) itself, let YouTube drown ISNI before flooding Wikidata. 10:44, 10 January 2019 (UTC)

Item delete request

Please delete Q60525617. I can’t finish to compile.  – The preceding unsigned comment was added by (talk • contribs) at 19:06, 9 January 2019‎ (UTC).

  DoneMisterSynergy (talk) 19:09, 9 January 2019 (UTC)

Not autocreated

Hi. I created a WP article for Alan Garrity on 9 Jan. Normally a Wikidata item is autocreated within 24hrs but this hasn't happened. I am reluctant to do it manually and risk duplication. Is there a backlog on the bot? TIA. Gbawden (talk) 06:51, 10 January 2019 (UTC)

@Gbawden: Wikidata items don't get automatically created as not every new Wikipedia article needs a new Wikidata item. There might already be an existing Wikidata item for the topic either because another Wiki already has an article or because a Wikidata item exists that's not linked to any Wikipedia article.
Wikidata items have also different naming conventions. While on Wikipedia all article names get capitalized on Wikidata only proper nouns get capitalized.
If a Wikipedia article however stays for a while without an Wikidata item there's a bot that creates a new item. You are still encouraged to manually check whether there's an existing item that already exists or create the item properly otherwise. ChristianKl❫ 08:23, 10 January 2019 (UTC)

Help Needed with Navigation Box (collapse/uncollapse)


Maybe someone could give me a hand in completely uncollapsing the navigation box on the following page: Wikidata:WikiProject_Cultural_heritage#Navigation.

It used to be uncollapsed; but since a while it is collapsed, and I don't know how to make it uncollapsed by default again. It might be an issue with the template itself. Any help will be appreciated! --Beat Estermann (talk) 06:58, 10 January 2019 (UTC)

I could make it uncollapsed, but now the link to collapse is gone. --Pasleim (talk) 09:06, 10 January 2019 (UTC)
Thanks. That's better than before. But it's a pity that the collapse/uncollapse mechanism is not working any more. I had a look at the code of the base template last summer, but couldn't figure out what had broken the mechanism. I just hoped that someone else would bump into the same issue and be able to fix it... --Beat Estermann (talk) 09:12, 10 January 2019 (UTC)
I restored the old version of Module:Navbox. Probably adaptions to MediaWiki:Common.js or MediaWiki:Common.css need to be made. --Pasleim (talk) 09:36, 10 January 2019 (UTC)

Auto-adding complementary values

Genius artist numeric ID (P6351) has been created, complementing Genius artist ID (P2373). Is there a bot which can automatically add values for one property based on existing values of another property? (From the current links, the regex is \{"name":"artist_id","values":["(\d+)", and from the new property's links, the regex is "slug":"([0-9A-Z][0-9a-z-]*[0-9a-z]|[0-9A-Z])".) Jc86035 (talk) 17:58, 10 January 2019 (UTC)

commons cat (P373)

I propose a new task by a bot or otherwise, that is, when a commons category is linked to an item, and its P373 is still empty, then add P373.--Roy17 (talk) 21:56, 3 January 2019 (UTC)

DeltaBot has done it every hour. Matěj Suchánek (talk) 10:20, 6 January 2019 (UTC)
It seems that the bot's action trails far behind actual edits, adding P373 more than half a year later. Yesterday (9 Jan) it did not add a single P373. It would be much better if it could function like what MatSuBot does with missing labels.--Roy17 (talk) 22:53, 10 January 2019 (UTC)

How to handle usurped "Official Website"

Will Sharpe (Q14946917) has a official website (P856) that has been usurped (domain expired, now for sale and hosting ads). What's the right way to indicate this short of deleting the property? An end date of some sort? I have no idea when it expired, so it would have to be some kind of "on or before 9 January 2019" type thing. Or is there a general "This is no longer valid" marker here beyond the Deprecated rank? I have set the rank of the property to Deprecated, but am uncertain whether this is supposed to be sufficient. (PS. please ping, not a WD regular) --Xover (talk) 12:12, 9 January 2019 (UTC)

As far as I understand it, deprecated means that the statement was never true, but was wrongly stated somewhere. But since this website was correct in past, deprecated would be wrong. In this case, it would be better to set a new "official webpage" to <None> with preferred rank, and set a "end time" to the usurped URL. 15:30, 9 January 2019 (UTC)
Thanks. But in that case, is there any way to indicate "at some undetermined point prior to this date"? We don't know when it lapsed, we just know when we noticed. --Xover (talk) 20:45, 9 January 2019 (UTC)
you can use “point in time” for the date we noticed. - PKM (talk) 22:38, 9 January 2019 (UTC)
I checked on Internet Archive, there's been no relevant content since 2014. Ghouston (talk) 00:35, 11 January 2019 (UTC)

QR Code of resonator

Hi. I have noticed that reasonator provides a QR code on the right of the page. Is there any way to access bulk data about the traffic of people who might scan such code if used on a poster or a website? Many on line services ask for fee to access such data when a QR code is generated, so I assume that on the long term providing such information could be a target also of our open access tool? Does anyone have any link about that? the question popped up while investigating the pros of wikidata tools with a fellow scientist.--Alexmar983 (talk) 15:10, 10 January 2019 (UTC)

As far as I know, QR codes on Reasonator are provided by QRpedia (Q2182). To find out how many people use these QR codes you will have to get in touch with the developers of that service. --Pasleim (talk) 12:07, 11 January 2019 (UTC)

Same book, same edition (?), different scans/external IDs. Merge?

Should we merge Q51517187 and A peep at Uncle Sam's farm, workshop, fisheries, &c (Q51517185)? I had a look at the scans at Internet Archive, they appear to be the exact same edition, though different physical books. Please merge if appropriate. --Magnus Manske (talk) 15:43, 10 January 2019 (UTC)

  Merged per [5]. --Pasleim (talk) 12:09, 11 January 2019 (UTC)

Authority IDs for newspaper apparently gives two authority IDs (one from the Library of Congress itself, the other from OCLC) for The Argus (Q3519810), but I don't see how they line up with our properties. Could someone follow up on this, and I can learn from the example so I don't have to ask again? Thanks. - Jmabel (talk) 09:01, 11 January 2019 (UTC)

@Jmabel: Done. diff. Jheald (talk) 14:59, 11 January 2019 (UTC)
@Jheald: Thanks! Any idea about that constraint violation? Looks to me like the problem is probably in the contstraint, not the value. - Jmabel (talk) 17:20, 11 January 2019 (UTC)
@Jmabel: I have added serial (Q2217301) as an allowed type for Library of Congress Control Number (LCCN) (bibliographic) (P1144), which should sort it. Jheald (talk) 18:05, 11 January 2019 (UTC)

Do we really need a new subclass whenever we add a adjective?

I have had a really unsatisfactory conversation where I was told that I do not know what I am talking about.. Which is in fact a personal attack. This has been made worse by removing statements I care about in favour of statements I disapprove of. It is easy enough to revert all changes but hey, lets talk.

Over time I have created many, many awards. I have added many many people to awards.. Check my history. What I have seen is that many awards are a bit ambiguous. It does not really work when you add an adjective like "science" of "movie" or "art" that you have clean sub classes. Also many awards are not classed as awards while they are linked with "award received". A good example is OBE and all these other new year thingies in Anglo countries.

Given the amount of animosity I received, I want to remove all the "science awards" and replace them with "award". What I do not mind is an explanation why we need these sub classes. Arguments better than "it is a sound ontological practice". It is not. At best sub classes are proposed and when they are not obviously needed, they are removed. This by the way is sound ontological practice where splitters and lumpers face of. Thanks, GerardM (talk) 14:05, 6 January 2019 (UTC)

  • It seems like you disagree with the general way subclasses are used on Wikidata.
Having a subclass of science awards allows users to make that ask: "Alumni of which universities get the most science awards?" ChristianKl❫ 14:21, 6 January 2019 (UTC)
So it is not relevant for alumni to have an OBE.. Really?!
It is more "useful' to show which alumni of a university received awards in the first place. You also get into the awkward situation where one most relevant award may be split up in parts for this to work.. eg Nobel prize.. Thanks, GerardM (talk) 16:05, 6 January 2019 (UTC)
Nothing I have said, implies that an OBE isn't relevant. It can be interesting to see which university does better at which kinds of awards.
A person who's interested in all kinds of awards can still ask that question even where there are sublclasses. ChristianKl❫ 16:07, 6 January 2019 (UTC)
I think the award classes have been done in an ad-hoc way based on items which have been created for Wikipedia. There are 469 subclasses of award [6], including battle honour (Q262775) (little used in Wikidata), literary award (Q378427) and science award (Q11448906) which are used quite a bit. There are also subclasses for things like trophy (Q381165) and certificate (Q196756). It's quite confusing and probably arbitrary. Is IEEE Particle Accelerator Science and Technology Award (Q15819768) really a science award, shouldn't it be a "science and technology award"? Can we create items for "physics award" or whatever? Or should we just use field of work (P101) to describe what an award is for? Ghouston (talk) 00:08, 7 January 2019 (UTC)
The idea that certificates are always awards is highly dubious. It makes things like marriage certificate (Q1299632) into awards. Ghouston (talk) 00:16, 7 January 2019 (UTC)
This is an interesting general question, maybe suitable for an RFC. With (real) people we decided just having one class to use instance of (P31) with was the right approach (human (Q5)), and then you filter/group people based on other properties. For almost every other type of entity we have gone the other way, with hundreds or thousands of subclasses, and sometimes it's hard to know which one to use (but it's fine to use multiple parents if that's what makes sense - so an award can be both a "science award" and a "technology award" for example). Is this inconsistency between human beings and other entities a concern? Do we have good reasons to adopt the human approach in other areas (and would that require many new properties)? I know this has bugged me for a long time, but I don't have a strong opinion on which way is better. ArthurPSmith (talk) 16:05, 7 January 2019 (UTC)
Instead of multiple parents, I'd see it the other way around. Science awards are a subset of "science and technology" awards, likewise for technology awards. IEEE Particle Accelerator Science and Technology Award (Q15819768) would be a direct instance of "science and technology" awards. The question of when to use subclasses and when to use properties is not clear to me either. They appear to be different ways of expressing the same thing. Automated tools may find it easier to follow the subclassing hierarchy than to code the relevant properties individually. Ghouston (talk) 02:02, 8 January 2019 (UTC)
  • It also seems strange to have a mixture of methods, using both "subclass" and "field of work". Perhaps we should stop using items like literary award (Q378427) as a parent class and put "field of work = literature (Q8242)", or create all kinds of new items like "experimental psychology award" and use only subclass statements. Items like literary award (Q378427) can't be deleted because they are used in Wikipedia, but a bot can always change statements in Wikidata to enforce consistency. Ghouston (talk) 20:40, 8 January 2019 (UTC)
    « field of work » does not reflect the specialization hierarchy between the professions. Whereas it’s a fact that a surgeon is also a physician. author  TomT0m / talk page 13:26, 9 January 2019 (UTC)
The hierarchy would still be there, because the value of the field of work property is part of a hierarchy, e.g., experimental psychology (Q475042) is a subclass and specialty of psychology (Q9418). One question is which method is easier to use? Ghouston (talk) 00:46, 10 January 2019 (UTC)
Well, I have more concerns with subclassing sciences by their specialties, ontologically (the « mathematics » term is highly polysemic, a discipline refers both to a body of knowledge about a topic of interest, the act of studying this body of interest). I don’t know in which sense Algebra is a subclass of mathematics for example, this needs careful examination. Also being a math teacher is different from having several life and being a history teacher first, then becoming a math researcher (unlikely in this example but it should not be too hard to find examples of similar nature), it’s not really easy to model such subtilety with « field of work » without creating item such as « math teaching » which are not really different from the « math teacher » one, for example. author  TomT0m / talk page 12:10, 10 January 2019 (UTC)
It needs some thought, but if the branches of science can't be put into a hierarchy, then the awards can't be either. By using subclass, we'd just be creating, for every field like "experimental psychology", another item "experimental psychology award". We may also have an item "experimental psychologist". It seems possible to subclass the first and last items, in principle: we can have a set of all the psychology awards, and the experimental psychology awards are a subset of them. Likewise, we can have all the people who work in the field of psychology, and the experimental psychologists are a subset of them. For the field itself, it depends what an item like "experimental psychology" is supposed to represent. Perhaps its the body of knowledge of the field, the collection of results which have been obtained such as theorems and experimental results, as described by articles etc., and that would be a subset of the body of knowledge of psychology in general. Ghouston (talk) 02:46, 11 January 2019 (UTC)

This presumably relates to discussion at and at User talk:Vladimir Alexiev#Scientific_award (@Vladimir Alexiev, fnielsen: FYI.) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:53, 7 January 2019 (UTC)

Arguably, there are no "science awards" there are ecology awards, psychology awards, psychotherapy awards ... Thanks, GerardM (talk) 13:21, 12 January 2019 (UTC)

Musings: Difference between PetScan & Wikidata Query

Hello! I was just using PetScan earlier to generate lists of articles matching certain criteria. I had to stop and wonder what's the difference between PetScan and Wikidata? I understand that PetScan looks only in existing articles while Wikidata queries can be for entries with or without an existing article. Is that correct? If it is correct, then Wikidata queries can function like PetScan too, no?--Reem Al-Kashif (talk) 15:58, 7 January 2019 (UTC)

Wikidata query service is a efficient tool to find items with/without certain statements, labels or sitelinks but it only weakly integrates other Wikimedia projects. PetScan is a tool not only for Wikidata but is used Wikimedia wide. It is able to combine criteria from various sources, e.g. Wikipedia categories and templates and also Wikidata query service. What is possible with both tools is probably best seen by looking at examples (Petscan, Query service). --Pasleim (talk) 13:02, 8 January 2019 (UTC)
Thank you :)--Reem Al-Kashif (talk) 21:23, 11 January 2019 (UTC)

Request for Checkuser rights

Dear all, I think it would be usefull if Wikidata has checkusers. I listed my request for rights on this page Wikidata:Requests for permissions/CheckUser. Please express your opinion and/or ask your questions. In addition could somebody give advice where to mention this on other relevant pages? Thanks, Ellywa (talk) 00:54, 12 January 2019 (UTC)

Ellywa: This page is to discuss/inform about all aspects of Wikidata, so this is the most proper page to inform about it. Project chat is in different languages, but this is the global page. Esteban16 (talk) 15:15, 12 January 2019 (UTC)
Thanks. I suppose this is the right spot then for this announcement. Ellywa (talk) 15:22, 12 January 2019 (UTC)

Importing Julian dates

I'm currently setting up a large upload of dates pre-1582; as such, they're all defined as Julian, and they're all at day-precision. If pre-1582 dates are added manually, they default to being marked as Julian; if they go in through QuickStatements (either v1 or v2) they seem to be marked as Gregorian example. This is a bit of a problem, as ideally I'd like to be clear that all the dates are defined appropriately and consistently.

Is there an import tool which would be able to do this? wikidata-cli doesn't seem able to define Julian vs Gregorian, unless it's a feature I haven't yet tracked down.

Alternatively, is there a bot script which I could run afterwards to reset all defined dates to Julian? Seems like this might be a useful maintenance task anyway (eg all dates before X sourced to reference Y should be Julian, all dates after Gregorian). Andrew Gray (talk) 12:30, 12 January 2019 (UTC)

Delete P973s

Can somebody delete these described at URL (P973) statements? Just those with link not others like in Q40523561. I transformed the links into Crew united title ID (P6359). thx Queryzo (talk) 20:45, 14 January 2019 (UTC)

  Done --Pasleim (talk) 21:45, 14 January 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

Searching for file names

Is there a way to search for a file name? For instance if I want to find all of the entries that have the same "page banner" (e.g. the file: Euro cent coins banner.jpg), how would I perform this search? I looked in multiple places (Wikidata:Introduction, Tools, and a couple of others), but I did not find a simple way to perform a search like this. I saw that there is a SQL search function available, but its been more than 25 years since I have used SQL, and I don't know if that will give me the results I am trying to find. Thanks! Zcarstvnz (talk) 08:56, 16 January 2019 (UTC)

Have a look at, for instance w:en:Help:Searching. I suspect parameters such as insource: or linksto: will work. (Remember to select the namespaces where the files you seek might be - probably start from Special:Search --Tagishsimon (talk) 09:05, 16 January 2019 (UTC)
The query service uses SPARQL and not SQL. It's a different query language. ChristianKl❫ 09:42, 16 January 2019 (UTC)
Note also that commons images list the pages on which they're used. --Tagishsimon (talk) 14:55, 16 January 2019 (UTC)
e.g. commons:File:Euro cent coins banner.jpg#File usage on other wikis. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 16 January 2019 (UTC)

This query will give you all items that share a page banner, sorted by number of items per banner. --Magnus Manske (talk) 15:44, 16 January 2019 (UTC)

Thanks for all of the suggestions and explanations. I appreciate all of the help! Zcarstvnz (talk) 09:46, 17 January 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)


George Hyde Pownall (Q38186523) and Q60644992 seem to be the same person, but not sure. --Magnus Manske (talk) 15:40, 16 January 2019 (UTC)

Given that there are currently dfferent dates of birth and death, there seems to be no basis to merge. I created a thread on the Wikipedia page of the person who created the linked Wikipedia page: en:User talk:Philafrenzy#George Hyde Pownall ChristianKl❫ 15:55, 16 January 2019 (UTC)
The bases for the merge would be, for instance, the wikipedia article for George Hyde Pownall (Q38186523) - w:en:George Hyde Pownall matches (DoB/DoD aside) the description in ID links from Q60644992 such as [7] and [8], or matches on pictures in Q60644992's [9]. DoB & DoD are all over the place, but they're almost certainly the same person. has a solid ref for the 1939 death date, but that source doesn't specify its references. The best ref we have from Q60644992 is, which without skipping a beat specifies both pairs of DoB/DoD - 1876-1932 and 1866-1939. --Tagishsimon (talk) 16:27, 16 January 2019 (UTC)
Philafrenzy concurs they are the same, and I've merged them. I'll do some fiddling with DoB and DoD in the record, taking the detailed research paper [10] as preferred and the many catalogue entries as deprecated. --Tagishsimon (talk) 16:41, 16 January 2019 (UTC)
@Tagishsimon: Invaluable are, sadly, very unreliable with dates. [Aside: see his en.WP article talk page regarding the dates of his time in Australia!] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:58, 17 January 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

Can't mark WS item proofread

I can't mark Virgil (Q60432130) as "proofread" (the WS equivalent of a "good" article). I'm not getting any options at all when I try to edit the existing badge for the en.WS link. When I "edit", then go to the badge, I get only "..." instead of the drop-down list of options I normally get. --EncycloPetey (talk) 04:03, 17 January 2019 (UTC)

Me too. —Justin (koavf)TCM 04:54, 17 January 2019 (UTC)
This is phabricator:T213998. --Pasleim (talk) 09:42, 17 January 2019 (UTC)
The patch for this should roll out in the next few hours. ·addshore· talk to me! 10:16, 17 January 2019 (UTC)
This should now be fixed. ·addshore· talk to me! 13:02, 17 January 2019 (UTC)
  DoneI was able to change the badge now. --EncycloPetey (talk) 14:36, 17 January 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

Filtering query results by article size?

Hello! I put together this query to generate a list of English Wikipedia articles about male writers. Is it possible to put another criterion that all results should be for articles which sizes are equal to or more than 10k bytes? I understand that this is better done by PetScan, but for some reason my PetScan query on "Male writers" category keeps showing me "bad gateway". Thank you for your help.--Reem Al-Kashif (talk) 21:30, 11 January 2019 (UTC)

@Reem Al-Kashif: Try downloading the PetScan query result directly (e.g. CSV) if you weren't doing that already. Jc86035 (talk) 04:05, 13 January 2019 (UTC)

Converting P361 uses to P1433

Would it be appropriate to convert all part of (P361) uses, where the subject is a track and the object is album, to use published in (P1433)?

The issue arises because there is no exact inverse to tracklist (P658). Consequently, both part of (P361) and published in (P1433) are currently used to link songs[1] to albums. This is inconsistent, and it would be better to consistently use one property.

Furthermore, some items for songs/compositions,[2] such as Make You Feel My Love (Q1886329), have been separated from all of their recordings (e.g. Bob Dylan's version, and Adele's) to better organize their data and to match the structures of other databases. However, users adding data with Harvest Templates often unintentionally incorrectly add part of (P361) to the items for compositions, when the items for tracks already contain the same link. (See this discussion for context.) Harvest Templates does prevent edits if they would introduce constraint violations, but it would be impossible to have a non-complex constraint for part of (P361) because it could be correctly used on items for e.g. movements of classical compositions. On the other hand, the purpose of published in (P1433) on song items can be unambiguously inferred without knowing the instance of (P31) for the statement value.

When doing this conversion, how would it be possible to retain all qualifiers, ranks and references? Would it be desirable to do so? The qualifier most often used, I think, is series ordinal (P1545), for indicating track numbers. series ordinal (P1545) is not currently a valid qualifier for published in (P1433). Also, if the appropriate tracklist (P658) is present on the album item (or edition items, if any), the qualifier would unnecessarily duplicate data without the duplication being structurally advantageous in MediaWiki. Jc86035 (talk) 17:29, 12 January 2019 (UTC)

  Support Strongly support this! As for preserving qualifiers - Purely based on what I've come across myself I doubt there are that many, if someone could write a Query listing all affected items I'd be more than happy to try to clean this up manually (unless, of course, we're talking thousands...) Moebeus (talk) 17:45, 12 January 2019 (UTC)
@Moebeus: 16,283. Jc86035 (talk) 18:16, 12 January 2019 (UTC)
@Jc86035 : heh, 16 thousand is not nothing ;) But what I meant was Items that have "part of" AND one or more qualifiers, like "series ordinal". For Items with no qualifiers a straight conversion to "published in" shouldn't cause any headaches, unless I'm missing something? Moebeus (talk) 18:27, 12 January 2019 (UTC)
@Moebeus: Oh, I didn't read that properly. (Also, there are 53,936 singles, which would be 64,036 after removing duplicates.) I don't know how to check for arbitrary qualifiers. Jc86035 (talk) 18:34, 12 January 2019 (UTC)
@Moebeus: There are 1,433 songs and 1,272 singles with a series ordinal (P1545) qualifier, totaling 2,019 after removing duplicates. There are 744 + 576 = 941 items which have the semi-inverse tracklist (P658) statements linking to the aforementioned items, which leaves a little more than half to have the inverses added (with references, etc., also transferred). Jc86035 (talk) 18:59, 12 January 2019 (UTC)
@Jc86035 : Brilliant work! Those numbers are a lot more manageable, should be within the realm of possibility to fix them manually although it might take me a couple of hours/days/a month :/ Moebeus (talk) 19:10, 12 January 2019 (UTC)
@Moebeus: It depends on how "fixed" you want the items to get. If you just want to add the inverses and remove the qualifiers, then you could do this automatically with the query service and QuickStatements. The "other data" issue remains, although I've managed to query almost all of the reference/qualifier data available for each statement (songs, singles). There are still some values which need to be otherwise obtained (e.g. the wdv: values), but it's a useful (if crude) way of getting all of the necessary data solely through the query service. Jc86035 (talk) 19:47, 12 January 2019 (UTC)
  Support: But with a question: why shouldn't published in (P1433) accept series ordinal (P1545) as a qualifier? I can immediately give the example of hymns published in a hymnbook which are invariably given an ordinal number so that church congregations can find the next hymn to be sung. There must be many similar examples of publications which are collections and where the series ordinal is a significant piece of data. From that perspective the tracks on an album are neatly analogous, and P1433 then looks a very sensible property to use for tracks. It would be a shame to lose potentially useful qualifiers if a solution would be to make the argument for removing that constraint. --RexxS (talk) 22:09, 12 January 2019 (UTC)
@RexxS: I initially thought that series ordinal (P1545) wouldn't make sense due to the series (the album) being the object of the statement rather than the subject, but since it's qualifier-only it wouldn't matter that much. Jc86035 (talk) 03:39, 13 January 2019 (UTC)

Lexemes and Concepts

Given the Lexeme, like (L3037), should a concept also be created for the concept of "liking"? I suppose I'm asking where the line is drawn between a lexeme and an item (or if there is a line). Thanks for your help! U+1F360 (talk) 18:50, 11 January 2019 (UTC)

@U+1F360: We've had some discussions about this on Wikidata talk:Lexicographical data and related pages. Basically lexemes are words in a language, and items are concepts independent of language. Via item for this sense (P5137) each sense of a lexeme can be linked to an item - and multiple senses may correspond to the same item, either in the same language (synonyms) or in other languages (translations). But for the most part up to now, items have also almost entirely been about concepts that would be represented as nouns in a language. We have an item for gratitude (Q2728730), but not for thank. Of course it turns out there is an item like (Q3249878) as an English word, but that's because it has rather odd usage that enwiki decided was notable; that item is NOT about the concept behind the word, and should not be linked from a lexeme. Anyway, the discussion right now is whether we should consider adding items for the concepts associated with verbs (actions), adjectives, and perhaps other parts of speech. It does seem like this would be a useful thing to do. ArthurPSmith (talk) 19:52, 11 January 2019 (UTC)
All what Arthur said and currently discussed property proposition Wikidata:Property proposal/adjective of KaMan (talk) 20:12, 11 January 2019 (UTC)
@ArthurPSmith: so... why are Senses tied to Lexemes? If Senses are translatable (independent of language) and have their own items... why aren't they first-class entities? In more practicial terms, if I were to create an item for L3037-S1 what would I make the label? Would it be "to enjoy, be pleased by; favor; be in favor of"? U+1F360 (talk) 21:25, 11 January 2019 (UTC)
@ArthurPSmith: Or would it be three items? "enjoy", "pleased" and "in favor of" (if those don't already exist)? U+1F360 (talk) 21:46, 11 January 2019 (UTC)
@U+1F360: Lexemes are still pretty new - we didn't even have "senses" at all until a few months ago. So join the discussion in the areas KaMan and I pointed to. It's not clear how "granular" we need to be either with senses or with corresponding items for example. I have run into some cases (a recent example was "pipeline", for which Wikidata seems to have 3 distinct software-related definitions, in addition to the standard material transport one) where Wikidata is very granular, others where we seem to lump a lot of things in one concept. Partly it depends on the degree to which we as volunteers want to create and maintain a lot of fine distinctions... ArthurPSmith (talk) 02:57, 12 January 2019 (UTC)
When it comes to creating new concepts it's important that they have a clear meaning and users of different languages can understand what the item means. I'm not sure to what extend the English word liking maps easily into other languages and that's what you should investigate when thinking about creating the item. ChristianKl❫ 08:31, 13 January 2019 (UTC)

Wikimedia Category - translations

Is it a best practice to translate the label of a Wikimedia category when there is no corresponding category in that language's Wikipedia? (Example - should Q8987669 have the label "Baroque costume" in English, even though EN wiki does not have an article or category for that topic?) - PKM (talk) 20:51, 11 January 2019 (UTC)

@PKM: Even though there would be no article for certain language, as long as the translation makes sense there shouldn't be any issue. --Esteban16 (talk) 20:57, 11 January 2019 (UTC)
We do this often on people who don't have an article in a particular language. - Jmabel (talk) 23:03, 11 January 2019 (UTC)
@Jmabel: oh , I do that, too. The difference in my mind is that a person exists; if we say "Baroque Costume" is a Wikimedia Category, that isn't precisely true because there is no such category. I also rarely (never?) see translations of labels for categories when there is no equivalent category in a language Wikipedia. So I though maybe there was guidance about this and I just missed it. - PKM (talk) 22:04, 12 January 2019 (UTC)
I don't translate category labels for the same reasons either. That's said, you should not have any problem if you translate category labels. Pamputt (talk) 08:13, 13 January 2019 (UTC)

Lists of awards

Is it sometimes appropriate to have multiple values for is a list of (P360)? I've tried using two values at list of awards and nominations received by Robert Redford (Q17097452) because of the "awards and nominations" bit in the title (of the awards listed, some of them did not have nominees, and some of them were not won by Redford). Jc86035 (talk) 17:19, 12 January 2019 (UTC)

@Jc86035 : I don't think that's appropriate, but at the same time there is a great need for it since some Wikis like to collect different lists together (Example: , German wiki collect Hit Albums and Hit Singles into the same article, while most other languages don't. I think there is a need for a new property, something akin to , maybe "contains lists of"? "list combines topics"?? Moebeus (talk) 18:36, 12 January 2019 (UTC)
Awards are added individually for a person and not as a list. The award knows its recipients by inference. Thanks, GerardM (talk) 13:22, 13 January 2019 (UTC)

Is there a way I could contact Wikimedia Deutschland?

I have a couple of questions regarding Structured Data on Wikimedia Commons and if this is going to make Wikimedia Commons "a Wikidata outside of Wikidata" or if they are also going to improve cross-wiki integration with Wikimedia Commons on Wikidata. Also I want to know about the legal status (read: Copyright © status) of the Structured Data on Wikimedia Commons project, but I haven't found a single hub where I could ask questions to members of Wikimedia Deutschland. -- 徵國單  (討論 🀄) (方孔錢 💴) 10:28, 13 January 2019 (UTC)

@Lydia_Pintscher_(WMDE): is one of the people you can ask. ChristianKl❫ 10:36, 13 January 2019 (UTC)
Hello @Donald Trung:, I'm working on communication with the community for the Wikidata team, you can contact me about any question that you have regarding Wikidata. You can also use Wikidata:Contact_the_development_team.
When it comes to Structured Data on Commons, the person who can answer your questions the best is @Keegan (WMF):. I hope that helps! Lea Lacroix (WMDE) (talk) 12:15, 13 January 2019 (UTC)

Bilal Hassani

Hi guys,

This person is a trending topic in France now and is victim of a campaign of cyber-bullying. Can some of you take this Wikidata item in their watchlist?

Thanks, FR (talk) 12:06, 13 January 2019 (UTC)

I protected the item for two weeks. ChristianKl❫ 12:28, 13 January 2019 (UTC)

Confirmed or autoconfirmed

I don't have permission to edit Nepal (Q837). I think it is semi protected page. Am I not autoconfirmed yet in Wikidata? What is required to be autoconfirmed? --Binod Basnet (talk) 12:14, 11 January 2019 (UTC)

Hi! You are actually autoconfirmed now, and at exactly 50 edits! I think your message here just pushed you over the auto confirmed limit(i think)? You should be able to edit the item now. ·addshore· talk to me! 12:26, 11 January 2019 (UTC)
@Addshore: Hi! I am autoconfirmed now. Thanks--Binod Basnet (talk) 00:54, 12 January 2019 (UTC)
  • On a related note - Unlike Wikipedia, where you can create a 10,000 word article and have it count as 1 edit. I am not sure 50 edits on Wikidata should be enough, simply because each word is an edit.Lazypub (talk)
    • If we want to change this I guess we need to have an RFC regarding the autoconfirmed requirements! ·addshore· talk to me! 08:22, 14 January 2019 (UTC)


Q477088 appears to be about the male given name, but at least for Commons & en-wiki, it is linked to articles about the eponymous deity, the Hindu god of architecture. Someone who knows better than I how to disentangle this should do so. - Jmabel (talk) 04:02, 13 January 2019 (UTC)

Every article I looked at seems to be about a deity. We can ask User:Jura1 who set up the item. Ghouston (talk) 08:45, 13 January 2019 (UTC)
It went wrong here. Sjoerd de Bruin (talk) 10:46, 13 January 2019 (UTC)
So can someone disentangle it? - Jmabel (talk) 18:58, 13 January 2019 (UTC)
Sorry, I didn't notice the earlier history. I think it needs to be mostly purged (descriptions in all languages, and statements) and set up anew as an instance of Hindu deity (Q979507). I'll have a go. Ghouston (talk) 21:51, 13 January 2019 (UTC)

Wikidata weekly summary #347


Is there a hall of shame  somewhere? I'd like to add ISNI with more than one ID for Suzi Quatro (Q234750), followed by ISNI with a search form offering ORCID ID, but not finding an existing ORCID ID, and as third entry in the top 5 epic fails ISNI with a "sofixit"/DIY form committing suicide after I tried to tell them that a simple "copy stuff from Q2709" would seriously improve their rubbish record.

The new ISNI registrar YouTube could also get a honorary entry in the top 5, no Q15994935 at all. Worldcat at least knows the book and the author,[11] but didn't bother to create an ID. Anything OCLC is a waste of time, PURL was supposed to exist forever, not given up to WAYBACK as hopeless case after about two decades. But maybe MusicBrainz is more relevant for a hall of shame, an 11 years old kid allegedly released two records six years before she was born, this is just spam. 11:36, 10 January 2019 (UTC)

I've submitted the appropriate corrections to the MusicBrainz item. It looks like a user who has since deleted their account accidentally added the info to both artists. I haven't checked the other errors that you've listed.
I think you should create an account if you don't have one already. It generally has benefits (the linked page is for the English Wikipedia, but most of it applies to Wikidata as well). Jc86035 (talk) 18:13, 10 January 2019 (UTC)
Okay, ignoring these silly MusicBrainz GUIDs for now, if somebody figures out what they do the property could be renamed to GUID.
WP:WNCAA claims to be humorous, but actually isn't, let's say that there is no ex in ex-wikiholic. Back on topic, I'm still unhappy with two ISNIs for one living person, and some hours ago I somehow managed to create two identical Discogs label IDs for one item (of course fixed, but why was it possible?) – 07:11, 14 January 2019 (UTC)
I'm not very familiar with ISNI, but is it particularly problematic for Wikidata (or for you) if they have duplicate values? The ISNI property doesn't have a single value constraint. I don't really know enough about the other databases or the current context to respond to your other complaints. Jc86035 (talk) 11:54, 15 January 2019 (UTC)

Which Wikidata tours are missing?

Hi all

This year I plan on writing some of the missing Wikidata:Tours to provide people new to Wikidata with an easier way to learn the ropes. The question is what tours are missing? All suggestions welcome, @Lydia Pintscher (WMDE): in case she has a list already :)

Also is there any guidance written on how to actually make the tours?

John Cummings (talk) 09:51, 14 January 2019 (UTC)

Hello John,
The page used to display ideas or tours that were not done yet. They've been hidden but they are still present in the code of the page:
  • References
  • Ranks
  • Special values
It would be awesome to have one about Lexemes as well.
For a tutorial to create tours: you can check mw:Extension:GuidedTour, en:Help:Guided tours and mw:Extension:GuidedTour/Write an on-wiki tour, and to have a look at the existing tours to see how they are done.
Thanks a lot for your help! Lea Lacroix (WMDE) (talk) 10:20, 14 January 2019 (UTC)
A couple of tours are already written but not yet active due to JavaScript errors: Wikidata:Tours/Qualifiers, Wikidata:Tours/References, Wikidata:Tours/Special Values, Wikidata:Tours/Behind the Scenes. If anybody is JavaScript expert, please help at --Pasleim (talk) 10:32, 14 January 2019 (UTC)

Thanks very much @Lea Lacroix (WMDE): and @Pasleim:, it seems like we can't really proceed until the Javascript errors have been addressed, who could fix this and how much work is it? Are there Phabricator tasks written explaining the issues? Without Phabricator tasks it will be hard to find someone. Thanks again, --John Cummings (talk) 10:41, 14 January 2019 (UTC)

I don't know what the problem with the JS issues is and I don't think there is a ticket for it. Here is a ticket with subtickets for the missing tours: phabricator:T165903. --Lydia Pintscher (WMDE) (talk) 12:51, 14 January 2019 (UTC)
Thanks very much @Lydia Pintscher (WMDE):, do you know anyone who might know? I remember the tours were broken for a while and then they got partly fixed. Its difficult to write these instructions when the software is broken :( --John Cummings (talk) 13:44, 14 January 2019 (UTC)
Pasleim maybe? I am not sure, sorry. --Lydia Pintscher (WMDE) (talk) 15:08, 14 January 2019 (UTC)
I think there is a problem related to the loading order. The JS is loaded before HTML loading completed and thus the pop-ups can not be attached to all HTML elements. You can test it out on The seventh pop-up should be attached to the property field but it isn't. Except if you press once the forward arrow and then the backwards arrow, the pop-up is corrctly attached. --Pasleim (talk) 16:12, 14 January 2019 (UTC)
Thanks very much @Pasleim: and @Lydia Pintscher (WMDE):, I'll ask around and try to find a friendly wizard to fix it, I started a Pahbricator ticket for it here. --John Cummings (talk) 10:17, 15 January 2019 (UTC)

Survey of Scottish Witchcraft database - torture/death modelling and modelling of 16th/17th century locations

Hi all, back to work on the Survey of Scottish Witchcraft database. Some tidyup needs doing in terms of labels and some items require merging with few pre-existing items but wanted to ask firstly about bulk importing manner of death (P1196) information, cause of death (P509) information. This should be relatively straightforward as there are only a few values for these properties. BUT the related, if grim, information is in the torture the alleged witches endured: sleep deprivation, hanging by thumbs, whip, burning feet, stocks, irons, wedges on the shins, bow strings etc. Therefore my question would be, is it pertinent to create a new Property for 'Torture Type' as this does not seem to be currently modelled on Wikidata and there would, sadly, be modern instances where this could be relevant to. Realise it is a grim topic, but suggestions welcomed as this information does not fit into the cause of death/manner of death area.
Second question, spoke with Chris Fleet, Map curator at the National Library of Scotland, and he has helped me to see how I could continue to use their old maps in their collections, and possibly also Ordnance Survey Linked Open Data, to get approximate co-ordinates to where some of these old hamlets existed. Plotted 1,000+ so far of the easiest to plot locations but the older places may be a bit trickier to track down. As an alternative/additional mapping option, he suggested using their shapefiles converted to create geoshapes on Commons of the 18th/19th century parishes. The problem here would be that there are so many parishes to import that doing this one by one would be so time consuming when a script maybe able to do this in one fell swoop. the other issue is that the boundaries for these 18/19th century parishes will not match the 16th/17th century parishes but will be as close as we can get it based on available information at the NLS. As long as these parish geoshapes are given a qualifier as to their period of time would could this still be a workable approach? Stinglehammer (talk) 17:51, 14 January 2019 (UTC)

Regarding torture data: Were these judicial sentences, as punishment for witchcraft? If so, I think we might already have a way to model that. If not, we could still probably create a more generic property than "torture type" to deal with it. --Yair rand (talk) 21:24, 14 January 2019 (UTC)
If not, such as? (Let's go with the presumption this is extrajudicial coercement. --Tagishsimon (talk) 21:28, 14 January 2019 (UTC)
@Stinglehammer: On the geography question, if Chris Fleet is happy to release shapefiles for parishes, those would be incredibly useful to have for all sorts of purposes, not just witchcraft. Definitely any conversion needed should be done by script -- don't even think of doing it by hand. But one caveat may be the licensing. Not sure about this, but is Data namespace on Commons still requiring CC0? Would NLS be okay with that? They have tended to be rather restrictive regarding the terms of what they release.
There's also quite a lot of work to do on the items for parishes (or lack of them). We currently only have nine items marked as civil parish (Q5124673) (Scottish, specifically), two with the more general civil parish (Q4976993) and eight marked as parish (Q102496); so there's some useful work to do, to bring across the data at en:List_of_civil_parishes_in_Scotland for the post-1845 civil parishes; plus the ecclesiastical parishes that were the subjects of the en:Statistical Accounts of Scotland (which it would be nice to link to the relevant pages of). So quite a lot of spadework needed, even just for parishes -- but a foundation that it would be incredibly useful to get in place.
As to more detailed places, could you post a link to your list, so we can see what the project is grappling with? NLS is probably a good place to find out how far people have got towards trying to collate a detailed electronic historical gazetteer of Scotland, including variant spellings -- they host scans of quite a few print ones after all; as well as the Ordnance Survey surveyors' books, that preserve various alternate names and spellings. The Vision of Britain site also has a lot of places in its database, many of which we link via Vision of Britain place ID (P3616) and Vision of Britain unit ID (P3615), but there are a fair number more there that have never been aligned to items here. Recently also the GB1900 project, coordinated with the NLS, has produced a comprehensive gazetteer of every single place recorded in the big six inch OS maps made in 1900. There's also the Gazetteer for Scotland project, being run out of University of Edinburgh. Parish pages, eg [12] appear to contain listings of large numbers of names of settlements and features within them; though possibly these may only be a reflection of what's listed by the Ordnance Survey (either 2018 or 1900), and there don't appear to be many attestations to earlier forms or different spellings. But possibly somebody somewhere may have done some of that collation work, at least for some localities, after the model of the Historical Gazetteer of England's Place-names. Jheald (talk) 01:19, 15 January 2019 (UTC)
On licensing, the Map Data help page was changed in August 2018 to show that the Data namespace can now also take a range of CC-BY or CC-BY-SA versions, or ODbL. --Oravrattas (talk) 11:01, 15 January 2019 (UTC)
Scotland's Places (NLS again, amongst others) might be interested in your list, particularly if it's based on original transcriptions they could quote for context. Jheald (talk) 01:37, 15 January 2019 (UTC)

Academic PhD tree

All the data in AcademicTree is licensed CC-BY. Is there any way to make such a database importable to WikiData by quoting as the source? It'd be a great trove for analyses like Scholia. Evolution and evolvability (talk) 10:10, 15 January 2019 (UTC)

Relation between P1628 (equivalent property) and P2888 (exact match) ?

User:Thadguidry has recently removed equivalent property (P1628) from Library of Congress authority ID (P244) and replaced it with exact match (P2888). (diff)

I was wondering, what is the appropriate relation between these two? When should P2888 be used, and when should P1628 ? Is equivalent property (P1628) redundant? Jheald (talk) 15:12, 12 January 2019 (UTC)

Exact match is supposed to follow the semantics of skos:exactMatch. On the other hand, equivalent property (P1628) can also represent skos:closeMatch ChristianKl❫ 16:19, 12 January 2019 (UTC)
@ChristianKl: Thanks. One could alternatively indicate that a match was exact by qualifier mapping relation type (P4390) = exact match (Q39893449). Is there a need for exact match (P2888) over using equivalent property (P1628) and equivalent class (P1709) with this qualifier? I'm troubled by the apparent redundancy: if sometimes exact match (P2888) is used, but sometimes mapping relation type (P4390) = exact match (Q39893449) is used, then searchers may miss some matches. Jheald (talk) 20:30, 12 January 2019 (UTC)
The inconsistency doesn't seem ideal. I would personally prefer to have properties for close match and related match and then make them subclasses of equivalent property (P1628) over using mapping relation type (P4390). ChristianKl❫ 08:39, 13 January 2019 (UTC)
I agree that the whole field auf equivalences and semi-equivalences is a bit confusing.
  • equivalent property (P1628) has owl:equivalentProperty as an alias, which in turn has a formally defined meaning in RDF - which I'm not able to fully grasp and express in plain words.
  • exact match (P2888) (skos:exactMatch) means: two concepts have an equivalent meaning for a broad range of applications, and can be applied transitively - without the formal implications of owl:equivalentProperty. In particular, it does not imply that the item is a property, and the value (URL) denotes a rdf:Property.
  • mapping relation type (P4390) is different from both, in that it is an qualifier currently restricted to external identifiers, and as such can do nothing for values of datatype URL (as mapped by equivalent property (P1628) or exact match (P2888)).
When we are striving for a more streamlined approach, we could consider replacing exact match (P2888) and equivalent property (P1628) by an new property "maps to" (or similar), with url as datatype, and a mandatory mapping relation type (P4390) qualifier. Possibly, that approach could be extended to equivalent class (P1709) and to narrower external class (P3950) (not indicating that the external url represents a class, however).
-- Jneubert (talk) 18:08, 14 January 2019 (UTC)

Response from thadguidry

I will repeat what I mentioned to User:Tpt in private email between us, Regarding "exact match" and "equivalent property" on a Wikidata Property: We really need those concept exact matches when they exist, no matter if it's a Wikidata TOPIC, PROPERTY, etc. I take a realist view and when we began the Wikidata <-> mapping we had a rule where we applied "exact match" when concepts on both sides matched, and so I don't think there is anything inherently wrong with having "exact match" on a Wikidata TOPIC, PROPERTY, etc.

Quite often a Wikidata Property can be mapped "conceptually" to an external "concept", which could be a class, property, idea, concept, alienFromMars. That is the intent of SKOS:exact match which is what Wikidata's P2888 was tailored around just read yourself

PLEASE read and understand these first paragraphs in section 3.5.1 and 10.6.1 and 10.61.3 of SKOS Concepts & mapping Wikidata needs and uses exact match (P2888) as it is intended, a transitive semantic relation that can hold entailment. This does not mean that 2 concepts that are mapped cannot have omitted properties on one side or the other, but that both concepts need to be semantically "exact" in their meaning. This is a big difference between some RDF relations. But SKOS: exact match is not about RDF, but about concepts.

I would recommend that documentation on exact match (P2888) be improved to state this regarding using it for matching semantic concepts. I would disagree with adding another layer of indirection with a new property "maps to". "exact match" (P2888) is to be used for concept equivalency, versus the more strict "equivalent class" and "equivalent property". "exact match" can be used to map a PROPERTY on some vocabulary to a CONCEPT or CLASS in another vocabulary. I.E. jumping the semantic bridge.

A good example comes from child (P40) where we have both "equivalent class" and "exact match" statements applied, because some external entities are Classes and yet others are Properties. There is no harm in this, since we are stating 2 different things with 2 different statements, the concepts are semantically equivalent "exact match"(SKOS), and they are also considered "equivalent class"(RDF).

In essence, we have these different properties in Wikidata to help alignment with both SKOS and RDF resources. Perhaps saying that in the documentation on each might help others understand and avoid confusion. -- Thadguidry (talk) 14:51, 16 January 2019 (UTC)

Regarding placing exact match (P2888) on Properties

I was trying to help with Option B, by adding "exact match" to properties.

Option A - Don't allow "exact match" on properties. So then with SPARQL, it is just 2 extra lines for folks if they want to lookup and retrieve the external concepts (on topics) for all properties. However, not all properties will have a subject item of this property (P1629) link to a Wikidata Topic (item).

Option B - Allowing "exact match" on the properties eliminates those 2 extra SPARQL lines.  It allows linking to properties to external concepts, even when we don't have the subject item of this property (P1629) already in Wikidata. Some properties will never have a linked subject item of this property (P1629). Allowing "exact match" on properties also makes more clear when viewing a property what links to what, but then many things are still hidden anyways, not just "exact match", until you click around, or perform well-constructed queries, but still it adds more data without ambiguity, since "exact match" means to have equivalent semantic meaning.

In light of the above, I would still vote for Option B.

-- Thadguidry (talk) 22:40, 14 January 2019 (UTC)

suffragist (Q27532437) and suffragette (Q322170)

Doc Taxon (talkcontribslogs) has decided to completely change the meaning of those items. Previously, suffragist (Q27532437) was an occupation referring to an activist advocating for woman's right to vote in general, and now it is a member of a specific British organisation: the Women's Social and Political Union (WSPU). On the other hand, suffragette (Q322170) used to deal about a specific type of suffragist called "suffragette" who was a member of WSPU, and now the same item deals about a group of humans: the "suffragettes". As a result, there is no longer an item for "suffragist" or "suffrage activist" (en:Category:Suffragists) as a broader non-country specific item encompassing "suffraggette" (en:Category:Suffragettes). There was clearly no consensus for these changes which is shown in my talk page, and I do not agree with this type of radical changes by force, but I would like to hear more opinions. Most labels and descriptions have not been updated, and the aforementioned items are used as statements in over 500 and 1800 items, respectively. Therefore, any thoughts to solve this would be appreciated, even better if mansplaining (Q16961425) such as this is avoided. Andreasm háblame / just talk to me 01:45, 14 January 2019 (UTC)

This seems like a ***really unhelpful*** set of changes. There is a VERY CLEAR distinction between a suffragist and a suffragette. The former are supporters of votes for women. The latter tend to be members of WPSU. The former tend not to be militant. The latter tend to be militant. The distinction is found in the lead paragraph of w:en:Suffragette. Here is a helpful British Library primer on the subject. A set of changes which conflate the two is just nonsense on stilts. The best course of action is to revert all of Doc Taxon's changes. Out of courtesy, I'll await Doc Taxon's input, but I have to express my deep deep disappointment at seeing something like this happen. --Tagishsimon (talk) 02:19, 14 January 2019 (UTC)
I note that, at least as far as the en label is concerned, Q27532437 was "suffrage activist" and Q322170 was "suffragette". That is what the two should return to. Unhelpfully, the non-EN labels in Q27532437 were "suffragette", but I think that as the term Suffragette "refers in particular to members of the British Women's Social and Political Union (WSPU)" [13] it is reasonable to go with the EN labels and amend the non-EN labels. --Tagishsimon (talk) 02:32, 14 January 2019 (UTC)
@Doc Taxon: I've reverted the two items, 48 hours having passed and you having clearly been alerted to this discussion. Please do not re-implement such a profound change without first seeking consensus. @Andreasmperu: - fyi. --Tagishsimon (talk) 00:18, 16 January 2019 (UTC)
I see women's suffrage movement (Q1222730) got itself involved in this clusterfuck. I've had to revert that too. --Tagishsimon (talk) 00:22, 16 January 2019 (UTC)

Uploading population data to Dutch municipalties

I want to upload data on population of Dutch municipalities through the years 1960-2018. I will start to add total population on the 1st of January. Presently these are added by hand, are incomplete and inconsistent. Look at Zwolle for an example. As a source I will use the Statistics Netherlands dataset on Bevolkingsontwikkeling; levend geborenen, overledenen en migratie per regio. In the future then these data can much more easily be maintained as an API call on the database can be done. These data are open data with a CC BY 4.0 license. I have already done a bot request under the user histobot. I would like to get started. Historazor (talk) 14:34, 15 January 2019 (UTC)

I think there is still discussion about data imports that are not CC-0... Sjoerd de Bruin (talk) 15:32, 15 January 2019 (UTC)
In practice this is not a big issue. Current population data on Wikidata mostly list Statistics Netherlands as a source. That is the main condition for the use of their data. When the data is used in Wikipedia it will be referred back to this source.Historazor (talk) 22:04, 15 January 2019 (UTC)
The concept behind Wikidata is that you can even use the data here without attributing Wikidata or the license at all. Sjoerd de Bruin (talk) 10:51, 16 January 2019 (UTC)
I know. Statistics Netherlands publishes its datasets at which also has a CC-0 license. There is no problem with that. Historazor (talk) 13:28, 16 January 2019 (UTC)


Can somebody help me add the redirect lemma Звуковой сигнал from ru-Wiki to the above item?--Hildeoc (talk) 17:30, 15 January 2019 (UTC)

  • I thought we didn't have any way to connect Wikipedia redirects to Wikidata items. - Jmabel (talk) 19:05, 15 January 2019 (UTC)
  • done. -- VlSergey (трёп) 07:20, 16 January 2019 (UTC)
    • So is that acceptable (linking a redirect like that)? I thought elsewhere people had said not to do this. - Jmabel (talk) 17:16, 16 January 2019 (UTC)
a) I don't think it is acceptable, no, at least based on the convention that redirects are not offered as sitelinks by the machinery of wikidata; and b) the ru.article we arrive at - Sound - seems completely inappropriate for the wikidata item - signal tone. --Tagishsimon (talk) 17:21, 16 January 2019 (UTC)
@Jmabel, Tagishsimon: It's definitely acceptable - see Wikidata:Requests for comment/Allow the creation of links to redirects in Wikidata. When the Wikidata UI will be adjusted to actually allow this more directly is an excellent question, but it's definitely something the community supports. That said, the links should be for equivalent concepts; if a redirect is just an alternate name for the same thing, it should NOT be linked to a new Wikidata item. ArthurPSmith (talk) 18:08, 16 January 2019 (UTC)
Ah. Thanks. --Tagishsimon (talk) 18:12, 16 January 2019 (UTC)

Wikipedia Page for the organization

Hello, can i create a company profile on Wikipedia if yes, please tell me the procedure for that.

You can, if you are not connected to the company and the company satisfies Wikipedia:Notability (organizations and companies). As to how, maybe start here. --Tagishsimon (talk) 16:30, 16 January 2019 (UTC)

single-value constraint, non-mandatory, references, state it, module... all over again...

Previous discussions:

title (P1476) has single value constraint (Q19474404). title (P1476) can be use as a property to add a statement or as a refeferce property (to indicate sources). It the property is said that "Non mandatory constraint. Add only title of work in its original language. Multilingual works may have several."

According to

Something is wrong, because there are not all the items that are using P1476 as a refeferce property (to indicate sources). I know there are least 778.

I am not good in SPARQL to find all the violations. @Jura1: tells me that There are 20 million uses of this property. Do we know many may have several titles. I can't find that...

The constraint was added to P1476 some months ago (March). I thought it was wrong. I removed it (Arpil). The constraint was added again at 11 November.[[16]]. Then, a new change happened: Displaying the reference unfolded when there is a constraint violation.

Before that period, I have added many statements with multilanguage references (english and greek). Now, my contributions are difficult. I need more time to add statements, to move to a statement in item page, the references are not unfolded from the time you open an item page but are need some seconds and the page move down and you are not to the point you were etc. Ok, I understand that the change was happen to help users, but that make problem to other users. Even If I am the only one with the problem, I am still a user that also need the help of the communtity.

I have tried to change the way the reference are added [17] @Pasleim:. Of course, I need help with bot and other issues. But, other issues come out. I have tried so hard to use wikidata statements to wikipedia articles. And is was working perfect (with the help of @Matěj Suchánek:). Now, I will need help to change the codes and other thinkg because of all that situation.

@Lea Lacroix (WMDE): create a ticket asking to keep references with non-mandatory constraints folded [18]. I am waiting for that (I don't understand how exaclty will work, if that happen, but it may help).

I am thinking just to add the "statements" to wikipedia infoboxes with the reference and not to wikidata anymore. It easier now for me, than wikidata. It is useless if we change so many things in Wikidata that affect wikipedia. And then change the templates and modules in wikipedia and etc... Yesterday, I needed douple ot time to add all the statements I wanted to wikidata, because of the problem. So tired situtation...

I am asking two things to the community:

1) Please think again the single-value constraint with title property. There are so many multilanguages items. Especially with two language, one of them are English. Or,

2) Please, remove the constraint untill we have an answer to the ticket.

Sorry for my Enlgish. Xaris333 (talk) 21:12, 28 December 2018 (UTC)

  • Both title (P1476)-statements could be added to Cyprus census 1976 (Q29639032) and not repeated in every reference using that source. This would solve most of the problem. If there is an item for the source, I don't see why there would be P1476 in the reference. --- Jura 21:23, 28 December 2018 (UTC)
  • Is there any reason we should not use separator (P4155) = "language" to allow multiple values for "title" when the language is different? I wasn't aware of this qualifier until last week, but I think it would solve the issue here. - PKM (talk) 21:30, 28 December 2018 (UTC)

  • For the first point: that create more problems, for example in Wikipedia module. In Greek Wikipedia we need help from the user I told above to fetch the reference from wikidata. Now, we have to change it again because of that situation. And, you can understant in some communities there is not always some who has the knowledge and/or wanted to help. For me, that changes is like that all the days we spent to make the modules work, was waste of time. All over again from the beggining. I know that does not care wikidata community and of course wikidata is not just a user and the problem he has while constibur... If that is the answer (what you suggest), then it is just better for me to just add the statements and references to Wikipedia. It is so tired always to change things in Wikidata that affects all the others. I just need a final discussion (this one) to know what to do. Noone will continue to contibute if changes make problems to his contributions... Moreover, the constraint also exist in Cyprus census 1976 (Q29639032). Why is a problem that an item has two titles?
  • How to use separator (P4155)?
  • And why title has single-value constraint and language of work or name (P407) not? If a work has more than one language, it may has more than one title. Xaris333 (talk) 22:03, 28 December 2018 (UTC)

Xaris333 (talk) 21:44, 28 December 2018 (UTC)

    • If the LUA module isn't following Help:Sources maybe it's worth revising it. I haven't said it's a problem to add 2 titles, I even suggested moving them to the correct item. There you wont have the "unfolded references" issue. --- Jura 10:52, 29 December 2018 (UTC)


1) I am adding a lot of references last 3 years. Noone ever tell me and noone ever correct any of those references. Is that wikidata? Anyone can add references some years, create modules to fetch that reference to Wikipedia, and one day someone tell him that are "wrong" and have to change everything? Actually is not wrong, is the url approach. In Help:Sources said: "Typically the property used for sources is one of two options: stated in (P248) (referring to publications and media) and URL reference URL (P854) (used for websites and online databases). I was adding the reference with the second options: they are url and online databases. That they are. And now you are telling me that this is wrong. Can you explain me why this url must go with the first option and not with the second? It is a data set (Q1172284).

2) "I haven't said it's a problem to add 2 titles, I even suggested moving them to the correct item. There you wont have the "unfolded references" issue." See Classification for the degree of urbanisation in Cyprus (Q60197762). You are telling me to create items for references that they will aslo have the single-value constraint!

3) If it is not a problem to add 2 titles, then why we have single-value constraint for title?

Xaris333 (talk) 16:57, 29 December 2018 (UTC)

  • It's just a potential issue. If you try to add three title statements to Q29639032, it would be an actual issue. If you just add one, it's never an issue and for most works this the way it should be. If you have a suggestion for a better solution for these, I'd be interested. --- Jura 17:42, 29 December 2018 (UTC)
I have: remove the constraint. It is wrong, it is proplematic, it is not useful. Xaris333 (talk) 17:47, 29 December 2018 (UTC)

@Jura1: Why you avoid answering my first question. Can you explain me why this url must go with the first option and not with the second? It is a data set (Q1172284). Xaris333 (talk) 17:48, 29 December 2018 (UTC)

  • I'm just addressing the question about the single value constraint. I'm sure you will find someone who is interested other issues you may have with Help:Sources, GUI etc. --- Jura 17:55, 29 December 2018 (UTC)
    • @Jura1: your supporting a constraint that affect sources, you suggest a soloution base to Help:Sources but you don't want to answer a question related to constraint and to your suggested solution!! Xaris333 (talk) 18:35, 29 December 2018 (UTC)
      • I think I provided a solution for the only sample you kept repeating in the two previous discussions. --- Jura 18:40, 29 December 2018 (UTC)
        • @Jura1: I gave another example for the same item, but you are avoiding to answer. Moreove, you are avoiding to answer why title has single-value constraint and language of work or name (P407) not? Xaris333 (talk) 18:48, 29 December 2018 (UTC)
    • @Xaris333, Jura1: An alternative to the single-value constraint could be to add a complex constraint that allows at most as many title (P1476) statements as language of work or name (P407) statements. --Pasleim (talk) 18:05, 29 December 2018 (UTC)
      • That is the most logican and helpful suggestion. Thanks Pasleim. I hope that Jura1 and other users will support that. Xaris333 (talk) 18:33, 29 December 2018 (UTC)
        • Somehow I doubt that will work out, but if you will maintain it .. sounds great! --- Jura 18:40, 29 December 2018 (UTC)
        • @Pasleim: can you do that? Xaris333 (talk) 18:48, 29 December 2018 (UTC)
        •   Support this solution, though I don’t know how to build the constraint. - PKM (talk) 22:21, 29 December 2018 (UTC)
          • There are actually three steps involved: (1) write the query, (2) ensure it scales to the number of uses of the property, (3) review and fix statements on the output of the complex constraint (in place of editors currently using the gadget). --- Jura 13:27, 31 December 2018 (UTC)
            • Does adding the qualifier separator (P4155) actually create the complex constraint? - PKM (talk) 02:52, 3 January 2019 (UTC)
            • And how does one add separator (P4155) with value “language”, since the language used for strings isn’t (obviously) one of the language properties? (Is there a secret p-value for “language of string”?) - - PKM (talk) 22:36, 9 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Pasleim, Jura1, Xaris333:, I realized that the proposed solution (complex constraint tying number of titles to number of "language of work") will not solve the constraint for paintings like Mona Lisa (Q12418) which have different titles in different languages.

@Lea Lacroix (WMDE), Lucas Werkmeister (WMDE):, is it even possible to use separator (P4155) with value “language”, since the language used for strings isn’t one of the available language "properties" in the user interface? - PKM (talk) 19:58, 10 January 2019 (UTC)

Thanks for pinging me. I can't provide an answer right now but I'll come back to it next week. Lea Lacroix (WMDE) (talk) 07:52, 11 January 2019 (UTC)
Currently, it is not possible to define the language of monolingual strings as a “separator” for a single value constraint. Another option would be to set up a new constraint type, “single value per language”, rather than a variant of “single value”. Lea Lacroix (WMDE) (talk) 15:31, 14 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Lucas Werkmeister (WMDE) – work account, mainly for development discussions
Jarekt - mostly interested in properties related to Commons
John Samuel
Yair rand
Jon Harald Søby
Was a bee
Peter F. Patel-Schneider
  Notified participants of WikiProject property constraints

@Lea Lacroix (WMDE): - Thanks, Léa. Would we need a Phabricator ticket to create this type of constraint?

How do members of the Property Constraints project feel about a new constraint type, “single value per language”, for titles and similar? - PKM (talk) 20:16, 14 January 2019 (UTC)

A “single value per language” could be a good solution for the species vernacular name, title, officil name or other. --Fralambert (talk) 00:16, 15 January 2019 (UTC)
@PKM: Yes, can you create it? :) I just created a tracking task that you can add as a parent task. Lea Lacroix (WMDE) (talk) 10:28, 15 January 2019 (UTC)
Done, task T213967 created. - PKM (talk) 20:50, 16 January 2019 (UTC)

Sandbox link broken?

The link to my sandbox has been pointing to a non-existing page (, which does not load at all. Has anyone experienced the same issue, and if so, how can it be fixed?--Underlying lk (talk) 18:32, 14 January 2019 (UTC)

Where did you copy this link from? The problem seems to be the "redlink=1" fragment in your link. --Pasleim (talk) 21:49, 14 January 2019 (UTC)
This is just the page that opens if I click on the 'Sandbox' link at the top-right corner (between talk and preferences).--Underlying lk (talk) 02:10, 16 January 2019 (UTC)
By default there is no such link in the top-right corner. Do you have some user script or gadget activated which could add it? --Pasleim (talk) 10:11, 16 January 2019 (UTC)
You're right, it is this gadget:
mySandbox: Add a “Sandbox” link to the personal toolbar area.
The link seems to be broken now.--Underlying lk (talk) 22:05, 16 January 2019 (UTC)

Birth rate Death rate

I can not find any property covering the birthrate or deathrate within a population. Do anyone know of such properties? Have they been proposed anytime? Pmt (talk) 21:22, 15 January 2019 (UTC)

@Pmt:. I came across total fertility rate (P4841) and thought of you. --Tagishsimon (talk) 22:43, 16 January 2019 (UTC)

Creating new items for humans based on Commons categories

Hi all. tl;dr: is it OK to create new Wikidata items for all humans that have Commons categories?

The longer version: I've been doing a lot of work over the last year to get Commons sitelinks added to Wikidata, so that commons:Template:Wikidata Infobox can be added to commons categories. This is now at the stage where about a third of Commons has sitelinks, and more have candidate items waiting to be matched in the distributed game. As the next step, I wrote a bot that looks for Commons categories about humans that don't have an existing sitelink (or a possible match queued in the game, or any other matches from search or from the uses of images in that category, which are then added into the game for review). It then creates new items for them, importing birth/death years and gender from the Commons categories where possible. The bot was proposed and approved last month by User:Ymblanter.

Since then I've been doing some short runs of ~100 new items to make sure it was working OK, and yesterday I set it going on a run of ~1000 items. About half-way through that run, User:Multichill blocked the bot, saying that the new items don't meet the notability criteria. I think they are notable as they have a Commons category. There was a subsequent discussion about that on my talk page, but Multichill (and @Jheald, Christian Ferrer:) may want to repost their comments here.

You can see the bot-created items here. Most are only bot-edited so far, but some like Raymond Bardet (Q60439263) have been expanded by humans, and Miles Armitage (Q60318705) even led to the creation of a Wikipedia article. It does create some duplicates, e.g. Q60439069, but that's inevitable and I've tried to minimise that as much as possible.

I'd like to restart the bot task, but it needs further consensus. So, what does everyone here think - are these OK notability-wise, and is it OK to bot-create them? Thanks. Mike Peel (talk) 11:08, 6 January 2019 (UTC)

  • I think almost all of those items would satisfy WD:N criterion 3 (structural need), if not criterion 2 (notable entity). This would also make Commons structured data a bit more useful. Jc86035 (talk) 11:26, 6 January 2019 (UTC)
I am not opposing Commonscat-only sitelinked items in general, but I have two concerns about it:
  • Unlike in Wikipedias, information in Commons categories is typically not backed by any sources. If we now start to create Wikidata items based on unsourced Commons categories, we have unsourced Wikidata items. It would be much easier for me to accept those new items if there was some identification against external sources provided in the items during creation process, or if references for critical claims were provided. Items such as Bart Bauer (Q60439662), Bernard Baudin (Q60439643), Geoffrey Barusei (Q60439525), or Lluis Bartrina (Q60439512) from the recent Pi_bot batch are barely useful for Wikidata, and in fact it is difficult for random editors who visit the item to improve anything in it.
    We have a substantial similar problem with items whose only (non-Commons) sitelink has been deleted in the past. There are really lots of them, most of them do not surface to any attention. They are practically abandoned, do not receive maintenance any longer, and are not backed by any sources. In surprisingly many cases, it is impossible to identify which person is described by those items at all, and administratively we do not even remotely manage to keep up with the resulting necessary deletion workload of no-longer notable items. Please let’s not increase this problem and provide external identification from the first moment on.
  • There is also continuous doubt about Commons’ notability criteria for categories. I am often surprised which content persists at Commons, lots of which appears out of scope for Wikidata. This looks like another potential venue for self-promoters to establish notability of items which we would otherwise not accept.
Finally a relevant number: we have around 19.000 items about humans with a sitelinks to Commons only. —MisterSynergy (talk) 12:51, 6 January 2019 (UTC)
@MisterSynergy: One thing to consider is that nearly all of these items will have media attached that make it easier to identify the subject and then to expand the item. That's akin to a reference, but a different type than is usually considered on Wikipedias. I could auto-add an image as well, but I'd only be able to do that randomly, so it's probably better if a human does that later on. In terms of numbers: pi bot has created between 1,000 and 2,000 so far, which has done the A's - so maybe there are around 30,000 new items to create to start with, as a rough estimate. Thanks. Mike Peel (talk) 13:02, 6 January 2019 (UTC)
I have concerns similar to MisterSynergy's. There are few -if any - rules on Commons as to who gets their own category. The only real criteria seems to be that a photo was uploaded to Commons. Every day people try to create Wikipedia articles about themselves and upload promotional images of themselves to Commons to include in their articles. The articles then get deleted rather quickly because the persons are entirely non-notable, but the images often stay around on Commons forever. And sooner or later someone comes along and creates a category for this person so the image doesn't stay uncategorized.
Which means there are countless categories for persons that are not notable in any way or form. Often times the only thing known about them is their name - and even that is often not verifyable through reliable sources. IMO that's not valuable data that can be used in any way of form, that's just noise clogging up the database. Sure, some of them are most likely for persons that would definitely be notable on Wikidata and Wikipedia, but not necessarily.
We also already have lots of SEO people trying to add spam to Wikidata about themselves or their clients, so they can get a nice little information box shown in the Google results. Most of them can get deleted quickly because without external IDs and serious references, they don't mmeet our notability criteria. But if all they need to do is upload a photo to Commons and create a category for it, it won't be long before SEO guides will include that strategy. --Kam Solusar (talk) 14:03, 6 January 2019 (UTC)
Googles Infoboxes are based on the Google knowledge graph, new Wikidata items don't make it automatically into Google infoboxes. ChristianKl❫ 14:23, 6 January 2019 (UTC)
Oh, I know that a Wikidata item doesn't automatically result in a corresponding Google Knowledge graph being created. But a while ago I looked around on various SEO sites and forums, and there were indeed various people recommending creating Wikidata items because it would (in their opinion) boost the likelyhood of Google creating new knowledge graph entries and would help getting their information out there. Just two or three weeks ago I stumbled upon a whole series of new items for German SEO people, all with similar statements and no external IDs or independent sources. And of course they all had a photo of the person included. Pretty much all them were deleted thankfully. --Kam Solusar (talk) 13:35, 7 January 2019 (UTC)
@Kam Solusar: In those cases, nominate the photos + category for deletion on Commons, and then the connected Wikidata here could also be deleted? It seems a double standard to say to do that on Wikipedias (which is what I've seen on RfDs here asking for Wikidata entries to be deleted) but not on Commons. I don't buy that they are 'countless' cases of this, and there is commons:Commons:Project scope. Thanks. Mike Peel (talk) 14:54, 6 January 2019 (UTC)
I think the difference between Wikipedia and Commons is, that it's a lot harder to get your own Wikipedia article and the big language versions are pretty good when it comes to dealing with entirely non-notable persons on their own. Whereas on Commons, it seems pretty much anyone can upload a few photos of themselves and create a category without much interference. In my experience, Commons simply doesn't have the manpower to evaluate all those categories and images. And neither does Wikidata have the manpower to really look into all such items. Sure, if I see one, I can nominate it for deletion - but that would require either stumbling upon it by chance or spending lots of time combing through those categories, checking whether any file is currently used or could potentially be used somewhere. --Kam Solusar (talk) 13:35, 7 January 2019 (UTC)
  • Also, Commons quite deliberately has a lower threshold of notability than most Wikipedias. E.g.: almost any Wikimedian; every speaker at a notable conference; any member of the faculty of a notable college or university; any head of a department of any city government; etc. - Jmabel (talk) 02:12, 8 January 2019 (UTC)
  • It seems to me that **In addition, sitelinks on category items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites.** within our notability policy is quite clear on Commons categories not being notable per default.
I'm not opposed to changing that if the Wikidata Commons integration needs those items, but I do think we shouldn't simple ignore the existing policy. I would also read (3) in our policy as being about structural needs within Wikidata and not about needs within other projects. ChristianKl❫ 15:28, 6 January 2019 (UTC)
@ChristianKl: In this case we're not talking about category items (which is where instance of (P31)=Wikimedia category (Q4167836)), we're talking about topic items. In my view, those then get covered by the first part of notability ("It contains at least one valid sitelink to a page on [...] Wikimedia Commons." - where a Wikipedia 'page' corresponds to a Commons 'category'.) It's also not clear if the notability guidelines need to be updated, as there was related discussion at Wikidata_talk:Notability/Archive_4#RfC:_Notability_and_Commons that wasn't fully resolved. Thanks. Mike Peel (talk) 16:06, 6 January 2019 (UTC)
  • More or less same doubt like MisterSynergy. As a possible solution we can give a month before cancellation, if nobody adds some data that show the notability, they will be deleted --ValterVB (talk) 18:00, 6 January 2019 (UTC)
    • For many of the Wikimedians who have Commons categories, de"Wikipedia:Persönliche_Bekanntschaften/Teilnehmerliste should qualify as a reference. - Jmabel (talk) 19:26, 6 January 2019 (UTC)
    • As a Commons admin: there are certainly categories on Commons that do not have notability in their own right. Much as Wikidata has structural needs, so does Commons. For a recent example in my own work, commons:Category:Engine room of Virginia V (ship, 1922) does not mean that the engine room is notable in its own right, it simply means that we have (currently) 42 photos of the same compartment on a particular notable ship, and that was enough to merit a category of its own. Similarly, there is nothing notable about Category:October 2018 in Seattle, it's just a place to store 200+ photos that come from the same city in the same month.
    • If we are going to start hauling in Wikimedia Commons categories wholesale as Wikidata items, we probably need the two projects to coordinate. There needs to be a way to mark which Wikimedia Commons categories are not notable in their own right; presuming that work is to be done on the Commons side, that would require building a consensus there on something for which we've never before needed a consensus. Separately, Wikidata would need to decide whether that criterion means we don't create a Wikidata item at all or, if it is needed for structural purposes, that we mark it accordingly.
    • I personally think any wholesale approach to creating Wikidata items for Commons categories could wait until the "structured data for Commons" project has proceeded a bit further. - Jmabel (talk) 19:26, 6 January 2019 (UTC)
  • It seems that there is the same problematic here and Wikimedia Commons (and in other projects too), here we talk about of lacks of notability, and in Commons we say "out of scope". And when we talk about items/categories that are about persons, then we talk about the exact same thing. As administrator in Commons, it happens that I speedy delete out of scope content, as well as the categories that contained the images. When there is a corresponding item, I come here to take a look, and without serious references (therefore with lacks of notability), the existance of this item don't prevent me to delete the content in Wikimedia Commons. And usually, when the deletion is done, I nominate the item here for deletion. However I don't know if the other administrators are doing the same thing. In a perfect world, we should work together, and have perfect reciprocity. In case that a category in Commons, that has an associated item, is deleted for being out of scope, then the attention of the Wikidata community should be drawn to this item. Conversely if a item here that has an associated category in Commons is deleted, then this fact should be brought to the attention of the Commons community. When we find inappropriate content in a project, let us take advantage of our work the other project. All this is done in an automated way would be perfect. Personnaly I think the future will be a clear increase of the connectivity between the both projects, the problem is more to find solutions to the disadvantages generated, than to limit the connectivity to prevent the disadvantages. The second option is only a short-term vision and is doomed to failure. I support the creation of such items, as well as all other things (such as properties) that should be a need for Commons and in the scope of the "Structured data for Commons". That said, I am sorry for the potential disadvantages for Wikidata, and we should evolve our policies and guides, both here and in Commons, for that we can work towards the same way. Example I was talking above a kind of "automatic reciprocity" in case of deletions, the first thing should be that Wikidata:Deletion policy and Commons:Deletion policy contains a procedure to follow, why not with examples, in cases of deletions for all kind of things that are connected within the both projects. That's exactly the same thing for the Wikidata notability and for the Commons scope. While we have, and likely we should keep, some differences, IMO it is very important that we have some common parts, and references to each other. Christian Ferrer (talk) 20:26, 6 January 2019 (UTC)
  • It seems to me that the time has now come to create items for all categories on Commons.
First let's consider a case like the WMF staffer Juliet Barbara (Q60439088) / c:Category:Juliet_Barbara, which is the example (raised by User:Jean-Frédéric) that started off the discussion on Mike's talk page, with User:Multichill objecting that he thought she was not notable and should not have an item here (and on that basis stopping Mike's bot).
The problem is for Structured Data on Commons to work as intended, there need to be items like Q60439088 here. In order for SDC to be able to fulfill requests like "Show pictures of WMF staffers" or "Show pictures of people called Barbara", as well as analytical queries like "How many Commons pictures depict people we know the names of" or "How many people we know the names of are depicted on Commons", those require us to be able to tag a picture like File:Juliet-IMG 4052.jpg with depicts (P180) Juliet Barbara (Q60439088) and for the item Q60439088 to exist so that statements like instance of (P31) human (Q5), employer (P108) Wikimedia Foundation, Inc. (Q180), given name (P735) Barbara (Q153957) have somewhere they can be recorded. SDC simply doesn't work without items like Q60439088 -- they are intrinsic for SDC being able to describe what an image depicts and to be able to record or access the relevant attributes of that depicted thing.
Each 'simple' Commons category represents something that the images in it have a relationship to, so an item that is going to be needed for it to be possible to express the relationship in statement form. This is the very essence of "structural need" as policy understands it. Jheald (talk) 21:37, 6 January 2019 (UTC)
Let me also say that there is a real advantage to letting Mike get on with things now, so that (i) all these items are already present, and can be ready for systematic use as soon as SDC goes live; and (ii) in the process we pick up as soon as possible an awful lot of missing things that we should have had items for a long time ago, but didn't even know we hadn't got. Systematic reconciliation of Commons things to Wikidata is something we should have started a long time ago. It's not going to be a small job -- after people there are going to be places, monuments, geographical entities, types of things, etc, that are all going to need to be looked at. But it's a necessity for SDC, and something I think Wikidata is also likely to gain a huge amount from in terms of improved completeness. So I think we should be applauding Mike for the work he has been getting underway, and right now doing everything we can to let him get on with it. Jheald (talk) 21:37, 6 January 2019 (UTC)
Somebody like Bart Bauer (Q60439662), mentioned above, is likely to remain notable on Commmons, because he's a US Navy photographer who has taken hundreds of photos that are present on Commons. His Wikidata item would be a desirable linking target for structured data. Perhaps it will turn out that there's little publicly available information about him and so not much to put in the item. But the existence of the item is still useful. Ghouston (talk) 22:33, 6 January 2019 (UTC)
The broader question is what to do with categories like c:Category:Theatre posters of the United Kingdom, 1884. In my view, the balance of advantage has shifted, and it would be immensely useful to be systematically creating items for categories like that too, where we can transpose the text of their names into statements. (eg category combines topics (P971) : poster (Q429785) (instance of (P31)) / theater (Q11635) (field of work (P101)) / United Kingdom (Q145) (country of origin (P495)) / 1884 (Q7819) (publication date (P577)).
The first advantage items like this give us is the possibility of Wikidata infoboxes, to finally allow the meaning and relevant data for what these categories represent to be communicated to users internationally and multilingually. This has been a very long-standing request by users on Commons, and their introduction has gained overwhelming support.
The second advantage is that much of this information directly corresponds to the information will be needed for individual file pages by the SDC project -- indeed, in many cases the categorisation is the only way this appears at the moment in any way even slightly amenable to machine interpretation. Creating items for the categories, and populating them with the relevant descriptive statements, is therefore really valuable (and timely now) as a stepping stone for being able to cascade the information down further to relevant file pages. Moreover, through making the information available through the wikidata item and the wikidata infobox it is available and transparent and accessible, so that anyone can add it, inspect it, correct it, extend it -- essential for collaborative working (because this task is going to be so big it is going to need to be something people can collaborate on); and also of usefulness as an ongoing consistency check for the data on the files themselves -- if the files have a manually set categorisation, does the statement of what that category represents correspond with the statements on the file? If not, what are the anomalies? Can they be explained or cleared up?
Thirdly, having statements on items for categories like this helps us understand the category structure itself. Do the statements for the category correspond with the statements for the categories it is in? Are there statements that are missing, or inconsistent? Do they help understand 'simple' categories that are in the tree below them? Are there statements on those that appear to be missing, or inconsistent? Are there further categorisations of the category, or category refinements that could be made? Similarly, do they reveal further categorisations that ought to be present for some of the files in them? Indeed, with really systematic structured descriptions of what the categories mean, it should be possible to move towards significantly machine-assisted categorisation, trickling a file down from the top and identifying all the categories where it should be land up and be included. With luck it should be possible to greatly add to both the comprehensiveness and accuracy of categorisation, both of files and of categories themselves. (With some further additional knock-on bonuses of missing property identification for corresponding 'simple' items on Wikidata).
But all of this only becomes possible if items exist for the categories, otherwise there is nowhere to store the statements about them. That is a new step, but in my view it is a step that the time has now come to take. None of this is possible without it. Jheald (talk) 22:51, 6 January 2019 (UTC)
  • It seems to me that the items that the bot was creating are not notable according to current criteria. If there would be external sources describing those items, then it would be ok, but that is not the case. In my view the easiest solution would be if those items were created in the Wikibase instance for Commons, and also created here and connected whenever they are notable. It is not a problem to have 2 wikibase instances (Wikidata and Commons) with a different set of items.--Micru (talk) 22:36, 6 January 2019 (UTC)
It won't be possible to create items on the Commons Wikibase. Ghouston (talk) 22:40, 6 January 2019 (UTC)
Why not? It is being developed now, make it possible.--Micru (talk) 22:44, 6 January 2019 (UTC)
It was proposed, for such reasons given here, but rejected by the developers. Ghouston (talk) 22:46, 6 January 2019 (UTC)
Gather support, and propose it again. If enough users ask for it, they might change their mind.--Micru (talk) 23:04, 6 January 2019 (UTC)
@Micru: I pushed for it really hard. They simply don't want to know. Plus they already feel very pushed to deliver even what they are already committed to deliver -- there's no slack available for scoping out new commitments. Besides, it may well make sense to keep all structured information about categories on the same wikibase -- splitting it between here and Commons wikibase creates considerable difficulties. I believe their current plan is to create only MediaInfo objects on Commons wikibase -- all other sorts of items are expected to live here. Jheald (talk) 23:15, 6 January 2019 (UTC)
@Jheald: In that case you might consider another wikibase instance to store those items. I don't think there is willingness here to open the floodgates to so many un-notable items by Wikidata standards.--Micru (talk) 23:23, 6 January 2019 (UTC)
@Micru: Part of what Wikidata is here for (and is funded for) is to support the needs of all of the Wikimedia community of projects. It's not appropriate for editors here to stand in the way of something of critical value to a sister project. Jheald (talk) 23:52, 6 January 2019 (UTC)
@Jheald: The Wikidata community is definitely commited to support the needs of all of the Wikimedia community of projects, as long as that doesn't compromise the integrity of Wikidata itself. You cannot ask for something that goes against the values of the community.--Micru (talk) 00:01, 7 January 2019 (UTC)
@Micru: On the question of complex categories, it's worth looking at the numbers. We currently have about 2 million Commons categories linked to items here (a bit under 30%), out of an approximate total current 7.32 Commons categories [19]. However, when User:Mike Peel looked at a sample of 1000 un-sitelinked categories in June last year (sample he found that very many were not "intersection" categories, but were actually for simple topics of the sort that the present policy text already allows items to be created for.
So I don't accept that broadening the criteria to allow the final (say) 2 million categories that are intersection categories would necessarily be "opening the floodgates" or "going against the values of the community". They would merely be an extension of the category items we already host, quite happily. While on the other side of the balance, intersection concepts like this are exactly where there is most to gain by describing them by way of statements, for all the reasons set out above. So I don't understand why you have such fear of them, or what harm you think their inclusion here would do? Jheald (talk) 01:21, 7 January 2019 (UTC)
@Jheald: If we are talking about "Creating new items for humans based on Commons categories", why do you bring up the topic of "complex categories"? It is offtopic, so I refuse to comment on it on this thread.--Micru (talk) 13:12, 7 January 2019 (UTC)
@Micru: The requirement of external sources for notability (criterion 2) doesn't apply where there is structural need (criterion 3) -- these are two separate independent routes to pass WD:N. The items also appear to pass criterion 1, under the current wording. Jheald (talk) 23:06, 6 January 2019 (UTC)
@Jheald: It is unclear if they fulfill the structural need criterion. That is a question to solve here (btw, I think you got your criteria numbers wrong, I have corrected them).--Micru (talk) 23:19, 6 January 2019 (UTC)
@Micru: Policy refinement is always possible, but per the current text the requirement is for items to meet "at least one of the criteria". They currently appear to be meeting #1 and #3. (Thanks for correcting my numbering above) Jheald (talk) 23:25, 6 January 2019 (UTC)
@Jheald: Which argument do you use for them to be able to fulfill #1? Those categories are not linked to other categories in other Wikimedia projects. Beyond what is written there, there is also the opinion of editors here, and I do not think that they would allow to use any loophole in the policy to circumvent their wishes.--Micru (talk) 23:33, 6 January 2019 (UTC)
@Micru: The qualification I think you are thinking of is a requirement relating to "sitelinks on category items to category pages on Wikimedia Commons". The items Mike has been creating have been main items, not category items. Per the current wording, main items are under no such restriction.
Personally, I would do away with the restriction, to allow broader creation of category items for Commons categories. But that is a wider question than what Mike has been doing. Jheald (talk) 23:43, 6 January 2019 (UTC)
@Jheald: In the past sitelinks from items not representing categories to Commons categories were not allowed. Do you have the link to the discussion when it changed? I cannot find it, and Help:Sitelinks doesn't say anything about Commons.--Micru (talk) 00:01, 7 January 2019 (UTC)
Supposedly the restriction that only category-items could link to Commons categories was adopted in this 2013 RFC. But that close (by a now-banned editor) was always dubious. It bore little relation to the most popular option, was never really implemented, never had buy-in from the Commons community, and year by year became ever more strongly ignored. As the hatnote on the 2013 RfC indicates it's now really only of historic interest. By June last year there were 4x more Commons categories with sitelinks to main items than to category items. (data). The ratio is probably even higher now.
The text of WD:N was changed by User:Mahir256 in March of last year to reflect this [20] after users had been confused, with a revision by User:Jura1 about thirty minutes later [21] to give the current formulation; which has stuck since then. Discussions and a short edit war to try to change it further (see eg two long threads at Wikidata_talk:Notability/Archive_4) have so far been inconclusive. The current text thus permits main-type items to be created at will for Commons categories that eg represent real-world things that have pictures taken of them or statements made about them, on the same basis that such items can be created for things with an article in a particular-language wikipedia. But beyond that, category-type items, eg for 'complex' / 'intersection' categories, may be created only if the category also exists on a non-Commons wiki. Jheald (talk) 00:54, 7 January 2019 (UTC)
@Jheald: WD:N reflects the current understanding. The usage data should be presented in a comprehensible way to support an amendment. I think the text can be changed to reflect better current practices, but definitely not to stretch the guidelines beyond of what is accepted.--Micru (talk) 13:12, 7 January 2019 (UTC)
@Micru: Please clarify: Are you saying above that WD:N does reflect the current understanding, or WD:N should reflect the current understanding? According to the current (stable) text, Mike's new items pass route #1 of WD:N. Jheald (talk) 13:27, 7 January 2019 (UTC)
Discussion noted at c:Commons_talk:Structured_data#Notability_discussion_on_Wikidata Jheald (talk) 13:03, 7 January 2019 (UTC)
@Jheald: Should reflect. Even if the text might read as if the created items pass criterion #1, they do not, so the text should be amended to reflect that understanding in a way that it is more clear.--Micru (talk) 16:03, 7 January 2019 (UTC)
  •   Comment I appologize that I did not have patience to read all the comments above. However I looked at dozen new items created by Mike and great majority seemed perfectly notable. Unfortunatelly there often was no information in the item or in the Commons category to prove that notability. I see such items as good stubs ready for others to expand, but unless someone expands them they are quite useless. I would suggest starting with the people for whom we have the most information, like occupation, nationality, dates of birth and death, which can be extracted from the categories. I would avoid at the members of c:Category:Wikimedians by name, c:Category:Wikimedia Foundation staff, etc. or items like Category:Asaf Bartov by year (Q60439508). Maybe we could prioritize members of c:Category:Pages using authority control without Wikidata link, althought some of those already have wikidata items. --Jarekt (talk) 15:04, 7 January 2019 (UTC)
  • It is possible that the items could be potentially notable, however as they are now, they are not. The information about the potential notability should be provided by the creator, not expected to be provided by someone else. You can provide the proof of notability in Commons, and import only the items that have such information there.--Micru (talk) 16:03, 7 January 2019 (UTC)
  • @Jarekt: I went for commons:Category:People by name on the basis that it should just contain people (but it's not perfect, as Category:Asaf Bartov by year (Q60439508) demonstrated). c:Category:Pages using authority control without Wikidata link is a mix of people and other things so would need some extra logic coding up, but I could focus on that. I could also exclude a given list of categories, which could be generated based on the WMF/Wikimedian categories if need be. I'd be happy if this conversation ended up saying "we'll accept new items for wikimedia categories with <these defined criteria>, and <these defined exclusions>", but those needs to be things that can be coded (which 'notable' on its own is not). Thanks. Mike Peel (talk) 18:50, 7 January 2019 (UTC)
  • Mike, I had the same issue while creating wikidata items for large number of people then in c:Category:Creator templates without Wikidata link. I considered person notable if they had authority control identifiers, or if they had enough identyfying information to disambiguate their identity, like full name and dates of birth and death (at least one), or link to a reference, etc. If all we have is a name and occupation than it might not be enough to tell two people with the same name apart. I do not claim that such approach guarantees that someone is notable, after all you can get all of those from a random tumbstone, but I think it improves the odds. I would support a creation of new items if you avoided wikimedians, WMF staff, etc. (unless they are notable) and added more info based on category names, like dates of birth and death, occupation, citizenship, etc. By the way, in the past I used this AWB module and other similar ones to scrape off some of such info. Finally do you have any system for matching categories to existing items, so you do not create duplicates? --Jarekt (talk) 04:36, 8 January 2019 (UTC)
  • @Jarekt: Birth/death dates (and gender) were already being added. Occupation and citizenship are a bit harder to automatically derive from the category names, I'll have a think about how to do that. Apart from the extensive work I've already done to add sitelinks to existing items, any remaining possible matches (found primarily through search) are added to my distributed game for human checking, and are then avoided by the bot until the matches have been checked. Thanks. Mike Peel (talk) 07:22, 8 January 2019 (UTC)
  • I   Support Creating categories of humans based on Commons cats. I would not say that every Commons category needs a Wikidata item, at categories like c:Category:Aglais io on Hylotelephium flowers or c:Category:Brandenburg Gate from east that dose not make sense. But every "main-category", what person categories are, should have a Wikidata item. --GPSLeo (talk) 17:57, 7 January 2019 (UTC)
  •   Support Items for top level categories for people (vs. XX in 2017, etc.). Jheald and Ghouston explain well the usefulness of items for some of these supposedly non-notable people. Gamaliel (talk) 19:53, 7 January 2019 (UTC)
  •   Comment Having done some manual matching of economists derived from external authority files, I'd share the concerns and suggestions of Jarekt: The more persons identified only by their name (plus perhaps a picture, which normally does not help for researchers) we have in Wikidata, the harder the job of manually matching and adding more verified information gets. Jneubert (talk) 05:58, 8 January 2019 (UTC)
  •   Support Creating items for people who have a category on Commons. That is needed for SDC to work, and it meets current Wikidata policy. Regards, Yann (talk) 10:00, 8 January 2019 (UTC)
  •   Comment Guidelines here need to evolve. It is possible to imagine how we would accidentally out anonymous photographers by the synthesis of categories on Wikidata. Wikidata contributors diligently, and sometimes automatically, add birth dates, portrait photographs, work exemplars, references, artistic taxonomies and so on to a bio entry. A few of these correlations could easily line up alternative names with a photographer's or artist's real identity which may be original research. -- (talk) 11:19, 8 January 2019 (UTC)
  •   Oppose: this is not the right venue for these decisions. This proposal will add a loophole for Wikidata notability. Sjoerd de Bruin (talk) 16:28, 8 January 2019 (UTC)
    @Sjoerddebruin: Where would the right venue be? Thanks. Mike Peel (talk) 18:35, 8 January 2019 (UTC)
    Wikidata:Requests for comment, those are announced in the weekly newsletter and above the watchlist of every user. Reaching consensus on a project chat seems weird to me, but maybe that is because we have guidelines about that on the Dutch Wikipedia. Sjoerd de Bruin (talk) 18:38, 8 January 2019 (UTC)
    @Sjoerddebruin: Ah, this wasn't meant as an RfC, just to sound out what others thought about the issue to see if setting the bot re-running was controversial or not. I might do a more general RfC at some point about what different types of Commons categories it would make sense to bot-create wikidata items for, but that's something for the future. (Also, it does not look like RfCs actually get closed / acted on in a reasonable timeframe here from the list on that page!) Thanks. Mike Peel (talk) 21:06, 9 January 2019 (UTC)
    Not sure if the whole import is a good idea, but I don't see a problem to send false positives/not notables to WD:RFD, item creation doesn't establish notability, that's what WD:RFD is made for. --Marsupium (talk) 16:13, 17 January 2019 (UTC)
  •   Support first create wikidata item from category, then create creator template at commons, fill in references from authority control and artist databases. Slowking4 (talk) 04:14, 16 January 2019 (UTC)

Review of edits by user:Zhxy 519

I am not particularly active at this time, though I have noticed problematic edits and merges by User:Zhxy 519. I have undone those that relate to the wikisources, though others need checking. A native Chinese speak may wish to converse with this user as they seem to be mistaken in matters.  — billinghurst sDrewth 11:03, 12 January 2019 (UTC)

  1. I think I’m getting your points somehow and will stop doing this. However I’m afraid that such edits are not only done by me and quite common in WikiData. Also the traditional foreign language version links on the left side among wiki project pages will be challenged by this, especially in Wikisource. I will reserve my opinion.
  2. Only your undos Q18849710 and Q16260428 undone again. Q18849710 is a page deleted and can be never restored, and Q16260428 is author page which has nothing to do with edition.

Zhxy 519 (talk) 15:41, 12 January 2019 (UTC)

I think that this user is having many bad behaviors e.g. on La Marseillaise (Q41180), Thus He should be blocked here. --2409:8902:9001:7E2B:E47B:BCFE:1199:955D 06:56, 17 January 2019 (UTC)

FileExporter beta feature

Johanna Strodt (WMDE) 09:41, 14 January 2019 (UTC)

@Johanna Strodt (WMDE): Highly appreciated boils down to untested, feedback is rejected by some "insufficient permissions for this action" flow filter on MediaWikiWiki.
Can admins on Commons move files back, if they have to be deleted on Commons? Some US copyright details are rather bizarre (photos of coins = bad 3D, photos of PD pictures = good 2D, etc.), and major parts of the "move to Commons" procedures on dewiki/enwiki try to avoid any move not triple checked by human users, if it could result in a deletion on Commons. – 13:31, 14 January 2019 (UTC)
Hi! Thanks for taking the time to comment. Are you saying you cannot comment on the central feedback page? If so, something might have triggered a false positive of the spam filter, maybe an added link. I’m afraid that’s not in our control.
As for your question about moving files back: It's not a built-in feature, but it’s already possible to delete the file on Commons and restore the original file on the local wiki. Both steps require admin rights. Other users have mentioned this as well, and I’ve created a Phabricator ticket for that: T214065. I hope that helps. -- Johanna Strodt (WMDE) (talk) 17:55, 17 January 2019 (UTC)

Coffee house

I have just noticed that Q4236467 was remodelled, some time ago ,from "coffee house" to "Turkish coffee house". Should that be let or reverted? Hindoostane Coffee House (Q5766176), Jonathan's Coffee-House (Q3183299), Nando's Coffee House (Q16930669), Trew Era Cafe (Q19944780) and Carpenter's Coffee House (Q5045652) all use it, and non are Turkish, or Turkish-style. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:02, 15 January 2019 (UTC)

Given that for example the German translation still refers to the original it should be reverted. The meaning of items shouldn't be changed like that. ChristianKl❫ 17:22, 15 January 2019 (UTC)
Done. It would seem likely that someone needs to redo the Turkish-language description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:08, 16 January 2019 (UTC)
I would just delete the Turkish description given that it's wrong. ChristianKl❫ 14:18, 17 January 2019 (UTC)

Femicide as a manner of death

How can I register a woman's manner of death as a femicide if this property manner of death (P1196) is restricted and the closest one to choose is homicide (Q149086) and this isn't reflecting the hate crime against women? --Pablísima (talk) 21:56, 4 January 2019 (UTC)

  • You could qualify the killed by (P157) statement with has quality (P1552) ?--- Jura 22:30, 4 January 2019 (UTC)
    • What happens is that in many cases we don't have the murderer's name. --Pablísima (talk) 13:32, 6 January 2019 (UTC)
  • Why not femicide (Q1342425) as manner of death? ChristianKl❫ 10:05, 5 January 2019 (UTC)
    • Do we have a reference for that? --- Jura 10:08, 5 January 2019 (UTC)
    • I'm not sure what kind of reference you would want. femicide (Q1342425) instance of (P31) manner of death (Q2438541). What more would you want? ChristianKl❫ 10:24, 5 January 2019 (UTC)
      • "reference" is what goes in the corresponding section of a statement. Currently Q1342425 just has "0 references". --- Jura 10:32, 5 January 2019 (UTC)
        • I'm not sure why you ask me for a reference. I have spoken about the fact that certain information can be modeled in a certain way in Wikidata and not that a particular person was killed a particular way. ChristianKl❫ 14:07, 5 January 2019 (UTC)
          • I guess we could have a property for either (manner of death or femicide). --- Jura 08:17, 6 January 2019 (UTC)
  • Thank you for your suggestions. I think it would be great if we can put femicide as a manner of death (P1196) and use subclass of (P279) to clarify that is a form of homicide. Like it is in this example: But it isn't valid. So I don't know how to solve this issue. --Pablísima (talk) 13:32, 6 January 2019 (UTC)
@Pablísima: femicide (Q1342425) already subclasses homicide (Q149086). Currently, that claim has no source. Can you add a source that says it's a femicide? ChristianKl❫ 11:07, 13 January 2019 (UTC)
Hi @ChristianKl: I've just added two sources that confirming that femicide is a type of homicide.--Pablísima (talk) 22:19, 17 January 2019 (UTC)

Dishwashing needs, er, cleaning up

dishwashing (Q336152) has Commons category (P373) -> commons:Category:Dish washing; yet Category:Dishwashing (Q30646425) has the same Commons category linked under "Other sites". Is there a standard way to resolve this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:06, 17 January 2019 (UTC)

@Pigsonthewing: Looks right to me as it is: no cleanup needed?
In a case like this, where we have a Wikidata item for a category, and one for the subject of the category, current working consensus is that the category item here should have the sitelink to the Commons category; both items here should have Commons category (P373) set; and the two items should be interlinked via category's main topic (P301) / topic's main category (P910). The latter allows the Wikidata infobox on the Commons category to find and include information from the subject item, even though it is the category item that it is sitelinked to.
All of the above appears to be in place, so: nothing to fix? Jheald (talk) 17:37, 17 January 2019 (UTC)
Yup, that's all normal as things stand. The main issues here is that dishwashing (Q336152) needs expanding to better describe the topic. Thanks. Mike Peel (talk) 22:10, 17 January 2019 (UTC)

Link page from wikimedia.Commons with page exisiting on en.wikipedia with no existing item on wikidata fails

Hello I just created a new phabricator task Link page from wikimedia.Commons with page exisiting on en.wikiipedia with no existing item on wikidata fails which might interest people involved in wikidata. Thanks Robby (talk) 22:03, 16 January 2019 (UTC)

add statement button at the start

Is it possible to put an add statement button at the start of a page or the Statement section? It wastes time to scroll (or use find in browser) to get to the button hidden in the middle of long lists of statements and wikilinks. I also tried looking for a gadget.--Roy17 (talk) 02:00, 18 January 2019 (UTC)

+  --Hedwig in Washington (talk) 06:04, 18 January 2019 (UTC)
See phab:T142082. Matěj Suchánek (talk) 09:30, 18 January 2019 (UTC)

data from Wikidata in a semantic mediawiki project

Can I (or how i can) use data from Wikidata in my Semantic Mediawiki project? Can I use Wikidata's parser functions in a semantic wiki project?

Thanks for your time

Katikei (talk) 07:08, 18 January 2019 (UTC)

No, see phab:T48556. Matěj Suchánek (talk) 09:31, 18 January 2019 (UTC)

Mass creation of new items, no properties, no deduplication

What does the wikidata hive-mind make of this profile: articles with no items?

The linked graph appears to show that, every so often, someone or some people, take it into their head to clear down the backlog of en articles with no items, by the mass creation of items, to the tune of about 30-40k each time. I very strongly suspect that the method is to use Petscan to find such articles; and the creation of items with two strong characteristics: 1) no properties whatsoever and 2) no deduplication whatsoever. Clearly Petscan is designed to enable deduplication to be done rather than willy-nilly item creation; but it is equally possible to override Petscan defaults to force it to create items whether or not there's a string match between the article title and an existing item label.

I suspect at this work is being done by GZWDer (flood) (talkcontribslogs), operated by GZWDer (talkcontribslogs) - by way of example, here are 500 prototypical item creations - no properties, and for 50/50 no labels. I don't know if others also take this sort of approach.

The pros of the approach seem to be that the item is created, and thereafter can be found via a wikidata search. The cons, though, seem to be that none of the items have properties, and so they're not really accessible through WDQS. And there must be a significant proportion of duplicates created.

I'm troubled as to how, if at all, these items ever get surfaced, except on the margin, or through one of Magnus's games. Although it's possible to use Petscan to discover items lacking specific properties, I imagine the mainstream use of Petscan is to ask, does the item exist or does it not; and so I struggle to see a) how the mass of these items get improved, by way of property addition and b) how they are discovered such that they can be deduplicated. And next, given that Petscan, Duplicity &c provides facilities for spotting possible duplicates and deduplicating for articles with no items, once an item is created afaik we lose most or all of the support for deduplication, and so that task becomes more difficult.

In short, if the above narrative is the practice, is it a good thing to be encouraged, or a bad thing to be avoided? --Tagishsimon (talk) 14:54, 11 January 2019 (UTC)

I'm not sure if it's good or bad, but it is appropriate for more of us to be aware of it. How can we add a deduplication step into this process? Could we get notifications on when the bot runs, so other people can work on the deduplications? ArthurPSmith (talk) 15:44, 11 January 2019 (UTC)
I am currently running a query to get all items created by GZWDer (flood) (talkcontribslogs) without statements. --Magnus Manske (talk) 16:22, 11 January 2019 (UTC)
Hoi, this is a crisis of our own making. We have spurned the efforts at the Cebuan Wikipedia in the past repeatedly. As a group we/you decided that "this was not the thing to do" while at the same time denying the existence of sources used to build up projects like it. They were considered "not good enough".. I speak from personal experience that particularly when we consider a subject like "African towns, and administrative entities" I have been able to link many items created there in a single structure.
The first active purpose of Wikidata is to replace the interwiki system. The way it worked using bots, any and all Wikipedia articles get a link. With Wikidata we gained a better quality and imho it is our own intransigence and inaction to reach out that landed us here. When we want to improve things we start a conversation and ingest the data that is at the basis of the Cebuano ingestion processes. Thanks, GerardM (talk) 16:48, 11 January 2019 (UTC)
I don't even begin to follow your argument, Gerard. This is a discussion about - we find - 745k items, I suspect the majority sourced from, which have no statement, a significant proportion of which will be duplicates. I'm not privy to any information on 'spurning the efforts at the Cebuan Wikipedia in the past repeatedly', although I have seen posts of people mortally pissed off at the number of duplicates in the system. If you're right, we must have done something hella bad to to deserve this sort & scale of retribution. I suspect you're not right, but by all means develop your thesis without making an a priori assumption that we have a clue what you're talking about.
Arthur, the normal practice is to deduplicate before adding, which is to say not to add duplicates. Most of the good tools exist at the point before an article has been added to wikidata. Few of the good tools exist at the point after duplicates have been created - I can think only of the distributed game. I think prettymuch no-one is really interested in deduplicating someone else's mess, especially on this sort of epic scale.
Perhaps I'm a simple soul: would it not be better not to tolerate this sort of thing, fullstop? I charitably tried to present pros & cons, above, but really, I can see no real pros, just lots of damage which realistically will take years to fix. --Tagishsimon (talk) 19:46, 11 January 2019 (UTC)
@Tagishsimon: I have some experience with attempting to deduplicate both before and after adding items (mostly for organizations). It's tricky - there are some techniques (for example certain classes of SPARQL queries) that are much easier to do after the data import. But of course that usually requires at least some properties - though you can do some interesting deduplication queries based on labels and aliases I guess. ArthurPSmith (talk) 02:52, 12 January 2019 (UTC)

Update: My query has completed, and I converted it into a PagePile for convenience. There are 745,312 items that were created "blank" by GZWDer (flood) (talkcontribslogs), and still (at the time of writing this) do not have any statements. --Magnus Manske (talk) 19:19, 11 January 2019 (UTC)

Wow!! (Thanks for the query, Magnus). That number seems way too high. Now that we are aware of this issue, the obvious question would be: should this continue to be allowed? Maybe we could use some basic guidelines for bot creating items. For instance, checking for duplicates must happen always before creating an item, or all new items should include at least one property (probably more difficult). Andreasm háblame / just talk to me 20:58, 11 January 2019 (UTC)
This isn't the first topic about this process, btw. Sjoerd de Bruin (talk) 23:13, 11 January 2019 (UTC)
And won't be the last I'm afraid. For the Dutch Wikipedia people are pretty active linking up the unconnected pages to existing and new items. To prevent a backlog from forming I run the new item bot which will only create a new item if the article is at least 28 days old and hasn't been edited for over 21 days. This seems to work quite well. If you look at Wikidata:Database reports/without claims by site/nlwiki you'll see that the oldest item on the list is from January 2013.
I understand that on the English Wikipedia the number are much larger. But it's worth considering to also deploy the new item robot to at least have an item.
But that still leaves us with the empty items. I still operate User:NoclaimsBot. That robot will only add a claim when an item is empty. See for example this edit. As you can see in the edit summary, the claim is based on the used template. You can configure this on en:User:NoclaimsBot/Template claim. Looking at Wikidata:Database reports/without claims by site/enwiki I see quite a few templates that good be added. You only have to do that once and the bot runs every night on that database report. Who wants to help? Multichill (talk) 11:58, 12 January 2019 (UTC)
  • Ideally, we would like that users create items themselves. On the other hand, we don't want that items stay without any item. It feels to me like if we increase the amount of time till an item gets created that might encourage Wikipedians to create proper items. From out side it would be create if in such a case there would be a Item is currently unlinked in the interwiki list for those items. Clicking on that link could pop up a dialog that leads the user through searching for other items and creating a proper item themselves. ChristianKl❫ 09:32, 13 January 2019 (UTC)
  • I'm returning now. For reasons to creating such items, see Wikidata:Requests_for_permissions/Bot/GZWDer_(flood)_4. tldr: It will make a basis for other improvement (many tools, including PetScan, HarvestTemplates and projectmerge, does not work for unconnected pages).--GZWDer (talk) 17:11, 19 January 2019 (UTC)

class of award (Q38033430)

What the hell is a "class of award" and why are awards replaced with something that is totally unexplainable. I intend to revert all of them to award. Thanks, GerardM (talk) 08:43, 18 January 2019 (UTC)

It seems like it's for a subcategory of an award. Have you informed the relevant users about this? Sjoerd de Bruin (talk) 14:45, 18 January 2019 (UTC)
Because there is a distinction between a specific instance of Award, for example when Barrack Obama got the Nobel Price, and the Nobel Price itself, which is a class of such awards instances. author  TomT0m / talk page 16:10, 18 January 2019 (UTC)
Actually, I suspect it is more the relation between Nobel Prizes in general and (in this case) the Nobel Peace Prize. - Jmabel (talk) 17:27, 18 January 2019 (UTC)
Yes, but this implies that counter intuitively, both « Peace Nobel prize » and « Nobel prize » are (instnaces of) classes of awards, as they both have many concrete awarding instances. author  TomT0m / talk page 17:56, 18 January 2019 (UTC)
That is not the case. Mr Obama is a recipient of the Nobel Price, but the award is the recognition; Recognition in a specific tradition. There is no Nobel Price itself as it has its own subdivisions all Nobel prize, all part of that same recognition. All the words are meaningless in themselves.. It is not explained what an award class is, why we need it. It cannot be explained and therefore it is fud. Thanks, GerardM (talk) 18:22, 18 January 2019 (UTC)
  •   Comment I would expect just about every award (exceptions might be things like Orteig Prize (Q1930819)) are awarded many times, some of them many times in a single year. So they are (in general) abstract, and not specific concrete objects. And we have our usual confusion about where to put them in our class hierarchy. Some clear thinking is needed, but I'm not sure quite the best way to approach it... ArthurPSmith (talk) 19:31, 18 January 2019 (UTC)
    Proposition to clarify the terminology (every concept do not necessarily have to have its own item or property on Wikidata, it’s just at this point an attempt that we all discuss on the same page):
    • An « award-event » is a decision of a group of person / organisation that decides to reward somebody / another organisation for some reason.
    • There might be several things associated to an award event, such as a ceremony, a prize, a symbolic object such as a medal, an eternal gratitude or a symbolic title …
    Some award events may be unique, such as a sport event unique in history, or there may be several events of the same kind, there is many award events for the Nobel-price for example.
    • An « award-type » has « award-event » instances. In that sense, the Nobel Prize is an award-type. There is many things that we can associate to an award type, such as the period of recurrence of the ceremonies (yearly for the Peace Nobel Prize), the nature of the price itself (amount of money if relevant for example)
    • An « award-reward » is what is given to the recipient.
    Questions : The meaning of award recieved search. Is the value of « award received » the award-reward, the award-event, an award-type, any of these ? What is the « Nobel prize » item ? If we read the first sentence of the french or english article, the answer is probably « an award-reward-type ». author  TomT0m / talk page 11:54, 19 January 2019 (UTC)
That is so far removed from what we do, it does not even register. We register awards, when they are awarded to a given person and that is it. Thanks, GerardM (talk) 17:27, 19 January 2019 (UTC)


Hello. Is there a way to show that the person who held a position (Q4164871) is elected or appointed by?

For example, President of the European Commission (Q8882) is appointed by (P748) European Parliament (Q8889).

How can I show that President of Cyprus (Q841760) is elected (chosen by the voters)?

Moreover, how can I show that President of Cyprus (Q841760) is elected with Cypriot presidential election (Q60676589)?

Or maybe is one way to show them? Xaris333 (talk) 19:32, 18 January 2019 (UTC)

I found elected in (P2715) this could be used for your problem. But the President of the European Commission (Q8882) is also elected by the European Parliament (Q8889). So we need an item for "Election of the President of the European Commission" --GPSLeo (talk)
The usual method to show that President of Cyprus (Q841760) is elected in Cypriot presidential election (Q60676589) is with a office contested (P541) on the election, e.g.
To show that only a restricted set of people can vote in such an election, elector (P2319) is used, e.g.
--Oravrattas (talk) 23:30, 18 January 2019 (UTC)

OK. Thanks. Something more complicated. If we have Mayoral Elections Elections, we should have different item from each Municipality? For example,



< Mayoral Elections Elections, Cyprus (Limassol Municipality) > office contested (P541)   < Mayor of Limassol Municipality (Q28078366)     >
< Mayoral Elections Elections, Cyprus (Nicosia Municipality) > office contested (P541)   < Mayor of Nicosia Municipality (Q12878858)     >
< Mayoral Elections Elections, Cyprus (Larnaca Municipality) > office contested (P541)   < Mayor of Larnaca Municipality (Q28078123)     >


< Mayoral Elections Elections, Cyprus (Limassol Municipality) > subclass of (P279)   < Mayoral Election, Cyprus (Q60686170)     >
< Mayoral Elections Elections, Cyprus (Nicosia Municipality) > subclass of (P279)   < Mayoral Election, Cyprus (Q60686170)     >
< Mayoral Elections Elections, Cyprus (Larnaka Municipality) > subclass of (P279)   < Mayoral Election, Cyprus (Q60686170)     >

Xaris333 (talk) 11:23, 19 January 2019 (UTC)

You will end up with a separate item for each individual election you want to store distinct information about e.g "2016 Limassol Mayoral Election": each individual election is a distinct thing, and would also have separate values for ballots cast (P1868), total valid votes (P1697), successful candidate (P991), etc. Having those all share the same base class (e.g. "Mayoral Election in Cyprus") isn't wrong in any way, but introducing a new item for each distinct one ("2016 Limassol Mayoral Election" is instance of "Limassol Mayoral Election" is subclass of "Mayoral Election in Cyprus") gives you a little more flexibility (e.g. being able to add distinct office contested (P541) values), at a one time cost. --Oravrattas (talk) 15:09, 19 January 2019 (UTC)

@Oravrattas: I am confused. You mean:

< 2016 Limassol Mayoral Election > subclass of (P279)   < Limassol Mayoral Election >
< Limassol Mayoral Election > subclass of (P279)   < Mayoral Election, Cyprus (Q60686170)     >


< 2016 Limassol Mayoral Election > subclass of (P279)   < 2016 Mayoral Election, Cyprus >
< 2016 Mayoral Election, Cyprus > subclass of (P279)   < Mayoral Election, Cyprus (Q60686170)     >

? Xaris333 (talk) 15:21, 19 January 2019 (UTC)

@Xaris333: 2016 Limassol Mayoral Election is a specific item, so whichever route you take it would use instance of (P31) rather than subclass of (P279). My suggestion would be:
< 2016 Limassol Mayoral Election > instance of (P31)   < Limassol Mayoral Election >
< Limassol Mayoral Election > subclass of (P279)   < Cyprus Mayoral Election >
(or even just mayoral election (Q15280243))
I'm not entirely sure what Mayoral Election, Cyprus (Q60686170) represents (or will represent) — items named in the plural are usually representations of Wikimedia list article (Q13406463). If this is something new you're creating for this purpose, I'd name it in the singular rather than the plural. --Oravrattas (talk) 15:36, 19 January 2019 (UTC)

@Oravrattas: Mayoral Election, Cyprus (Q60686170) is like Italian local elections (Q3722112). For president, we have Cypriot presidential election (Q60676589). For local goverments, municipalities, we have Mayoral Election, Cyprus (Q60686170). Xaris333 (talk) 15:43, 19 January 2019 (UTC)

In your example, there is not an item 2016 Mayoral Election, Cyprus. I add that because the elections for all Cypriot Municipalities, for example at 2016, are called 2016 Mayoral Election, Cyprus. So, 2016 Limassol Mayoral Election, 2016 Nicosia Mayoral Election, 2016 Larnaca Mayoral Election etc was part of 2016 Mayoral Election, Cyprus. I just wanted to clear that. It's ok with me not to use that item, but is that the correct way? Xaris333 (talk) 15:53, 19 January 2019 (UTC)

Wikidata:Project chat -> Add topic

In some wikis, when you go to the last topic of Project chat, you have the option to select Edit and Add topic. You don't have to go to the top of the page to select Add topic. Not a serious problem but sometimes Project chat is too big... Xaris333 (talk) 19:37, 18 January 2019 (UTC)

There is a gadget (Preferences->Gadgets) named NewSection that does that. --Shinnin (talk) 19:52, 18 January 2019 (UTC)
Thanks! Xaris333 (talk) 19:54, 18 January 2019 (UTC)

Official colors (school colors, team colors, etc.)

Is there currently a way to note official colors of an organization, like a school or a sports team? I can't find a property that seems appropriate, and color (P462) with qualifiers seems inelegant. Trivialist (talk) 19:33, 6 January 2019 (UTC)


is not enough? Xaris333 (talk) 20:25, 6 January 2019 (UTC)

  • would imply to me that Liverpool football club is red, which is not what we mean here. I would support a new property for "official color" = team colors = school colors (Q3246652). - PKM (talk) 20:54, 6 January 2019 (UTC)
    • That's what I was thinking of—saying a school's colors are blue and white could be interpreted to mean that the school's actual physical structure is blue and white. Trivialist (talk) 21:03, 6 January 2019 (UTC)
Agree, see stats. At the moment 1496 uses for association football club (Q476028), 124 political party (Q7278), both used by multiple infoboxes.--Jklamo (talk) 21:07, 6 January 2019 (UTC)
There's also the rather awkwardly named, and not-very discoverable sRGB color hex triplet (P465), which is documented to be used in this sort of context for things like political parties (and seems to have more uses for those than color (P462), which should be harmonised one way or the other). There are currently a tiny handful of uses on sports teams as well, e.g. New York Yankees (Q213417). --Oravrattas (talk) 21:55, 6 January 2019 (UTC)
Interesting, I did not know that property :-) I can see 136 political party (Q7278), which is slightly more. I am not sure if there is need for harmonization, as both color (P462) and sRGB color hex triplet (P465) are a slightly different aspects, both can be useful (for example sRGB color hex triplet (P465) for coloring the infobox and color (P462) as infobox parameter). Also for smaller teams/political parties exact sRGB color hex triplet (P465) may not exists.--Jklamo (talk) 23:59, 6 January 2019 (UTC)

Wikidata:Project chat/Archive/2016/07#Colours of a team. 2,5 years ago I asked Project Chat about which property should I use for the colours of a team. Only one person answer and he suggest color (P462) (which could be used with the appropriate qualifier). I have added that property to many teams' items. Is so tired when you asked project chat, get only one or few answers, applied the only suggestion you got and years laters the community want to change that because it was wrong. I am not against of having a new property, is reasonable. I am just showing that repeated situation. I have asked Project chat, I haven't use the property with out asking. If more users answered then, we would have the right property to items 2 years ago. Is so dissapointed. Xaris333 (talk) 23:45, 6 January 2019 (UTC)

Do not be dissapointed! This is community project, so sometimes there is no one "correct" answer/option. color (P462) is used by multiple versions of Template:Infobox football club (Q5611964), so adding it to teams certainly was not useless.--Jklamo (talk) 00:08, 7 January 2019 (UTC)
We might also use ”color” modified with <of> “school colors” or “team colors”. - PKM (talk) 21:07, 7 January 2019 (UTC)
It would make sense to have a document that specifies which properties should be used for what purpose with sports team the way we have with embassies at Such a document would be the only way to come to a consensus about what's right for the sport clubs. @Xaris333: given that you seem interested in the sport items, you might start writing such a document and thinking about where it has to be linked. ChristianKl❫ 09:55, 8 January 2019 (UTC)
@ChristianKl: I have tried it in the past but we couldn't have an agreement. Wikidata:WikiProject Association football/Discussion about properties Xaris333 (talk) 11:54, 8 January 2019 (UTC)
@Xaris333: have added player properties to that list - Unnited meta (talk) 07:24, 13 January 2019 (UTC)

Wikidata:Property proposal/official color Xaris333 (talk) 19:50, 8 January 2019 (UTC)

Japan Football
Unnited meta
محمد آدم
Сидик из ПТУ
Sakhalinio   Notified participants of WikiProject Association football What do other people of the project have to say about the page? ChristianKl❫ 11:01, 13 January 2019 (UTC)

    • I would rather support the idea, the property of "official symbol" doesn't not imply linking with sport teams, I guess. Team's official colours are same relevant as e.g. club official emblem. --Wolverène (talk) 11:12, 13 January 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── FYI all, the new property official color (P6364) was created a couple of weeks ago. - PKM (talk) 20:31, 19 January 2019 (UTC)

Scottish clan chiefs

Should "Chief of Clan Maclean" be a position held, or is it considered a noble title? --RAN (talk) 20:16, 19 January 2019 (UTC)

It seems to be an inherited position, so a noble title. If there are some duties associated with the position, perhaps it would be both? Ghouston (talk) 00:13, 20 January 2019 (UTC)
That would probably make more sense if I'd used "title" instead of "position" in two instances. Ghouston (talk) 01:32, 20 January 2019 (UTC)

How active: WikiData Community

I am a data scientist who has always believed in freedom of information. I would wish to contribute multiple terabytes of datasets and sources that I have accumulated and are public.

Please respond if this community is active and discuss with me how best to do this.

I’m a fan of this idea!

posted by PassionateCuriosity (talk) 03:11, 19 January 2019 (UTC)

Wikidata:Data donation. Paucabot (talk) 06:36, 19 January 2019 (UTC)
Welcome to the community - it's definitely on the active side! :) If you haven't seen it yet, Wikidata:Data_donation is a good place to start on how to go about contributing/onboarding data. Who to reach out to specifically really depends on the domain on your data. There are different WikiProjects each with their own area of expertise. One of the challenges is to match the schema of your data to Wikidata's - which is where the expertise of various WikiProjects comes in. the What sort of data are you hoping to contribute? Cheers! ElanHR (talk) 06:37, 19 January 2019 (UTC)
@Paucabot: @ElanHR: Can either of you add notation to correct my note edited in the signature for "PassionateCuriosity" following the original comment above? I don't know the template for adding it properly? Or @PassionateCuriosity:, perhaps you can edit it and sign with four tildes? Regards. Trilotat (talk) 15:49, 20 January 2019 (UTC)

same object?

Can somebody please check whether portrait at bust length (Q241045) and bust (Q17489160) are the same object? Merge or separate more clearly. --Herzi Pinki (talk) 00:31, 20 January 2019 (UTC)

Descriptions, statements, and even sitelinks are different, so I do not see how. Andreasm háblame / just talk to me 00:39, 20 January 2019 (UTC)
  • The subclass statements are pretty similar: they are both portrait sculptures. There's not much overlap in the sitelinks, although frwiki is connected to both. Ghouston (talk) 01:12, 20 January 2019 (UTC)
  • The French article fr:Buste says the term can be used for a particular style of paintings (where the Google translation isn't good enough that I understand it). I think they've just combined two dissimilar (but related) concepts that share a word. Much as there's an alternative English meaning of the word, but en:Bust_(sculpture) is disambiguated. Most of the project links probably want bust (Q17489160). Ghouston (talk) 01:41, 20 January 2019 (UTC)
No need for Google translate when several editors already took the time to explain the difference. Somebody had changed one subclass statement, but the rest was clear. portrait at bust length (Q241045) refers to artworks in general, whereas bust (Q17489160) is limited to sculptures. That is why they are an instance of art genre (Q1792379) and genre of sculpture (Q18783400), as well as a subclasses of portrait (Q134307) and portrait sculpture (Q28777669), respectively. Again, it's always a good idea to take extra time checking the descriptions and statements, so no extra time is wasted. Andreasm háblame / just talk to me 02:19, 20 January 2019 (UTC)
Removing the "subclass sculpture" statement certainly helps, but it was hardly clear. portrait at bust length (Q241045) still has topic's main category = Category:Busts (sculpture) (which I'll fix) and the interwiki links are apparently confused. E.g., nl:Buste (kunst) is about sculpture (which I'll fix). The English label "bust" may be misleading because I don't think the word is normally used that way in English. Ghouston (talk) 02:47, 20 January 2019 (UTC)
Hmm, I suppose two category items are needed because fr:Catégorie:Buste seems to have the expanded usage. Ghouston (talk) 02:50, 20 January 2019 (UTC)
The term used on Commons for such paintings is "portraits at bust length", at c:Category:Portrait paintings at bust length. I don't think they would normally be called "busts". The Commons category c:Category:Portraits at bust length (which includes sculpture and paintings and photographs) can perhaps be linked with fr:Catégorie:Buste. Ghouston (talk) 03:02, 20 January 2019 (UTC)
Basically concurring with Ghouston: a "bust" is necessarily a sculpture, but "at bust length" just refers to the portion of the body shown in a painting or photograph. - Jmabel (talk) 10:43, 20 January 2019 (UTC)

SNCZI-IPE reservoir ID (P4568)

When following the formatted link, e.g., I get an SEC_ERROR_UNKNOWN_ISSUER security error. How to deal with? I usually don't overrule these certificate errors. Can we unlink this property values until everything is proper again? best --Herzi Pinki (talk) 20:31, 20 January 2019 (UTC)

Internal server errors

I've been getting "500 internal server error" intermittently on OAUTH/QuickStatements login for the last several days, but today it's consistently failing. Anyone know what's up? - PKM (talk) 21:46, 20 January 2019 (UTC)

And of course it's back now. - PKM (talk) 21:46, 20 January 2019 (UTC)
Same here - it seems to lose your WIDAR login state after some time, and then it takes 10 minutes or more to get back in. Has been happening for several days now. ArthurPSmith (talk) 02:08, 21 January 2019 (UTC)
Same here. :/ --Marsupium (talk) 02:29, 21 January 2019 (UTC)

CiteTool (autofill for references)

For some time, I've been using User:Aude/CiteTool.js when adding citations; it adds an "autofill" command which populates parameters using Citoid.

It recently stopped working I have no "autofill" option (consistently, not just intermittently). On looking for help, I found that an improved version was available, at User:MichaelSchoenitzer/CiteTool.js. I switched to that but it too is not working.

Is anyone else having issues? Is there a fix? @Aude, MichaelSchoenitzer: for info. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:16, 4 January 2019 (UTC)

I think that stopped working for me as well. Jc86035 (talk) 18:34, 4 January 2019 (UTC)
I'm confused because I can't imagine how a program could do a proper job of citing a source for a statement in Wikidata. This is because it isn't a simple matter of adding a number of adding a reference with a number of qualifiers to the statement. One has to check if the source already has an item, and use it; otherwise add the source as a new item. Similarly for authors. Jc3s5h (talk) 20:44, 4 January 2019 (UTC)
@Jc3s5h: The script does/did not have that capability, and right now news articles with items are still rare enough that it's not necessary to check, I would think. Presumably it would be possible to fix this after the fact (if news articles are ever imported) by matching URLs in references to items. Jc86035 (talk) 06:43, 6 January 2019 (UTC)
@Jc86035: your post at 06:43, 6 January 2019 (UTC) is the first mention of news articles. I would think many items that need citations would/should be supported by a citation to something other than a news article. Also, it wouldn't be normal to add an item for a particular news article, but it is typical to have items for news publictions and programs, such as The New York Times (Q9684), Meet the Press (Q1543066), or The Times (Q50008). If an appropriate item for the pubication or program exits, it would only be necessary to add qualifiers to the statement being supported giving the date, article title, episode information, etc. If authors are identified, items should searched for and, if necessary created. Jc3s5h (talk) 15:57, 6 January 2019 (UTC)
@Pigsonthewing, Jc86035: I have a fork at User:Mvolz_(WMF)/CiteTool.js that works. Just FYI it's very slow, because it's looking up items. If you get impatient you can press 'esc' and just save what's produced thus far. It has a lot more properties than the older version but it's also very greedy, so you may need to remove some snaks before publishing. Mvolz (WMF) (talk) 14:40, 8 January 2019 (UTC)
Thank you. I'm still curious as to why (and when) the original tool stopped working. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:57, 11 January 2019 (UTC)
@Andy Mabbett, Aude, Jc3s5h: Sorry for the delayed answer! The original script stoped working in autum, when the security settings for userscripts and gadgets where changed. JSON-files can now not be loaded anymore wiht contenttype javascript. All users of audes version should be pinged to swich to Mvolzs or mine version. Alternatively Aude or any itnerface admin could fix Audes version.
User:Mvolz (WMF) and me both did forks of the original script in which we not only fixed this and a few bugs in the original code but also added lots of features! Sadly we didn't knew of each others work and therefore developed to versions independently. We added several features independently to both versions and both of us added features that the other version doesn't have. There's no easy way to get back to one tool with all the features. We'd have to put in a lot of effort for that. Since I'm dooing this in my free time I currently have not enough time for that. -- MichaelSchoenitzer (talk) 15:11, 16 January 2019 (UTC)
@Pigsonthewing: new ping due to mixup of username. -- MichaelSchoenitzer (talk) 15:12, 16 January 2019 (UTC)
@MichaelSchoenitzer: Thank you, but as I said above, your version is also not working for me. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:59, 21 January 2019 (UTC)

Wikidata weekly summary #348


Why "An entity with diocese (P708) should also have a statement religion (P140)." [22]? Maybe as a qualifier... Xaris333 (talk) 18:51, 20 January 2019 (UTC)

I think they should have a religion (P140), If you are adding a "church" or "congregation" that belongs to a diocese, it must belong to a particular religion. That way someone can look up all the Lutheran churches vs. the Roman Catholic churches in a particular geographic area. --RAN (talk) 22:20, 20 January 2019 (UTC)
@Richard Arthur Norton (1958- ): Ok. But also a municipality belong to a diocese. Municipalities don't have a religion. Xaris333 (talk) 14:40, 21 January 2019 (UTC)
The municipality should usually have a separate item. ChristianKl❫ 17:27, 21 January 2019 (UTC)
@ChristianKl: What do you mean? Xaris333 (talk) 17:31, 21 January 2019 (UTC)
@Xaris333: Municipality definetely does not belong to a diocese. They share some territory, but that's it. Dioceses are divided into deaneries, parishes etc., but let us not confuse state and church administrative divisions. I think we can link those two types of entities by adding located in the administrative territorial entity (P131) to the church divisions. If you really have to, you could probably use located in the ecclesiastical territorial entity (P5607) the other way round, but my personal view is that P5607 should be used only for religious items, not state ones. Powerek38 (talk) 17:32, 21 January 2019 (UTC)
@ChristianKl: So, Q349340#P708 is a wrong statement? Xaris333 (talk) 17:41, 21 January 2019 (UTC)
Without being able to understand the relevant languages my impression ist: No, but Diocese of Limassol (Q16331837) should state the religion. ChristianKl❫ 17:55, 21 January 2019 (UTC)
@ChristianKl: Now Diocese of Limassol (Q16331837) states the religion. But the problem is the constraint in Q349340#P708. Xaris333 (talk) 18:54, 21 January 2019 (UTC)
@Xaris333: that would be because diocese (P708) is intended strictly for church entities: parishes, churches etc. (which ought themselves have that property, hence the constraint). As pointed out by Powerek38 above, municipalities and other secular entities such as Yermasoyia (Q349340) are better off using located in the ecclesiastical territorial entity (P5607), as the relation is geographical, not administrative (the diocese has no administrative or similar power over the municipality). Circeus (talk) 01:04, 22 January 2019 (UTC)
@Circeus: So, is the correct statement? Xaris333 (talk) 12:59, 22 January 2019 (UTC)

According to Wikidata:Database reports/Constraint violations/P708 there are 49162 violations. I check some, they are municipalities and other secular entities. Maybe users don't understand the use of diocese (P708) or don't know located in the ecclesiastical territorial entity (P5607). I had the same problem. Xaris333 (talk) 13:57, 22 January 2019 (UTC)

JAnDBot Wikisource category creations

It seems JAnDbot is creating data items for all categories on English Wikisource, whether or not these categories apply anywhere else. I thought we'd agreed not to do so for Commons (or has that changed?) If we're not doing it for Commons, then why do it for Wikisource?

Most of these categories will have no equivalent on any other project ever.

For example:

Will data items for any of these (or their many similar data items) be of any use whatsoever? --EncycloPetey (talk) 20:52, 21 January 2019 (UTC)

For example, in cs.wikisource exists some translated articles from EB1911, so similar category might exist in future. There are many categories from various projects which have no equivalent in different project.
And second problem - some of categories have equivalent, but are not connected yet, some not. And nobody can recognize if exist or not, when are stored somewhere in local project, not in Wikidata.
But I stopped creation for now. JAn Dudík (talk) 21:01, 21 January 2019 (UTC)
From what I saw on a brief inspection, fewer than 1 in 100 of these categories will have a possible equivalent anywhere else. It would make more sense to prepare a batch list and ask people to identify the ones that can be matched to existing data items, instead of creating thousands of unattached data items, most of which will be of no value and have no possible connections. --EncycloPetey (talk) 21:05, 21 January 2019 (UTC)
Yeah, they don't seem very useful. I tried to change the Notability policy a while ago, to remove the explicit reference to Commons and replace it a more generic principle: that category items should only be created if a) they have two sitelinks, or b) there's one sitelink but it's linked with a main item. It didn't get anywhere though. Ghouston (talk) 21:15, 21 January 2019 (UTC)
  • Looking through the bot edits (see JAnDbot (talkcontribslogs)), a lot of them look like useful links to me that easily meet notability (you've cherry-picked your examples here). However, there doesn't seem to be adequate duplicate checking, for example Q60773447 is the same as Category:Prime Ministers of Canada (Q9054940), and that could be improved. Thanks. Mike Peel (talk) 21:47, 21 January 2019 (UTC)
    Hardly "cherry-picked". I only posted after the Bot created more than 100 data items for categories for articles from the 1911 Encyclopædia Britannica. The more recent edits appear to have been checked against Wikipedia categories (although apparently not checked against Commons). --EncycloPetey (talk) 23:21, 21 January 2019 (UTC)

Can someone help fix the Wikidata Tours?

Hi all

The Wikidata:Tours are a very valuable tool for beginners to start learning Wikidata (and could also be used to explain more complicated things as well) Unfortunately there is an error causing many of the Wikidata to be non functional so they cannot be published. Please can someone take a look at the code and try and find the error?

Thanks very much

John Cummings (talk) 12:16, 22 January 2019 (UTC)

Smaller media franchises

How are they intended to be structured? Take Long Riders! (Q19829609) as a random example. It has a manga and an anime combined into one entry (currently incomplete). Should they be separated? Most of these franchises are currently combined entries, so are they technically all wrong? Should there also be a separate entry for the franchise itself? Assuming it was split, which entry is supposed to get the Wikipedia links, the original or the most notable? This might all be covered in an FAQ somewhere but I couldn't find it. —Xezbeth (talk) 14:06, 22 January 2019 (UTC)

@Xezbeth: The manga and anime should definitely be separate items (since they're different creative works), and maybe the franchise could receive its own item as well. I'm guessing that if the first sentence of the article says "Long Riders! is a manga …" then the sitelink should be on the item for the manga, and vice versa, although it might alternately be appropriate to link all such pages to the franchise item regardless of what each article's introduction says it's about. The most recent project chat discussion was in September. I personally think Wikidata tends to lack sufficient documentation for most things. Jc86035 (talk) 14:17, 22 January 2019 (UTC)

Connection between wiki (Q171) and wiki software (Q6686945)

At the moment, these two items are only linked by different from (P1889). We don't actually show the connection between them. The connection is also lacking between website (Q35127) and web server (Q11288). What is the best property to express this relation? uses (P2283)? MartinPoulter (talk) 15:15, 22 January 2019 (UTC) PS. I note the existence of software engine (P408), but that seems to be intended to point to specific software engines, not type of software. MartinPoulter (talk) 16:53, 22 January 2019 (UTC)

software engine (P408) is permitted on websites, according to constraints. It's used on Wikipedia (Q52). wiki (Q171) vs wiki software (Q6686945) seems like an abstract version of that. uses (P2283) also seems OK, in a less specific way. Ghouston (talk) 21:07, 22 January 2019 (UTC)

Merge 2x Andreae, Samuel Traugott

Q55133437 = Q55122657 18:12, 22 January 2019 (UTC)

Done. 22:13, 22 January 2019 (UTC)

Author name string

We use "author name string" when we do not have a Wikidata entry for an author. When I add an entry for an author, should I delete the field for "author name string"? See Decoding an Ancient Computer (Q55922387) --RAN (talk) 23:11, 21 January 2019 (UTC)

Do not be fooled. Author name string is always used by mass imports (i.e. of BHL, or articles...) even if there is a clear, unambiguous match on wikidata. Circeus (talk) 00:48, 22 January 2019 (UTC)
Is that an answer to the quesiton? I delete them, since they seem redundant. I put the value in a stated as (P1932) qualifier, although I've noticed that these author name strings, taken from databases, often don't match how they are written in the original article. Ghouston (talk) 01:33, 22 January 2019 (UTC)
I'm not sure that it's so easy to match authors. Maybe there's only one "John Smith" in Wikidata, but that doesn't mean the "John Smith" in the article you are importing is the same guy. Well, I checked and there are already multiple John Smiths, which just makes it even harder. Ghouston (talk) 01:49, 22 January 2019 (UTC)
They should be replaced by the correct item, if it exists, then deleted. At least that's what I always do. Circeus (talk) 05:42, 22 January 2019 (UTC)
But is that correct practice? For example for use in citation templates it is very useful to have original "author name string", as we are interested in both author (P50) (to link author article/item) and author name string (P2093) (to show actual author string, it may be pseudonym maiden name etc.--Jklamo (talk) 12:42, 22 January 2019 (UTC)
Yes, that's true. Skim (talk) 12:46, 22 January 2019 (UTC)
It is common practice to delete the property and add the information to the stated as (P1932) as a qualifier under author (P50). This is what does. — Finn Årup Nielsen (fnielsen) (talk) 13:00, 22 January 2019 (UTC)
Also when the "author name string" is there Scholia regards the author as "missing", see, e.g., Årup Nielsen (fnielsen) (talk) 13:06, 22 January 2019 (UTC)
Also, if was bad practice to delete the author name strings, we should also be adding them when they are missing. It would be an easy bot task to derive them from the author. I'm not convinced it would be useful though. Ghouston (talk) 21:20, 22 January 2019 (UTC)
  • I came here from the WikiProject Source Metadata ping. I delete "author name string" when we have the same information in "author". Blue Rasberry (talk) 13:23, 22 January 2019 (UTC)
  • I am now using almost exclusively to do this work. It uses QuickStatements to add author qualified with "stated as" the original string, preserve the series ordinal number, and remove the author name string. (Example results at A Review of Periodical Literature on Textile History Published in 1974 (Q58342779).) But you still must determine that this particular "J. D. Smith" author name string is the same as the "John David Smith" you are matching to. I use a combination of the author's bibliography, the journal published in, the co-authors, the article itself, and the subject matter to determine this. (I admit I have it comparatively easy, working with textie and costume historians.)- PKM (talk) 19:52, 22 January 2019 (UTC)
Hoi, from someone who uses the "sourcemd" tool a lot, yes, publications are created with "author strings" only. In a second run known authors are added and the author strings are replaced. Having both "author" and "author string" is bad news. Typically the strings used in the publication can be found in a qualifier. Thanks, GerardM (talk) 13:40, 23 January 2019 (UTC)
It would be cool when for every paper without an author a sourcemd process is started to add the authors. Thanks, GerardM (talk) 13:55, 23 January 2019 (UTC)

Why does the article appear to have a subtitle but no Wikidata page?

The article w:Native American ethnobotany appears on the Wikipedia mobile app with the subtitle "Medicinal plantç" [sic]. This is while there does not exist a Wikidata page associated with the page, as seen here, where is this subtitle likely coming from, I'm assuming from somewhere on Wikidata? The Editor's Apprentice (talk) 23:51, 22 January 2019 (UTC)

@The Editor's Apprentice: I have made some improvements to Native American ethnobotany (Q6806679) which should help. You could not find the page in your search because you were looking for the Wikipedia page title which, rightly or wrongly, does not seem to be indexed for search. Bovlb (talk) 23:59, 22 January 2019 (UTC)
Interesting. Thanks for improving the page. If you don't mind me asking how did you find the page yourself, and how is a page marked not to be indexed for search? The Editor's Apprentice (talk) 00:59, 23 January 2019 (UTC)
I'm guessing the answer is, the item's labels, descriptions and aliases are indexed, but the sitelink names are not indexed. And in this case, "Native American ethnobotany" did not appear in any of the labels, descriptions nor aliases, but only in the sitelink. The en article has been linked to the wikidata item since 2013. --Tagishsimon (talk) 01:14, 23 January 2019 (UTC)
The problem with your search was that you wrote "American Native ethnobotany" instead of "Native American ethnobotany". By the way, sitelinks are indexed but this isn't related to ItemByTitle. Matěj Suchánek (talk) 14:57, 23 January 2019 (UTC)
The easy way is to use the "Wikidata item" link on the left side of the Wikipedia page, desktop version. Ghouston (talk) 02:08, 23 January 2019 (UTC)
Only if "Open link in new tab" is used. - Brya (talk) 06:22, 23 January 2019 (UTC)
Awesome, that you both for the information. The Editor's Apprentice (talk) 15:08, 23 January 2019 (UTC)

Fred Figner / Frederico Figner / Federico Figner - Jewish Czech immigrant to Brazil 1900s

I might be wrong, but it looks to me like Fred Figner Q5495141 and Federico Figner Q5440996 are one and the same. Two distinct WP articles in English blocks a merge. What's the procedure to deal with that, is there somebody/someplace I should notify? Moebeus (talk) 02:11, 28 January 2019 (UTC)

They should be merged on the English Wikipedia, as described at en:Wikipedia:Merging. Ghouston (talk) 02:55, 28 January 2019 (UTC)
Merged and fixed. Note that both articles were created in 2007, so 12-years old duplicates found thanks to Wikidata.--Jklamo (talk) 01:07, 29 January 2019 (UTC)
@Jklamo: @Ghouston: Great stuff, thank you both! Moebeus (talk) 09:40, 29 January 2019 (UTC)
This section was archived on a request by: Moebeus (talk) 09:41, 29 January 2019 (UTC)

Ski resort AND Town/Mountain

I asked this recently at Wikiproject Sport, but received no reaction. I'd just like a 'second opinion' on my approach, please.
I recently successfully proposed the creation of ID (P6389), our first ID property relating to ski resort (Q130003). I'm now trying to clean up the existing items before creating new items based on the missing-matches from that Property.
As you can see at THIS QUERY there are about 100 items which are BOTH 'instance of' ski resort (Q130003) AND a subclass of human settlement (Q486972) (town, village, commune...) Equally, at THIS QUERY, you see there are a dozen items which are both 'instance of' ski resort (Q130003) AND a subclass of geomorphological unit (Q12766313) (mountain pass, hill, mountain, valley...)
To me this seems inaccurate... The instance of (P31) of items all seem to be generated via Wikipedia import. In Wikipedia it is natural and normal to write an article that discusses the [otherwise insignificant] hill, the [tiny] town, and its associated ski-field all together in one page. But I feel like town/mountain/ski-resort should be split into different things on WD. For example here's a single WD item Plateau de Beille (Q764281) whose Wikipedia articles talks about the geology, the Tour de France cycling stages, the ski-resort... (English WP, French WP).
Therefore, I am working my way through these above queries manually, and deciding on a case-by-case basis how best to separate the information and items between Ski Resort, Town, and Mountain. Sometimes the existing metadata and inbound sitelinks are more relevant to the former, sometimes to the latter, sometimes mixed (hence the manual approach). For example, here's an mountain/ski-resort in Finland that I recently split into two items (Levi (Q262837) and Levi (Q60806057)) where I determined that the inbound sitelinks were primarily talking about the ski-resort so I broke-off the Properties relating specifically to the hill into a new item. In other cases it's the reverse...
Does this all sound right to you? Wittylama (talk) 14:14, 22 January 2019 (UTC)

That's how I've been tackling items like Native Anerican tribes and their reservations, lighthouses and the islands they sit on, and recreation areas/lakes. In your case, I'd use "located on terrain feature"/"located in the administrative territorial entity" to link them together. Alternatively, you can make "parent" items tagged as <instance of> Wikipedia article covering multiple topics (Q21484471) with "has parts" of the town, resort, and mountain, which lets you keep all the interwiki links together. - PKM (talk) 20:03, 22 January 2019 (UTC)
Thank you PKM for that reassurance :-) Yes, I'm using located on terrain feature (P706) to indicate the relationship of the ski-resort to the hill, but I've not found an appropriate way to indicate the reverse (i.e. how to say on the item about the hill that there's a ski-resort on top of it?). Equally, both the town and the ski-resort should have the same located in the administrative territorial entity (P131) statement but I've not found a way to indicate the relationship between each (except sometimes I use different from (P1889) when the name of the town and the ski-resort are the same). Any suggestions (apart from <instance of> Wikipedia article covering multiple topics (Q21484471), which is a new item I'd not seen before but I think will come in very handy in some cases like when the ski-resort stretches across multiple towns, notably w:en:Portes du Soleil.) Wittylama (talk) 18:59, 23 January 2019 (UTC)
Definitely the right practice, town/mountain should be separated from ski resort item. But as you noted, to decide, where to add sitelink, maybe sometimes very difficult.--Jklamo (talk) 10:27, 24 January 2019 (UTC)

Toggle collapse/uncollapse

Hello, I've noticed some wikielements can have very lengthy statements. For instance, France (Q142) is a very long page, it would be nice that by default every statement is reduced with a toggle button)

Bouzinac (talk) 22:14, 24 January 2019 (UTC)

Statement GUID's and WDQS?

This may be an extremely technical question but I'm not sure where to find somebody who would know the answer here... According to the RDF specs, "There is no guaranteed format or meaning to the statement id." Nevertheless it appears that statement id's obtained via SPARQL queries are almost identical to the statement id's used in the Wikidata API - for example with 'wbgetclaims' you can specify a "claim GUID" according to this API documentation. The only difference is that the first '-' character in the id obtained via the SPARQL/RDF context is replaced by a '$' character in the API context. Is this a reliable relation? Is it actually documented anywhere??? ArthurPSmith (talk) 20:02, 14 January 2019 (UTC)

@ArthurPSmith: hm, good point, I didn’t realize we don’t guarantee this yet – we already rely on this statement ID format in WikibaseQualityConstraints (here). @Smalyshev (WMF), Duesentrieb: do you know if there’s any reason to keep this unspecified? --Lucas Werkmeister (WMDE) (talk) 12:23, 15 January 2019 (UTC)
Being relied upon in code is actually pretty reassuring - thanks! But it would nice to have the documentation on this clear too... ArthurPSmith (talk) 14:18, 15 January 2019 (UTC)
Specifying exact formats for such things is dangerous. It means we have to keep them forever, since tools start relying on them. For example, we had to change '$' to '-' because it's harder to represent '$' in RDF URIs in WDQS context. Since we didn't promise statement URIs would match anything, it was an easy fix. However, if we now make such promise, if in the future we'd need to make another change - for compatibility, or efficiency, or any other reason - we may have trouble doing it.
That said, if the user realizes the dangers of relying on the internal IDs and we don't promise to keep it stable forever, and it's useful for something (with full realization this something might break in the future), you can use it. The code generating the statement URI looks like this: preg_replace( '/[^\w-]/', '-', $statement->getGuid() ); - so every non-word non-dash character becomes '-' - and so far we have very little reason to change it further. So with some caveats, it can be used as such. Smalyshev (WMF) (talk) 07:34, 16 January 2019 (UTC)
@Smalyshev (WMF): well, that’s what we have the stable interface policy for, isn’t it? It doesn’t mean we’re never allowed to touch the schema ever again, but it does mean that we should give appropriate prior notice to users when we make breaking changes. I think that’s a better way to handle things than to leave it unspecified and then blame the users when they do rely on the unspecified detail (because if you need to address a specific statement in SPARQL whose Wikibase statement ID you know, I don’t think there’s any better way to do it than to turn the statement ID into an IRI). --Lucas Werkmeister (WMDE) (talk) 17:23, 21 January 2019 (UTC)
Yes, if we declare it stable, it would be covered by the policy. I'm just not sure it makes sense to declare it so, since it's an implementation detail... But if you think it's necessary, I think the code above is simple and clear enough so we can document it. Smalyshev (WMF) (talk) 20:38, 21 January 2019 (UTC)
Okay, I’ve filed T214680. --Lucas Werkmeister (WMDE) (talk) 11:19, 25 January 2019 (UTC)

Clearer level of rank for statement

Sometimes, it is hard to read whether statement is preferred/normal/deprecated. It would be more user friendly to make clearer level of rank for a statement (preferred = make values bold, normal, normal and deprecated italic and smaller font for instance) I wonder if this can be implemented ? Bouzinac (talk) 22:17, 24 January 2019 (UTC)

@Bouzinac: I think the closest task to that is T206392, though I’m not sure – there are a few other related tasks as well. --Lucas Werkmeister (WMDE) (talk) 10:42, 25 January 2019 (UTC)
Perfect :) Bouzinac (talk) 12:39, 25 January 2019 (UTC)
@Bouzinac: this solution from Nikki works well for me. Add the following to your common.css page (you can also adapt it to modify the font instead):
/* from [[User:Nikki/common.css]] */

.wb-preferred { background-color: lavender }
.wb-deprecated { background-color: mistyrose }
Pintoch (talk) 15:09, 25 January 2019 (UTC)
Didn't know one could have a personalised CSS! Cool, thanks

BBLD claims Wikidata contains false info

An IP today added this link to the English Wikipedia article on Wikidata: [23] (it is in German, and one needs to scroll down). Does anybody know what the story is? Should we do something about it?--Ymblanter (talk) 15:23, 19 January 2019 (UTC)

@Ymblanter: The IP is most likely the subject of the second community global ban; is he the author of at least that section of that BBLD page? Mahir256 (talk) 15:44, 19 January 2019 (UTC)
I do not think the BBLD page is freely editable.--Ymblanter (talk) 16:06, 19 January 2019 (UTC)
There were two complaints about Baltisches Biographisches Lexikon Digital ID (former scheme) (P2580), both of which have now apparently been corrected by an IP address. Firstly the property had the general format as a regular expression (P1793) "[A-Za-z0-9][-.0-9A-Za-z]+", which does not come from the BBLD, whereas they have published the presumably more accurate regular expression "^[0-9A-Z][-.0-9A-Za-z]{1,62}[0-9Xa-z.]$". This has been updated now, but they have added the start time (P580) qualifier which apparently is not valid - I don't know how important that is. Secondly the label contained the string "(former scheme)" in English with an equivalent addition in German and French. 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. Strobilomyces (talk) 17:04, 19 January 2019 (UTC)
Management of that BBLD database is pretty crappy. Within roughly the past half year, they have moved to another domain, continuously change identifiers, and mix different identifier concepts (apparently ISNI style, ISBN style, and native BBLD style). All of that is bad style in the context of linked data, but we are not in control of it.
If something like this happens, we still retain the old identifier values and the old formatter URL (which is to be deprecated to deactivate links in the Web UI); mind that this is an identifier in the first place, not a mere weblink to that resource. To handle the new identifiers + new domain, there needs to be another, new property which I proposed at Wikidata:Property proposal/Baltisches Biographisches Lexikon Digital ID (new scheme); to disambiguate, the old one is marked with "(old scheme)" postfixes, and it needs to be reset basically to the mid-2018 setting. Whoever wants to retrieve links for that resource will have to use the new property once it is created and filled with values. —MisterSynergy (talk) 19:38, 19 January 2019 (UTC)
The site is missing an impressum (Q1075810). Thus it is not reliable at all. ---Succu (talk) 20:05, 19 January 2019 (UTC)
@Succu:, can you add an <instance of> or <subclass of> statement to impressum (Q1075810), since you understand what it is? - PKM (talk) 20:57, 19 January 2019 (UTC)
No. At least in Germany there is a impressum obligation (Q1660394). If this is a website of Baltic Historical Commission (Q12360160) they are obliged to follow this rule. --Succu (talk) 21:05, 19 January 2019 (UTC)
From any page such as you can find (home, 1st click), there you can (guess to) click BHK arriving on (2nd click), and that page has a link to (3rd click, arguably one too much for German rules, but why would anybody here care?) – 02:19, 26 January 2019 (UTC)

I don't understand the point of this

The other day on English WP I created an article on a rather obscure 19th century French operetta L'œil crevé [24]. Just now I got a notification "The page L'œil crevé was connected to the wikidata item Q60770728, which contains data relevant to the topic". So I look at that item "L'œil crevé (Q60770728)' [25] and it does not have any "data" whatsoever except it says the language is English, which is wrong, and that there is an article in English WP about it. This puzzles me, what is the point? I don't get it. Please do not suggest that I fill in any of the missing fields, I have no interest in editing anything in this project. I am simply baffled as to how this is meant to be of any possible use to anyone or anything, please explain.Smeat75 (talk) 20:48, 21 January 2019 (UTC)

@Smeat75: You don't have to do anything. Wikidata is an all-languages structured data wiki. If other people find it interesting they will add information, including translations and descriptions in other languages, and linking to other items - for example I added a link to the composer and a couple of other details. ArthurPSmith (talk) 21:21, 21 January 2019 (UTC)
@Smeat75: And I've added links to records at the Bibliothèque nationale de France and the US Library of Congress, which will allow individuals to locate copies of the score and libretto in either library. --EncycloPetey (talk) 21:45, 21 January 2019 (UTC)
Oh, OK, that's better I guess. Thanks.Smeat75 (talk) 22:04, 21 January 2019 (UTC)
Filed phab:T214355 to improve wording of the message. Matěj Suchánek (talk) 08:17, 22 January 2019 (UTC)
I too am confused. I just wrote an article, Sánchez Navarro latifundio [26] for Wikipedia and was notified that it was put on wikidata. Should I be pleased about this? Is it a compliment to the luminance of my labors? Or are wikipedia articles routinely put on wikidata? Is there something I could or should be doing for wikidata? Just curious. Smallchief. 10:44, 22 January 2019 (UTC)
Almost every Wikipedia article is associated with a Wikidata item. This enables, among other things, the links between articles in different languages about the same topic. The data can also be used by Wikidata articles through the Scribunto/parser functions, for example in external link templates and infoboxes.
For new articles specifically, Special:UnconnectedPages on each wiki lists articles which are not yet connected to Wikidata. Users might use that list – or use software like PetScan to e.g. go through the categories on each wiki – to manually or semi-automatically select pages for which to create associated Wikidata items. Jc86035 (talk) 12:04, 22 January 2019 (UTC)
This is a question for enWP - if it is "obscure" why is there an article about it? WP doesn't like obscure, they like notable. Lazypub (talk) 12:18, 22 January 2019 (UTC)
Well it is notable in the history of French opéra bouffe, certainly, although that whole topic could be considered "rather obscure" in comparison to many others.Smeat75 (talk) 14:23, 22 January 2019 (UTC)
Obscure and notable are not mutually exclusive. You could show some notability with three independent WP:42 references for an obscure topic, and if folks think that it's still too "obscure" they can PROD or AFD it as they see fit. You'd get an invitation to the deletion discussion on your talk page, and all projects interested in the "obscure" topic (as noted on the talk page for the article, maybe by you) get an alert if there's a PROD or AFD. These procedures don't work too bad (on enwiki), I really like PROD = PROposed Deletion, invented about 13 years ago, all it takes to stop a PROD is a decisive NO.) – 02:40, 26 January 2019 (UTC)

Notability of categories

I've been reading Wikidata:Notability and I'm not able to understand what to do with categories in a project with no interwikis to other projects. It seems I have to create the items if the category is, for example, from catalan wikipedia but I do not have to create the item if the category is from Commons. Am I right? Thanks in advance. Paucabot (talk) 06:42, 19 January 2019 (UTC)

Pretty much. There seems to be consensus that any category on any Wikipedia necessarily represents something notable by Wikidata standards. There is not the same consensus for categories on Commons. - Jmabel (talk) 21:00, 19 January 2019 (UTC)
Thanks, @Jmabel:! Paucabot (talk) 06:54, 20 January 2019 (UTC)
Creating an associated Wikidata items for categories also provides a place to add structure even when there are currently no interlanguage links. For instance, Category:2015 films (Q6293942) is a Wikimedia set category (Q59542487) and defines strict semantics for membership(SPARQL) via Wikidata SPARQL query equivalent (P3921). This provides a great way to discover missing articles and also wards against bad interlanguage links based solely on translation. One such case of this error happening is with en:Category:Biography_(genre) which had been linked to ru:Категория:Персоналии_по_алфавиту (a category containing all articles using en:Category:People and person infobox templates) presumably because it translates to "biographies". ElanHR (talk) 04:01, 22 January 2019 (UTC)
Related discussion: #Creating new items for humans based on Commons categories. Matěj Suchánek (talk) 08:00, 22 January 2019 (UTC)
@Matěj Suchánek, ElanHR, Jmabel: And what about wikipedia administration or maintenance categories from one wikipedia that do not have interwikis (like, for example Category: Wikipedia Edit-a-thons in 2019 (Q60590662)? Should we create an item for them here? Paucabot (talk) 18:09, 22 January 2019 (UTC)
Replying only because pinged: on that last, I don't care. - Jmabel (talk) 18:13, 22 January 2019 (UTC)
While I think there is benefit, I agree that it is probably less in this case. "Wiki edit-a-thons in 2019" is a cross-language concept (e.g. Category:Wikipedia edit-a-thons (Q9468246)) but manually organizing this part of the category tree probably isn't as impactful as cleaning up those of articles in the Main namespace. I believe an exception to these are tracking categories such as Category:Articles needing more detailed references (Q8267520) since sharing this signal across languages editors can potentially help editors, bots, and data analysis.
My general opinion is more structured/cross-language data is always better but editors' time is valuable and how to spend it and be most impactful way is a tricky question. Curious to what you think. :) ElanHR (talk) 23:37, 26 January 2019 (UTC)

RDF formatter update delay

Recently I updated the formatter URI for RDF resource (P1921) for some MusicBrainz identifiers from "$1/type" to "$1". I did this after discovering that MusicBrainz uses in their embedded JSON-LD the latter format and I could not find any sources or discussion that explain where the former is coming from. This query lists the current MusicBrainz RDF formatters:

select distinct * where {
  ?prop wdt:P31 / wdt:P279* wd:Q18616576 .
  ?prop rdfs:label ?propLabel .
  optional {?prop wdt:P1921 ?rdfFormat .}
  filter (lang(?propLabel) = "en" && strstarts(?propLabel, "MusicBrainz"))
} order by ?propLabel
Try it!

However, when retrieving those values using the prefix wdtn: then they still use the old format, even though I updated say MusicBrainz work ID (P435) more than two weeks ago:

select * where {
  ?work wdtn:P435 ?mbwork .
} limit 5
Try it!

How long does it take to propagate this update? I remember seeing some updated values, but currently I can't find any. Toni 001 (talk) 13:31, 24 January 2019 (UTC)

@Toni 001: I’m afraid we don’t propagate such updates at all at the moment (see T121274 (comments) and compare also T112081). The formatter URLs will only show up once the affected items are edited. (And I’m pretty sure it has to be a real edit, even a null edit isn’t enough.) --Lucas Werkmeister (WMDE) (talk) 15:24, 24 January 2019 (UTC)
Thanks for the info. Toni 001 (talk) 22:22, 26 January 2019 (UTC)

Wikidata:Notability and Wikimedia Commons

Currently there is a text which states "In addition, sitelinks on category items to category pages on Wikimedia Commons are allowed if and only if they are linked with category pages on other Wikimedia sites.[8]" which could be kind of problematic for the whole structured data on Wikimedia Commons project which aims to better integrate Wikimedia Commons with Wikidata, currently a lot of notable subjects which are simply not covered by any other Wikimedia website are on Wikimedia Commons as a category, I don't propose completely removing that statement (although I would be in favour of doing so), but at "User talk:Pigsonthewing#Ziengs Schoenen" one could see a conversation concerning a notable subject which has no entries yet on any other Wikimedia websites being covered which is notable enough for Wikidata, I propose changing the text to reflect the practices as opposed to what is currently stated as it could discourage the creation of notable items. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 14:38, 24 January 2019 (UTC)

Pinging @Pigsonthewing: and this is related to "Depictes"_(local_Vs._Wikidata-based_solutions) this conversation (Mobile 📱) where a Wikidata-based solution would be more than welcome, but the wording should reflect this. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 14:41, 24 January 2019 (UTC)

I have proposed a change to that sentence here. A category page on commons shouldn't be enough to create an item on Wikidata, however criterion #2 should be enough for most cases where the item is notable by itself and additionaly it might have a category page on Commons.--Micru (talk) 16:56, 24 January 2019 (UTC)
We had a related discussion at Wikidata:Project chat/Archive/2019/01#Creating new items for humans based on Commons categories recently.
Key issue from many Wikidatan's point of view would be proper identification of subjects against external sources (i.e. serious external identifiers or in references). Otherwise it would be difficult to find editors who can work with the items or improve them, or to verify any of the data in an item. It also helps to constrain Wikidata's project scope to something manageable in terms of community workforce and server capabilities. Let's put it like that: the exception for Commons categories in the notability policy has basically two reasons; firstly, there is concern about Commons' weak notability policy (lots of dubious, promotional content seems to be fine there), and secondly, Commons categories do not require any sources for the actual data they contain e.g. via categorization. In contrast, Wikipedia articles are typically supported by proper sources.
I understand that providing external identification would be a time-consuming task when the Commons project basically starts with unsourced content to import to Wikidata. Yet, if that is done properly, the items to be created would already be notable according to the current Wikidata notability policy, but just not due to the Commons category sitelink as User:Micru said in the previous comment. —MisterSynergy (talk) 19:18, 24 January 2019 (UTC)
@MisterSynergy: I didn't see any kind of resolution or closure on the previous discussion. While some voices agreed that the concerns you express should be paramount, there were as many that believed the need to have somewhere to structurally describe the category should be paramount, and that such descriptions are something which a start can be made on, and valuable information recorded, based just on the images (and perhaps citations to "imported from WikiCommons"), even without any further external sources.
Currently, policy as written allows an substantive article-type item here if a corresponding Commons category exists. It is specifically category-type items that policy places further restrictions on (to prevent -- mistakenly in my view -- items from being created for Commons "intersection" categories; which are precisely a set of categories that it would be particularly useful to have a structured description on hand for in terms of identified Wikidata items).
User:Micru has proposed to change (or as he calls it "clarify") the current wording to make it more restrictive. So far that proposal doesn't seem to have gained a lot of traction. Jheald (talk) 19:42, 24 January 2019 (UTC)
There was no closure of the previous discussion as we are all just about to form coherent opinions about whether or not we need a policy update, and how it could look like.
The essence of our current notability policy is basically that “all content needs external sources within reach”, without enforcing references on each and every claim; I fear that an approach which allows imports based only on unsourced Commons categories may be a carte blanche to create items about basically anything here. In other words, the other requirements from the notability policy could simply be circumvented by putting some content (and a category) to Commons, and create a Wikidata item subsequently as well. This can of course be abused for defamatory content, doxing, hoaxes, inacceptable privacy violations, purely promotional content, and so on as nobody would check the information anyways.
In my administrative role I deal a lot with borderline notability cases here at Wikidata. We do already have a large amount of problematic content which barely anyone cares about. From my experience, unidentified items tend to be abandoned by the community, which in particular means that nobody will show up and look for sources. I’ve seen way too many unsourced items with the problems mentioned above, in particular hoaxes and promotional content, and lots of them are meanwhile several years old.
Furthermore there are lots of Wikipedians who continue to claim “Wikidata is all unsourced” and reject data use in their projects. I don’t buy it of course, but it would be even more difficult to argue with them if we open the gates here for unsourced content. Proper sourcing is key. —MisterSynergy (talk) 23:38, 24 January 2019 (UTC)
@MisterSynergy: I am not convinced. We already accept that anyone who has authored any academic paper can have an item here, or anybody that is needed to be the object of a statement here. I don't see that allowing people with Commons category does more than add a few more drops into what is already an ocean.
As for Wikipedias, people that want to dislike Wikidata content will find their reasons to dislike it. For practical purposes, most Wikipedia templates allow sources to be required for particular fields. Besides, if someone doesn't have a Wikipedia article, then whatever happens here is not going to be a problem on their Wikipedia article.
We already have policy against "defamatory content, doxing, hoaxes, unacceptable privacy violations". I don't really see that subjects of Commons categories would be more prone to that than anybody else; so I don't think that that is a valid reason to block them. In some ways, because Commons categories actually use Wikidata infoboxes, Wikidata content may be more visible for people with categories there, so more likely to be picked up.
The bottom line is that these items would relate to real-world people and things -- we have pictures of them -- and Commons needs these items, in order to be able to describe categories and files through Wikibase statements. Part of Wikidata's mission is to support the data-keeping requirements of Wikimedia projects. Commons is such a project, and this is data that is needed to be accessible. This is part of what Wikidata is for. Jheald (talk) 00:20, 25 January 2019 (UTC)
@Jheald: If the Commons community was really serious about notability, they would make sure that their categories are notable. As it is now, anybody can create any category for any reason, which doesn't inspire much trust. You brought up already in the past that part of the mission of Wikidata is to support other Wikimedia projects, but the community is free to choose how or up to which extent. Nobody can force the community to carry a burden that it is not wanted.--Micru (talk) 23:14, 25 January 2019 (UTC)
With all respect, the Commons community is serious about notability, but has a different standard than either Wikidata or the various Wikipedias. Wikidata falls somewhere between a typical Wikipedia and Commons. Clearly, an academic article that meets Wikidata's standard of notability does not necessarily merit a Wikipedia article. Similarly, Commons might have several hundred photos of a parade, and might make a category for a parade float the recurs from year to year; that doesn't mean the parade float merits a Wikidata item. Also, keep in mind: Commons' scope allows us to host any media that has a potential educational purpose. That means, for example, we have very good reason to host a lot of 19th-century or early 20th-century ephemera, such as party invitations, (even sloppy) hand-lettered signs for events, etc.; again, that doesn't bring those things up to a Wikidata level of notability, but it doesn't mean we are unserious. - Jmabel (talk) 01:05, 26 January 2019 (UTC)
@Jmabel: On the other hand, we are going to need an item here for the parade float, if we are to be able to describe it in structured terms.
I think Wikidata needs to be a little less precious about this. With 54 million items already, it can afford a few parade floats.
Commons is serious about trying to facilitate pictures being well described and discoverable. That is what should be fundamental. Jheald (talk) 17:02, 26 January 2019 (UTC)
This has been discussed at dozens of revenues and as Wikimedia Commons is about to introduce a whole lot of Wikidata-centric tools to structure its data it's perhaps time to open an RfC about this. I'm quite busy as of late but will draft one soon, I'll announce it on Wikimedia Commons and here when it's launched, this probably needs more perspectives including some from both volunteer (hobbyist) developers and Wikimedia Foundation staff. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 18:50, 26 January 2019 (UTC)
Notability is not a question whether we accept an item about some parade or not. If there is serious external coverage about such a parade, we do of course happily welcome an item about it. What is important about notability is that we, as Wikimedians, do not judge on an individual level what is notable and what is not; we leave it to external third parties to decide about notability, and we just pick up what gained notability out there in the real world. This is a key principle of most Wikimedia projects—Wikipedias and Wikidata at least—and ensures our independence and impartialness regarding the subjects we create content about; it is one of our most precious assets in fact.
By making sources available, we ensure that there is serious external coverage and thus notability. It furthermore allows us to verify (typically large portions of) the data we present in our projects, and to spot defamatory content, doxing, hoaxes, unacceptable privacy violations; we also have an effective measure to deal with self-promotion of which we see a lot already now. All of that really requires that serious sources are easily accessible from items.
That said, I would like to express that I really welcome the SDC project including the fact that it is supposed to make heavy use of Wikidata, and I am looking forward to seeing how it evolves. I write here because I think that the notability concept and the sourcing requirements in its current form are not negotiable, and I would like to emphasize that extra efforts need to be spent for the all-unsourced contents of Wikimedia Commons during an import. This does of course slow things considerably, but it would appear unfair if Wikidata key principles would need to be eased a lot just to enable the Commons project to efficiently dump any of their content here with bots. —MisterSynergy (talk) 22:07, 26 January 2019 (UTC)
@MisterSynergy: It is important to recognise that what you are describing is only one of the routes sufficient for an item to be acceptable under WD:N. According to WD:N an item is acceptable if there is external sourcing OR it has a page on another wiki OR it fulfills a structural need.
Items such as for the parade float will fulfill a structural need in that there needs to be an item here if it is to be the object of a depicts (P180) statement; PLUS it corresponds to a page on another wiki, namely the category on Commons, corresponding with one of the purposes of Wikidata namely to allow entities featured on other wikis to be represented in structured data form. If there is external sourcing too that is nice, and completes the trio, but it is not a requirement WD:N makes.
The progression that has been universal with Wikidata items is that first items get created; then statements get added, enough to locate the item in a structured data context; then (sometimes) more statements get added, and (sometimes) references get added. It's quite reasonable to apply the same model to Commons; and if we want Commons systematically described by structured data we have no choice. Jheald (talk) 22:32, 26 January 2019 (UTC)
I think the most important part of Wikidata:Notability is part 2, "clearly identifiable conceptual or material entity." That's the section that potentially allows creating items for every author in the world, or every concept listed in an academic databases, while apparently not permitting the importation of telephone books, old censuses, and personal family trees. Probably, that part 2 should be promoted to part 1, and additional items needed by other projects can be treated additionally. I think the number of non-notable items needed by other projects will be small in comparison. I'm not convinced that it's worth creating an item for every intersection category on Commons, or any other project, unless its doing a useful function like linking the same category on two projects. I think it's the paranoia about such intersections that led to the Notability change I suggested getting nowhere, even though as I worded it, it didn't permit such items. Ghouston (talk) 22:46, 26 January 2019 (UTC)
Intersection categories are not a major concern here, as far as I can tell. There is more concern about the possibility that way too many people upload images about themselves (plus an individual category, optionally), and that automatically grants an individual Wikidata item as well. There are lots of people who wait for that, in order to boost their Google ranking via Wikidata and the like (the SEO community is eager to exploit Wikidata for their needs, but their content is not well maintained and does not add any value our project). On the other hand, there are plenty “non-notable” persons such as Wikimedias who’d rather not have a Wikidata item about themselves due to privacy concerns, but for some reason they are depicted at Commons somewhere. Reliance on external coverage for item notability would avoid all these complications. —MisterSynergy (talk) 23:23, 26 January 2019 (UTC)
Then wouldn't it be best to delete item 1 from the Notability requirements? Then the non-notable items are rejected no matter which project they originate from. A list of exceptions can be added where items can be created for non-notable concepts, such as for linking categories and templates that are found on multiple projects. Ghouston (talk) 00:00, 27 January 2019 (UTC)
I should add that every user on Commons who has ever uploaded a self-made photo is a topic of interest on Commons, since authorship needs to be recorded. The simplest implementation of structured data would have been to create an item for them on Wikidata, but that would be probably in the hundreds of thousands (probably including many duplicates where people have made multiple accounts for their uploads). Technically, the Notability policy doesn't actually prohibit that, but it's likely that Wikidata as we currently know it can't meet all the needs of other projects. Ghouston (talk) 22:54, 26 January 2019 (UTC)
commons:Commons:Structured data/About/FAQ#How will usernames be stored in Structured Data?; it looks like they do not plan to create an item for each and every uploader. Good decision. —MisterSynergy (talk) 23:11, 26 January 2019 (UTC)
The “structural need” criterion is a weak one as this term is not clearly defined. It happens relatively often that backlinks and use in Wikimedia projects are evaluated during a deletion process, and the item is deleted regardless of the use (which is typically removed then). We do this particularly in case of circular dependencies between otherwise non-notable items, and if we have privacy concerns e.g. in family relationships. It depends a lot on the context whether there is “structural need” due to use or not.
Your assumption about the item development process is not convincing. With little exceptions, we have two types of items: those with a connected (Wikipedia) article which we readily assume to be properly sourced (this does not hold for Commons categories, which is why we have this commonscat exception in WD:N), and those without sitelinks; the latter are almost always created with proper identifiers (=sources) and/or references for critical claims in place, or as really unambiguously structurally needed items. There is in fact only a surprisingly little amount of items where you cannot find sources easily. I am actively monitoring this for quite some time now. —MisterSynergy (talk) 23:03, 26 January 2019 (UTC)

Specificity in descriptions

Is "French association football player" preferable to "French footballer"? Jc86035 (talk) 17:58, 25 January 2019 (UTC)

No, per Help:Description it's worse, unless of course we have a Paul Pogba who plays American football. Mattythewhite shouldn't mass change these descriptions and undo the ip that corrected him. Multichill (talk) 20:43, 25 January 2019 (UTC)
Yes, "footballer" is ambiguous because the sport of football has multiple codes. And it's ironic you use Help:Description to *support* your argument when it actually contradict you. Look at the example of Daniel Alves' description, which uses "association football player". Mattythewhite (talk) 21:22, 25 January 2019 (UTC)
My two cents: not worth fighting over. With "French", "footballer" is perfectly clear, even though "association football player" is more precise. If he were a Canadian, it would be a lot less clear. - Jmabel (talk) 01:11, 26 January 2019 (UTC)
I think keeping it standard as - association football player from <known nationality> or association football manager from <known nationality> or association football player and manager from <known nationality> would be ok. The Help:Description doesnt help much since it also states Messi as footballer from Argentina :) Unnited meta (talk) 08:53, 26 January 2019 (UTC)
Yet another example where automated descriptions are better.. They would function for any language. Thanks, GerardM (talk) 14:32, 26 January 2019 (UTC)

anyone up on Filipino judges, educated at, awards received?

Someone has put a lot of effort into Leonardo Quisumbing" (Q3484580) but the item might be in need of a second pair of eyes. Moebeus (talk) 17:55, 26 January 2019 (UTC)

It is indeed in need of some major restructuring. I have done some work on one position he held.. Secretary of Labor and Employment. It needs more work but it shows nicely that Filipino information needs a lot of TLC. Thanks, GerardM (talk) 20:11, 26 January 2019 (UTC)

Protection of thousand of items

Please join the discussion at Wikidata:Administrators' noticeboard#Protection of thousand of items. --Succu (talk) 21:49, 26 January 2019 (UTC)

Please remember that the administrators' noticeboard is for administrators to resolve requests. General discussion is fine here, on the project chat. Thanks! --abián 21:56, 26 January 2019 (UTC)
@Abián: I certainly disagree with that assertion, if there was a bad block we wouldn't force all non-admins to comment on the project chat. --Rschen7754 22:15, 26 January 2019 (UTC)

Restriction on label and description needs to be removed

Currently when a label is changed because it is wrong .. eg E. Franceschi is to become Enrico Franceschi, it is not permitted because there already is an Enrico Franceschi. They are clearly different persons, they have distinct ORCID identifiers. Restricting such edits are nice on a micro level. On a macro level it is plain stupid. It means that batch processes do not function.

Add to this that descriptions are problematic at best. The quality is such that they are best ditched in favour of automated descriptions. This works bette for any language. This restriction is adding insult to injury. Thanks, GerardM (talk) 09:21, 24 January 2019 (UTC)

What's the problem with adding a distinctive description? "Researcher with ORCID xxxxx" will always work, if you are updating items based on ORCID id's. ArthurPSmith (talk) 09:28, 24 January 2019 (UTC)
Your assumption is that everything is done by hand and not in a batch function. Second, "with ORCID xxxxx" is not a good description, it does not describe the person involved in a proper way. Such a "solution" is proof perfect that we do not need descriptions because we do not really care. Thanks, GerardM (talk) 09:48, 24 January 2019 (UTC)
The description is a distinguisher, it is what is shown in search results within the main Wikidata UI. Without a description, when people select an item via the autocomplete interface they have no way to tell which "Enrico Franceschi" is the one they want. A better description would be great, but at least put something in. ArthurPSmith (talk) 13:58, 24 January 2019 (UTC)
Well, that is not that great an argument. It only works for one language and not for any other. With automated descriptions, like I use in my daily practice, adding statements helps disambiguate perfectly fine. The use of an "Orcid identifier" as suggested does not help at all choosing the right item by that name. So your argument is not functional at all. Thanks, GerardM (talk) 18:00, 24 January 2019 (UTC)
If the batch import fails, what stops you from manually writing a description that allows people to know which Enrico Franceschi they mean? It's actual work to google, but it's work that produces useful descriptions. ChristianKl❫ 18:36, 26 January 2019 (UTC)
It does not stop the job, I do not know things are substandard except when I do things manually. NB you still have not made the case why this is a good idea. Thanks, GerardM (talk) 20:29, 26 January 2019 (UTC)
This tool does stop me adding manual changes. It has everything to do with the time it takes for the database to know that a discription has changed. This restriction is a show stopper. It is also very much not in line with the wiki philosophy where you add what you want to add at a time. Descriptions from a quality point of view suck already so we should stop insisting on its use. Thanks, GerardM (talk) 14:02, 27 January 2019 (UTC)

Include country in address when using P6375

From the given examples of located at street address (P6375) it's not clear to me whether one should include the country or not when entering an address.
The example Threadneedle Street, London, EC2R 8AH doesn't include the country while Angertorstraße 3, 80469 München, Germany does. And if a country should be specified, is it supposed to be in English or the native language of the country which the address is in?

If there is consensus on these questions I'd like to propose to edit the examples accordingly. --Naseweis520 (talk) 18:21, 24 January 2019 (UTC)

  • I'm sure Pasleim meant to add "Deutschland" for "Germany" in German. --- Jura 06:50, 27 January 2019 (UTC)

Duplicate items (scholarly articles)


By chance I came across an apparent duplication of a Nature article. Q59066989 and Q57753530. The items are largely the same apart from identifiers; the former has a DOI and the latter PMID. They were both created by Quickstatements invoked by Source MD and only about a month apart. I suppose the two items need to be merged ?

Is it an isolated incident ? If not, how it can be prevented .

Kpjas (talk) 19:49, 21 January 2019 (UTC)

Thanks, I merged them. I doubt that it's the only such duplicate. They could be prevented by better checking for existing items when creating new ones: the duplicate was created in this instance by User:Sic19. Ghouston (talk) 20:50, 21 January 2019 (UTC)
Sorry, my mistake. Thanks for merging Simon Cobb (User:Sic19 ; talk page) 23:08, 21 January 2019 (UTC)
I have found duplicate items for scholarly articles that have two DOIs in two different repositories, but they represent the same article in the same issue of the same journal (Textile History). I merged one, and I expect there are more to look for. - PKM (talk) 21:36, 27 January 2019 (UTC)

Property "text on commons"

Is there no property to link a file with a text to the item of the text? Or did I just not found it? image (P18) could be used to do this but I think it should not. --GPSLeo (talk) 21:58, 22 January 2019 (UTC)

scanned file on Wikimedia Commons (P996) ? Jheald (talk) 22:03, 22 January 2019 (UTC)
Good for old scanned texts but for a native PDF like a law or ordinance text? --GPSLeo (talk) 07:33, 23 January 2019 (UTC)
I think you could use it for that. full work available at (P953) is also possible. Jheald (talk) 10:32, 23 January 2019 (UTC)
Yes but it is a URL datatype and not a Commons media file datatype. --GPSLeo (talk) 11:08, 23 January 2019 (UTC)
I just proposed it: Wikidata:Property proposal/full work on commons --GPSLeo (talk) 20:02, 27 January 2019 (UTC)

Heinz-Erich Wichmann / Heinz Erich Wichmann

Can anyone figure out if Heinz Erich Wichmann (Q1517116) and Q30500514 are the same person? If so, how are the entities to be merged and one of them deleted? Thanks.-- 20:52, 27 January 2019 (UTC)

I believe they are the same. The only information about Q30500514 is the set of articles linked to it. I found a Google Scholar account for Heinz Erich Wichmann (Q1517116) and under the list of publications it includes articles linked to both items. The field of work is very similar in any case. To merge them, there's a gadget "Merge with" that appears under the "More" menu at the top of the page. Ghouston (talk) 22:47, 27 January 2019 (UTC)
As an anonymous user you may not be able to merge, but I'll do it later (in case somebody wants to dispute my methodology). Ghouston (talk) 22:49, 27 January 2019 (UTC)
(edit conflict) You can merge the two items if they are referring to the same person. Q30500514 did not have any link to external database, nor wikipedia article, but linked internally in wikidata. You can check those academic paper entry that under Q30500514, is really published by Heinz Erich Wichmann (Q1517116) or not, or is there any possibility a namesake. Matthew hk (talk) 22:50, 27 January 2019 (UTC)
Yeah, a good indication is also to look up one of more articles and see if the affiliations match. Genome-wide association analysis of genetic generalized epilepsies implicates susceptibility loci at 1q43, 2p16.1, 2q22.3 and 17q21.32. (Q29417109) has an affiliation, that includes University of Munich (LMU) which is also listed on Heinz Erich Wichmann (Q1517116). Ghouston (talk) 22:55, 27 January 2019 (UTC)

Should podology (Q52862) and podiatry (Q18011356) be merged?

I've made a lot of research and haven't found big differences in meaning and definition between these terms. Many English dictionaries treat them as synonymous. The French article on Podologie is quite similar to the English one on Podiatry. Pinging مصعب, who has attempted a merger last year but was reverted. —capmo (talk) 16:12, 20 January 2019 (UTC)

hi. @Capmo:. during my studu as medical student i found that both terms are used interchangeably so that i tried to merge them. what's your opinion bro @علاء:. regards--مصعب (talk) 17:17, 20 January 2019 (UTC)
Given that we have German articles for both we can't simple merge them.
When it comes to the description it seems that podiatry (Q18011356) includes the lower extremity while podology (Q52862) is about feet. ChristianKl❫ 17:40, 20 January 2019 (UTC)
I also seems that in Germany to be a practioner of podology (Q52862) you don't need to have a medical degree as a doctor while podiatry (Q18011356) is a speciality of people who do have medical degrees. ChristianKl❫ 17:54, 20 January 2019 (UTC)
As I know that it's different from country to another, for example on Malta the podiatrist = podologist, but in other countries like Australia you study podology first, then specialise in podiatry. It's probably like psychology (Q9418) and psychiatry (Q7867). Also I found Cameron Kippen comment/2005, here and here --Alaa :)..! 21:47, 20 January 2019 (UTC)
There is also a distinction between the knowledge of the discipline and the practice of someone who treats people using that knowledge. author  TomT0m / talk page 14:21, 27 January 2019 (UTC)
Thank you all for your comments! Considering the subtle differences and the fact that the German wiki has articles for both concepts, I agree that the items can't be merged. But because of how different cultures use one or the other term more or less interchangeably, it might be good to read each article and check if they are connected to the right concept at wikidata. Regards, —capmo (talk) 16:02, 28 January 2019 (UTC)

Wikidata weekly summary #349

Order statements by date, if they are dated

Hello, I think it would be more user friendly that lengthy statements can be ordered by date (or another user-defined sort) ? Or parameter that specific properties shall be default-ordered by year (patronage (P3872)), another property default-ordered by alphabetic etc. It would help data more easy to read, sort out and verify. I don't know whether Wikidata team has already discussed of this, or if it hard to encode. Thank you! Bouzinac (talk) 22:23, 24 January 2019 (UTC)

@Bouzinac: Yes, I think that’s T173432. In a comment there, Seb35 also mentions they have a user script for doing this (User:Seb35/sortValues.js), though I’ve never tried it out, so I can’t tell you how well it works. --Lucas Werkmeister (WMDE) (talk) 10:41, 25 January 2019 (UTC)
Sorting claims by qualifier values in WE-Framework gadgets
(self-promotion) WEF gadgets can do that: sort by dates and string (not links) qualifiers. -- VlSergey (трёп) 11:39, 25 January 2019 (UTC)
Hello, thank you. I was able to open the WEF gadget, see
The WE-Framework gadgets from my point of view
. How can I use it to order and see specifically patronage (P3872) ? Bouzinac (talk) 16:42, 26 January 2019 (UTC)
@Bouzinac: well, sadly such property doesn't present in existing editors. What kind of entries are you working with? Is there any kind of page where "typical" properties for this entries are listed? New editor can be quickly created for new type of entity. -- VlSergey (трёп) 09:42, 28 January 2019 (UTC)
Hello Vlsergey (talkcontribslogs), thank you for your help. I suppose the patronage (P3872) and daily patronage (P1373) would mainly be used in transport-related entities like airports, subways, buses etc. Bouzinac (talk) 10:15, 28 January 2019 (UTC)
@Bouzinac: please check new "Transport Infrastructure" editor. It has patronage (P3872) and daily patronage (P1373) properties on distinct tab. -- VlSergey (трёп) 11:59, 28 January 2019 (UTC)
Hello Vlsergey (talkcontribslogs), nice job! I'm surprised by 2 "bugs" :
  • "patronage" is shown with english name "patronage" and not "clientèle" while all other tabs are labelled with correct french text. Where is it supposed to be translated ?
  • No seeing of IATA airport code (P238) and ICAO airport code (P239) (which are very important and specific to airports), is it normal?

Spassibo again ! Bouzinac (talk) 12:36, 28 January 2019 (UTC)

Hello there, still no seeing ICAO and IATA codes ?
; спасибо вам ещё раз! Bouzinac (talk) 08:58, 29 January 2019 (UTC)

New Wikidata metaclass

Since there is footballers who play in this club (Q56465024), it seem good to have coach/ or manager (English football terminology version) counterpart for category combines topics (P971). Should i create one? Matthew hk (talk) 02:49, 27 January 2019 (UTC)

No, much more effective is "category contains" with "human as qualifier and "position held" for the coach. It allows for automated imports. Thanks, GerardM (talk) 09:34, 27 January 2019 (UTC)
Thanks for pointing out, as i can't find the right example from entry such as Category:A.C. Milan managers (Q8216975) and Category:Manchester United F.C. managers (Q8604872). Matthew hk (talk) 13:46, 27 January 2019 (UTC)
In addition to setting occupation (P106)/position held (P39) what is the best way to link them to the team they are managing? member of sports team (P54)? I see Louis van Gaal (Q207431) (a manager of manchester united) simply has them as employer (P108). ElanHR (talk) 08:04, 28 January 2019 (UTC)
Just to understand what is a wikidata metaclass? Also a statement with head coach of sports team (P6087) is the best way to link an association football manager (Q628099) with the club. You can refer to this - Wikidata:WikiProject_Association_football/Discussion_about_properties/Players - Unnited meta (talk) 14:35, 28 January 2019 (UTC)
I would be amused if P value can be used in category combines topics (P971). Matthew hk (talk) 02:38, 29 January 2019 (UTC)

Statement not supported by reference present

Sometimes people add references to statements that don't actually support the statement they are trying to reference. What's the best approach to fix this?

Personally, I either ask contributors to add a relevant quote from the referenced source that could support the statement or remove the reference. Supposedly one could also deprecate the statement until a quote is added. What do you think ? --- Jura 06:49, 27 January 2019 (UTC)

I don't think we have an existing good procedure. Asking the person who made the statement seemed to be the best way. If that doesn't help depricating with an appropriate reason for deprecation (P2241) statement might be a good way to go about it. ChristianKl❫ 14:35, 27 January 2019 (UTC)
Help:Ranking seems to me to say that marking a statement as deprecated should only be done if there is consensus that the statement is not correct, which isn't quite the same thing as not being stated in a given reference. So if a supplied reference does not support any part of the claim, then I would say it should be removed. But marking the statement itself as deprecated seems much stronger, and should require more than an invalid reference:
"Ranks are not a way of asserting your view for a disputed value, but instead are used for communicating the consensus opinion for a statement. All disputes should be discussed on the item's discussion page. Edit warring over values is not acceptable. There is however another way to state that a statement is disputed and by whom: the qualifier statement disputed by (P1310)  ."
--Oravrattas (talk) 18:04, 27 January 2019 (UTC)
  • I don't think that part of help covers the aspect that the reference doesn't support the statement, e.g. someone adds VIAF as reference for a date of birth while VIAF doesn't actually mention a date of birth anywhere. Or it mentions that date, but it's actually its odd way of providing dates when a subject was known to be alive. --- Jura 18:20, 27 January 2019 (UTC)
    • It says that a statement should only be marked as deprecated if there is consensus that it is incorrect. An invalid or incorrect reference doesn't relate to that — at most it means we have the equivalent of an un-referenced statement, which itself wouldn't be sufficient to mark something as deprecated. --Oravrattas (talk) 18:28, 27 January 2019 (UTC)
      • If even attempts at referencing didn't provide a valid reference, the statement could obviously be deleted. As this is hardly productive, deprecating has the advantage that we know why it doesn't have a valid rank. The addition of a quote, should make it easy to double-check for anyone. --- Jura 18:34, 27 January 2019 (UTC)
        • That would be turning Ranks into effectively a "citation needed" mechanism, which isn't what they currently mean. If there was widespread agreement to change their meaning in this way, it might be a valid approach, but the Help page is fairly clear that that's not how they're meant to be used at present. --Oravrattas (talk) 19:02, 27 January 2019 (UTC)
          • So you'd favor deletion? --- Jura 19:10, 27 January 2019 (UTC)
            • @Jura1: Deletion of what? I can see deleting the bad reference, but I can't see deleting the statement because it is insufficiently referenced. We have tons of unreferenced statements, and we leave them in place most of the time. image (P18), for example, almost never has a reference. - Jmabel (talk) 23:39, 27 January 2019 (UTC)
              • I'm not aware of images generally needing references. What about the sample I mentioned: when someone attempted to reference it and failed, it shouldn't be left as a valid statement. --- Jura 02:34, 28 January 2019 (UTC)
                • Still, I see tons of unreferenced birth dates, citizenships, etc. Seems to me like unless you have pretty good reason to believe the statement is actually wrong, yes it makes sense to remove the bad reference, but I'd keep the statement as an unreferenced statement, which speaks for itself about not overly presuming any authority for it. Or do you think we should always remove unreferenced statements about such things? Because it seems crazy to say that if we have an unreferenced statement we leave it alone, but is someone adds a crappy reference, then we delete the statement entirely. - Jmabel (talk) 09:27, 28 January 2019 (UTC)
                  • There are three things: (1) the statement is likely wrong, (2) the reference doesn't cover the statement, (3) someone (generally the person who added the statement) attempted to research the question, but couldn't come up with a reference. Personally, I find deprecating such statements is generally the most productive approach. There is always a risk that someone already picked up our data and then tries to track its source. Merely leaving the statement as valid one seems counterproductive. We have a qualifier that indicate reasons for deprecation. --- Jura 17:12, 28 January 2019 (UTC)
(Assuming good faith) Unfortunately, websites are easier to change than than the printed page. Today, what contains an actual reference to a statement, can be edited to not include the reference to a statement tomorrow. You see it often with sports articles something like "José Altuve expected to retire" is written today. If you go back two days from now, the same article will read "José Altuve quits cable". Printed papers can't change their articles like that. Websites do it entirely too often.
So, you can either remove the link. Or you can depreciate the link. But the statement doesn't need removed. Lazypub (talk)
@Jura1: If the reference doesn't support the statement, remove the reference and ping the contributor who added it in the talk's page of the item with a comment explaining the reason of your action. Snipre (talk) 07:02, 29 January 2019 (UTC)
How would one address the point that no reference for the statement can be found? --- Jura 07:04, 29 January 2019 (UTC)

Antonio Machado (Q243771) - vandalism

Spanish poet Antonio Machado likely being taught in school or something, the item is attracting quite a bit of (childish) vandalism. Would it be possible to set some protection on the item for a period? Moebeus (talk) 15:51, 29 January 2019 (UTC)

  Done Andreasm háblame / just talk to me 16:12, 29 January 2019 (UTC)

Statistical information via external tools in the item history page

Hi. Months ago I wanted to show to a friend the visit to a wikidata item and it took me a while to get something like that. It was not complicated, but it was strange to see that standard tools I often use on other wikiplatforms are missing from the items history pages here.

Links to "External tools" such as articleinfo and pageviews are very common on many platforms, compiled with the string input and available from the history page just a click away. Did we ever discuss if we want them here too? thank you in advance.--Alexmar983 (talk) 04:20, 27 January 2019 (UTC)

@Alexmar983: if you choose “Page Information” in the left toolbar, scroll down to the last item “Pagevews Analysis”, does that give you what you want? - PKM (talk) 00:55, 30 January 2019 (UTC)
So there it is. But I don't see the histroy statistics there, the summary page with pie charts of editors and added kb.--Alexmar983 (talk) 00:59, 30 January 2019 (UTC)

Best GPS coordinate

There was a thread a few months ago about what to do about GPS coordinates where Google Maps and Geonames and our other fave sources differ. The larger differences were with states and cities where sometimes it is the geographic center of the state and sometimes the capital. Sometimes for a building or a park, the GPS coordinates are for the center of the building or park, and sometimes the entrance to the property from the street. Was there a resolution? --RAN (talk) 16:06, 29 January 2019 (UTC)

I think that's a discussion to be had on the talk page of coordinate location (P625) (with maybe a link from here). ChristianKl❫ 18:20, 29 January 2019 (UTC)
Don't recall the old threat, but for extended objects adding the qualifier applies to part (P518) helps a lot - e.g. can indicate that a coordinate of a city points the city hall (Q543654), or for a river to its river mouth (Q1233637), and also makes it easier to add more than one coordinate where useful. Ahoerstemeier (talk) 21:42, 29 January 2019 (UTC)
Street entrance coordinates is a terrible idea. In many cases it is unclear from aerial photos where an entrance might be, and of course there are multiple entrances to just about everywhere. Centering on the target is easy to do using OSM tools, or even manually. Abductive (talk) 01:39, 30 January 2019 (UTC)

Subclass for media professional (Q15980804)


Would it be a good idea to have subclass like person (Q215627) or individual (Q795052) for media professional (Q15980804).

Looks like media professional (Q15980804) is a "dead end".

Thank you. Benoit Rochon (talk) 15:09, 20 January 2019 (UTC)

No. In Wikidata, "media professional" is a profession, not a tyoe of human. There are 14 subclasses of media professional, all related professions. - PKM (talk) 21:31, 20 January 2019 (UTC)
Echoing what PKM said - it looks like this is meant to be used with occupation (P106) rather than instance of (P31). e.g. and . More examples: [27]
@PKM: "media professional" is a profession, not a tyoe of human seems meaningless to me. « media professional » has to be someone. There is a distinction between the practice of carpentry or a carpenter, for example, but usually the carpenter is a person. Practicing carpentry is something else, for example a carpenter may not practice carpentry on its dayoff, but saying « media professional » is a profession is nonsense. A better label could be « media-related practice » for example. author  TomT0m / talk page 14:26, 27 January 2019 (UTC)
Tom Tom, I totally lost you. Why does what you say not make sense. It is such arguments that disgust me when I see subclasses. They are not self explanatory and they are utterly confusing. Thanks, GerardM (talk) 14:35, 27 January 2019 (UTC)
@GerardM: It’s the inconsistency between the label and what the item is supposed to represent. A profession is an activity, a professional is someone that practices this activity. Saying « a professional is a profession » is inconsistent, and that’s what is said by « "media professional" is a profession ». This is a nonsense and I understand why you should be puzzled by such assertion. author  TomT0m / talk page 09:40, 30 January 2019 (UTC)
@TomT0m: What is your point. We have a profession eg researcher, it is expressed on a person by statement Profession:researcher.. We do not need the difference between one and the other. What you dabble in is semantics that are effectively not in use. Thanks, GerardM (talk) 09:46, 30 January 2019 (UTC)
@GerardM: Still, there is an ambiguity. See the definition of the term « boulanger » (baker) in french : « A baker is someone who makes and sell bread » (as a noun) and as a verb (to bake, it’s the same word in french) it’s the activity of making bread. « A baker is someone » implies effectively all bakers are human. author  TomT0m / talk page 10:05, 30 January 2019 (UTC)
@TomT0m: No. This is not OmegaWiki. A description is not a DefinedMeaning. In Wikidata we do not have nouns nor verbs when we consider items. So no, not at all. Almost everything that is in a description could be defined by its statements. Thanks, GerardM (talk) 10:27, 30 January 2019 (UTC)
Almost everything that is in a description could be defined by its statements. We’re far from this and there is still a lot of room for interpretations by human label. How do you define the concept of a profession (Q28640)     by statements, for example ? author  TomT0m / talk page 11:07, 30 January 2019 (UTC)
This is a non-issue. We currently have a gazillion number of people who are "researcher".. I would have it as a "profession". This is not about lexemes. If you want to, you refer to a lexeme. This is NOT omegawiki, a unique description is not a requirement. Thanks, GerardM (talk) 15:32, 30 January 2019 (UTC)

How to model Wikimedians in Residence on Wikidata?

Hi all

There's a big long (and most probably incomplete) list of Wikimedians in Residence on Outreach Wiki here. What do you think is the best way of modelling this on Wikidata?


--John Cummings (talk) 18:18, 23 January 2019 (UTC)

Pigsonthewing has already mapped this out on his own item Andy Mabbett (Q15136093) quite extensively. So that'd be a good guide. Wittylama (talk) 19:03, 23 January 2019 (UTC)
Thanks @Wittylama: :) --John Cummings (talk) 20:00, 23 January 2019 (UTC)

On previous occasions items have been removed because of "privacy concerns". Thanks, GerardM (talk) 09:23, 24 January 2019 (UTC)

One admin deleted the item about himself, despite his COI, and others at the same time. He refused to reinstate them so they could be debated by the community. That should not be taken as , nor allowed to be, a precedent. Indeed, the items should be restored. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:38, 25 January 2019 (UTC)
Yes please. GerardM (talk) 19:21, 26 January 2019 (UTC)
Do you have an item-id of which item we are talking about? ChristianKl❫ 14:31, 30 January 2019 (UTC)

Buildings protected on the municipality level (in Finland)

I am starting to chart a new category of protected buildings, those that are protected on a municipality level. I am missing properties or hitting constraints with the described item. Here is what I would like to display roughly:

The item is already created with these incorrect properties here Wuorion talo (Q60998101)

Let me know which property you would use for the jurisdiction, the plan symbol, and if you would (probably should) create an item for the plan in which the protection took place, and which property to use with it. Which project do you think I should document this in when it gets resolved? Thanks for your help! – Susanna Ånäs (Susannaanas) (talk) 10:47, 28 January 2019 (UTC)

@Susannaanas: For the municipality, I use approved by (P790) for the municipally leveled heritage in Canada. --Fralambert (talk) 13:43, 28 January 2019 (UTC)
@Fralambert: I think that sounds like an excellent way, thank you! I will correct that in my example and continue to look for the remaining properties. Cheers, Susanna Ånäs (Susannaanas) (talk) 13:46, 28 January 2019 (UTC)
I relalise that I forget adding a exemple: St. Mary's Church (Q7590192), Q53680106 and a last one Finnish Labour Temple (Q5450788) :p. --Fralambert (talk) 17:49, 28 January 2019 (UTC)
Great examples!! – Susanna Ånäs (Susannaanas) (talk) 07:05, 30 January 2019 (UTC)

P996 for non scanned files

On the talk page of scanned file on Wikimedia Commons (P996) is a discussion about a renaming of is property to make is usable for every text on commons and not only for scanned text like it is now. This started after a proposal for a new separate property for this "full work on commons". --GPSLeo (talk) 11:13, 30 January 2019 (UTC)

Visualising gene structure 'is part of' relationships as diagram

Hello all,

I'm trying to encode the relationships and references in the two diagrams in w:Gene_structure within Wikidata. I've a few questions:

  1. Am I using the mostly using Property:P361, Property:P31, and Property:P279. Do those seem reasonable?
  2. what're the best ways to visualise the hierarchy (maybe as a tree diagram)?
  3. Is there a good way to indicate which properties only apply to eukaryotes or prokaryotes? (example using 'of' qualifier)

Evolution and evolvability (talk) 10:31, 29 January 2019 (UTC)

Can you be more specific about where you want to use the diagram to give a better understanding of the needs for it? ChristianKl❫ 18:17, 29 January 2019 (UTC)
@ChristianKl: I'm hoping to show how the key relationships within the diagram can be made machine readable via Wikidata. Something where I could draw a network showing the elements as vertices with properties as edges of different colours, constrained into a directional hierarchy, with vertices coloured based on their Property:P31? E.g. core promoter is part of a promoter, which is a type of regulatory element and part of a gene. Evolution and evolvability (talk) 04:34, 30 January 2019 (UTC)
@Evolution and evolvability: I’m currently trying some experiments on visualizing taxonomic ranks datas on Wikidata, for example this diagram is an idea of what I’d like to achieve (on principle, not real datas) and some page in which I try to go towards this User:TomT0m/TestRanks on this test page (using a Sparql query to extract the datas. As the discussion on project taxonomy on implementing the model I’d like on ranks data to reach my goal is currently stuck, I’d be happy to reorient my goals to collaborate with you. :) author  TomT0m / talk page 08:56, 30 January 2019 (UTC)
@TomT0m: Very nice! I've had a bit of a play around to come up with that and a couple of other google search suggestions:
So none are quite successful, but seem to be getting closer! Evolution and evolvability (talk) 11:14, 30 January 2019 (UTC)
I've also added a not over at Request_a_query no that I've discovered that page, since it seems a sensible location. Evolution and evolvability (talk) 03:53, 31 January 2019 (UTC)

Please merge article with translated

Salzderhelden saltworks (Q60790654) is a translated or english version of the german version: Saline Salzderhelden (Q2214431) . Please merge or make otherwise visible the corresponding language version in both wikipedias. --Rosegluy (talk) 19:56, 30 January 2019 (UTC)

  Done--Ymblanter (talk) 20:19, 30 January 2019 (UTC)

Soviet Sports Title

We have Master of Sport of the USSR (Q1803234), Master of Sport of USSR in Chess (Q16674680), Master of Sport of USSR in Chess Composition (Q4284316) and maybe others. How should those be used? If the latter two are separate titles, I think they should be used as individual statements with award received (P166), but if they are only thematic divisions of only one title, I think that only the first item thould be used. But I don't know much about those soviet titles, and therefore I am hesitating to add anything. Steak (talk) 08:55, 31 January 2019 (UTC)

  • They are three different titles. -- VlSergey (трёп) 09:09, 31 January 2019 (UTC)
Ok, thanks. Steak (talk) 13:37, 31 January 2019 (UTC)

Facto Post Issue 20, licensing data

The latest issue is at w:User:Charles Matthews/Facto Post/Issue 20 – 31 January 2019. The editorial mentions the version problem with much Creative Commons licensing in major repositories, but without giving details.

This business came up in the ScienceSource planning to scale up the focus list described at WD:SSFL. Licences without version number, so more precisely subclasses of licenses, are commonly used in sites such as unpaywall. They are present in the open access collection of PubMed Central, and presumably unpaywall gets them from there. PubMed Central pages on papers very often link to the actual Creative Commons license page; but not always. As far as we can tell, the best source to use is the OpenXML on Europe PMC. Charles Matthews (talk) 12:01, 31 January 2019 (UTC)

Anastasiya Knyazeva

I have noticed that Anastasiya Knyazeva was deleted. Why? :-) -- 22:47, 30 January 2019 (UTC)

Without you giving the item ID it's hard to give you an answer. Likely, the item didn't fit our notability policy. ChristianKl❫ 10:10, 31 January 2019 (UTC)
Did you mean this - Q55104095? --Ksc~ruwiki (talk) 18:49, 31 January 2019 (UTC)
Or perhaps Anastasiya Pavlovna Knyazeva (Q44979759), deleted 2019-01-20T14:54:35 by @MisterSynergy: (Does not meet the notability policy: content was: "Anastasiya Knyazeva", and the only contributor was ""). Bovlb (talk) 19:59, 31 January 2019 (UTC)
I have undeleted and merged. Bovlb (talk) 20:08, 31 January 2019 (UTC)