Shortcuts: WD:PC, WD:CHAT

Wikidata:Project chat: Difference between revisions

From Wikidata
Jump to navigation Jump to search
Content deleted Content added
Hazard-Bot (talk | contribs)
m Bot: Archiving 3 threads (older than 7 days) to Wikidata:Project chat/Archive/2017/04.
Line 641: Line 641:
:::::::: {{ping|billinghurst}} But technically I (as a crat) can not assign account creation rights. The panel just says "rights you can not assign". I assume it is either not available or only available to stewards. This can be changes by holding an RfC and, if it is successful, filing a Phabricator request, but I do not see how it can be changed otherwise.--[[User:Ymblanter|Ymblanter]] ([[User talk:Ymblanter|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 09:59, 12 April 2017 (UTC)
:::::::: {{ping|billinghurst}} But technically I (as a crat) can not assign account creation rights. The panel just says "rights you can not assign". I assume it is either not available or only available to stewards. This can be changes by holding an RfC and, if it is successful, filing a Phabricator request, but I do not see how it can be changed otherwise.--[[User:Ymblanter|Ymblanter]] ([[User talk:Ymblanter|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 09:59, 12 April 2017 (UTC)
:::::::::Ah, gotcha. Completely right, they would require a consensus for a phabricator; again not certain whether an RfC is required or just the evidence of the conversation. &nbsp;— [[user:billinghurst|billinghurst]] ''<span style="font-size:90%;">[[user talk:billinghurst|sDrewth]]</span>'' 12:10, 12 April 2017 (UTC)
:::::::::Ah, gotcha. Completely right, they would require a consensus for a phabricator; again not certain whether an RfC is required or just the evidence of the conversation. &nbsp;— [[user:billinghurst|billinghurst]] ''<span style="font-size:90%;">[[user talk:billinghurst|sDrewth]]</span>'' 12:10, 12 April 2017 (UTC)
::::::::::If "a phabricator" means "a task in [[mw:Phabricator|Phabricator]]", general [[meta:Requesting_wiki_configuration_changes|documentation for consensus requirements for configuration changes is available]]. --[[User:AKlapper (WMF)|AKlapper (WMF)]] ([[User talk:AKlapper (WMF)|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:50, 12 April 2017 (UTC)


== Coordinates ==
== Coordinates ==

Revision as of 19:51, 12 April 2017

QuickStatements - setting ranks?

Is possible to set ranks with QuickStatements? If not, is there another tool to do that for a number of claims at once? (Why would this be helpful? If somebody updates any property to its actual value, one would like to set this value also as the preferred one.) 123 (talk) 00:08, 29 March 2017 (UTC)[reply]

You can make use of qualifiers (series ordinal (P1545)). Quickstatements does support qualifiers. Jsamwrites (talk) 08:46, 29 March 2017 (UTC)[reply]
@123: As far as I know, the answer is: no, it doesn't; and I'm not aware of any tool that does. (Having recently deprecated a couple of hundred statements for withdrawn identifiers by hand, because I couldn't think of an easy mechanised way to do it.) Jheald (talk) 15:03, 30 March 2017 (UTC)[reply]
Thanks for clarifying. But this greatly reduces the utility of the tool. Would be great, if this feature could be added ... 123 (talk) 22:43, 3 April 2017 (UTC)[reply]
@Jsamwrites: Even for Jhealds clarification I tried a bit around with qualifiers like series ordinal (P1545), but really didn't get anywhere. Do you have a working example for setting ranks? 123 (talk) 21:18, 6 April 2017 (UTC)[reply]

BLP policy?

There is currently an RfC on the English Wikipedia to remove the mobile view page description which is pulled from Wikidata. One of the biggest problems noted is Wikidata's lack of wikipedia:WP:BLP policy, which allows potentially libellous and defamatory material to be written about living people. Wikidata should have a BLP policy, both to assuage concerns of editors and to avoid lawsuits. Cheers, Laurdecl talk 09:21, 30 March 2017 (UTC)[reply]

There are two things here. Problems with descriptions and having a BLP policy.
It is easiest to consider Wikidata descriptions. They are not that good. They are typically added by bots based on information that is often later updated making the information more complete and accurate. There are automated descriptions, they are based on existing statements and they have been generated in English for years now. They are my preferred way to do disambiguation using Reasonator.
Nominally there is a BLP policy as the WMF has a policy that is applicable to all projects. However, having a policy and insisting on a practice are two things. Much of the work at Wikidata is done in an automated or in a half automated way and issues with for instance descriptions or labels are often found thanks to the functionality that registers it but the problem is that there is a flood of changes at Wikidata much higher than at en.wp. So if you see anything, fix it. Wikidata is your project too. Thanks, GerardM (talk) 10:39, 30 March 2017 (UTC)[reply]
"Wikidata should have a BLP policy, both to assuage concerns of editors and to avoid lawsuits." it may need a policy, but "what concerns" and what lawsuits?" it is unclear that fear of action by others is a roadmap. rather wikidata might consider a quality circle to improve data quality about living people. Slowking4 (talk) 23:22, 30 March 2017 (UTC)[reply]

We are bound by the Wikimedia Foundation resolution regarding Wikimedia's handling of material in biographies of living people (BLPs). This predates Wikidata, as it was passed on 9 April 2009 (there have been amendments since, but they don't affect what follows). It noted that there are problems with some BLPs being overly promotional in tone, being vandalized, and containing errors and smears. The Foundation urges that special attention be paid to neutrality and verifiability regarding living persons; that human dignity and personal privacy be taken into account, especially in articles of ephemeral or marginal interest; and that anyone who has a complaint about how they are described on the project's websites be treated with patience, kindness, and respect.

It also "urges the global Wikimedia community to uphold and strengthen our commitment to high-quality, accurate information, by [among other things] Ensuring that projects in all languages that describe living people have policies in place calling for special attention to the principles of neutrality and verifiability in those articles". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:40, 30 March 2017 (UTC)[reply]

While that resolution is a lovely thing, and provides some ... direction, it has not been "translated" to and made actionable in the Wikidata community. There is nothing like en-WP's BLP here and nothing like discretionary sanctions here. What does that resolution mean in Wikidata? The commons had to translate BLP notions into what they meant for images of identifiable people, right? So what does "BLP" mean here in this realm of data and phrases? Does content about living people that someone contests stay up while being contested, or come down immediately? How would such disputes even be resolved -- on what grounds? Many questions like that are not worked out here yet. I reckon they will be, eventually, as this community encounters problems, comes to consensus ways to solve them, and those consensuses (sp?) solidify into policy. But no WMF community can just write a policy de novo and enforce it all the sudden. That is not how WMF communities work, as far as I know. Jytdog (talk) 05:50, 31 March 2017 (UTC)[reply]
Jytdog, the Commons guideline that you refer to pre-dates the WMF resolution, so it cannot have been created as a way to apply that resolution to Commons. WhatamIdoing (talk) 17:58, 5 April 2017 (UTC)[reply]
User:WhatamIdoing Good point but irrelevant. The Commons has a policy (and yes, an actual policy) that translates the notion of being very careful about living people (which long predated the board resolution) to images. Something this project is not even close to. The point is that this project has no governance concerning data about living people. Jytdog (talk) 18:06, 5 April 2017 (UTC)[reply]
That depends upon what you mean by "policy". If by policy you mean "written page that says 'policy' at the top", then they don't, because c:COM:BLP says "official guideline" at the top. But if policy you mean ""course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions", then Commons has such a policy – and Wikidata might, too. In the hypothetical example below about the person being wrongly tagged as a criminal, it appears that everyone has agreed that the wrong data must be removed. "Remove bad data when we learn about it" appears to be the policy here. WhatamIdoing (talk) 20:55, 5 April 2017 (UTC)[reply]
We should make WD:BLP a policy. Laurdecl talk 07:33, 31 March 2017 (UTC)[reply]
Hell no, this is still a Wikipedia centred proposal. What if there is no article for a person in any Wikipedia but only secondary information.. Mr Blp won the Whatever award in 2002.. ? We have many such items. The problem is that these items are inherently needed to complete the information in Wikidata. What Wikipedia has is often just a name in text, a red link. These things are not even considered in the Wikipedia BLP. Thanks, GerardM (talk) 09:01, 31 March 2017 (UTC)[reply]
Thanks for providing that link! I had looked and not found it. So.. proposed since 2013. That is the germ of what one day might be a BLP policy here. Jytdog (talk) 15:45, 31 March 2017 (UTC)[reply]
Hell yes. It's a Wikimedia-centred proposal. If there is no article for a particular living person on any Wikipedia, then you'd better make damn sure that any claims you make about them on Wikidata have reliable sourcing and that reliable sourcing is present in the item's entry. You'd also better be certain that you're not riding roughshod over a marginally notable individual's expectation to privacy. This project needs a BLP policy. --RexxS (talk) 16:56, 31 March 2017 (UTC)[reply]
Right, and what you do is parrot Wikipedia thinking. I care about "Sources" and less about "sources". When an award winner has as much as an item and the fact of the winning of the award, I am completely satisfied when the person is known through a red link or a text on a Wikipedia page. For me, the fact that we have a back log of humans who died is something that I want you to focus on. It is the kind of problem that we have largely solved but there is a lack of volunteers doing this. When you say BLP, my challenge to you is will we make sure that we get such basic facts right. The basics in Wikidata are typically hardly controversial. so what do you mean, we need a policy.. First we need to get to grips with the issues that a BLP covers and make sure that we at the very least have basic facts as good as they get. Once we have done let us talk about sources. Let us talk about it once we do the basic things. Thanks, GerardM (talk) 19:14, 31 March 2017 (UTC)[reply]
Sources are basic things, and without them you don't know whether the facts are right. Nikkimaria (talk) 02:32, 1 April 2017 (UTC)[reply]
From a Wikipedia point of view, sure. But when we have to spend our time on improving quality at Wikidata, there is a different priority. When "Sources" agree, I do not need "sources" to tell me what to concentrate on. A BLP has its place but as long as we do not have accurate practices to maintain who lives and who is dead we have our priorities wrong. When Wikid oidata agrees on this with Wikipedias, we may not have "source" information at Wikidata but through the "sources" on our "Sources" we are good. Of primary importance is that we focus our effort so that BLT issues do not arise at this stage of our development it is not sources. So let us focus on what facts in a BLP are relevant and get procedures for those. We are doing really good with the date of death (thanks Pasleim) but when we know, should we not ensure that ALL Wikipedias register death accurately, is that not a much more effective way of having a proper BLP? Thanks, GerardM (talk) 05:35, 1 April 2017 (UTC)[reply]
@Jasper Deng, RexxS, Jytdog, Laurdecl: Maybe it's time for another RFC here along the lines of this one: Wikidata:Requests for comment/Verifiability and living persons (but maybe with some better prep work as that basically crashed and burned in the community). I agree something like this is really really needed here. Something wikidata-specific. Labels and descriptions and aliases don't allow sourcing, so should they be purely automatic from sourced statements for living people? Are there properties that should always have a verifiable source for a living person? How do we enforce? etc. ArthurPSmith (talk) 18:57, 31 March 2017 (UTC)[reply]
I appreciate the invitation but I am really an en-WP person; i don't understand the culture of this place and i would be of no help. and i have no wish to force the ways of en-WP on this place. We need to respect our differences and support each other in ways that are appropriate. :) Jytdog (talk) 20:09, 31 March 2017 (UTC)[reply]
I know this might sound vindicative, but I will be brutally and completely honest: the problem of us not having a living persons policy can be blamed on the failure of that RfC and by extension the community members who caused it to fail (including this instance of blatant off-wiki canvassing by User:Magnus Manske). Those community members should absolutely be ashamed of themselves (yes, this is a harsh statement, but completely true). The fact is, while it is true that we want to include as much information as possible, and as freely as possible, what good is a knowledgebase that has no standard for the veracity of its information?
With that said, to ensure a future RfC better takes into account everyone's concerns, we need to talk more about them here. My intent with the original RfC was that no one has business complaining about the RfC if they did not partake in the discussion that originally spurred it. This statement should not be taken literally. Rather, the discussion here is the chance to craft a proposal most likely to get the support of our community.
@GerardM: Verifiability problems on other wikis, or verifiability problems in general, are red herrings with respect to the subject of BLP's. Just because we have to work on sourcing basic information in general does not mean we can ignore the importance of living people in particular. The foundation resolution binds us to this. The fact is, living people need to have the information on them correct, period. We are not allowed to ignore that for any reason.--Jasper Deng (talk) 10:26, 1 April 2017 (UTC)[reply]
@GerardM: As a further rebuttal of your comments, I do not understand why you believe "The basics in Wikidata are typically hardly controversial". That is simply nonsense. Even something innocuous as the description of an item is susceptible to BLP violations. There is no attribute of a living person that does not fall under the umbrella of BLP -- not even if it would seem uncontroversial at first glance.
I don't think you understand the purpose of "BLP". BLP is not the problem of deciding who is living and who is not. BLP means making sure information on living people is accurate, because the information we host on them is public and therefore can have real-life consequences. Remember, our information is used by Google in its search results pages. You agree that we want our information to be correct, right? If this is not policy, then there is no reason for that to be honored here.--Jasper Deng (talk) 10:38, 1 April 2017 (UTC)[reply]
The proposal in that RfC was to have much stricter policy than en.Wiki has. I think there are good reasons for why such a policy would be bad for Wikidata. en.Wiki uses the wording "any material challenged or likely to be challenged must be supported by an inline citation to a reliable, published source."
Any policy document has to have clear standards that indicate to whom it applies. En.Wiki has "Anyone born within the past 115 years is covered by this policy unless a reliable source has confirmed their death". A good way to write a policy would be to stay roughly with the standards layed out in the English BLF. There's no reason to be stricter. ChristianKl (talk) 12:58, 1 April 2017 (UTC)[reply]
@ChristianKl: A potentially valid objection, though I fail to see how "living people" is not a well-defined set. But again, the question is, why was it not raised during the initial discussion before the RfC began? Only one user raised an issue about the RfC on its talk page before it went live, and I took care to talk to him about the proposal. That is why I am frustrated. My entire point is that we are not going to make another proposal that fails due to objections that were not raised during the crafting of the proposal.--Jasper Deng (talk) 18:27, 1 April 2017 (UTC)[reply]
@Jasper Deng: The EnWiki BLP policy takes 150 words to explain what they mean with living person. Why do they do that? Otherwise it's not clear whether a person where the last reliable source that says something about the person was published 20 years ago is supposed to count as alive or dead for the sake of the policy. ChristianKl (talk) 13:17, 2 April 2017 (UTC)[reply]
You claim to be "completely honest" and "completely true", and manage neither. The objections were to a badly flawed proposal, and included suggestions as to how it could be improved - suggestions about which you apparently did nothing. In any case, the tone of your statement is utterly unacceptable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:24, 1 April 2017 (UTC)[reply]
@Pigsonthewing: Let me be a little more explicit. Any flaws in the proposal were a result of a lack of commentary whenever I opened a discussion on this page on the subject. Furthermore, at least in the initial stage of that RfC, anyone who didn't like the proposal was free to propose alternatives. It's not my responsibility to propose others' changes. Nothing excuses the canvassing in any case.--Jasper Deng (talk) 18:27, 1 April 2017 (UTC)[reply]
If I remember right it was my impression was that the RfC was started prematurely. ChristianKl (talk) 18:51, 1 April 2017 (UTC)[reply]
Bullshit. You were the proponent - if there was a lack of commentary, then you acted prematurely in putting forward something for a vote. If you were not prepared to take on board constructive criticisms (which did include proposed alternatives), doubly so. Don't try to blame others for your own shortcomings. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:08, 1 April 2017 (UTC)[reply]
@Pigsonthewing: "Bullshit" - says the one who tries to call me on my tone here. No criticism that begins with "bullshit" is constructive criticism.--Jasper Deng (talk) 20:38, 3 April 2017 (UTC)[reply]
You'll notice that "bullshit" was the word I used to describe - accurately - your claims; unlike you, I did not denigrate individuals. But still, you avoid addressing the point I made; just as you failed to address the points I and others made during your RfC, and on its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 4 April 2017 (UTC)[reply]
I am not vindictive but brutally honest when I notice that you do not understand the issues. First, quality and BLP are related. It is not only in "sources", it is also in "Sources". When BLP is infringed on in any of our projects it is a Wikimedia problem. Restricting it to one project is irresponsible. When you state that the descriptions are innocuous, I fail to agree. I prefer automated descriptions because they will improve with improved statements. Many descriptions are horribly incomplete.
Wikipedias are involved in "sources". Some Wikipedias only accept "sources" in their own language. Accepting policies are already problematic, accepting that what Wikipedia does has a similar effect on Wikidata is not possible. When "Sources" like the Wikipedias accept that a fact is true, for instance a date of death, an employment or whatever it follows that we can inherit / assume their source and not give such an aspect of a person attention. Not when there is so much where Wikidata / our projects are not in agreement on the facts.
When we focus on where there is disagreement, we focus our attention where problems are most likely, where quality / BLP issues exist. Our information needs to be correct but we gain quality by focusing our attention. Thinking in absolutes is silly.
When you ass-ume that there is only one way and that is by sourcing everything, you set us up to fail. By concentrating where quality issues are likely by comparing "Sources", we set ourselves up to succeed. Thanks, GerardM (talk) 13:58, 1 April 2017 (UTC)[reply]
@GerardM: Again, I don't think you understand what I mean. I don't care how it is achieved, but the information about living people must be verifiable, i.e. correct, and it must be a policy that we hold ourselves to that general principle. "Verifiable" is up to us to define. And you may prefer automated descriptions and data entry if you want, but this is a knowledgebase anyone can edit, so we have to be concerned about users changing it, such as in the example I cited.
Verifiability is a different question from the general question of living people. As someone who has done revision deletions of some serious BLP violations here and read and understood the foundation's resolution quite well, I think I understand the issue quite well.--Jasper Deng (talk) 18:27, 1 April 2017 (UTC)[reply]
"I don't care how it is achieved" That would explain the deficiencies in the RfC. Some of us who do care offered you advice there, which you ignored. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:12, 1 April 2017 (UTC)[reply]
If you do not care how it is achieved, should I care about your opinion? At issue is that a policy that is impossible to implement has little merit but good intentions. Effectively it is telling others what to do. When descriptions are factually misleading and a target for vandalism, when they do not scale well particularly not for other languages, what is the net value of descriptions anyway? The fact that anyone can edit does not mean that we have to have hand made descriptions and as you know they are mostly created by bots.
I do understand what you mean however I am of a totally different opinion, it is the basis for a plan that is actionable and will have a positive impact. Thanks, GerardM (talk) 19:20, 1 April 2017 (UTC)[reply]
I apologize if my pinging Jasper is starting a fight, that was far from my intention (and GerardM I suggest you read a little more carefully before arguing back). Moving on, the recent major discussion on this issue failed to come up with any statement of policy. The important thing here is how do we craft a policy that IS acceptable to the wikidata community while actually addressing BLP concerns? @ChristianKl: has a reasonably specific suggestion above based on enwiki's language. How do we translate it to wikidata? Are there certain types of statements that might routinely be "challenged or likely to be challenged", or could any statement fall in that category? Is "imported from" one of the wikipedias sufficient source information to meet BLP standards for such statements? Should vandalism on pages of living people be treated more aggressively? How do we treat items about people for which we don't have a birth or death date? ArthurPSmith (talk) 18:08, 1 April 2017 (UTC)[reply]
sexual orientation (P91), ethnic group (P172) and religion or worldview (P140) are properties where I can see a general need for sources.
When writing a good BLP policy verifiability also isn't the only concern. Privacy also matters (and Jasper's proposal didn't say anything about it). Given Wikidata's much wider notability standards we can't simply copy enwiki on that front. ChristianKl (talk) 18:34, 1 April 2017 (UTC)[reply]
This was meant to address the issue of hiding revisions. Our oversight policy already includes provisions for hiding libel and other violations of the foundation privacy policy, but I guess you want it to be more explicit.--Jasper Deng (talk) 18:38, 1 April 2017 (UTC)[reply]
Libel isn't the only way to violate someone's privacy. It's possible to quote reliable sources about someone's home address and other doxxing informtion. We need a policy about when it happens to be okay to include the home address of a person. You don't violates Trump's privacy by saying that he lives in the White House and previously lived in Trump tower but if someone would include my home address in a Wikidata item about myself that would be a violation of my privacy. ChristianKl (talk) 18:51, 1 April 2017 (UTC)[reply]
I agree with you. WhatamIdoing (talk) 17:58, 5 April 2017 (UTC)[reply]
So, lets look at sexual orientation (P91), ethnic group (P172) and religion or worldview (P140). There are a lot of other sensitive data, like blood type blood type (P1853) or partner unmarried partner (P451) etc etc., but lets stick with sexual orientation (P91), ethnic group (P172) and religion (P140), because they even have explicit conditions for sources.
  • ethnic group: "Each P172 claim needs to have at least one (non Wikipedia) source". "subject's ethnicity (consensus is that a VERY high standard of proof is needed for this field to be used. In general this means 1) the subject claims it him/herself, or 2) it is widely agreed on by scholars, or 3) is fictional and portrayed as such)."
wd-analyst: Number of statements 17,637. unsourced statements 68%. Wikipedia references 31%.
  • sexual orientation: "Each P91 claim needs to have at least one (non Wikipedia) source". "the sexual orientation of the person — use IF AND ONLY IF they have stated it themselves, unambiguously, or it has been widely agreed upon by historians after their death")
wd-analyst: Number of statements 3,267. unsourced statements 78%. Wikipedia references 18,3%.
  • religion (P140): "Only if the person's religion is public information and important in his or her career."
wd-analyst: Number of statements 34,620. unsourced statements 80%. Wikipedia references 15%.
It's a disgrace. --Atlasowa (talk) 19:17, 2 April 2017 (UTC)[reply]
A disgrace for whom, Atlasowa? Wikidata? Careless tool users? But yes, sensible information should have a at least one solid reference. Otherwise the „information“ should be dropped. Gruß --Succu (talk) 19:40, 2 April 2017 (UTC)[reply]
@Succu: a complete taxon includes an author and a source. I am totally with you when we delete at the same of all information that "is not sensible" all deficient taxons. Thanks, GerardM (talk) 05:06, 3 April 2017 (UTC)[reply]
This subthread is about sensitive information not completeness. I'm fully aware that most of our more than 2,000,000 taxon names are lacking some basic information. --Succu (talk) 05:46, 3 April 2017 (UTC)[reply]
@Atlasowa: that doesn't look good - however, can you tell how many of those were for living people as opposed to historical data? ArthurPSmith (talk) 15:59, 3 April 2017 (UTC)[reply]
@ArthurPSmith: Wikidata:Request a query? Queries about references are not at all easy AFAIK. --Atlasowa (talk) 08:45, 4 April 2017 (UTC)[reply]

arbitrary break

Ok all, some good suggestions above on specifics. How about we continue this discussion on Wikidata talk:Living people and try to refine that page, which I just discovered has been around since 2013. ArthurPSmith (talk) 15:36, 3 April 2017 (UTC)[reply]
I cannot find all the good suggestions on that page. This is where the discussion is going on. I am not interested in yet another venue for this discussion where arguments are ignored. I have blogged yet again about quality and BLP.. An obvious additional point is that at Wikidata we are not in the business of biographies so there is no reason for a BLP. Thanks, GerardM (talk) 18:39, 3 April 2017 (UTC)[reply]
GerardM that is why the page here is called Living people and not "Biographies of living people". I have tried to consolidate the concrete suggestions from this discussion on that page; if you think I have missed something please consider adding it. I read your blog post, you are quite right that a lack of completeness through missing statements can be almost as harmful as statements made that are not valid. Nevertheless there is an issue here and it HAS resulted in some complaints particularly from enwiki people. There must be a happy medium. I am not advocating for, nor do I think anybody who wants such a policy is advocating for the mass removal of existing statements. If what we are doing now works, let's codify that so it can keep working. But these issues of potentially controversial or privacy-violating statements are real, so there has to be some areas where we need to both push for greater care and find ways to enforce that. I don't have a magic answer here, I'm just hoping as a community we can come together on this because it has been an issue that needs addressing for a long time now. ArthurPSmith (talk) 19:21, 3 April 2017 (UTC)[reply]
People from en.wiki have no standing. I am on record for a quality approach that uses "Sources" as being equivalent to "sources" as they focus our attention to where the issues are. We are heavily adding "Source" identifiers and we can use comparison to realise where it makes sense to spend additional effort to curate data.
As long as en.wp people only insist on us doing their bidding and not consider how Wikidata can enables improved quality in en.wp their opinion is exactly that. My guestimate is that some 4 to 6 % of their wikilinks particularly in lists are wrong. Thanks, GerardM (talk) 20:07, 3 April 2017 (UTC)[reply]
@GerardM: Right now you are just hand-waving without making a concrete suggestion. I think you're missing the fundamental point here: we have to be careful with any information on living people, no matter where it is on our website, because their lives can be seriously impacted by information on the web. Do you agree with that? And since anyone is welcome to edit, English Wikipedia editors' opinions do have weight, even though they don't control our community in any way.--Jasper Deng (talk) 20:38, 3 April 2017 (UTC)[reply]
@Jasper Deng: Really? With the way you put it, I fail to appreciate your point of view, I disagree with your conclusions, I even reject them. There are several approaches to quality that I support. What Glorian is doing is an initial step to something good. Paleim does great work on the death of people. This can be expanded to signal to signal more strongly to Wikipedias that they do not have a date of death for people. I have proposed to use Wikidata for the management of Wiki projects. "Black Lunch Table" is a working example for artists from the "African diaspora". I have proposed to associate Wiki links and red links in Wikipedia with Wikidata items. It will improve quality and completeness in both Wikipedia and Wikidata. I have proposed the notion of quality as the level of linking between items. At this moment I am doing this for librarians and, it works. I have proposed that the comparison between "Sources" (Wikipedia / Viaf / Open library et all) will allow us to focus on differences. When we concentrate on these differences and seek "sources" for these, our time is well spend because we are active where it matters. We should also seek a use for our data. Wikipedia templates is one, filling the {{authority control}} is another and helping people to find free books in Open Library is another.
So when this is all "classified" as hand waving, I fail to see that you actually understand what conversation the waving of hands supports. Now do you agree that all these approaches improve quality and by inference raise the level of what we do? If not what arguments of your own do you have because so far I fail to see you make a coherent point. Thanks, GerardM (talk) 04:49, 4 April 2017 (UTC)[reply]
@GerardM: Look, quality assurance is important in general, but the fact is that we cannot allow our site to be used for libel or defamation, and it is our obligation to prevent it. It's not about dates of death. It's about respecting a foundation principle: living people must have information on them treated with care. You're completely sidestepping this point. And you're not getting anywhere by doing so, because again, this is a foundation principle. Quoted from the resolution, we are urged to commit to "Ensuring that projects in all languages that describe living people have policies in place calling for special attention to the principles of neutrality and verifiability in those articles". A general notion of quality is not compatible with the need for special attention to information on living people. None of your proposals do that.
Perhaps a rhetorical question would help: if you were someone famous, and you found that your Wikidata item was modified to include claims like "instance of criminal", what would you think? What if its description were modified to say your occupation is a prostitute when you yourself were vehemently against prostitution (hypothetically speaking)? What if you found that someone posted a comment accusing you of having committed sexual assault on an item's talk page? Wouldn't you want an easy-to-refer page that clearly and directly states the community's commitment to be especially careful with living people? We're talking about the lives of real people here. These could be perfectly acceptable to include in the items of people who lived long long ago, even if poorly verified, but not in those of living people.--Jasper Deng (talk) 06:58, 4 April 2017 (UTC)[reply]
When you say "we cannot allow our site to be used for libel". Obviously. However, what you say is not practical. The quality of our data is substandard and that means that we misrepresent practically everyone on Wikidata. Misunderstanding this information is easy and obvious. When you do not understand how quality measured mitigate problems, fine. When you want to clean up the act of our project you have to focus our attention. We cannot do everything now. We have to fix the issues we know that exist first. When someone has an issue with our data, there are processes for dealing with them. How often were these triggered for Wikidata? Yes, we have had data that was wrong and I added some faulty data myself. That is not the problem, the issue is in how we deal with them in a scalable way. Bullshit rhetorical questions are exactly that. Thanks, GerardM (talk) 11:21, 4 April 2017 (UTC)[reply]

──────────────────────────────────────────────────────────────────────────────────────────────────── @GerardM: I'm going to remind you again that we do not have the luxury to not pay attention to this, because Wikidata exists in the real world, and real people are impacted. But you at least agree on the subject of libel. If I revert something libellous or potentially libellous, I need to have a policy I can point to. It is true that we cannot do everything, but the least we can do is formulate a policy. This is not the same as implementing it (i.e. auditing items for such information). You may claim this is impractical, but the fact is, it's not. Enforcing protection of living people is this straightforward.--Jasper Deng (talk) 19:25, 4 April 2017 (UTC)[reply]

There is a difference between libellous and damaging. When someone is convicted at the international court in the Hague it is damaging, not libellous. Anyway.. my problem is that we have projects dealing with information of living people, I see easy options for more projects what I do not see is involvement. I have added millions of statements and as anyone I make mistakes. What is wrong is in the "Sources" and on top there are my own mistakes. When it comes to living people, we already will remove libellous information. We will send people packing who add wrong information when we notice their pattern. Projects have been formulated that focus on erroneous statements or focus on particular relevant information like date of death and the comparison with "Sources".
What is wrong with policies based on all individual items focusing on living people is when they do not take in consideration the existing items / data / people we already represent in items. I resent it when they do not recognise that a lack of data does misrepresent people and we have loads of those. I resent it when a policy is so stupid to prevent us from improving the quality because of adding individual item based restrictions. I resent it when people that talk do not seek practical measures to increase quality. I have presented several policies that will impact quality both in Wikidata and Wikipedia but that is ignored because it does not fit the preconceptions.
What I hate most is that what is proposed in a LP is based on bad faith and starts with the wrong premises. This does not mean that "sources" do not have their relevancy and it does not mean that having them is a positive quality improvement and it does not mean that they are extremely relevant when there are conflicts. Thanks, GerardM (talk) 04:48, 5 April 2017 (UTC)[reply]
@GerardM: It's not even about individual items or about bad-faith edits. I gave the example of a person's own item as a simple one, but LP would apply to any page. For example, if on someone else's item I add a claim saying you are their spouse, even in good faith, you might feel uncomfortable with that. All of my example claims could be perfectly acceptable if any reasonable person would be convinced that they are true (i.e. verifiable). But because the burden of proof lies on whomever adds the data (something I am aware you disagree with, but which is absolutely essential in this case - we cannot wait for a living person to complain to us because that is not their job), they can't be added otherwise. This is not nearly as much of an issue for other items. It's not even limited to items: adding those same claims to this page or any other discussion page can be just as bad.
One does not need to be acting in bad faith to run into issues here. Not everyone who comes here (remember, our content is editable by anyone, including completely new users unfamiliar with how online information can affect real people) knows to avoid adding things they hear about in forums and on social media, because as far as they are concerned, that information is true. They may add that to Wikidata in perfectly good faith. An LP policy would also serve as a page to educate such users.
Finally, you already agree that we remove libellous and incorrect information. But there is no written policy at this time that requires it (WD:UCS does not count). Furthermore, as I hinted above, all users, good-faith or not, should have an easy-to-refer-to page for the purpose of learning about why information that might merely be disputed in some topics should not be added at all to the website, barring easy verifiability. Note that I am leaving "verifiability" as a free word here, since the community hasn't defined it.
This might not have the immediate effect of improving our data quality, but it provides reassurance to living people that we are at least committed to being careful with their information. Again, however, as much as you may dislike it, you can't conflate the issue of general data quality with being careful with living people - living people comprise quite a small minority of our items as far as I can tell. Unlike with most subjects, it is better to have no data than to have dubious data when it comes to them.--Jasper Deng (talk) 05:31, 5 April 2017 (UTC)[reply]
It does make a nice plot though tinyurl.com/m6shc5l. I didn't know the bar-chart display mode automatically sorted the data. Jheald (talk) 09:20, 4 April 2017 (UTC)[reply]
  • speaking as a Wikimedia movement member who primarily edits en-WP, some observations
The first is that I get it, that a goal of Wikidata is scalability and openness. You want to be able to run bots that add data to loads of articles, and you want people to be free to make individual edits.
At that same time, I see a real consensus above (with the glaring except of GerardM) to take the WMF resolution about living people seriously.
So this project should think through how to accomplish the two goals above.
I would think that this would be the way to go:
a) decide what this project will consider to be "reliable sources" for data about living people and through that discussion establish a Wikidata:Verifiability policy for data about living people. (the focus on living people should make that discussion tractable)
b) in practice, put any bot runs that will add data to items about living people through severe scrutiny with regard to the source from which the data is taken, per a).
c) change the WD software so that no one-off entry can be made to entries about living people without citing a source. (!) And perhaps flag them for review with some kind of "pending changes" function.
It is likely that some people will be interested in and committed to the work of reviewing and cleaning existing entries on living people, and through that work you all will encounter a bunch of disputes that will eventually result in standard ways to resolve them, and those ways to resolve them will result in a WD:LP policy that grows from community practice and has consensus here.
fwiw. Those are all very actionable things, and would be a better use of everyone's time than arguing with GerardM. Jytdog (talk) 22:44, 4 April 2017 (UTC)[reply]
a - ok; b - no; c - no. you will not increase data quality by raising the drawbridge, preventing unsourced data input, or increasing the scrap rate of unsourced data. you will not increase data quality by instituting a block policy under the BLP rubric. and you will not increase quality by drive by tagging.
rather you must have a quality circle. "It is likely that some people will be interested" - show me the project. i see a lot of normative statements and exhortation. i do not see many work horses here.
this would be a good grant proposal. let's start by working with the ORES team to use their metrics. Wikidata:Project_chat#Item_Quality_Pilot_Campaign, Wikidata:Item quality campaign; then make a query of unsourced statements about LP. Slowking4 (talk) 01:58, 5 April 2017 (UTC)[reply]
@Slowking4: While I mostly agree with you in principle, I very strongly disagree that I should not be able to make blocks for violations of LP. I like that many project members are thinking along the lines of "positive" (i.e. "we should do this and focus on that") rather than "negative" ("we cannot do this because of that") statements, but the subject of living people is sensitive enough to warrant it. I don't want to be the devil's advocate, but we should not have potentially libelous or otherwise damaging (to a given subject) information in the knowledgebase unless we can be assured that it is correct. Users who insist on inserting claims like "person x is an instance of sexual offender" indiscriminately should be blocked from doing so, because that goes contrary to the foundation principle and can harm real people.--Jasper Deng (talk) 02:18, 5 April 2017 (UTC)[reply]
i would suggest that your desire to block people is a wikipedia cultural norm, for which you will not find a consensus here. and no amount of drama-mongering or scare quotes about "libelous" either on wikipedia or here will get you that consensus. i increasingly see the argument that "this issue is so important that we are justified to suspend AGF." i would suggest that a pillar is more important than a policy. we have seen the consequences of this toxic practice with editor decline at the wikipedias where the blocking culture is the worst. Slowking4 (talk) 16:19, 5 April 2017 (UTC)[reply]
@Slowking4: Please capitalize your "i" and the first letter of each sentence, it's harder to read your comments when they are all lower-case No, read my reply to Gerard above. Blocking does not imply assumption of bad faith and I don't see where you got the notion of the opposite; good-faith edits can be disruptive. To be quite frank, a policy without provisions for enforcement is not a policy at all.
With that said, it's not like this would all-of-a-sudden result in a million users blocked at once. Blocks by their nature are to be used only if needed. A user, good-faith or not, who receives repeated messages about their editing and keeps doing what they're doing is a candidate to be blocked - and, other than extreme cases, not otherwise.
If you think this is not a problem, just take a look at my linked examples above.--Jasper Deng (talk) 17:13, 5 April 2017 (UTC)[reply]
It is exactly your point of enforcement why I oppose your need for a justification to delete. When a fact (like a spouse, a date of death) is supported by a Wikipedia, you are not justified in deleting a statement or banning a user. It is a too narrow view on what we do and where we are in our development. Without a justification for deletion or blocking, I agree that "sources" are to be preferred and when there is no secondary support, sources may be asked. When there is suspicion of bad faith, we already do go further and that does not need a policy change. Thanks, GerardM (talk) 06:28, 6 April 2017 (UTC)[reply]
@GerardM: What if said statement happened to have been added by a vandal on that Wikipedia at the time you added it? What if it were directly inserted out of nowhere? If a living person is upset by that statement, do you think they care where it came from if it's dubious and not verifiable? You're still missing the point (if you are having trouble understanding my comments due to a language barrier, please do not hesitate to get translation from others). And like I said, bad faith is definitely not a necessary condition for LP-violating information to be inserted. And no, even in the case of bad faith, we do not have a policy for that (not all bad-faith edits are mere vandalism).--Jasper Deng (talk) 07:21, 6 April 2017 (UTC)[reply]
How often have their been complaints by external people about Wikidata. Get real. You insist on your point of view and do not consider anything else. No, I do not want you to delete on such flimsy arguments. Thanks, GerardM (talk) 16:40, 6 April 2017 (UTC)[reply]
@GerardM: There are none that I know of. However, that absolutely does not mean it's not a potential problem that we should work towards addressing. Your logic is like saying in a new town, we should only have a fire department once a home in that new town burns down, or saying that there shouldn't be an evacuation plan in place for a tsunami in the Pacific Northwest region of the United States despite the glaring threat of a tsunami from the Cascadia Subduction Zone. The bottom line is, we have to be prepared. You clearly are the one who isn't being real here. Have you not read the foundation's resolution? After all, the English Wikipedia removed Wikidata's descriptions from mobile search precisely for this reason.--Jasper Deng (talk) 19:28, 6 April 2017 (UTC)[reply]
You are conflating two issues and ignoring some main issues. The problem with descriptions has been ignored for many years and there is a solution that is wilfully ignored. You rate it a BLT issue and that makes your POV about your wish to enforce as an admin. You ignore that for many BLP there is a BLP issue because of a lack of data. Your pov prevents your use of my argument that we are immature in where we are with Wikidata. There is a tool by Pasleim and when we truly cared about BLP there would be not so many items that need an BLP intervention. Your example of a new town you could consider Almere but at its very start there was no fire department. That came later. As to resolutions, they are written for a different platform. It does not consider the corner cases in Wikidata and it certainly does not consider the issues that we face. I am adding a profession for 5383 people at this very moment. It is backed by information in a Wikipedia that suffices for sources as far as I am concerned. That Wikipedia has an error rate and there are errors in there. I did check glaringly interesting cases by hand and that is all you can expect. When you state "we have to be prepared" my question is for what and why? We are not prepared to tackle our known existing BLP issues, we have a problem because of a lack of data and not too much data, there have been no complaints and we can tackle them using our vandalism approach anyway. Vandalism with BLP issues may need a firmer approach. My position is I am totally on board to improve our BLP, I am not on board when we are to implement something that works on a big Wikipedia, that has no provisions for what we do and that does not really function on small Wikipedias. So get real and think on how we can tackle BLP issues and forget your power grab. Thanks, GerardM (talk) 04:15, 7 April 2017 (UTC)[reply]
"conflating two issues" @GerardM: To be quite frank, to say this and to accuse me of not listening is to call the kettle black, and it's getting tiring. You're not making a coherent argument by copying, misusing and misunderstanding my terminology.
You are assuming a priori that we are already even committed to addressing living people. That's not what we have, and why we need to have a policy. And no, you again misunderstood my analogy. We're not a brand new project, so that invalidates the counterargument that it's too early. We're quite an old one (we will be celebrating our 5th birthday this October), with tens of millions of items - which makes it even more important for us to have a policy. Also, you should know very well that your view that you are not responsible for the reliability of information you import is not accepted (just check your own talk page), and that therefore, "imported from Wikipedia" usually does not suffice. The problem is, what if the information you imported was not compliant with BLP on the home wiki? You're only exacerbating the problem by importing it. Your mass imports have been controversial in the past so you are in no position to use it as an example; if I knew you would be doing this I would have refused to unblock your RobotGMwikt alternate account when you approached me in person at Wikimania 2014 about that.
And you're also blatantly wrong that we're not prepared to handle BLP issues, unless you are referring to the fact that we have no policy to that effect. That's a very defeatist attitude and not helpful. Admins have the tools to handle BLP, and I know that because I myself have used revision deletion to that effect. And no, you cannot ignore the resolution because it predates this project. Foundation resolutions apply everywhere unless they state otherwise. We are a content project so we definitely fall under that.
Overall, I really dislike your negative attitude. You do not have the perspective of an administrator who has handled this sort of thing, so your comments are almost condescending.--Jasper Deng (talk) 23:13, 7 April 2017 (UTC)[reply]
If just a) and b) agreed that would be an amazing place to start. Jytdog (talk) 03:00, 5 April 2017 (UTC)[reply]
i would agree to b) if it were not "severe scrutiny" but rather "severe coaching and counseling of uploaders to do the necessary pre-processing of data sets". i prefer the coach model to the gatekeeper model, in a consensus project. Slowking4 (talk) 16:26, 5 April 2017 (UTC)[reply]
@Jytdog: It also remains that any notion of (B)LP is contingent upon a notion of verifiability, so we must also discuss that.--Jasper Deng (talk) 07:21, 6 April 2017 (UTC)[reply]
@Jytdog:c would mean having stricter standards than en-wiki. On en-wiki you can make edits on living person that cite no sources without violating the en-wiki BLP policy as long as the statements aren't likely to be challenged. I don't think the wish to be "stricter than en-wiki" will win any RfC.
As far as b goes, how does en-wiki handle the issue? ChristianKl (talk) 12:17, 11 April 2017 (UTC)[reply]
User:ChristianKl -- i suggested b) and c) together, ~trying~ (probably unsuccessfully) to think about Wikidata as Wikidata, and not as a Wikipedian. The emphasis here as far as I can tell is all about data, and all about scale. b is really the most important. We don't have bots that add tons of content in en-Wikipedia; there is no analogy that I am aware of. Bots in en-Wikipedia tweak stuff. Cluebot changes content, but all it does is delete vandalism. I don't know how it works. With regard to c, yes for these fields this would be more restrictive than WP. But WP has a BLP and V policies not to mention "discretionary sanction" imposed by "Arbcom" (our supreme court, as it were) and we have well established policies and procedures to handle disagreements (questionable stuff is removed right away and not restored until it is settled) and people who do bad things to content about living people get the banhammer. Swiftly. In the absence of solid policy and procedure, locking down just those fields is a sensible thing that honors what Wikidata is and its level of development as a project, and respects the Foundation resolution. Jytdog (talk) 19:33, 11 April 2017 (UTC) (correct per below Jytdog (talk) 21:19, 11 April 2017 (UTC))[reply]
Jytdog, yes, Wikipedia has bots that add tons of content. Here's a bit of trivia for you: Which Wikipedia has the second-largest number of articles, and how did they do that with one-fiftieth as many active editors as the English Wikipedia has? Which Wikipedia has the third-largest number of articles, and how did they do that with less than 100 active editors? Answers: Swedish and Cebuano – and they run article-writing bots.
It's not just those two wikis, either. Bots have been used to create articles at the Vietnamese, Waray-Waray, and Dutch Wikipedias – and the English Wikipedia. User:Rambot was before your time, but it used a single source to create articles like this one at the English Wikipedia. The last time anyone looked, that one bot had created or edited about 98% of the English Wikipedia's articles on US geographic locations. JBradleyBot added multiple paragraphs to thousands of articles at the English Wikipedia a few years ago. WhatamIdoing (talk) 20:59, 11 April 2017 (UTC)[reply]
Those geographic article-creation bots were incredibly controversial in en-WP as you well know. yes there are bots that generate content in other Wikipedia languages. I corrected above. Jytdog (talk) 21:19, 11 April 2017 (UTC)[reply]
@GerardM: the problem seems to be that you are "assuming bad faith" on the part of Jasper Deng (and enwiki folks, etc. etc.). I don't believe that is true at all, I think this is an honest attempt to help us find a workable policy solution here. Note also that wikidata is hardly "small" any more in itself. However, I do see one potential source of trouble - the statement in Wikidata:Verifiability that "The majority of unsourced statements, and statements not supported by the source provided, will be removed from Wikidata.". The second portion (statements not supported by the source) I agree with, but the first half (majority of unsourced statements ... will be removed) I find clearly objectionable. If there is no cause to remove a statement, why remove it just because no source is given? If it is a statement that might be argued with, the first step should be to find a source that either supports the statement, or find a contradictory source and add that (sourced) statement. We should not be removing statements just because they have no specified source. Except - possibly - in the case of living people for certain types of information as we've been discussing here. Help:Sources lists a lot of exceptions to the general requirement for sources, including "common knowledge" which can cover just about anything. More to the point of this discussion, the proposed policy at Wikidata:Living people supports indirect sourcing: statements, labels and descriptions can "Be supported by information in at least one corresponding Wikipedia article, that (in the article) has a citation to a reliable source". So GerardM or anybody else, if you are importing data from a wikipedia, add the "imported from ..." wikipedia statements, or perhaps better a reference URL directly to the source page, and you should meet all the proposed requirements. But we do need to reword the statement in Wikidata:Verifiability because I don't think that's anywhere near current practice or community consensus. ArthurPSmith (talk) 13:38, 7 April 2017 (UTC)[reply]
The problem is that it has nothing to do with bad faith and everything to do with refusing to argue. They do not refute any of the arguments opposing their point of view. There has been no problem so far from external parties but the internal criticism about descriptions is ignored, the use of "Sources" to target our effort where we are weak is ignored. The notion that the lack of data itself is a "BLP" issue, the fracas with the quality states has only an acceptable outcome when we do not accept it as effective but only as an approach to quality. An approach that may improve over time. This "Verifiability" thing is not a policy and it will be a disaster when applied. It is a disgrace that tools we have to fix BLP issues are not used by all and that so many known issues are still there.
The problem is that it is not an honest attempt to help. It is wilful disregard to face observable facts and a refusal to argue and listen. The problem is that it is telling others what to do and not walking the walk themselves. It is all talk and exactly because of this refusal to argue not accepted. Thanks, GerardM (talk) 21:04, 7 April 2017 (UTC)[reply]
@GerardM: Do you really think I would be spending time on an issue that did not matter to me? Do you really think I am not spending my precious time for anything but the betterment of the project? As I said above, this comment is quite hypocritical. I will not go as far to say that your comment describes your own (earlier) comments, but that's not far from the truth, and your comment very clearly assumes bad faith on my part. I should remind you that last month, you were put on moderation on the wikimedia-l mailing list because of that, and ArthurPSmith (talkcontribslogs) has observed it too, so it's not like I am the only one who has observed it. It is very hard for me to lighten my tone when you are so disrespectful.
I'm not going to be responding to your comments anymore because that is clearly not constructive.--Jasper Deng (talk) 23:13, 7 April 2017 (UTC)[reply]
@Jasper Deng: I do not say that you do not care, I never did. I say that you are wrong. No bad faith, but with all the arguments I put in front of you, no argument of mine has been refuted. You did get a reaction to the arguments you put forward. When you consider the BLP it did good and it did harm at Wikipedia. If you cannot see this, fine, ask someone who should know.
Calling me hypocritical is a personal attack. You forget that I have a large and consistent body of work in my blog. It is quite consistent on the issues that I raise and I raised them over the years, twelve years. When you study what I wrote you will see that I developed my arguments often in response to critique. So you may care but arguably so do I.
I do not mind to be wrong, but prove it. At that you failed and it is reasonable to expect that the implementation at this time of a destructive BLP policy will hurt Wikidata. I made my arguments, they are there to refute, not to ignore. Thanks, GerardM (talk) 04:03, 8 April 2017 (UTC)[reply]

