Open main menu

Wikidata:Project chat

(Redirected from Wikidata:PC)

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


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

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.[[3]]. 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 [4] @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 [5]. 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)

CiteTool (autofill for references)Edit

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)

Femicide as a manner of deathEdit

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)

Creating new items for humans based on Commons categoriesEdit

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 [6]. 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 [7] after users had been confused, with a revision by User:Jura1 about thirty minutes later [8] 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)

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

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 [9], 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)

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

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)

Musings: Difference between PetScan & Wikidata QueryEdit

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)


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,[10] 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)

Confirmed or autoconfirmedEdit

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)

Mass creation of new items, no properties, no deduplicationEdit

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)

Lexemes and ConceptsEdit

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 - translationsEdit

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)

Filtering query results by article size?Edit

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)

Request for Checkuser rightsEdit

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)

Review of edits by user:Zhxy 519Edit

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)

Importing Julian datesEdit

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)

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

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 thadguidryEdit

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 PropertiesEdit

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)

Lists of awardsEdit

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)

Converting P361 uses to P1433Edit

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)


Vishvakarman (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)

Is there a way I could contact Wikimedia Deutschland?Edit

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 HassaniEdit

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)

suffragist (Q27532437) and suffragette (Q322170)Edit

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)" [11] 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)

Hippolyte Peragallo (Q21390773) and Hypollyte Peragallo (Q21522800)Edit

Aren't those the same?

FileExporter beta featureEdit

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)

Which Wikidata tours are missing?Edit

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)

Wikidata weekly summary #347Edit

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

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)

Sandbox link broken?Edit

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)

Statement GUID's and WDQS?Edit

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)

Delete P973sEdit

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)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

Academic PhD treeEdit

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)

Uploading population data to Dutch municipaltiesEdit

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)

Coffee houseEdit

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)


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)

Birth rate Death rateEdit

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)

Searching for file namesEdit

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)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

Wikipedia Page for the organizationEdit

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)


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 [13] and [14], or matches on pictures in Q60644992's [15]. 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 [16] 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)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

Can't mark WS item proofreadEdit

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)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:27, 18 January 2019 (UTC)

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

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)

Dishwashing needs, er, cleaning upEdit

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)

add statement button at the startEdit

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 projectEdit

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)

class of award (Q38033430)Edit

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)


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)

Wikidata:Project chat -> Add topicEdit

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)

How active: WikiData CommunityEdit

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!