Wikidata:Project chat/Archive/2019/07

From Wikidata
Jump to navigation Jump to search


request merger

Sorry to ask, but I need to do this infrequently: could someone merge Q56356221 into Aurebesh (Q13221551)? -- AnonMoos (talk) 17:41, 3 July 2019 (UTC)

Done. Scs (talk) 17:59, 3 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 07:46, 4 July 2019 (UTC)

Items merge

Please merge Q3766879 and Q3107110. Thanks! -- 21:22, 3 July 2019 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 07:47, 4 July 2019 (UTC)

Please add ko:기독교 정교회 to Orthodox Christianity (Q3333484)

Please add ko:기독교 정교회 to Orthodox Christianity (Q3333484) – The preceding unsigned comment was added by 2001:2d8:e52d:9af6::ba08:1f00 (talk • contribs) at 15:55, 5 July 2019 (UTC).

Done by UnifyKorea. --Ksc~ruwiki (talk) 20:18, 5 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Ksc~ruwiki (talk) 20:18, 5 July 2019 (UTC)

duplicates from BD Gest' import

It looks as though a recent MnM import for BD Gest' author ID (P5491), circa 28 May, may have created a number of duplicate items.

The database has separate IDs for pseudonyms, eg [1], identified as such in the fiche and linked to other entries for each author. New items seem to have been created via MnM for pseudonyms that MnM could not name-match to Wikidata authors.

I've found quite a few of these on the report page for people with matching dates of birth and death; but this will only catch authors who are (i) dead, and (ii) have full (day-specific) dates of birth and death.

Duplicates may also have been created where the name in the database was not an exact match for name(s) we have here; but these may be harder to catch.

I have a bit too much to do at the moment to go in in depth and clean this up, so if somebody could step in and sort it out I would be grateful. Jheald (talk) 13:34, 23 June 2019 (UTC)

Came across a somewhat similar problem with The Encyclopedia of Science Fiction ID (P5357) as the encyclopedia too has separate entries for pseudonyms and pen names (though they are often little more than "pen name used by author X"). Which led me to wonder in which cases it might make sense to create separate items for such pseudonyms and pen names. I guess for pen names used by just one person it's not necessarily neeeded, but we'd need to have a way to model which pseudonym the ID refers to. But there are also pen names shared by several authors or owned by a publisher, where I think it might be better to create separate items. --Kam Solusar (talk) 15:30, 23 June 2019 (UTC)
A applies to name (P5168) qualifier can be added to the identifier statement. Ghouston (talk) 02:58, 24 June 2019 (UTC)
@Ghouston: Thanks. I'd been adding named as (P1810) to the multiples I was finding. I can see that P5168 is useful as a qualifier for eg named after (P138), but I somewhat prefer P1810 for identifiers because for many identifiers people add it anyway for all items. Jheald (talk) 09:29, 24 June 2019 (UTC)
@Kam Solusar: Agreed that for eg house pseudonyms shared by multiple authors, or eg Nicolas Bourbaki (Q190529), in such circumstances it may well make sense to have a particular item. But not sure how one would link eg both the house pseudonym item and the actual author item in a author (P50) statement. The usual stated as (P1932) used to indicate the pseudonym that an author used for a book lets one specify a string, but not an item. Jheald (talk) 09:38, 24 June 2019 (UTC)
@Jheald: We also have the same problem with ghostwriters. There are a few discussions involving the topic of ghostwriters in the past (1, 2, 3) but there doesn't seem to be a good way to model that situation yet. --Kam Solusar (talk) 02:52, 28 June 2019 (UTC)
@Kam Solusar: Presumably, use author (P50) = <item>, with qualifiers object has role (P3831) = ghostwriter (Q623386) and sourcing circumstances (P1480) = "uncredited", listing the authors that are credited on the title page in the order that they appear first, before any additional uncredited (but sourced) authors. Jheald (talk) 09:31, 28 June 2019 (UTC)
@Jheald: That would work in most cases. But I think we might run into similar problems as with the pen names, as we don't have a good way to directly link the ghostwriter and the credited person. In the most common case where we have one ghostwriter and one credited person, we can infer the connection. But there are probably other cases involving multiple persons where it might not be that easy. Seeing as people creating something in someone else's name also exist in other arts like movies (Alan Smithee (Q734916)), music, etc., maybe we need a new property to properly model these kinds of relationships. --Kam Solusar (talk) 14:01, 1 July 2019 (UTC)

Wikimedia Space

Forwarding here since no one else has done it yet: Wikimedia Space is a new platform for movement news and conversations. See the announcement for more information. --Lucas Werkmeister (talk) 23:56, 28 June 2019 (UTC)

Personally, one way I can see this being useful for Wikidata is as a place for discussion or announcement of changes to the Wikidata data model that are especially relevant to other wikis. For example, I imagine that the recent-ish narrowing of Property:P143’s scope from “imported from” to “imported from Wikimedia project” could have simplified a lot of other wikis’ Lua modules (to determine whether a reference is a Wikimedia reference, you no longer have to look at the value of the P143, its presence is enough), but I’m not aware of a good place where this change could have been communicated to them (flooding all the Project:Village pump (Q16503) or Wikipedia:Village pump (technical) (Q4582194) pages via MassMessage might have been excessive). That’s not to say there wasn’t a solution for this before, but perhaps the Wikimedia Space can be part of an improved version? --Lucas Werkmeister (talk) 23:56, 28 June 2019 (UTC)
  • So, will there WMDE staff moderating it too? --- Jura 10:32, 1 July 2019 (UTC)

How to handle a page move which led to a new article

list of video games based on Marvel Comics (Q13644820) was originally a list article, but someone on English Wikipedia moved the old article to create a new one. Three other wikis followed suit; two did not.

Can someone familiar with the process explain how we can split this?

Thanks. Magog the Ogre (talk) 08:47, 30 June 2019 (UTC)

Presuming you're satisfied that the three 'articles' are now Articles rather than lists with a more detailed header, then the solution is to create a new item for Marvel Games, delete Marvel Games sitelinks from the list item and add them to the new article item. The subtelty is that those language wiki pages wikidata classifies as a list do not necessarily have to have a title starting 'List of ...'. --Tagishsimon (talk) 09:20, 30 June 2019 (UTC)
@Magog the Ogre: You didn't say what your problem is. I find the articles close enough if there is no other that better represent the game publisher. Leaving as is should be fine? It is however a problem that the WD item start to get conflicting properties attached to it.
In my personal opinion every "list of ..." should not be notable for wikidata. Is this "list itself" notable other than as a Wp article? IMHO turning the item into the actual publisher and make each game a separate item makes sense. Extracting the list from WD when needed should be better than maintaining an actual list. --Jagulin (talk) 19:46, 30 June 2019 (UTC)
Jagulin, possibly you overlook that sitelinks on wikidata items are the mechanism by which interwiki links are provided to wiki articles. For this reason, there is not really any question as to whether any list or article on a wiki is 'notable for wikidata'. They all are, so that interwiki links can be provided. --Tagishsimon (talk) 20:03, 30 June 2019 (UTC)
OK, I created a new item. Why is the interfacing not allowing me to enter the title in other languages? Magog the Ogre (talk) 21:39, 30 June 2019 (UTC)
You probably need to do something with Babel - --Tagishsimon (talk) 21:49, 30 June 2019 (UTC)
@Magog the Ogre: Adding new item Marvel Games (Q64918019) here for reference. You may want to have different from (P1889) statement to make sure they are not merged easily. There is Help:Split an item that may have been what you asked for, as a way to clone an object and move labels. Babel is good when you have several languages you want in the overview. If you occasionally want another language, there is a link below the label box to get all, saying "All entered languages" in English. Unfortunately it doesn't show language that is completely empty. Jagulin (talk) 11:53, 1 July 2019 (UTC)
@Tagishsimon: I did not overlook interwiki. When assigning the enWp "company with list of products" article into a separate item from "list of products, only briefly hinting the company" you will not get interwiki links between them. If there is no other article for the company, I see no error in leaving the list as the interwiki link. Seeing the complaints coming in I believe there is soon a request to merge the items just for this reason. If there is no "real world" notability for the list itself, each Wp should better adapt to the more notable concept. I know anything that have a Wp link is notable for wikidata according to #1, but when solving conflicts I think we should promote going for #2 instead. No consensus perhaps, but something to consider. Jagulin (talk) 11:53, 1 July 2019 (UTC)

Interwiki conflicts

Where is the Interwiki conflicts workflow documented? How many are usually working with the backlog? Is there an inter-language community group to explain language differences and suggest how to make those differences known on other Wikipedia language variants?

Wikidata:Notability mentions two main goals, but I feel WD documentation may need to shift to not get stuck on the inter-language-goal. There are three main criteria, the first gets most attention but the others show that the Wikipedia article structure isn't the rule for WD. Wikidata:Interwiki_conflicts gives three example types of conflict. As far as I see, only the first type (duplicate items) is a possible WD problem. The other problem would be when WD isn't granular enough to have each needed item. Most complaints to "interwiki conflicts" doesn't seem to say anything about which wikis that are in conflict, just pointing out two WD items that I suppose they think should be merged. Most cases (still in the backlog, I guess the easy merges are filtered quickly) to me seems to be a matter of how the local Wp should relate to WD structure, rather than WD to adapt. Did I misunderstand the goals?

An important part of validity of data and the notability criteria are source references. I see very little discussion and requesting of sources when one decides to link an article to an item. When merging, nothing other than personal decision seems to be required, no consensus or referenced sources? Jagulin (talk) 12:10, 30 June 2019 (UTC)

@Liuxinyu970226: Can you assist with some of these questions? Thanks! Jagulin (talk) 11:57, 1 July 2019 (UTC)

Inverse constraint question P1029

P1029 (Crew member) seems to be used to designate participants in spaceflight missions. It appears to have an inverse constraint of P5096 (member of the crew of).

However standard practice on data on astronaut/cosmonaut pages seems to be to use P450 (astronaut mission) to list their flights. Perhaps to avoid the constraint warnings or need for data duplication, this should be looked at. CanadianCodhead (talk) 13:08, 1 July 2019 (UTC)

We need a convention how a Wikidata external property context is explained for an end user

We are testing displaying Wikidata Properties of type External in a template on sv:Wikipedia

see test page Wikidatalight

To make it more user friendly we try to find the Wikipedia page that explains the "external property context"

Example of Wikidata Properties of type External

Salgo60 (talk) 11:10, 29 June 2019 (UTC)

For external identifiers, maybe it's COALESCE(?P1629value, ?P2378value) ..
Obviously, if you prefer items that have a Wikipedia article in a specific language, you might need to come up with a longer chain. By default, you could also link the property talk page, which does provide some information. --- Jura 17:26, 29 June 2019 (UTC)
I see in that list that you use an always the same icon. When available it might be nice to use the icon that's specific in the Wikidata property/subject item of this property (P1629)/issued by (P2378). That might encourage people in general to add more icons. ChristianKl❫ 09:56, 2 July 2019 (UTC)

weather properties

Hi, which property may I use to expres weather concepts like temperature (Q11466) or water balance (Q1148989) related with places, like natural àreas, deserts or just cities?. The temperature (P2076) is mandatory as qualifiers in chemical or biological reactions. The recently created maximum temperature record (P6591) is, by definition, only vàlid as a "maximus". IMHO, a lost opportunity to have a more flexible property, just naming it "temperature" or "remarkable temerature" + criterion used (P1013) with maximum (Q10578722) / average (Q202785) /minimum (Q10585806) etc. Any suggestion will be wellcomed. Thanks, Amadalvarez (talk) 07:17, 30 June 2019 (UTC)

I don't see why temperature (P2076) should not be useful for places or different from a chemical temperature. It does however say "Use only as a qualifier to indicate at what temperature something took place" and I don't know what the subject item of this property (P1629) means. helium (Q560) does use temp, in a clear context. Atlantic Ocean (Q97) has two temperatures, but as you see they don't really make any sense since there are no further clarifications. When, where and how? As subject, Temperature measurement (Q909741) sounds promising, but I don't see it much used and there is a difference between measured and calculated temperatures.
maximum temperature record (P6591) was discussed first, though I agree that "extreme" or "remarkable temperature" would be a more general idea. I would suggest that it at least had "when where how" as a recommended qualifier. The ability to set constraints is a reason to not use temperature (P2076) directly, I suppose. Jagulin (talk) 17:17, 30 June 2019 (UTC)
Thanks, @Jagulin: I understand that temperature may be A) the "cause" or the "condition" that anything happens, or B) a result of something to document. For instance, "the forest fire started because the temperature rose to 45°C with a humidity of only 20%. The intensity of the fire produced temperatures up to 600ºC that destroyed several farms". It is, cause/condition and resultant temp. So, I agree with two different properties. The temperature (P2076) is to expres the necessary conditions or cause to get an event, and is correct as a qualifier. The other (P6591 ?) should be able to record what temperature got (or we use to a place); it must be use as a property to be able to have qualifiers ( "when where how"). The P6591 discussion was near "irregular". Only two days and 1 support to get approved. When I created properties, was not so easy.....
What do you propose ?. Try to modify P6591 ?. Try to create a "B) temperature" and let P6591 as a "property for trivial game" ?. Thanks, again. Amadalvarez (talk) 05:06, 1 July 2019 (UTC)
@Amadalvarez: Let me clarify that I'm not experienced with WD structure decisions, I was just responding from a general perspective. Sorry for not finding an obvious suggestion for you.
Causality is sometimes difficult to judge. As far as I see, it's not built into temperature (P2076) at all (see instead has cause (P828)). It however says that it should be "qualifier" only, an added information to another statement. If you have a temperature for the water balance (Q1148989), you should use the qualifier to register that. If the temperature itself is "the statement" it should not be in the qualifier but set as a "property". Maybe speed (P2052) can be changed to allow also use as property, I don't know why it was restricted.
@Manu1400, ديفيد عادل وهبة خليل 2, Jura1: You were involved in the maximum temperature record (P6591) creation process. I see that it is "subproperty" of temperature (P2076), which may be against the intention of that? Can you share your view of making it more general, using a mandatory criterion used (P1013) to mark the type of extreme? Instead of adding the "minimum ..." counterpart it would allow a more flexible use of the property. Is it against WD data design guidelines, making it more complicated? Did you use it somewhere to show how it's meant to be used? In Ohio (Q1397) it has no specific location and no clarification how it was measured. Jagulin (talk) 15:17, 1 July 2019 (UTC)
Thanks @Jagulin: to invite P6591 participants. Look my answer to Jura; probably talking about the specific case make easier to understand it and find a reasonable solution. Amadalvarez (talk) 16:56, 1 July 2019 (UTC)
  • If you want to add something "remarkable" about the weather and don't quite know what, there is weather history (P4150). --- Jura 11:53, 1 July 2019 (UTC)