Executive Order data from Federal Register

Note: this was originally posted on Wikidata:Partnerships and data imports, but in line with Wikidata:Data donation#How to add data to Wikidata, I am reposting it here.

I'm looking to improve the coverage of Federal Register records on Wikidata, and I'm looking to start with Executive Orders. The Federal Register has exportable lists of United States Executive Orders since 1994 at https://www.federalregister.gov/executive-orders in both CSV and JSON formats. There are approximately 1000 documents listed, with a fairly well-populated example extant on Wikidata at Executive Order 13233 (Q5419885). There are also further details about the Federal Register API on their developer resources pages, but I'm looking first at establishing a set of mapped and well-populated records before even considering any sort of API usage. One of the things that this is for is to provide additional support for Wikipedia:Template:Infobox U.S. Presidential Document, to which I've added a number of Wikidata properties in order to automatically populate a number of fields, including various document numbers and links to the Federal Register document.

I'll be honest, I've never dealt with Wikidata uploads before, and my experience with APIs is almost as limited, so I would greatly appreciate any assistance that I can get. I am more than happy to do any groundwork in preparing either a CSV or a JSON file, including mapping properties to the data fields populated in the Federal Register records. Would anyone be able to assist me in the upload? — Sasuke Sarutobi (talk) 17:19, 2 April 2017 (UTC)[reply]

