Wikidata:Project chat: Difference between revisions

Content deleted Content added

Inline

Revision as of 16:53, 17 February 2020

Wikidata project chat

Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Requests for deletions can be made here. Merging instructions can be found here.
IRC channel: #wikidata^connect
Wikidata Telegram group

Start a new discussion

Edit

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/07.

Label/alias in mul

Is it possible to add label and aliases with 'mul' as a language? In some cases there are names, symbols etc. that are correct for many languages (like symbols of the elements for example) and it's quite tedious to add such things to many languages as having the same aliases in many languages does not help in searching etc. Wostr (talk) 15:09, 22 January 2020 (UTC)[reply]

Slightly OT, years ago I was on the language tag review and related RFC-update lists, exploring mul + und issues (after en-GB surviced a basic plausibility check) can be fascinating. On YouTube I gave up to find a tag for Kobaian. Is und-Latn (example) a thing? After all you would at least know the script. –84.46.53.84 02:16, 28 January 2020 (UTC)[reply]

Previous discussions: Wikidata:Project_chat/Archive/2013/07#Global_labels, Wikidata:Project_chat/Archive/2019/06#Multilanguage_label has ended with nothing. --Infovarius (talk) 15:57, 29 January 2020 (UTC)[reply]

Given that there's support and no pushback, maybe we need a Phabricator ticket? ChristianKl ❪✉❫ 08:52, 3 February 2020 (UTC)[reply]

Please make sure to get this right per RFC 5646 section 4.1 clause 5.
I just saw that enwiki has mis for Kobaian, and zxx non-linguistic can be also interesting. In one of the two archived discussions wikilinked above you had a mul-Latn, that's not the same as und-Latn, there is a SHOULD NOT for mul in BCP 47 = RFC 5646. –84.46.52.96 05:17, 4 February 2020 (UTC)[reply]

There's a SHOULD NOT but I don't think it applies to our planned usage. "This subtag SHOULD NOT be used when a list of languages or individual tags for each content element can be used instead." A list of languages is not possible for our use-case. We actually mean all languages and not a subset that could be expressed by a list. I think we comply with the recommendations in that document. If you think we don't please point to the specific portion that you think get violated by the planned usage.

zxx seems to be a good idea for special unicode characters. ChristianKl ❪✉❫ 17:43, 10 February 2020 (UTC)[reply]

All fine if you checked it, the experts on phab: can sort it out. @Cbrescia: My comment about shp in January was misleading, if MediaWiki now tries to cover all plausible language tags. –84.46.52.252 11:36, 11 February 2020 (UTC)[reply]

Academic journal with different series

Can anyone please help me with this.

For instance this article appeared in The Zoologist 1900, in the 4th series, volume 4, etc. I can add volume 4, but I don't find how I can add that "4th series".

Thanks in advance, --Dick Bos (talk) 12:01, 29 January 2020 (UTC)[reply]

Interesting, it's described at en:The Zoologist. It would be possible to make a separate item for each series, e.g., "The Zoologist series 1", but I'm not sure if that's best. Ghouston (talk) 12:08, 29 January 2020 (UTC)[reply]

There are journals named in that way, like Deep-Sea Research. Part 1: Oceanographic Research Papers (Q15765364) or Journal of Polymer Science Part A (Q2411132), although it's not exactly the same. My inclination would be to create a separate item for each series, and declare it to be a scientific journal (Q5633421) in its own right. The "parent" item The Zoologist (Q7776911) would also remain a scientific journal (Q5633421), and they could all be linked with has part(s) (P527) and part of (P361). Perhaps not perfectly logical, but is there anything better? Ghouston (talk) 22:13, 29 January 2020 (UTC)[reply]

Yes. I noticed this about 18 months ago, when doing some reconciliation/matching work for some of the journals available through the Bioheritage Diversity Library. I did try to ask at WikiProject Periodicals at the time (see archived threads: Journal splits and Journals that change their name, which include some more examples), but got no real feedback. It's an area where we could do with a much firmer style guide. As far as I can see, we seem to be very inconsistent, both with journals being split into multiple parts, and for journals starting "new series", with the volume number being re-set to 1. It also doesn't help that some different external IDs can be inconsistent, sometimes splitting the journal sometimes not (particularly for journals that undergo name changes, but may or may not restart their numbering). I don't have an answer for this also when some sources/wikis wants to say that a journal was "original founded in 1836", and some wikis may have an overall article for its entire history since that time, but it may have gone through a lot of new series and/or part reconfigurations since then. Jheald (talk) 10:26, 30 January 2020 (UTC)[reply]

There's also the angle of what is most helpful for people wanting to cite the journal (eg from wiki-based templates), and/or analyse data about journals. Is it helpful to be able to cite <Overall title> with additional parameter <4th series>, or do we require them to specify <Overall title, 4th series>. Would everyone tend to get it right, either way? Pinging @Andrew Gray: for any thoughts. Jheald (talk) 10:30, 30 January 2020 (UTC)[reply]

Notified participants of WikiProject Periodicals

Citations are a good point. I suppose the way it's cited would depend on which citation style is in use, and it would be nice to be able to generate arbitrary styles from a Wikidata item. In that case, perhaps the series should be a separate property, not mixed up with the journal name. I guess it would be worth looking at how citation software/databases handle it. Ghouston (talk) 00:07, 31 January 2020 (UTC)[reply]

Here's another example, Annals and Magazine of Natural History: Series 1 - 13 [1]. Ghouston (talk) 04:49, 6 February 2020 (UTC)[reply]
en:Template:Cite journal has a field "series", which is described as "series or version: When the source is part of a series, such as a book series or a journal where the issue numbering has restarted." I think a new property should be created for it, maybe called "journal series id" to distinguish it from part of the series (P179). Ghouston (talk) 01:06, 14 February 2020 (UTC)[reply]

Occupation=photographer

Is occupation=photographer only reserved for people who are professional photographers or does it include people who own a camera that that took photos as a hobby and they have images at Wikimedia Commons. --RAN (talk) 15:56, 29 January 2020 (UTC)[reply]

That's a discussion to be had at the talk page of the property. It seems to me that the view that's expressed there is that the property is about the subject's dayjob. ChristianKl ❪✉❫ 16:04, 29 January 2020 (UTC)[reply]

That view was expressed by one user, in 2015. I think it's wrong; equally I don't know where the dividing line should be placed. We use occupation for e.g. suffragettes, for few of whom it was their 'day job'. (And of course, that usage is also questionable). More widely we use it for a range of activist roles, where many described have other day jobs. For me, RAN's example doesn't merit occupation=photographer any more than the idea that we're all cooks since we once made a piece of toast. Wikipedia usefully comments in its Occupation DAB: "Occupation commonly refers to: Occupation or job, one's role in society, often a regular activity performed for payment" - my emphasis. That may be a useful yardstick; certainly wider than day job. --Tagishsimon (talk) 16:16, 29 January 2020 (UTC)[reply]

Not that I at all want a Wikidata item about me, but let me take myself as a middling example. I'm a Commons photographer. I mainly make my living developing software, but I have had photos I've taken used prominently as billboard advertisements, covers of books, in major newspapers such as Ha'aretz and the Seattle Times, and in one book from National Geographic; I've won an award from an architectural organization for my documentation of Mid-Century Modern architecture in Seattle; and I have at least one photo on permanent exhibition in a museum. I suspect that this is probably typical of the more prolific Commons photographers, as is the fact that I mainly make my money elsewhere. We describe H. Ambrose Kiehl (Q38605082) as an "American civil engineer and photographer" and list

⟨ H. Ambrose Kiehl (Q38605082)  

 ⟩ occupation (P106) ⟨ photographer (Q33231)  

 ⟩

; I don't see any sense in which he was more of a photographer than I am, or than a good several dozen Commons photographers are. It seems that if you were going to have an item about me, my work as a photographer is of much broader interest than my work as a software developer. - Jmabel (talk) 17:19, 29 January 2020 (UTC)[reply]

It's not a matter or right or wrong but about how we decide to set the scope of the property. That discussion is better had on the page of the property as it's a place where in future people will look if they want to know. ChristianKl ❪✉❫ 13:06, 30 January 2020 (UTC)[reply]

It comes down to common sense, but sense isn't all that common. All scientists and academics write to communicate, but it would be redundant, frivolous clutter to add writer (Q36180) to every entomologist, art historian, and mathematician. Many people take and publish photographs incidental to other roles (e.g. scientific articles). My rule of thumb is that an occupation is worth adding only if it's a role commonly and consistently associated with the subject. In the case of H. Ambrose Kiehl (Q38605082), given that the University of Washington has a collection dedicated to his photographs, I think it is appropriate to add photographer (Q33231). For people known solely or predominantly from posting photos to Flick or Commons, or who take photographs rarely or incidentally, amateur photographer (Q21694268) might be more appropriate. It is also not mandatory that occupation (P106) be completed at all. -Animalparty (talk) 21:09, 29 January 2020 (UTC)[reply]

Yes, they do have such a collection as a representative example of amateur photography, in no small part because (unlike most amateurs) he took good enough notes so that we know what he photographed. As it says on the page you linked, "The photographs are typical of those found in many family albums of that period and illustrate everyday family life at the turn of the century." - Jmabel (talk) 00:37, 30 January 2020 (UTC)[reply]

Perhaps occupation can be used once somebody has achieved some recognition in the field? Being paid is one form of recognition. Being able to publish an article in a peer-reviewed journal or receiving a prize would be another. I don't see a difficulty with using it on a graduate student, for example. We've even got it set to criminal (Q2159907) for people like John Wilkes Booth (Q180914). Ghouston (talk) 00:51, 30 January 2020 (UTC)[reply]

I think Occupation=amateur photographer (Q21694268) is a good compromise for now. We can always remove them globally in the future, if we make that decision. I want to be able to distinguish the professional photographers from the amateur ones as I am adding in identifiers from the various photographer databases. I will reserve Occupation=photographer for those that have images in museums and those that operated photo studios. We may develop something like Hobby= in the future. --RAN (talk) 05:19, 30 January 2020 (UTC)[reply]

"those that have images in museums and those that operated photo studios" would leave out the bulk of photojournalists working since the end of the film era, since studios as such are no longer common. (Some have work in museums, but many not, I'd guess.) I suspect there is at least one staff photographer for a genuinely major newspaper or magazine who wouldn't meet those criteria. - Jmabel (talk) 05:36, 30 January 2020 (UTC)[reply]

Yes! Sorry for ignoring photojournalists! The database I am working with seems to contain photographers from the 1800s to 1920s. --RAN (talk) 06:01, 1 February 2020 (UTC)[reply]

Perhaps a separate property would be better than creating an item "amateur X" for every occupation X. association football player (Q937857) -> amateur footballer, criminal (Q2159907) -> amateur criminal? But I think that either way it puts too much weight on being paid verses other forms of recognition. Ghouston (talk) 05:48, 30 January 2020 (UTC)[reply]

IMO the broad understanding of occupation (P106), ie as representing occupation (Q12737077) "label applied to a person based on an activity they participate in" is helpful, for queries to be usefully broad and inclusive finding aids. (ie otherwise queries based on P106 would miss out too many people, that probably are wanted). I therefore think User:Jeblad's 2015 proposal to change the scope to "the subject's day-job", ie specifically work (Q6958747), would have been unhelpful, and I am glad it was not taken up. Jheald (talk) 10:10, 30 January 2020 (UTC)[reply]

First; Wikidata or any system that model semantic relations will not work properly if we start to use predicates with dual meaning. From Oxfords Advanced Learners Dictionary (1989):
3 [C] (a) (fml) job; employment: ‘what's your occupation?’ ‘I'm a dancer’ ⚬ Please state your name, age, and occupation. (b) activity that occupies a person's (esp spare) time; pasttime: She has many occupations including gardening and wine-making. ⚬ His favorite occupation is reading.
What some try to do is to use both (a) – your job, and (b) – your hobby in the same statement. That creates a mess. Owning a camera and shooting pictures are usually a hobby, only when you start to put a real effort into it, and you are known as a photographer, then you should be named a photographer.
The template entries using occupation (P106) is now changed from “yrke” (“work”) to “beskjeftigelse” to be somewhat more descriptive for how the property is actually used. The discussions about “yrke” (“work”) has been one of the more contentious debates at nowiki, and resurfacing this discussion might very well end with removal of its use. Jeblad (talk) 12:15, 30 January 2020 (UTC)[reply]

Should having works in Wikisource lead to "occupation:writer" claim?

Currently, every person who has an Author page at wikisource is having the claim "occupation: writer" added to their wikidata page. That doesn't seem right to me. Having had just one or two magazine articles or letters published is not the same thing as being a writer as an occupation. The confusion seems to have chiefly arisen because Wikisource automatically adds Author pages to categories such as "Women writers." Should there somehow be standards for what is an Occupation that means WS categories don't automatically translate into occupations? Levana Taylor (talk) 22:45, 4 February 2020 (UTC)[reply]

We are a bit confused about what qualifies as an "occupation". See the discussion above Wikidata:Project_chat#Occupation=photographer. I suppose a lot of people may write things throughout their lives, like SMS messages to their friends, and we wouldn't consider them writers any more than we'd consider them chefs for cooking their own dinners, even though they may spend quite a bit of time on these things and develop some expertise. How many magazine articles, books, scientific papers, etc., do you need to write before you are a "writer"? In this case, Wikisource has apparently already classified them as writers. Ghouston (talk) 22:52, 4 February 2020 (UTC)[reply]

Yikes, I didn't see that an almost identical discussion had been already started just days ago re: photographer. Okay, so let me clarify: I think general discussion of what is an occupation should be in that thread, and this discussion should question whether it's desirable to automatically translate Wikisource "writer" categories into WD "occupation" statements. Levana Taylor (talk) 23:19, 4 February 2020 (UTC)[reply]

Have you any estimate or hunch about the the false positive ratio in such an exercise? By your lights what % of wikisource authors are not occ=writers? --Tagishsimon (talk) 00:10, 5 February 2020 (UTC)[reply]

I can tell you that for the magazine I'm working on, there are author pages for nearly all the contributors, and I've tried to put a semi-complete list of all their publications on their pages (though I'm not done with the project). That allows me to estimate that about 10% (not more) have only a couple of publications, in most cases only their contributions to this magazine. I don't know what the percentage of occasional authors is for WS overall but it is certain to be far, far less. Levana Taylor (talk) 00:50, 5 February 2020 (UTC)[reply]

Without knowing how "occupation" should be used in Wikidata, it's impossible to say whether copying the entries from Wikisource is a good idea or not, or to say that something is a false positive. Ghouston (talk) 00:57, 5 February 2020 (UTC)[reply]

True! I have moved this section as a subsection of the other discussion. Levana Taylor (talk) 01:05, 5 February 2020 (UTC)[reply]

Thought in favor of separating author from occupation as writer: in the work of some scholars attempting to uncover the underdocumented lives of women in history, a woman writer is a woman who wrote anything, however little, and no matter whether it was published. For such scholars, women who wrote as a profession, or who had a reputation as writers (for example, those whose works circulated in French salons) are of interest in a different way. WD can't capture every nuance, but seems like this is one that could be codified by having only the latter qualify as an occupation. (the former is a member of the category of woman writers, though). Levana Taylor (talk) 01:12, 5 February 2020 (UTC)[reply]

Note to closer, please cut and past a copy of this to talk page of Photographer or add a link to it. --RAN (talk) 03:11, 8 February 2020 (UTC)[reply]
@Levana Taylor: do you mean English wikisource? Do they have speech creators/performers? Because in ru-wikisource we have Category:Speeches (Q7564984) (and in en-ws too as I see) and probably some people only authored speeches, I wouldn't call them "writers". Also we have Category:People by behavior (Q6819158) in which Category:Writers is one of ~100 other occupations... --Infovarius (talk) 11:47, 10 February 2020 (UTC)[reply]

Which country is Puerto Rico in?

.. and then, which values to use for country (P17) and located in the administrative territorial entity (P131)?

There are some lengthy comments by User:The Eloquent Peasant on various talk pages of items about places in Puerto Rico and a few other non-US states, such as United States Virgin Islands (Q11703), Guam (Q16635): Talk:Q44547, Talk:Q11703, Talk:Q16635.

The arguments for not using Q30 seem to be that:

It's not a state of the US,
it's not part of the continental US,
some infobox at some Wikipedia displays it in a way not liked by some users,
the statements were added by an IP in 2013,
and/or, some US politicians think it's not in the US.

I don't quite see how any of this is relevant. --- Jura 07:36, 3 February 2020 (UTC)[reply]

Neither do I. It's neither independent nor part of any other country: it's part of the United States. Ghouston (talk) 08:17, 3 February 2020 (UTC)[reply]

The common approach is to use US for country (P17) and nothing for located in the administrative territorial entity (P131) because it's not in the U.S. .. Located in the U.S. are 50 states.--The Eloquent Peasant (talk) 11:54, 3 February 2020 (UTC)[reply]

I think the "common" approach since 2013 was to use Q30 in P131. What else do you mean with "common"? --- Jura 12:02, 3 February 2020 (UTC)[reply]

However, in the case of the Arecibo Observatory, if we place United States in the country field, then the infobox incorrectly displays that Arecibo Observatory is locted in the U.S. which it is not. Sorry, I should not have said common. What does Q30 mean? I'm not very familiar with wikidata terms but I do know what is in and not in the U.S. Thank you.--The Eloquent Peasant (talk) 12:05, 3 February 2020 (UTC)[reply]

As mentioned above, I don't think argument #3 is relevant to Wikidata. Q30 is linked further up. --- Jura 12:07, 3 February 2020 (UTC)[reply]

Regarding the located in the administrative territorial entity (P131) "Located in administrative...entity", please show me a map, an official map of the U.S. that shows that Guam, P.R. The US Virgin Islands, etc. are in the U.S. Something is either in the U.S. or it is not in. This is not a controversial topic. I fail to see how this is difficult to understand.--The Eloquent Peasant (talk) 12:11, 3 February 2020 (UTC)[reply]

Can you clarify what you mean with "U.S."? Argument #1 isn't a reason not to use Q30 in Wikidata. --- Jura 12:15, 3 February 2020 (UTC)[reply]

Argument #1 is a reason not to use Q30 in located in the administrative territorial entity (P131) . If you are in your house-you are in your house. If your left foot is in your house and your right foot is outside your house you are both in and out. However, in the case of these territories they are not in the U.S. so P131 should not be populated with Q30.The Eloquent Peasant (talk) 12:20, 3 February 2020 (UTC)[reply]

Regarding your comment "I think the "common" approach since 2013 was to use Q30 in P131." This was done by someone who used an algorithm to do it without giving much other thought to what he was doing with the algorithm and many editors called him out for introducing errors into wikidata, in 2013. The U.S. territories slipped through the cracks at that time. Because it's been there since 2013 doesn't make it right. Many errors exist in wikidata and wikipedia because editors don't notice them until later. So every wiki different language article after that assumed these territories are in the U.S.The Eloquent Peasant (talk) 12:25, 3 February 2020 (UTC)[reply]

So your argument is that "US territories" should not use P131=Q30. --- Jura 12:31, 3 February 2020 (UTC)[reply]

Neither Washington DC is inside one of the 50 states of the US. The models we use here at Wikida can never fully describe all the fine details in all relations. We have to accept that it sometimes is a little rough, and not fully can describe the truth. I can accept both that Puerto Rico is described as located in US and that it is not. But we cannot have one model for some parts of Puerto Rico and another model for other parts. We have many territories like this in the world. We maybe not even can have the same model for Puerto Rico as for Greenland as for New Caledonia. But inside all of these terrotories we have to accept a common model. 62 etc (talk) 13:01, 3 February 2020 (UTC)[reply]

For the United Kingdom, we've got the British overseas territories (Q46395) which seem to be treated as part of the UK, and the Crown Dependencies (Q185086) which are not. For Australia, all of its various territories like Cocos (Keeling) Islands (Q36004) seem to be considered part of Australia, I'd have guessed the US territories would follow the same principle. Ghouston (talk) 13:33, 3 February 2020 (UTC)[reply]
Also for the United Kingdom we have constituent country of the United Kingdom (Q3336843), e.g.
⟨ England (Q21)    ⟩ instance of (P31) ⟨ constituent country of the United Kingdom (Q3336843)    ⟩
. - Jmabel (talk) 16:56, 3 February 2020 (UTC)[reply]

And that shows that the term "country" is poorly defined. In my language we do not use the same word (ie country) to describe Wales and UK. The country of Wales and the country of UK are not the same kind of entity. We do not even translate a "county" in England the same was as a "county" in US. 62 etc (talk) 17:07, 3 February 2020 (UTC)[reply]

So we should ackowledge that Wikidata has this flaw, and maybe attempt to correct it. I don't know how much coding is involved but because the entire world looks to wikipedia / wikidata for accurate information, I think we should try to get a fact such as whether a place is in a country or not in a country correct. --The Eloquent Peasant (talk) 17:42, 3 February 2020 (UTC)[reply]

What is a country? "A country can be part of a larger state" according to our very own wikipedia here, P.R. would be a country, part of (but not in) a larger state, the U.S. --The Eloquent Peasant (talk) 17:48, 3 February 2020 (UTC)[reply]

located in the administrative territorial entity (P131) is itself a bit of a strange concept, combining geographical location with administrative control. We have Puerto Rico at some level controlled by the United States (government), even if it may or may not be part of the United States geographically, depending on how we are defining "United States". Ghouston (talk) 22:23, 3 February 2020 (UTC)[reply]

@Jura1: I was confused and wondering why you made this change. Isn't this exactly what we are discussing here. Is Guam in the United States? What does in mean? What does located in the administrative territorial entity (P131) mean? --The Eloquent Peasant (talk) 20:43, 4 February 2020 (UTC)[reply]

It seems your deletion isn't supported, but, if the conclusion ends up being that it should be removed, we will do so. If you need a reference for Guam being a territory of the US, I can add one. --- Jura 20:46, 4 February 2020 (UTC)[reply]

located in the administrative territorial entity (P131) is about "administrative territorial entities", which I suppose are arbitrary areas administered by a government body. They won't necessarily have any connection to geographic entities. Puerto Rico doesn't have much geographical connection to Guam, but they still in international politics considered possessions of the same state. Ghouston (talk) 23:07, 4 February 2020 (UTC)[reply]

@Jura1: I believe adding located in the administrative territorial entity (P131) = (U.S.) to Guam and PR. and other territories is wrong but I also see that from the beginning you don't care and will do whatever you want. I don't need a ref to say they're territories. I've never disputed that fact. The fact that they are territories is covered in other wikidata properties. So you're basically saying they're in the U.S. with located in the administrative territorial entity (P131) and that is incorrect--The Eloquent Peasant (talk) 23:57, 4 February 2020 (UTC)[reply]

Because you are defining U.S. to mean something other than all of the territory coming under the sovereignty of the U.S. government. It will also make a difference when calculating things like population and land area. en:United States says "The United States of America (USA), commonly known as the United States (U.S. or US) or America, is a country comprising 50 states, a federal district, five major self-governing territories, and various possessions." Ghouston (talk) 00:47, 5 February 2020 (UTC)[reply]

The territories are "of" but not "in" the U.S. Adding located in the administrative territorial entity (P131) = U.S. to the wikidata item of the terrorities will state they are in the U.S. when they are not. The property is "Wikidata property to indicate a location" --The Eloquent Peasant (talk) 02:33, 5 February 2020 (UTC)[reply]

Personally, I don't care either way, but I think things should be consistent, i.e., how Wikipedia defines it, the population counts and area for the US on Wikipedia and Wikidata, the P17 and P131 statements, should all match. In principle, you can create two or more items on Wikidata for the US, with different definitions, but it would be incredibly confusing. We do have contiguous United States (Q578170), but this is something else. Ghouston (talk) 04:34, 5 February 2020 (UTC)[reply]

It would seem germane that anyone born in Puerto Rico is a U.S. citizen. Not sort of a U.S. citizen, with some weird document. They are exactly as much a U.S. citizen as if they had been born on Boston or Chicago. - Jmabel (talk) 05:12, 5 February 2020 (UTC)[reply]

Do not look to deep into such words as "in", "of", "on" and "at". Their meaning seldom survives a translation. In fact, it is one of the most difficult things to manage when you are learning a new language. At least when the languages are closely related. 62 etc (talk) 07:13, 5 February 2020 (UTC)[reply]

First of all, some background reading: w:Dependent territory.

This stuff is complicated. (IIRC, I brought it up during the discussions leading up to the ongoing "Countries, subdivisions, and disputed territories" RFC, but left it out of the RFC itself because it added complications that could be left for later.) Some countries claim certain territories as their own while saying that the territory is not "part of" the country, making a distinction between all areas governed by the country and the area of the country "proper". This distinction is often applied to various legal things, and is inconsistent between countries. Similar complicated things: What are protectorates, tributary states, dominions, associated states, vassal states, puppet states, colonies, etc? There are many different levels of association an entity can have with a country in power over it. We need a broad and consistent solution for how to represent the levels of association. Current uses of country (P17) and located in the administrative territorial entity (P131) are ambiguous on this. --Yair rand (talk) 22:45, 5 February 2020 (UTC)[reply]

In this instance, we only have to solve the problem for the US territories, not come up with a general theory for every country at every point in history. There can be three answers: 1) they are part of the US (as we define it here) 2) they are not part of the US 3) they are variously part of or not part of, on different items or at different times depending on the whim of whoever edited it last. Option 3) will apply by default unless otherwise decided. Ghouston (talk) 00:50, 6 February 2020 (UTC)[reply]