That is for measurement series, I believe. In general I think WD idea is not to merely reference external data, but rather annotate it in graph structure. Otherwise creating a table for every location is a good idea if there is no external database to reference directly. Jagulin (talk) 15:09, 1 July 2019 (UTC)
It's neither external nor necessarily for series. --- Jura 15:20, 1 July 2019 (UTC)
  • Thank, @Jura1:. Tabular-data is not what I'm looking for. I do not have sources of mass data nor plan to upload historical series.
  • In the cawiki "infobox for natural spots", used for parks, lakes, deserts, seas, etc., we have a few "historical" manual parameters related with temp. I try to find the way to get them from WD, and I need a "quantity property" that can be use -with qualifiers- to expres "when, where and how", as Jagulin well described. Nowadays are: year average temperature, atmospheric temperature range, water temperature (for hot spring (Q177380)). I just want to eliminate the manual information moving it to WD and help editors to enter information in WD instead via manual parameters.
  • If we had a flexible formula, we probable will used for any other temperature data. I red Property talk:P6591 and I believe it may become a more useful property if we manage it as many other dimension properties, as:
Do you think we can reorient the P6591 and harmonize its ontology with this others?. Thanks, Amadalvarez (talk) 16:56, 1 July 2019 (UTC)
  • In general, a property should be usable without reading all qualifiers. I find the use of P2044 somewhat problematic.
P6591 is meant to store things like average and min/max temperature for every month in a year for a given location. What it actually stores is defined on Commons. The idea is that it would be too much data for Wikibase to handle directly in Wikidata. You don't need to store as much at once as it was done for NY. --- Jura 17:03, 1 July 2019 (UTC)
Sorry, yes, it should read weather history (P4150) not P6591. --- Jura 09:32, 2 July 2019 (UTC)
@Jura1: I think the numbers got mixed up in your reply. Did you mean criterion used (P1013) as problematic and weather history (P4150) for the temperature series?
"a property should be usable without reading all qualifiers" may be a good guiding idea. Can you point to any documentation of it for further understanding of reason and exceptions? The "qualifier" system is certainly adding value but you say that it's only meant for "useless" details?
Seeing that criterion used (P1013) is widely used, could you give some examples of what makes it problematic? The problem I can see is that it is difficult to document, thus less obvious for anyone to apply this "property". On the other hand I think having lots of properties with very specific is also making it difficult to use them properly. And weather history (P4150) is also not very obvious how to use the first time.
Even having criterion used (P1013) with "maximum" as in Q80294#P2107, seems to me like a fair use. The property is specific and the qualifier clarifies it. Is it problematic?
@Amadalvarez: Would it be possible for you to try weather history (P4150) in an example and learn more of the benefits and problems of it? Maybe it works well, otherwise it helps you to find arguments for a set of new, specific properties as is said to be the norm. Also see discussions (perhaps to find other users interested in the topic).
Thank you all for an interesting chat. I will now leave it all to you. Jagulin (talk) 07:05, 2 July 2019 (UTC)
@Jagulin:I did not propose the use of P4150. In fact, There is only 3 items with this property. So, it doesn't seem too much popular. In the discussion you linked (thanks), they talked about have a full series of climate and, finally, they created P4150. This references to external tracking events, probably may be solved with data stored on Commons. I don't know, but it was their decission and, today only 3 properties have been created that add 16 items among them.
Apart from that, I just want discrete values of something so usual as temperature in a place. Likely we have population (P1082) without having all the census month by month segmented by sex, profession, origin, incomes level, etc. etc. as it appears in official agencies. Thanks for your contributions. Amadalvarez (talk) 07:56, 2 July 2019 (UTC)
@Jura1: I find it interesting the doubts expressed by Jagulin; surely your answer would help us a lot. Additionally I affirm that the use of qualifiers to determine "when, where and how" for each one of the values, are not problematic. Qualifiers such as determination method (P459), criterion used (P1013) or applies to part (P518) allow us to handle the multi-values ​​of the properties. Obviously, the name of the property should not be too generic, except for the wildcard properties like P2670 or P793 that have saved us from creating hundreds of ultra-specific properties.
Speaking specifically on the P6591: his name is, right now, excessively specific. It is legitimate?, yes, but it would require creating as many properties as variants that someone could imagine (maximum, minimum, average, season of the year, etc.). Many of these combinations, or are not very useful or have few real values, therefore, I think they should not be admitted. I guess you'll agree on this point. Your last answer declares "P6591 is meant to store things like average and min / max temperature". I am with you in the concept and the scope. I wish to interpret that we will modify its name and its definition. Thanks. If you don't mind, I can incorporate the key points of this conversation in the Talk: P6591 to describe the change and ask for opinions in the new scope. I look forward to your reply, Amadalvarez (talk) 09:09, 2 July 2019 (UTC)
I mixed the property ids. It should read weather history (P4150). A more general property than maximum temperature record (P6591) was discussed in Wikidata:Property_proposal/average_yearly_temperature and thought to be problematic. So no, re-purposing maximum temperature record (P6591) to get there isn't a good idea. Do you see any problems with the data as entered? --- Jura 09:32, 2 July 2019 (UTC)
  • BTW, reminds me of phab:T147049. Maybe an update by the devs could help you. I think the general idea is that tabular data should be accessible on query server. --- Jura 09:32, 2 July 2019 (UTC)
Thanks, @Jura1: if you say that P6591 is questionable, I forgot my suggestions. I build infoboxes, so I think in terms of recovery full information about something, doesn't matter if it is in on item, in one monovalue property or in a multivalue property with several qualifiers to understand what each value means and represents. To me, tabular data is difficult to recover, because I get info via cawiki LUA module:wikidata and I do a few SPARQL queries. I think (may be I'm wrong), tabular data are no directly recoverable as the data value of properties. In addition, I don't need to work with series, by now. If, finally, do not delete the P6591, please consider to carry on with this discussion, thanks.Amadalvarez (talk) 16:57, 2 July 2019 (UTC)

Editing and discussions

I've been contributing to WD "by hand" for a few days now. Maybe more advanced users have a tool-assisted set up, but I'd like to share some impressions from a "new user" perspective.

  • There is a "quick insert tool box" below the editor in edit mode. It's mostly made up of symbols. I've been missing {{Ping|}} or {{re|}} for discussions. Even more important should be {{Q|}} and {{P|}} - or some kind of subst to handle either case. How to go about suggesting additions to the set? Or is there a plugin to be used?
  • Discussion pages for items rarely draw enough attention to have discussions started. Seems to be the case for help pages as well. Is the rule to have all discussion in the chat or are there certain things to be discussed on the item talk page? Maybe the talk page should be dedicated to tool output and all discussion redirected to chat? Having a search pull out all mention of the item so one knows if there has been consensus made already?

Editing WD is one thing, but learning the procedures and seeking assistance or consensus involves discussions. Making this more efficient can help improve WD overall. Jagulin (talk) 16:35, 1 July 2019 (UTC)

The edit tools below the editor are set at Template:Edit tools, but they require an admin to mark the version for translation before it goes live. --Yair rand (talk) 21:28, 1 July 2019 (UTC)
✓ Done --Matěj Suchánek (talk) 07:25, 2 July 2019 (UTC)
Thanks! I was just going to ask if it was possible to test the change in a sandbox, but I've now tested it live. Works great! There is a space before </charinsert> that I don't think is relevant, but it doesn't seem to have any effect so no problem.
Was there opposition for including Ping, or was I just not fast enough? Jagulin (talk) 07:41, 2 July 2019 (UTC)

River became a mathematical object last night

By the magic of some mysterious edits, it seems that river (Q4022) became a subclass of « history » last night, and is currently a subclass of mathematical objects. I just hope this was good faith edits. author  TomT0m / talk page 19:41, 1 July 2019 (UTC)

This morning it's mysteriously gone. --Matěj Suchánek (talk) 07:26, 2 July 2019 (UTC)
You awoke my interest... I see no trace of this in the item history and you talk about mysteries. Was it vandalism that have been hidden in history or would you think it was some kind of bug in the underlying database? Or write it off as a misunderstanding in the first place, if nobody else noticed? Jagulin (talk) 07:48, 2 July 2019 (UTC)
Probably refers to the addition of path (Q12799272) to watercourse (Q355304), where the former is a mathematical object. Ghouston (talk) 09:47, 2 July 2019 (UTC)

Wikidata Graph Builder - where can I find a description of the parameters?

I sometimes use Wikidata Graph Builder tool, but I have not been able to find any description of the parameters in general and Iterations and Limit in particular. I understand that they can be used to limit the result, but what are the exact function of these two parameters? Can anyone please enlighten me? --Larske (talk) 10:44, 2 July 2019 (UTC)

Bad constraint error

On Mecosaspis mapanjae (Q14823309) there is a bogus constraint error, because the image file name includes the string "map". Is this a worthwhile trade-off, or should the constraint be removed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:48, 2 July 2019 (UTC)

The regex includes a word boundary before "map". If it also included a word boundary after "map", there would be fewer false positives. But it is somewhat strange to constraint based on a file name which can be in any language. --Dipsacus fullonum (talk) 14:58, 2 July 2019 (UTC)
It's a very hopeful constraint; I've seen a complaint that it gets annoyed with any .*poster.* which is not affixed to a film item, because theatre posters don't exist. --Tagishsimon (talk) 15:54, 2 July 2019 (UTC)

Politico y aristócrata chileno José Nicolás de la Cerda <=> político y aristócrata chileno José Nicolás de la Cerda de Santiago Concha

José Nicolás de la Cerda de Santiago Concha and José Nicolás de la Cerda are looking awfully like duplicates to me, but a merge is blocked by two different Spanish wiki articles. Also, the birth dates are (slightly) off. If anyone from Spanish wiki could have a look that would be great. Moebeus (talk) 12:58, 5 July 2019 (UTC)

Posting a note at Wikidata:Café is a good way to find a Spanish speaker to help out. —Scs (talk) 00:21, 7 July 2019 (UTC)
I have merged the two articles, waiting for a sysop to proceed with history merge. As of the birth dates, I couldn't find any source to indicate which one is the correct. Esteban16 (talk) 01:04, 7 July 2019 (UTC)
Done now. Esteban16 (talk) 03:39, 7 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 08:29, 8 July 2019 (UTC)

English As She Is Spoke

I was editing the entry for Battle of Waterloo (Q48314) and was surprised to see an "English" and "British English" entry. I have trawled the archive to this page and came up with these discussions:

The ignorance of some of the contributors to the previous conversations are surprising, how for example can someone not be aware that there is a dialect of English called w:Indian English? I find the discussions surprising and some of the comments bigoted, particularly as these were issues addressed more than 10 years before the first archive entry above and was settled inclusively and harmoniously.

Either the two outliers English-GB and English-CA need to be scrapped, or all of the different types of English need to be included. This includes the English used in the USA at the UN and within the EU. (The English used by the UN and EU are different but based on variants of British English).

As has been pointed out in the previous conversations English on Wikipedia is dialect neutral until a dialect word is introduced at which point that dialect spelling or word becomes the default version of the language used for that subject.

It is not as if the data within articles often provides this information:

Or in the case of some where the version of English is obvious to native speakers, other templates that can be indicative for machine reading:

There is a list of the use English dialect templates at w:template:Use X English. If there seem to be too many consider using w:Use Commonwealth English and incorporate into that all the other dialects apart from American and Canadian English.

This is supposed to be a database project, adding or removing attributes ought to be easy, why has this issue not been addressed?

-- PBS (talk) 12:33, 19 June 2019 (UTC)

We probably should add more types of English labels; there are 12 variants of Chinese available here. Though written (and spoken) Chinese probably varies considerably more than English does. To see the list of available languages for labels, try creating a new item and look at the language dropdown. The process of adding languages to the list however is a bit complex right now. Items do exist for American English (Q7976) and other varieties though. ArthurPSmith (talk) 19:22, 19 June 2019 (UTC)
There was a very sparsely attended RFC on this way back in 2013 - Wikidata:Requests for comment/Labels and descriptions in language variants. My personal feeling is that we should just get rid of English variants. It can very occasionally defuse an argument in some items, but in practice it's just more maintenance overhead 99.99% of the time. Andrew Gray (talk) 20:18, 19 June 2019 (UTC)
Thanks for writing this! I agree that more variants should be supported. I'll be happy to support requests for that. --Marsupium (talk) 17:44, 21 June 2019 (UTC)

I guess this has been said before, but: I'm glad this issue hasn't been "definitively resolved", that it doesn't receive much debate, that an RFC on it was "sparsely attended". Truly, labels (and descriptions) on Wikidata are secondary, just for convenience. (Because obviously doing everything based on raw Q numbers would be a nightmare.) But we don't have to get wrapped around the axle trying to find the "right" label or description, or complaining that some entity has the "wrong" label -- and this is as it should be. (The Wikipedias get wrapped around this particular axle all the time, in part because of their visibility, in part becaue of the requirement that each article have exactly one title. I'm really glad Wikidata doesn't have that problem.) --scs 11:05, 26 June 2019 (UTC) [My point is that distinguishing between British vs. Canadian vs. American vs. Australian vs. Indian English -- important though the issue can be in some contexts -- is just really small potatoes here.]

The IETF shares your attitude, and uses a "the shorter spelling wins" rule—as a joke, no centre in RFCs, centers will do.:-) Of course copying an enwiki SHORTDESC, even it uses en-GB spelling, should be okay. – 12:31, 3 July 2019 (UTC)

Featured pictures

On the subject of images, shouldn't we allow "featured picture" or "Valued image" as a reference type? Adam Cuerden (talk) 10:49, 24 June 2019 (UTC)

@Adam Cuerden: so after a bit of investigation, I think the best option here seems to be a object has role (P3831) qualifier - it's currently used in various places, though about 500 image statements have one. It's a bit cryptically named, though....
So we'd add this qualifier to the image statement, and give it a value similar to Wikipedia featured article (Q28801937) (there is currently no item describing the concept of a "featured picture", but it would be straightforward to create one). Add a reference (to the FP discussion?) and bang, we're done.
A couple of caveats, though - firstly, this wouldn't be able to differentiate between Commons FPs or Wikipedia FPs (or which Wikipedia, for that matter) since we can't put qualifiers on qualifiers. If you wanted to do that, you'd probably need items for "Dutch WP featured image" and "Commons featured image" and so on.
Secondly, you'd have to add these qualifiers to each appearance of the image - although that would probably be an easy job for a maintenance bot.
In general, I don't see any reason not to do this - it's useful contextual information, and I can easily imagine that someone would be interested in being able to say "if there are several images, use the FP" or similar. Ultimately, it might be that the Commons linked data project (which is oriented towards information about that exact file) would be able to handle it better. But perhaps the two approaches could complement. Andrew Gray (talk) 21:09, 28 June 2019 (UTC)
On commons FP can be certified nonsense, just tweak the "scope" until only one file fits. – 15:38, 3 July 2019 (UTC)