please also check out Wikisource:WikiProject United States Executive Orders - talk to transcribers from scans there or at Wikisource:Scriptorium. we have talked with the federal register folks at NARA, drop a line to user:dominic. Slowking4 (talk) 03:32, 3 April 2017 (UTC)[reply]
I'm interested. I'm trying to gather certain Federal Register entries which may belong on Wikidata too. I don't know about uploads yet. econterms (talk) 16:54, 7 April 2017 (UTC)[reply]
Slowking4: Thank you, that helps a lot! I'm messaging the EO WikiProject now, and I'll speak to user:dominic afterwards.
Econterms: Is there anything that you're looking into in particular? I've got a number of basic properties already mapped out on the page for Wikipedia:Template:Infobox U.S. Presidential Document (mostly the ones most appropriate to EOs). Please feel free to message me, and I can see if I can help you from what I already know. — Sasuke Sarutobi (talk) 15:30, 9 April 2017 (UTC)[reply]

Mix'n'match proposing inclusions that do not meet notability

I am wondering why toollabs's mix'n'match is offering creation opportunities for items that are not within the notability criteria [Abraham Janeway. While I can understand that the tool can generate potential matches of external data, I am not convinced that it is the bot's role to offer these for creation of an item here when there is no internal article, nor a wikimedia page, hence not within the inclusion threshold. I can understand that I can kick past its offerings, as it doesn't reference notability, nor even link to notability, one can see that people will create and match, "just because". Am I missing something?  — billinghurst sDrewth 06:31, 4 April 2017 (UTC)[reply]