There are just three involved (Puerto Rico, Guam, USVI). --- Jura 05:29, 6 February 2020 (UTC)[reply]

Also American Samoa and Northern Mariana. And some others like Guantanamo Bay, or in the past Panama Canal, in a completely uncertain status.--Ymblanter (talk) 13:09, 6 February 2020 (UTC)[reply]

Guantanamo Bay is interesting in that Cuba retains sovereignty, and should probably have country (P17), but maybe the located in the administrative territorial entity (P131) chain wouldn't lead to Cuba. At present though, it's set as part of a Cuban province: Guantanamo Bay Naval Base (Q762570). Should the population of Guantanamo Bay be counted under the US or Cuba? Presumably it's so low that it wouldn't make much difference. Ghouston (talk) 22:15, 6 February 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘The US Census does not include PR in its tally of US population.^[1] The April 2010 US population was 308,745,538, not including Puerto Rico's 3,725,789 inhabitants. The way the US Census accounts for American personnel at US foreign bases (Guantanamo, etc) into the total tally of US population is via the Census tally at the state of residence of the individuals in question (they are residents of their individual states not of the US foreign base).

@The Eloquent Peasant: what were you suggesting above with "The property is 'Wikidata property to indicate a location.' " Were you saying that by manipulating that parameter holds the answer to satisfactorily address the "in"-versus-"of" concern? Mercy11 (talk) 23:36, 11 February 2020 (UTC)[reply]

@Mercy11: Thanks for your comments on US population and clarifying that. The only thing I was saying was that - well see here .. https://www.wikidata.org/wiki/Talk:Q16635 ---- That an editor, in 2013, felt that every location needs to be "in" a country (as a matter of heirarchy) but I know that is not necessarily so for P.R., Guam, the Virgin Islands, etc. Because as we all know there are 50 states in the U.S. and they don't include those territories. I explained that the editor was mistaken when he made that change in 2013 with a bot. I explained, in the talk page, that I removed the parameter from those US territories wikidata items, because if we add it then also addresses might say something like "Arecibo, Puerto Rico, US" and that is incorrect per pretty much everyone's knowledge. Also, I warned that because of that change made in 2013, other language Wikipedia articles created geographic location articles that stated that P.R. is in the U.S. This is the parameter that I feel should not be on US territories = to US ---> https://www.wikidata.org/wiki/Property:P131 = P131 is a property that indicates a location. So it's clear that this property should not be added to US territories because they are not "in" the US. Finally, to answer your specific question I believe the definition of parameter located in the administrative territorial entity (P131) is to indicate a location, thus again should not be added to US territories. (Sorry to sound like a broken record) One editor mentioned not to get too hung up on "in" or "on" or "by" or "of".. (prepositions) but I think that something as simple as whether or not a place is in another place should be accurate on Wikipedia so that we don't perpetuate wrong information. I've had people say to me "Oh Puerto Rico is not in the U.S.?".. So that's all. (Obviously the relationship is complicated - It reminds me of the question- are you married? divorced? answer is "it's complicated".) But I think the P131 parameter is clearly talking about a location (not relationship between US and PR).. but the location of PR is not complicated, and whether a location is in another location is not complicated. That's all. Bottom line "my argument is that "US territories" should not use P131=Q30" (and Q30 means US)--The Eloquent Peasant (talk) 23:56, 11 February 2020 (UTC)[reply]

@Jmabel: When you said "anyone born in Puerto Rico is a U.S. citizen...exactly as much a U.S. citizen as if they had been born on Boston or Chicago", how do you see citizenship having a bearing on the issue here? You seemed to be implying that citizenship can be a way to determine the "in" relationship, but I don't think I can agree with that because w:Puerto Rican citizenship explains how people born in Puerto Rico have both "Puerto Rican citizenship" and "US citizenship." But reviewing what happened after PR became a territory "of" the US people born in PR were only "Citizens of Puerto Rico" and did not automatically become US citizens until an Act of Congress some 20 years later (1917). There is no record that in the 1917 grant of citizenship incorporated PR "in"to the United States. The lesson is that citizenship is no more a determinant of PR being "in" the US than, say, Congress passing a Law granting earthquake relief moneys would be a determinant that PR is suddenly "in" the US. Seems to me that citizenship, like population, can't be used to determine whether or not PR is "in" the US, or was I missing something in your rationale? Mercy11 (talk) 02:25, 12 February 2020 (UTC)[reply]

It still seems like you can argue it either way. en:United States seems to be taking that position that Puerto Rico is part of the USA, for example. "United States (U.S. or US) or America, is a country comprising 50 states, a federal district, five major self-governing territories, and various possessions." and in geography: "the entire United States is approximately 3,800,000 square miles (9,841,955 km2),[218] with the contiguous United States making up 2,959,064 square miles (7,663,940.6 km2) of that. Alaska, separated from the contiguous United States by Canada, is the largest state at 663,268 square miles (1,717,856.2 km2). Hawaii, occupying an archipelago in the central Pacific, southwest of North America, is 10,931 square miles (28,311 km2) in area. The populated territories of Puerto Rico, American Samoa, Guam, Northern Mariana Islands, and U.S. Virgin Islands together cover 9,185 square miles (23,789 km2)". Ghouston (talk) 03:06, 12 February 2020 (UTC):[reply]

No one here disagrees that PR is part "of" the USA, and the article you cited also states it is part "of" it. The disagreement is whether or not PR is "in" the USA. The links offered by the various editors above show the problem is one of sometimes articles implying or openly stating PR is part "of" the US and sometimes articles implying or openly stating (with the help of wikidata) that PR is "in" the US (e.g., former version of Arecibo Observatory). The confusion seems to stem from a tendency to equate the two: that being "part of the USA" implies being "in the USA" and vice versa. PR is part "of" the US while at the same being not "in" the US. The lead paragraph at the English WP US article you cited above is consistent with this, but says nothing about the "in" part. Are these Wikidata constructs (Q30, P|17, P|131, etc.) supposed to facilitate the work of the WP sister projects or are the sister projects supposed to perform workarounds to facilitate Wikidata's work? Mercy11 (talk) 04:09, 13 February 2020 (UTC)[reply]

Doesn't the "administrative territorial entity" of the USA consist of all the territories that are part "of" the USA, or administrated by the USA at some level? Wouldn't every geographical area that's part of the USA then be "in" this territorial entity? Ghouston (talk) 04:55, 13 February 2020 (UTC)[reply]

I don't think so. I took a snapshot of the also known as (multiple descriptions - please see attached image) of the parameter in question. And I went ahead and tabulated / summed the population as seen in the source provided by Mercy11. Total US Population 203,211,926 which can be seen at the top of US population in 1970 did not include Puerto Rico's population of 2,712,033 of 1970 (which is listed on the last line of same source). I just added them to check. PR's pop is listed but not included in the US total pop. --The Eloquent Peasant (talk) 11:42, 13 February 2020 (UTC)[reply]

So the Spanish national census agency is still doing the census in PR? --- Jura 12:02, 13 February 2020 (UTC)[reply]

Whoa- don't go getting salty --The Eloquent Peasant (talk) 12:37, 13 February 2020 (UTC)[reply]

@Ghouston: As I believe I read someone state above, the term country seems to be poorly defined. Like beauty, this too seems to be in the eyes of the beholder. Mercy11 (talk) 03:13, 15 February 2020 (UTC)[reply]

Sure. I don't know how this can be resolved: maybe somebody can be appointed to toss a coin, or we could have a vote? Otherwise, we will never know one way or the other. Ghouston (talk) 03:18, 15 February 2020 (UTC)[reply]

Another page where Wikipedia says it's in: en:Unincorporated territories of the United States: All modern inhabited territories under the control of the federal government can be considered as part of the "United States" for purposes of law as defined in specific legislation (refs). Ghouston (talk) 09:26, 15 February 2020 (UTC)[reply]

It's not a matter of a coin toss. @Jura1: Do you think the US territories are in the US? If you do, please share sources that say the US territories are in the US. Have you ever seen a map of the US? We are talking about Parameter 131, a parameter that I did not create but that was created and defined by someone on the wikidata project. The definition or "also known as" states in more than a dozen times and this is the most ridiculous thing at this point because you're not listening. You just want to win an argument, and this was your position from the beginning - from the moment I updated the wikidata items for US territories and added my "lengthy explanation" that you defined as "not relevant". Well it is relevant and it is important to get it right here.--The Eloquent Peasant (talk) 12:39, 15 February 2020 (UTC)[reply]

@Mercy11: When you say the territories are of the US, I think you mean belong to the US. I can have a dog or a kitty cat that belong to me but they are unINcorporated into my household, so they stay outside all the time. The territories belong to the US but again are not in the US, not INcorporated. Scholars from Yale talk about the issue here, using the term belong to.^[2] --The Eloquent Peasant (talk) 12:00, 16 February 2020 (UTC)[reply]

The "in" in "incorporated" is the latin prefix, not the English word. "please show me a map, an official map of the U.S. that shows that Guam, P.R. The US Virgin Islands, etc. are in the U.S.": Here is one by the NOAA. But more generally the property asks for the administrative territorial entity the item belongs to. From what I understand of w:en:Territories of the United States, Guam, Puerto Rico, etc. are part of the territory of the United States. -Ash Crow (talk) 22:14, 16 February 2020 (UTC)[reply]

Hi. The located in the administrative territorial entity (P131) in question is defined as places that are in other places (if you see the screenshot attached you can see what I mean) and the map you shared is a natural map which includes the "U.S. Caribbean region (in Spanish:

El Caribe estadounidense

) is a term used by the National Oceanic and Atmospheric Administration (NOAA) to refer to the waters belonging to the United States in the Caribbean Sea.^[3] NOAA maps it as a natural region of the United States, located in the Caribbean Sea, made up of federal waters in and around Puerto Rico, the US Virgin Islands, Navassa Island, and the Guantánamo Bay Naval Base. Serranilla Bank, and inhabited island, and Bajo Nuevo Bank, which are currently controlled by Colombia but claimed by the United States, are sometimes included in the region by NOAA. The U.S. Caribbean region is a natural region and not a political or administrative region." These locations are not administratively located in the US. Have a great week.^[4] – The preceding unsigned comment was added by The Eloquent Peasant (talk • contribs).

located in the administrative territorial entity (P131) refers "administrative entities", there's another property located in/on physical feature (P706) for "geographical" areas. I seems like it would be useful to have an item that represents all of the territory where the US government is generally considered sovereign. It's also useful to have items that represent well-defined sub-regions such as contiguous United States (Q578170). There are plenty of other countries that have largely autonomous areas, and even some which have autonomous areas that don't recognize the sovereignty. Ghouston (talk) 05:50, 17 February 2020 (UTC)[reply]

Thank you. I think another field would be useful. A new field / parameter could explain something to this effect. --> The U.S. Secretary of Interior "Carries out Responsibilities for the U.S. Insular Areas" even though P.R. is not on this doi.gov site's list of public laws.^[5] --The Eloquent Peasant (talk) 12:12, 17 February 2020 (UTC)[reply]

I'd also like to invite you all to read what the Wikiproject Puerto Rico team believes happens often regarding the editing of Puerto Rico articles, here in a 2014 Wikipedia Signpost.--The Eloquent Peasant (talk) 16:53, 17 February 2020 (UTC)[reply]