Wikidata Bridge: edit Wikidata’s data from Wikipedia infoboxes

Hello all,

I’m happy to announce that the Wikidata Bridge project (you may have heard about before under the name “client editing”) started. The goal of this project is to offer a way to Wikipedia editors to edit Wikidata’s data more easily. This will be achieved by an interface, connected to the infoboxes, that users can access directly from their local wiki.

The project is now at an early stage of development. A lot of user research has been done, and will continue to be done through the different phases of the project. The next steps of development will be achieved by the development team working at Wikimedia Deutschland, starting now until the end of 2019.

Here’s the planned timeline:

  • From June to August, we will build the setup and technical groundwork.
  • From September to November 2019, we will develop the first version of the feature and publish a test system so you can try it and give feedback.
  • Later on, we will test the feature on a few projects, in collaboration with the communities.
    • We will first focus on early adopters communities who already implemented a shortcut from their infoboxes to edit Wikidata (for example Russian, Catalan, Basque Wikipedias)
    • but we also welcome also communities who volunteer to be part of the first test round.
    • Then we will reach some of the big Wikipedias (French, German, English) in order to see if the project scales and to address their potentially different needs.
    • Even later, we can consider enabling the feature on all the other projects.

On Wikidata, from the technical side, not much will change. When the feature to edit Wikidata’s data from Wikipedia will be implemented, a tag for edits coming from Wikidata Bridge will be added, so the Wikidata editors can watch and filter these edits more easily.

If you want to get involved, there are several ways to help:

If you have any questions, feel free to ask them here or on the on the dedicated talk page.

Cheers, Lea Lacroix (WMDE) (talk) 13:05, 24 June 2019 (UTC)

Hi Lea. Some thoughts and questions. First up, this is called a bridge, but it seems more like a shield -- trying to shield Wikipedia editors from the fact that it is Wikidata they are editing by not showing the Wikidata item, but instead a pop-up dialogue.
According to the pitch (mw:Wikidata_Bridge#The need), Wikipedia communities currently find issues over "lack of control over the data, not enough information about when and where the information is updated, differences in the way Wikipedias and Wikidata structure information".
It's not clear how the shield will help this. If information is not stored in the wikitext of wikipedia pages, bad edits on Wikidata (which will continue to be possible whether or not the shield is present) will continue to show as vandalism in infoboxes, without there having been any change to the wikitext, or any change in the page-history or in watchlists (if Wikidata notifications have been turned off). The shield if anything seems less apparent where information is held and updated, since its intention is to hide wikidata pages from casual editors. And there will continue to be differences in the way Wikipedias and Wikidata structure information, since for item-valued properties only a drop-down/autocomplete list of items will be available, rather than the free-text Wikipedia editors expect. There also remains the issue that most vandal-fighting and batch-editing power tools on Wikipedia are based on wikitext, which wikidata-based fields in infoboxes and templates will continue to sit apart from.
That's not to say that the shielded edit-interface may not be a good thing in its own terms for casual editors -- more accessible, more immediate, less scary than being thrown into a wikidata page; so the initiative I think is quite welcome. But when communities say I want the information that appears on Wikipedia to be editable on Wikipedia, it's not just the accessibility issue by/for casual editors that that sentiment is code for.
With luck more causual accessibility will mean easier good edits. But the point made by Vojtěch Dostál on the mw talk page is significant: it will also mean easier bad edits and easier vandalism, including quite subtle vandalism that may be hard to pick up (eg minor falsifications of physical constants, and other statement values that may be deliberately wrong, but not wildly implausibly so). His idea of requiring editors to be autoconfirmed before they can make shield edits is a good one.
But a further issue is that, for high-visibility high-vandal-risk edits like this, referencing and verifiability is particularly important. But there seems to be no provision for this, in the apparent development roadmap. Perhaps understandably. Creating new references on Wikidata can be quite tricky, particularly if new items for new sources would need to be created. An alternative might be to create a wikitext reference on the local wiki, and Visual Editor does have some quite developed tooling for that; but then (i) some option would be needed to allow or combine with a reference that already exists on the page; (ii) the reference would not be available on other wikis where the value might suddenly be appearing via Wikidata; (iii) there would be a danger of the value subsequently being changed on Wikidata, but the local reference for the old value still being applied to it. So local references become difficult.
There's talk of VE independence but also potential VE integration. This idea of à-la-carte access to VE-component features is quite interesting. I'm not sure if there are gadgets to give access to the VE reference-editing component without VE being chosen for the main editor. But maybe worth remembering that VE uptake on wikis is often low, sometimes very low. (I've seen figures of fr-wiki 23% use of VE, ru-wiki 19%, es-wiki 11%, de-wiki 11%, en-wiki 4%). I don't know how reliable those figures are; but on some wikis there is definite resistance to VE.
Finally, any thoughts about Commons? Is there any thought to make SDC data available editable from templates on description pages in this way? Jheald (talk) 15:56, 24 June 2019 (UTC)
@Jheald: I hope you won't consider this to be diverting your remark, and if you do please just tell me to take it somewhere else, but as I've said before mainly on Commons: I continue to believe that the best solution to this is serialization of Wikidata into (and deserialization of Wikidata from) something with at least approximately the same syntax as a wikitext template. The wikitext user would have basically the same experience as when using a template that offers name-value pairs; the content corresponding to the template's name-value pairs would actually reside in Wikidata. This is not necessarily exclusive of the current proposal, which may be easier for less techincally oriented users, but should be available for those of us who prefer to work with wikitext. - Jmabel (talk) 22:55, 24 June 2019 (UTC)
@Jmabel: I once thought that's what should be investigated, particularly for editing SDC via something close to wikitext edits on existing templates. But I am not sure it's so easy. Serialisation, from wikidata/SDC to wikitext, might be relatively easy. But the reverse is not -- data reconciliation from strings to wikidata items is a real grind, for which I really don't see any shortcuts. Any idea that one could just make arbitrary wikitext edits in the template, and leave it to the software to convert that into wikidata updates is just not realistic. I don't see any way round manual disambiguation (or manual confirmation that really no wikidata item exists). Without such intervention the best one could generally probably automatically get to might be somevalue stated as (P1932) "string". But that's not really good enough. Alternatively, one could accept a wikitext update to a local value, but then tag if it didn't match SDC/Wikidata, in some way that could be automatically retrieved at scale. That might be more promising, but it probably does make sense to try to get casual manual editors to directly choose a wikidata value if possible instead. Jheald (talk) 23:28, 24 June 2019 (UTC)
It probably can't be done universally, but for a lot of properties it should be easy:
  • Image links.
  • Things that actually are strings (e.g. captions; URLs).
  • Things with a reasonably limited domain, e.g. dates, simple numbers.
  • It's only a little tougher to do amounts of money (because a currency qualifier is needed) and physical areas (unit of measure qualifier)
  • We could have a syntax available so that any item that already has a Wikipedia article of its own wikilink can be referenced via the name of that article, or Wikidata items could, of course, be referenced directly. Especially for the latter (and perhaps for the former) it would be nice to have a search tool available during editing: not trivial, but not prohibitive.
That right there is easily the majority of cases.
This wouldn't be trivial to do, and obviously, there is a bit of calculation involved in the deserialization, and it would doubtless introduce a step of coming back to the user to deal with anything unparseable or ambiguous (much as Commons already has to warn about various upload problems), but I believe it would be tractable. Certainly tractable enough to merit some investment into looking at the potential. - Jmabel (talk) 04:06, 25 June 2019 (UTC)
I think it's only easy for those when you ignore the fact that good statements are sourced. This is in particular true when the big Wikipedia's don't want to read unsourced date values from Wikidata. ChristianKl❫ 10:09, 25 June 2019 (UTC)
Interestingly, infobox values at Wikipedia have rarely a source indicated ;)
Reminds me to repeat: make sure not to overwrite or "correct" sourced Wikidata statements when editing from Wikipedia. --- Jura 13:17, 25 June 2019 (UTC)
Even if it's true, they will still hugely complain if we want to install a Wikidata Bridge on their Wiki that brings unsourced claims with it. ChristianKl❫ 13:48, 25 June 2019 (UTC)
On wvwiki, infoboxes about persons are often unsourced as such. But they are often regarded as secondary to the text. And the text have to have sources. Complaints often comes when the infobox and the text tells different things. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 13:54, 25 June 2019 (UTC)
For most wikis that is probably true. Supposedly some even discuss diverting dates/info. Still in some wiki, user mention the source only in the edit summary ;)
Anyways, if the bridge is set up for editing/adding, it could be less an issue. Besides, many of the larger wikis may feel that they can't do all updates locally. --- Jura 14:03, 25 June 2019 (UTC)
All info in the lede and an infobox has to be covered by RS in the body, otherwise it should (or for a BLP must) be removed. For info from Wikidata "unsourced" is clear (=unusable, remove). The R in RS is undefined, e.g., reference URLs can be anything. – 12:54, 3 July 2019 (UTC)
c:Module:Creator, c:Module:Institution and c:Module:Artwork do something quite similar to this. They compares the templates' fields to Wikidata's data and if it's missing here composes a link to QuickStatements that allows adding them. That functionality is open to extension. Currently, only Commons will be added as a source. --Marsupium (talk) 10:55, 25 June 2019 (UTC)
You have to be aware about one important difference here. On Wikipedia we tend to update data by simply replacing it. Here we add new data and change the ranks. Its doable, but the developers have to know what they are doing. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 13:07, 25 June 2019 (UTC)

Hello all, and thanks for your feedback. Let me answer on a few points:

  • About Commons and other projects: if everything goes right, the system that we will develop can work on projects using similar templates. Because the need emerged primarily from Wikipedia communities, we'll focus on them for the first versions, but at any moment we can consider experimenting with other projects, if the template builders are willing to.
  • As we are aware that references are extremely important for the data quality but also the acceptation of Wikidata's data by Wikipedia communities, we'll make sure that they are present, at least in a simple form, since the first version. Later we can develop more complex checking systems.
  • Just to make it clearer: nothing will be enforced on Wikipedias. We will offer to the template builders a possibility to update the infoboxes to make them have the Wikidata Bridge option. We will encourage the communities to go step by step (eg start with only one Wikiproject) and see how it goes.
  • About replace vs update data: yes that is one of the tricky pieces, and we hope that we can boil it down to a few standard cases that lead to distinct edit flows on Wikidata (add new value, change rank, ...). We hope we can then let the template creator chose which of those standard cases applies to a particular template parameter. The editor would then just have to say if they are fixing a typo or adding something new as shown in the mockups. We'll test it in the next versions and see if it works out.

Cheers, Lea Lacroix (WMDE) (talk) 08:27, 27 June 2019 (UTC)