To clarify, I am seeing things match like ACAD (Cambridge Uni alumni) and CCEd (clergy database) which are people of their time, but when dying at 25 years of age, + other DB, which are hardly notable by our criteria. There must be some databases that we should treat as secondary and supportive of data, not notable in their contents.  — billinghurst sDrewth 06:46, 4 April 2017 (UTC)[reply]
@billinghurst: It's just a tool. Often, eg for painters, it is useful to be able to directly create an item. Jheald (talk) 08:34, 4 April 2017 (UTC)[reply]
(ec) @Jheald: I understand that it is a tool, however, it is a tool that is advertised, and advertised without reflection or connection with the requirements for inclusion; and iclusion requirements are not further identified on the tool. I am not saying ditch the tool, I suggesting that there needs to be fine-tuning in what/when it presents. Certain sources, eg. ODNB, contain notable subjects; other sources, ACAD/CCEd contains some notable people, but it is not a database of notable people. So maybe not present names where there is notable subject sources, or there is no matching WD items.  — billinghurst sDrewth 10:33, 4 April 2017 (UTC)[reply]
What makes you think someone with entries in four external databases does not met our current notability criteria? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:01, 4 April 2017 (UTC)[reply]
My inclusion in four databases doesn't make me notable. Inclusion in a database doesn't make anyone notable, unless the data is specifically notable.  — billinghurst sDrewth 10:33, 4 April 2017 (UTC)[reply]
I think you need to re-read the current notability criteria; in particular: "It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references.". Conversely, your "unless the data is specifically notable" claim is not supported by any text in those criteria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:45, 4 April 2017 (UTC)[reply]
So you are saying that Abraham Janeway is notable as he appears in an employment database (CCEd) and a similar listing (Surnam) and a list of university students? So what about any person who can be found in the 1851 UK census; Someone whose will appears in the PCC probate? Someone who appears in bankruptcy court records? A criminal who has a court record, transportation record, ticket of leave, etc.? Someone who appears in published government records of employees? All those seem to fit your criteria, and generally none of those people will be notable. Or is it that they all have an electronic web-classified number? I feel your acceptability of criteria for notability is too low.  — billinghurst sDrewth 13:47, 4 April 2017 (UTC)[reply]
I'm afraid the word "serious" in the notability criteria is just too vague. Those who are fond of gobbling up data the way a blue whale consumes krill are bound to interpret "serious" as "not compiled by a crackbot or anonymous author".
I note the Mix'n'match tool includes a genealogy database. I don't know if it is consulted when the tool makes suggestions about creating items, but if so, it would make the goal of the tool to include everyone for which records exist. We might as well use the phone book. I think the notability critera require revision. Jc3s5h (talk) 14:03, 4 April 2017 (UTC)[reply]
The issue here is not with Mix'n'Match. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:03, 4 April 2017 (UTC)[reply]
I'm saying that Janeway meets the criterion I quoted; which is that agreed and used by the Wikidata community. It's not "mine". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:03, 4 April 2017 (UTC)[reply]
Yes, the way Andy Mabbett interprets this policy, everybody in a phone book would meet these criteria. Presumably, this policy was drawn up assuming that users would use good sense. Adjusting the policy is a good idea. - Brya (talk) 16:23, 4 April 2017 (UTC)[reply]
This has nothing to do with my interpretation of our notability policy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:48, 4 April 2017 (UTC)[reply]
Is an entry in an local phonebook or an social media account sufficient enough to become notable in our sense? --Succu (talk) 19:26, 4 April 2017 (UTC)[reply]
In my opinion: NO. Databases are informational, not notable. The criteria for inclusion into a database is what matters. Telephone books, and social media accounts are low-bar information, which is pertinent ONLY when the person or organisation is notable. We need to be able to rate and rank databases for credible notability, not their accuracy and scope. — billinghurst sDrewth 21:53, 4 April 2017 (UTC)[reply]
In what way is it "good sense" to not have an item about a person that's already referenced in four databases. The person clearly seems to exist. Storage space is cheap.
When it comes to copying data from the local phonebook there are privacy concerns. It's quite easy to create social media accounts of fictional persons that don't exist, so I don't see a social media account as a serious source. Curated databases like the membership database of a university on the other hand are serious sources. ChristianKl (talk) 09:34, 11 April 2017 (UTC)[reply]
@ChristianKl: My argument is not doubting that a source is serious, nor that a database is notable; my raising the discussion is whether items that appear in a database become notables under our criteria for their presence alone in a database. My argument is that the single criteria of that item's appearance in a database does not make that item notable; and extrapolating that, appearance of the same item in multiple databases does not make a person notable. Our notability criteria should not solely be multiple appearances in datasets, so we need the means to rate a dataset, eg. dataset #A shows notable people by a criteria, so people are automatically notable; dataset falls into rank #1; dataset #B shows all people who have an event type, or includes numerous people who are doing non-notable activities, this is rank #3, it can be used for supportive, references only, not to determine notability or creation of an item.  — billinghurst sDrewth 02:24, 12 April 2017 (UTC)[reply]