↑ 2010 US Census
↑ https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=6444&context=faculty_scholarship
↑ Delgado, Patricia; Delgado, Patricia; Stedman, Susan-Marie (2004). La región del Caribe Estadounidense: humedales y peces, una conexión vital (in Spanish). Silver Spring, MD: Administración Nacional de los Océanos y la Atmósfera (NOAA), Oficina de Pesquerías de NOAA, División de Conservación de Habitáculo – via Google Books.
↑ {{Cite book|url=https://www.biodiversitylibrary.org/bibliography/62466%7Ctitle=La región del Caribe Estadounidense : humedales y peces, una conexión vital|last=Delgado|first=
↑ https://www.doi.gov/oia/budget/authorities-public-law

Problem with P3054

Hi, I have a problem with Ontario MPP ID (P3054), aparently the format of the ID changed from a number to a name format, like for Dalton McGuinty (Q568204) it is now dalton-mcguinty instead of the old format. What sould we do, change the ID, or mark this property as obselete and start a new one? --Fralambert (talk) 01:35, 3 February 2020 (UTC)[reply]

Sure, but is the string stable ? --- Jura 07:18, 3 February 2020 (UTC)[reply]
Probably, It seem to be at least 6 month stable. --Fralambert (talk) 12:40, 3 February 2020 (UTC)[reply]
For information Wikidata:Property proposal/Legislative Assembly of Ontario MPP ID. --Fralambert (talk) 17:10, 10 February 2020 (UTC)[reply]

Discussion continues on the property's Talk page to find a way out. —Eihel (talk) 11:06, 12 February 2020 (UTC)[reply]

Items refusing to appear

Does anyone else deal with this problem? It's pretty annoying constantly having to refresh a page just to get the items to appear. --Trade (talk) 00:46, 5 February 2020 (UTC)[reply]

Yes! Has always happened intermittently. Add a field, hit publish and it disappears until refresh. --RAN (talk) 13:14, 5 February 2020 (UTC)[reply]

Most of the times I can't simply "hit publish". I have to focus somewhere else, then return focus to edit field and then I can hit publish. Strange behavior. --Infovarius (talk) 00:03, 11 February 2020 (UTC)[reply]

US counties

There is now a dashboard at Wikidata:Lists/US counties/dashboard.

It still needs some tweaking to handle co-extensive cities. --- Jura 18:00, 5 February 2020 (UTC)[reply]

The main list isn't quite working, but at least: Wikidata:Lists/US counties/named after. --- Jura 17:20, 7 February 2020 (UTC)[reply]
Main list finally made it: Wikidata:Lists/US_counties. --- Jura 14:15, 8 February 2020 (UTC)[reply]

@Donnanz: This may interest you. —Justin (koavf)❤T☮C☺M☯ 14:21, 8 February 2020 (UTC)[reply]

Also: Wikidata:Lists/US counties/named after/unique names. --- Jura 16:58, 10 February 2020 (UTC)[reply]

Looks like some items (and Wikipedia articles) missed the updates since creation: e.g. name and area changes that come with re-oranization. --- Jura 05:48, 17 February 2020 (UTC)[reply]

RAL Colors

I was working on colors to improve them and I found that there are a lot of RAL colors instance of RAL classic color (Q17421658). I would like to suggest a batch change and an addition of a property.

First I think it would be better to have the name of the RAL colors as label and the RAL 0000 number part as an alias. Additionaly I think it would be create to add the RAL identifier as an external identifier, so we would need a property RAL identifier or similar.

Any ideas, thought for the further process on this?

--DaSch (talk) 19:33, 5 February 2020 (UTC)[reply]

@DaSch: https://www.wikidata.org/wiki/Wikidata:Property_proposal is the place to propose new properties. ChristianKl ❪✉❫ 09:07, 11 February 2020 (UTC)[reply]

Interest in This Tool?

I made a browser extension that rips structured data from Google's knowledge panel search results and posts the data to wikidata. I'm aware of concerns about sourcing data from Google (it can create cycles of information given they source from us). But it's a good semi-automated tool that currently only pulls out:

Social media links
Freebase/Google KB ids

The changes it makes to wikidata look like this. The results need to be hand audited for accuracy since Google's data is noisy but it's much faster than doing it by hand.

My questions are:

Is there any interest in my open sourcing/distributing this tool? Doing so would require some effort to make it more user-friendly.
Are there thoughts about pulling more structured data from these panels (e.g. inception dates).

Also, is this the most active place to discuss the project or is there a mailing list/IRC that would be better?

BrokenSegue (talk) 22:17, 5 February 2020 (UTC)[reply]

I'm well aware about the concerns regardit sourcing data from Google but i think we should be very much safe extracting social media links. --Trade (talk) 22:30, 5 February 2020 (UTC)[reply]

Doesn't Google rip data from Wikidata? Seems likely to create circular citations, and amplify "citogenesis" , corrupting verifiability of the origins of data. -Animalparty (talk) 23:24, 5 February 2020 (UTC)[reply]

yes, but the tool only populates fields that are currently empty in wikidata and I hand audit the results (it's not fully automated and cannot be fully automated). examining the data it's clear Google is sourcing the social media information primarily from somewhere else. and the population of the freebase/google kb info seems unproblematic since they can't be sourcing that from us. BrokenSegue (talk) 00:23, 6 February 2020 (UTC)[reply]

This sounds like the tool does populate fields where Google mirrored our data and then we deleted our data. I think the tool is fine as long as there's hand auditing of the results. ChristianKl ❪✉❫ 16:45, 6 February 2020 (UTC)[reply]

Yeah that is a reasonable concern though I think that's a minority of cases and yeah i'm hand auditing the results. BrokenSegue (talk) 17:05, 6 February 2020 (UTC)[reply]

@BrokenSegue: Is it possible to have these edits include a reference? You have "scraped data from google" in the edit summary, but it would be really helpful in the long run if you could add some kind of reference like stated in (P248):Google Knowledge Graph (Q648625) (or possibly a more appropriate item) Andrew Gray (talk) 20:12, 10 February 2020 (UTC)[reply]

@Andrew Gray: good idea. I added that feature. you can see it here BrokenSegue (talk) 04:44, 11 February 2020 (UTC)[reply]

Technical problem with the Living People policy

Hi, on Sasha Grey (Q2709) I removed mass (P2067) as ancient and undesirable per policy, cf. Talk:Q2709 here and on enwiki. Wikilinks to the 2019 history about the corresponding weight in an infobox on demand, meanwhile {{Infobox person}} does not more support this on enwiki.
However, ruwiki still supports it, and of course folks try to import the "missing" statement here: How is that supposed to be handled? –84.46.53.138 09:44, 6 February 2020 (UTC)[reply]

The policy doesn't consider the property undesirable per se. I think there's a good chance that the test of "widespread public knowledge or are openly supplied by the individual themselves" can be passed here. As far as automatically importing statements subject to the living people policy, the living people policy has a section on how to deal with the relevant bot approvals. If a bot imports statements from Wikipedia's without honoring that policy, raise the issue with the bot operator and if that doesn't work here. ChristianKl ❪✉❫ 16:35, 6 February 2020 (UTC)[reply]
I can see in ru:Саша Грей mass=55kg with reference to article in Rolling Stone. I have no idea whenever this source is ancient or not, but I'm failed to see how does "ancient" or presence/absence of "weight" is en-infobox has anything to do with wikidata. The mass statement neither violates ru:WP:BLP not WD:BLP Ghuron (talk) 15:23, 7 February 2020 (UTC)[reply]
WD:BLP—nice shortcut, now hoping for a Russian translation—wikilinks WikiProject Properties/Wikidata properties that may violate privacy and WikiProject Properties/Wikidata properties likely to be challenged.
The latter contains mass (P2067). In sports (example) a moving target such as "mass" could make sense with a point in time qualifier, but for actresses—note the suspicious absence of actors—I call BS. As far as I can tell it the over ten years old sources for 55kg are based on a scanned 2006 driver licence. –84.46.53.249 16:23, 7 February 2020 (UTC)[reply]
Yes, according to WD:BLP P2067 statements should be supported by a reliable public source and yes, Rolling Stone article that states 110 pounds is exactly that type of source (and has nothing to do with driving license). May be it would make sense to add point in time (P585) qualifier. Ghuron (talk) 09:15, 8 February 2020 (UTC)[reply]
You are right, mass (P2067) is not in our highest privacy status but in the "likely to be challenged"-status and that status seems to be supported by that source. ChristianKl ❪✉❫ 15:19, 10 February 2020 (UTC)[reply]

If the source is accurate, it should be restored. It is physics, not "ancient and undesirable" information. And the decision to remove body masses appears to be one person's opinion here at Wikidata based on a decision at English Wikipedia. We remove living people information to prevent identity theft and protect minors, no one uses body mass as a personal identifier since it changes from year to year. --RAN (talk) 03:46, 8 February 2020 (UTC)[reply]

Only me happens often, but I wasn't involved in anything related to WD:BLP and its two lists. –84.46.53.249 08:41, 8 February 2020 (UTC)[reply]

One should not romove info from wikiData because of some local rules. 46.188.23.100 11:15, 8 February 2020 (UTC)[reply]
Ignore local rules, enwiki was only an example. This is about WD:BLP + related global rules on Meta, if there are any, or in plain DEnglish sexism. –84.46.52.123 16:09, 9 February 2020 (UTC)[reply]

Draft for why we need new ranks

I have written a draft for the case for having two new ranks of Uncertain and False. Feel free to comment on the talk page if you have input at the draft stage. ChristianKl ❪✉❫ 11:27, 7 February 2020 (UTC)[reply]

I think it's a good idea to tackle the problem created by the property statement disputed by (P1310).

It seems preferable to split them into separate statements, but "false" might not be the optimal term (compare with "erroneous" used also for deprecated). --- Jura 11:42, 7 February 2020 (UTC)[reply]

@Jura1: I'm open to other terms then false. "erroneous" doesn't feel to me like an improvement. – The preceding unsigned comment was added by ChristianKl (talk • contribs).

It wasn't meant as an improvement, just a comparison for being too close. "contested" might do. --- Jura 21:58, 7 February 2020 (UTC)[reply]

"Refuted" suggesting the addition of the refutation reference? --SCIdude (talk) 14:34, 8 February 2020 (UTC)[reply]

Not sure about description of the VIAF part: neither is this way these are currently handled nor is deprecated rank currently appropriate for these. --- Jura 12:31, 7 February 2020 (UTC)[reply]

I do not like the idea of "new ranks":

Ranks as we have them now do deliberately not carry any semantic meaning; they are mere visibility controllers, and we can freely compose a ranking combination for all claims of a given property in an item for very different reasons. The proposed draft intends to change this completely.
Even the three current ranks are poorly understood by many editors and often used incorrectly.
The more ranks we add, the more complicated it becomes to understand which data is visible in which data retrieval scenario.
The more ranks we add, the more likely it becomes that multiple ranks appear applicable at the same time. Which one to choose then?

That said, I do acknowledge that it is currently difficult to annotate statements properly with editorial decisions in a structured manner. We do so by using a combination of qualifiers, references, and rank usage to deal with this shortcoming and it is a mess. This should somehow be improved, but please do not mess up ranks to try this. —MisterSynergy (talk) 12:49, 7 February 2020 (UTC)[reply]

In data retrivial scenarios today sometimes a person will make adjustments for qualifiers and sometimes they don't, it doesn't seem clear to me. Can you point to example where you think the proposed ranks wouldn't leave a clear which rank to use.

I do agree that the current ranks are poorly understood and that suggests to me that the current implementation of them is problematic. Ranks are essentially messed up right now. If it would become more commanplace within Wikidata to make decision about whether normal or uncertain is the more appropriate rank, this will result in users getting more conscious about ranks. Having ranks more visible in the UI will also help making them more visible. ChristianKl ❪✉❫ 17:54, 7 February 2020 (UTC)[reply]

To paraphrase: ranks are poorly understood, so if we add a new rank they will become better understood. No. --Tagishsimon (talk) 18:38, 7 February 2020 (UTC)[reply]

Well, as ranks are visibility controllers, your proposed new ranks would be sort of sub-ranks that control claim visibility in the same way as one of the existing ranks. Rank "false" would actually be like "deprecated-false", and "uncertain" would be "normal-uncertain" (I guess). There would always be uncertainty whether to use the sub-rank or to main-rank, and very soon there would be demand for even more sub-ranks for various purposes. For that reason, I clearly prefer to keep it as "simple" as it is, i.e. continue with pure visibility controllers without any further semantics.
I think we should maybe overhaul Help:Ranking in order better educate users what ranks actually are; improving visibility should not be that difficult (there is at least a phabricator ticket for it, and we could probably offer a gadget within hours if we wanted to do so). —MisterSynergy (talk) 22:09, 8 February 2020 (UTC)[reply]

I think we currently also have "deprecated-uncertain", so it's not a straight subrank.

I agree that we shouldn't add ranks that don't have an effect on visibility. Both of my proposed ranks do effect visibility and this would be a natural barrier towards people proposing additional sub-ranks. ChristianKl ❪✉❫ 08:06, 11 February 2020 (UTC)[reply]

one potential use for the "false" rank is to prevent bad data from re-entering wikidata. for example, if some source says the imdb profile id of X is y but I've hand audited that to be mistaken I would like to be able to encode that information in wikidata to prevent a later editor/bot from mistakenly re-adding the wrong imdb profile link. is that something you imagine the rank being used for? BrokenSegue (talk) 15:27, 7 February 2020 (UTC)[reply]
- Deprecated rank with a reason such as error in source covers that use case. I'm not buying any of the new rank argument. --Tagishsimon (talk) 16:50, 7 February 2020 (UTC)[reply]
Opening the floodgate of large amount of uncurated data may be a concern.--GZWDer (talk) 22:52, 7 February 2020 (UTC)[reply]

I think adding of uncurated data already happens to day already. When it comes to large-scale adding of data the gate that we have is supposed to be the bot approval process even if you try to circumvent it in cases like the Peerage import. ChristianKl ❪✉❫ 10:05, 8 February 2020 (UTC)[reply]

Two thoughts:

1. I think it may make sense to distinguish between statements that we are pretty confident are wrong, and have therefore deprecated from the project, from statements (perhaps suggested by an AI -- and in particular, in Commons Structured Data, suggested by machine vision) that we think might well be right, but we think would benefit from a check or review. We could use deprecation for this latter case, but a specific new type of rank might be more undersatandable and transparent.

2. At the moment we don't have that many deprecated statements. But if we anticipate the number increasing, I think there is a fair case for reviewing the p:Pxxx prefix in the RDF dump and WDQS, and splitting out deprecated statements from it, to use a new prefix, eg pd:Pxxx.

At the moment, to exclude deprecated statements in SPARQL, you have to do something like the following:

  VALUES ?not_deprecated {wikibase:NormalRank wikibase:PreferredRank}
  ?item p:Pxxx ?stmt .
  ?stmt wikibase:rank ?not_deprecated .

or alternatively

  ?item p:Pxxx ?stmt .
  MINUS {?stmt wikibase:rank wikibase:DeprecatedRank} .

This is inefficient because it requires an extra join. More to the point, nobody ever does this, because it's a pain to include -- even people who are having to use the p:Pxxx form in their queries because they want to extract or filter by a qualifier value. So as a result, deprecated statements get included in their results, which is probably not what was intended. This is bad design. It's not helping people to get the results they are most likely to want.

The alternative, if we introduced a pd:Pxxx prefix for deprecated statements would be that

 ?item p:Pxxx ?stmt

would only return non-deprecated statements (probably the desired behaviour 99% of the time); while

 ?item p:Pxxx|pd:Pxxx ?stmt

could be used whenever deprecated statements were desired to be included -- an easy enough change to make, but requiring the query-writer to explicitly signal this intention.

Yes, this would be a breaking change for a limited number of existing queries and reports. But in my view it is one that would make sense. Jheald (talk) 14:25, 8 February 2020 (UTC)[reply]

Breaking change for queries that might already be broken .. I don't usually filter for deprecated rank when accessing qualifiers (which is kind of bad). --- Jura 22:14, 8 February 2020 (UTC)[reply]

I had sort of assumed until this point that p/ps was "normal plus preferred", not "normal plus preferred plus deprecated". Ooops. I like the idea of a specific "give me deprecated values" prefix. Andrew Gray (talk) 20:08, 10 February 2020 (UTC)[reply]

I support that change. I would guess it will fix more existing queries then it breaks. ChristianKl ❪✉❫ 08:06, 11 February 2020 (UTC)[reply]

Little riddle…

Something happened yesterday on Wikidata that had not happened since February 22, 2013, shortly after the beginnings of this project.

What is it? —Eihel (talk) 23:58, 7 February 2020 (UTC)[reply]

For one single day, no one trolled other editors, wrote nasty things, tried to ban their enemies? --RAN (talk) 02:58, 8 February 2020 (UTC)[reply]

No bogus items by Wikipedia editors? No redundant bot edits adding a description identical to the value of the P31 statement? --SCIdude (talk) 14:29, 8 February 2020 (UTC)[reply]

Please, tell us. --Matěj Suchánek (talk) 08:10, 12 February 2020 (UTC)[reply]

Solution Matěj Suchánek :
We congratulate Mike Peel for obtaining administrative rights. Note that it was very close to not getting it ;)
Indeed, since 2013, we have not seen such a high number of votes. Instead of Lymantria, I would have allowed myself a little joke. In the genre:

Sorry, I don't have enough fingers to count the voices… in doubt, Granted
or In front of the candidate's Stalinist score, I am inclined to granted the right. etc.

Again, congratulations Mike, I have no doubt that you will use it well. —Eihel (talk) 10:19, 12 February 2020 (UTC)[reply]

@Eihel: Thanks! I'll try to use the mop well. What was the event in February 2013, though? Thanks. Mike Peel (talk) 10:40, 12 February 2020 (UTC)[reply]

My apologies for not having been funny enough ;P Granting rights is serious stuff. ;) Lymantria (talk) 11:26, 12 February 2020 (UTC)[reply]

Link from Commons to Wikidata for entries on images

At Wedding Deferred, Commits Suicide (Q84572479), for instance, we have a Wikidata entry for a news article hosted at Commons. I can click on the image to get to Commons ... but if I was at Commons how would I know there was a Wikidata entry for this image? --RAN (talk) 06:13, 8 February 2020 (UTC)[reply]

I added a P6243 statement on its structured data, does that look right? Ghouston (talk) 06:23, 8 February 2020 (UTC)[reply]

Or you can check File usage on other wikis section on commons. ‐‐1997kB (talk) 06:48, 8 February 2020 (UTC)[reply]

Ok, both are clever, thanks! Now I see the "File usage on other wikis". --RAN (talk) 07:38, 8 February 2020 (UTC)[reply]

I wonder why we have a massive, and monolithic, quotation or excerpt (P7081) value on that item, rather than the whole (short) article, which is out of copyright, being transcribed on Wikisource, where it can enjoy the use of heading and paragraph markup? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:39, 8 February 2020 (UTC)[reply]

Can't we have both? I have had items deleted at Wikisource as out of scope in the past. Quote at Wikidata is limited to 1,500 characters, so not "massive, and monolithic". Sometimes redundancy is good since we have no control over the deletion policies at other projects. Wikipedia has purges of classes of people and things, and the information is only preserved because we have an entry for them here. At one time there was a purge of high schools at Wikipedia and more recently a purge of mayors and county administrators. They even tried deleting the entries for those people/things here at Wikidata. So ... redundancy can be beneficial. --RAN (talk) 17:38, 8 February 2020 (UTC)[reply]

@Richard Arthur Norton (1958- ): Storing data in Wikidata statements is more expensive then storing it elsewhere. The query service has limited capacity and that should encourage us to not store longer texts in statements, so that we can have more items/statements in the query service. ChristianKl ❪✉❫ 08:53, 11 February 2020 (UTC)[reply]

Performance of tools is abysmal and is often denied

What are the plans to get back to a situation where tools like awarder, quickstatements, tools that editors use gain an acceptable performance. As it is the performance is arguably so bad that I no longer consider Wikidata as performing on an acceptable level. What are the plans and do plan on the pent up demand that is currently denied. Thanks, GerardM – The preceding unsigned comment was added by GerardM (talk • contribs) at 20:20, 8 February 2020‎ (UTC).[reply]

The current bottleneck is the Wikidata Query Service, and they wrote about current plans yesterday in a posting on the wikidata mailing list (the author is one of the team members of the responsible WMF department). The short term plan is to optimize the software of the current setup, as they have identified some pretty expensive processes there which could potentially be streamlined. A mid-term plan is to restrict WDQS more than currently (we won't like this for sure). —MisterSynergy (talk) 22:29, 8 February 2020 (UTC)[reply]

This email is a technicians view. While valid, the question then becomes what the position is of the Wikimedia Foundation. I have written a blogpost where I ask the WMF to value projects other than English Wikipedia. GerardM (talk) 11:49, 9 February 2020 (UTC)[reply]

WMF is not equipped to have a position on particular tools like QuickStatements. WMDE sets the priority about how Wikidata gets developed.

There are ethical reasons for using money that's raised with banners that ask people to help Wikipedia at least partly to improve Wikipedia. It's alright when the WMF using some of their funds for other purposes but if you call that the majority of the donor money should be used in a way that's distinct from what the donors wanted to support, that seems problematic. ChristianKl ❪✉❫ 14:27, 9 February 2020 (UTC)[reply]

This is not about the use of tools. It is about the prospects available to the project- the future of Wikidata. As it is the usefulness of Wikidata is severely impacted by its performance.

The notion that the WMF is beholden to anyone because it raises funding does in my mind not register at all in this. Thanks, GerardM (talk) 17:00, 13 February 2020 (UTC)[reply]

Wikidata step-by-step

Is there some sort of a guide that suggests things to try for new contributors ?

e.g. if someone decides to invest some time every week they could go through a list of things to do (by actually editing). We currently have "tours", but they don't seem to actually lead to edits.

Some samples (each done in a separate, short session):

find a three missing facts to add to Wikidata. (maybe from some generated list)
create three new items for Wikipedia article
fix three labels, etc.
create a series of items on some topic manually
create a series of items on some topic with Petscan
create a series of items on some topic with Quickstatements

Not sure about the sequence, but the general idea is to get to know various aspects if one can't invest too much time at once.

Some thought is needed that a few users don't exhaust all samples. --- Jura 13:58, 9 February 2020 (UTC)[reply]

There are many different ways to contribute to Wikidata. Different people are motivated to do different tasks. I don't think many people start out with an intention of investing time X every week into Wikidata. ChristianKl ❪✉❫ 15:15, 9 February 2020 (UTC)[reply]
- Well, if you decide to contribute by maintaining, e.g. the items about NASA, you'd probably want to know how other aspects work .. --- Jura 16:16, 9 February 2020 (UTC)[reply]
That's a fair point. I think it's worthwhile if such material is written with a good mental model of newcomers. ChristianKl ❪✉❫ 15:20, 10 February 2020 (UTC)[reply]
Similar features has been deployed to some Wikipedias: mw:Growth/Personalized first day/Newcomer tasks. --Matěj Suchánek (talk) 10:49, 10 February 2020 (UTC)[reply]
- Interesting .. seems to be a whole ocean of things. I need to take a closer look. I hadn't exclusively in mind newcomers strictly speaking, but users who want to explore additional features, are interested in trying, but not necessarily read too much documentation beforehand and search for uses .. --- Jura 21:05, 10 February 2020 (UTC)[reply]

Described by source

Described by source Property:P1343 is currently restricted to dictionaries and encyclopedias, why can't the source be an obituary or a biography or a news article. Most people and events are not in existing encyclopedias, but described by news articles and biographies and obituaries. If we have those news articles and biographies and obituaries as Q entries, shouldn't they be linked by "Described by source"? --RAN (talk) 18:57, 9 February 2020 (UTC)[reply]

I use "described by source" (judiciously) for other items like exhibition catalogs. I'd like to see this property opened up. - PKM (talk) 20:06, 9 February 2020 (UTC)[reply]

It's only "restricted" by the English label. There's nothing in the constraints. I use it with obituaries, biographies, etc. Ghouston (talk) 22:55, 9 February 2020 (UTC)[reply]

I tried to change the label and it was reverted. So I am seeking consensus to make the definition broader. We don't have to link to every news article we have that mentions George Washington or Abraham Lincoln, but if we have news articles on people with no coverage in an encyclopedia, we should link to those news items and books about them. Especially since Wikisource does a poor job of indexing and cataloging their entries. They are indexed by author but not by subject. There is no way to know that John Smith is the same as John Q. Smith is the same as J. Q. Smith across articles at Wikisource. --RAN (talk) 00:16, 10 February 2020 (UTC)[reply]

The property was proposed and created for dictionaries and encyclopedias describing the item. Don't just use it otherwise. If people start using properties as they like instead of as intended, it will be chaos. --Dipsacus fullonum (talk) 08:36, 10 February 2020 (UTC)[reply]

Or, you know, it'll be managed change. It's perfectly possible to use as a qualifier object has role (P3831) to specify the nature of the source; and that way we get a useful general purpose property. The alternative is we proliferate properties for no good reason, which makes consistency unlikely and reporting a PITA. There doesn't actually seem to be anything at all very useful about restricting the sources to two types, doesn't seem to be anything that'll get broken if we include an obituary or a magazine article. --Tagishsimon (talk) 09:03, 10 February 2020 (UTC)[reply]

It's not clear from me from the proposal that it can only be used with dictionaries and encyclopedias. The labels don't all match either, e.g., en-gb says "dictionary, encyclopaedia, etc. where this item is described", with the addition of "etc." perhaps expanding the usage considerably, and nl says "woordenboek, encyclopedie of naslagwerk", and who knows what "naslagwerk" (reference work) may encompass. So I've treated it as an analogue of described at URL (P973), which I don't think is limited by type of external content. Once you describe the resource at the URL with it's own item, you have to switch to described by source (P1343). Ghouston (talk) 09:09, 10 February 2020 (UTC)[reply]

I've been using this property to specify "technical standards" which define or describe a concept; but why stop there and not allow any scientific article or source which, well, describes (as the label of the property reads) a concept. Therefore I

Support extending the documented scope of this property to any source. (I think that the current label in en, de, es, fr is good; the description could be updated, but the important point is that the outcome of this discussion should be recorded, say, on the property talk page and property usage examples so that others easily find guidance for how to use this property.) Toni 001 (talk) 10:47, 10 February 2020 (UTC)[reply]

I don't think that Project chat is the place to create consenus to change property descriptions. That discussion should happen on the property page, so that in future people can review it easily. If the discussion doesn't get enough attention, link it from here. ChristianKl ❪✉❫ 13:35, 10 February 2020 (UTC)[reply]

We can always migrate the discussion there when complete, but people only respond to highly visible discussions here. Even when you link to a discussion elsewhere, most people do not click through, including myself. --RAN (talk) 04:54, 11 February 2020 (UTC)[reply]

See for example special:diff/1096069043 by @Trade:. Visite fortuitement prolongée (talk) 21:45, 10 February 2020 (UTC)[reply]

Using described by source (P1343) seems better than described at URL (P973) for the items on Eurabia (Q737979), given that they have their own Wikidata entries. A problem with both properties is that they may turn into extensive lists, as is already happening there. The item for "London" could potentially list every encyclopedia and guidebook that mentions the city. Ghouston (talk) 01:15, 11 February 2020 (UTC)[reply]

We can always limit the number of references to 10 or 15, or only display the first 10, or rank the references by the number of times the subject name gets mentioned. There can be many technical solutions. For some obscure topics, Wikidata may be the only way to link to obscure news articles and scientific papers. --RAN (talk) 04:54, 11 February 2020 (UTC)[reply]

"Better than" described at URL (P973) is not necessarily "good enough", it could still be a maintenance nightmare. –84.46.52.252 13:57, 11 February 2020 (UTC)[reply]

I thought described at URL (P973) was primarily for online resources while described by source (P1343) is for other ones.
An advantage of described at URL (P973) is that it can be converted to a new property fairly easily once one is created.
Also, using that before actually creating a separate property ensures that we don't create properties that remain dormant and unmaintained. --- Jura 11:35, 12 February 2020 (UTC)[reply]

time-varying P31

Quite recently, the two small Indian union territories of Dadra and Nagar Haveli district (Q46107) and Daman and Diu (Q66710) merged to form Dadra and Nagar Haveli and Daman and Diu (Q77997266).

If the Wikipedia article is to be believed, the new territory is actually ((Dadra and Nagar Haveli) and Daman and Diu). That is, although the former union territory of Daman and Diu is no more, the former union territory of Dadra and Nagar Haveli is now one of the three districts making up Dadra and Nagar Haveli and Daman and Diu.

I have indicated this at Dadra and Nagar Haveli district (Q46107) with two different values for instance of (P31), qualified by start time (P580) and end time (P582) in the obvious way. I believe this is a good way to do it.

However, based on discussions I sometimes see here, I suspect there might be an argument for creating two distinct Q-entities for the former union territory as distinct from the current district.

So, if anyone is interested, feel free to correct the tagging at Q77997266 and related entities if I got it wrong, or lobby for creating the second, distinct entity for Dadra and Nagar Haveli. —Scs (talk) 21:05, 9 February 2020 (UTC)[reply]

If the new territory is the legal successor of one of the two previous - i.e. it was one territory added to another - then keeping the old and new in one item would be OK. But if a legally new territory was formed out of the two previous, then it must be a new item. Its a grey area which other external identifiers for administrative units handle differently, some assign a new identifiers at every merge/split of an administration units, others keep them at least when the name of the successor stays same. But probably the Wikipedia links will require two items anyway, as there will be at least one Wikipedia which chooses to have different articles about them. Ahoerstemeier (talk) 09:33, 10 February 2020 (UTC)[reply]

In this case there are already separate items, but I think the difficulty is that Dadra and Nagar Haveli district (Q46107) is being used to represent different kinds of entities before and after the change, union territory of India (Q467745) vs district of India (Q1149652). Since they are different kinds of administrative entities, should they have different items, even though they have the same name and possibly the same territory? Ghouston (talk) 09:58, 10 February 2020 (UTC)[reply]

Yes, that's precisely it: Same name and (AIUI) same territory, but a different "kind of entity".

And although I said above that "I believe this is a good way to do it", here's a pretty strong counterargument: Do we expect someone running a query for "all Indian states and territories (that is, someone trying to check or recreate one of the lists at w:Administrative divisions of India) to explicitly qualify their wdt:P31 query to make sure they get only entities that are currently instances of whatever? —Scs (talk) 11:33, 11 February 2020 (UTC)[reply]

hyphens in URLs but underscores in lists

Why do the tables on the pages e.g. https://www.wikidata.org/wiki/Q32762#sitelinks-wikipedia use underscores e.g. "fiu_vro" while the actual URLs use hyphens e.g. https://fiu-vro.wikipedia.org/wiki/V%C3%B5ro_kiil ? consistency would be much better. Is it possible to fix this? or too big? Irtapil (talk) 01:12, 10 February 2020 (UTC)[reply]

Good question, per #Label/alias in mul above I bet on bug, maybe try to report it on phab:. –84.46.52.252 14:06, 11 February 2020 (UTC)[reply]

We use MediaWiki:Gadget-SiteIdToInterwiki.js to strip -wiki etc. suffixes, perhaps it could also do this. Note that you can still see be_x_old, although it was renamed to be_tarask a few years ago. --Matěj Suchánek (talk) 08:17, 12 February 2020 (UTC)[reply]

MediaWiki:Gadget-SiteIdToInterwiki.js is definitely responsible for this, in my opinion. Wikibase itself shows site IDs in the sitelinks list (which I believe correspond to site_global_key) – that’s also why it still shows be_x_oldwiki, the database hasn’t been renamed yet (T127570). And these site IDs use underscores, not hyphens – if MediaWiki:Gadget-SiteIdToInterwiki.js is supposed to turn those site IDs into interwiki codes, then apparently it needs to turn the underscores into hyphens as well. --Lucas Werkmeister (WMDE) (talk) 18:12, 12 February 2020 (UTC)[reply]

Q56299775 vs Q1122799

Comstock laws (Q56299775) vs Comstock Act of 1873 (Q1122799). How should we handle this, should the two French Wikipedia articles be merged? We have the various laws passed under one article in the English Wikipedia but there are two articles in the French Wikipedia, one is on a single act of Congress and the the other on the various laws passed. --RAN (talk) 01:28, 10 February 2020 (UTC)[reply]

Although one of the French articles - https://fr.wikipedia.org/wiki/Comstock_laws - leaves something to be desired, it appears to be about the set of laws, whilst https://fr.wikipedia.org/wiki/Comstock_Act seems to be about the 1873 'parent' act. My view: swap the FR sitelinks around, clarify the label and description of Q56299775 - it's an act, not laws - and then use has part / part of to link the two wikidata items. --Tagishsimon (talk) 09:11, 10 February 2020 (UTC)[reply]

@Tagishsimon: Go for it, I think you have the best grasp! --RAN (talk) 04:46, 11 February 2020 (UTC)[reply]

does Western Punjabi Wikipedia pnb.* پنجابی have a higher than average number of trolls?

I don't speak it, but a lot of things look suspect and when I look them up they make even less sense. I'm learning Urdu and I occasionally look up Western Punjabi to compare, since there is a lot of overlap. I find for most languages the matching wiki page is a good quick way to check i'm getting the right concept, and not mixing it up with a synonym. For most languages this works well and confirms or clarifies what I find in other sources, but for پن٘جابی I find the result often looks a bit off, and when I look it up it seems to be some sort of joke. But for Western Punjabi there aren't many good quality accessible resources to compare to, so am i just getting muddled or does pnb.wikipedia.org have a higher than average troll problem? Is there a way to approach it if i find what looks like a troll but i don't know how to fix it? Is there a way to flag things for a fluent speaker to check? Irtapil (talk) 01:29, 10 February 2020 (UTC)[reply]

I cannot help with the OP's problem, but I would love to have a way to flag things to be checked by a fluent speaker of a specific language. Bovlb (talk) 16:28, 10 February 2020 (UTC)[reply]

Q12678612 vs Q12678613

Please help. --Kusurija (talk) 12:58, 10 February 2020 (UTC)[reply]

Vyžuona (Q12678612): Wikimedia disambiguation page

Vyžuona (Q12678613): river in n Lithuania, tributary of Šventoji --- Jura 13:01, 10 February 2020 (UTC)[reply]

Thank you very much. --Kusurija (talk) 13:07, 10 February 2020 (UTC)[reply]

It seems that there are actually 5 items with the same label:

2 watercourses:
- Vyžuona (Q12678613): river in n Lithuania, tributary of Šventoji
- Vyžuona (Q11985332): tributary of Nemunėlis, in Lithuania
a lake: Vyžuona (Q16477262): lake in Lithuania
a human settlement: Vyžuona (Q16477263): village in Rokiškis district, Lithuania
an item for disambiguation pages: Vyžuona (Q12678612): Wikimedia disambiguation page

All got expanded over the last days.

@Kusurija: --- Jura 06:01, 17 February 2020 (UTC)[reply]

Thank you. --Kusurija (talk) 08:25, 17 February 2020 (UTC)[reply]

Wikidata weekly summary #402

Here's your quick overview of what has been happening around Wikidata over the last week.

Discussions
- Open request for adminship: Nomen ad hoc

Events
- Learn about the use of Wikidata, Wikipedia and sister projects in education, at the Wikimedia in Education UK Summit at Coventry University on 26 February
- Hackday Niederrhein, Germany, on March 28-29, including a Wikidata workshop
- Next Linked Data for Libraries LD4 Wikidata Affinity Group call: further discussion of labels and aliases; start looking at Google Sheets, 11 February. Agenda
- WikiCite meetup in Melbourne, Australia, on February 14th
- Wikidata Wednesday in Vienna, Austria, on February 19th

Press, articles, blog posts
- Wikidata and Beyond – Knowledge for everyone by everyone, keynote video from Denny Vrandečić at SWAT4HCLS 2019
- Wikidata and the sum of all video games − 2019 edition, by Jean-Frédéric
- Discovering Implicational Knowledge in Wikidata, by Tom Hanika, Maximilian Marx and Gerd Stumme.

Tool of the week
- Reasonator offers a visual formatted display of Wikidata information. It is useful for introducing Wikidata to new audiences and can help find missing or incorrect data by presenting a different view than the standard editing interface.

Other Noteworthy Stuff
- The Kensho Derived Wikimedia Dataset is a a cleaned English subset of Wikipedia/Wikidata with 2.3B tokens, 5.3M pages, 51M nodes, and 120M edges for use in natural language processing (NLP) research
- Property talk pages now include a link to query for a few random items using the "SERVICE bd:sample" in SPARQL. Example: look for "random list" on d:Property talk:P279
- "Status of Wikidata Query Service" update from WMF, on Wikidata mailing list
- Facebook page of a volunteer working on Wikidata about the French local elections in Conflans
- Swiss newspaper Le Temps built a new front-end to interact with a Wikibase backend developed by nonprofit PersonalData.IO to power its citizen-led investigation of personal data flows.
- There are now 100,000 people with the name "John" in Wikidata. "Elizabeth" is now the most frequent female given name.
- Knowledge Grapher is a new tool to create Wikidata knowledge graphs without needing any knowledge of Wikidata Query or SPARQL code. Developed by Fuzheado, it is currently in early testing mode and helps create graphs as described by MartinPoulter at his 2019 blog post Making Wikidata Visible. Feedback is appreciated.

Did you know?
- Newest properties:
  - General datatypes: none
  - External identifiers: Academia.edu publication ID, TI-99/4A Videogame House ID, National Aviation Hall of Fame ID
- New property proposals to review:
  - General datatypes: гражданский чин, uses dataset, CVR person ID, description, Wikimedia community discussion, The Great Biography
  - External identifiers: Visual AIDS Artist+ Registry ID, CYRI ID, Mendeley publication ID, CODEPAC-Bauru ID, Daughters of the American Revolution ancestor ID, PC Games Database.de game ID, Encyclopedia of Chicago, DANFS ID, Deutsche Biographie ID, Haz-Map ID, RAL ID, PC Games Database.de company ID, Kickstarter project ID, Adventure Games company ID, VcBA ID, Adventure Games series ID, Hrvatska enciklopedije ID, Biografisch Woordenboek van Nederland: 1880-2000 ID, Encyclopedia on Early Childhood Development ID, Trakt.tv uri, Open Food Facts label, Compendium heroicum ID, Gry Online game ID, Gram.pl game ID, startrekdb.se query, Legislative Assembly of Ontario MPP ID, Gry Online company ID
- Deleted properties: lithography (P2157)
- Query examples:
  - Timeline of same-sex marriage legalization in various countries (source)
  - Chart of the number of infections and deaths casued since the outbreak of novel coronavirus, as reported by the World Health Organisation
  - Adjacent constituencies of the UK Parliament - query federated with Ordnance Survey's SPARQL endpoint. (source)
  - List of this year’s Academy Awards winners

Development
- Wikidata Bridge: more work on enabling error messages for various cases (datatype not supported, user can't edit on client or repo, etc.)
- Including the property label in the title of the Data Bridge dialog (phab:T233295)
- Mismatched references: follow-up of the deployment in production, adding the "remove warning" button
- Monitoring the number of times the feature reference warnings are being triggered and opened (phab:T231731)
- Fixing some issues connected to the train deployment
- Fixing an issue with new edit summaries not being displayed on client wikis (phab:T244129)
- Fixing an issue with ittem having label conflict with itself (phab:T243158)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Suggested and open tasks!
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 16:24, 10 February 2020 (UTC)[reply]

We might expose a subgraph with only truthy statements. Or have language specific graphs, with only language specific labels.

It's not clear to me why the SPARQL server needs to know anything about labels or descriptions in the first place. I don't think we would lose much relevant functionality when labels and descriptions would be moved to a different server. On a related note I think that the main venue for communicating information about Wikidata should be Wikidata and if there's a monthly edition of the state of the query service it would be great to have it on Wikidata (it's okay to additionally email it). ChristianKl ❪✉❫ 08:15, 11 February 2020 (UTC)[reply]

Duplicates about French mayors

Hi there,

I continuously find duplicate items about French mayors, especially from Gard- lastly Q60677070 and Q65579675 (now merged) about Mr. Gilles Dumas, CLH. They were all created en masse months ago without checking pre-existing ones. I can't check one by one all the mayors of Gard. How to deal with it?

Thanks for any idea... 86.193.172.227

Some checking was done, some dups happen. See Help:Merge.

Are you sure one isn't the father or a relative of the other?

@Arpyia: for info. --- Jura 22:04, 10 February 2020 (UTC)[reply]

Already knew merge tools, thanks. And it is obvious that it is the same person (both items deal with a politician who hold the same position, at the same time). 86.193.172.227

1977 and 2014 isn't exactly the "same time". --- Jura 22:10, 10 February 2020 (UTC)[reply]

Look: this isn't the same start time (because one item took in account the first election as a mayor, and the second only the current elective term; and both dates are correct, see for instance [2]), but as the position is still hold now, it means that two "Gilles Dumas" can't have been both mayor of Fourques synchronically. 86.193.172.227

Thanks for merging them then. It wasn't visible from the data available here. Such duplicates might be a side-effect of the data model chosen for French mayors. --- Jura 12:02, 11 February 2020 (UTC)[reply]

@Jura1: I just found some other duplicates (Q65604477 and Q60824253; Q60824116 and Q65582364; Q60824933 and Q65591551; Q60677916 and Q65603310; Q60824490 and Q65572113; Q65569085 and Q60825842; Q60815680 and Q65571735; Q60815035 and Q65569716; Q60823841 and Q65587974), only having a look at Gard towns whose name start with A. But I don't think that it is me to merge all of them... Regards, 86.193.172.227

Of course not. This finds some 250 (out of 41557 mayors/35277 distinct offices). While the mayors of Tours are probably not duplicates, e.g. Q65577425 and Q83617920 should have been avoided. Eventually, these need to be looked into. The rate of possible duplicates seems fairly low given the number of items involved. --- Jura 08:58, 12 February 2020 (UTC)[reply]

I already merged a duplicate about Ms. Pilar Chaleyssin, CLH, mayor of Aubais, on August 2019. What's the sense of re-creating one on January 2020? I'm puzzled. 86.193.172.227

Odd, indeed. As label and P569 is present, it shouldn't have happened. I left a note on the talk page of the uploader. --- Jura 09:34, 12 February 2020 (UTC)[reply]

Items deletion request

Please delete this empty items:

--151.49.42.20 21:19, 10 February 2020 (UTC)[reply]

I checked one of them; it should have been merged, not emptied out. The same is likely true of others. Please read Help:Merge. ArthurPSmith (talk) 21:48, 10 February 2020 (UTC)[reply]

They are not emptied by me, I have found already empty... —151.49.42.20 21:53, 10 February 2020 (UTC)[reply]

I fixed the last one. Is this from Special:ShortPages, basically everything with a size of 158 or 159 bytes? Ghouston (talk) 00:35, 11 February 2020 (UTC)[reply]

So I can reuse them... Thanks! --2001:B07:6442:8903:E1F5:E3C3:7545:62E0 08:38, 11 February 2020 (UTC)[reply]

@2001:B07:6442:8903:E1F5:E3C3:7545:62E0: Merged items should never be reused.--GZWDer (talk) 08:54, 11 February 2020 (UTC)[reply]

@GZWDer: I don’t speak about merged items. I have say the intention to use EMPTY item, NOT the merged one. You don’t want to delete empty item, why? The empty (not merged) item should be deleted otherwise they are available for the reuse! --151.49.42.20 19:53, 11 February 2020 (UTC)[reply]

empty entries that have been merged elsewhere should be redirected. if it never had any content it should be deleted presumably. why re-use? BrokenSegue (talk) 00:59, 12 February 2020 (UTC)[reply]

It's not like we are running out of integers. Ghouston (talk) 01:04, 12 February 2020 (UTC)[reply]

+1. +1. +1. +1. +1. +1. +1. +1. +1. +1. +1. (concur w/ Ghouston.) - Jmabel (talk) 04:50, 12 February 2020 (UTC)[reply]

I suppose it wont break the site entirely if an IP changes an entity once in a while to something else. Still, I find it more concerning when more extensive re-purposing is done. --- Jura 17:46, 12 February 2020 (UTC)[reply]

P953

At Property:P953 can we delete the "mandatory qualifier constraint property=archive URL" it is very confusing as to what it wants and every instance of using the "full work at" gets the message which appears as if an error, even though it is just a suggestion. Is it suggesting to me I should be using a link from the Wayback Machine? If it is it is something that would be better automated by a bot. --RAN (talk) 04:44, 11 February 2020 (UTC)[reply]

Sounds reasonable even if it's only a suggestion constraint. --- Jura 17:47, 12 February 2020 (UTC)[reply]

Merging 2 items

Could someone merge Q84564408 and Q55771445 ? Same individual. Txs--René La contemporaine (talk) 10:53, 11 February 2020 (UTC)[reply]

@René La contemporaine: see Help:Merge. --- Jura 11:15, 11 February 2020 (UTC)[reply]

Jura Thank you.--René La contemporaine (talk) 13:24, 11 February 2020 (UTC)[reply]

Reduced loading times for Wikidata/Wikimedia Commons

Hello all, While cleaning (reviewing and rewriting) the code of Wikidata and Wikimedia Commons backend in October 2019, The Wikidata team at WMDE together with WMF worked on reducing the loading time of pages. We managed to reduce the loading time of every Wikidata page by about 0.1-0.2 seconds. This is due to a reduction of the modules (sets of code responsible for a certain function) that need to be loaded every time a page is opened by someone. Instead of 260 modules, which needed to be loaded before, only 85 modules need to be loaded now when the page is called. By doing so, it is easier to load Wikidata pages for people who only have a slow internet connection.

Reducing the amount of modules called when loading the page equals a reduction of about 130 GB of network traffic for all users every day, or 47TB per year. The reduction of network traffic translates into a reduction of electricity use, thus, this change is also good for the environment. Additionally, the interdependencies between the modules were reduced from 4MB to 1MB, which improved the loading time per page as well.

Many thanks to everyone involved in this improvement! If you want to get more details about the actions we performed, you can have a look at the Phabricator board.

If you are developing scripts or tools on top of the Wikidata UI, some documentation will walk you through the architecture of RessourceLoader, what’s page load performance and how to create module bundles with ResourceLoader.

For further questions or feedback, feel free to contact us on this page.

Cheers, for the Wikidata team: Max Klemm (WMDE) (talk) 11:05, 11 February 2020 (UTC)[reply]

Items failed to merge because two items contain the same sitelink

Category:People executed by the Qin dynasty (Q10813613) was merged to Category:Executed Qin dynasty people (Q24918671), but could not be redirected, because Category:People executed by the Qin dynasty (Q7016834) is linked to the same Chinese Wikipedia page as Q24918671. I don't know which is the correct item for the sitelink, as putting the description into Google Translate suggests Q7016834, but based on the categories Q24918671 looks more likely. Peter James (talk) 12:20, 11 February 2020 (UTC)[reply]

The two categories are distinct on both enwiki and zhwiki. Li Si seems to be in one enwiki category but not in the other. Before we can merge on Wikidata, the enwiki and zhwiki would have to merge their categories. ChristianKl ❪✉❫ 14:03, 11 February 2020 (UTC)[reply]

The merged items are Q10813613 and Q24918671, not Q7016834. The zhwiki links on Q24918671 and Q7016834 are identical, which makes it impossible to edit the items unless one of the links is removed, but I don't want to remove a correct link and keep an incorrect one. Peter James (talk) 14:59, 11 February 2020 (UTC)[reply]

It's not generally possible to put the same sitelink on multiple items anyway. I assume it was only a bug that allowed it to happen. I'd just remove it from one item and then complete the merge. Ghouston (talk) 22:02, 11 February 2020 (UTC)[reply]

Coordinates

Hello,

is there a free source for coordinates of a map, where I can look for coordinates of a address to enter it into Wikidata. OpenStreetMap is licensed under the OpenDatabaseLicense and so it is not possible to use it for getting coordinates for Wikidata and so I need another source and I dont know one I can use here in Wikidata. At the end in cases like this CCO as a license makes it difficult to use information of other databases. -- Hogü-456 (talk) 17:51, 11 February 2020 (UTC)[reply]

I use this tool to pin a point on the map manually, to get the coordinates of something, somewhere. Edoderoo (talk) 19:45, 11 February 2020 (UTC)[reply]

Is it allowed to use this tool for Wikidata. I am not sure if it is allowed. At the end I use OpenStreetMap and this is not conform because of the license with Wikidata. At the end it is a question about the license of Geodata and if there is a possibility to get free Geodata witout a License what is Public Domain. I dont know Geodata what is licensed in that way. If there is no possibilty to use Coordinates from a map here in Wikidata license conform I think then there should be disussions about the License of Coordinates. I dont want to get problems and so it were good to get an answer what I am allowed to do with coordinates from a map and what not. -- Hogü-456 (talk) 20:32, 11 February 2020 (UTC)[reply]

Yes, it is allowed, why should it *not* be allowed? Edoderoo (talk) 19:19, 16 February 2020 (UTC)[reply]

How do you make citation-needed constraint (Q54554025) work with qualifiers

This is a problem i have been running into. --Trade (talk) 19:13, 11 February 2020 (UTC)[reply]

Try Template:Complex constraint? But then, would there be a statement that only needs a reference when it has a qualifier? --- Jura 17:52, 12 February 2020 (UTC)[reply]

@Trade: In my opinion, the reference of a value can be inserted as a reference of a qualifier. I mean: a qualifier qualifies a value and a reference proves the existence and the usefulness of this value, so the qualifier is indirectly sourced, IMHO. applies to part (P518) can be part of the references to specify that a reference applies to a qualifier.

From a property perspective, I believe we can add citation-needed constraint (Q54554025) to a property that also hosts as qualifier (Q54828449). For example, place of marriage (P2842) is used as a qualifier in spouse (P26) and P26 must have a constraint reference. Otherwise there is no way to specifically reference a qualifier (if that was the question): a source reference a value that can contain one or more qualifiers and that seems sufficient, as described in Help:Sources. Does that help you or did I confuse you? With an example, your question will be clearer. —Eihel (talk) 19:23, 12 February 2020 (UTC)[reply]

@Eihel:, i want to make 'citation needed' work with number of reviews/ratings (P7887) --Trade (talk) 20:09, 12 February 2020 (UTC)[reply]

For information to SPARQL query writers : workaround found to a bug

If you ever tried to use aggregation functions in SPARQL with the query service together with the wikibase:label service and it did not work, you’ll be happy to read a workaround : Wikidata:SPARQL_tutorial#wikibase:Label_and_aggregations_bug

(and a bug is filled)

Tracked in Phabricator
Task T244924

This may help someone :)

author TomT0m / talk page 21:19, 11 February 2020 (UTC)[reply]

There is no bug. It is just as documented in the User Manual. The label service in automatic mode is supposed to work on unbound variables in SELECT. You try to use it for variables in GROUP BY which isn't mentioned as supported, so there is no case. --Dipsacus fullonum (talk) 22:11, 11 February 2020 (UTC)[reply]

I think it had always been that way. Not sure if it's a bug or the absence of a feature, obviously, it could be simpler .. --- Jura 00:40, 12 February 2020 (UTC)[reply]

@Dipsacus fullonum: I get the point, I missed that. Nethertheless, technically it’s also used in the « select » clause in the aggregation expression, still unbound as it’s also unbound in the group by. so the user manual may be seen as ambiguous and this may still be seen as a bug. It’s not very intuitive anyway, and as most of the time the label service is used with default naming (watch the query examples, I think that none or almost none explicitely name the variables) I suspect most people forgot about that feature. Anyway I’ll modify the user manual. author TomT0m / talk page 09:01, 12 February 2020 (UTC)[reply]

@TomT0m: “used in the select clause” is an underdefined term; strictly speaking, the label service looks at the projection of the query. I’ve updated the manual as well. --Lucas Werkmeister (WMDE) (talk) 12:55, 12 February 2020 (UTC)[reply]

@Lucas Werkmeister (WMDE): Is there a technical reason why this should remain as this and this could not be implemented to look inside the aggregation expression for variables ? Too much work to implement ? Because it’s the kind of papercuts that can be very frustrating and puzzling for no good reason. It’s already frustrating to have to care at all for labels where the work of choosing labels for items could be done by the query service UI … author TomT0m / talk page 16:41, 12 February 2020 (UTC)[reply]

@TomT0m: I don’t know Blazegraph internals well enough to judge that, sorry. --Lucas Werkmeister (WMDE) (talk) 16:56, 12 February 2020 (UTC)[reply]

Academic papers about Wikidata

I would like to read some papers about Wikidata. Where should I start? Any recommendations what to read first? Thanks in advance! Bencemac (talk) 07:14, 12 February 2020 (UTC)[reply]

@Bencemac: Where to start? With a wikidata report, perhaps. Beyond that, it somewhat depends on what facet of wikidata is of interest.

SELECT ?item ?itemLabel (group_concat(?instLabel; separator="; ") as ?type) ?date ?inLabel
WHERE 
{
  ?item wdt:P921 wd:Q2013.
  ?item wdt:P31 ?inst .
  optional {?item wdt:P577 ?date . }
  optional {?item wdt:P1433 ?in . }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". 
                         ?inst rdfs:label ?instLabel .
                         ?item rdfs:label ?itemLabel . 
                         ?in rdfs:label ?inLabel .}
} group by ?item ?itemLabel ?date ?inLabel