@Lea Lacroix (WMDE): Something is missing in the description of the new tool (or perhaps I didn't find it): the rules of the process used in data selection.
How the tool selects statement when several values are available ? When a preferred rank is used among other normal ranks, this is simple, but when several preferred rank values are present or several normal rank values without a preferred one, how the tool will select a value to be updated/changed ?
If I understood the principle, the tool will change one value but not necessary the value displayed in the infobox: if the extraction rule of data from WD is managed by other rules than the rank one (for example, statement selection is based on reference type in WP side by using a lua programmation), then wikipedians will spend time trying to update the value but not the one used by the infobox. How do you plan to overcome that situation ?
What happens if someone changes the value of a referenced statement ? Does the reference stay or is deleted ? If a referenced statement is wrong or outdated, then the value shouldn't be changed but a new statement created with rank lowering for the existing statement.
Someone see a data in an infobox which is not the usual one because the data selection of the Wikipedia template was defined in a particular way. Contributor will create new statement which perhaps already exists (duplicate) just because he is not able to see all existing statements in WD.
For me that kind of tools is not a good idea because he is not linked to what the contributor is reading: there is no link between the data which can be modified by the tool and the data displayed by the template. Rule for data selection is not only based on rank, date or reference type.
Unless a better description of what is done by the tool, I think we are going in the wrong direction by developing that kind of tools which are not able to provide all information about what is displayed in the infobox and which statement will be modified in WD. Snipre (talk) 12:25, 28 June 2019 (UTC)
@Lea Lacroix (WMDE): To be a little more constructive, I can only advice you to consider a complex case with several statements for one property, with different values, and several references and several qualifiers for each value:
Example, heat capacity of a chemical with different values, different units, different qualifiers (temperature, state), et different reference data
value unit qualifier 1 (temperature) qualifier 2(state) reference data 1 (stated in) reference data 2 (page)
2.01 kJ/kg °C 25°C liquid CRC Handbook of Chemistry and Physics 3-21
Determination of heat capacity of XXX (scientific article)
2.015 kJ/kg °C 20°C liquid CRC Handbook of Chemistry and Physics 3-21
1200 Btu/lb °C 25°C liquid New determination of heat capacity of XXX using quantum chemistry (scientific article)
1.75 kJ/kg °C -100°C solid The latest values in chemical engineering 150
This table should be displayed by you tool before wikipedian can only try to modify something in WD. Snipre (talk) 13:35, 28 June 2019 (UTC)
  • Let's see how it goes. The default should probably be "add the new value with preferred rank". --- Jura 13:31, 28 June 2019 (UTC)
@Snipre: Thanks for your feedback. We've been thinking about this, and we're still trying to figure out the technical details, and how to display all of this information in a nice and readable way in the interface. Lea Lacroix (WMDE) (talk) 08:15, 2 July 2019 (UTC)

Disambiguations in aliases

Hello. Some people add Wikipedia article names to aliases (diff) to make item searching easier for them. I have tried to find if it is allowed or disallowed in rules (Help:Aliases, Help:Label), but failed to do so. Please help me to understand consensus on this topic and modify rules accordingly. — Vort (talk) 08:29, 28 June 2019 (UTC)

I don't know that there is a consensus, one way or another. The full search will, AFAICS, return the item at the top of the results list if the sitelinked title is searched for - example: - but the search box dropdown does not list the article when the sitelinked title - John Smith (architect) - is input; and it would if the sitelinked title were included as an alias. So a case can be made that it is a useful thing to do. Again, AFAIK, labels, descriptions and aliases are there for the convenience of users, whereas statements and qualifiers are the rigorous structured data; and so my view, fwiw, is that we should be relaxed about users exercising the option to include what might from many perspectives be thought of as superfluous aliases. In the scheme of things, I don't think any harm is done. (Obvs, because this is a wikipedia project, others may hold different views.) --Tagishsimon (talk) 10:33, 28 June 2019 (UTC)
I see that item appears in search. Better example is "Ивановка (Теренкольский район)". But there are no appearance when user adds item as property value (most likely, the same mechanism is used as in search suggestions). So I think better solution is adding of titles as virtual aliases for all usages inside Wikidata engine. — Vort (talk) 14:36, 28 June 2019 (UTC)
Let me clarify the example to save others from doing the investigation to understand the details:
"Ивановка (Теренкольский район)" article is page for Q16654862. Still, the item does not appear when [ searching for "Ивановка (Теренкольский район)".
Item does appear in dropdown and search or "Івановка (Теренкольський район)" (which is a label in 'uk') or "Ивановка (Kazakstan)" (which I added as "also known as" for 'sv').
Item appear does not appear in dropdown, but probably in search, for "Siedlung in Kasachstan" (a description text for 'de')
Dropdown shows the description text too, and matching "alias". Description text included only from the current view language or from English (e.g. Q1374309 in 'ru'). Left out if both blank. If item label is blank for current language, item title taken from English (e.g. Q1374309 in 'ru').
Searching seems to match any language, regardless of set language. Q-number is an alias automatically.
The advanced search method "pages in this language" doesn't seem to have any use on WD. Trying both 'ru' for Q16654862 and 'de' for "Siedlung in Kasachstan" give zero matches. It thus neither matches items having Wp for a specific language, nor the description in a specific language. --Jagulin (talk) 17:14, 29 June 2019 (UTC)
I don't think that adding Russian Wikipedia article names to Russian aliases is a problem — it breaks nothing. However, I consider it useless to add foreign names to obviously inappropriate labels like Special:Diff/969490993 or Special:Diff/120755985. Сидик из ПТУ (talk) 14:06, 28 June 2019 (UTC)
Duplication is always a problem. If one instance is changed, second should be changed too. And almost always no one cares about it and incorrect duplicate stays in data for years. — Vort (talk) 14:21, 28 June 2019 (UTC)
I agree that duplication causes a maintenance problem. Time spent when pasting the "alias" in addition to the time spent by the community to maintain it needs to be considered if there is a guideline about this. A better solution would be a change in the software, to include each language URL in the search and dropdown list generation. Did anyone create such a suggestion?
The second problem to consider is how to make item selection in dropdowns efficient. "John Smith" gives lots of matches and there is a lead text. Having even more items matching in the list, if adding several alias, is perhaps not optimal. --Jagulin (talk) 17:14, 29 June 2019 (UTC)
Titles can be used as aliases if other data sources generates no (or small amount of) suggestions. — Vort (talk) 19:59, 29 June 2019 (UTC)
@Vort: If you still meant that it should be done automatically by the system, rather than by volunteers spending time on it, I agree. Did you create a tracker for the suggestion, to get developer feedback? Or did you man that it's already working like this? Jagulin (talk) 07:03, 3 July 2019 (UTC)
@Jagulin: I have created phab:T227170. — Vort (talk) 07:25, 3 July 2019 (UTC)

F1 races module


Is possible to create a module, as Cycling race, for F1 race, to not edit the result for all Wikipedias, but include the results and edit once for have the one result for all Wikipedias, and Wikinews.

Thanks, Aabbccddeeffabcdef (talk), the 15:32, 30 June 2019 (UTC).

Post scriptum : I'm French, so my English is not very good (level 2).

@Aabbccddeeffabcdef: Is it possile ? Yes, but for that you need to ask help in the wikipedia you want to implement that module. Wikidata is not responsible of the data use in Wikipedia and as each WP has different rules and different tools for data implementation from WD, there is no unique solution. Snipre (talk) 04:44, 1 July 2019 (UTC)
Avoiding the need to maintain raw data in each language Wp sound like a good idea if you have some users with you. Even if not easily solved, if you have a "Cycling race" module you should try to make contact with anyone in charge of that. They could probably assist in technicalities and clarify how much problem they've seen. Even if each Wp is different, it should be possible and beneficial to make a module generic enough to be used across language and style. "Commons" may be a place to work independently from Wp. Each Wp then picks it up when they see fit. Jagulin (talk) 12:05, 1 July 2019 (UTC)
Even if I agree with the comment of Jagulin, I can only remark a point: a lua module require the use of general template to extract data from WD and to format them (example: references). The main general templte for that is module:Wikidata. But this module is not the same for each Wikipedia. So you have 2 possibilities: use an existing general module and then you are limited by the module used in your Wikipedia or creat your module integrating all basic features for data extraction from WD. The best is to contact the person who wrote the module Cycling race to see how this module is independent of other modules. Snipre (talk) 15:59, 1 July 2019 (UTC)
Many people have contributed to Module:Cycling race. It is working indpendent of other modules so it can be copied to and used in any Wikipedia. To do something similar for some other area, you or the persons writing the module will need to be able program in lua, know how lua is used in MediaWiki (the Scribunto extension), and know how to access data from Wikidata. The module will need to access data from many different Wikidata items to compose its tables. That can use a lot of resources, so it is important to do this as efficient as possible to avoid timeouts or other resource limits. Also design the module to have translations and configuration in separate submodules. Module:Cycling race have some problems caused by some less than good design decisions in these areas. I would be able to give some advice on how to do such things. Keep in mind too that it only works if someone input all the needed data to Wikidata. That can also be a lot of work in it self. --Dipsacus fullonum (talk) 16:48, 1 July 2019 (UTC)
Thanks for sharing, Dipsacus fullonum, it was exactly the helpful guidance I expected to see. I never meant to say it was easy, but if there is a strong community interest it could be done. In the end, it should save effort to not maintain language-independent data on each Wp, and having even a first draft module may be the only way for people to take that step. At least, I hope that's the result seen in Cycling. There is of course a chance that "the normal wikipedian" stops contributing since WD and interwiki is too scary for them. A quick look to the Cycling module discussions it looked generic to other type of seasonal racing, but I understand it's unfortunately more work to be more generic too.
@Snipre: Even if there are historic Wp-specific modules, I don't see any reason to make a new model anything less than generic. Do you know if there has been plans to introduce a new "basic module" (abstracting some f the lower level programming work) that would (or could easily) be available on all mediawiki? It would still be a community decision to accept the specific inclusion, use and configuration of each template, but new modules would have a base to start from. Jagulin (talk) 09:24, 3 July 2019 (UTC)
@Jagulin: To create a module in WP using data from WD you need 3 things: a set of extraction tools, a set of data format tools and the module itself which organizes the data in the wikitext. The main proble is that extraction tools and data formatting tools are different between WP, because each community develops code according to its need. But this influence the way you access the data in your module code so you can't create a generic module because the interfaces between the module and the extraction/formatting tools are different.
There is no plan to generate generic code for all WPs because WPs want to keep the lead on that code which influences their templates. Snipre (talk) 10:05, 3 July 2019 (UTC)

Wikidata weekly summary #371

Quick The DJ List artist ID (P6935) plausibility check on Sasha Grey (Q2709) with the expected result spam.:-( 13:38, 3 July 2019 (UTC)

P6546 requires constraint on data

There should be a constraint on this preventing it from being a negative number, which is not possible. Whether by data entry or import error, it seems possible to be entered as one, such as here Q1852981 CanadianCodhead (talk) 15:57, 2 July 2019 (UTC)

You could try and see if format constraint (Q21502404) and format as a regular expression (P1793) works on penalty minutes in career (P6546). Multichill (talk) 17:29, 2 July 2019 (UTC)
Or you could use range constraint (Q21510860) (documentation). --Lucas Werkmeister (WMDE) (talk) 10:34, 3 July 2019 (UTC)

I used a format constraint (Q21502404) to set a regex pattern career plus-minus rating (P6547) values must conform to. Two things now: 1) can someone double-check my regex? I've used "-?\d+" to catch any positive or negative integer; 2) I'm seeing an error now on pages where this property is used, "Properties with constraint 'format constraint' need to have values of type 'String' or 'Monolingual text.'" Does anyone know how to change the value type to string? The data type for career plus-minus rating (P6547) is currently "Quantity" and I can't figure out how to change it. On a related note, I used a range constraint (Q21510860) to specify that the value for all the other properties I've employed for hockey statistics -- total goals in career (P6509), total assists in career (P6545), total points in career (P6544), penalty minutes in career (P6546), and total shots in career (P6543) -- can only have a minimum of zero, and thus shouldn't get mixed up with +/- values. LesserJerome (talk) 12:27, 3 July 2019 (UTC)

entries for social media user names

It seems like the social media user names for Greta Thunberg and Luisa Neubauer in their wikidata entries are changed again and again - but only the capitalization of some letters is changed. As far as I know the capitalization of letters in user names is irrelevant. Only the aricle history gets longer and longer. Would it be possible to have a filter that does not allow edits that only change the capitalization of social media user names? --C.Suthorn (talk) 17:27, 2 July 2019 (UTC)

Sounds like a textbook job for protection. Circeus (talk) 02:33, 3 July 2019 (UTC)

Creating an item for an author of multiple items

I was gonna create an item for Li Dongrong 李东荣, a Chinese central banker, then I found five papers: special:search/"李东荣". Is there a neat way (a script or program?) to create the item and migrate author name string (P2093), or create the item from the P2093?--Roy17 (talk) 11:34, 3 July 2019 (UTC)

You can try [2] --Stevenliuyi (talk) 14:11, 3 July 2019 (UTC)

Change in the name pattern of new Wikidata RDF dumps

Hello all,

Starting on July 15th, the name of the RDF dumps will be changed to remove the "beta". For example, the file that would have been named wikidata-20190717-all-BETA.ttl.bz2 with the former name format will be named wikidata-20190717-all.ttl.bz2.

This will only impact the new generated dumps, not the previous ones.

If you have questions or issues, feel free to ask on the Phabricator ticket. Cheers, Lea Lacroix (WMDE) (talk) 13:30, 3 July 2019 (UTC)

No JSON dumps for the weeks of June 24th and July 1st

Hello all,

Due to technical issues, the JSON dumps for this week and last week couldn't be properly generated.

  • 20190624 because of a commit that was fixing another bug (phab:T226601)
  • 20190701 due to an issue with qualifier hashes (phab:T227207)

We apologize for this inconvenience. The problem is about to be solved, so we expect the situation to be back to normal next week. However, we will not generate the previous failed dumps.

Thanks for your understanding, Lea Lacroix (WMDE) (talk) 17:37, 3 July 2019 (UTC)

instance of(P31) or subclass of(P279) pseudoscience(Q483677)?

Querying everything that has been labeled instance of(P31) pseudoscience(Q483677) there is 1 result: Bach flower remedies

Querying subclass of(P279) pseudoscience(Q483677) there are more results. Regardless of how many hits I get with any of these, should I do instance of or subclass of for this item? blood type personality theory.

Also having read the Help:Basic_membership_properties I didn't completely get yet the difference between instance of and subclass of an item. Ελλίντερεστ (talk) 20:32, 2 July 2019 (UTC)

Bach flower remedies (Q788110) would be a class. One particular glass of such a solution sitting on your table would be an instance. Whether it's really a subclass of pseudoscience I'm not sure: I think that's saying it's a field of pseudoscience, in the way that organic chemistry (Q11351) is a field of chemistry (Q2329), and has been made a subclass. potassium compound (Q12547983) isn't a subclass of chemistry, or of science in general. Ghouston (talk) 04:55, 3 July 2019 (UTC)
It could be a subclass of homeopathic drug (Q50092815). Ghouston (talk) 06:58, 3 July 2019 (UTC)
In most cases subclass of (P279) would be more appropriate here. When adding claims as something being a pseudoscience I would recommend that you add sources for that classification. ChristianKl❫ 21:01, 3 July 2019 (UTC)

New item: central banker?

Should there be an item of the occupation(?) central banker (akin to investment banker (Q2883465))? There is Category:Central bankers (Q8353786).--Roy17 (talk) 20:26, 3 July 2019 (UTC)

This data is stored using a combination of central bank (P1304), office held by head of the organization (P2388), and position held (P39). --Yair rand (talk) 20:52, 3 July 2019 (UTC)
See Mario Draghi (Q294460) and President of the European Central Bank (Q605440). Xaris333 (talk) 21:02, 3 July 2019 (UTC)
As Yair points out, "Central banker" is not really an occupation (economist (Q188094) would be more typical) and this is usually handled via position held (P39). That property doesn't work too well when defining category contains (P4224) (you can't structure it as you can for, say, Category:School principals and headteachers (Q8709447)). Was that the actual issue you were trying to get at, @Roy17:? I think skipping the "human" level for it can work: category contains (P4224) director (Q1162163) / of (P642) central bank (Q66344). Circeus (talk) 21:11, 3 July 2019 (UTC)
I know they are usually regarded as economists, but IMHO central banker could be a profession, being a special type of government economists as well as a special type of bankers. They are economists that have real power, such as influencing monetary supply. They are bankers who dont work for profits of a corporation but the well-being of a country's economy. I was just hoping to see objection to this item.--Roy17 (talk) 21:49, 3 July 2019 (UTC)

Date of birth reference

We now require a reference for date of birth, but not, for instance, date of death ... was their a discussion for that? I can see requiring it when we have contradicting dates, as sometimes happens, especially for early historical people. --RAN (talk) 23:56, 29 June 2019 (UTC)

It's just a suggestion, see: suggestion constraint (Q62026391): status of a Wikidata property constraint: indicates that the specified constraint merely suggests additional improvements, and violations are not as severe as for regular or mandatory constraints. Multichill (talk) 09:46, 30 June 2019 (UTC)
Coming from Wikipedia traditions I'd like to stress verifiability. Help:Sources allows unreferenced sources as an exception only. References are not to prevent criticism, but to allow it.
Spreading knowledge is of course always useful. @Tidoni: Can you share background to the change in date of birth (P569)? Recently copied to date of death (P570) too. Why are only some properties marked like this? Jagulin (talk) 13:00, 30 June 2019 (UTC)
The lack of a references last year led to a purge by some people of "ethnicity" and "religion" in entries. They were applying English Wikipedia rules to Wikidata. Again, I think it only needs a reference when we have two conflicting dates, each date should be referenced so reader can judge which one is canonical. A quick search shows we have >5,000 with multiple birth dates in the field. There already are several bots that scrape other databases for matching birth and death dates and add in the reference here at Wikidata. --RAN (talk) 19:03, 30 June 2019 (UTC)
No, I don't think they were applying Wikipedia rules, but the Wikidata policy on Living people as they may and should. --Dipsacus fullonum (talk) 08:58, 1 July 2019 (UTC)
If this is about living people, then why was it just expanded for the death date? --RAN (talk) 23:05, 1 July 2019 (UTC)
RAN, obviously having both verifiable birth date and death date is useful to judge if a person is living, but don't mix "reason for deletion" with "reason to have source". Thank you for highlighting that date of death was missing the symmetric enforcement. WD is, as most community driven projects, evolving in an iterative manner. I think it's very good that WD is at a point where promoting quality is possible. To me it's not at all dependent on "living person" policy, but person category is a large and important part of WD, so a good place to build quality and consensus. Jagulin (talk) 07:25, 2 July 2019 (UTC)
which was copied from BLP, QED. the venue may change but the deletionism is the same. you will not increase referenced statements by deletion. Slowking4 (talk) 12:00, 1 July 2019 (UTC)
@Richard Arthur Norton (1958- ): I was not promoting purge, but saying that Help:Sources and Wikidata:Introduction are clear: WD is supposed to be "A secondary database. Wikidata records not just statements, but also their sources". This is WD consensus, not enWp. Out of curiosity: Could you point at any Wikimedia project that have the policy you describe?
  • A source alone would require a fairly large amount of work to asses. For an automatic process it might be very difficult to judge the statement validity. There are however properties you can set on a contended statement (e.g. disputed (Q18912752)). A perfect knowledge system is perhaps a utopia, but we should not actively make WD guesswork.
  • What guideline says: only needs a reference when we have two conflicting dates? When that second date is entered it would be harder to find the source for the first date since we can't know where you found it.
  • You say bots add in the reference and I can only see that as a support for the need of references. Whenever there is no reference (added by bot or directly) the statement is IMHO unsourced and assumed to be speculative. Also if bots are good enough to actively add sources to correct persons, they could also add the date themselves. No need for you to do only half of their job. And "date of birth" is only a special case. The general case is that there are no bots that qualify all statements in WD. The contributor should do that.
I hope you now agree to the reasons and WD consensus for documented sources. -- Jagulin (talk) 10:27, 1 July 2019 (UTC)
  • Most claims should have a reference, especially P570. There just some that must have a reference already when first added. --- Jura 09:34, 1 July 2019 (UTC)
"Most claims should have a reference", then why this field and why now? --RAN (talk) 23:03, 1 July 2019 (UTC)
  • Wikidata has Living people. In contrast to Help:Sources, it's a policy. It's worth reading the policy as it specifies what classifying a property as property that may violate privacy (Q44601380) does and the process for challenging it's application to a property. As long as it's on date of birth (P569) I can understand having the constraint there. If you don't think it should be there, voice your opinion on the talk page.
I see no good reason to have the constraint for date of death (P570) as I don't see what makes date of death (P570) specially worth protecting. ChristianKl❫ 11:29, 4 July 2019 (UTC)

Took the place 2,5 years after the elections

Q64959563#P39. See the statements 1 and 2. In the first one he (the item) was elected at the day of the elections. In the second one, he wasn't elected the day of the elections. He was runner up. After 2,5 years the person who won resigned (he became a minister) and the item took his place in the parliament. Reading the statement, there is a gap between the elections new parliament start day (1996) and the start day of him as a parliament member (1999). Am not sure if someone can understand why. Xaris333 (talk) 21:17, 1 July 2019 (UTC)

  • You might be better served with a normal statement structure, one where the "start date" indicates the start date and the "end date" indicates the actual end date. --- Jura 21:26, 1 July 2019 (UTC)
But, this structure is already served. The "start date" indicates the start date and the "end date" indicates the actual end date. Xaris333 (talk) 21:47, 1 July 2019 (UTC)
As the guy is known to be immortal and stick to his seat? --- Jura 21:52, 1 July 2019 (UTC)
Sorry, I can understand the comment. Xaris333 (talk) 22:23, 1 July 2019 (UTC)
Instead of adding the start and end dates to the term, you add it to the position statement(s) of the person. --- Jura 22:39, 1 July 2019 (UTC)
Example? Xaris333 (talk) 22:47, 1 July 2019 (UTC)
I think all but one date. If the guy holds the position from 1991 to 1996 and from 1999 to present, there are just two actual start dates and one actual end date. --- Jura 22:57, 1 July 2019 (UTC)
But this has nothing to do with my first question. Xaris333 (talk) 23:07, 1 July 2019 (UTC)
If you wouldn't use fictional end dates, I don't think you would ask yourself the question. Election date and actual start date is rarely identical. --- Jura 23:09, 1 July 2019 (UTC)
You misunderstood or I wasn't clear, sorry. I don't use the election day as a start day. I use as start day the day they new parliament member starts. For example, election day was 22 May 2016 and the start day as parliament member was 2 June 2016... The "problem" is that the new parliament start at 1996 and he became parliament member at 1999. I am asking is that a problem the way I added the statement. Xaris333 (talk) 23:38, 1 July 2019 (UTC)
Did this person take the office because they were second in this years-earlier election? Or was that basically coincidence (or even a motivating factor in, but not legally the cause of them taking office), and this is like any time someone is appointed to a normally elective office? - Jmabel (talk) 05:19, 2 July 2019 (UTC)
The party won 1 seat in the parliament to that district. The person came second. So he didn't elected. After 2,5 years, the person who came first became a minister. So he quit from the parliament. According to the law, the seat is going to the person who came second in the elections. Xaris333 (talk) 06:47, 2 July 2019 (UTC)
We have a similair system in Sweden. I know from svwp, that such persons are not considered "elected" at all. Instead thay are seen as "Ersättare", . They have a seat in the parliament for shorter or longer period, but they often seem to lack the legitamacy an "elected" parliamantarian has. A user from svwp would then probably not add elected in (P2715) at all. But I do not know if that would be right here. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 07:19, 2 July 2019 (UTC)
The gap should not cause any problem. I would agree that it's an option to leave out elected in this case, yet having it as is seems perfectly fine, but not familiar with they specific system. If the source shows the person elected to be successor, that's all good. The way it was described (as well in Sweden) I would not dispute legitimacy, the person was still appointed by vote.
Possibly off topic: No related property found. Q10488457 and Q10684100 have hardly any links but would be variants of "ersättare". substitute (Q3504856) (french) and deputy member of the Parliament of Norway (Q16159375) seems to be intendedly country specific, though I don't see exactly why. I was surprised not to find any "successor/replacement" item. Relevant to make sure if it is a strict successor or also temporary stand-in when needed: substitute (Q29863201). runner-up (Q3275569) might indicate a successor-type of role, but most likely not. Jagulin (talk) 08:54, 2 July 2019 (UTC)
Q12009014 is a substitute for a member of a parliament as described in nowiki. --Dipsacus fullonum (talk) 10:01, 2 July 2019 (UTC)
Now merged with "Ersättare" from svwiki Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 08:20, 3 July 2019 (UTC)
Brought the off topic part up in noWp already. Jagulin (talk) 07:56, 4 July 2019 (UTC)

Thoughts about Wikidata

(Sorry for my English). I often realizes that Wikidata is a place were every user can do anything he/she wants. For similar subjects, they add different properties to say the same things. Everyone uses different structure and models. We don't have a common politic, manuals or examples... There is a mess... But we have thousands of users that contributes every day, we have bot and useful tools. But still we have a lot of problems... (And that problems make problems to Wikipedia also with the use of data of Wikidata to Wikipedia templates). That is Wikidata we want? In my opinion there are two ways:

1) Continue the same way...