Help getting property proposal for Australian Honours

Would someone more conversant with proposing properties plug together the information so we can add the Australian Honours that are currently sitting in mix'n'match.

I see examples are Gough Whitlam (Q23333) receiving Companion of the Order of Australia (Q9680541) (link 884426 as evidence); and receiving Centenary Medal (Q2393205) (link 1112594 as evidence). So each awarded honour will have one reference link within the system. The website for the honours is described at It's an Honour (Q6091377). Thanks to anyone who can string this together.  — billinghurst sDrewth 03:16, 5 April 2017 (UTC)[reply]

Hoi, I do not understand the problem.. Both awards were already part of Mr Gough Whitlam. So what is your problem ? Really interested to see more background to Mix'n Match as well.. Thank,  – The preceding unsigned comment was added by GerardM (talk • contribs) at 5 April 2017, 16:17 (UTC).
@GerardM: I know Gough has the references added, it was meant to be illustrative to have the references added as means of an external identifier, rather than a straight paste of the url (base url always better handled through a specific item than raw url).

[1] enables the presentation list of the awards. To my view, the straight use of mix'n'match and application of link is not appropriate, as here the external-id is actually an award (award type, date, person) rather than a typical straight identifier of a person, especially as some people will appear multiple times (eg. Whitlam). I will be back to annoy Magnus about how we could utilise the database through an alternate presentation to apply the awards and data, but either way having the ability to have linking through a property enables better checking, and data manipulation, and can be manually or systemically applied.  — billinghurst sDrewth 21:26, 5 April 2017 (UTC)[reply]

ːˑ Mr Cough has multiple awards and by finding the link, adding an item it is possible to identify one person once and add multiple awards lager.. I think this is an appropriate way not to abuse the time of people too often. Thanks, ~~ ~

Scientific papers - Author's items

I have created an item of a scientific paper, but I face the issue that some authors are not known or famous (phd students). Should I create items for them to include them in the author fields or not? Maybe it is also good to know who exactly fulfills the requirements to have a wikidata item. Would be thankful for any reference to this issue --Sky xe (talk) 10:29, 5 April 2017 (UTC)[reply]

@Sky xe: For those cases there is author name string (P2093). You can also specify the order in which the names appear on the paper. See for example:
--Micru (talk) 11:33, 5 April 2017 (UTC)[reply]
What if the author string is ambiguous? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:01, 5 April 2017 (UTC)[reply]
I asked this question in the past and was told an item for the author should be created because "it fulfills some structural need". Jc3s5h (talk) 14:13, 5 April 2017 (UTC)[reply]
@Jc3s5h: On one of the examples cited above there are ~600 authors. In those cases it is not practical to create items for all of them. Normally it is better to use your own criteria than any fix rule.--Micru (talk) 11:17, 6 April 2017 (UTC)[reply]
In my opinion, even if the article has ~600 authors, it is important to create item for each author since sometimes the authors may have other publications in the future. The creation of such items satisfies the Wikidata:Notability criterion pointed out by Jc3s5h). Also it is easier to search other articles by the author. Tools like QuickStatements can be used for bulk item creation. Jsamwrites (talk) 11:31, 6 April 2017 (UTC)[reply]
and if those authors have previously been added to wikidata then what? How do you link them up? Are we planning to have every publishing researcher (ORCID has over 3 million) in wikidata? ArthurPSmith (talk) 14:03, 6 April 2017 (UTC)[reply]
I know it's a bit difficult task (but not undoable) to verify whether there are already existing items. But that brings to the second part of the question on whether or not we are interested in having all the ORCID identifiers here on Wikidata? Jsamwrites (talk) 17:37, 6 April 2017 (UTC)[reply]
Should is too strong. I would say "It may be created". Notability is established through the structural need but that doesn't mean that you have to add items for the authors if you don't want to put in the effort. ChristianKl (talk) 09:20, 11 April 2017 (UTC)[reply]
If we use good references, most of the time we can create an item for the authors because good references are written by experts which write several articles or books. Snipre (talk) 12:25, 6 April 2017 (UTC)[reply]

Quoted text in an item description

Can a description be copied directly from a dictionary or, in the case of the item being a published work, from the preface of that work or any other publication? If so, how do we demonstrate that this is a quotation and not original text? Martinvl (talk) 18:54, 5 April 2017 (UTC)[reply]

Copyright, wise I don't think that's possible. Try to write your own description. ChristianKl (talk) 12:09, 11 April 2017 (UTC)[reply]
@ChristianKl: I have done a little more reading around the subject and this example suggests to me that use if dictionary definitions is "fair use". The example also shows how to format such use. Martinvl (talk) 11:58, 12 April 2017 (UTC)[reply]
I don't think anything written in the link suggests usage in Wikidata and it's derivative works would be fair use, especially when we are talking aout more than a single item. ChristianKl (talk) 12:10, 12 April 2017 (UTC)[reply]

Wikidata editor for Wikipedia

I would like to announce my grant proposal for the development of a gadget for editing Wikidata information (primarily used in the infoboxes) without leaving the Wikipedia page. My goal is to make one simple gadget helpful for all users which cover 80-90% of the needs, even if not everything is available for editing. In simpler terms, it's about creating an editor for "Wikidata infoboxes". Please write your opinion and wishes on the grant page. —putnik 01:03, 6 April 2017 (UTC)[reply]

QuickStatements tool not working for me lately

Calls like this done with quick_statements tool are not working for me lately. I click the button and nothing happens: no edits, no request to log in with oAuth and no error messages. I see 3 possibilities: (1) tool is broken, (2) I am doing something silly and the tool is properly "saving" me from making a mistake, or (3) something is wrong with my setup, state of oAuth, browser, etc. Does quick_statements tool work for others and is so can someone execute this commend to add Commons Creator page (P1472) to Alexander Hausch (Q18325071)? --Jarekt (talk) 13:00, 6 April 2017 (UTC)[reply]