Try it!

--Tagishsimon (talk) 13:13, 12 February 2020 (UTC)[reply]

Wikidata:WikiProject Properties/Lists/Articles discussing properties could use an update .. --- Jura 13:33, 12 February 2020 (UTC)[reply]

Thank you very much, these links are very useful! To be more specific, I'd like to read about Wikidata in general and VIAF (maybe other library catalogues) integration. Regards, Bencemac (talk) 15:41, 12 February 2020 (UTC)[reply]

Many new Wikidata Tours ready to be published but a software bug is stopping it :(

Hi all

I've spent the past few weeks working on creating many new Wikidata Tours which cover almost all the basics of Wikidata and some common specific tasks like adding coordinates. All the text is now written and Nav Evans has kindly agreed to do all the technical parts. However the tour software has some bugs which means they Tours won't work properly :(

I'd really appreciate your help (will take 2 mins):

https://phabricator.wikimedia.org/T244994

Non Programmers: subscribe to the task to let people know having functional tours is important
Programmers: Have a look at the issue and see if you can contribute

Thanks very much

--John Cummings (talk) 13:23, 12 February 2020 (UTC)[reply]

From the task it isn't really clear what needs fixing. The task mentions two or three script files which may need unification, and also some issues with each.

If you have successfully tested everything on test.wikidata, then perhaps just make {{Edit request}}'s at respective files, so that local (interface) admins know what needs updating.

Anyway, thanks for working on this debt. --Matěj Suchánek (talk) 15:09, 12 February 2020 (UTC)[reply]

Has the Recent Changes issue been addressed? Cheers, Bovlb (talk) 20:43, 13 February 2020 (UTC)[reply]

located in the administrative territorial entity (P131) isn't really transitive...

Hi folks! Over on the located in the administrative territorial entity (P131) talk page, we're trying to figure out how to best handle the fact that administrative territorial entitites at different logical levels aren't really transitive (but the conversation is sort of stuck, so I'm asking for more attention here). For example, the city of Atlanta (Q23556) exists in two counties: Fulton County (Q486633) and DeKalb County (Q486398). The problem arises when I state in P131 that an organization like Patch Works Art & History Center (Q76461608) is located in Atlanta...but then which county is it in? After a natural disaster, I need to be able to search for all organizations in a specific county. Without some fix for this, many organizations will show up as being in the wrong county. Сидик из ПТУ proposed Wikidata:Property proposal/hierarchy switch to explicitly state at the organization level which "grandparent" administrative territorial entity it belongs to, as a potential solution. However, my "inner ontologist" says that a property is either transitive or it isn't, and therefore we could say that located in the administrative territorial entity isn't transitive and we should just explicitly state all logical levels for each organization in the P131 field (returning to the example, explicitly stating that Patch Works Art & History Center is in Atlanta, Fulton County, and Georgia (U.S. State), all in the P131 field). I know that removing P131's transitive property status would be a dramatic change that could have a heavy impact, so I'm curious if there's consensus around one of these two options, or if there's a third option that we're not thinking of. Thanks for your time and attention on this! Clifflandis (talk) 14:13, 12 February 2020 (UTC)[reply]

Here we are talking about an exception to the rule, the solution to the problem is elementary and expects only the adoption of a new property. Thanks to the hierarchy of located in the administrative territorial entity (P131) declared by default, we can easily adjust and build chains from the village to the state with a minimum number of edits, and if you specify not the most accurate values, but everything from parish to the state, this will require significant duplication of efforts, duplication of data and the creation of less savvy algorithms with an extensive knowledge base formalized in code, which will be far from universal in contrast to the current state of affairs. In other words, if we reject the declared hierarchy and transitivity here we will need switches at each access to the property to figure out which of the values is higher in status.Сидик из ПТУ (talk) 15:15, 12 February 2020 (UTC)[reply]

@Сидик из ПТУ: "an exception to the rule"? Hmm, you have forgotten this discussion about French intercommunalities and cantons. Ayack (talk) 15:33, 12 February 2020 (UTC)[reply]

Well, yes, for France it’s done topsy-turvy without clear reasoning. I understand that the arrondissement of France (Q194203) and canton of France (Q184188) lived in parallel there, but no one answered me why the region of France (Q36784) are specified for commune of France (Q484170) if they are completely determined by the arrondissement of France (Q194203). Сидик из ПТУ (talk) 15:42, 12 February 2020 (UTC)[reply]

For an edge case like this, wouldn't it make more sense to create items for the portion of Atlanta (Q23556) within Fulton County (Q486633) and the portion within DeKalb County (Q486398), rather than having to change how we handle what is probably the 98+% case? - Jmabel (talk) 16:08, 12 February 2020 (UTC)[reply]

I think this is a bad idea. There is nothing better than using of Atlanta (Q23556) item in all cases (for place of birth (P19) and located in the administrative territorial entity (P131) or for 1996 Summer Olympics (Q8531) and Atlanta Thrashers (Q244039)). Just adding a switch qualifier as needed, we will not change anything at all for 98+% cases. Сидик из ПТУ (talk) 16:19, 12 February 2020 (UTC)[reply]

This isn't really an edge case for Georgia (Q1428). Of the 539 municipalities in Georgia, 51 (9.5 %) are in more than one county. Clifflandis (talk) 17:01, 12 February 2020 (UTC)[reply]

Maybe territory overlaps (P3179) is what you are looking for? --- Jura 17:54, 12 February 2020 (UTC)[reply]
For using as qualifier instead of proposed property? Сидик из ПТУ (talk) 19:30, 12 February 2020 (UTC)[reply]
- I think it's intended as being used in the following way: Atlanta overlaps with county A, county B. Atlanta is located in Georgia. county A overlaps with Atlanta. All without qualifiers. --- Jura 19:40, 12 February 2020 (UTC)[reply]
@Jura1: I'm trying to picture how your proposal would work, and how it would impact search results. So let me know if I'm not getting this right: Atlanta (Q23556) would have a located in the administrative territorial entity (P131) of Georgia (Q1428), skipping counties altogether. Then it would instead have territory overlaps (P3179) of both Fulton County (Q486633) and DeKalb County (Q486398), so basically separating counties out into the P3179. Do I have that right? If so, that would technically work to preserve the transitive inheritance of P131 (because every city only exists in one state), but it would mean moving all county information to P3179. For the 9.5% of municipality of Georgia (Q76514543) with more than one county, that could be a good solution, but I'm unsure what the impact would be for the other 90.5% that have a one-to-one municipality-to-county relationship. Searching would become clearer (search for city in P131, search for county in P3179), but I'm not sure what other impacts it would have, since I don't know what systems rely on P131 as it's currently set up. Thanks! Clifflandis (talk) 13:39, 13 February 2020 (UTC)[reply]

So it should not be so. All municipalities (cities) of Georgia (Q1428) should have counties in located in the administrative territorial entity (P131) (two for Atlanta (Q23556), one for Roswell (Q585176)). Otherwise it ruins the whole logic. Сидик из ПТУ (talk) 13:54, 13 February 2020 (UTC)[reply]

That's the heart of the problem here -- the current way things are set up is not logical. For a property to be transitive, it has to be transitive all of the time, not just 90% or even 98+% of the time. It is always true that Atlanta (Q23556) is in Georgia (Q1428), and it is always true that Fulton County (Q486633) is in Georgia (Q1428), but it's not always true that Atlanta (Q23556) is in Fulton County (Q486633) (because sometimes it's in DeKalb County (Q486398)). Since the municipalities/cities aren't tied to the counties in a logical way, they're two separate logical systems. So we can either make Wikidata conform to the logic of the world (separating out cities and counties since they're nontransitive), or we can add qualifiers to make Wikidata more convenient to use (creating and using the Wikidata:Property proposal/hierarchy switch to explicitly state the value of county). Honestly, I think either solution could work -- it comes down to philosophical approach around how we want to represent knowledge in Wikidata. And just so it doesn't go without saying, thank you Сидик из ПТУ for your continued work on this -- it's a tough problem and I appreciate the thought and effort you're putting into it! Clifflandis (talk) 14:38, 13 February 2020 (UTC)[reply]

Qualifier-based solution is the most flexible, inexpensive and universal, it will not prevent us from continuing to automatically build hierarchies without additional applied knowledge and will not affect 98+% cases. Separate properties for all types of territories of all times and countries cannot be created and doing it only for Georgia is futile. Сидик из ПТУ (talk) 14:54, 13 February 2020 (UTC)[reply]

Agreed, I think Wikidata:Property proposal/hierarchy switch is a pragmatic solution to a complex logical problem. @Jmabel:, @Ayack:, @Jura1:, @Pasleim:, what do you all think? Would you be willing to support Wikidata:Property proposal/hierarchy switch? Or is there a different practical solution to this transitive property problem? Clifflandis (talk) 15:25, 13 February 2020 (UTC)[reply]
In such cases, I add two P131 claims, e.g. located in the administrative territorial entity (P131)=Atlanta (Q23556) and located in the administrative territorial entity (P131)=Fulton County (Q486633). --Pasleim (talk) 20:39, 12 February 2020 (UTC)[reply]
I think that we need to comply with the rule "indicate the most local territory". It will greatly simplify the construction of hierarchical chains like Atlanta (Q23556)→Fulton County (Q486633)→Georgia (Q1428)→United States of America (Q30). If we add at the same level both Atlanta (Q23556) and Fulton County (Q486633) as located in the administrative territorial entity (P131) then we lose this opportunity. And if we set only counties for other cities of Georgia (Q1428) then we shouldn't set state for Atlanta (Q23556) too. Сидик из ПТУ (talk) 10:41, 13 February 2020 (UTC)[reply]
I thought it was incorrect to state that Atlanta is within Fulton county. --- Jura 10:53, 13 February 2020 (UTC)[reply]
Fulton County (Q486633) and DeKalb County (Q486398). It's two actual administrative territorial entity (Q56061) for Atlanta (Q23556). Atlanta (Q23556) in Category:Cities in Fulton County, Georgia (Q15211928) and Category:Cities in DeKalb County, Georgia (Q15211352) in English Wikipedia (Q328) like Brookhaven (Q154462) (only in Category:Cities in DeKalb County, Georgia (Q15211352)) or Roswell (Q585176) (only in Category:Cities in Fulton County, Georgia (Q15211928)). Сидик из ПТУ (talk) 11:10, 13 February 2020 (UTC)[reply]
I suppose it's not an option to create an item for both counties combined and use that as value for P131. --- Jura 12:03, 13 February 2020 (UTC)[reply]
Yes, nobody needs such a combined element. We need a switch to build a hierarchy for a specific point Patch Works Art & History Center (Q76461608)→Atlanta (Q23556)→Fulton County (Q486633)→Georgia (Q1428)→United States of America (Q30). Сидик из ПТУ (talk) 12:15, 13 February 2020 (UTC)[reply]
I don't think we need the switch. The problem with some layers of administrative levels is that they may be hierarchical in some way, but aren't really territorial entities, frequently change and tend to create more problems than they actually solve. --- Jura 12:20, 13 February 2020 (UTC)[reply]
But C’est la vie (Q1151203). I see nothing wrong with trying to solve these quirks of bureaucrats with qualifiers. Especially since it does not affect 98+% standard cases. Сидик из ПТУ (talk) 12:33, 13 February 2020 (UTC)[reply]
Yeah, but I'd rather see it resolved in the way suggested by Pasleim above instead of adding a qualifier that states that the property isn't entirely applicable. --- Jura 12:51, 13 February 2020 (UTC)[reply]
Not the best way because it violates the logic in comparison with other cities of the state and doesn't allow to understand the hierarchy. Same problems with Redcar and Cleveland (Q1434448). Сидик из ПТУ (talk) 13:25, 13 February 2020 (UTC)[reply]
I find the approach chosen for Scotland rather easy to understand . --- Jura 13:28, 13 February 2020 (UTC)[reply]
Scottish places have only most local located in the administrative territorial entity (P131) at the moment. No one will teach algorithms the hierarchies of all times and peoples, this should be obtained from the data through the belief that we have only the most local territories here and so on up the chain. Сидик из ПТУ (talk) 13:47, 13 February 2020 (UTC)[reply]
Not quite. --- Jura 15:51, 15 February 2020 (UTC)[reply]

Thanks for bringing this issue here. I think I agree with Jura here, that we should only be using located in the administrative territorial entity (P131) when the subject is entirely within the object. For the exceptional cases like Atlanta, we should use territory overlaps (P3179) for the next-level geopolitical entities it falls within, and P131 for the smallest geopolitical entity it's within (Georgia). The problem with using P131 for multiple counties is that this practice effectively redefines P131 to be the same as P3179, rendering it non-transitive and far less useful. If 2% of P131 usage does not denote transitive geo-containment, then none of it does. Bovlb (talk) 20:39, 13 February 2020 (UTC)[reply]

Okay, so let me use the example above to make sure I understand your proposal correctly. Atlanta (Q23556) would have a located in the administrative territorial entity (P131) of Georgia (Q1428) since that's the next-level geopolitical entity that it's entirely in. And then Atlanta (Q23556) would have territory overlaps (P3179) of Fulton County (Q486633) and DeKalb County (Q486398). That makes sense from a mathematical logic perspective for the transitive property of P131. Do I have that correct? So for an organization like Patch Works Art & History Center (Q76461608), I would then tag it by putting both Atlanta and Fulton County in the P131 field so I could find it by county following a natural disaster. That could work for search results, but it would also require changing P131's guidelines. However, it would also impact the results of folks running queries like "What county is Atlanta in?" To Jheald's point, most folks aren't going to ask "What counties does Atlanta overlap with?", even though that's technically a "more correct" question from a geopolitical borders perspective. Is there any way to mitigate that problem? Clifflandis (talk) 13:44, 14 February 2020 (UTC)[reply]

Yes, you have correctly summarized my position (and, I hope, Jura's). It seems to me that the statement "Atlanta is in Fulton County" is simply false, so we should not say it, and queries asking "What is Atlanta in?" should not return "Fulton County". Cheers, Bovlb (talk) 17:55, 14 February 2020 (UTC)[reply]

But in reality this isn't false, it is a consensus point of view, according to Category:Cities in Fulton County, Georgia (Q15211928). Both Roswell (Q585176) and Atlanta (Q23556) should be specified in the same way. Сидик из ПТУ (talk) 18:49, 14 February 2020 (UTC)[reply]

Hmm. Just to be clear, I do think it is false in reality to claim that "Atlanta is in Fulton County", but now we're down to arguing what "in" means, which will have no satisfactory resolution. :)

I had a quick look around WPEN to try to find a definition of what inclusion in en:Category:Cities in Fulton County, Georgia is intended to denote, but I didn't find anything relevant to this question. It is the nature of the category system that the link between the article and the category is unspecified, so in edge cases it will end up having multiple possible meanings. Here at Wikidata, we're trying to be ontologists, so we should not tolerate such vagueness. Cheers, Bovlb (talk) 21:13, 14 February 2020 (UTC)[reply]

There are many languages where are no analogues of in at main labels of P131. But the logic on the example of the city is clear and it's similar to continent (P30) for Russia (Q159). Сидик из ПТУ (talk) 21:51, 14 February 2020 (UTC)[reply]

In my view, we need to think about what queries will people most typically write, and how do we try to make sure they get back as much as possible of what they are looking for.

I don't like the territory overlaps (P3179) solution, because in practice people won't think to ask for it when they're writing queries.

I'm not sure I understand the "hierarchy switch" suggestion -- I don't see how this would work in queries, when people are most naturally just using wdt:P131*

For myself I think the best approach would be to use P131 with applies to part (P518) qualifiers when required eg on Atlanta, plus a P131 at whatever level can be given without qualification (eg Atlanta -> Georgia), plus 'leapfrogging' P131s when there is ambiguity (eg organisation -> Atlanta, and organisation -> Fulton County). This allows queries using P131* to return pretty much the right answers, while careful queries can return exactly the right answers, using P131* MINUS {chains that include a qualified P131} PLUS {chains where that qualified P131 is covered by a P131 from a lower entity}. Jheald (talk) 21:19, 13 February 2020 (UTC)[reply]

Sorry, I don't quite follow how we would use applies to part (P518) to qualify P131. Do you mean for Patch Works Art & History Center (Q76461608) we would say that located in the administrative territorial entity (P131) has a value of Atlanta (Q23556), qualified with a applies to part (P518) of Fulton County (Q486633)? That sounds similar to Сидик из ПТУ's proposed property, but I want to make sure I don't misunderstand. Thanks! Clifflandis (talk) 14:00, 14 February 2020 (UTC)[reply]

@Clifflandis: No, it would be Atlanta (Q23556)located in the administrative territorial entity (P131)Fulton County (Q486633) with qualifier applies to part (P518) = somevalue or applies to part (P518) = some list of districts of Atlanta that are in Fulton County (Q486633).

For Patch Works Art & History Center (Q76461608) I would suggest both Patch Works Art & History Center (Q76461608)located in the administrative territorial entity (P131)Atlanta (Q23556) and Patch Works Art & History Center (Q76461608)located in the administrative territorial entity (P131)Fulton County (Q486633), the latter probably qualified with an appropriate object has role (P3831) qualifcation to flag that Q486633 is not the regular next step up the hierarchy. Jheald (talk) 15:05, 14 February 2020 (UTC)[reply]

@Jheald: Thanks for spelling that out for me -- I'm following you now!

I don't think that applies to part (P518) will work as a way to try to connect cities and counties, since they're not logically related to each other, so there's no somevalue to apply. As you suggest, we could maybe cobble something together for Atlanta based around neighborhoods, but that approach won't work as well for smaller towns like Braselton (Q899020) where the city exists in four counties -- around 9.5% of municipalities in Georgia exist in more than one county, unfortunately. There's just no logical connection between city borders and county borders, at least in Georgia.

For Patch Works Art & History Center (Q76461608)located in the administrative territorial entity (P131)Fulton County (Q486633), where you suggest qualifying with object has role (P3831), would it look like this: Patch Works Art & History Center (Q76461608)located in the administrative territorial entity (P131)Fulton County (Q486633)object has role (P3831)county (Q28575)? Does that make sense, or would it just be redundant?

The messiness between cities and counties is what has me leaning towards Сидик из ПТУ's proposed Wikidata:Property proposal/hierarchy switch as a pragmatic solution. Clifflandis (talk) 18:22, 14 February 2020 (UTC)[reply]

@Clifflandis: applies to part (P518) is not a connector, it's a warning -- it means that the statement does not apply to the whole of the subject, only a part of it. Even if we cannot precisely detail which parts of the subject item the statement applies to, nevertheless we can still use applies to part (P518) with the generic value somevalue to indicate that the statement Atlanta (Q23556)located in the administrative territorial entity (P131)Fulton County (Q486633) does not apply to the whole of Atlanta.

We need something like Patch Works Art & History Center (Q76461608)located in the administrative territorial entity (P131)Atlanta (Q23556), otherwise a query for archive centres in Atlanta will not return it. Jheald (talk) 16:12, 16 February 2020 (UTC)[reply]

I think we should approach this from the perspective of the "client". There are two major types of questions we are solving by located in the administrative territorial entity (P131):

How to get display geochain in infobox like Patch Works Art & History Center (Q76461608)→Atlanta (Q23556)→Fulton County (Q486633)→Georgia (Q1428)→United States of America (Q30) in lua. That seems to be quite trivial, assuming that Wikidata:Property proposal/hierarchy switch will be implemented as P8000 and statement Patch Works Art & History Center (Q76461608)located in the administrative territorial entity (P131)Atlanta (Q23556) will have qualifier P8000:Q486633
How to query for all instance of (P31)organization (Q43229) located in Fulton County (Q486633)? Not sure I have immediate SPARQL snippet here. May be someone with better query writing skills can do it? Ghuron (talk) 06:44, 15 February 2020 (UTC)[reply]

@Ghuron: Maybe something like this:

  {
    ?item wdt:P31/wdt:P279* wd:Q43229. # organisation
    ?item wdt:P131+ wd:Q486633. # located in Fulton County
  }
  MINUS
  {
    # remove the item if there is a hierarchy switch to another county
    ?county_of_georgia wdt:P31 wd:Q13410428.
    ?item wdt:P131*/p:P131/pq:P8000 ?county_of_georgia.
    FILTER (?county_of_georgia != wd:Q486633)
  }

--Dipsacus fullonum (talk) 13:33, 15 February 2020 (UTC)[reply]

To summarize as I see the dissussion:

Viewpoint one is that there is a hierarchy where municipalites is considered to be lower in the hierarchy than counties. That is the view of English Wkipedia (and probably also all other Wikipedias) which has the category Category:Cities in Fulton County, Georgia (Q15211928), but there is no category named w:Category:Counties in Atlanta, Georgia. For that viewpoint to be reflected in Wikidata, we will need the proposed hierarchy switch qualifier.
Viewpoint two is that in Georgia municipalites and counties have equal hierarchical status, so chains of hierarchy should be like (1) Patch Works Art & History Center (Q76461608) → (2) [ Atlanta (Q23556) and Fulton County (Q486633) ] → (3) Georgia (Q1428). For that viewpoint to be reflected in Wikidata, the municipalites and counties of Georgia should point to each other with territory overlaps (P3179)

I agree that from strictly logical point of view that viewpoint 2 is correct. However most sources inclusive the Wikipedias assume viewpoint 1, so I support to also use viewpoint 1 as I don't think that it is sustainable to have another model of the world in Wikidata than all or most other places. --Dipsacus fullonum (talk) 06:45, 16 February 2020 (UTC)[reply]

There is no such thing as "hierarchical status" where I live. The discussions here tends to be dominated by people from federal states (US/Germany/Russia) which have "hierarchical status", but many other nations do not have them. The 98+% case people talk about above, is more of an exception here, rather than a rule. If I have to add the smallest entity, I sometimes have to add "Europe" if I should follow the rule to the book. 62 etc (talk) 08:47, 16 February 2020 (UTC)[reply]

I'm failed to see how you get from "Sweden does not have hierarchical status" to "wikidata should not capture hierarchical status where one clearly exists" Ghuron (talk) 12:56, 16 February 2020 (UTC)[reply]

I remember my talk with Yger who said that transitivity works about OK from kommun. län land. And when I look at the Swedish Wikipedia, I observe the following: Hässjö distrikt är ett distrikt i Timrå kommun och Västernorrlands län, Timrå kommun är en kommun i landskapet Medelpad i Västernorrlands län (where province of Sweden (Q193556) is not for located in the administrative territorial entity (P131) at our days). Moreover, I found there many-to-one direct matching Lista över Sveriges kommuner and similar district listings in articles and templates of kommuns. Сидик из ПТУ (talk) 14:14, 16 February 2020 (UTC)[reply]

I'm no expert on ontology, but if there's one thing I've learned from my own work trying to classify administrative regions into databases, it's that they are not hierarchical. You can convince yourself that at best they're mostly hierarchical. But if you have a scheme that assumes that they're perfectly hierarchical, a scheme that's going to break if confronted with a real-world exception, then the bad news is: it's going to break. There are a lot of exceptions out there in the real world.

But the other thing I strongly believe is that there needs to be an effective compromise. The convenience of assuming that something is "mostly" hierarchical is significant. A scheme that forces every entity to be explicitly categorized under its grandparents and great-grandparents (just because there are a relatively few entities whose direct parents happen to be ambiguous in that regard) is going to be way too much work.

So I believe our goal should be: that compromise. What's the right way of encoding situations like Atlanta's, that balances the needs of the people entering and maintaining the data, versus the needs of the people querying the database? —Scs (talk) 14:46, 16 February 2020 (UTC)[reply]

Right way is a) Get Wikidata:Property proposal/hierarchy switch; b) Use query of Dipsacus fullonum with this property. In this scenario everyone will be satisfied in their needs with the filled data will correspond to the main PoV stated in authoritative sources. Сидик из ПТУ (talk) 15:00, 16 February 2020 (UTC)[reply]

I basically agree with viewpoint 2, though wherever a municipality is entirely inside a county, we should express the simple hierarchy. - Jmabel (talk) 17:21, 16 February 2020 (UTC)[reply]

Fictional character as a value for notable work

Agatha Christie (Q35064) has notable work (P800) Hercule Poirot (Q170534). The value is for the fictional character Hercule Poirot, which seems strange since notable work is intended for creative works and has a value-type constraint (Q21510865), which includes work (Q386724). It turns out fictional character (Q95074) is a subclass of work in the hierarchy, so that's why it's not flagged as a constraint violation. Is it possible to exclude fictional entity (Q14897293) from being an allowed value type constraint, or is there a better way to address this issue? Chicagohil (talk) 20:20, 12 February 2020 (UTC)[reply]

If you think something else is notable, why not just add it in addition? This is not Wikipedia, you don't need to overwrite other contributors. --- Jura 21:15, 12 February 2020 (UTC)[reply]

It doesn't seem strange to me at all. Hercule Poirot (Q170534) is a creative work, not a person. What seems strange to me is that fictional human (Q15632617) is a subclass of person (Q215627). Ghouston (talk) 21:30, 12 February 2020 (UTC)[reply]

Can location be a vehicle, ship, airplane or similar?

What is the "most specific known" location if a person is born eller died during transportation in an ambulance, other vehicle, ship, airplane etc.? Should it be the continent, country, highway, ocean or whatever is known about where the vehicle etc. was, or name or type of the vehicle etc.? Or is there a way to state both? --Dipsacus fullonum (talk) 02:58, 13 February 2020 (UTC)[reply]

Specific vehicles seem fine as values for location but the type of vehicle is no valid value. ChristianKl ❪✉❫ 08:44, 13 February 2020 (UTC)[reply]

Certainly that specific vehicle was at a specific location when "it" happened? --SCIdude (talk) 14:39, 13 February 2020 (UTC) PS. I just want to prevent people from adding "hospital bed" which can be considered a vehicle...[reply]

I am not sure if knowing that someone was born in an ambulance is any more or less valuable than knowing they were born in a hospital bed or a sofa or a grassy knoll. The actual location--'X highway', 'X hospital', 'X other place'--would seem fundamentally different and more important than the type of furniture/vehicle/etc. they were born in. Of course if the individual vehicle/room/etc. is known (e.g. the ambulance in which a famous person was born which is now on museum display), then sure, that makes sense to list. Aircraft and ships might be a complication since depending on the flag nationality of the vehicle, there may be legal ramifications independent of the geographic location of the vessel, but again this would require more than the general type of vehicle be listed to make sense. Josh Baumgartner (talk) 21:05, 13 February 2020 (UTC)[reply]

The reason for my question is the death of Søren Christensen (Q46730224). He died in an air ambulance (helicopter) while it flew between two Danish hospitals (from Aalborg Hospital (Q2757508) to Rigshospitalet (Q3357360)). It could be somewhere over Denmark or over the sea. What should the location of death be stated as? --Dipsacus fullonum (talk) 23:37, 13 February 2020 (UTC)[reply]

Sounds like we may want a way to model a location that means "In transit from [A] to [B]". - Jmabel (talk) 00:01, 14 February 2020 (UTC)[reply]

There's the location at sea (Q55438959) which can be used for death on a ship on an unknown sea. I think there may be a similar concept for "death in the air", but I can't find anything. If you know the place where the plane was flying over, would you record the death at that location? Then you can just use the most specific location, such as "Denmark", "Europe", "Northern Hemisphere". Ghouston (talk) 01:27, 14 February 2020 (UTC)[reply]

Versionize property definitions ?

Occasionally an identifier scheme is replaced with some other: new identifers, possibly new domain name, etc. The question arises: what to do with the property?

The general approach for entities is not to repurpose existing entities.

Some users like to keep the integer (PID) they were aware of and would just want to redo the property definition, formatter and all values at Wikidata they can get hold of.

While this probably wont matter for properties that have never really been used around Wikidata, the question has a larger impact now that other WMF sites use properties and these can't even be tracked from Wikidata (read: Commons). For third party users .. well too bad for them.

If we try to define a version for each property definition, users could check if they still have the current scheme. A simpler approach could be to delete the existing property and create a new one. --- Jura 11:03, 13 February 2020 (UTC)[reply]

Sounds like a good argument to create new properties when significant changes like that happen. ArthurPSmith (talk) 15:11, 13 February 2020 (UTC)[reply]

I agree for any version change which could create a conflict between values assigned under different versions. If the bulk of the old version's values are still valid in the new one, a bot can copy them over as a one-time thing when the new property is created. Josh Baumgartner (talk) 20:55, 13 February 2020 (UTC)[reply]

WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --- Jura 20:36, 13 February 2020 (UTC)[reply]

Colour property for films

Santo contra el cerebro del mal (Q130087) has Property:P462 colour set to "colour" - is this the right property? It seems like a different thing from a field which can be, say, blue, green, red. All the best: Rich Farmbrough, 14:40, 13 February 2020 (UTC).

According to Wikidata:WikiProject Movies/Properties#Other properties, yes, right thing. --Tagishsimon (talk) 14:45, 13 February 2020 (UTC)[reply]

How to show the correct item if a statement is deprecated with 'applies to other...' reason?

Like in (4RS)-4-hydroxy-L-proline (Q27102938) I have two deprecated IDs (not removed, because someone probably would re-add these IDs in the future):

CAS Registry Number (P231)30724-02-8reason for deprecated rank (P2241)applies to other chemical entity (Q51734763)

DSSTox substance ID (P3117)DTXSID60861573reason for deprecated rank (P2241)applies to other chemical entity (Q51734763)

What would be the best way to show the correct item (in which the same ID is added correctly)? Which qualifier I should use? Wostr (talk) 15:40, 13 February 2020 (UTC)[reply]

I have proposed Wikidata:Property proposal/intended subject.--GZWDer (talk) 22:41, 13 February 2020 (UTC)[reply]

About a public nickname statement

Hi all,

the statement that Christian Giudicelli (Q1079854) was nicknamed "Eight One One" by Gabriel Matzneff (Q3093872) has been recently reverted, despite:

it is supported by reliable sources - and very recently, by nationwide magazines such as L'Express ([3]) and The New York Times ([4]);
as reported by L'Express, it is publicly admitted by Giudicelli himself, who wrotes in Florent Georgesco (Q51884467) (ed.), Gabriel Matzneff, Le Sandre, 2010: "Durant notre premier séjour à l'hôtel Tropicana, lui habitait la chambre 804 [Eight o four] et moi la 811 [Eight one one] : ainsi, en bavardant, avons-nous pris l'habitude de nous désigner plutôt que par nos prénoms et [...] mon cher Eight o four prend soin de dissimuler son cher Christian sous l'aile protectrice d'Eight one one : un tour de passe-passe qui n'abuse plus depuis longtemps ses fidèles lecteurs." ("During our first stay at the Tropicana Hotel, he lived in the 804 [Eight o four] room, and I the 811 [Eight one one] one: hence, while chatting, we got into the habit of naming ourselves like that rather than by our first names and [...] my dear Eight o four is careful of hiding is dear Christian under the protective wing of of Eight one one: a sleight of hand who no more misleads our faithful readers.")

So what do you think about that? Thanks, 86.193.172.227 17:02, 13 February 2020 (UTC)[reply]

See fr:Discussion:Christian_Giudicelli, the editor is claiming that he or she is acting on a request by Christian Giudicelli. If this is true, do we retain "hostile" nicknames? Ghouston (talk) 00:53, 14 February 2020 (UTC)[reply]

Or nicknames used briefly while staying in a hotel, or between friends, that have no wider significance? Ghouston (talk) 00:57, 14 February 2020 (UTC)[reply]

Hi Ghouston. Please consider that:

This is not an hostile nickname: Matzneff is a close friend of Giudicelli.
It neither wasn't used "briefly", nor only "in a hotel", but also in many books of Giudicelli and Matzneff; see L'Express: "dans plusieurs de leurs romans respectifs" ("in several of their respective books"); or Le Monde: "Dans les livres [de Matzneff], il figure souvent sous le surnom « Eight One One » [...], comme un numéro de chambre d’hôtel." ("In [Matzneff]'s books, he is frequently mentioned under the nickname Eight One One [...], like a hotel room"; my emphasis). It can be checked on Google Books: Boulevard Saint-Germain and Voici venir le fiancé (2006); Les Demoiselles du Taranne (2007); Carnets noirs (2009); dedication of Les Nouveaux Émiles de Gab la Rafale (2013)

Best, 86.193.172.227

Fair enough, but it seems like a nickname used only by one person. If I understand the context, Gabriel Matzneff has been accused of sex crimes and Giudicelli is apparently trying to reduce the association. Ghouston (talk) 07:38, 14 February 2020 (UTC)[reply]

Correct. 86.193.172.227

Krolik w sauce

The user "Krolik w sauce" is engaged in Vandalism, bypassing the block, I'm already tired of canceling edits of this vandal. Please cancel all edits and block it.--Ilnur efende (talk) 18:43, 13 February 2020 (UTC)[reply]

Krolik w sauce (talk • contribs • logs)

@Ilnur efende: Could you please clarify what you mean by bypassing the block?

This user seems to be making a lot of quickstatements edits. I cannot make much of the Tartar, but is it possible they have conflated the label with the description? Also, I'm wondering what steps you have taken to interact directly with the user. I see their talk page is a redlink. Cheers, Bovlb (talk) 20:13, 13 February 2020 (UTC)[reply]

Bovlb , User:Maitsavend and Krolik w sauce (talk • contribs • logs)it's the same person. He makes up his own words and adds them. When they are corrected, it cancels the contributions of others. for that was blocked forever.--Ilnur efende (talk) 15:38, 14 February 2020 (UTC)[reply]

Thanks. Here are some discussions about Maitsavend: Wikidata:Administrators'_noticeboard/Archive/2018/01#User:Maitsavend, Wikidata:Administrators'_noticeboard/Archive/2019/02#Maitsavend, Wikidata:Administrators'_noticeboard/Archive/2019/03#Vandalism

@Ymblanter: Do you want to weigh in? The language barrier makes it hard for me to confirm the similarity. Bovlb (talk) 17:48, 14 February 2020 (UTC)[reply]

Bovlb,is it possible to cancel the entire contribution of these users to this project, because it takes a long time to manually cancel their contribution--Ilnur efende (talk) 18:02, 14 February 2020 (UTC)[reply]

I blocked the user, bacause this is clearly the same person as the several accounts I previously blocked (mass-changing Tatar labels with only fixing orthography is a good indicator), but I do not know how to mass-revert their edits, there are hundreds of them.--Ymblanter (talk) 20:29, 14 February 2020 (UTC)[reply]

I rolled back whatever I could roll back--Ymblanter (talk) 20:50, 14 February 2020 (UTC)[reply]

Ymblanter, thanks,--Ilnur efende (talk) 05:14, 15 February 2020 (UTC)[reply]

Incorrect genealogy

Following on somewhat from this earlier discussion ten days ago: Wikidata:Project_chat/Archive/2020/02#Wildly_variant_genealogies?), again: how to represent genealogy which is wrong, but found in a popular source, eg The Peerage person ID (P4638)? It is desirable, I think, to represent the wrong genealogy here, so we can mark it as wrong (or at least probably wrong), so that people working with the source that is incorrect can understand what we have done here, and that we do know about it, but haven't followed it.

To make things concrete, here's a case study: the genealogy of the first four people to be Viscount Wenman. I've done my best, but some of the items do seem a bit messy now as a result. I'd welcome any thoughts as to what might be improved.

According to current thinking (and in particular the History of Parliament ID (P1614) biogs, which tend to be of a very high quality), the sequence of relationships went as follows:

0. Thomas Wenman (Q26790736) (c.1548-77) -- HoP

m. Jane West (Q76172650) (d. about 1606)

Richard Wenman, 1st Viscount Wenman (Q7329888) (1573-1640) -- HoP / HoP
Son of #0
Sir Thomas Wenman, 2nd Viscount Wenman (Q7794988) (1596-1665) -- HoP / HoP
Son of #1.
Philip Wenman (Q76151947) (d.1686)
Younger son of #1, brother of #2
Richard Wenman, 4th Viscount Wenman (Q7329889).(1657-1690) -- HoP
Son of Mary Wenman (Q76265422) (m. 1651; d. 1657; see HoP), who was a daughter of #2.

However, the entries for the above people in The Peerage (Q21401824) follow a different genealogy, essentially equivalent to the one given at the bottom of this page from Burke's Extinct and Dormant Baronetcies (1844).

According to TP,

Jane West (Q76172650) was married to a Sir Richard Wenman (Q76115470), who had a brother Thomas Wenman who was part of the English military in Ireland, and died in 1637.
#1 and #3 are given as the sons of this Richard Wenman, so that #3 would be the uncle of #2, rather than the brother of #2; and
Mary Wenman (Q76265422) is given as the daughter of a Thomas Wenman (Q76265423) who is another brother of #1, ie another uncle of #2 rather than her being the daughter of #2 directly.

The TP version is clearly wrong:

#1's date of birth, and the identity and date of death of his father are presumably established by what sounds like a considerable paper trail alluded to in [5] following his father's death.
And if #3 died in 1686 and #1's father died in 1577, then there is no way that #3 can have been #1's brother. #3 was therefore surely #1's son; and #3's uncle, the Thomas that died in Ireland in the 1630s and remembered #3 in his will, must therefore have been #1's brother not his uncle.
As for Mary's father, he mathematically might have been a brother of #1; but a member of #2's generation fits much better. Given HoP's definiteness that her father was #2 (eg in [6] and elsewhere), it may well be that Mary and her husband were mentioned in #2 will, or some other of the documents, settling the point.

So how to deal with the TP version on Wikidata?

Given that the account in Burke's explicity had Thomas Wenman (Q76265423) different from Sir Thomas Wenman, 2nd Viscount Wenman (Q7794988), it seems inappropriate to merge them, so I've left Thomas Wenman (Q76265423) separate, identifying him as uncle (Q76557) of Sir Thomas Wenman, 2nd Viscount Wenman (Q7794988) (which is what the Burke's pedigree makes him), identifying the item as a human whose existence is disputed (Q21070568). (But perhaps this is not strong enough?)
Similarly, it doesn't seem appropriate to merge Sir Richard Wenman (Q76115470) and Richard Wenman, 1st Viscount Wenman (Q7329888) -- for one thing, it would be odd to give Richard Wenman, 1st Viscount Wenman (Q7329888) as his own father, even deprecated. So, following User:GZWDer's suggestion in the previous discussion, I have preserved Sir Richard Wenman (Q76115470), but identified it as a conflation (Q14946528).

But it does lead to quite a mess of deprecated statements, especially on Sir Richard Wenman (Q76115470) and Thomas Wenman (Q76265423), but also on some of the other items. Pinging @Andrew Gray, Salgo60, Tagishsimon, Pigsonthewing, GZWDer: and anyone else who's been working in this sort of area for your thoughts. Is this appropriate? What can be improved on?

Thanks, Jheald (talk) 20:05, 13 February 2020 (UTC)[reply]

For what it's worth, the DNB (s:Wenman, Thomas (1596-1665) (DNB00)) seems to have avoided the glitches in Burke's, at least for this family, as long ago as 1899. Jheald (talk) 20:39, 13 February 2020 (UTC)[reply]

Ping @Bvatant, Lesko987a: to people over in Wikidata land.... I dont think Wikidata should dig too deep into the land of unsure genealogy and research is my feeling.... I guess we need better tools for describing hypothesis in Wikidata I like the software Evidentia that try to follow en:Genealogical Proof Standard. Wikidata is good for sources we trust not questioning the relevance of sources - Salgo60 (talk) 21:28, 13 February 2020 (UTC)[reply]

When it comes to labeling things as unsure see Draft:New_Ranks for a possible way of to mark claims where the sources aren't strong. ChristianKl ❪✉❫ 22:10, 13 February 2020 (UTC)[reply]

@ChristianKl: Well yes, but the community doesn't seem to be going for it. Jheald (talk) 22:12, 13 February 2020 (UTC)[reply]

@Jheald:I don't think strong support is necessary to discuss how the proposal interacts with various challenges. At the moment it's a draft. Maybe, I will bin it and maybe I will put it up sooner or later as an RfC to see what the community wants. ChristianKl ❪✉❫ 22:23, 13 February 2020 (UTC)[reply]

@Salgo60: Not really the issue I was bringing up. Here I was wondering how to deal with something that is reliably wrong -- a source that is known for (occasional) weakness, that here is definitively contradicted by much stronger sources; the question being how best to acknowledge what the popular but incorrect source says, but nevertheless mark it as not correct.

The question of how to mark hypotheses, even strong ones, that all the same could use some more explicit and conclusive sources (eg how to indicate "citation needed"), is a different one, though also very relevant to genealogy. For example, in the same family, I know that Penelope Wenman (Q75785757)father (P22)Sir Richard Wenman (Q76115470) from ThePeerage is wrong. I think Penelope Wenman (Q75785757)father (P22)Richard Wenman, 1st Viscount Wenman (Q7329888) is the appropriate correction (and is what user trees at familysearch.org and geni.com also suggest). But I don't (yet) have a reference with a hard citation to put it beyond doubt. So how to try to indicate that is also a good question, but not really the one I was getting at above. Jheald (talk) 22:09, 13 February 2020 (UTC)[reply]

Conservation status (of monuments)

WikiProject Cultural heritage has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

conservation state (Q55553838) seems to be used for two different concepts - there are a handful of statuses (abandoned, restored, etc.) and hundreds of crashes, sunken ships, etc. Does anyone know what's happening here? Was there a bad merge or something? - PKM (talk) 21:07, 13 February 2020 (UTC)[reply]

@PKM: Interesting. The set of items that are direct instances of the class seems pretty well controlled ( https://w.wiki/HC9 ), and the values of state of conservation (P5816) also seem pretty well concentrated ( https://w.wiki/HC7 ).

But I think you're looking at this query, for things P31/P279* conservation state (Q55553838), https://w.wiki/HCA which includes all the wrecks, caused by the chain

shipwreck (Q852190) --> subclass of (P279) disaster remains (Q21073029) --> subclass of (P279) conservation state (Q55553838)

Could I think be fixed by changing disaster remains (Q21073029) to instance of (P31) conservation state (Q55553838), but might need to think about that. Jheald (talk) 21:37, 13 February 2020 (UTC)[reply]

I have made the change, which I hope now gives something closer to the expected behaviour. disaster remains (Q21073029) could use an additional class something like "remains" -- the kind of general concept we don't yet have an item for, because WP doesn't think such a generality is worth an article, yet is a grouping without which our ontology doesn't really express what things are. General and/or abstract grouping concepts without items -- something we hit again and again.

But what you raised at least now should be fixed. Jheald (talk) 21:50, 13 February 2020 (UTC)[reply]

@Jheald: Thank you! Yes, that was the query I was using (the default one on the "information" template). Now I need to think of a good "conservation status" for movable historical monuments that have gone missing (disappeared in "the war", weren't there when a new inventory was ordered, etc.) I'll probably use "missing".

Merge ?

St. John (Q7593634) vs St John (Q65953328) ? Jheald (talk) 23:20, 13 February 2020 (UTC)[reply]

See w:St_John_(name). --- Jura 00:48, 14 February 2020 (UTC)[reply]

How about the case of items where all the properties, including the image, are identical with the only exception of inventory number (P217). It is unclear if it is one object entered twice into institution database, or two objects with one having wrong image. See Kaiumers, the First King of Persia (Q64538958), Kaiumers, the First King of Persia (Q64538960); or Sultan Murad III receiving a book (Q64537998) and Sultan Murad III receiving a book (Q64538040). --Jarekt (talk) 04:55, 14 February 2020 (UTC)[reply]

It could be separate entries for each side of an object?

Occasionally, I add possibly invalid entry requiring further references (Q35779580) to P31 with preferred rank when I come across what seems to be database artifacts (but that's something different from the two items mentioned initially). --- Jura 08:46, 14 February 2020 (UTC)[reply]

I like possibly invalid entry requiring further references (Q35779580). It seems like handy way of tagging problem items, especially if they lack references and URLs. As for Q64538958/Q64537998 and Q64537998/Q64538040 pairs, we have the source but the source is unclear or wrong. It is not uncommon to have item based on a single record in some institution database, which can give us inventory number (P217) but not much else. --Jarekt (talk) 16:44, 14 February 2020 (UTC)[reply]

Most common values for a given property

Is there a way to figure out what the most common values for depicts Iconclass notation (P1257) are? Thanks! Calliopejen1 (talk) 01:09, 15 February 2020 (UTC)[reply]

@Calliopejen1:

SELECT ?value (COUNT(?i) as ?count) {
  ?i wdt:P1257 ?value.
}
GROUP BY ?value
ORDER BY DESC(?count)

Try it!

should do it. Mahir256 (talk) 01:14, 15 February 2020 (UTC)[reply]

@Mahir256: thanks!! Calliopejen1 (talk) 01:16, 15 February 2020 (UTC)[reply]

Discussion of P180 ("Depicts") usage on Wikimedia Commons

This discussion may be of interest: c:Commons:Village pump#Misplaced invitation to "tag" images. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:50, 15 February 2020 (UTC)[reply]

This can be considered vandalism, can't it? --SCIdude (talk) 16:22, 15 February 2020 (UTC)[reply]

I'm sorry, User:SCIdude, what can be considered vandalism? Andy's linking to Commons? Adding a feature on Commons without the consensus of its participants? Trying to get that reversed? Adding bad depicts statements? Removing depicts statements? Having a discussion at c:Commons:Village pump? - Jmabel (talk) 18:46, 15 February 2020 (UTC)[reply]

Thanks. I'll pick "Adding bad depicts statements" without consensus there and here. It seems similar to running a WD bot without having read anything about WD. --SCIdude (talk) 20:28, 15 February 2020 (UTC)[reply]

Inaugural lecture

Does anyone have any experience with modeling the 'inaugural lecture' of a university teacher? First of all: what would be the appropriate P-number/propery to use for 'inaugural lecture'? (It would be okay if I could put a string in it, but ideally it would use a normal Wikidata value/Q number.) Though I could use inaugural 'lecture:name of lecture' as a qualifier either for the chair that is held by the university teacher or the position accepted at the university, my preference is to be able to model the inaugural lecture as its own statement that includes its own qualifiers. I am simply wondering if I haven't been able to find the property for inaugural lecture or that it isn't available yet. If so, I will ask for the correct property to be created. Thanks for your feedback, Ecritures (talk) 12:12, 15 February 2020 (UTC)[reply]

@Ecritures: Are you trying to create an item about the lecture, or simply to add details of it to the item about the person? for the latter you could use significant event (P793). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 15 February 2020 (UTC)[reply]

The latter indeed. Yeah I suppose that could be the way I can model it. Somehow it feels suboptimal but it will do. Thanks for the input! Ecritures (talk) 14:52, 15 February 2020 (UTC)[reply]

Maybe "notable work", but then they aren't necessarily .. I'd rather make an item about the lecture and link it to its author/speaker. --- Jura 15:02, 15 February 2020 (UTC)[reply]

@Ymblanter: you probably have input on this? Multichill (talk) 19:40, 16 February 2020 (UTC)[reply]

I would support "significant event". Lectures are sometimes being published afterwards, but not always, so it is not "work". Do we add info on say TED talks? Inaugural lecture should be probably described by the same property.--Ymblanter (talk) 19:44, 16 February 2020 (UTC)[reply]

Wikimedia 2030 community discussions: Last week begins

We are entering the last lap of the discussions on the Wikimedia 2030 strategic recommendations. Until next Friday, February 21, you can share your feedback, questions, concerns, and other comments.

In my last 2 messages on this village pump, I described how the recommendations were created, the role of your input, and the next steps. This time, let me describe just one selected recommendation, one that sounds to be particularly close to the activities on wiki: 'Improve User Experience'.

It states that anyone, irrespectively from their gender, culture, technological background, or physical and mental abilities, should enjoy a fluid, effective, and positive experience during both the consultation and contribution to knowledge. This recommendation is, among others, about the design improvements, user interface, but also training and support programsdedicated resources for newcomers, and, what I personally find especially interesting, mechanisms that allow finding peers with specific interests, roles, and objectives along with communication channels to interact and collaborate.

Please comment on the recommendations' talk pages. What do you think about this and other recommendations? Should some points be improved, removed, or added?

If something is not clear, please ping me. I will write back as soon as I can.

SGrabarczuk (WMF) (talk) 14:43, 15 February 2020 (UTC)[reply]

I made a clumsy visual representation of the connections between the recommendations (data taken from the sections called Connection to other recommendations). I didn't take into account the cases when a recommendation is connected to all the others. Anyway, I leave making the conclusions to you. In addition, I'm sharing a cloud with the most frequently used words in the recommendations. SGrabarczuk (WMF) (talk) 23:54, 15 February 2020 (UTC)[reply]

Archiving links

Hello,

is it possible to run InternetArchieveBot here in Wikidata to check the links to other websites if they work. I think there are pages who are no longer available. For pages like this it were good if they are archieved. -- Hogü-456 (talk) 18:23, 15 February 2020 (UTC)[reply]

I tried to add a archive URL (P1065) required qualifier constraint (Q21510856) to official website (P856) but one of the other users were strongly against it. --Trade (talk) 20:18, 15 February 2020 (UTC)[reply]

The problem with that is that some websites forbid archiving, or archiving fails for technical reasons (typically too much Javascript), so you'd end up with a lot of constraint violations or exceptions. Ghouston (talk) 01:54, 16 February 2020 (UTC)[reply]

I don't get why we need to add archive URLs to the entities since the archive links can be programatically generated after the fact if the link does go dead (assuming we also record a last-fetched timestamp). The real issue is making sure that we try to archive all the URLs soon after they are added to wikidata. BrokenSegue (talk) 03:39, 16 February 2020 (UTC)[reply]

Constraints are mostly for human editors. If you want to run a bot, you don't need that. --- Jura 07:38, 16 February 2020 (UTC)[reply]

I don't get why we need to add archive URLs to the entities Because that way we can be assured that the URL have been archived after it have been added to Wikidata. Also some values such as review scores might change with time making a archived URL a must have. --Trade (talk) 19:18, 16 February 2020 (UTC)[reply]

And if the archive goes offline? We need to add a backup url?

Anyways, if you think archiving is necessary, why not set up a bot to do it? --- Jura 05:19, 17 February 2020 (UTC)[reply]

I'm not against setting up a bot to do yhe job.--Trade (talk) 11:19, 17 February 2020 (UTC)[reply]

Is gender a property that may violate privacy or likely to be challenged?

@Daniel Mietchen: removed sex or gender (P21) from Nicky Nicolson (Q28913663) for WD:BLP. It have been removed by other user(s) but the removal was reverted by @ديفيد عادل وهبة خليل 2:. There's source that refers the person as female. I don't know whether it is proper to include the gender information to Wikidata.--GZWDer (talk) 20:10, 15 February 2020 (UTC)[reply]

I've heard about religion, medical conditions and sexuality being information that violates privacy but never gender. It just seems like such extremely basic knowledge. --Trade (talk) 21:45, 15 February 2020 (UTC)[reply]

As in everything in life (Wikidata included), Common sense is required. Nothing is absolute. Gender may be non-controversial or obvious for the vast majority of living or historic people, but if there is reason to suspect that it is controversial, or sensitive, for some living people, then "basic knowledge" needs to take a hike, and exceptionally high sources are required. I have no knowledge of the subject in question, but in general, in some cases it may be preferable to leave the field empty, even if reliable sources can be scrounged from the depths of knowledge, if such information is not public, not widely circulated, and/or contradicts a person's stated or assumed gender. -Animalparty (talk) 23:51, 15 February 2020 (UTC)[reply]

I put it back, with a reference. Ghouston (talk) 01:17, 16 February 2020 (UTC)[reply]

Cannot save

On The Lookout (Q85244833), I am trying to add a link to w:en:The Lookout (Laura Veirs album) but I keep on getting "Could not save due to an error. The save has failed." Can someone help me? —Justin (koavf)❤T☮C☺M☯ 00:39, 16 February 2020 (UTC)[reply]

28th time is a charm apparently. —Justin (koavf)❤T☮C☺M☯ 00:43, 16 February 2020 (UTC)[reply]

Misspelling of a moth name

I'm not sure how to fix it, so I'll post it here. Please see Talk:Q13393150. SchreiberBike (talk) 04:00, 16 February 2020 (UTC)[reply]

Wikidata_talk:WikiProject_Taxonomy might help. --- Jura 07:41, 16 February 2020 (UTC)[reply]

Question about subclass and instance of

A few questions I couldn't find answers to in the docs. Maybe I'm being too pedantic here but I don't get how to model data here.

When do you use subclass v. instance of?
- For example Q11421395 is an instance of a medal but there are lots of copies of the medal. Should it be an instance of a "kind of medal"? Or a subclass of medal?
- Q868130 is an instance of a softdrink but really it's a soft drink brand not an actual soft drink? Or surely at least it's a subclass of softdrink? Should it be an instance of a brand and a subclass of soft drink?
- Q12372598 is an instance of "food ingredient" but a subclass of "fruit". Should they both be sub-classes? Also, isn't marking it as a sub-class of "drupe" and "fruit" redundant? Is there value in having both?

Am I over thinking this? Or are there docs describing this I missed? Thanks. BrokenSegue (talk) 04:46, 16 February 2020 (UTC)[reply]

I struggle with this at times too and it would be good to have a dedicated help page that runs through things to help an editor decide which is more suitable. --SilentSpike (talk) 11:49, 16 February 2020 (UTC)[reply]

WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Please see Help:Basic membership properties. Joao4669 (talk) 12:32, 16 February 2020 (UTC)[reply]

Should caramel ice cream (Q84573720) be an instance or a subclass of ice cream (Q13233)?

Should Bubblegum Squash McFlurry (Q82751912) be an instance or a subclass of McFlurry (Q906754)? --Trade (talk) 18:47, 16 February 2020 (UTC)[reply]

Subclass in both cases as they are currently modeled, because you're not talking about a specific instance of a dessert. Now if "McFlurry" were a product model (Q10929058): class of manufactured objects of similar design sold under a specific brand, not a dessert, then any flavor of McFlurry would be an instance. IMHO. - PKM (talk) 19:45, 16 February 2020 (UTC)[reply]

As to the original medal question, the first step would be to look if there is a speciic project that has a guideline / schema. If not, naively I would agree that United Nations Peace Medal (Q11421395) is an instance of a medal class (there is class of award (Q38033430)), not instance of medal; and making it subclass of medal is correct but should be improved by giving the next-higher category of United Nations Peace Medal (Q11421395) if there is one. --SCIdude (talk) 08:23, 17 February 2020 (UTC)[reply]

As to plum (Q12372598) there is the problem that "plum" can have at least two meanings, 1. type of plant (represented by the taxon item Prunus subg. Prunus (Q6401215)); 2. the fruits of (1); and 3. the food ingredient---which is not necessarily (2) because I expect more Prunus species/varieties whose fruits are not eaten, e.g. those varieties that are out of fashion. Now the item in question is (3) plum (Q12372598) and there are several plum varieties, so it is a class of ingredients, a subclass of fruits, and yes, since a drupe is a fruit, the subclass of fruit is redundant. --SCIdude (talk) 08:44, 17 February 2020 (UTC) PS: There is one case when you should not remove the subclass of fruit statement: if it has a better reference than the more specific statement.[reply]

It is not redundant - all drupes are fruit (Q1364), but not all are fruit (Q3314483); some drupes are nut (Q3320037), or inedible fruit (Q30312832). Peter James (talk) 12:38, 17 February 2020 (UTC)[reply]

Do we have a rule against making revision deletion requests at Wikidata:Administrators' noticeboard?

@Jasper Deng: I'll like to have this clarified. I've made revision deletion requests at Wikidata:Administrators' noticeboard before but i never knew such an rule existed. --Trade (talk) 20:41, 16 February 2020 (UTC)[reply]

As we don't have an administrator mail list this may be the only viable way. Another way is via IRC but I don't think there's always someone online and actively monitering messages (in October I was asking an Oversight request to remove a password unintentionally leaked by another user in Wikidata, I can only find an oversighter after 80 minutes.)--GZWDer (talk) 23:57, 16 February 2020 (UTC)[reply]

@GZWDer: If it's urgent then i suppose you could just ping a admin who have been active within the last hour. Also what's an oversighter? --Trade (talk) 11:14, 17 February 2020 (UTC)[reply]

@Trade: WD:OS. ‐‐1997kB (talk) 11:36, 17 February 2020 (UTC)[reply]

I remember there was a time where all admins were able to read deleted revisions. Any idea why that was changed?--Trade (talk) 11:54, 17 February 2020 (UTC)[reply]

There are two types of revdel:

admin-revdel (which admins can do and undo, and all admins can still see the admin-revdel'ed content; this is logged in Special:Log/delete)
oversight-revdel (which only oversighters can do and undo, and only oversighters can still see the content; this is *not* logged publicly)

If you think you need revdel, have a look at Wikidata:Deletion policy#Revision deletion first and decide which sort of revdel you need. As WD:AN is watched by hundreds of editors, it may im many situation be wiser to approach individual admins or oversighters via email, in order not to drag too much attention to the problematic content. This is usually the case for content pages (items, etc.), but often not so much on high-traffic project pages such as the Project chat. —MisterSynergy (talk) 12:04, 17 February 2020 (UTC)[reply]

dead links - items with broken references

The data item about Sue Gardner (Q7524) has at least two references that are broken (date of birth). At enwiki such links are tagged with {deadlink}. What is the practice here? Thanks in advance , Ottawahitech (talk) 02:32, 17 February 2020 (UTC)[reply]

Sue Gardner (Q7524). Ideally add archive URL (P1065), but in this case, the links don't seem to have been archived. If it was a main statement it could be deprecated, or given qualifiers, but I'm not sure what to do when it's already a qualifier. Ghouston (talk) 06:12, 17 February 2020 (UTC)[reply]

Wikidata weekly summary #403