2) Try to create common politic, manuals or examples. To discuss and find finals models. I know, there will be disagreements. But if the community agree to a model about a subject, then the users who have disagreements they have to accept the model... And of course we will need time to correct the items according to the model, but at least we will have a model that we can base on it to make corrections, to complete new items, to give examples to new users... And with the help of bot and tools, one day everything will be OK. I hope so...

Just some thoughts. I am not so expert in Wikidata and I don't use English language with perfect way, so I can't help as much I want, but I want to try... Or maybe I am wrong and there is no problem at all... Your opinion? (We need practical suggestions, not only theoretical). Xaris333 (talk) 22:48, 3 July 2019 (UTC)

We do have common politic, manuals or examples, such as Wikidata:WikiProject ShEx or Wikidata:Showcase items; or Wikidata:WikiProject Books#Work item properties and Wikidata:WikiProject every politician/Political data model, to give just two examples. We also have users who find it easy to criticise established practices, but who are slower to come up either with reasoned arguments to support their criticism, or with practical improvements; and users unaware both of extant models and of work done to promulgate such models, and who would wish us to reinvent what we already have. --Tagishsimon (talk) 23:04, 3 July 2019 (UTC)
  • There are many cases where we don't have established standards. The way to get established standards is to write them on the relevant Wikiproject and seek consensus there. Afterwards when you have consistent documentation of a standard on the Wikiproject it's possible to talk to the people who violate the standard. Sometimes this will mean that the people will reopen discussion about standards but the process of talking to people about the standard is the way you get people to adhere to a common way to model a domain. This means that there need to be people who care about enforcing standards for a given domain. For cases of more global standards it requires people writing RfCs. ChristianKl❫ 11:32, 4 July 2019 (UTC)
This keeps coming up. See the previous discussions "schema again" and "Glossary of topics on how to structure data". I'm sure Shape Expressions are the way of the future, but I suspect it'll be some time before they're fleshed out & in widespread use. I've been doing some work to try to come up with simple tables describing the common claims and qualifiers to be used to describe common entities (people, cities, rivers, etc.), but my work got interrupted by a computer crash so I don't have anything to show for it yet. —Scs (talk) 14:30, 4 July 2019 (UTC)

Wanted - someone to adopt a discontinued bot

The en:Wikipedia:WikiProject Women in Red is looking for someone who'd be prepared to run a bot, the owner of which has recently retired. The bot is described at d:Wikidata:Requests for permissions/Bot/Emijrpbot 6, which points to code here. The function of the bot is to add new wikidata items for new biographies and/or to add human and/or gender statements to existing wikidata items, based on articles found on en:Special:UnconnectedPages. WiR bases all of its metrics (& these) on wikidata records for articles, and since end April the project's stats have become increasingly hard to compile. We'd be more than grateful if someone would consider picking up this thankless task; thx. --Tagishsimon (talk) 17:44, 3 July 2019 (UTC)

(Really, I should not be taking more such responsabilities but here I go) If that would be welcome then I may be up for that − unless you find someone else of course :) Jean-Fred (talk) 21:24, 3 July 2019 (UTC)
If Jean-Frédéric can't do it, then I might be able to persuade Pi bot to help. Thanks. Mike Peel (talk) 21:33, 3 July 2019 (UTC)
Thx both; I have to leave it to you to decide. J-F - you know it makes sense; what could go wrong ;) --Tagishsimon (talk) 21:43, 3 July 2019 (UTC)
  • Personally, I do some of them once in a while, but, as I'm working with PetScan, this isn't possible any more. --- Jura 15:50, 4 July 2019 (UTC)
@Tagishsimon: It's nice code! I've merged it into one file at [3] and set it running, see Special:Contributions/Pi_bot. Unless there are objections, then I just need to know how often you want it running. If @Jean-Frédéric: wants to take this on, though, then I have no objections. :-) Thanks. Mike Peel (talk) 18:04, 4 July 2019 (UTC)
Could it add full dates instead of just years? e.g. at Q65032839, Q65032842, both linked to articles with actual dates. --- Jura 18:14, 4 July 2019 (UTC)
@Jura1: It currently uses the categories to get the birth/death dates, not the text. It should be possible to change that, though, I'll investigate. Thanks. Mike Peel (talk) 18:27, 4 July 2019 (UTC)
@Jura1: done, as long as the enwiki article uses en:Template:birth date and age. Thanks. Mike Peel (talk) 19:21, 4 July 2019 (UTC)
Excellent! Thanks. --- Jura 19:27, 4 July 2019 (UTC)


albedo (P4501) has image (P18) as a constraint. It is probably rarer that we have (downloaded) pictures of a celestial body than that we don't have. Could it be downgraded to a recomended property instead? Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 07:05, 29 June 2019 (UTC)

@Arbnos: You added this constraint. Any comments? item requires statement constraint (Q21503247) description says "should". Is mandatory constraint (Q21502408) enforcing it more strongly?
I don't know astronomy, and have hardly any wisdom of WD structure design, but I also noticed this as a bit tough. There must be lots of sources for albedo where there is no free image to use. Is the image meant to be a graph, such as in albedo (Q101038)? Maybe even "allow" is enough?
parent astronomical body (P397) is also required. Maybe meant to be the star related to the item, but AFAIK the albedo is not strictly bound to having a "parent". And the Moon (Q405) has albedo, and parent Earth.
Were the constraint meant to be on "albedo qualifiers" rather than on "item properties"? And should they be mandatory in that case? Jagulin (talk) 16:03, 1 July 2019 (UTC)
@Jagulin: Hello! The image I added when the property had limited use and it seemed that the absence would be an exception, so it can be removed.--Arbnos (talk) 16:20, 1 July 2019 (UTC)
@Arbnos:I take that as support for removing the image constraint entirely and I agree. I believe you also added parent astronomical body (P397) constraint and the existing exception. I suggest remote those too. What do you say about it? What is the meaning of the constraint? Jagulin (talk) 05:48, 2 July 2019 (UTC)
@Jagulin:Yes, you can delete the image. As for parent astronomical body (P397): the description of the property, like all asteroids, for example, should be the parent of warm Sun, even a "star" to be synonymous worth it.--Arbnos (talk) 17:57, 2 July 2019 (UTC)
We have objects about thousands of minor planet and comets. Since (with one single exception) all of them have Sun as parent astronomical body (P397), it maybe looks a little redundant to add this statement to them all. But as it is doable, so why not? A bot/script could add it everywhere for every comet or minor planet without causing any problems at all. Yes, there are many comets who do not circle around the Sun today. But at some point they have at least been doing that. Not a single one of them (yet) have seemed to have a foreign background. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 19:35, 2 July 2019 (UTC)
@Arbnos: I removed the image constraint, as agreed. About my other suggestion:
  • "parent astronomical body (P397): major astronomical body the item belongs to" says nothing about "parent of warm Sun" (nor "child" which I guess you meant). I already mentioned Moon (Q405) as a counter-example, but there are plenty.
  • "albedo (P4501): ratio of reflected radiation to incident radiation" says nothing about being dependent of a Sun or a parent. It is an instance of "Wikidata property for astronomical objects (Q21451142): Wikidata property" but that doesn't say "child" to me.'
  • Structurally it doesn't IMHO make sense to have "parent astronomical body" as requirement of Property:P4501#P2302. The planet (Q634) needs a parent even if nobody entered albedo value. "mean anomaly (P2325): element of orbital definition" has the requirement, but in this case it makes sense due to the "orbital".
  • On the other hand, it's not a problem and I said I don't know astronomy... If consensus is for the requirement to stay, I won't remove it.