Looks like QS is broken. I get this in console (when I'm logged in, if that matters):
Uncaught ReferenceError: toggleHowto is not defined
XMLHttpRequest cannot load https://tools.wmflabs.org/widar/?action=get_rights&botmode=1. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://tools.wmflabs.org' is therefore not allowed access.
OK, the first one isn't related, but toggling is also broken. Pinging Magnus Manske (talkcontribslogs). --Edgars2007 (talk) 13:24, 6 April 2017 (UTC)[reply]
That version seems to work --Ghuron (talk) 13:56, 6 April 2017 (UTC)[reply]
Also niosh fork of quick_statements works. --Jarekt (talk) 11:43, 7 April 2017 (UTC)[reply]

Busts

It looks like there is a little mess in two of these elements (interwiki, properties. categories and so on): bust (Q241045) and bust (Q17489160). And I cannot understand if they should be merged or not. --Stolbovsky (talk) 16:37, 6 April 2017 (UTC)[reply]

They shouldn't be merged. Fr.Wiki has articles for both of them. bust (Q17489160) is only about scultures. bust (Q241045) is about scultures as well as paintings. ChristianKl (talk) 15:59, 11 April 2017 (UTC)[reply]

When a "comune of Italy" change name

Luni (Q270220) will change its name April 20 (pdf source) how to manage this change? On wiki we move the page, but here? --ValterVB (talk) 17:13, 6 April 2017 (UTC)[reply]

For UK administrative entities where this has happened, I tend to change the label to the new name, with the old name given as an alias; and also to record both names in statements with official name (P1448), with the old name qualified with end time (P582) and the new one with start time (P580). Jheald (talk) 18:39, 6 April 2017 (UTC)[reply]

Associating a publication with a museum

This book How the West Was Worn (Q29192837) was published by Abrams Books (Q4669411) "in association with" Autry Museum of the American West (Q4827110). It is related to an exhibition, but it is not a catalogue of the exhibition. How can I show the relationship between the museum and the publication? - PKM (talk) 00:06, 7 April 2017 (UTC)[reply]

Notification about "Information extraction and replacement"

One of my crazy ideas; Information extraction and replacement, it is about supervised learning of patterns that encapsulates facts. This is the first step on extracting facts, and identification of sources, both on Wikipedia and external pages. (The whole thing is well-known language processing stuff, and is not pushing edges anywhere. In short, boooring!) Jeblad (talk) 00:13, 7 April 2017 (UTC)[reply]

QuickStatements - problems with quantities without unit

The standard version of QuickStatements ([2]) doesn't allow to add references or qualifiers to quantities ([3]). A partial solution comes with the niosh fork: All works fine as long one uses quantities with units. But using quantities without units results in two problems:

  1. Again references and qualifiers are not added.
  2. Numbers are extended with many additional digits. (For instance 0.641 becomes 0.6410000000000000142108547152020037174224853515625)

The first problem I can solve by using https://tools.wmflabs.org/quickstatements/ But I didn't find a solution for the second problem. Any suggesion? 123 (talk) 00:50, 7 April 2017 (UTC)[reply]

I will give it a look, as I'm responsible for [4], [5] and [6]. Additional digits looks like a floating point (Q117879) issue beyond Quick Statements though: numbers are sent as-is to Widar. --EdouardHue (talk) 11:10, 8 April 2017 (UTC)[reply]

Please accept our apologies for cross-posting this message. This message is available for translation on Meta-Wiki.

On behalf of the Wikimedia Foundation Elections Committee, I am pleased to announce that self-nominations are being accepted for the 2017 Wikimedia Foundation Board of Trustees Elections.

The Board of Trustees (Board) is the decision-making body that is ultimately responsible for the long-term sustainability of the Wikimedia Foundation, so we value wide input into its selection. More information about this role can be found on Meta-Wiki. Please read the letter from the Board of Trustees calling for candidates.

The candidacy submission phase will last from April 7 (00:00 UTC) to April 20 (23:59 UTC).

We will also be accepting questions to ask the candidates from April 7 to April 20. You can submit your questions on Meta-Wiki.

Once the questions submission period has ended on April 20, the Elections Committee will then collate the questions for the candidates to respond to beginning on April 21.

The goal of this process is to fill the three community-selected seats on the Wikimedia Foundation Board of Trustees. The election results will be used by the Board itself to select its new members.

The full schedule for the Board elections is as follows. All dates are inclusive, that is, from the beginning of the first day (UTC) to the end of the last.

  • April 7 (00:00 UTC) – April 20 (23:59 UTC) – Board nominations
  • April 7 – April 20 – Board candidates questions submission period
  • April 21 – April 30 – Board candidates answer questions
  • May 1 – May 14 – Board voting period
  • May 15–19 – Board vote checking
  • May 20 – Board result announcement goal

In addition to the Board elections, we will also soon be holding elections for the following roles:

  • Funds Dissemination Committee (FDC)
    • There are five positions being filled. More information about this election will be available on Meta-Wiki.
  • Funds Dissemination Committee Ombudsperson (Ombuds)
    • One position is being filled. More information about this election will be available on Meta-Wiki.

Please note that this year the Board of Trustees elections will be held before the FDC and Ombuds elections. Candidates who are not elected to the Board are explicitly permitted and encouraged to submit themselves as candidates to the FDC or Ombuds positions after the results of the Board elections are announced.

More information on this year's elections can be found on Meta-Wiki. Any questions related to the election can be posted on the election talk page on Meta-Wiki, or sent to the election committee's mailing list, board-elections(at)wikimedia.org.

On behalf of the Election Committee,
Katie Chan, Chair, Wikimedia Foundation Elections Committee
Joe Sutherland, Community Advocate, Wikimedia Foundation

Posted by MediaWiki message delivery on behalf of the Wikimedia Foundation Elections Committee, 03:36, 7 April 2017 (UTC) • Please help translate to your languageGet help

Useful resources on structured data on Congress

Hi everyone,

I'm new to the Wikimedia community but am attending an edit-a-thon at the Library of Congress and wanted to share some possible resources with you.

I coordinate the Congressional Data Coalition, which is focused on making legislative information available to the public. Our website is here.

One thing we have done is gathered a list of structured data (both in bulk and via API) of information about Congress. It includes the chairs/ranking members of all committee, photos of all members of congress, legislation going back decades, enacted bills going back centuries, roll call votes, and much more. You can find my constantly-updating list at this hackpad page. I also publish all recent Congressional Research Service reports here.

Considering the volume of information about Congress that is regularly updated on wikipedia pages, it may make sense to automatically pull that information. For example, you could pull the official photos of all members of Congress, or all of the members of a committee, and update it automatically whenever it changes.

Happy to chat about this more. Thanks!

Daniel  – The preceding unsigned comment was added by Luminousenchiladas (talk • contribs) at 18:44, 7 April 2017‎ (UTC).[reply]

Hi Daniel - this sounds great. Is this data essentially public domain, so we don't have to worry about copyright (wikidata is supposed to be CC-0)? We have a number of properties that seem relevant to what you are offering - the basic image (P18) for photos, for example. If every member of congress does not currently have an english wikipedia page you may have to create a new item in wikidata for each, either way we need to link your record to the wikidata one. You might want to (or have somebody else) propose a specific property to link your identifiers with wikidata ids. ArthurPSmith (talk) 19:01, 7 April 2017 (UTC)[reply]
Every member of Congress back to at least the 1970s already has a Wikidata item (I suspect it's complete even further back than that, but that's all I've verified so far). US Congress Bio ID (P1157) already exists, and is currently set for over 12,000 people. So as long as a data-source can be cross-referenced with that, it should be fairly simple to import, at least in terms of simple biographical information, and positions held (though I suspect many of the committee positions themselves would need to be created as separate items first). I'm not sure what the Wikidata position is regarding legislation — do we actually want an item for every Bill in every jurisdiction? I suspect not, though I'd be happy to be wrong on that! Even for significant bills that are included, I'm not sure there's been any/much thought yet on whether / how to record how individual politicians voted on those. --Oravrattas (talk) 07:25, 8 April 2017 (UTC)[reply]

Subsection about modeling legislative bodies in Wikidata

RELATED: I have a bigger question for the Wikidata community - Do we have a good example in Wikidata of modeling all the committees and subcommittees of a legislative body? (I was at yesterday's edit-a-thon in Washington DC, where I met Daniel @Luminousenchiladas: and chatted about Wikidata, and can vouch for the usefulness of his site.) However, we noticed that the US House and Senate committees and subcommittees that had Wikidata items had no properties that fully captured their relationships within Congress. I took a look at the en.wp and Wikidata entries for UK government and EU parliament, and found they are no better. What is the best built-out national legislature in Wikidata that we can use as an exemplar? Thanks. (Pinging: @econterms, Slowking4: ) -- Fuzheado (talk) 11:38, 8 April 2017 (UTC)[reply]

hmmm, i don't think there is one that has enitre information but I could start working on some of them.MechQuester (talk) 04:19, 9 April 2017 (UTC)[reply]
I'm interested to follow up. My local chapter, Wikimedia DC, has had events with the Cato Institute to help include and standardize legislation references on Wikimedia. I do not think all bills deserve a Wikidata item. It would be good to get official legislative committees into Wikidata, and I don't know how it's been done. And, more my speed to make sure all Congressional Research Service reports are in Wikidata. They are valuable and reliable on certain important topics for which it is hard to find other references. -- econterms (talk) 20:02, 11 April 2017 (UTC)[reply]
yes, if we had any structured data about legislatures, that would be a useful model. i see there was one editor interested in executive orders, but that is a small subset of government publications available. we may be looking to import what data we have about US congress. Slowking4 (talk) 03:35, 12 April 2017 (UTC)[reply]
I don't see a reason why a specific bill wouldn't deserve a Wikidata item. Bills are important documents and it's useful to be able to query all bills that a congressperson authored. ChristianKl (talk) 13:41, 12 April 2017 (UTC)[reply]

Is it possible to identify the terms for "disambiguation" in different languages?

Is it possible to identify the terms for disambiguation in different languages (e.g. Spanish desambiguación, French homonymie, German Begriffsklärung...), so that a new disambiguation page for a word in a specific Wikipedia, marked as such, will be added to existing ones in Wikidata automatically? At the moment, they need to be added manually (at least in case of German, but I think it's the same for other languages). --KnightMove (talk) 18:51, 7 April 2017 (UTC)[reply]

I'm not sure if is what you ask, but disambiguation page in every wiki include the magic word __DISAMBIG__ (more info on mediawiki.org). So is very easy detect what is a disambiguation and what is not a disambiguation. We have also a script that show if sitelink in an item are disambiguation or not.
As far as I can see, no disambiguation page in German or English Wikipedia contains __DISAMBIG__ - anyway, my question is about automated identification. Assume an English page Xxx (disambiguation) with counterparts in some other languages, sharing an entry in Wikidata. When I create a German Xxx (Begriffsklärung), I'd like it to be added automatically to that Wikidata entry - without a separate one being created. Is this possible? --KnightMove (talk) 09:41, 8 April 2017 (UTC)[reply]
 Comment Every disambiguation uses __DISAMBIG__ by using the template. --Bigbossfarin (talk) 10:28, 8 April 2017 (UTC)[reply]

Probably misspelled taxon names

Because we talk about quality judging elsewhere: Batch #234 run by QuickStatements did not cite any reference as requested by Wikidata:Bots and introduced at least more than 200 misspelled values for taxon name (P225) (e.g. Ipomoea pes-caprae (Q28935685), Carex halleriana (Q28934858), ...). The batch was commanded by Magnus Manske, operator of User:QuickStatementsBot too. Resolving the issue (mapping a misspelled taxon name to a real one) without a reference (aka a reason why a item was created) is hard. It involves guessing or knowledge and it's a waste of time of human ressources (in this case of mine). Did we (as Wikidata) learned something from cases like the Tamawashi-incident, a massive tool misuse? --Succu (talk) 21:33, 8 April 2017 (UTC) PS: Not a single item I checked until now had a matching Wildflowers of Israel ID (P3746). --Succu (talk) 21:45, 8 April 2017 (UTC)[reply]

63.143.226.149

Here is this IP again with the addition of [ethnic group-america] to items. MechQuester (talk) 02:53, 8 April 2017 (UTC)[reply]

At this rate, the page is going to be unreadable. And it defeats the purpose of the said item. PokestarFan (talkcontribsSULBlock logUser rights logUser rights) 17:49, 8 April 2017 (UTC)[reply]

I'd say yes. - Brya (talk) 13:37, 9 April 2017 (UTC)[reply]
Done and protected already. MechQuester (talk) 00:01, 10 April 2017 (UTC)[reply]
Yes. --Succu (talk) 06:54, 10 April 2017 (UTC)[reply]
BTW: More of him #Advice needed, tools broken for lists of 1000 articles every Wikipedia should have. --Succu (talk) 21:34, 10 April 2017 (UTC)[reply]

QuickStatements - references

I happen to think that entries into wikidata should be supported by sources as described in Help:Sources. But neither the standard version of QuickStatements ([7]) nor the niosh fork seem to allow to add the full array of necessary entries. (Cf. the related, though not identical issues 52, 46 or 31.) I experimented a little bit with https://tools.wmflabs.org/quickstatements/ but I didn't succeed. I'm wondering whether in principle it would be possible to add the full array of entries (title, date, accessdate, author, editor, publisher ...) and if so, if anybody could provide me with a recipe? 123 (talk) 00:42, 9 April 2017 (UTC)[reply]

Run the newest version and use the syntax from the original version: Each statement can be followed by an unlimited number of "source pairs" of source property TAB value. I can confirm it works. Matěj Suchánek (talk) 08:25, 9 April 2017 (UTC)[reply]
In the case of printed sources, or sources where the editor wants to give a more complete and permanent reference than just a URL, the editor would use the stated in (P248) property. Some information that would differ among the various citations to the source, such as the page number(s), would be contained in the item that has a statement citing the source. But other information about the source, such as the title, author(s), publisher, publication date, etc., would be contained in the item describing the source. So when using stated in (P248) it's going to be necessary to search to see if the item for the source already exists, and if not, create it, before the source can be cited. Jc3s5h (talk) 13:47, 9 April 2017 (UTC)[reply]
Thanks, this helps: I can now pinpoint the problem somewhat better. I tried to include a title (as string: S1476 "Some Title" or with an item: S1476 World Economic Outlook (Q8035662)). This gives me always an error. Author works if I use an item, but not with strings. (It should be possible to include titles and authors as strings, as surely not every article, and probably not every author merits an item.) 123 (talk) 17:32, 9 April 2017 (UTC)[reply]
Actually, this was just discussed on this page at Wikidata:Project chat#Scientific papers - Author's items. As I read it, the consensus was that if a work is cited to support a claim, that creates a structural need to create an item for the author. Jc3s5h (talk) 18:23, 9 April 2017 (UTC)[reply]
You should read more carefully: For a monolingual string, prefix it with the language and a colon, e.g. en:"Some text". This applies to title (P1476). Matěj Suchánek (talk) 18:46, 9 April 2017 (UTC)[reply]
Thanks a lot. This way titles work. (Authors obviously need an item.) 123 (talk) 19:28, 9 April 2017 (UTC)[reply]

Should we interwiki them? Black-red coalition includes hypothetical improbable coalition between en:CDU/CSU and The Left. Futhermore de:Schwarz-rote Koalition article includes Austrian political coalition. --Ticgame (talk) 05:07, 9 April 2017 (UTC)[reply]

I believe the geographical coverage difference is enough to warrant two separate items unless the former article talks about Austrian politics as well. Mahir256 (talk) 23:20, 10 April 2017 (UTC)[reply]

Duplicated items - Q28208784 and Q11737225

Both items about Lake Nyos disaster. Please delete one.

✓ Done. MechQuester (talk) 00:00, 10 April 2017 (UTC)[reply]

Advice needed, tools broken for lists of 1000 articles every Wikipedia should have

In Interlingua Wikipedia there are the pages

Three observations:

  1. The first was linked with meta:List of articles every Wikipedia should have - User:MechQuester killed the connection [8] the connection was restored [9] MechQuester killed it again [10].
  2. MechQuester removed all 1000 article connections, breaking ListeriaBot maintained tracking tools.
  3. User:Eurodyne protected the page [11] /Excessive vandalism ([Edit=Allow only autoconfirmed users] (indefinite)))/

What Eurodyne refers to with "Excessive vandalism"? The IP edits, or those by MechQuester, or anything else? How can the old state be restored, we need it in iawiki to progress with 1) item name translation (setting labels) 2) finding images if missing 3) translating P31, P279 and P361 target item names 4) tracking article creation progress.

The goal was to have stubs ready for all top 1000 articles by end of April. The goal is now in danger. Please advice! Also how it is possible to track the articles automated, an item could be removed and another added, without ListeriaBot, how does iawiki get notified about a newly missing item, in case for the new one there is no article? 85.180.37.42 06:26, 10 April 2017 (UTC)[reply]

Hey there. I know that every those 1,000 articles are important to every wiki. However, i don't think it is necessarily important to add every single one to them. in fact, the article. MechQuester (talk) 13:10, 10 April 2017 (UTC)[reply]
It absolutely does not matter what you think about necessity, does it? This is Wikidata, and Wikidata is made to describe things. The meta-list is a reality, a real list and it has list items. And policy that allowed you to remove facts from Wikidata? 85.180.50.240 19:44, 10 April 2017 (UTC)[reply]

Suggestion: why not add catalog (P972) = Wikipedia:List of articles all languages should have (Q5460604) on each of the thousand items, in the same way that Gerard has done for the items of interest to the Black Lunch Table ?

Then it's an easy matter to query for which of those items don't have articles in any particular wiki. Jheald (talk) 13:06, 10 April 2017 (UTC)[reply]

I am quite happy to make a catalog and set this up. What page should I use for the source of the thousand ? Thanks, GerardM (talk) 17:07, 10 April 2017 (UTC)

@Jheald, GerardM: Thank you for your positive cooperation and offer for help!!! Source: https://meta.wikimedia.org/wiki/List_of_articles_every_Wikipedia_should_have/Itemlist . Can you also re-install the link to ia:Appendice:Lista de 1000 articulos que cata Wikipedia debe continer on Q5460604. The Listeria code in the two articles can be adjusted later. 85.180.50.240 19:40, 10 April 2017 (UTC)[reply]

I have added all 1000 to a catalog. You can change your listeria list now. Thanks, GerardM (talk) 06:27, 11 April 2017 (UTC)[reply]

@GerardM: Thanks a lot. Edits look good, but http://tinyurl DOT com/llj2a42 " SELECT ?item { ?item wdt:P972 wd:Q5460604 }" does not work, it finds no results. If I try the equally structured http://tinyurl DOT com/mc3nmja " SELECT ?item { ?item wdt:P92 wd:Q428 } " it finds Q12536 . You or @Jheald:, any idea? Some delay? [spam filter prevents link to tinyurl]85.180.52.199 13:25, 11 April 2017 (UTC)[reply]

@GerardM, Jheald: - the edits all linked the catalog claim to Q29295845, which is for absent items, correct is Q5460604. 77.179.204.253 14:15, 11 April 2017 (UTC)[reply]

No, it is for all the 1000 items. Listeria will show what exists and what not. Thanks, GerardM (talk) 16:00, 11 April 2017 (UTC)

@GerardM: - no. Q29295845 according to the links to meta and iawiki and according to the labels (ru, en, it) is for missing items. And Q5460604 as mentioned in the thread intro is for the the meta-1000-list. @Infovarius: thanks for Russian fix! @ValterVB: thanks for Italian fix. GerardM, you changed the en-label [12], but that was turning it to be wrong. What now with all the wrong incoming claims? Only 222 items are correct, and as of now Wikidata:List of 1000 articles every Wikipedia should have only lists 222 items. 78.55.15.204 21:11, 11 April 2017 (UTC)[reply]
A list is a list .. it is a "Wikimedia list article" I changed the name and the one that is about single items has 1000 articles. Change the query and it will be fine. Thanks, GerardM (talk) 04:42, 12 April 2017 (UTC)[reply]
@GerardM: The anon's right. Please, change the statements to the correct item. – Máté (talk) 05:23, 12 April 2017 (UTC)[reply]
I am changing the statements to the right target (Q29295845->Q5460604). Infovarius (talk) 14:40, 12 April 2017 (UTC)[reply]

GerardM, you are talking nonsense. It is list. Both are a list. But not every list, is the list of the top 1000. You included 1000 articles in "absent". But the absent lists are Wikipedia-edition-specific. Complete rubbish. 85.180.174.34 16:10, 12 April 2017 (UTC)[reply]

Subclass

I think these statements are wrong, could someone fix them (keeping in mind that there might be many in the same case) or tell me whether they are actually OK?

Thanks a lot! Syced (talk) 11:42, 10 April 2017 (UTC)[reply]

Looks like there are about 15 numbers defined as subclasses of something. Syced (talk) 11:52, 10 April 2017 (UTC)[reply]
By the way, I am also rather uncomfortable with stock market index (Q223371) being a sub-sub-class of number (Q11563). Syced (talk) 11:57, 10 April 2017 (UTC)[reply]
Thank you for remarks. Added criterion used (P1013) orders of magnitude (Q1191085). -0.000001 uses other criterion used (P1013). About set/subsets: 0.000001 is one of the representations (views, forms and so on) of a number. Other forms: 0.000 001; 1/1 000 000; 1/1000000; 0.000001; 0,000001; 0,000 001; .000001; .000 , 001; 1000⁻²; 1x10⁻⁶; ... --Fractaler (talk) 13:15, 11 April 2017 (UTC)[reply]

Wikidata weekly summary #255

P123 (publisher) -- German/French problem

publisher (P123) has as description: "organization responsible for publishing books, periodicals, games or software". As German translation "Verlag" is used and the description is: "Namen des Medienunternehmens, das die Publikation auf den Markt gebracht hat". (Literally: "Name of the media company that has published the publication to the market".) If one looks at the actual use of the property in references[13] one finds that there hardly figures any organisation which in German would be called a "Verlag". Actually, while the English description of P123 would need only little change to accommodate the actual use, the item publishing company (Q2085381) doesn't fit, as many of the entries are no "media companies". The wikidata module in the German wikipedia uses P123 entries in references and precedes them with "Verlag", which doesn't make any sense in most cases. I'm just wondering whether there is some way to rectify the situation. 123 (talk) 17:06, 10 April 2017 (UTC)[reply]

And if you look at the constraints on P123 you will note the publisher can be an organization or a human. The German translation of the description is clearly too restrictive. But it seems there may also be a problem with the way people are using this property in references. Do you have some specific examples where it looks wrong to you? ArthurPSmith (talk) 13:28, 11 April 2017 (UTC)[reply]
Well, in the German wikipedia basically all entries with the property P123 result in something which looks (actually: is) wrong. Only 61 entries from 52155 use an item which is an instance of publishing company (Q2085381) (to be a publisher in the sense of Q2085381 would be a necessary but not sufficient condition to qualify as a "Verlag") and even under these 61 7 actually do not give a "Verlag". For the rest: the United Nations, Rostock District, BBC, Statistics Belgium, Adobe Systems, Aargau, Department of Defense, Microsoft, World Health Organization, Bochum, oronto, International Astronomical Union, Bad Doberan, erbo-Croatian, Facebook, Wikimedia Foundation and so on are all no "Verlag". From a German perspective the problem is not so much that the description is too restrictive (it is adequate as description of a Verlag in the context), but that the translation of publisher with "Verlag" is wrong. The deeper problem is that the English and German ontology seem to differ. As a result there is no interwiki link from de:Verlag (and fr:Maison d'édition, pt:Editora ...) to the English wikipedia! (A link to en:Publishing would be as wrong as is the link from en:Publishing to de:Edition: "Edition" as concept is much narrower than "Publishing".) Most of the entries for P123 would qualify for what in the context of cataloging in German is called Körperschaft as de:Urheber (originator, creator) or initiator/causer of a publication. ("Urheber" again being an important German concept without interwiki link into the English Wikipedia.)
In an ideal world, from a German perspective (and French and some others) there would be at least four properties for the "Urheber" or initiator/creator of a reference: author (P50), editor (P98), publisher (P123) and a new one, called in German "Verlag" (in French "Maison d'édition", in Portuguese "Editora" ... and in English perhaps "Publishing house").
* author (P50) for, well, authors.
* editor (P98) for editors according to the description given: "editor of a compiled work such as a book or academic journal" (at the moment for most of the entries what is given are not editors but the organisations responsible for the publication, and P98 should therefore in these cases be replaced by P123).
* publisher (P123) should in German get a different name (like "Körperschaft" and a corresponding description); the English description could be somewhat wider on the one hand but exclude publishing houses and the like on the other hand.
* P|xxxx in German Verlag, in English perhaps publishing house; would correspond to item publishing company (Q2085381)
The hole point is that the concept "publisher" as used now, lumps together two quite different activities: The actual production of content and/or ultimate responsibility for the publication of some work through some organisation (like the Worlbank producing and publishing data, the UNDP producing and publishing its reports ...) and the copy editing, layouting, printing, selling etc. of published work. Two examples (one from a library record, one from academic writing) which illustrate the difference:
*Title: Human development report ... By: publ. for the United Nations Development Programme (UNDP) Place: Oxford [u.a.] Publisher: Oxford Univ. Press
*U.S. Department of Commerce, Bureau of the Census (1975). Historical Statistics of the United States, Colonial Times to 1970. Washington, DC: U.S. Government Printing Office.
Most of the entries under P123 give organisations like the UNDP or the U.S. Department of Commerce ... A very few give entities like Oxford Univ. Press or the U.S. Government Printing Office. Both categories should be distinguished. 123 (talk) 18:57, 11 April 2017 (UTC)[reply]
123 - does "copy editing, layouting, printing, selling" even apply for information published on the world wide web? Certainly the "printing" and "selling" parts do not. At least in English, the verb "publish" means the act of making something public, or available for distribution to the public (whether for sale or not) and doesn't require any of the things you mention. So "publisher" should be the actor that performs that act of publishing for the work in question. I think the German verb "veröffentlichen" might be closest to the English meaning of publish as used here - is there a German noun that captures that meaning similarly for "publisher"? ArthurPSmith (talk) 16:30, 12 April 2017 (UTC)[reply]

Wikidata item quality labeling drive

Is Wikidata high quality? What items are due for promotion to the showcase? Answering these questions would require reviewing millions of items on a regular basis and that would take far too long. So we're training machine learning models to evaluate the quality of items in Wikidata automatically. In order to train these machine learning models, we need to label a bunch of items by their quality level. I'm posting to invite you to join our working group.

We're trying to get ~5,000 items labeled. We'll use this labeled data to train a machine learning model for m:ORES and use it to categorize the rest of items in Wikidata, look for trends & coverage biases, etc. We've built similar quality models for English, French, and Russian Wikipedia and they have been used to do a bunch of cool things (e.g. content coverage dynamics, helping students write articles, and helping WikiProjects prioritize re-assessments). So, we think this'll be a great thing for Wikidata too.

If you want to help us train the model, see our labeling campaign information page and sign up list.

-- Glorian WD, EpochFail, and Ladsgroup 19:30, 10 April 2017 (UTC)[reply]

Is the stats page supposed to be as it is now? Just plain text? --Micru (talk) 16:49, 11 April 2017 (UTC)[reply]
Micru, yeah, it should be updated as more items have been labeled :) --Glorian WD (talk) 19:33, 11 April 2017 (UTC)[reply]