@Sextvå.tvånoll.ettsjunoll.sjufyra: I may have misunderstood the context of your recent comment (sorry for mixing another topic into your original question). I totally agree that parent astronomical body (P397) should be set when known. Interestingly, you seem to answer a question I asked in another place (last bullet of this). If you can bot those, it would be nice! Or can it be inherited (e.g. from asteroid belt (Q2179)) and remove the effort entirely?
  • I do however question if you say "the Sun" meaning Sun (Q525). Naturally we know more about our current solar system, but I'm sure there are planets identified for other stars as well and as mentioned above "parent" is not always a sun. "minor planet and comets" is perhaps difficult to find at a distances, but are they really conceptually defined only to our Sun? You can bot now, but later it may be untrue. asteroid belt (Q2179) is well defined, but I would suppose there are "other asterid belts" both in our system and for other stars. Jagulin (talk) 08:36, 3 July 2019 (UTC)
@Jagulin: We have found exoplanets around other stars, but they are neither minor planets or comets. (Minor planets is the sum of asteroids in the inner part of the solar systems and the transneptunian objects and everything there between.) And we have found belts of asteroids around other stars, but not identified single objects. We have maybe detected swarms of comets in other solar systems, but not single comets. So there are comets and minor planets in other solarsystems, but we should have not items about them. There are from time to time comets who are encircling Jupiter and Saturn and not Sol, but they have in the past been encircling Sol, so adding that to the items is never wrong. The only known exception to this is 1I/ʻOumuamua. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 08:52, 3 July 2019 (UTC)
@Sextvå.tvånoll.ettsjunoll.sjufyra: Thanks for the added insight!
* We agree that you're not talking about Albedo it seems. I think it would make sense for someone to add the "parent" constraint to the item classes that should have it, e.g. planet, asteroid...
* You suggest to inject "parent" value into specific kinds of objects. That's out of my league, so as long as you know what you do and have support, I don't mind. :) As a general rule I'd not inject data into WD if I had no source for it. I prefer leaving "gaps" and let the "reader" fill them in by any assumption they're willing to do, rather than add statements that the reader will have to question.
* I don't know the definition of "parent" really, but I would expect the data to be "current" (is that within 1000 years?), stable and that the basis is gravitational. That was only my guess however. You seem to indicate that comets are bound to the Sun, but occasionally spin around a planet before they head out to the Sun trajectory again. If there are some sources that say the "parent" is Saturn and some say "Sol" then they are both valid statements and you may need to Rank or timestamp those facts.
* 1I/ʻOumuamua (Q42313338) was interesting. Rather than relax the need of parent astronomical body (P397) for that item (such as in albedo (P4501)), maybe parent astronomical body (P397) could be set to "no value" or "it's complicated" and have the exception stated in parent astronomical body (P397) only? I think that would make the structure more rigid.
* To get out of this trouble is also the reason why I suggested albedo (P4501) not to have constraints for "parent". Jagulin (talk) 16:50, 3 July 2019 (UTC)
  • Comet Shoemaker–Levy 9 (Q3076) was for a period a "pseudomoon" to Jupiter before it collided with the planet. The dynamics of orbits is a very interesting subject. Most small objects that are trapped by the gravity well of large planets, tends to run away after some years. They may stay for decades, but sooner or later the kinetic energy they have let them run away. There are exceptions. Both moons or Mars are probably caught out of the asteroid belt. Many of Jupiters moons probably have the same origin. The exact definition of parent, I do not know if it is scientfically defined. My guess is that it is mainly a WD-template thing. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:25, 3 July 2019 (UTC)
After more thoughts, I'm not found of the "originating" use of "parent". I did however open for discussion in Wikidata_talk:WikiProject_Astronomy#Definition_of_parent_and_child? in hopes of more expert opinions. I suggest we take the discussion there from now, since your original Albedo issue was solved. Jagulin (talk) 10:21, 5 July 2019 (UTC)

Same person?

Arthur Devine (Q16943844) and Q64980647? --Magnus Manske (talk) 07:45, 2 July 2019 (UTC)

  • I'd think so, though it's unclear where the P569=1860 comes from. --- Jura 08:15, 2 July 2019 (UTC)
I've asked Mpaa about 1860 here. --Tagishsimon (talk) 09:12, 2 July 2019 (UTC)
I can't recall but 1849 seems correct, according to this s:Page:The_Catholic_encyclopedia_and_its_makers.djvu/73. I must have mistakenly taken the 1860 from the author below in such page.--Mpaa (talk) 20:56, 2 July 2019 (UTC)
Without looking into the issue myself, I would point out a situation that I am familiar with - Q7376409 and Q7376408. Both named Ruby Wright. Both blond. Both singers. Born 25 years apart. Died 5 years apart. The internet has the pair so mixed... But they are different people. It's one thing for common names like "John Smith", but I have even found "oddball" names that were not the same people despite similar details. Quakewoody (talk) 21:10, 2 July 2019 (UTC)
I think they are the same. References indicate same works for both of them.--Mpaa (talk) 21:18, 2 July 2019 (UTC)
"one thing for common names" you say. I'd expect the "odd" names to be a bigger problem because people (as in "even otherwise legitimate publications") may easily assume the name to be unique. Once it's in a legitimate source it will spread. For "generic name" I'd expect a bit more care, but you're probably right that mixups are even more frequent, since those names are also frequent. Since WD is based on other sources, not here to decide what's right or wrong, I don't know how to get around the problem. Marking "deprecated" if found, but there is no way to stop it. It would help a lot if we at least can avoid merging items based on the mixup. On the other hand, how to make sure (when to create an item) that the already existing one with a similar name is actually the same, so maybe that's a reason for duplicates too? Jagulin (talk) 06:20, 3 July 2019 (UTC)


Spind (Q6515721) and Spind (Q61955092) --RAN (talk) 13:51, 4 July 2019 (UTC)

No! Add different from (P1889) instead. The former was the capital of the municipality with the same name. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 14:07, 4 July 2019 (UTC)
There is no settlement called Spind in Norway. According to enwiki the capital of Spind municipality was Rødland (no Wikidata item). Besides Spind (Q6515721) have an area of 43 km² which is much too big to be a settlement in Farsund (Q490462), so I suppose both are the former municipality and should be merged. --Dipsacus fullonum (talk) 16:33, 4 July 2019 (UTC)
You are right. I was tricked by Spinds church. I thought I saw a village around it, but that is something else. And next to that "something else" is Rødland. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:35, 4 July 2019 (UTC)
I originally split the item, because while Spind municipality existed until 1965, Spind definitely still exists as "something" even after the municipalities merged. Store norske leksikon and Kartverket both call it a parish of Norway (Q814691), so I suppose we could do the same at Spind (Q6515721). Einar Myre (talk) 06:39, 5 July 2019 (UTC)
I changed the wrong and confusing instance of (P31) human settlement (Q486972) to instance of (P31) parish of Norway (Q814691) for Spind (Q6515721) and updated descriptions for no, da, en and deleted probably wrong descriptions for ar, de, nl.
Probably a Geonames-ghost. (Hej!) 13:08, 5 July 2019 (UTC)

Update: deployment and migration plans for wb_terms redesign

Hello all,

This is an update regarding the progress and dates of migration of wb_terms table replacement solution in Wikidata production environment.

We have successfully put Wikidata production in the stage where property terms are stored in and written to both the old store (wb_terms table) and the new replacement store. Retrieving property terms is still being done using the old store.

The previously announced dates are no longer effective. No changes to tools are needed yet. Tools can continue to read from the old store (wb_terms table) for the moment. There will be a later announcement regarding the date when tools have to switch to reading property terms from the new store.

The next step will be to go to the stage of retrieving property terms from the new store, while we keep storing them in both stores. That step is blocked by a problem we discovered while testing that switch on beta cluster, and we are working on solving it at the moment (Task on Phabricator).

As for item terms, and in the light of the new information about switching master node to a better host (see Failover s8 (wikidatawiki) on Phabricator) that can actually host the migration of them till the end, we have as well decided to push out item terms migration on hold until after that failover is done and is stable.

The migration of all item terms will take weeks to finish, but it isn’t clear yet how long exactly. We will run it in several stages and there will be separate announcements regarding those stages to announce and inform about how to deal with it, in case it affects your work.

You can find more information regarding those dates and how to prepare for them in this task, and we have dedicated a board to receive and help with any questions from tool builders that need to update their tools accordingly.

In order to keep all discussions in one place, we kindly ask you to react or ask your questions on Phabricator.


--Alaa Sarhan (WMDE) (talk) 10:39, 5 July 2019 (UTC)


I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 11:05, 11 July 2019 (UTC)



UsernameReviewerBot (talkcontribsnew itemsSULBlock logUser rights logUser rights)
Operator: JJBullet (talkcontribslogs)

Task/s: Creates a list of users - in userspace - that may have inappropriate names or edits, and sends them to administrators for review.

Code: N/A

Function details: Creates a list of usernames (In userspace) that may be inappropriate or that may have made inappropriate edits / be offensive to another user, sends them to admins / crats for review. --~JJBullet~ {Talk} 09:10, 4 July 2019 (UTC)

why are you importing english wikipedia drama? is there any evidence of inappropriate user names? what is your criteria for inappropriate? what is your criteria for inappropriate edits? is this scope creep? Slowking4 (talk) 10:28, 4 July 2019 (UTC)
Do you need to be so rude? i am simply carrying on with my other request~JJBullet~ {Talk} 10:31, 4 July 2019 (UTC)
would you care to answer the questions? you do not have a consensus, see also Wikidata:Requests for comment/Adopt a username policy - Slowking4 (talk) 02:32, 6 July 2019 (UTC)
  • You don't need to have bot permissions to read the list of user names. I would propose that you do the first 5 cases manually and then we see whether that's something worth automating. Apart from that, while it's nice to have a link in the project chat, the actual request should still be at requests for permission. ChristianKl❫ 11:08, 4 July 2019 (UTC)
    The bot may have gain of the apihighlimits rights. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 14:11, 4 July 2019 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Uncertain date

Anastasiya Pavlovna Knyazeva (Q44979759) have 1 July 2011 as birth date. However, is there various website that have 30 June, other 1 July. On the Knyazeva YouTube channel was uploaded today 4 July a video which celebrate her birthday... So, when Anastasiya Knyazeva was born? 30 June, 1 July or 4 July? -- 17:55, 4 July 2019 (UTC)

  • No idea. From a Wikidata perspective, you can add all dates, each with the reference that supports it. --- Jura 18:01, 4 July 2019 (UTC)
  • Day of video upload on YouTube is not the same the birthday. According post on her Instagram she clebrated birthday on 1 July. The same is in Russian magazine's article. --Ksc~ruwiki (talk) 20:32, 5 July 2019 (UTC)

dewiki:Frauenzentrum Westberlin and enwiki:West Berlin Women's Center

Moved from WD:RfD

These two objects both describe the same entity, but I can't merge them. Could someone please help me? -- 17:35, 8 July 2019 (UTC)

✓ Done --GPSLeo (talk) 19:31, 8 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 09:02, 11 July 2019 (UTC)


I notice that some people can add comments to edits, how can I do that? I would like to let people know why I may be reversing an edit, they should see the rationale so they do not add it again. --RAN (talk) 18:19, 10 July 2019 (UTC)

In history, when you hit "undo" or "restore", you can write the explanation. --Matěj Suchánek (talk) 09:02, 11 July 2019 (UTC)
This section was archived on a request by: --JJBullet❫ 09:22, 11 July 2019 (UTC)

Format fix property proposal?

Can someone fix Wikidata:Property proposal/begin and end of covered period ; covered period so the discussion section appears? There's something funky with the ping templates but I can't figure out what it is. - PKM (talk) 21:07, 10 July 2019 (UTC)

Fixed. Not sure what exactly it was... --Yair rand (talk) 03:48, 11 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Matěj Suchánek (talk) 08:59, 11 July 2019 (UTC)


Shouldn't Q803626 and Q23932292 be merged? Sorry if this is not the correct place to suggest a merge. -- 08:14, 11 July 2019 (UTC)

✓ Done --JJBullet❫ 08:50, 11 July 2019 (UTC)
Also it would be best to suggest a merge at the RFD JJBullet❫ 08:49, 11 July 2019 (UTC) sorry, my mistake--JJBullet❫ 09:04, 11 July 2019 (UTC)
No, that's where deletions are requested, not merges. A merge can be conducted by anybody. --Matěj Suchánek (talk) 08:59, 11 July 2019 (UTC)
I was literally about to strike that out but you got there before me, thanks :) --JJBullet❫ 09:01, 11 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. SilentSpike (talk) 09:16, 11 July 2019 (UTC)

John Pierce (Q65054514)

That person, en:John Pierce (tenor) - too many John Pierce - is the same as de:John Pierce (Sänger). Sorry, I failed to make the connection when creating. --Gerda Arendt (talk) 09:19, 11 July 2019 (UTC)

This is just my thoughts, but why would we need to deal with stuff from outside wikis? correct my if im wrong?--JJBullet❫ 09:20, 11 July 2019 (UTC)

✓ Done--JJBullet❫ 09:55, 11 July 2019 (UTC)

This section was archived on a request by: --JJBullet❫ 09:55, 11 July 2019 (UTC)

Edit filter to prevent edits that are obviously wrong?

Why don't we activate an editing filter that prevents edits like the following, that are obviously wrong, to be entered into Wikidata in the first place?

[4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

These are just examples on when a taxon (Q16521) or a film (Q11424) has been used for country of citizenship (P27), probably by mistake as the name is similar to the name of the correct object. One of the edits in the list above is almost three years old, and has not yet been corrected! --Larske (talk) 16:39, 28 June 2019 (UTC)

Edit filters have very limited checking features and their maintenance is restricted to sysops. On the other hand, the system for constraints was developed for Wikidata and is still evolving, unlike edit filters developed mainly for Wikipedias. --Matěj Suchánek (talk) 19:17, 28 June 2019 (UTC)
Sorry if I used the wrong terminology. It doesn't have to be an "edit filter" if that has a particular meaning in the Wikimedia context.
I rephrase my concern: Why don't we prevent, or automatically (by a bot) revert, edits that obviously violates the most obvious contraints like a country of citizenship (P27) must not be a taxon (Q16521)? It is very bad that such edits that can be detected at once remain uncorrected after months or years. --Larske (talk) 22:04, 28 June 2019 (UTC)
It's good that you've found these anomalies.
The first thing to ask is whether there's a proper, governing constraint. Clearly, the target of country of citizenship (P27) should be a state (Q7275) -- and, in fact, there is such a constraint at P27.
The second thing to ask, then, is: Why is the constraint not working, in that (for example) the P27 claim at Juan Carlos Mareco (Q3466333) is not flagged as violating it? [Never mind, the constraint seems to be working fine. I suspect the reason it seemed not to be working for me was due to an unrelated issue in my environment.]
The third thing to ask is, if the constraint were working, why have some of the items you mentioned been in violation of their constraints for so long? Are there "you can help" / "things you can work on" lists for constraint violations? Do volunteers need to be prodded to whittle down those lists?
And then, finally, to your specific suggestion: should there be a mechanism to simply prevent edits which supply new or modified claims which violate certain (or all) constraints?
Me, I don't know the answer to any of these questions except the first, but perhaps someone else here does. —Scs (talk) 22:56, 28 June 2019 (UTC) updated 11:31, 30 June 2019 (UTC)
Two answers: 1) there are reports for most/all constraints, listed in the talk page of the property; for example, here's a report for P39. 2) We should not prevent edits that break constraints. In general, constraints are simple and the world is complex; the consequence of preventing the addition of truthful information because it is outside the compass of a constraint, is greater than the consequences of addition of data that breaks the constraint. --Tagishsimon (talk) 12:04, 30 June 2019 (UTC)
Well, reports are fine if they are acted upon. But in reality faulty statements can be left uncorrected for years as you can see among the few examples I listed. I understand, that not all existing constraints may be appropriate to use for stopping edits, so they can not be stopped "in general". But what is your opinion about when people enter a taxon (Q16521) or a film (Q11424) as the value for the country of citizenship (P27) property just because they have identical or similar labels. I found it very strange that such entries are not prevented.
Maybe we need another type of constraint that do not list what is acceptable (because there may always be exceptions in "complex world" as you say), but what is not allowed (i.e. not as in never, with no exceptions), based on experience of common mistakes like the ones I listed. Or, if not stopped, at least "delayed" with a "CAPTCHA" that humans, but not bots, can successfully pass if they actively confirms that there is not a mistake that they want to enter an taxon (Q16521) (or subclass thereof) as the value for the country of citizenship (P27) property. Do you think that would be possible?
Or maybe such constraints already exist but are not used. We have country of citizenship (P27)/property constraint (P2302)/value type constraint (Q21510865) with six listed class (P2308) and relation (P2309) equals instance of (Q21503252), but I guess what I am thinking about is a number of class (P2308) with relation (P2309) equals "is definitely not instance of (Q21503252)". The class (P2308) listed here can of course not be all classes except those listed above, but just those where experience has shown that mistakes are common. I think taxon (Q16521) and film (Q11424) would be two of my candidates for such a list for the country of citizenship (P27) property. Suggestions for such "commonly mistaken" class (P2308) can of course be found in the constraint violations reports that we have today. Do you see what I mean?
I also have a questions on the reports you refer to. You refer to the report for P39 when my examples were all about P27. If I look at the Constraints violation report for P27, I can not find all objects in my example list. The report says the violation count is 10914 and not all violations are listed. At the bottom of the first list it says: "Too many results. 5913 records skipped.". And if I try to run the "SPARQL" mentioned on the talk pages it results in timeout, and the "SPARQL (new)" question only lists 299 items. @Tagishsimon: What am I doing wrong here? --Larske (talk) 16:00, 30 June 2019 (UTC)
Bad idea. Wikidata allready has implementations in the Wikibase extension which enforce constraints. Even if that is unfinished or has some bugs in it, then the extension should be fixed. Abuse filter is not the fix for that. Also, I protest to the use of the term "Edit filter" for the Abuse filter. That is just enwiki jargon, based on different policies than this project has.--Snaevar (talk) 17:42, 6 July 2019 (UTC)

Q482980 proposed to rename in Japanese language

As announced on wikidata:project chat in Japanese language, there is a proposal/request-for-edit in progress on Talk:Q482980 by a Japanese editor: rename Q482980 from (A) "作家" (ja) to (B) "著作者" (ja), or the copyrighted author of things. The proposer lacks editing rights, and the proposal is in two folds to "swap" page labels between two wikidata pages as:

  • Q482980 needs to be relabeled as (B) "著作者" (ja) and should be wikilinked on jawp to (B) w:ja:著作者 as well. Currently wikilinked to (A) or on jawp w:ja:作家, and enwp link w:en:Author should remain as is. The proposer is drafting and planning to rewrite jawp page w:ja:著作者 extensively from the viewpoint of law field.
  • Q11620855, currently linked to (B) on jawp (w:ja:著作者), needs to be re-labeled as (A) "作家" (ja). FYI, (A) includes ISCO occupation code, as a creator of things. Please join and drop your thoughts.  --Omotecho (talk) 18:36, 3 July 2019 (UTC)
If the page is protected, you could use {{Editprotected}} or ping the protecting admin. --- Jura 09:11, 6 July 2019 (UTC)

problems with query API

Dear Wikidatas,

in my Python-code I use the module "SPARQLwrapper" referring to for retrieving a bunch of features on authors of research articles. It worked for many weeks. However since about two weeks I get Error messages, mostly "HTTP Error 403: Forbidden" and some times some Error 402 (?) due to too many requests. Then yesterday afternoon (Berlin time) it worked again for half an hour.

Whats going on? How can I fix my code? Or do I just have to wait till you fix something behind the scene? I tried to join the Wednesday tech-chat but I couldn't manage to join the channel on freenode.

Looking for you reply! Thank you very much in advance! Cheers! Eva from Cologne — Preceding unsigned comment added by (talk) 07:42, 4 July 2019‎

I had this problem when I hadn't specified a user agent in SPARQLWrapper. When I added it to my tool, I stopped getting 403 errors. --Vesihiisi (talk) 10:52, 4 July 2019 (UTC)
Are you following the User-Agent policy? We’ve recently started to enforce this more strictly, I believe; specifically, the default python-requests user agent is currently blocked. (Even if the problem turns out to be something else, sending an informative User-Agent header is good practice anyways.) --Lucas Werkmeister (WMDE) (talk) 10:56, 4 July 2019 (UTC)
ha! that worked! thank you a lot! Eva

Can we create a wikipedia page for a new company?

I wanted to know, whether we can create a Wikipedia page for a new company. I had tried that a few months ago, but the page was deleted, and my IP also got blocked. And I specifically don't know why?

Since I do not know what the company is and I do not know which version of Wikipedia you were editing and which IP you were using, it is impossible to tell here. But most likely the problem was that the subject of the article don't fulfill the standards we would like to see at Wikipedia. en:Wikipedia:Notability for example tell: "Wikipedia articles cover notable topics—those that have gained sufficiently significant attention by the world at large and over a period of time, and are not outside the scope of Wikipedia. We consider evidence from reliable and independent sources to gauge this attention." New companies normally do not fullfill such demands. And articles created by persons close to the subject, often look more like marketing of the subject than an encyclopedic article. That can also be a reason why it was deleted. IP (Hej!) 07:12, 6 July 2019 (UTC)
List_of_bad_article_ideas Why_was_the_page_I_created_deleted%3F It occurs frequently that self-promotional articles are created of naivety or ignorance and deleted short time later. But you should not have got banned for that. Probably you tried to re-post your article several times or edited many pages to link to your page. As about why, there is a design flaw in wikipedia: when an article is deleted then it vanishes from both the recent changes and your contributions. But the act is visible in the deletion log. The sysop performing the deletion is supposed to give reasons for that. But your case is easy to guess: inappropriate self-promotion. The answer to the core question is NO. Do NOT try to create a wikipedia page for your company, do NOT retry with other public wiki or other IP. Even if your company becomes notable then you should NOT start an article or substantially enhance such if it already exists. Taylor 49 (talk) 09:08, 6 July 2019 (UTC)

Bot that changes [[Q12345]] to {{Q|12345}}

I frequently see it that people who are used to the style of links within Wikipedia use links like [[Q12345]] inside discussion on this project. Likely, because they don't know about our templates. I'm of the opinion that the template is always better then the interwiki-link. I feel it would be great to have a bot that automatically changes [[Q12345]] to {{Q|12345}}. How do other people feel about the issue? ChristianKl❫ 09:03, 2 July 2019 (UTC)

  • Not really, personally I use Q123 when the label isn't helpful. What I do find annoying are QIDs without any links at all. --- Jura 09:06, 2 July 2019 (UTC)
Even if the label isn't helpful, what use does it have to be shown the number? ChristianKl❫ 09:24, 2 July 2019 (UTC)
Normally, there should be some text around it explaining the item. In any case, I don't think a bot (or a user) should edit other users signed comments. --- Jura 09:35, 2 July 2019 (UTC)
Even if there's text around it explaining it I don't see how the {{Q|12345}} form is worse. I generally do believe that edits that fix spelling mistakes or formatting issues are okay. I spent a lot of time on StackExchange where that happens very frequently and the advantage of the Wiki system is that editing is possible. ChristianKl❫ 10:15, 2 July 2019 (UTC)
A wiki talk page isn't exactly a wiki article. Given the problems we have had around here with people doing it .. let's not. There is actually no way to be sure what users see when you add {{Q|12345}}. --- Jura 10:27, 2 July 2019 (UTC)
I agree that mass-editing discussions should be avoided and StackExchange culture and answering is different from here. If nothing else, the history would be a mess. It could possibly be a feature of the editor (remember Office Assistant (Q1042885)?) so inexperienced users would be asked to (auto)change before saving. Another possibility is to have a WD plugin or local browser plugin to show any matching ID (template or not) the way you perfer it: Something alike "Descriptions: Show the description of..." in gadgets. Anyone knows if it is available? The downside of local fixup is that there may be confusion in the discussion when you see different things. Jagulin (talk) 06:59, 3 July 2019 (UTC)
I kinda wish the template could pull in the number only where the relevant description is missing, as I agree in most instances the numbers are not that useful. Circeus (talk) 02:11, 3 July 2019 (UTC)
@Circeus: To me, seeing the number is quite important. The same description may be used both for Q and P and it's very relevant to separate those in a glance. When talking about possible duplicates, it's also needed to keep track of items with similar names but different numbers. I "always" use Q-template (e.g. Count von Count (Q12345)), but maybe that's annoying to someone. There us also Q'-template (Count von Count (Q12345) View with Reasonator View with SQID) and Q+-template (Count von Count (Q12345): character on Sesame Street) and maybe more (one showing only number but having details when hovering?) so the idea is that the writer decides which they think is most relevant at each case. Jagulin (talk) 06:59, 3 July 2019 (UTC)
  • I used to use {{Q|12345}} first time in discussion in order to help other editors to know the meaning, but not for the further appearances. Thanks by the proposal. Amadalvarez (talk) 09:29, 2 July 2019 (UTC)