Glorian WD, EpochFail, and Ladsgroup, how about using the 1000 items every Wikipedia should have? They are from different areas of interest, and several Wikipedias work on having articles for all of them. Russian has it completed. 78.55.15.204 21:17, 11 April 2017 (UTC)[reply]

Fusionproblems

Can someone fusion de:Homosexualität in Portugal (Q13427064) with en:LGBT rights in Portugal (Q2007877) ? 92.76.106.150 19:56, 10 April 2017 (UTC)[reply]

Until the Spanish articles are merged or one of them is deleted (notwithstanding the differences between 'LGBT rights' and 'homosexuality'), this would not be appropriate. Mahir256 (talk) 23:20, 10 April 2017 (UTC)[reply]

Help with Perl

Could anyone please check if the Perl format of DBC author ID (P3846) is correct? It's supposed to say "14 digit number, first 2 '87', then 12 others". Jonathan Groß (talk) 09:38, 11 April 2017 (UTC)[reply]

Is it always a 14 digit number? In that case, it should be 87\d{12}. Jsamwrites (talk) 10:57, 11 April 2017 (UTC)[reply]
I believe it is. Thank you! Jonathan Groß (talk) 11:03, 11 April 2017 (UTC)[reply]

Who else is interested in item datasets?

I find this proposal by Jheald quite interesting. It would be more practical to work with sets of items than with individual items. Even for maintenance, it would be easier to watch a tree of items and see which items have been added or removed to that tree. I find that, due to the nature of Wikidata, the watchlist is not enough to maintain large amount of items. Is there anyone else interested in discussing this?--Micru (talk) 16:56, 11 April 2017 (UTC)[reply]

I'm not sure what you're proposing exactly - a watchlist computed from a SPARQL query perhaps? But yes this seems useful. I maintain an occasional watch over the 4000+ regular nuclides in wikidata where this sort of thing would definitely be helpful. ArthurPSmith (talk) 12:34, 12 April 2017 (UTC)[reply]

Read-only mode for 20 to 30 minutes on 19 April and 3 May

MediaWiki message delivery (talk) 17:34, 11 April 2017 (UTC)[reply]

This work will cause long-running scripts at Wikidata to stop. Please plan to re-start scripts and check bots once the sites are online again. Whatamidoing (WMF) (talk) 21:05, 11 April 2017 (UTC)[reply]

SPARQL federation - more of the same

Hi!

I've added more endpoint to SPARQL federation whitelist, including attribution-licensed ones. Please see the full list in the User Manual. All endpoints are acknowledged at WDQS Licensing page.

You are welcome to nominate new endpoints at Wikidata:SPARQL federation input. I've made some cleanups and edits there to make nominating easier, hopefully that helps. Examples and links to any materials showing how to integrate data between endpoints are very welcome too.

--Smalyshev (WMF) (talk) 19:43, 11 April 2017 (UTC)[reply]

Please, stop this vandal Briya!

Moved to Wikidata:Administrators' noticeboard

Can anyone here help sort out presumed IP ban for ongoing Wikidata hackathon in Suriname?

Please see this message to wikidata-l for the details I have so far. Thanks, --Daniel Mietchen (talk) 21:29, 11 April 2017 (UTC)[reply]

@Daniel Mietchen: To lift the account throttle, please use the IRC channel #wikimedia-tech on freenode to contact a system administrator.--Jasper Deng (talk) 21:44, 11 April 2017 (UTC)[reply]
Thanks. I did that — so far no response. --Daniel Mietchen (talk) 22:01, 11 April 2017 (UTC)[reply]
I also tried phab:T162751. --Daniel Mietchen (talk) 22:24, 11 April 2017 (UTC)[reply]
After a while, I got some helpful responses via Phabricator and the wikimedia-tech IRC, but then the hackathon crew did not respond to me any more. In any case, I think we should have better mechanisms to deal with problems arising during ongoing Wikidata-centric events. --Daniel Mietchen (talk) 23:17, 11 April 2017 (UTC)[reply]
this is an ongoing problem, where vandal fighting is valued more than collaboration with new users. we have various techniques to route around the filters and throttles, but a newbie would have no clue. Slowking4 (talk) 03:28, 12 April 2017 (UTC)[reply]
@Daniel Mietchen: Anyone organising a hackathon should be organising for one or two experienced/trusted users to have "account creator" rights for the duration of the hack, OR to have IP addresses isolated from the throttle restriction. I am not sure whether local 'crats here can allocate creator rights, or whether we rely on stewards from m:SRP, either way it would normally need a discussion somewhere. [Stewards can always allocate that right in an emergency at their discretion]. Noting that anyone with advanced rights (sysadmin and above) at wikis will get that ability bundled into their rights anyway (per Special:ListGroupRights). I would think that mw:Hackathons should cover this topic matter and I have popped a note on the talk page to have it considered.
@Billinghurst: The only ones with account creator(-equivalent) rights here are the sysops, we don't have any provisions for otherwise doling out the right.--Jasper Deng (talk) 06:34, 12 April 2017 (UTC)[reply]
@Jasper Deng: Pretty certain that it is part of the default account type for all wikis (you can check by looking at an account via Special:UserRights and if it is a greyed out option, then it is available to someone to allocate), as such stewards can do it for any wiki. So for us it is just the process of saying YesY please assign date-to-date. For us it is being certain that the user is trusted with email account details (need for creations) and able to work within the boundaries of blacklists and anti-spoof.  — billinghurst sDrewth 07:53, 12 April 2017 (UTC)[reply]
But accounts are global, they can be created on any project.--Ymblanter (talk) 07:58, 12 April 2017 (UTC)[reply]
@Ymblanter: Yes, the impacts are global; as with any admin at any wiki when they create accounts (stated that above); however, if we wish to allocate that right to a person (the right has to be given at a wiki), stewards would expect a local conversation if we are asking them to undertake that.  — billinghurst sDrewth 08:33, 12 April 2017 (UTC)[reply]
@billinghurst: Sure, my point was that since we do not have account creator flag here (and we would need an RfC to create it - may be someone can start it), a legit workaround seems to be having a couple of account creators on another project in the team.--Ymblanter (talk) 08:48, 12 April 2017 (UTC)[reply]
I don't think that you need an RfC to allocate the right on a temporary needs basis. If someone wants it, they ask here ahead of requirement, it sits open for up to a week, and is approved or not. And Ymblanter, I don't disagree that a conversation and rights allocation can take any place. A user could just as easily have the conversation at m:SRGP and have stewards make a decision. However, if it is important to this community, then owning the conversation and solution is better than leaving it to stewards to make up their minds in their time.  — billinghurst sDrewth 08:58, 12 April 2017 (UTC)[reply]
@billinghurst: But technically I (as a crat) can not assign account creation rights. The panel just says "rights you can not assign". I assume it is either not available or only available to stewards. This can be changes by holding an RfC and, if it is successful, filing a Phabricator request, but I do not see how it can be changed otherwise.--Ymblanter (talk) 09:59, 12 April 2017 (UTC)[reply]
Ah, gotcha. Completely right, they would require a consensus for a phabricator; again not certain whether an RfC is required or just the evidence of the conversation.  — billinghurst sDrewth 12:10, 12 April 2017 (UTC)[reply]
If "a phabricator" means "a task in Phabricator", general documentation for consensus requirements for configuration changes is available. --AKlapper (WMF) (talk) 19:50, 12 April 2017 (UTC)[reply]

Coordinates

On the main site I have a hidden category named: Category:Coordinates not on Wikidata. How might I go about fixing this? Semmendinger (talk) 23:22, 11 April 2017 (UTC)[reply]

on a wikipedia article, go to the left side and look for "wikidata item". click on it. Go down a bit and look for the "+add" all by itself in white. Click on it and add coordinates (if it is not provided already). Then add. MechQuester (talk) 23:45, 11 April 2017 (UTC)[reply]
I must be blind as I don't see that option anywhere on the left side bar in either the article or editing page. It is however showing up on other pages just not the one I want to link.Semmendinger (talk) 23:53, 11 April 2017 (UTC)[reply]
Mind if I ask for the wikipedia article? If there isn't one, I'll create one. MechQuester (talk) 23:57, 11 April 2017 (UTC)[reply]
Thanks Mech, I think I just created one successfully, I don't really know how WikiData works. The Wikipedia article is at this link. But I think I just created one here? Semmendinger (talk) 00:00, 12 April 2017 (UTC)[reply]
Fantastic creation @Semmendinger:!. Now to the article. Since the library system has 2 branches, I would suggest imputing 2 sets of coordinates. I have added the 2nd location from Palmer location to the item. MechQuester (talk) 02:22, 12 April 2017 (UTC)[reply]
Great point - appreciate your help! This will go a whole lot smoother on the next data entries now! :) Semmendinger (talk) 02:36, 12 April 2017 (UTC)[reply]
@MechQuester: value in adding subject named as (P1810) as qualifiers to each to differentiate?  — billinghurst sDrewth 05:53, 12 April 2017 (UTC)[reply]

Please, stop cross wiki vandalism by Sintakzo!

Moved to Wikidata:Administrators' noticeboard

Letters and Correspondence

I welcome advice on the difference between letter (Q133492) and correspondence (Q1784733) and when it is appropriate to use them. correspondence (Q1784733) seems to be used both for individual letters such as Franklin D. Roosevelt to Winston Churchill (March 29, 1941) (Q23533314) and Letter from Alexander Henry Haliday to John Curtis undated (Q19096518) as well as collections of correspondence such as Letters of Charles Lamb (Q6533761) and The Letters of William Blake (Q19092346). correspondence (Q1784733) is also attached to people, such as Pavel Kohout (Q163557) and Mademoiselle Aïssé (Q275947): it seems that this property is being stretched. It would be nice to have letter (Q133492) used for each individual piece of correspondence, and correspondence (Q1784733) attached to collections of correspondence, or works of fiction written in the form of correspondence. Thanks in advance for any help, MartinPoulter (talk) 16:41, 12 April 2017 (UTC)[reply]

Kingdom of Aksum not P31=kingdom?

[14] ? 78.48.218.9 17:04, 12 April 2017 (UTC)[reply]

It should have both historical country (Q3024240)  View with Reasonator View with SQID and kingdom (Q28050776)  View with Reasonator View with SQID if you want the latter. Having end time (P582) View with SQID on the latter and/or dissolved, abolished or demolished date (P576) View with SQID on the whole item won't hurt also. --Laboramus (talk) 18:17, 12 April 2017 (UTC)[reply]