Using regular links and not {{Q}} is also a good idea when the discussion is about the identity or labels of the items themselves – using their current labels for them can make the discussion very confusing to read in the future (“should imported from be changed to be Wikimedia project-specific?” vs. “should imported from Wikimedia project (P143) be changed to be Wikimedia project-specific?”). See the topic right above this one (#Same person?) for another example – using {{Q}} for items with the same label isn’t very helpful. --Lucas Werkmeister (talk) 16:54, 3 July 2019 (UTC)
My first reaction is that this sounds like a problem with the template. Ideally, the template would show both the label that was applicable when the template was first used and the current label. In any case I'm not advocating that the form [[Property:P143|imported from]] should be edited by the bot. ChristianKl❫ 21:09, 3 July 2019 (UTC)
  • Perhaps this could be done with JavaScript, so one can choose to use it or not? Might be expensive though, don't know. Best would be if Wikipedia:Tools/Navigation popups (Q11305696) displayed the label in the user language with fallback. Unfortunately, it's half-broken for Wikidata. --Marsupium (talk) 15:12, 5 July 2019 (UTC)

So again: How to link to a section if that is using {{Q|XXX}}?

If there can't have a user-friendly solution of this question, then I would consider nominating zh:Template:Q for deletion. --Liuxinyu970226 (talk) 23:50, 5 July 2019 (UTC)

  • This makes no sense at all. (1) You begin the header here with "again," but this appears to be your first comment on this thread. (2) You refer to a template on the Chinese-language Wikipedia, but this discussion has been about a template on Wikidata. (3) The fact that a template might not be entirely suitable for use in a section header is not a reason to delete the template. (4) You should still always be able to get a suitable link to a section header by left-clicking in the table of contents to go to that section, then copy-pasting from the URL bar. - Jmabel (talk) 08:53, 6 July 2019 (UTC)
@Jmabel: I was asked at Template talk:Q for several times, and until your comment, no answers. --Liuxinyu970226 (talk) 09:03, 6 July 2019 (UTC)
  1. The account you are editing under has no posts at Template talk:Q. Were you editing on a different account?
  2. What about my points 2, 3, & 4? - Jmabel (talk) 09:15, 6 July 2019 (UTC)
What the... there is no trace whatsoever of any such discussion by anyone at all either at [[[Template talk:Q]] or at zh:Template talk:Q... Circeus (talk) 22:22, 6 July 2019 (UTC)


Is it legal to have adjectives as items? There is an item about "small" Q24245823 but none about "big". Also we have two items about "case sensitivity" Q55121384 and Q257869 and one item about "case sensitive" Q55121148. Are adjective items desirable? Taylor 49 (talk) 16:55, 5 July 2019 (UTC)

  • If, as for small (Q24245823), Wikiquote has a page for an adjective, aren't we pretty much obligated to have an item? - Jmabel (talk) 19:58, 5 July 2019 (UTC)
  • Yeah, we pull items from a lot of different wikis that can cause apparent duplicates with lexeme. I've applied subject lexeme (P6254) to small (Q24245823). the other two seem to be strictly because of stackoverflow tags that happen to be written in the adjectival form. I would straight up merge those with the matching qualities' items. Circeus (talk) 22:35, 6 July 2019 (UTC)

Help with Q65052377

What needs to be changed for the reference to Haida people to work? Not sure if I am using the wrong property, or if something needs to be changed at the Haida people item. Also, what is the appropriate way to connect Northwest Coast art to this item? Right now it's "genre" which doesn't seem quite right. Thanks! Calliopejen1 (talk) 00:03, 6 July 2019 (UTC)

@Calliopejen1: Haida is defined as an "ethnic group" (as are most US indigenous peoples in WD). ethnic group (Q41710) is (ultimately) a subclass of group of humans (Q16334295). The property culture (P2596) wants a value that is a people (Q2472587) or a civilization (Q8432). There are two ways to fix this. Quick and easy, make Haida <instance of> both ethnic group (Q41710) and people (Q2472587) "plurality of persons considered as a whole, from a government perspective", which I think is correct. We could also get consensus to add ethnic group (Q41710) as a valid value for culture (P2596). I'd vote for doing both.
I'd also make Native American tribe in the United States (Q7840353) an instance of people (Q2472587), since a recognized tribe certainly has a political aspect, and eventually add <instance of> "people" to all other indigenous peoples in the US that are not formally recognized tribes.
Typically, "art of [place]" isn't a genre, but a subclass of art. However, tribal art (Q2864736) is an art genre, with subclass Indigenous Australian art (Q420716). So Northwest Coast art (Q7059995) could be a subclass of either "art" (in which case this mask in an instance of it or part of it), or it could be a genre, subclass of "tribal art", equivalent to Getty AAT's Northwest Coast Native American styles. I think either one is valid as long as we're consistent. We have very little coverage of Native American Indian art in Wikidata, so we can set an initial standard with what we do here. - PKM (talk) 20:39, 6 July 2019 (UTC)
(And we could of course have two items for "Northwest Coast art", one a subclass of art and one the genre linked to it), which I think is good ontology. - PKM (talk) 20:44, 6 July 2019 (UTC)
@PKM: I am so new at Wikidata that my ability to weigh in here is limited. I will say that the ethnicity issue is a common problem I've encountered not just for Native American/Alaska Native art but also for any art or craft that is associated with an ethnic group (e.g. Nomoli figurine (Q3343234), Kutch blouse E77824 (Q65088082)). Re: Northwest Coast art, Northwest Coast art (Q7059995) is associated with a geographic region, but it is a style of artwork -- I wouldn't call it "art of [place]". It probably could be a subclass of tribal art, though some non-Natives are creating artworks in this style as well (see e.g. [21], [22]). Calliopejen1 (talk) 21:17, 6 July 2019 (UTC)
@Calliopejen1: Thanks for those links. We do have Visual arts by indigenous peoples of the Americas (Q7936583) I missed it before. It's a <subclass of> visual arts, and has no subclasses of its own.
While we tend to use Getty AAT as a reference vocabulary for decorative arts, where we lack anything better, we don't follow it uncritically. We have more or less deferred the entire question of "styles, periods, and cultures" (hierarchy here). FWIW, Getty does not attempt to group "tribal art" across geographic regions.
We have the concept art style (Q1792644), <different from> genre (Q483394). art style (Q1792644) is used very loosely for a lot of different concepts, but it would certainly be appropriate for Northwest Coast art (Q7059995). We don't have a specific property that goes with this concept, but we might propose such a property - we have genre (P136), movement (P135), and architectural style (P149), all of which are adjacent to "style" but not exactly the same. For now, we can make Northwest Coast art (Q7059995) <instance of> "style" and reference the Getty AAT item. - PKM (talk) 00:49, 7 July 2019 (UTC)
Another property you may find useful is indigenous to (P2341) for crafts and so on (not individual objects). - PKM (talk) 01:01, 7 July 2019 (UTC)
@Certainstars: Do you have any thoughts on this? - PKM (talk) 20:44, 6 July 2019 (UTC)

"Collaborating on the sum of all knowledge across languages"

Hi! I really try not to spam the chat too much with pointers to my work on the Abstract Wikipedia, but this one is probably also interesting for Wikidata contributors. It is the draft for a chapter submitted to Koerner and Reagle's Wikipedia@20 book, and talks about knowledge diversity under the light of centralisation through projects such as Wikidata. Public commenting phase is open until July 19, and very welcome: "Collaborating on the sum of all knowledge across languages". --Denny (talk) 21:49, 6 July 2019 (UTC)

Thank you very much for share it, Denny! I have pending to review it and give some comments if I have something useful to contribute. Regards, Ivanhercaz (Talk) 00:09, 7 July 2019 (UTC)
Thank you! --Denny (talk) 00:10, 7 July 2019 (UTC)

Stated-as as a qualifier on dates

special:diff/975860943 was done because Chinese dates could be ambiguous. In this case, it can be assumed to be a Gregorian calendar date, but there's still a small chance it's a Chinese calendar date since the date is written in Chinese characters instead of Arabic numerals. But stated-as is not allowed on dates. Could you please help present this info in a correct way, or allow stated-as as a qualifier?--Roy17 (talk) 11:02, 8 July 2019 (UTC)

A similar issue occur with dates of the French Republican Calendar (Q181974) (the year starts in September, so if it's only down to a year...) Circeus (talk) 16:45, 8 July 2019 (UTC)
@Marsupium: thx!--Roy17 (talk) 08:45, 12 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --Roy17 (talk) 08:45, 12 July 2019 (UTC)

EntitySchema Sandbox?

Who can tell me that where to test this namespace? -- 07:37, 10 July 2019 (UTC)

EntitySchema:E123 is the sandbox entity schema page. --Lucas Werkmeister (WMDE) (talk) 11:29, 11 July 2019 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Lucas Werkmeister (WMDE) (talk) 12:34, 12 July 2019 (UTC)

From a parliamentary group to independent or to other parliamentary group

Q54152815#P39 She was elected as a candidate of a political party. After she elected, she was part of this party's parliamentary group. But then she left the party and the group and she became independent. If someone reads the statement may think that she was independent all the parliamentary term. (Maybe someone realize what happen by reading Q54152815#P102?) Xaris333 (talk) 12:24, 3 July 2019 (UTC)

You could state position held (P39) twice, with end time 2018-02-02 for Citizens' Alliance (Q20773826) in the 1st statement, and start time 2018-02-02 for independent politician (Q327591) in the 2nd statement with another reference adopted from member of political party (P102). – 15:16, 3 July 2019 (UTC)

Q52773609#P39 He was elected as a candidate of a political party. After he elected, he was part of this party's parliamentary group. But then he left the party and the group and he became independent. One year later he joined the parliamentary group of other party. If someone reads the statement may think that he was in the second party all the parliamentary term. (Maybe someone realize what happen by reading Q52773609#P102?) Xaris333 (talk) 12:35, 3 July 2019 (UTC)

See, for instance Chuka Umunna (Q267648) - 4 statements for his P39 for his 57th Parliament membership, as he moved from one political grouping to the next. This, I suggest, is the model to be followed. --Tagishsimon (talk) 18:25, 3 July 2019 (UTC)
(By which I mean, the model to be followed on wikidata. As an IRL political strategy, possibly less so.) --Tagishsimon (talk) 18:26, 3 July 2019 (UTC)
Seems like these statement get more and more out of hand. We need to get this closer to a model with actual start and end dates for positions. We can't just mirror everyones database artifacts. --- Jura 18:33, 3 July 2019 (UTC)
Well, good luck with that. Presuming you want the electoral group, having multiple position statements seems unavoidable. This sort of organisation has not been found to cause issues with e.g. UK politician reports; and the handling of UK MPs & reports theron is in advance of any country on wikidata. "Seems ... out of hand" is an interesting but unempirical objection. Can you point to an actual downside - for instance, a report that's no possible because of the data structure? --Tagishsimon (talk) 20:55, 3 July 2019 (UTC)

@Jura1: I aggree. And the cases are not so many, we can easily find a model. Where can we open a discussion about it? Xaris333 (talk) 20:48, 3 July 2019 (UTC)

"Easily". I've ordered popcorn. On you go, Xaris333: easily find a better solution which represents the changing electoral group membership of an individual as part of their holding of a position. Alternately, per Jura, specify what exactly you think the practical problem with such an approach is, ideally with examples of the failure modes it causes. Those of us who have gone here before await the insight which evaded us. You could try discussing it at Wikidata talk:WikiProject every politician. I know Jura a) doesn't like the every bit of every politician; doesn't like subclasses of MP for British MPs; and now does not like multiple P39s reflecting membership of different electoral groups. So all this will probably cause them lots of pain; but there you go. --Tagishsimon (talk) 21:03, 3 July 2019 (UTC)
That's so disappointed... Xaris333 (talk) 21:53, 3 July 2019 (UTC)
Easily. --Tagishsimon (talk) 22:04, 3 July 2019 (UTC)
@Tagishsimon: These are just baseless claims. Please refrain from such accusations. Apparently some users don't like to hear that they are adding unsourced claims and that others ask them for references ..
Maybe it's time to learn how sourcing of claims works and not depreciate statements that don't appear suitable to you [23]. --- Jura 14:40, 4 July 2019 (UTC)
Here where I live, electoral groups are not so important as they maybe are in other nations. Technically you can be elected for a political party, without any membership in that party. On national level, you can technically leave a electoral group and become independent politician (Q327591), but you cannot technically not join another group, even if you cooperate with them. And you can definitely not form a new group midterm. Another way to group MP's are according to their constituencies. On national level, they often meet in such groups. They cooperate in regional matters and it is not unusual that an MP challenge the whip on matters that are consideered important on regional level. IP (Hej!) 06:44, 7 July 2019 (UTC)

Balustrading To Area Of Municipal Buildings Municipal Buildings (Q17551052)

Where did this title come from? Nowhere I know, especially when the linked Historic England page says totally different. I'm going to remove it from the Commons category. Rodhullandemu (talk) 17:48, 7 July 2019 (UTC)

Wikidata items for Women in Red's events and redlists

Women in Red is having a conversation regarding whether there would be value in creating Wikidata items for Women in Red's events, most of which are virtual but some are in-person. There are 120+ events to date; each has a "meetup" page on en-wp as a subpage to Women in Red. (Example: There are additional events (virtual & in-person) in the 23 other language communities of Women in Red.

Women in Red is also discussing whether there would be value in creating Wikidata items for our 400+ "redlists". These are subpages of Women in Red which include redlinked notable women. (Example: Some of these redlists are "crowd-sourced", others are Listeria-generated, others are based on biographical dictionaries, and so forth. Besides the en-wp redlists, there are those which have been created by the 23 other language versions of Women in Red.

If we were to go forward with creating these Wikidata items, we would include "on focus list of Wikimedia project" (P5008) : "Wikipedia:WikiProject Women in Red" (Q23875215) on the Wikidata items. I don't know if other groups/communities doing this. What are your thoughts about us doing it? --Rosiestep (talk) 15:25, 7 July 2019 (UTC)

I think that is what the property is created for. The examples at on focus list of Wikimedia project (P5008) are exactly the same as you want to use it. --GPSLeo (talk) 16:41, 7 July 2019 (UTC)
@Rosiestep: We have 43 items that are <instance of> edit-a-thon (Q16022392) going back to 2015, so that seems to establish a precedent that events meet notability requirements. I don't see that any of them have associated lists, though - how are you thinking of structuring those? - PKM (talk) 21:29, 7 July 2019 (UTC)
@PKM:, I thought Art+Feminism and/or Black Lunch Table had associated lists, so maybe I should check with them? --Rosiestep (talk) 21:56, 7 July 2019 (UTC)
@Rosiestep: That sounds good; I don't see any linked lists on their Wikidata items. - PKM (talk) 22:01, 7 July 2019 (UTC)

Merging request

Q65122684 and Q54604086 are one and the same disambiguation page in different languages. Francesco 13 (talk) 12:23, 13 July 2019 (UTC)

✓ Done I did done it Moebeus (talk) 12:39, 13 July 2019 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Moebeus (talk) 12:39, 13 July 2019 (UTC)

Part of goverment

Q2792539#P39 -> Cypriot Minister of the Interior. Which qualifier can I use to show that was a minister in Demetris Crhistofias goverment (Q1719844)? Xaris333 (talk) 06:41, 8 July 2019 (UTC)

Possibly cabinet (P5054), or member of (P463), both of which are listed as valid qualifiers for position held (P39)? Looking at the count of uses, we see:
fwiw, EveryPolitician seems to make do with a comparison of ministry dates (e.g. for Second May ministry (Q30178117) and position dates to provide e.g. Wikidata:WikiProject every politician/United Kingdom/Cabinet/Q30178117 so there's a sense in which membership qualifiers within a position statement are redundant. Equally, it does seem to me desirable that we have a standard for this, which I don't see in Wikidata:WikiProject_every_politician/Political_data_model#Cabinet_memberships ... it does seem like a natural qualifier. One to consider, @Oravrattas:? --Tagishsimon (talk) 07:48, 8 July 2019 (UTC)


Can we remove the commons category from Q63245258 as the page is not active and also the candidate info as he is not old enough. 2600:6C56:6F08:1CF:0:4945:4CD6:27CB 09:18, 8 July 2019 (UTC)

As the cat no longer exists, consider it done. --Tagishsimon (talk) 09:47, 8 July 2019 (UTC)
Is the person actually notable?--Ymblanter (talk) 18:21, 8 July 2019 (UTC)
Ymblanter - I didn’t think so but I was overruled during the deletion process. Datamaster1 (talk) 18:41, 8 July 2019 (UTC)

Wikidata weekly summary #372

Request from RfD

Moved from WD:RfD

Hi, there is an issue with the two pages: School of Management Fribourg (Q30594328) is the most complete section

It is therefore not possible to link the two translations in EN et DE:

Language Label Description Also known as English School of Management Fribourg No description defined French Haute école de gestion Fribourg No description defined HEG-FR German Hochschule für Wirtschaft Freiburg No description defined HSW-FR -- 10:55, 8 July 2019 (UTC)


Paulsboro Refinery (Q35287721) is listed in Geonames as an airport instead of an oil refinery, some refinerys have heliports, but I do not see a corresponding FAA airport code, for example see Bayway Refinery (Q3014399) which has Bayway Refinery heliport (Q61675718). Do you think it is an error at Geonames? --RAN (talk) 22:32, 8 July 2019 (UTC)

Yes and no. The AIA Directory of Heliports (admittedly for 1981) lists a heliport at Paulsboro Refinery, on page 147. Equally, I cannot find a heliport by eye using google satellite view; so perhaps its now defunct? What is odd, for me, at least based on a search in geonames for 'Paulsboro Refinery', is that there is not a record for the refinery coded as 'Oil refinery', a label that does feature in their ontology. That aside, presuming that there is no longer a heliport there might explain the lack of FAA code, presuming that US heliports must have such a code. --Tagishsimon (talk) 23:07, 8 July 2019 (UTC)
If there is, it wasn't licensed as of 2016. Circeus (talk) 23:11, 8 July 2019 (UTC)