Wikidata:Project chat/Archive/2019/03

From Wikidata
Jump to navigation Jump to search

Broken title Q57620842

In The influence of selected trivalent dopants on the dielectric properties of Pb(Mg₁/₃Nb₂/₃)O₃ (Q57620842) the title of a dissertation is incorrect. It references https://ethos.bl.uk/OrderDetails.do?uin=uk.bl.ethos.426854 which also has the same title (and is possibly the source). It seems like the title is supposed to contain chemical elements with subscripts. I failed to figure out the correct title. Can someone help?--37.201.30.22 20:52, 1 March 2019 (UTC)

It's mentioned at http://www.isni.org/isni/0000000135489107, which is better, but probably not perfect. Ghouston (talk) 04:22, 2 March 2019 (UTC)
References to Pb(Mg₁/₃Nb₂/₃)O₃ can be found elsewhere, so it's probably that. Ghouston (talk) 04:23, 2 March 2019 (UTC)
This section was archived on a request by: Ghouston (talk) 07:44, 3 March 2019 (UTC)

Wikispecies duplicate? Argentine entomologist María Laura Libonatti and Argentine entomologist María L. Libonatti

It looks like María L. Libonatti and María Laura Libonatti might be the same person. Both have Wikispecies articles, blocking a merge. Moebeus (talk) 20:33, 5 March 2019 (UTC)

@Moebeus: I agree that these look like the same person. See steps for such items at the help page here. You can also report interwiki conflicts. --SilentSpike (talk) 21:12, 5 March 2019 (UTC)
Merged on both projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:25, 5 March 2019 (UTC)
@Pigsonthewing: @SilentSpike: Thank you both! Moebeus (talk) 01:25, 6 March 2019 (UTC)
This section was archived on a request by: Moebeus (talk) 01:25, 6 March 2019 (UTC)

Anti-abuse save-error nonsense

I'm running five quickstatement batches to add descriptions to 50k CBDB people items; e.g. "Ming dynasty person CBDB=34576" to Xie Qian (Q45426084) so that we have a more of a clue, when searching, about who these people are. QS is reporting many many errors.

Doing the job manually, I'm getting "Could not save due to an error. The save has failed. As an anti-abuse measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit. Please try again in a few minutes."

May I politely ask, what the fuck? QS is rate limited in line with wikidata's capacity to accept edits. Wikidata by its nature will be subject to large-scale serial edits like this. What fresh hell has been imposed on us to frustrate these edits? --Tagishsimon (talk) 11:46, 26 February 2019 (UTC)

Any batch tool you use needs to comply with the server etiquette and that etiquette includes taking into account rate limits. If the tool cannot handle a rate limit error then it should be fixed by its maintainer. TheDJ (talk) 14:43, 26 February 2019 (UTC)
My understanding is that quickstatements is rate limited. That's why I said "QS is rate limited in line with wikidata's capacity to accept edits." --Tagishsimon (talk) 14:51, 26 February 2019 (UTC)
Quickstatements works fine if you run into this, just reset the errors when the rest of the batch has finished and it will automatically re-try them. But you should probably not try to do more than 2 simultaneously or you will hit this. ArthurPSmith (talk) 18:48, 26 February 2019 (UTC)
A while ago the general idea was that if you add 50K items that's the kind of action that shouldn't happen automated without a bot approval. ChristianKl14:33, 1 March 2019 (UTC)

Daty Wikidata Editor beta release

Hi everyone,

Pellegrino Prevete, aka Ogoorcs, here again to announce the release of the beta version of Daty, the native Wikidata editor that has already been mentioned on this board last month, which aims to simplify Wikidata user experience for new as for old users.

This month saw a rewrite of the open entities dialog, which first version was righteous found not much intuitive.

Filter search (i.e. graphical SPARQL queries) has been introduced, too, which usability is of course on you to test.

In fact, despite the improvements, the failure of many testers in using filters, brought me to write and integrate a little manual to the program which has been made available online for windows users.

In this version you will also find:

  • a new GTK+ theme,
  • close buttons for entities in the editor,
  • unsourced statement visually distinguished from referenced ones,
  • huge performance improvements and
  • an entities download cache.

Editing has been disabled in this release, too. It will probably be activated in one of the march intermediate releases, just after references visualization will be completed.

I recently published the issue boards, which I am using as to-do manager. So, if you want to follow the work but you do not want to read the commit list you can read that.

I recommended current and future users to endorse the project at this page.

Download

Installers are available for Microsoft Windows (64 bit) and GNU/Linux.

Complete release notes have been published on my website; bug reporting happens here.

Notes for Mac users

I recently buyed a used mac which should arrive mid march, so the .app will probably be ready for the next release, barring unforeseen circumstances.

Ogoorcs (talk) 23:45, 27 February 2019 (UTC)

Discussion

Looking forward to trying it when Ubuntu 19.04 comes out :-) Syced (talk) 05:48, 1 March 2019 (UTC)

It would be great to an automatic update function on windows. ChristianKl14:59, 1 March 2019 (UTC)

Add all Sámi languages in Wikidata

Wikimedia Finland is starting to work with Sámi communities during the year. Only Northern (sme) and Southern (sma) Sámi are available in Wikidata, while the following ones are missign: sju – Ume, sje – Pite, smj – Lule, sjk – Kemi, smn – Inari, sms – Skolt, sia – Akkala, sjd – Kildin, sjt – Ter. Two of them are already extinct, but there is need to use them nevertheless. What is the procedure to add languages in Wikidata? – Best, Susanna Ånäs (Susannaanas) (talk) 17:38, 1 March 2019 (UTC)

I see it has just been asked. Feel free to complement, but I think the above question helps already! – Susanna Ånäs (Susannaanas) (talk) 17:44, 1 March 2019 (UTC)

Can one just ask for a language for it to show up as an option in monolingual fields eventually? Because I'll then be happy to get Réunion Creole (Q13198) created under the rcf code! Thierry Caro (talk) 17:51, 1 March 2019 (UTC)
To get a new language added for monolingual properties, see the procedure outlined at Help:Monolingual text languages. For a new language to be used with labels and descriptions, you also need to create Phabricator tickets. --Pasleim (talk) 17:58, 1 March 2019 (UTC)

Study to understand Wikidata? NO WIKIDATA ID FOUND!

Valfornace (Q28104985) and Category:Valfornace in wikimedia commons - I ca'nt bring they together - Can someone help?- nach Jahren ist Wikidata noch immer ein Buch mit sieben Siegeln für mich - undurchschaubar, stellenweise nicht nachvollziehbar und für Laien wie mich, die nur Schulenglisch hatten absolut unverständlich - Selbst so etwas Simples, wie die Verknüpfung einer Wikidata-ID mit einer Kategorie in Wikimedia ist für mich unergründlich. - Schade, dass Wikidata kein bisschen besser wurde - irgendwo wird das sicher stehen, wie es gemacht wird, aber ich hab keine Lust mehr hier stundenlang zu suchen. Adelfrank (talk) 17:46, 1 March 2019 (UTC)

Auf der Seite des Items Valfornace (Q28104985)(https://www.wikidata.org/wiki/Q28104985) unter "Andere Websites"(in der Spalte, in der auch die Wikipedia Artikel verlinkt sind) Commons eintragen und dann Category:Valfornace als die Seite. (Hier habe ich das jetzt gemacht.) --GPSLeo (talk) 18:00, 1 March 2019 (UTC)
Danke - das hätte ich nie im Leben gefunden - schön blöd, dass wenn man dem Link "NO WIKIDATA ID FOUND!" folgt, keinerlei Hinweis oder Ziel erscheint - Bei Wikidata gehen bei mir beide Daumen runter- ist nur für Fachleute geeignet, ich finde das Projekt miserabel erklärt - aber dafür kannst Du ja nichts und den Machern ist es egal - nochmals vielen Dank von Adelfrank (talk) 18:20, 1 March 2019 (UTC)

Q61876969

For The Man Inside (Q61876969) I am getting a suggestion/error to use "manifestation of" because I added a "Internet Broadway Database production ID", I am not sure what it is asking for and I cannot find an example to help me. --RAN (talk) 01:47, 26 February 2019 (UTC)

A theatrical productrion would be a manifestation of the play itself (considered as a written work independent of any particular cast or production). - PKM (talk) 20:39, 26 February 2019 (UTC)
@PKM: So every produced play gets two entries, one for the written play and one for the produced play? --RAN (talk) 04:49, 27 February 2019 (UTC)
I think not so much "gets" as "can get". A lot of the time, we seem to conflate these things when there is only one significant production, but as soon as there are two or more, you pretty much have to go that way if you want to describe them. - Jmabel (talk) 04:54, 27 February 2019 (UTC)
Yes, thanks, that is how the IBDB handles it too, even as you point out play=production when it its only performed in one run. IBDB has two IDs for each produced play for this reason, now I understand. --RAN (talk) 20:51, 1 March 2019 (UTC)

Right tool for multiple edits

Hi all. I want to change all items that list field of work (P101) as differential equation (Q11214) and make it theory of differential equations (Q28575007) instead. I know there's at least one tool that allows one to do this easily and in fact I've used such a tool a while ago. Unfortunately, I can't recall what that tool is! Can anyone help? Pichpich (talk) 21:40, 28 February 2019 (UTC)

One way would be to use Wikidata Query Service to list the items to be changed, save the output as CSV, and use an advanced text editor to convert it into commands for QuickStatements. Maybe there's an easier way. Ghouston (talk) 22:14, 28 February 2019 (UTC)
@Pichpich, Ghouston: For straightforward edits (ie you don't want to worry about references or qualifiers) you can use Petscan. This link is preset to:
  • run a SPARQL query for all items with P101:Q11214 (under the Other sources tab)
  • set up a batch edit to remove the P101:Q11214 and add P101:Q28575007 (the box in the lower right, above the search results)
You'll need to log into Widar (link above the search results) reload the page, and then hit "process commands". It will run your selected changes on all items ticked in the list (by default all search results are ticked). Andrew Gray (talk) 22:23, 28 February 2019 (UTC)
This looks handy, thanks. The commands box wasn't easy to find. Ghouston (talk) 22:42, 28 February 2019 (UTC)
You might also use TABernacle [1] for this sort of work. - PKM (talk) 23:55, 28 February 2019 (UTC)

Thanks for the help everyone. I think I used an earlier version of Petscan way back when. Pichpich (talk) 19:45, 1 March 2019 (UTC)

Harassment and other negative issues in Wikidata

I am wondering whether we have seen any instances of harasment or discriminatory behavior on Wikidata. It has been speculated in Creating Structured Linked Data to Generate Scholarly Profiles: A Pilot Project using Wikidata and Scholia (Q59652985): "...may be wary of participating in open community platform that may expose contributors to discriminatory behavior and harassment.". I cannot come up with a single instance. — Finn Årup Nielsen (fnielsen) (talk) 14:08, 1 March 2019 (UTC)

I have seen heated discussions based on genuine disagreement about how our ontology should be structured, but I have not seen anything I would call discriminatory behavior or harassment. - PKM (talk) 21:48, 1 March 2019 (UTC)
Unfortunately I can think of more than a single instance. But clearly it is not nearly as bad as enwiki. - Brya (talk) 06:05, 2 March 2019 (UTC)

Possible duplicates: Brazilian botanist Geraldo José Peixoto Ramos and Brazilian researcher Geraldo José Peixoto Ramos

Looks to me like Geraldo José Peixoto Ramos and Geraldo José Peixoto Ramos might be the same person. Anyone up on Brazilian botany researchers have a look? Moebeus (talk) 14:00, 7 March 2019 (UTC)

Merged based on PT Google Scholar and IPNI record. - PKM (talk) 03:57, 8 March 2019 (UTC)
Thank you! Moebeus (talk) 23:44, 8 March 2019 (UTC)
This section was archived on a request by: Moebeus (talk) 23:44, 8 March 2019 (UTC)

Part of a sequence

I've been asked to take a look on sequences in navigational templates, and found that there are a lot of errors. It seems like User:DeltaBot has made some changes, that not only breaks the expected behavior, but the changes are also wrong.

An item can be part of a sequence. It is no sequence by itself, and that is very important. It is part of a sequence. That means the item has follows (P155) and followed by (P156), and those statements points to other items in the same sequence.

An item 1932 European Figure Skating Championships (Q1318059) is a figure skating competition (Q2990963), it has a relation to European Figure Skating Championships (Q869121), and that might hold a sequence. If you want to create a sequence of championships (items) as a list, then you put that list in European Figure Skating Championships (Q869121). The item 1932 European Figure Skating Championships (Q1318059) has follows (P155) and followed by (P156), and those points to 1931 European Figure Skating Championships (Q694528) and 1933 European Figure Skating Championships (Q1318067).

Another way to formulate this is functional data for the item first, then limiting context for the functional data.~A qualifier is the limiting context. Using a qualifier for the functional data creates all sorts of problems, in particular the present parser functions must nearly always be replaced with modules, which makes it really hard for small projects to use Wikidata.

I leave it as a readers exercise to figure out the difference to marriages.

This is a real mess now, not sure who created the idea used for these structures as they are now. It is possible to write a module to hack around the problems, but it would be better to fix it on this project. Jeblad (talk) 14:07, 28 February 2019 (UTC)

Recent discussion: Wikidata:Project chat/Archive/2019/02#Sport events editions and P3450. Matěj Suchánek (talk) 18:06, 1 March 2019 (UTC)
An item can be part of many sequences, thus follows (P155) and followed by (P156) are by themselves ambiguous. Only if they are used as qualifier of a series property it is unambiguous. For example, the successor of the 2018 Winter Olympics can be the 2022 Winter Olympics or the 2020 Summer Olympics, depending which sequence is considered. Even for cases like 1932 European Figure Skating Championships (Q1318059) the sequence is ambiguous. Somebody who is interested in French sports events may say that 1932 Tour de France (Q261798) is the successor of 1932 European Figure Skating Championships (Q1318059) because that was the next big sport event in France. Or 1956 European Figure Skating Championships (Q1318159) can also be as successor of 1932 European Figure Skating Championships (Q1318059) because that's the next European Figure Skating Championships held in Paris. --Pasleim (talk) 10:06, 2 March 2019 (UTC)

Keyboard shortcut to add statement?

While wikignoming I add thousands of statements manually (to existing items).

I am not a fan of mouses and the "add statement" link is quite a long way to reach by TABs.

Question: Is there a keyboard shortcut? It would have the same effect as clicking on "add statement".

Thanks! Syced (talk) 05:43, 1 March 2019 (UTC)

Complicated Situation

Hi,

fa:رده:اهالی پلوپونز is a category in Farsi Wikipedia

en:Category:People from the Peloponnese is the same category in English Wikipedia

in both category consist of some interwiki

there are thousands of categories which have the same situation

Modern Sciences (talk) 18:04, 2 March 2019 (UTC)

@Modern Sciences: The two sets of categories have corresponding Wikidata items Category:People from the Peloponnese (Q7923846) and Category:Births in Peloponnesos (Q7118630). (You can find these, as you probably know, by following the "Wikidata item" link in the sidebar of the Wikipedia page).
If these Wikidata items were equivalent, it would normally be easy to merge them. However, note that they both have links to Russian wikipedia -- to two different pages. This suggests either that they are not equivalent, or that some clean-up is needed. If we now go to ru:Категория:Персоналии:Пелопоннес (corresponding to Category:People from the Peloponnese (Q7923846)) the situation becomes more clear. This category includes not only the category corresponding to Category:Births in Peloponnesos (Q7118630), but also a category for people who died there. (One might also distinguish a further sub-group of people who neither were born there, nor died there, but lived there for a time).
So it would appear that there are genuinely two different concepts here. But whether each of the categories in each of the languages is currently connected to the correct concept, that I can't guarantee. Jheald (talk) 21:35, 2 March 2019 (UTC)

Duplicating Item

Is there an easy/quick way to duplicate an item? I'd like to make a duplicate and then change the values that need to be changed, rather than having to copy most of the values from one item to another. U+1F360 (talk) 18:31, 2 March 2019 (UTC)

Try User:Magnus Manske/duplicate item.js.--Jklamo (talk) 18:38, 2 March 2019 (UTC)
@Jklamo: Awesome! Thanks! U+1F360 (talk) 18:59, 2 March 2019 (UTC)

Country (P17) -- current country or historical country ?

I had always thought that country (P17) was supposed to take the value of a present-day sovereign state, to assist with searching. (E.g. for a query like this one, tinyurl.com/y2wk3j2j, for battles fought in the UK or Ireland).

But when adding Republic of Ireland (Q27) for Battle of the Boyne (Q644960) I am getting a constraint warning contemporary constraint (Q25796498) :

"The entities Battle of the Boyne and Ireland should be contemporary to be linked through country, but the latest end value of Battle of the Boyne is 11 July 1690 Gregorian and the earliest start value of Ireland is 29 December 1937."

I think this constraint warning is unhelpful, and (if looking for ancient buildings, battle-sites, etc) will make searching rather difficult. But what do people think? Jheald (talk) 13:37, 22 February 2019 (UTC).

IMO also, if the value of the property should always be the present-day sovereign state, it should be eg United Kingdom (Q145) rather than England (Q21). (diff) Jheald (talk) 13:54, 22 February 2019 (UTC)

(Looking at Property talk:P17 it turns out there's already an auto-replace active, to change any value England (Q21) to United Kingdom (Q145) as a matter of course. So this aspect is already established. Though the auto-replace doesn't apply to Kingdom of England (Q179876). Jheald (talk) 10:32, 23 February 2019 (UTC) )
Pinging @Abián: who added the constraint in September 2018 diff Jheald (talk) 13:58, 22 February 2019 (UTC)
Here "contemporary" does not mean "current". See Help:Property constraints portal/Contemporary. --abián 14:07, 22 February 2019 (UTC)
@Abián: And that is exactly the problem, and why it should not have been added to P17. Jheald (talk) 14:15, 22 February 2019 (UTC)
Sorry! I misread your comments. It's a matter of consistency, using a country that was created after the entity disappeared makes no sense, it's not even possible to agree such a country in most cases. country (P17) is clearly a contemporary property; however, countries are also the entities whose data are the most inconsistent in Wikidata. There's a brief explanation (in Spanish, but easily translatable by automatic means) about the issues with countries on the work about the contemporary constraint, page 24. --abián 14:30, 22 February 2019 (UTC)
On the contrary, it makes every sense to consistently use the present-day country for P17 rather the contemporary country, in order for the items to be readily discoverable -- eg for a query like the one at the top of this section to be able to work. Jheald (talk) 14:38, 22 February 2019 (UTC)
The query and its answer are consistent. If the result doesn't meet the information needs, then the query should be improved. There are no one-to-one matches between all historical and current countries and, since those matches can't be set manually in any objective way, SPARQL can't do it either. If those matches were exact, then historical and current countries would be the same Items, it wouldn't even make sense to distinguish between historical and current countries. --abián 14:58, 22 February 2019 (UTC)
The query gives a perfectly consistent answer to the question "what battles occurred on the territory of the present-day sovereign states of Ireland and the UK" -- the established understanding of P17. The query works because all the items ignore your constraint. If the items obeyed your constraint, the query would return very nearly a null set, and would be of much less usefulness. Jheald (talk) 15:57, 22 February 2019 (UTC)
Sounds to me like this calls for two different properties, one specifically for a country contemporary with the event, one for a present-day country. - Jmabel (talk) 16:47, 22 February 2019 (UTC)
P17 is a mess that I never totally understood (qv. the self-referencing, discuss multiple times on the property talk page, the last discussion being about self-referecing of historical countries) but here the problem is more general. I don't get why would someone want to put current value on something when it didn't existed, is may seem more easy but it's anachronic, not-perennial (no country will exist forever, what will call present is already the past) and country are not fully consistent. In the long run, it's just trouble waiting to happens, when a query can often easily infered the current country. For me, te contemporary constraint is totally logic here. Cdlt, VIGNERON (talk) 17:10, 22 February 2019 (UTC)
It's incredibly useful to have a property so that one can know that all items with a geographical component -- eg including, but not limited to: settlements, battlefields, events (even if long abandoned) -- should be relateable to a modern country; so that one can drive for completeness, i.e. easily identify any that have coordinates but don't have a present-day country; and so one knows that in principle one should be able to search for all such objects within a country's territory and be reasonably likely to find them. This is a cornerstone for many national wikidata assessment and improvement efforts. It's also a very natural thing to want to be able to do.
This was, I believe, the understanding of P17 before Abián added the constraint. It worries me that now, as a result of the constraint warnings, we are losing completeness; which then messes so many further things up in turn. Jheald (talk) 18:36, 22 February 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── It does not help that many items like Russia (Q159) or Poland (Q36) serve a double duty as the concept of the "country" (for Poland starting in 10th century) and the latest incarnation of "sovereign state" (in case of Poland starting 1918). So articles about Poland and Russia cover both concepts (history of Poland talks about one and government of Poland talks about the other) and items have multiple "inception" dates. Boundaries of "Poland" changed a lot since 10th century, there were also significant changes since 1918. The "contemporary" constraints often make very little sense for such broadly defined concepts. And this confusion is not new to Wikidata, I remember that number of people killed in Poland during World War II changes drastically depending on if you consider pre or post war boundaries. --Jarekt (talk) 19:45, 22 February 2019 (UTC)

I understand you. I am trying to clean up P17 (and P27) = Q159 values when I see it and change to some more appropriate historical values (such as Soviet Union (Q15180) or Sirtori (Q42166)). But Poland (Q36)... Some users even fight against my changes. Even more furiously with Baltic states... --Infovarius (talk) 12:20, 28 February 2019 (UTC)
I'm not sure that there really is an "established understanding" on this. I suspect there are certain topic areas where are there are fairly well established conventions, but I'm less sure that those are going to be consistent everywhere. With political data, the convention is generally to use the relevant country at the time, not the current one: it would seem very odd to me, for example, to have the country (P17) on something like Supreme Soviet of the Soviet Union (Q326465) to be a present-day country (or 15 countries?), rather than Soviet Union (Q15180). --Oravrattas (talk) 21:23, 22 February 2019 (UTC)
+1, it's unclear since the beggining (see the discussion, for instance Property talk:P17/Archive#Change this to be about modern countries in 2014 among many others). Cdlt, VIGNERON (talk) 21:54, 22 February 2019 (UTC)
Regarding the original battle item, it makes sense to me that the country should be marked as the country at the time it occurred (the battle isn't still ongoing and therefore isn't present in the modern country). For a battlefield (Q4895508) item, then it would make sense to use the modern country because the site still exists there. Surely if someone wanted to query battles in the UK or Ireland as originally proposed, then it lies on the data consumer to query the historical data appropriately. --SilentSpike (talk) 21:59, 22 February 2019 (UTC)
How should a country (P17) statement on an item like Battle of the Boyne (Q644960) be interpreted? Isn't it saying that the Republic of Ireland was one of the participants of the battle? The Republic was only founded in 1937. Ghouston (talk) 23:52, 22 February 2019 (UTC)
I think it would be a useful thing, if a full schema for battles and campaigns could be worked up -- looking at eg en:Template:Infobox military conflict there can be quite detailed information in wiki infoboxes that I am not sure we yet have the ability to fully represent. It's also perhaps surprising that there seems to be no Military History wikiproject here yet, to host and maintain such a schema. But participant (P710) I think would be the normal way to record who participated in a battle, with country (P17) used to indicate where the battle was. Jheald (talk) 10:29, 23 February 2019 (UTC)
Doesn't location (P276) give the location? But even as a location, the Republic of Ireland didn't exist until 1937. Also, states can be unreliable as locations, since their borders can change over time (consider the USA). Ghouston (talk) 10:35, 23 February 2019 (UTC)
P276 should also give contemporary location (location existed at that moment). If this location still exists it can have some modern country as a P17 value. --Infovarius (talk) 12:20, 28 February 2019 (UTC)
  • P17 can include both the current country and the historic one. The contemporary constraint was probably added without actually functioning or being discussed prior to addition. --- Jura 08:55, 24 February 2019 (UTC)
This constraint is so right. A battle like being a citizen of a country can only be contemporary to the person or event involved.. Stating them in modern times is an historical falsehood. Thanks, GerardM (talk) 19:35, 24 February 2019 (UTC)
+1. P17 is for contemporary countries. Otherwise, Jheald, how would we query for all battles on the territory of Kingdom of England (Q179876)? --Infovarius (talk) 12:20, 28 February 2019 (UTC)
@Infovarius: I think User:Jmabel was probably right above, when he said it would be useful to have both values. On Battle of Bosworth Field (Q222013) above, I have re-added United Kingdom (Q145) but with qualifier determination method (P459) = present-day boundaries (Q61912379). It would be useful to turn off the constraint warning when this qualifier combination is present. Jheald (talk) 12:28, 28 February 2019 (UTC)
valid in period (P1264) = present (Q193168) might also be appropriate way to indicate this. Jheald (talk) 13:20, 28 February 2019 (UTC)
I think what this ignores is how useful it is to be able to specify and retrieve a country (P17) as a relatively easy, quick, straightforward initial form of classification, based just on present-day boundaries. We may not have coordinates for the battle. It may be quite difficult to specify what historic territory it occurred in -- eg whose territory was Battle of Degsastan (Q2712138) fought on? Or Battle of Deorham (Q1429157)? It may be difficult to identify all the relevant historical territories for a set of present-day boundaries: wikidata doesn't currently have that information easily available, even for a country like United Kingdom (Q145). And if land was captured by one state, then recaptured by another state, whose territory was that second battle fought on? Also, if one wants to find battles fought in the present-day territory of Lithuania (Q37), one probably doesn't want to find everything fought in Grand Duchy of Lithuania (Q49683). So the idea of querying by matching back from present-day states to historical states doesn't really work. Alternatively it has been suggested to use located in the present-day administrative territorial entity (P3842), but this requires someone to have made the effort to have identified what the relevant present-day administrative entity would be; and also that the administrative tree is in good enough shape that it would be found for a search for a present-day country.
The key advantage of systematically including present-day country (P17) values is that they are almost always easily available, so it's something where one can aim for systematic good property-completeness as an immediate first step without too much difficulty. That makes them a very good initial stage in any data improvement drive; as well as providing an enabling basis of organisation for further improvement, by breaking the overall set into natural manageable chunks by present-day country that can then be the targets for further improvement. It's also a very useful property to have for comparison to external lists. Whatever solution we adopt to make it possible, these attributes must not be lost. Jheald (talk) 12:57, 28 February 2019 (UTC)
I tend to agree that P17 should avoid anachronisms. In SPARQL is it possible to create a kind of "function" that gives all items whose coordinates fall into a given current country (or region)? That would be the best for both usages. Syced (talk) 06:02, 1 March 2019 (UTC)
@Syced: It's not really possible, no. The nearest one can currently get is to ask for coordinates within a bounding circle or rectangle; or to try to identify a tree of historical entities to include; or if the items have a located in the present-day administrative territorial entity (P3842) value, to try to gather up matching items via that tree. But as commented immediately above, most items don't have located in the present-day administrative territorial entity (P3842) set; and there are some quite severe problems (even in principle) trying to get the right entities via their historical associations. Both approaches are a mile away from the immediate accessibility of P17, as well as being a lot more expensive to query -- a key consideration when the solution sets may be very big.
It's easy enough working offline to find code that will reasonably efficiently calculate within which of a number of possible boundaries a point falls. This makes the modern P17 something which can very efficiently be calculated offline, then written to Wikidata to make available online the useful grouping noted above.
The GeoSPARQL standard includes a function geof:sfWithin() to ask whether a point is within a polygon. But Blazegraph doesn't implement GeoSPARQL, only regular SPARQL. Possibly a similar function could be added as a SERVICE call by the WDQS developers; or, alternatively, a more efficient call that would work as a generator rather than a filter, taking directly into account the Z-order curve Blazegraph uses to spatially index points. But neither such call is available at present, and they would have to compete with quite a lot of other priorities to gain rather limited developer time. Jheald (talk) 09:27, 1 March 2019 (UTC)
Pinging @Lucas Werkmeister (WMDE): for thoughts, in case he has anything to add. Jheald (talk) 09:38, 1 March 2019 (UTC)
Nothing to add from my staff role except that T204045 is the task for GeoSPARQL support, if anyone wants to follow it. --Lucas Werkmeister (WMDE) (talk) 10:39, 1 March 2019 (UTC)

Solution using qualifiers?

A few lines above, I have suggested using qualifiers to indicate when a P17 value is for the corresponding present-day country, not a historically contemporary one.

Some questions:

  1. Do people feel that such an approach would broadly be acceptable, and viable?
  2. If so, what would be the best qualifier/value combination to indicate that the statement refers to a present-day country. E.g.
    determination method (P459) = present-day boundaries (Q61912379)
    valid in period (P1264) = present (Q193168)
    or something else?
  3. Is there a way to turn off the contemporary constraint (Q25796498) warning when such a qualifer/value combination is present? Or, perhaps, introduce a second, weakened form of the constraint to indicate that for some properties a value with such a combination is acceptable?

What do people think? Jheald (talk) 14:39, 3 March 2019 (UTC)

  • Maybe we should differentiate between various types of concepts using P17: for locations, using past and present values shouldn't be an issue. For some aspects of long gone countries, present day countries aren't of much use. Many are between these two. --- Jura 17:18, 3 March 2019 (UTC)

Battlefields

I also see we currently have separate entries for Battle of Bosworth Field (Q222013) and Bosworth Field site (Q55876564).

I think this is also unhelpful, and would propose to merge them. According to Reasonator, we currently have only 46 items that are instance of (P31) battlefield (Q4895508) [2].

In almost all cases therefore we will not have a separate item, so that would be the general expectation that searchers and queryers would expect. I don't see much value in having these as separate items. Exceptions might be if there are sitelinks, or if there is a significant set of properties that one would want to clarify apply to a preserved park, rather than the full original site; but otherwise I think it is not worth going against the general rule. Jheald (talk) 13:50, 22 February 2019 (UTC)

@Jheald: I think this is very helpful and much more clear to have separate item. Merging a point in time and a point in space would be messy and that would be unhelpful. Plus, as you said, in most case, the merge is impossible: see Waterloo Battlefield (Q16507442) and Battle of Waterloo (Q48314) with two distinct articles. Of the 47 items, 33 have a sitelink (70%). Cheers, VIGNERON (talk) 11:37, 24 February 2019 (UTC)
@Jheald: I also think that the battlefield should have a separate item. Some battlefields in Canada are national historic site of Canada (Q1568567), who is a designation of the place and not the event. Also, i see that a lot of battlefields are probably have theater of war (Q718893) instead of battlefield (Q4895508). We probably have some migration to do. --Fralambert (talk) 15:49, 24 February 2019 (UTC)

Structure of sports organizations/clubs/teams

Hello. Please, if you are interested, say your opinion at Wikidata talk:WikiProject Sports#Structure of sports organizations/clubs/teams. Xaris333 (talk) 10:46, 3 March 2019 (UTC)

Inverse of P831

Hello. The inverse of parent organization (P749) is has subsidiary (P355). What is the inverse of parent club (P831)? If we don't have one, do we need one? It'a about sports teams. We can say that

but how we can say that

I used to use has part(s) (P527) but P527 is not the inverse of parent club (P831). P527 is the inverse of part of (P361). If we can use P527 then we can also use P361 instead of P831, but that is wrong. Xaris333 (talk) 03:37, 2 March 2019 (UTC)

Between organisations(multi sport club and football club) use subsidiary and parent organization. Between team and club/organization use part of and has part. Since team is part of football club, it is implied that the football club is the parent club --Unnited meta (talk) 02:08, 3 March 2019 (UTC)
Hello @Unnited meta:. Please read Wikidata talk:WikiProject Sports#Structure of sports organizations/clubs/teams. A multi-sport club is not a parent club for a football club. A multi-sport club and a football club are parents club of teams. If we are going to use part of and has part, then parent club (P831) it will not be used at all. @Amadalvarez:. Xaris333 (talk) 10:43, 3 March 2019 (UTC)
I think that who created P831 wanted to illustrate a specific case of parent organization (P749). I do not know why he/she did not define Inverse; may be because is a bad solution, but it does not matter. For me, the solution is a) create a specific inverse for P831 or b) assume that has subsidiary (P355) is correct as Inverse of P831, since it is – de facto – an organization. As already happens with participant in (P1344) as inverse of participant (P710) and participating team (P1923), the double inverse is an assumible constraint. I vote for the b) option. Thanks,Amadalvarez (talk) 12:31, 3 March 2019 (UTC)
@Xaris333: Not necessary that we need to use parent club (P831). A subsidiary is specifically between organizations. Since we don't treat the team as an organization (the club is used for that) the relationship between team and club doesn't fit with subsidiary --Unnited meta (talk) 04:39, 4 March 2019 (UTC)

UEFA ID for coaches

Hello, I was wondering about the use of UEFA IDs for coaches. FIFA combine playing and coaching careers in their profile pages (FIFA player ID (archived) (P1469), example link here for Didier Deschamps (Q508711)), while Transfermarkt have separate profiles for someone's playing and coaching careers (Transfermarkt player ID (P2446) and Transfermarkt manager ID (P2447), example player and coach links for Carlo Ancelotti (Q174614)). However, UEFA use the same ID for someone's playing (UEFA player ID (P2276)) and coaching careers, however the information is displayed on different pages. For example, see the player and coach profiles for Ryan Giggs (Q10524). I wanted to add some of these UEFA IDs for coaches, but wasn't sure whether a new property should be created, it seems unnecessary to have duplicate values on items of players which became coaches. However, the URL scheme and scope of UEFA player ID (P2276) is currently meant for players. What would be the best solution? S.A. Julio (talk) 05:58, 2 March 2019 (UTC)

Looks like we may need a new property for that, don't think there is a mechanism to use a qualifier of coach and player and then differentiate the url with $1=$2 etc --Unnited meta (talk) 04:39, 4 March 2019 (UTC)

Legends should not end with full stop

Recently a new constraint added to media legend (P2096). [3] Is it correct? Is it wrong to use full stop (Q172008) at the end of the legend? I don't disagree or agree. I just want to know if it is correct. Xaris333 (talk) 20:24, 3 March 2019 (UTC)

Was there a discussion about this somewhere? (I don’t really care, either, but if we’re going to have a style guide we ought to discuss it.) - PKM (talk) 05:16, 4 March 2019 (UTC)
Maybe omit them, for consistency with labels and descriptions? At least in English. Ghouston (talk) 05:47, 4 March 2019 (UTC)

Shouldn't proper names be considered lexemes?

Ash Crow
Dereckson
Harmonia Amanda
Hsarrazin
Jura
Чаховіч Уладзіслаў
Joxemai
Place Clichy
Branthecan
Azertus
Jon Harald Søby
PKM
Pmt
Sight Contamination
MaksOttoVonStirlitz
BeatrixBelibaste
Moebeus
Dcflyer
Looniverse
Aya Reyad
Infovarius
Tris T7
Klaas 'Z4us' van B. V
Deborahjay
Bruno Biondi
ZI Jony
Laddo
Da Dapper Don
Data Gamer
Luca favorido
The Sir of Data Analytics
Skim
E4024
JhowieNitnek
Envlh
Susanna Giaccai
Epìdosis
Aluxosm
Dnshitobu
Ruky Wunpini
Balû
★Trekker

Notified participants of WikiProject Names

Wiktionary contains proper names. Why here on Wikidata they are considered items and not lexemes?--Malore (talk) 00:11, 27 February 2019 (UTC)

The name properties family name (P734) and given name (P735) were created as item properties without sufficient consensus for this data type. (When summoned, they have been kept with the reasoning, consensus for deletion hasn't been reached either…) Lexeme or multilingual text, or even monolingual text would be definitely much better choice, but I'm afraid, too many users and too many robots have made their career on Wikidata on propelling the established misconception and it's practically impossible to change it now. However, if you're willing to try, you can count on my support.--Shlomo (talk) 10:19, 27 February 2019 (UTC)

What about limiting the domain of named after (P138) and named by (P3938) to lexemes?

Currently, there are over 180000 uses of named after (P138), but only three of them are in lexemes.

named by (P3938) is used only one time for lexemes.

I think they should be used only for lexemes and for proper names. Why not including proper names in lexemes and limit the domain of these properties to lexemes?--Malore (talk) 00:21, 27 February 2019 (UTC)

Are you saying that we should not have, for example
? Or that something with lexemes would somehow replace this? - Jmabel (talk) 02:29, 27 February 2019 (UTC)
@Malore: Lexemes are for language-dependent concepts. named after (P138) is generally independent of language and should be at the concept level (items), not lexemes. Otherwise you would have the same relationship repeated for 300 lexemes (each language a proper name might be used in). ArthurPSmith (talk) 13:53, 27 February 2019 (UTC)
@Jmabel: I'm saying we should:
  • remove named after (P138)W. E. B. Du Bois (Q158060) from W.E.B. DuBois Clubs of America (Q7945187) because it doesn't talk about the organization but it talks about (one of) its name;
In general, I think an item shouldn't contain statements about its name, which can be more than one or differ from language to language. Instead, each of these names should be represented by a lexeme.--Malore (talk) 14:01, 27 February 2019 (UTC)
@ArthurPSmith: named after (P138) is not always language-indipendent. For example, Pascal's triangle (Q177051) can be named "Pascal's triangle" or "Khayyam's triangle" or "Yang Hui's triangle" or "Tartaglia's triangle", each of which is named after a different person. It's not so uncommon that the same thing is named after different people in different countries. Sometimes it's named after different persons even within the same country. --Malore (talk) 14:09, 27 February 2019 (UTC)
That's not a matter of language, that's conceptual attribution (you yourself mentioned it's a regional, not lingual, issue), and it should still be at the concept level, just have the concept named after several different people. Such problems are quite rare. Otherwise we're replacing 180,000+ items with 54 million+ (?) lexemes! ArthurPSmith (talk) 14:17, 27 February 2019 (UTC)
Because what you want for lexemes is derived from lexeme (P5191) anyway? Circeus (talk) 16:45, 27 February 2019 (UTC)
@ArthurPSmith: What I propose won't "replace" any item and, although it requires to create lexemes, these lexemes should be created anyway: "Pascal's triangle", "Tartaglia's triangle", etc. have every right to be lexemes. What I propose is to move the statements involving named after (P138) from the item to the lexemes' senses. It obviously requires more work but it will allow to better understand which word is named after which entity.
As for the regional vs lingual issue, it's not always true because January (Q108) is named after Janus (Q167685) in English, but it's named after ice (Q23392) in Czech.--Malore (talk) 21:00, 1 March 2019 (UTC)
You can qualify the statement on the item to express this. If you develop some model for these, maybe there is use for L-entities for "W.E.B. DuBois Clubs of America", but if it's only to link to "W.E.B. DuBois" indirectly, I don't see an advantage. --- Jura 12:06, 3 March 2019 (UTC)
Yes, we could use applies to name of subject (P5168), but I think it's conceptually wrong. I think this issue can be solved through a bot, without requiring to manually create a lot of lexemes--Malore (talk) 17:20, 4 March 2019 (UTC)

Different names in different roles

Nancy Bradfield (Q59529891) used her maiden name "Nancy Bradfield" in her work on dress history and her married name "Nancy Sayer" in her work as an illustrator. Is there an elegant way to record these facts in WD? - PKM (talk) 20:40, 2 March 2019 (UTC)

Presumably name (P2561) is the main property we're looking for here. Perhaps field of work (P101) for an appropriate distinguishing qualifier? Jheald (talk) 21:20, 2 March 2019 (UTC)
Interesting! It seems maiden name is typically represented with birth name (P1477) but pseudonym (P742) is usually used for a names used in a specific context (e.g. Hermann Hesse (Q25973) Mark Twain (Q7245)). Maybe use both and mark with field of work (P101) as @Jheald: suggests for pseudonym (P742)? That way it would be accessible to queries for people interested in either. -- ElanHR (talk) 20:12, 3 March 2019 (UTC)
It's not really a pseudonym if it was her actual birth name / married name. So that's why name (P2561) seems to me more appropriate than pseudonym (P742). It would also be appropriate to have statements for birth name (P1477) and married name (P2562), but I would suggest also have the two P2561 statements. Jheald (talk) 01:18, 4 March 2019 (UTC)
What seems right to me is new property “Professional name” = version of name used in a business or academic context, which will often be the version of the name used as the label (example J.R.R. Tolkien). - PKM (talk) 05:21, 4 March 2019 (UTC)
I would support that. Jheald (talk) 10:52, 4 March 2019 (UTC)

Linking to commons

Hi. I often try to link Commons cats to wikidata items but when I try do the add wikidata can't find the category, even though the category has existed for some time. For example, I am trying to link Matthew Quashie Q16150053 to commons but get this error A page "Matthew Quashie" could not be found on "commonswiki". Any idea why this happens? Gbawden (talk) 08:52, 4 March 2019 (UTC)

@Gbawden: Because c:Matthew Quashie does not exist but c:Category:Matthew Quashie does. The best thing to do is to add the property for Commons category and create a gallery page on Commons to link here. —Justin (koavf)TCM 09:14, 4 March 2019 (UTC)
I'm pretty sure that creating galleries on Commons just to link with Wikidata is a bad idea. Ghouston (talk) 09:17, 4 March 2019 (UTC)
? —Justin (koavf)TCM 09:18, 4 March 2019 (UTC)
Koavf Ok thanks that makes sense. Ghouston that wasn't my intention - I misunderstood what that linking was meant for Gbawden (talk) 09:21, 4 March 2019 (UTC)
Speaking as a Commons admin: please don't create a gallery as a redirect just for Wikidata's convenience. You can (and should) sitelink the Commons Category page directly. - Jmabel (talk) 17:13, 4 March 2019 (UTC)

If I add an image to a wikidata item the file name resolves quickly. However if I add a commons category the category name doesn't resolve, although if I hit publish it accepts and saves. Is this normal? Thanks Gbawden (talk) 09:32, 4 March 2019 (UTC)

@Gbawden: It should do that if you add it as a sitelink ('Other sites' -> 'commons' -> add 'Category:X', and you'll get a pop-down list of matches), but it won't if you add it as Commons category (P373). Despite what @Koavf: said above, the best thing to do now is to add it as a sitelink, not as P373 unless the sitelink is already used by a gallery. That way the information from Wikidata can be used on Commons through the infobox there. Please don't create a new gallery unless it's actually needed and going to be maintained. Thanks. Mike Peel (talk) 10:28, 4 March 2019 (UTC)

Protect Q60458248

Hello,

This item should be protected as it is the victim of troll attacks. Cheers, FR (talk) 12:34, 4 March 2019 (UTC)

I protected it. ChristianKl12:55, 4 March 2019 (UTC)

What's going on with P1946 (P1946)?

When this was originally proposed (and accepted with only two votes), there was no formatter URL. The one that has been added since is completely improper, as it has nothing to do with actual author records, but only book records. In fact, the numbers found in VIAF systematically correspond to individual works in that url, and not even works by those authors.

Example 1: In the original property proposal, Philip Henry Wicksteed (Q2306330) is given as having the id vtls000036581, this is the record for the Irish version of a Children's book about Ancient China (the author of which has become entangled on Wikidata with Lustmord (Q913245), I have fixed the VIAF link, but it will take some work to properly disentangle them).

Example 2: To Marianna O'Gallagher (Q3291272) was added the purported id vtls000086697. this correspond, again, not to O'Gallagher, but one of her books It is not, in fact a valid author record at all. The correct id as reported in VIAF is vtls000022718, and that corresponds to an edition of a play by Marina Carr (Q467609).

Example 3: Even the property example on the property page itself is incorrect, because the correct id in VIAF is vtls000044446.

I have deleted the formatter url from the property, as not only is it incredibly misleading, but the author records are not accessible online. I suspect many more authors that O'Gallagher are in the same situation of having a given record number that is incorrect. Circeus (talk) 15:43, 4 March 2019 (UTC)

Wikidata weekly summary #354

iCarly (Q3013) could need some protection

Seems there is a Spanish Michael Jackson meme going the rounds that is somehow related to iCarly, the item is seeing quite a bit of vandalism. If an Admin could have a look that would be great. Moebeus (talk) 19:16, 10 March 2019 (UTC)

✓ Done, protected for three months--Ymblanter (talk) 20:02, 10 March 2019 (UTC)
Thank you! Moebeus (talk) 01:07, 11 March 2019 (UTC)
This section was archived on a request by: Moebeus (talk) 01:07, 11 March 2019 (UTC)

How to distinguish against events?

I'm trying to find items near a given geographical point that are not events -- eg not 'happenings'.

It used to be that I could exclude (or de-prioritise) items that were in the subclass tree of occurrence (Q1190554) to achieve this.

But now I am finding chains like the following are breaking this assumption

and similarly for eg monastery (Q44613) --> organization (Q43229) etc

So: (i) do we think these are valid subclass of (P279) chains ?

And (ii) how best now to distinguish/exclude true "events" -- ie things happening over a finite (short) duration -- from general items ? Jheald (talk) 22:54, 24 February 2019 (UTC)

The most recent link in the chain above I think was organization (Q43229) --> order (Q16513015), by User:-xfi- on 27 January diff. This is what I think has joined up the chain, that has broken my query. It may have been based on reading a different sense of the word "organization". On the other hand, maybe it has a certain validity. Are there other links that should be questioned? Jheald (talk) 23:06, 24 February 2019 (UTC)
That certainly strikes me as the weakest link in the chain. - Jmabel (talk) 00:31, 25 February 2019 (UTC)
That link is certainly questionable, but I also question the chain which leads us from state (Q3505845), which seems to me to be associated with a certain stability and duration, to occurrence (Q1190554), which is specified to have has characteristic (P1552) = point in time (Q186408). The distinction would be useful to be able to draw, in our class tree, I think. Jheald (talk) 12:27, 25 February 2019 (UTC)
It’s very possible state (Q3505845) is actually a metaclass, so should be left out of this class tree. Let « combat state » be the state of a military ship prepared for a fight (Real example in Wikidata if I recall). This « combat state » has instances in the real world, obviously, and can be characterized - weapons armed, crew ready … But imho it’s not a subclass of states, but an instance of state. A state is then not a subclass of events, but a class of events. This fits with the definition of a state : « denotes the presence of stable values of a set of variables of an object ». Combat state IS the set of variables of the ship. The « state » concept itself is a kind of events-class, it is instantiated by giving the characteristics of the instances of that event class - just like the « ship » concept is instantiated by giving an object that fits the characteristics of a ship. author  TomT0m / talk page 12:54, 25 February 2019 (UTC)

WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. for input -- Jheald (talk) 12:29, 25 February 2019 (UTC)

Why should phenomenon (Q483247) be a subclass of occurrence (Q1190554)? A phenomenon (Q483247) is not necessarily associated with any time. — Finn Årup Nielsen (fnielsen) (talk) 12:56, 25 February 2019 (UTC)
The definition in english is « observable occurence », by this definition this is an event. On the frwiki article however we get a different definition « Un phénomène est la manière dont une chose, un fait du monde physique (objet, action…), psychique (émotion, pensée…) ou social (produit d'interactions sociales) se manifeste à la sensibilité d'un être vivant. » (a phonomenom is the way a thing or a physical (or social) fact manifests itself to a beeing sensitivity) which is definitely not the same. I’d say that then that it’s the same as for « state », « phenomenom » may be a metaclass. Watch a tree out of the window, you’ll feel twice the same tree, experimenting something similar if not identical. It seems reading a little more reading the frwiki article a little more that a « phenomenom » could be more precisely defined as a process in which a living entity feels the outside world. If instances of a process (say « jumping ») are events, « jumping » is a subclass of events. But not « process », which is a kind of events, a metaclass. So I’d best see « phenomenom » as a metaclass, but philosophical notions are always a challenge. author  TomT0m / talk page 13:30, 25 February 2019 (UTC)

It's not just this chain. I keep noticing subclass relationships on general classes that I do not agree with. I've learned to just live with them, to the point that I don't even record or remember them. If someone is interested in attempting to clean up the subclass hierarchy in Wikidata I'm motivated to participate. My first suggestion would be to require that general classes have a much better description, with examples and counter-examples, so that at least there is some guidance as to what correct and incorrect subclass relationships are. With the current level of documentation for general classes, it can be impossible to determine whether a subclass relationship on one of them is valid. Peter F. Patel-Schneider (talk) 12:54, 25 February 2019 (UTC)

I removed "order" as a superclass for "organization", and added it separately under "has quality". I see a lot of people using the class hierarchy for abstract relationships like this when we have much more suitable properties. There's no reason to defer to something that doesn't make sense. ArthurPSmith (talk) 13:35, 25 February 2019 (UTC)
I’m curious to know the rationale behind that statement. Is the « order » term used as a kind of synonym of the structure of an organization ? I can’t read the articles in which the term is defined. author  TomT0m / talk page 13:49, 25 February 2019 (UTC)
It seemed like a better relation - but perhaps there should be no such relation? I don't mind if somebody else removes it completely. The subclass of (P279) relation was certainly wrong anyway. I suspect the editor who added that was thinking of the meaning of the word "organization" as a state or condition, not the actual meaning of that entity as a class of groups of people etc. ArthurPSmith (talk) 17:02, 25 February 2019 (UTC)
I agree with Peter F. Patel-Schneider. The problem seems to be that subclass relationships are added on an adhoc basis whenever somebody thinks it's a good idea. This is the Wiki way after all. But unfortunately they don't always verify that every instance of the subclass is also an instance of the parent class. I'd suggest that an improvement would be to discuss the reasoning for the relationships in detail in the Talk page for each item, and then watch the item to revert changes that aren't consistent with the reasoning, at least without further reasoning. Ghouston (talk) 22:17, 25 February 2019 (UTC)
We probably also need regression tests. These would be particular queries that are expected to return certain results. Ghouston (talk) 22:41, 25 February 2019 (UTC)
Perhaps it would be useful if we had a central {{Wikidata list}} (or equivalent) for the upper ontology, which users could add to their watchlists to monitor changes to the items (and use the history to find the order of changes), and other lists for specialized ontologies for each Wikiproject which could be monitored there. --Yair rand (talk) 22:53, 25 February 2019 (UTC)
{{Wikidata list}} could also be used to construct regression tests: you'd just have to add the output page to your watchlist. Ghouston (talk) 23:10, 25 February 2019 (UTC)
I created the page Wikidata:WikiProject Ontology/Top-level ontology list to show the top two levels of the ontology, the theoretical fundamentals as stored on Wikidata. It's ... pretty bad. :( --Yair rand (talk) 02:26, 28 February 2019 (UTC)
Yeah, and improving it would involve a multitude of struggles, on a case-by-case basis. Ghouston (talk) 21:36, 28 February 2019 (UTC)
A lot of the entries are colours, I think I can do something with those. Ghouston (talk) 21:45, 28 February 2019 (UTC)
@Ghouston: Be sure to discuss with User:ArthurPSmith before wading in too quickly re colours. It's been quite a contentious area in the past. Jheald (talk) 21:48, 28 February 2019 (UTC)
Still, they can be subclasses of color (Q1075) instead of subclasses of entity (Q35120) ... it seems to me. Ghouston (talk) 21:53, 28 February 2019 (UTC)
Well, nothing is easy. What does the item color (Q1075) represent? Enwiki says "colour (Commonwealth English), is the characteristic of human visual perception described through color categories, with names such as red, orange, yellow, green, blue, or purple." So it's a "characteristic of human visual perception", but maybe we'd need another item to represent the colours themselves. Or perhaps color (Q1075) should represent the colours and there are other items like color vision (Q374259) to represent the mechanism. Ghouston (talk) 22:04, 28 February 2019 (UTC)
@Ghouston: User_talk:ArthurPSmith#Colors_as_subclass_of_entity?. --Yair rand (talk) 22:33, 28 February 2019 (UTC)
I see you've already been over the exact subject, and it shows how obscure these discussions can get. I'd imagine having a particular item representing the range of possible colours (at least such colours as we'd want to describe with items), with a colour like "red", actually a range of colours, being a subclass, and a "pure" colour, an item representing a "single colour" that can't be divided, being an instance. Ghouston (talk) 22:54, 28 February 2019 (UTC)
@Ghouston: Relevant: Wikidata:Requests_for_comment/Are_colors_instance-of_or_subclass-of_color. I'm not even sure if distinct "single colors" are things that can exist. Or maybe all the colors are pure/indivisible colors, but just somewhat ambiguous which one it is? Interestingly, the Suggested Upper Merged Ontology has Red instance of PrimaryColor subclass ColorAttribute subclass VisualAttribute, but Emw mentioned that BFO uses subclass all the way. Maybe splitting the colors into range items and pure-color items makes sense. (Notifying @ArthurPSmith: of this discussion.) --Yair rand (talk) 23:49, 28 February 2019 (UTC)
Uh, yes, it gets complicated. I think starting at the top level is the wrong approach - it's much easier to think about relationships at a more concrete level, and even with something seemingly as simple as color is actually quite tricky. As I just noted on my talk page, I think treating colors as classes may have been wrongheaded, and we should handle them more like the way we handle locations. Locations have natural hierarchies which we capture in wikidata with various properties like located in the administrative territorial entity (P131). Perhaps we need a special property for color space that works similarly - or maybe a generic property like facet of (P1269)? Using subclass of (P279) to represent this hierarchy seems to be definitely quite confusing. ArthurPSmith (talk) 16:00, 1 March 2019 (UTC)
It's hard to work out whether or not colours should have a subclass hierarchy, and how to construct a hierarchy. However, it doesn't seem to me that individual colours deserve to be near the top-level item in the ontology. Maybe the best thing for now would be to make each colour item an instance of color (Q1075), as many already are, and remove any subclass statements. At least they will be grouped together and can be enumerated with a simple query. Ghouston (talk) 08:00, 3 March 2019 (UTC)
Alternatively perhaps make the top level of colours a subclass of qualia (Q282250) ? Jheald (talk) 10:08, 3 March 2019 (UTC)
That would be color (Q1075) itself. Colours are subjective, but in response to particular a physical phenomenon, so colours can be standardised and measured and so forth. Ghouston (talk) 10:15, 3 March 2019 (UTC)
Don't think so. Every case of a colour in the class "red" is a case of a qualia. So that looks more like a subclass relationship. It may also be a case of a physical phenomenon. Items can combine more than one class heritage. Jheald (talk) 10:29, 3 March 2019 (UTC)
I don't think that the idea of colour subclasses is wrong, although building a good hierarchy of colours would be difficult because there are different schemes for defining and naming colours. You can start with a statement like "red is a colour", which gives an idea of what the "colour" item is going to be: the class of all possible colours. So red (Q3142) is an instance of color (Q1075). But then if you read the Wikipedia article about red, it confirms that red is a colour, but it turns out there's a whole range of reds, each of which can also be described as colours. Some are defined from the colours of chemical compounds, some from colour standards, some may be pretty vague. So it also makes sense to say that red (Q3142) is a subclasss of color (Q1075). Ghouston (talk) 10:57, 3 March 2019 (UTC)
If you declare that A is an instance of B and also a subclass of B you must be either conflating two different meanings in the item "A" or in the item "B"; in this case I think the conflation is between "red as a color" and "colors perceived as reddish" as a class of colors. As to the "top of the class hierarchy" issue - I think this is a pretty meaningless criterion. If you look at computer programs (java say) in practical use, huge numbers of classes are at the "top of the class hierarchy" because it's not useful to define them as subclasses of anything else. It's not wrong or a problem, just the way the world is. At least that's my view. But I wouldn't be opposed to a more general color class representing "all of colorspace" or something like that if it made sense. ArthurPSmith (talk) 14:27, 4 March 2019 (UTC)
Maybe perception (Q160402)  View with Reasonator View with SQID is a better item, less close to the philosophical definition problem. Both can be done, a specific colour seems to be a qualia-class to me.
⟨ visual perception ⟩ subclass of (P279) View with SQID ⟨ perception ⟩
-
⟨ human visual perception ⟩ subclass of (P279) View with SQID ⟨ visual perception ⟩
-
⟨ (human) color perception ⟩ subclass of (P279) View with SQID ⟨ Human visual perception ⟩
(because of course bees do not perceive the colours the same way humans do-
⟨ Red ⟩ subclass of (P279) View with SQID ⟨ (human) color perception ⟩
. The « colour » property associated to this hierarchy could then be labelled « perceived by human as colour».
If we want to then have a « colour » class, it should be a perception meta-class. This item would be described as « a class of visual sensation that humans gives names to, by which they can characterize objects or lights. »
Anyway there is a lot of aspects of colours (blue-light for example is different from blue-light qualia, a blue object is also something different), so a « one size fits all » approach may be doomed to fail. Also it would be a shame to avoid the hierarchy issue when it seems there is a natural colour hierarchy. A classification of light rays according to their wavelenght (X-ray, visible light, infrared …) is definitely something doable. Of course then « red light » is naturally a subclass of « visible light ». Of course it’s a little bit more complicated if there is a combination of different wavelenghts like in the light emitted by a star of in « white light » (enwiki: « White light, a combination of lights of different wavelengths in the electromagnetic spectrum »).
Another item funny item I found HTTPS://WWW.WIKIDATA.ORG/WIKI/Q375479
To sort this mess, I think I important question is « what do we want to achieve, what are our use cases ? » Do we want to describe paintings with colours ? Describe star lights ? Both ? Why should we have only one colour property ? author  TomT0m / talk page 10:59, 3 March 2019 (UTC)
This is why we have abstract concepts like "colour", so that we can talk about colours as a general concept and not have to deal with each colour individually. So whatever a colour is declared to be, we can declare it on color (Q1075), and then declare individual colours to be instances or subclasses of that. Ghouston (talk) 19:39, 3 March 2019 (UTC)
@Ghouston: There is a definition of color (Q1075) : « visual perception of light wavelengths … » (english description) and it’s no more no less abstract than any other concept. I don’t think we can use this as a catch all item for anything related to the colour domains as we like. So I don’t think your suggestion, if I understand it correctly, is of any help to sort anything out. author  TomT0m / talk page 12:38, 4 March 2019 (UTC)
"Visual perception of light wavelengths" is really the definition of color vision (Q374259). How do you define "a colour"? It will involve some subset of visible light. It's true some statements about particular colours may not apply to all colours, so can't be put directly on color (Q1075). In some cases the statement may be unique to that colour, in other cases there may be a subclass of colours, such as colours of a single hue, monochromatic color (Q6901438). Ghouston (talk) 20:18, 4 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── A useful reference here might be the Getty AAT color hierarchy, which distinguishes "colors (hues or tints)" and "color (perceived attribute)". [They also have color (pigment)" as a material, one or more pigments collectovely in suspension, but that's different.] - PKM (talk) 23:08, 4 March 2019 (UTC)

color (Q1075) is currently linked to the first two, using Art & Architecture Thesaurus ID (P1014). I think 300080438 colors (hues or tints) is the right match for this item. I'm not sure if there's an existing item corresponding to 300056130 color (perceived attribute), or how it could be used. Ghouston (talk) 04:29, 5 March 2019 (UTC)

Unclear semi-protection of all (?) items

FYI, reported on the Admin noticeboard, because the New York Times asked for a reliable and independent third party source.:tongue:84.46.53.245 17:54, 4 March 2019 (UTC)

P4224 and redundancy

Epìdosis
Jura
PKM
ValterVB
Jheald
Ghuron
Infovarius
Sannita
Avatar6
Pasleim
John Samuel
ElanHR
Tris T7 TT me
D.C.flyer
Csisc

Notified participants of WikiProject Categories

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

We have certain disagreement with @Brya: regarding possibility to add statements like Category:Boidae (Q7149834)category contains (P4224)taxon (Q16521). As far as I understand, he believes it is redundant because Category:Boidae (Q7149834)category's main topic (P301)Boidae (Q45556) + Boidae (Q45556)instance of (P31)taxon (Q16521) and such statements clutter view for human being, who might decide to edit such items manually. I think that having P4224 statements on as many category items as possible reflects current community consensus and simplifies both writing SPARQL queries and manual editing. We don't have to rigorously follow database normalisation (Q339072) here, some verbosity is good. @Infovarius: believes that category contains (P4224)taxon (Q16521) +parent taxon (P171) as qualifier are useful and supported by reasonator. Other members of Taxonomy project were not particularly interested in this discussion, so I am trying to get opinions of wider audience here. --Ghuron (talk) 08:49, 1 March 2019 (UTC)

I must admit that I did intentionally not participate in the discussion, but I have read it. As far as I am concerned, I agree with Brya that we should be reluctant in adding data that can be constructed from existing data-chains. So I have serious doubts as to if category contains (P4224) improves our structured data. I can understand the SPARQL-argument, but IMHO we don't build our database for SPARQL. Having said that, you can conclude that I am not really into the community consensus on category contains (P4224). Lymantria (talk) 11:34, 1 March 2019 (UTC)
@Lymantria: can you please elaborate more on what kind of doubts you have regarding P4224? --Ghuron (talk) 16:19, 1 March 2019 (UTC)
Well, let me try the obvious example: the claim of is about the elements of that catogory being taxa. But nl:Categorie:Insect for instance contains sterile insect technique (Q1462045) and insect hotel (Q1664398), both not being taxa. Lymantria (talk) 17:06, 1 March 2019 (UTC)
@Lymantria: I do not see how does this relates to redundancy. You are right that Category:Insects (Q5608148) should not have P4224 statement (thus I reverted my edit). I certainly can verify if there are any non-taxon items, that belongs to the category, and, if so, do not add P4224 --Ghuron (talk) 13:38, 4 March 2019 (UTC)
As per Lymantria, a big issue is how categories are used on different language Wikipedias. Even for plants on the English Wikipedia, where we try hard to separate "taxonomic" categories from more general ones, it's not possible to persuade all editors that this is correct, and there are many "mixed" categories like the nl one above. Only yesterday I altered en:Category:Fagopyrum and en:Category:Buckwheat so that they were distinct, but this may not have consensus, and will probably get changed back. So I do rather support Brya's point. Peter coxhead (talk) 20:55, 1 March 2019 (UTC)
@Peter coxhead: I agree that different wikis has somewhat different ideas about criteria for inclusion articles in the categories mentioned above (and many others). But the issue for >4M items will not disappear once we declare it. We might want to capture and express this criteria in wikidata and allows local wikis to display it. P301 is certainly step in the right direction and Template:Cat main (Q6383110) can use it. I've also seen some categories in uk-wiki (couldn't find it now), that were using P971 statements to describe criteria, but I strongly believe that P4224 is more appropriate way to express it. For instance, when I (incorrectly) add Category:Insects (Q5608148)category contains (P4224)taxon (Q16521) and if en:Category:Insects would be displaying header like The main article for this category is Insect. The category should contains instances of taxon, exceptions are possible as rare values may exist, people would notice this and revert my edit. Alternatively, if they see that majority of categories are dedicated to taxons, they will extract other categories to separate element. --Ghuron (talk) 13:38, 4 March 2019 (UTC)
I sympathize with @Brya:'s desire to simplify things and not needlessly duplicate information however category contains (P4224) and category's main topic (P301) serve different semantic purposes and should not be considered redundant. category contains (P4224) typically defines a Wikimedia category (Q59542487) whereas category's main topic (P301) is typically used to provide context and applies to all category types even those serving administrative functions (e.g. Category:Wikipedia administration (Q2944611)). Additionally even in cases where category's main topic (P301) can be used to infer a set category (as it appears to be in the case for taxon (Q16521)) the conversion to category contains (P4224) statement is often context dependent and requires information not captured in category's main topic (P301). For example:
While the approach using category's main topic (P301) may work with the current structure of taxonomic categories, it does not scale well to other domains. category contains (P4224) provides a way to specify the necessary information needed to define most category memberships while not requiring an editor to know SPARQL. -- ElanHR (talk) 00:07, 3 March 2019 (UTC)
As arguments go, this is not very convincing:
Brya (talk) 15:14, 3 March 2019 (UTC)
@Brya: Wikidata UI displays a single item "as is" and does not have to do it differently depending on whenever it is human, taxon or wikimedia category. Major wikidata consumers such as infobox modules, google knowledge strip (graph), siri/alexa/cortana, etc do some preprocessing such as filtering/joining/aggregation/etc. They also do not want to have different processing for items depending on their P31. They value uniformity over redundancy and it is not a "matter of writing one's software properly". It is cost of access to data, and if its too high, the data will not be used. --Ghuron (talk) 13:38, 4 March 2019 (UTC)
In my experience there are different kinds of infoboxes for different topics. In that case it is no hardship to make sure that the infoboxes read the information correctly. Commercial sources such as siri/alexa/cortana can afford to write their software properly, although they would prefer to slide by without making an effort. - Brya (talk) 17:46, 4 March 2019 (UTC)
@Brya: Whoops - definitely had a typo in my 3rd example (meant Germany (Q183) instead of a Germans (Q42884)) thank you for pointing that out - I've fixed in the original.
I totally agree that in some cases 'main topic' can be used (with appropriate domain knowledge) to infer the set definition reasonably well. That said I still believe category contains (P4224) provides a much more natural and scalable way of doing so. Perhaps an argument that would sit with you better would be cases where constructing an appropriately descriptive 'main topic item' would itself be unnatural. For example:
Note: As part of my project:Conflict of interest (Q4663309) I will mention that I have a relationship with Google (Q95). That said, data normalization helps everyone! As you pointed out, larger institutions have the resources to deal with these issue but properly structuring data allows hobby developers like @Ghuron: (and myself) to create consistency checks as well as import information that has been already human-curated in the form of structured categories. Cheers, ElanHR (talk) 05:21, 5 March 2019 (UTC)
If nothing else, your third example shows that adding an extra, redundant shell brings extra risks of introducing error.
        Your "Category:Hindu poets (Q8514421) (could be easily modeled as Category:Hindu poets (Q8514421)category contains (P4224)human (Q5)religion or worldview (P140)Hinduism (Q9089)occupation (P106)poet (Q49757))" is a case where there isn't a "category's main topic" so seems to be out of scope for this discussion.
        As with everything, data normalization can be overdone. It depends entirely on one's perspective if a further degree of normalization is helpful; in practice data normalization often enough loses information and introduces error. - Brya (talk) 12:14, 5 March 2019 (UTC)

Mass revert?

My bot made some unfortunate edits (unexpected statements removed, code is now fixed so it won't happen again). Can someone easily revert ~2800 revisions with these revision IDs please? They should all be the latest edit on the respective item, at this moment. Is there a tool for that? --Magnus Manske (talk) 14:59, 1 March 2019 (UTC)

@Magnus Manske: I am not aware of a tool for that, but have you considered enabling your bot for EditGroups? This way it will not be a problem if (when?) that happens again. − Pintoch (talk) 16:29, 1 March 2019 (UTC)
Doing, but it will take an hour or so… —MisterSynergy (talk) 19:51, 1 March 2019 (UTC)
Now done. —MisterSynergy (talk) 21:19, 1 March 2019 (UTC)
Thanks! --Magnus Manske (talk) 08:32, 5 March 2019 (UTC)

how to add more languages in a page

[5] sagt "choose your language in the menu that appears at the top of the screen, and then happy editing !". bei mir erscheint aber kein "menu at the top of the screen". (um ping wird gebeten) W!B: (talk) 18:12, 1 March 2019 (UTC)

PS: übrigens schaff ich es auch nicht, ein zweites alias einzugeben. beim erstellen steht "Aliasse, mit „|“ getrennt", aber wir geht das beim datenobjekt? (Q1776351) W!B: (talk) 20:01, 1 March 2019 (UTC)
Ich nehme an, es geht um das Änderung von Bezeichnungen, Beschreibungen, und Aliasse (hier zusammengefasst als "Begriffe"). Es gibt da im Grunde zwei Möglichkeiten:
  1. Du hast Javascript aktiviert, und wartest bis die Objekt-Seite vollständig geladen ist. Dann kannst Du mit dem "bearbeiten"-Link direkt über der Box mit den Begriffen den Bearbeitungsmodus direkt auf der Objektseite aktivieren. Dabei kannst Du alle Sprachen bearbeiten, für die bereits eines der Felder ausgefüllt ist (ggf. "In weiteren Sprachen" klicken), oder die Du standardmäßig angezeigt bekommst (siehe hierzu auch weiter unten in diesem Kommentar). Bei dieser Methode brauchst Du keine "|"-Separatoren für Aliasse, da immer hinreichend viele Felder angezeigt werden.
  2. Ohne Javascript wirst Du zum Bearbeiten auf die Seite Special:SetLabelDescriptionAliases/Q1776351 geleitet, um Begriffe zu bearbeiten. Da steht auf der Seite dabei, in welcher Sprache Du bearbeitest, und das ist meines Wissens dieselbe Sprache, die Du für die Benutzeroberfläche ausgewählt hast. Typischerweise wird das mit dem "Universial Language Selector" ausgewählt, der im Vector-Skin rechts oben neben dem Link zu Deiner Benutzerseite zu finden ist. Das dürfte das "menu at the top of the screen" sein. Alternativ kannst Du mit bspw. Special:SetLabelDescriptionAliases/Q1776351/fr zum Beispiel die französischen Begriffe mit deutscher Benutzeroberfläche verändern, oder neu setzen falls sie noch überhaupt nicht existieren. Bei dieser Methode gibt es nur ein Feld für Aliasse, die entsprechend mit dem Separator "|" getrennt werden müssen – siehe auch Special:SetLabelDescriptionAliases/Q1776351/de im aktuellen Zustand.
Letztlich noch ein Kommentar zu den standardmäßig für Dich angezeigten Sprachen: das wird aus irgendeinem Grund so ausgewählt, wie Du babel-Boxen auf Deiner Benutzerseite hast. Ich nehme also an, dass Du zurzeit deutsche und englische Begriffe angezeigt bekommst, und alles andere versteckt wird. Korrekt? Viele Grüße, —MisterSynergy (talk) 20:24, 1 March 2019 (UTC)
danke dir, das hilt. ja. mit Special:SetLabelDescriptionAliases/Q1776351/la (das wollte ich) hats geklappt. ich hab Javascript natürlich an. und ja ich kann alle sprachen bearbeiten, für die bereits eines der felder ausgefüllt ist. nur, wie leg ich eine neue sprache an? oder geht das sowieso nur mit Special:SetLabelDescriptionAliases? und wenn dem so ist, wärs doch nett, den link dort zu deponieren. jedesmal Javascript ein/aus, sprache umstellen oder den link händisch eintippen ist ja auch nicht lustig.
(PS: bei "alias hinzufügen" hab ich mich übrigens nur patschert angestellt. W!B: (talk) 20:57, 1 March 2019 (UTC)
Es gibt unter Special:Preferences#mw-prefsection-gadgets ein Gadget "labelLister". Wenn Du das aktivierst, bekommst Du zwischen den Tabs "Lesen" und "Versionsgeschichte" (im Vector-Skin) einen weiteren Tab mit einem separaten Begriffe-Tool. Das braucht auch Javascript, aber da kannst Du dann auch einen Sprachcode ohne bereits definierte Begriffe angeben und dann entsprechend etwas ergänzen. Etwas anderes fällt mir gerade nicht ein… —MisterSynergy (talk) 21:09, 1 March 2019 (UTC)
tut mir leid, aber das zeigt auch nur die schon eingegebenen sprachen (und das "NEW ! : Change several language in one fell swoop (go to beta version)." schickt mich nur wieder zum eingabefeld)
ich würde dich jedenfalls herzlichst bitten, das irgendwo auf der passenden hilfeseite zu vermerken (ich kann ja nicht der erste sein, der damit kämpft), und einen bugreport zu machen: es würde auch reichen, wenn ich irgendwie standardmässig "alle sprachen" bekomme: ich kann ja auch den italienischen namen einzugeben fähig sein, ohne italienisch zu können (googlen reicht). da hält uns wer für zu dumm ;) W!B: (talk) 23:22, 1 March 2019 (UTC)
Hier klappt das mit der älteren Version von labelLister durchaus. Wenn ich auf den Tab klicke kommt ein Dialog eingeblendet, dort auf "edit" bzw. "Bearbeiten" klicken. Dann ist da ein Eingabefeld, wo ich einen Sprachcode eingeben kann (zum Beispiel "hu" für Ungarisch), auch solche die noch keine Begriffe haben. Klappt das auch nicht?
Mir ist leider keine vollständige Liste der Sprachcodes bekannt, allerdings sollte Help:Wikimedia language codes/lists/all für die allermeisten Anwendungsfälle reichen. —MisterSynergy (talk) 07:14, 2 March 2019 (UTC)
MisterSynergy: ah, jetzt geht der labelLister: steht als "Liste der Bezeichnungen" ganz oben zwischen "Lesen" und "Versionsgeschichte". ich hab wohl nicht genug neu geladen nach dem freischalten, sollte ich eigentlich wissen ;). danke dir für mühe. W!B: (talk) 12:08, 5 March 2019 (UTC)

Way to model a gift (Q707482)

In this example: Domestic Scene (Q18510574), the subject of the item has been given to the museum that still owns it. This is currently modelled with significant event (P793) and the givers are qualified with participant (P710). I would like to explicitly mention the receiver(s) for such statements. How should this be done? Are there gift examples anywhere? Thanks in advance. Jane023 (talk) 11:05, 2 March 2019 (UTC)

We have donated by (P1028), currently 3370 times as a main statement and 2963 as a qualifier. Does this fit the need? Jheald (talk) 15:51, 2 March 2019 (UTC)
Interesting thanks! I didn't know about that, but it works for the giver. I am still looking for the receiver. See e.g. Dutch Gift (Q1165096). Jane023 (talk) 09:28, 4 March 2019 (UTC)
Reception will often be implicit in the start date of a collection (P195) statement, which would implicitly identify the receiver. But I can see things may get more challenging if there is a lengthy chain on provenance that we are seeking to record, more than just the final gift to the current collection. Although, on the other hand, an item can have many collection (P195) or owned by (P127) statements, each with a start date and end date. Jheald (talk) 10:58, 4 March 2019 (UTC)
Well I was thinking more generically, not just for collections, but to pinpoint a gift in time and place with giver(s) and receiver(s). Donated by works, but received by is needed. Jane023 (talk) 17:34, 5 March 2019 (UTC)

I think that most of labels and interwikis of sugar substitute (Q626292) actually mean sweetener (Q4368298). We need to seperate them. --Sharouser (talk) 12:31, 5 March 2019 (UTC)

Editing is desperately slow today?

Is there a problem with editing today? (Or is it just my set up?)

Editing just now, I keep getting "technical error - timeout" edit messages the first time I try to make an edit. If I try to make the edit again, the second time it usually works; but this shouldn't be happening. Are other people getting this too, or is it just me? Jheald (talk) 14:38, 5 March 2019 (UTC)

Candidate for elected office

Is there a standard way we show someone was a candidate for an elected office without creating, say, 50 "candidate for Governor of state X" entries? If we created the categories would it also list the winner of the election or just the losers? --RAN (talk) 20:54, 1 March 2019 (UTC)

The usual way seems to be to create one item per election (often created anyway for Wikipedia), then each person can be listed with candidate (P726). E.g., 2012 South Korean presidential election (Q82241) Ghouston (talk) 04:15, 2 March 2019 (UTC)
There's also the inverse approach, using candidacy in election (P3602) on the person, pointing at the election item. --Oravrattas (talk) 08:26, 2 March 2019 (UTC)
This section was archived on a request by: Ghouston (talk) 00:10, 12 March 2019 (UTC)

P53 (family)

Property:P53 is set to contain only a single value, but isn't every noble woman that marries into a noble family a member of two noble families? She would be a member of her parental family and after marriage a member of her husband's noble family. How should this be handled? Looking at various examples they tend to be a mix of the parental family and the family they marry into. Is it meant to only be genetic (parental family)? --RAN (talk) 05:16, 4 March 2019 (UTC)

Like Isabella Teotochi Albrizzi (Q5454), for example. That one could be fixed by marking start/end time qualifiers as separators in the constraint. But the setup on that item assumes that somebody ceases to be a member of a family when they marry into another family, which seems doubtful. Ghouston (talk) 05:59, 4 March 2019 (UTC)
No, it doesn't make that claim, only the first married family has an end time. I added start/end time as permitted qualifiers on family (P53), and as separators on the single-value constraint, that should be enough to handle it? Ghouston (talk) 06:35, 4 March 2019 (UTC)
Should we remove the restraint that it contain a single value? Half the entries will give an error if we assume half of the noble family entries are female. --RAN (talk) 06:49, 4 March 2019 (UTC)
Just give a start date for the second family and the constraint should be satisfied, even if it's <unknown value>. Ghouston (talk) 07:09, 4 March 2019 (UTC)
@Ghouston: How do I add in a null value, does it have a Q code? --RAN (talk) 18:04, 5 March 2019 (UTC)
See Help:Statements#Unknown or no values. Matěj Suchánek (talk) 19:10, 5 March 2019 (UTC)
  • Isabella Teotochi Albrizzi (Q5454) has a tricky name: her surname is being written "Teotochi Albrizzi", which is her birth name Teotochi, which is Greek and normally written in English as Theotokis, but in this case with the Italian spelling, along with the surname of her 2nd Italian husband Albrizzi. I'm not sure how to set this up in Wikidata such that it will sort properly in Commons. Ghouston (talk) 07:15, 4 March 2019 (UTC)
I suppose you create a special family name item just for her. Ghouston (talk) 07:28, 4 March 2019 (UTC)
This section was archived on a request by: Ghouston (talk) 00:10, 12 March 2019 (UTC)

Reducing people to an identifier with an ORCID identifier

Hoi, I strongly object to the practice where researchers are reduced in their descriptions to a researcher with an ORCID identifier. I fully understand the reason why but it is an awful practice. It is bad enough to only say "researcher" when it is a psychologist, a microbiologist or whatever.

The objective is disambiguation. As automated descriptions are superior anyway, it follows that disambiguation is done best by adding statements that distinguish one person/item from another. Thanks, GerardM (talk) 07:44, 2 March 2019 (UTC)

Wikidata is a WIP project, isn't it. I believe these items are going to be better and better. I am currently working on items of young Polish scientists who quite often are only an item with ORCID ID. There probably should be a list of these items (or a Wikidata project) to work on. Kpjas (talk) 08:03, 2 March 2019 (UTC)
195k items with an ORCID iD (P496) statement have three or even fewer statements (which are 42% of all items with an ORCID iD (P496)). There is quite a lot to do, I guess. —MisterSynergy (talk) 08:14, 2 March 2019 (UTC)
@MisterSynergy: The task looks overwhelming but... please compare [6] and Mateusz Adamiak (Q61101679). I am busy on items like this. Kpjas (talk) 08:48, 2 March 2019 (UTC)
I am working hard to bring authors and papers together like I just did for Mateusz Adamiak. I follow this up with work on co-authors that are evident in the Scholia for an author.
This is however beside the point. The point is that descriptions identifying people with a number is not acceptable. Thanks, GerardM (talk) 10:07, 2 March 2019 (UTC)
I don't think these items are of much use. For most cases, the easiest is probably to just ignore them. The query suggested by MisterSynergy can be used to filter them. --- Jura 12:20, 3 March 2019 (UTC)
Many of these items have dozens, some even hundreds of links to scholarly papers. So there is a use for them it will evolve over time. There has been for a month or so adding employment info for scholars. Thanks, GerardM (talk) 13:59, 4 March 2019 (UTC)
I've adjusted dozens of these descriptions to be more natural; however I don't see any problem with them as interim descriptions for people. ArthurPSmith (talk) 14:33, 4 March 2019 (UTC)
So you are perfectly happy for me to ask what people find about this outside of Wikidata? Really? Thanks, GerardM (talk) 14:35, 4 March 2019 (UTC)
A survey would be a great idea, if that's what you're suggesting? ArthurPSmith (talk) 19:39, 4 March 2019 (UTC)
As an "outside" user of Wikidata information, I prefer the description to be a plain, natural-language phrase that can be shown to an end user without provoking bafflement and confusion. Hence, while I sympathize with the problems this is trying to solve, I don't think we should be subverting the description to include identifiers in this way. Cheers, Bovlb (talk) 05:39, 5 March 2019 (UTC)
@Bovlb: Hmm, I'm not sure what you mean by "subverting the description". These are newly created items, so there was no description for them before. What would you suggest as "the description" that should be used to help disambiguate them? ArthurPSmith (talk) 19:08, 5 March 2019 (UTC)
@ArthurPSmith: I used the word "subvert", not because some prior value is being displaced, but because it seems to change the purpose of the description in a way which interferes with the established use case I described above. As to what I would suggest, I have looked at several cases and I agree that coming up with a good description is not easy, especially when all we have is an ORC_ID. The uniqueness constraint ("no two items can have both the same label and the same description") is going to make it harder and harder to generate useful descriptions automatically as Wikidata grows. The current work to import publications is putting pressure on person entities in this regard. We also see it when trying to add descriptions to geo-locations. Cheers Bovlb (talk) 19:27, 5 March 2019 (UTC)
The purpose of the description is to disambiguate the item label; that much is clear from sentence 1 of help:description, so it is a stretch to describe such disambigation as subvertion. The purpose of the description is not to describe the subject of the item; that's what item property statements are for. Expecting or relying on the description to decribe the item subject is a category error, easily made but nontheless wrong. --Tagishsimon (talk) 23:43, 5 March 2019 (UTC)

Let's look at en:Margin of error. It's counted in percents.

Let's look at ru:Предел погрешности. Different names are mentioned, but the title is "предел погрешности". Then see the row "20 см — предел погрешности". It's counted in centimeters, not percents.

The terms are not equal (measured in different units). Please disconnect. 62.220.40.76 22:55, 5 March 2019 (UTC)

Harry Potter is a fictional human

Can anybody help me to revert this edit but I only want to revert what was removed, I don't want to touch anything else. Or should I just manually enter the information again? I want to be effective... cause what if this happens many times, I'll lose so much time on this and I want to save my time. Thank you. Btqfshfst (talk) 17:14, 27 February 2019 (UTC)

@Btqfshfst, Fuzheado: That Harry Potter is a fictional human is already implied by the statement instance of (P31): wizard in the Harry Potter universe (Q15298259) (as wizard in the Harry Potter universe (Q15298259) is a subclass of fictional human (Q15632617)). So there is no need to add additionally instance of (P31): fictional human (Q15632617). I suppose that this was the reason for the removal. If there is no reason to keep this statement nonetheless, I would remove it again. - Valentina.Anitnelav (talk) 19:58, 27 February 2019 (UTC)
Thanks, I don't feel strongly one way or another - just make sure we are consistent. -- Fuzheado (talk) 20:08, 27 February 2019 (UTC)
So are there no non-human wizards in the Harry Potter universe? (I don't know the books well enough to know the answer.) - Jmabel (talk) 02:58, 28 February 2019 (UTC)
@Jmabel: Correct, other species can't be wizards in the series. --Yair rand (talk) 03:09, 28 February 2019 (UTC)
Si if I understand correctly Yair rand (do you have a reference, I easily remember non-human doing magic but not that their called "wizard/witch"), then, we should revert this removal Special:Diff/867421525 and this adding Special:Diff/211825515 (both by Infovarius who strangely hasn't been pinged yet). Cheers, VIGNERON (talk) 08:21, 1 March 2019 (UTC)
So it looks like in the Harry Potter universe non-humans are not allowed to have wands but it looks like half-humans can be wizards? I don't know how people want to model this in relationship to fictional human (Q15632617) vs fictional character (Q95074) *shrug*[7] -- ElanHR (talk) 05:38, 3 March 2019 (UTC)
Hm, I forgot about the case of half-humans. Assuming we don't count half-human as a subclass of human, then each human-wizard item should also have instance of (P31) fictional human (Q15632617). If we do count them as humans, then the additional statement is unnecessary, and wizard in the Harry Potter universe (Q15298259) should have subclass of (P279) fictional human (Q15632617). --Yair rand (talk) 04:48, 4 March 2019 (UTC)
Thank you. I'm happy I was patient enough to wait and not take further erroneous actions Btqfshfst (talk) 20:31, 6 March 2019 (UTC)

Edit action feed (Android app)

Background: Our readers mainly read the wikis on mobile phones; our editing tools are focused on desktop and keyboards. This will be a problem for us: Wikipedia and thus the Wikimedia wikis became a big thing because everyone who read it could add information. If this is not true in the future, we’ll have a harder time getting new editors. The developers are working on a number of different solutions, including, of course, trying to make the kind of typical content creation that we’ve always done easier on mobile. However, we’re also looking into if there are specific tasks that could be specifically well suited for mobile users. And Wikidata is of course not only one of these things, but also important for the future in general.

Users in the Android Wikipedia app will be invited to an edit action feed, where they’ll be fed Wikipedia articles in their chosen language and be asked to add Wikidata descriptions, where these are lacking, or translating existing descriptions. This will only be shown to editors who have made at least five unreverted Wikidata description edits in the app; the translations require fifty unreverted edits. If an edit gets reverted, the the count starts at zero again. This is an anti-vandalism measure: we don’t want to invite people to specifically do this unless they’ve shown basic competency at this kind of editing. You shouldn’t need to worry about an uncontrollable influx of edits since this only affects a subset of the Wikipedia Android app users, but we’ll be monitoring the stats to make sure everything’s going well. All Android app edits can be found with the Android app edit tag.

If you’ve got any comments or questions, the best place to leave or ask them is probably talk page on mediawiki.org. We aim to launch this towards the end of March. /Johan (WMF) (talk) 10:40, 6 March 2019 (UTC)

Suggestion noted. (: /Johan (WMF) (talk) 17:58, 6 March 2019 (UTC)

Linking a person to the index of their personal archive

How should I best model the relationships described on this page? https://www.prm.ox.ac.uk/manuscripts

I can represent that fact that a person has archives in this collection with Darrell A. Posey (Q5224576) -> archives at (P485) -> Pitt Rivers Museum (Q1456119). I'd like to connect the individuals to the index pages of their archives, e.g. Darrell A. Posey (Q5224576) to https://www.prm.ox.ac.uk/posey-papers . I see that we have personal archive (Q27032347) which could be used with described at URL (P973) or official website (P856) but that seems to refer to institutions, and in the present case "archive" practically means a box of papers, or a collection of boxes. Thanks in advance for any suggestions. MartinPoulter (talk) 12:08, 6 March 2019 (UTC)

Would creating a property for "finding aid URL" (or similar) be appropriate here? It could thus be a qualifier on archives at (P485), or a primary property on items about a collection. Otherwise, I'd recommend described at URL (P973) as a qualifier on archives at (P485), though I don't know if the constraints would allow it. Andrew Gray (talk) 12:51, 6 March 2019 (UTC)
described at URL (P973) as a qualifier sounds like a good solution, because then we can distinguish between links to an online digital archive (full work available at URL (P953)) and links to a description or index (described at URL (P973)). MartinPoulter (talk) 14:14, 6 March 2019 (UTC)
It's a bit confusing/misleading, because when editing the items for archives at (P485), described at URL (P973) is one of the suggested qualifiers. However entering the URL (which clearly does describe the archives), gives the message "The property described at URL should not be used in this location (as qualifiers). The only valid location for this property is as main value.". Oh well I think I'll just ignore the non-issue. Animalparty (talk) 05:55, 7 March 2019 (UTC)

Help with complex constraint

I would like to create a constraint on has part(s) (P527) such that a certain qualifier is allowed only if the value of the main statement is a class, not an instance. e.g.:

Marder I (Q156927)has part(s) (P527)turret front armor (Q38554489), with qualifier slope (P4184)33 degree — qualifier is allowed, because turret front armor (Q38554489) is a class.

Memphite necropolis (Q10334749)has part(s) (P527)Pyramid of Unas (Q1478801), with qualifier slope (P4184)56.3 degree — qualifier is not allowed, because Pyramid of Unas (Q1478801) is an instance of a class.

Thank you! Swpb (talk) 16:25, 6 March 2019 (UTC)

@Swpb: ✓ Done, added to the property. (Currently there are only two violations, both because gun shield (Q4096972) is erroneously structured like a non-class.) --Yair rand (talk) 21:34, 6 March 2019 (UTC)

Please help with reviewing property proposals

It would be great to have a bit more activity on property proposals - quite a lot of them are left open for many months, with few people chiming in to give their opinion. Here is how you can help:

  • Vote on open proposals to help them reach a consensus (big thumbs up to David who tirelessly voted on most proposals for the last few years I think);
  • Help mark mature proposals with |status=ready when you see a clear consensus for creation (you can do that for your own proposals too!). At the moment the bulk of this work is done by ArthurPSmith alone - if we have other people doing that (for instance in other timezones), properties will get created more swiftly.
  • Mark stale, inactive proposals with no consensus as |status=not done (or |status=withdrawn if it is your own);
  • Don't forget to ping relevant wikiprojects, that generally helps attract eyeballs.

A good place to look for properties to review is Wikidata:Property_proposal/Overview - this table makes it easy to find recently proposed properties or old inactive ones that probably need closing.

The property proposal process can be a bit daunting when you see piles of old proposals full of unresolved heated debates, or properties that only created many months after being proposed. If the reviewing is more efficient, more newcomers will hopefully be keen to submit proposals. This is a space where key decisions about Wikidata's structure are made, so it's really worth getting involved. This is also rewarding work - you get to think about interesting data modelling problems, it is quite creative! − Pintoch (talk) 21:54, 6 March 2019 (UTC)

@Pintoch: I had no idea I could update the status myself. Happy to help. From observation, tt seems that a proposal should be open for at least 7 days before being marked "ready" - is that right? - PKM (talk) 22:32, 6 March 2019 (UTC)
@PKM: See Wikidata:Property creators for current policies, including the "no less than one week" rule. ArthurPSmith (talk) 22:52, 6 March 2019 (UTC)
(Note: I recently-ish proposed on the talk page to extend that time to a bit longer than a week.) --Yair rand (talk) 22:55, 6 March 2019 (UTC)

Subclasses and parts

(@Verdy p:.)

See Talk:Q58416391. There's a dispute over whether parts and subclasses are the same thing, unless I'm misunderstanding the argument. Anyone want to weigh in? --Yair rand (talk) 22:53, 6 March 2019 (UTC)

Litre per year

Hello. In Nesjavellir Power Station (Q693330), how do I add product or material produced or service provided (P1056) as "litre per year" or at least "litre per day". I think I'm close, but can't seem to figure out how to add the period. Is a new property required here? Rehman 10:50, 7 March 2019 (UTC)

@Rehman: You need an item for the unit - check whether it already exists, but if not you can create "litre per day" as an item and use that as the unit for the quantity. ArthurPSmith (talk) 16:11, 7 March 2019 (UTC)
Thanks, ArthurPSmith. I created litre per day (Q61992237), litre per month (Q61992243), and litre per year (Q61992246), by basing on the similar existing litre per kilogram (Q57175557). The items will be used for entities in the geothermal power and cogeneration industries, among other areas. Rehman 16:39, 7 March 2019 (UTC)
They look good, thanks. ArthurPSmith (talk) 16:44, 7 March 2019 (UTC)

Alternative text for images

Hello. Just like how we could state media legend (P2096) for image (P18), do we have a way to set alternative text for images? Rehman 11:30, 7 March 2019 (UTC)

We do not - see the discussion around a previous proposal for this here: Wikidata:Property proposal/text alt. ArthurPSmith (talk) 16:12, 7 March 2019 (UTC)
Well that's a pity. Your last comment there made a lot of sense. Too bad it wasn't passed. Rehman 16:24, 7 March 2019 (UTC)
Image metadata is about to launch on Commons, another attempt can be made then. Matěj Suchánek (talk) 17:11, 7 March 2019 (UTC)
Not really. None of the developers seem to understand the difference between a caption and alt text, even when it's explained to them. --RexxS (talk) 22:54, 7 March 2019 (UTC)

Typography of labels

Hi,

Ludo29 raised an interresting question on the French Project chat (Topic:Uvhpolh1k8ylvkjt) : how to indicate that a label in one langage is foreign to this langage? (and consequently that when reused, it should often be in italic). The item concerned here is Teachta Dála (Q654291) but it applies to many other items.

The first idea was to put wiki syntaxe directly inside the label. It kind of works for Wikimedia projects but could make a mess for re-use outside of Wikimedia projects so I think it is a bad good idea. Maybe it can be solved with a specific property or something else (Lexemes?) but I'm not sure how.

Does anybody has an idea or a solution for this?

Cheers, VIGNERON (talk) 13:58, 7 March 2019 (UTC)

Yes. This is an important question. If a word is usually displayed, in a given language, in italic, and if we decide to maintain our labels here wikicode-free, then we need some place to store the type of display that we are expecting to see whenever that word is used. It can be stored on Wikipedia but it seems to me that even if this is monolingual stuff, it should be here. Unfortunately, we can't use statements that would use items such as italic (Q344098) as values, for there are names or titles that can require both italic for one part and nothing at all for the rest. The value should thus mimic some kind of wikicode. Thierry Caro (talk) 14:16, 7 March 2019 (UTC)
It's an intractable problem for labels. In French or Spanish, you see Q344098's label as "Teachta Dála" which could be rendered (for example on enwiki) as something like "{{lang|ie|Teachta Dála}}". However in English we see the label as "Deputy to the Dáil", where the only foreign word is "Dáil"; so it would have to be rendered as something like "Deputy to the {{lang|ie|Dála}}". In Welsh, we see the label "Dirprwy y Dáil", so we would render it as "Dirprwy y {{lang|ie|Dála}}", and so on. Labels are free text and may be a mixture of local and foreign languages, so there's no way of demarking which parts of a label are to be rendered as foreign. The best you could do would be to create a new property of datatype monolingual text that allowed some sort of markup to be included that indicated the foreign part, for example, <Teachta Dála> (fr); Deputy to the <Dáil> (en); etc. (with a qualifier having the value "ie"). That sort of duplication of labels just for use on other Wikiprojects is something we probably ought to reach some consensus on. --RexxS (talk) 23:22, 7 March 2019 (UTC)

"Field of work" and "Interested in"

General question: how do you distinguish field of work (P101) and interested in (P2650)? For organizations, writers, and historians, I've been using "interested in" (1) for very specific topics (field of work = history of costume; interested in = Ancient Greek clothing) and (2) for hobbies/interests outside of the subject's professional life. But the property proposal for "interested in" says it should be used only for the most general concepts ... which is how I use "field of work". How do you use these properties? - PKM (talk) 20:25, 4 March 2019 (UTC)

Your logic makes sense to me. interested in (P2650) seems woefully vague, arbitrary, and redundant. What's the basis for inclusion? if Angela Merkel (Q567) said in an interview she was interested in hiking or stamp collecting, should that sort of trivial detritus flood Wikidata? How about interested in Germany? Alternately, it stands to reason, and is likely verifiable that a lepidopterist would be interested in Lepidoptera, lepidopterology, entomology, biology, and maybe moths or Actias luna (Q135289), and also have the field of work (P101) lepidopterology, entomology, biology, taxonomy, etc. None of this matters, add whatever you want. -Animalparty (talk) 05:05, 9 March 2019 (UTC)

Questions about correlating Wikipedia titles and Wikidata IDs

[I'm new to this chat page. If there's a better place to ask this sort of question, please let me know.]

I believe one of the first uses of Wikidata on the Wikipedias was to properly systematize interwiki language links. I always assumed this was done by having a template somewhere in each Wikipedia article containing its Wikidata ID, and then machinery somewhere used that Wikidata ID to look up the names of the articles in other language Wikipedias on the same topic. But that's evidently not the way it's done: I don't see Wikidata IDs in Wikipedia articles anywhere. (And indeed they'd be a nuisance to maintain, and subject to vandalism.)

So I guess that when displaying interwiki language links, a query is first done to discover the Wikidata ID corresponding to the original article's name. Am I correct?

Anyway, that's by way of background. I've been wanting to look up Wikidata IDs corresponding to Wikipedia article names myself. I finally constructed this SPARQL query:

SELECT DISTINCT ?id WHERE {
    ?article schema:about ?id; schema:inLanguage "en"; schema:name "Boston"@en .
}

And this seems to work, returning "Q100" for "Boston".

But is this the right way to do it, or is there a better way? (I'm particularly interested in avoiding anything that's needlessly inefficient. If indeed something like this has to be done every time a Wikipedia page is displayed, there's got to be a nice, efficient, indexed, optimized way to do it, and I'd like to make sure I'm accessing that way.)

Finally, I'm already pretty sure my query is not quite the right way to do it. For example, it returns two IDs for "Cambridge", both Q350 which is correct, and Q857732 which seems to correspond to the Wikipedia disambiguation page for Cambridge. Which makes a certain amount of sense, but how did it happen? The name of the Wikipedia disambiguation page for Cambridge is not "Cambridge"! (Other examples which yield multiple IDs include "Spain", "Jordan", and "Ensenada".) Scs (talk) 15:42, 8 March 2019 (UTC)

@Scs: The name of the Wikipedia disambiguation page for Cambridge is not "Cambridge"! No, but the name of the English Wikinews and Wikivoyage disambiguation pages is, as you can see by selecting the ?article as well:
SELECT ?article ?id WHERE {
  ?article schema:about ?id; schema:inLanguage "en"; schema:name "Cambridge"@en .
}
Try it!
Instead, if you want to use the query service to discover the item corresponding to an English Wikipedia page, explicitly request that wiki –
SELECT ?id WHERE {
  ?article schema:about ?id;
           schema:isPartOf <https://en.wikipedia.org/>;
           schema:name "Cambridge"@en .
}
Try it!
– or directly encode the title into the URL:
SELECT ?id WHERE {
  <https://en.wikipedia.org/wiki/Cambridge> schema:about ?id.
}
Try it!
Alternatively, you can skip the query service completely and follow the Special:ItemByTitle/enwiki/Cambridge redirect. --TweetsFactsAndQueries (talk) 17:46, 8 March 2019 (UTC)
Got it! Thank you for all of those.
Related question: is there a good way to query across all languages at once? I tried variations on
SELECT DISTINCT ?lang ?id WHERE {
    ?article schema:about ?id; schema:inLanguage ?lang; schema:name "Boston"@?lang .
}
but had no success. (@ doesn't like ?, unsurprisingly.) Scs (talk) 18:02, 8 March 2019 (UTC)
You can also use the Wikipedia API, example, see API:Pageprops. Bovlb (talk) 22:13, 8 March 2019 (UTC)

Other (multilingual) wikis as authority control

Can we use other wikis (such as Wikia wikis, OpenStreetMap wiki, etc.) as authority control? If so, how can we manage the multilingualism of some wikis? Should we:

  1. add one value for each language version of an article or
  2. add one property for every language of the wiki.

The first approach requires a lot fewer properties, but it creates some problems where wikis have a different subdomain for every language version (Wikipedia-style). The latter approach solves this problem but it treats two language version of the same wiki as completely different websites.--Malore (talk) 02:00, 9 March 2019 (UTC)

Spam or hoax items

Suppose a small wiki admin created spam/hoax/self-promotion articles on different wikipedia. A wikidata item is created by linking them. It is easy to weed them out on large wikis, but s/he manipulates and blocks deletion requests on the small wiki. Is wikidata bound to include this unencyclopaedic item, just because it contains at least one valid sitelink? What's the best approach to deal with this sort of admin misconduct on small wikis?--Roy17 (talk) 07:14, 8 March 2019 (UTC)

Wikidata isn't an encyclopaedia, so it's irrelevant whether or not an item is "unencyclopaedic". Our scope is wider. Storing data is a quite different task then storing articles to explain concepts.
Apart from that we have the https://meta.wikimedia.org/wiki/Small_Wiki_Monitoring_Team to fight misconduct that happens on small Wiki's and when an admin of a small Wiki includes hoax articles it's the job of the Small Wiki Monitoring Team to deal with the problem. ChristianKl09:28, 8 March 2019 (UTC)
The Small Wiki Monitoring Team appears to be aimed at Wiki's with insufficient admin presence. It looks to me that there are real problems with small wiki admins, not limited to hoax items. There is not all that much that can be done from here, but obvious hoax items can be marked as "instance of: hoax", hoping that it will be dealt with in time. - Brya (talk) 07:29, 9 March 2019 (UTC)

How to ask for the president of some country using wqs?

Im new to wikidata query service, also im experimenting with wdq client and i'm struggling to ask for the president (p6 or p35 ?) of Argentina q414. My query was: #added before 2016-10

  1. Demonstrates "no value" handling

SELECT ?country ?president WHERE { ?country wdt:P35 wd:414 . #find humans SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" } }

--167.57.102.141 01:40, 9 March 2019 (UTC)

Do wd:Q414 wdt:P35 ?president. Matěj Suchánek (talk) 10:11, 9 March 2019 (UTC)
ok, how can i do the same with wdq in linux bash? is it there a better client for bash linux? sorry for my newbieness.--167.56.47.80 01:12, 10 March 2019 (UTC)

commons category

in item like Q25966820 when you have to set the commons category in P373 and when in the "other sites" field? thanks--Pierpao (talk) 08:13, 9 March 2019 (UTC)

For category items, the sitelink is useful, but I don't think you gain anything adding P373. Ghouston (talk) 10:27, 9 March 2019 (UTC)
There should always be both because the sitelinke could also be a a gallery page. So it is better to search for the categories by using Commons category (P373) in a query. --GPSLeo (talk) 11:05, 9 March 2019 (UTC)
This is true for main items, where P373 is also very useful for finding Commons categories that are sitelinked to category items, but galleries shouldn't be sitelinked to category items. Ghouston (talk) 04:08, 10 March 2019 (UTC)

Solar irradiance

Hello. What is the best way to state solar irradiance in SI-units (i.e. kWh/m2/year)? I see we have solar irradiance (Q7556707) and solar radiation (Q17996169) as well (very likely dupes), but do we need a new property here? Rehman 17:04, 9 March 2019 (UTC)

I think we would need a new property for this. But where do you want to ad this property? I think we do not even have properties for annual precipitation or mean annual ground temperature. --GPSLeo (talk) 19:19, 9 March 2019 (UTC)
Thanks GPSLeo, yes I thought so too. I will go ahead and propose it. This property will be used to indicate the solar resource at a solar power station site. Rehman 05:46, 10 March 2019 (UTC)

Journal de Bruxelles

How do you connect the specific editions of 'Journal de Bruxelles' Q45747062, Q46834135 and Q62015763 with the general 'Journal de Bruxelles' item Q25382985. And how can I place a specific dated newsitem such as De_Constantinople,_le_24_Brumaire_(15_novembre_1799) in Wikidata. These newsitems where printed in several newspapers as news dispatches where send around. (no telefone or telegraph). There is a date and place.Smiley.toerist (talk) 23:25, 9 March 2019 (UTC)

For the first question, I think with part of the series (P179), as in Journal de Bruxelles (1790-1800)/76-1799 (Q45747062) part of the series (P179) Journal de Bruxelles (1841) (Q25382985). For the second question, I suppose you could make an item in Wikidata for the dispatch and pick one of the publications that it appeared in. Perhaps the earliest dated, if they differ. Ghouston (talk) 06:21, 10 March 2019 (UTC)

Holocaust victim

I am trying to add the people from the German stumbling stone project to Wikidata, we have images of the markers but not entries for the people. Should "Holocaust victim" be an event as in Anne Frank (Q4583) where it gives a constraint error or should it be an "instance of" as in Käthe Henriette Salomon (Q58363991) with no constraint error? They seem to be a mix, mostly like Anne Frank, and probably added before the constraint error messages were developed. --RAN (talk) 17:58, 5 March 2019 (UTC)

while "instance of" sounds like it makes sense, I don't think we put people in classes like that anywhere else. ArthurPSmith (talk) 18:24, 5 March 2019 (UTC)
Personally, I think neither "statelessness" or "holocaust victim" ought to be listed as "significant events" to Anne Frank. For one, it should really be loss of citizenship (Q17144585), not "statelessness". "Significant event", as I understand it, is meant to cover events not otherwise included in other property. Her being a holocaust victim is not a significant event (strictly speaking, it's not even her claim to fame!), it's in my opinion better treated as part of her manner of death (P1196), and that has a separate property. Circeus (talk) 18:33, 5 March 2019 (UTC)

Weird, I have no idea who thought it was OK to say someone was "instance of" their manner of death. This is definitely wrong. The usage of significant event on a person however is fine, but the object of the statement can be either a slow period or sudden event - both are acceptable. I use "nazi looting" for artworks confiscated as part of a policy wiith uncertain date, while "destruction" is often due to fire in a house or museum that has a specific date and place. So the object of the significant event statement in this case should be something general, like "holocaust" and then qith qualifiers "interment", "disease" or "murder", depending on the outcome. For people moved from one camp to another they can have more than one significant event I suppose. Jane023 (talk) 12:11, 10 March 2019 (UTC)

Ranking

Help:Ranking. Maybe I have missunderstood some things in wikidata.

The deprecated rank is used for statements that are known to include errors (i.e. data produced by flawed measurement processes, inaccurate statements) or that represent outdated knowledge (i.e. information that was never correct, but was at some point thought to be). It is often useful to indicate the reason for a deprecation with a reason for deprecation (P2241) qualifier. This does not apply to correct historical information, such as previous values of a statement, as long as they represent accurate information for the indicated time period. Such statements should instead be annotated with the apropriate ημερομηνία έναρξης (P580)/ημερομηνία τερματισμού (P582) qualifiers.

If an organization have a website we use official website (P856). But if this website no longer exist and the organization have not a new one, then what must be the ranking of the old website? We can't remove the old one since P856 description says:

URL of the official homepage of an item (current or former) [if the homepage changes, add an additional statement with preferred rank. Do not remove the former URL]
  • I can't use deprecated rank. The old website was not error.
  • I can't use preffered rank. There is not a new website.
  • Normal rank is considered neutral. But, the information is sure that is not correct. We can't say that is believed to be correct.
  • If the rank is normal rank, since there is no preferred rank, the infoboxes will show the old website.

Xaris333 (talk) 22:07, 9 March 2019 (UTC)

@Xaris333: in this kind of case, you can add an empty no value and put the preferred rank on it. Cheers, VIGNERON (talk) 23:08, 9 March 2019 (UTC)
@VIGNERON: I did that but now I had single-value constraint (Q19474404). Q4700714#P856 Xaris333 (talk) 10:58, 10 March 2019 (UTC)
  • You might want to add the "end date" qualifier. If the infobox doesn't want to support it, the former website can be displayed. --- Jura 10:11, 10 March 2019 (UTC)
@Jura1: I don't know when is the end date and I can't find it. Xaris333 (talk) 10:58, 10 March 2019 (UTC)
Then use "somevalue" as value for "end date". --- Jura 11:01, 10 March 2019 (UTC)
OK, thanks. The infobox is showing the url, I quess we have to do a change in the wikipedia template. Xaris333 (talk) 11:05, 10 March 2019 (UTC)
@Xaris333: you don't know the end date but you do know that there is an endate, so you can use some value (which also solves the constraint violation ). And even if you don't know the precise end date, maybe we can use an imprecise value, like 21st century or 2010s. Cdlt, VIGNERON (talk) 11:06, 10 March 2019 (UTC)
PS: with the Wayback Machine, I found that the end date is '2018'.

Updation on Wikidata for sdwiki namespaces

Hi, We have localised all the namespaces on Sindhi Wikipedia, after the localisation done via Phabricator, the Wikilinks to other Wikipedia's pages aren't showing on the Sindhi Wikipedia, So Here I request to perform this function on large scale to link Namespaces pages of Sindhi Wikipedia with Wikidata items, so that they can be wikilinked with other wikis similar pages. Namespace name in English => Localised name in Sindhi

   NS_WIKIPEDIA           => 'وڪيپيڊيا',
   NS_WIKIPEDIA_TALK    => 'وڪيپيڊيا_بحث',
   NS_PORTAL           => 'باب',
   NS_PORTAL_TALK    => 'باب_بحث',
   NS_MEDIA            => 'ذريعات',
   NS_SPECIAL          => 'خاص',
   NS_TALK             => 'بحث',
   NS_USER             => 'واپرائيندڙ',
   NS_USER_TALK        => 'واپرائيندڙ_بحث',
   NS_PROJECT_TALK     => '$1_بحث',
   NS_FILE             => 'فائل',
   NS_FILE_TALK        => 'فائل_بحث',
   NS_MEDIAWIKI        => 'ذريعات_وڪي',
   NS_MEDIAWIKI_TALK   => 'ذريعات_وڪي_بحث',
   NS_TEMPLATE         => 'سانچو',
   NS_TEMPLATE_TALK    => 'سانچو_بحث',
   NS_HELP             => 'مدد',
   NS_HELP_TALK        => 'مدد_بحث',
   NS_CATEGORY         => 'زمرو',
   NS_CATEGORY_TALK    => 'زمرو_بحث',
   NS_MODULE    => 'ماڊيول',
   NS_MODULE_TALK    => 'ماڊيول بحث',
   NS_GADGET    => 'گيجيٽ',
   NS_GADGET_TALK    => 'گيجيٽ بحث',
   NS_GADGET_DEFINITION    => 'گيجيٽ وصف',
   NS_GADGET_DEFINITION_TALK  => 'گيجيٽ وصف بحث,

Source:https://phabricator.wikimedia.org/T186943 JogiAsad (talk) 11:10, 10 March 2019 (UTC)

Example SEE THIS JogiAsad (talk) 11:16, 10 March 2019 (UTC)
Done BOT REQUESTED HERE JogiAsad (talk) 11:21, 10 March 2019 (UTC)

First French republic

I added to the 'replacement property' (P1365). However these are under Identificationcodes chapter, while it should be added to the Declaration chapter by the county of Flandres. There are other historic states wich need to be added.Smiley.toerist (talk) 14:07, 10 March 2019 (UTC)

I found the solution: delete and add to the correct place.Smiley.toerist (talk) 14:18, 10 March 2019 (UTC)
Not sure to understand what was your problem (when you add an information, it's automatically in the right chapter, just refresh the page to see them at the right place) but glad you found a solution. Also, thanks for adding these information but don't forget to add the reverse information, if you add French First Republic (Q58296)replaces (P1365)Comtat Venaissin (Q1122980), you should also add Comtat Venaissin (Q1122980)replaced by (P1366)French First Republic (Q58296) . Cheers, VIGNERON (talk) 16:50, 10 March 2019 (UTC)

Difference between Commons category (P373) and linking commons category in "other sites"

What is the difference between Commons category (P373) and linking commons category in "other sites"? For example, the wikidata item Q3519973 is about the wikipedia article en:Comptroller and Auditor General of India and commons category commons:Category:Comptroller and Auditor General of India. Now, if I link the commons category as item Property:P373, it appears in the left side panel of wikipedia article but not on commons category (says "NO WIKIDATA ID FOUND!" when I add {{Wikidata infobox}}); whereas when I link the commons category in "other sites" section of wikidata item, it doesn't appear on wikipedia article left panel but show on commons category. So how are these two ways of linking commons category to wikipedia article different from each other, and which one is better? Thanks —Sarvatra (talk, contribs) 05:07, 11 March 2019 (UTC)

You need to link the Commons category in "other sites" (sitelink) to avoid the "NO WIKIDATA ID FOUND!" problem. The P373 statement is sometimes by software to find Commons categories, especially when the Commons category is linked to a different item (a category item vs a main item). There's a bot that will add it based on the sitelink. Ghouston (talk) 05:49, 11 March 2019 (UTC)
Noted. Thanks. —Sarvatra (talk, contribs) 06:27, 11 March 2019 (UTC)

Is it possible to track articled nominated for deletion on Wikipedia using Wikidata?

I know that a few WikiProjects use Wikidata to track articles to be created using User:ListeriaBot. I'm wondering if it is possible to track articles for deletion as well. Do I need to create/propose a new property? Is it outside the scope of Wikidata? Thanks! Tetizeraz (talk) 11:03, 11 March 2019 (UTC)

You could propose a new property for this; I'm not sure what would be the best way to model it though. Perhaps an item-valued property "proposed for deletion" with value the item for the wikimedia site where the deletion is proposed? ArthurPSmith (talk) 13:09, 11 March 2019 (UTC)
@Tetizeraz: In SPARQL you can use the MediaWiki api so you can ask the MediaWiki API for the articles nominated for deletion (based on inclusion of a category or template usage) and combine that with Wikidata.
For example on the Dutch Wikipedia we use nl:Template:Artikelweg. This query will give the articles nominate for deletion on the Dutch Wikipedia. Multichill (talk) 16:42, 11 March 2019 (UTC)

Duplicate from Commons

There exists Alphons Huber (Q87180), having a Commons category statement, and the duplicate Alphons Huber (Q21082996), having the associated commons gallery statement. My question is: Is it possible to find this kind of duplicates, where a commons category is in one item, but the subpage gallery in a different item? 129.13.72.197 11:27, 11 March 2019 (UTC)

Good question.
As a start, here is a query that looks to find items with a Commons gallery (P935) but no Commons category (P373). It also looks to see if there is a topic's main category (P910) and whether that has a Commons category (P373). Over 12,000 hits, which is a lot more than I was expecting.
SELECT ?item ?itemLabel (URI(CONCAT('https://commons.wikimedia.org/wiki/', ?gallery)) AS ?gallery_url) ?cat ?catLabel ?ccat WHERE {
   ?item wdt:P935 ?gallery .
   MINUS {?item wdt:P373 ?commonscat} .
   OPTIONAL {
       ?item wdt:P910 ?cat .
       OPTIONAL {
          ?cat wdt:P373 ?ccat .
       }
   }
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!
The tricky bit is to go through those gallery pages, see what commons categories they are in, and to try to identify whether one of those commons categories corresponds to the main topic of the gallery. Then one can look to see whether that commons category has its own sitelinked item, and whether that is a category-type item, or whether it is an article-type item that ought to be merged with the one that currently has the gallery sitelink, with a new item created to be sitelinked to the category.
@Mike Peel: (and anybody else): Any thoughts on any steps that could make such a process more automated, or at least more machine-supported? Jheald (talk) 11:49, 11 March 2019 (UTC)

Wikidata weekly summary #355

How to correct an automatically generated item description

Q18921708 was incorrectly marked as an "American basketball player" when the item was created. However, the subject is Senagalese, which I have corrected.[8] However, a bot added this old wrong description at various times.[9][10] Is there any way to get the bot to update them? Pinging User:Emijrp. Magog the Ogre (talk) 18:34, 9 March 2019 (UTC)

You have to blank all the incorrect descriptions, and the bot will add the new descriptions (for Senagalese basketball player) in the next run. Emijrp (talk) 19:14, 9 March 2019 (UTC)
But why do you say he is a Senegalese and not an American basketball player? As seen in the properties he was born in the Senegal but visited an university in Florida and plays for an US-Team, so I think he was just born in the Senegal and lives in the US. And he also has both citizenships. May just contain both in the description like "basketball player born in Dakar playing for an US basketball team" --GPSLeo (talk) 19:30, 9 March 2019 (UTC)
I have seen constructs like “American basketball player from Senegal” and “Senegalese-American basketball player”. I like the second form since he is known to have dual-citizenship. - PKM (talk) 02:42, 10 March 2019 (UTC)
It would be good to add a reference for the US citizenship claim, Wikipedia doesn't know anything about it. Ghouston (talk) 04:35, 10 March 2019 (UTC)
Maybe the error is there. If it's correct, the description doesn't seem incorrect. --- Jura 10:02, 10 March 2019 (UTC)
The claim in the decription that he is a US citizen was first added by PLbot on 2015-02-10T23:46:17. There's no apparent source for it. User:GPSLeo / User:PKM, why do you think he has US citizenship? Ghouston (talk) 01:07, 11 March 2019 (UTC)
I was following User:GPSLeo. Assuming that data is correct, this is how I’d record it. - PKM (talk) 01:58, 11 March 2019 (UTC)
I just looked at the statements but I see that RealGM (Q7300810) says something different. The English Wikipedia says nothing about his citizenships. --GPSLeo (talk) 11:07, 11 March 2019 (UTC)
Independent of this if someone lives in the US since he is 16 years old I would call him US-american if he has the citizenship dose not matter for me. --GPSLeo (talk) 11:10, 11 March 2019 (UTC)
I'd just go by citizenship in such things. To do otherwise makes the concept arbitrary, which makes it possible to call people "US-American" when they aren't citizens, but also to call people "not really US-American" even when they do have citizenship. Ghouston (talk) 00:28, 12 March 2019 (UTC)

Do project-space essays that exist on only one project meet WD:N? GMGtalk 22:26, 11 March 2019 (UTC)

"at least one valid sitelink" to any page outside certain namespaces. Looks like it qualifies. (Hope you don't mind, I've altered the section title to hopefully avoid drama from bringing up the essay's viewpoint.) --Yair rand (talk) 05:35, 12 March 2019 (UTC)

Postilion (Q43376794) and (Q596033)

Please would someone merge these two. I am not a computer programmer and while the merge instructions appear to be excellent my nerve fails me. Thanks in advance, Eddaido (talk) 08:10, 12 March 2019 (UTC)

Done, I just pressed the merge button and entered the number ... what could possibly go wrong? Ghouston (talk) 09:07, 12 March 2019 (UTC)
Listen! I can buy nice big strong plants and put them in the garden —they die soon after. If I'd done what you just did I might have screwed up the entire Wikidata project. Will try to be braver next time. Many thanks Ghouston, Eddaido (talk) 09:40, 12 March 2019 (UTC)
@Eddaido: I'm not really a computer programmer and I killed a lot of plants (including century old trees who where perfectly fine until I take "care" of them) but merging is really quite easy and self-explicit, look at Help:Merge#Gadget for explanations. Cheers, VIGNERON (talk) 10:23, 12 March 2019 (UTC)

Q62030223

The item Q62030223 was created as probably a test page. It contains a link to a Wikinews article, but it also has a few letters and some random nonsensical word. It should be deleted. George Ho (talk) 10:29, 12 March 2019 (UTC)

@George Ho: It looks to me like this was a botched/abandoned attempt at creating a QItem for a wikinews article. I tidied it up a bit, does that help? Moebeus (talk) 12:04, 12 March 2019 (UTC)
For now, yeah. --George Ho (talk) 12:24, 12 March 2019 (UTC)

Duplicate surname Liu

There are two items for the surname Liu at Liu (Q804970) and Liu (Q39000092), one supposedly in Chinese and the other in Latin script. They both have quite a few items using them as family name (P734). Q804970 seems to be a bit more popular and has sitelinks to Wikipedias, while Q39000092 is linked to a Commons category. But what are the criteria by which one item or the other is used for a particular person? If I see a pattern, it's that many of the items using Q39000092 are researchers. Ghouston (talk) 10:27, 6 March 2019 (UTC)

@Harmonia Amanda: regarding surnames and @Sic19: regarding researchers. Mahir256 (talk) 17:23, 6 March 2019 (UTC)
I chose to use latin transliterations for Chinese surnames, if there is an existing item, because I often see multiple items for surnames which appear to be family name varients in the original language and I do not know which would be appropriate. For example, here are some of the items for the family name Li: Li (Q686223), Li (Q770891), Li (Q13588410), Li (Q15283218), Li (Q3447118), Li (Q10910874), Li (Q11983876), Li (Q17008106). The reason the Liu (Q39000092) is used on researchers is only because I am trying to improve the sparce items that have been created from ORCIDs. Simon Cobb (User:Sic19 ; talk page) 18:08, 6 March 2019 (UTC)
So if you are taking data from a source in Latin script, you'd use a matching name with Latin script, but taking data from a Chinese source you'd use a name with Chinese characters. This does result in splitting people somewhat arbitrarily between different items depending on where their data was found. But then which item should be used when you have both a Chinese and Latin version of the name, e.g., if they have articles on two Wikipedias, or if there are web pages with different scripts? Ghouston (talk) 22:47, 6 March 2019 (UTC)
The Latin-script name should be used for people with a Latin-script native language. There are quite a few American, French, German, etc. of Chinese descent who genuinely have "Liu" now as a family name (thinking of Alysa Liu (Q55356854) for example). Chinese researchers should definitely not have a Latin-script names, because it's not their names. If we don't know their family names, we don't add it. We certainly don't add one we know to be false! --Harmonia Amanda (talk) 10:50, 7 March 2019 (UTC) Edit: to be more clear Liu (Q39000092) is not an item about "Liu and other family names transliterated as 'Liu'", it's an item for "Liu, the Latin-script name". It should not be used for people whose names we know are transliterated as 'Liu' but is not 'Liu'. Liu (Q804970) is about the family name 刘, which is transliterated as 'Liu' (among other transliterations). --Harmonia Amanda (talk) 11:02, 7 March 2019 (UTC)
So what should we do when someone with a non-Latin script name has used a transliteration of their name and this is the data we are working with? And how are we suppose to establish whether someone is using a transliteration or whether or not the name we are working with is their genuine or native language name? All of the data I have used to add surnames is in Latin script and a lot of the data is created by the persons represented by the items I am editing thus I used the Latin script items Liu (Q39000092). For example, Yongsheng Liu (Q42834021) has ORCID iD (P496) linking to a profile for Yongsheng Liu, who is based in China and the source of the data in this ORCID. Even when the language setting in ORCID is changed the name remains Yongsheng Liu. If Chinese researchers definately should not have Latin-script names please can you tell me what Yongsheng's family name is? Also, I notice that Liu (Q39000092) has said to be the same as (P460) statements linking to Liu (Q804970) and Liu (Q13391498) - is this correct or not? Simon Cobb (User:Sic19 ; talk page) 17:59, 7 March 2019 (UTC)
There are also bilingual people who will use both a Latin and non-Latin version of their name, depending on which language they are using at the time. Besides that, we don't always know what a person's native language is. Ghouston (talk) 00:14, 8 March 2019 (UTC)
Would we potentially need multiple family name (P734) statements for the surnames a person uses in different languages? The constraints on family name (P734) don't currently include a language qualifier, and it may make it hard for users of the data (templates etc.) Ghouston (talk) 00:24, 8 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── My two cents:

  • If the database doesn't include information about the family name in the native language, I think we should keep the Latin transliteration because there can be several different family names that have the same transliterations. As a native speaker, I'm able to find out that Yongsheng Liu (Q42834021)'s family name is indeed Liu (Q804970) instead of Liu (Q13391498), but we cannot make this assumption by default. If we do find the family name in the native language, we can then switch it from the Latin version to the non-Latin version.
  • For the cases like Alysa Liu (Q55356854), the situation is more complicated. Although she was born and grew up in US and should have the Latin version Liu (Q39000092) as her family name, one can definitely argue that Liu (Q804970) is also her family name since it is her father's family name. We may then ask is Liu (Q39000092) also her father's family name? (it's just an example, her father doesn't have an item yet) Although her father was born and grew up in China, he has been lived in US for 30 years and use his western name Arthur Liu in his daily life. I'm not sure what's the best way to deal with these cases.
  • There are also different transliteration systems, for example Liu (Q804970) can be transliterated as Liu, Lau, Lieu, etc. Andy Lau (Q16766)'s family name is Liu (Q804970), but should we also add Lau (Q16871901)? How about Ted Lieu (Q7693450), whose Chinese family name is also Liu (Q804970)?
  • As a side note, I notice that different Chinese family names that have the same transliteration are linked by said to be the same as (P460) or different from (P1889) or both. It doesn't make sense to me that said to be the same as (P460) is used here since they are totally different names that just happen to have the same transliteration. (Actually if we keep the tone marks in the transliterations, they might be different, for example Liu (Q804970) is Liú and Liu (Q13391498) is Liǔ.) I cannot see how the description of said to be the same as (P460) (this item is said to be the same as that item, but the statement is disputed) can be applied here. Using said to be the same as (P460) for linking the non-Latin version and the Latin version could be okay but I'm not sure.--Stevenliuyi (talk) 04:12, 9 March 2019 (UTC)
I seems to me that people who have a non-Latin script name, and also either publish in English (or other Latin script language) or live in a Latin-script country, basically have two names. In the case of living in another country, you'd probably have to supply some kind of translation for certain identity documents so you'd have an official transliteration. When publishing, I'd guess most people would tend to use the same transliteration consistently instead of choosing a different one for each publication. Ghouston (talk) 10:23, 9 March 2019 (UTC)
  • You can add several values in P734. Ideally, I'd start with one matching the native language label, but others are possible. --- Jura 10:16, 10 March 2019 (UTC)
  • Not all surname items are currently as developed as they should be. Please add "native label" and "script" properties to the item once determined.--- Jura 11:00, 10 March 2019 (UTC)
I suppose creating multiple given name or surname statements for different versions is the best that can be done when using this Wikidata system, and I can't think of a good alternative system. The difficulty will probably be that a lot of users of Wikidata won't understand these complexities. I created an item Hakeem (Q62029375) for a name of Arabic origin, which has an alternative Hakim (Q19965937), but no Arabic version. I'm not going to create one, since I don't know Arabic script and it's tricky (with letters taking different forms depending on their position in a word). Most likely, people will just link to the Latin versions. Ghouston (talk) 20:40, 12 March 2019 (UTC)

Diff of off external identifiers and external data

I ma looking for a tool to get external data that is not already added to Wikidata. I have the list of already created items with the qualifier and the list of the external source. What is the best way to get the IDs from the external source do not have a Wikidata item? May there is a simple command line tool that deletes all numbers that are in two columns so that I only get the ones they are only in one column. --GPSLeo (talk) 20:50, 12 March 2019 (UTC)

One can use the query service for that task, as in this example. You can provide quite a lot of identifiers—5000 should not be a problem—and it lists the ones which are not yet in use in any item in the results set. —MisterSynergy (talk) 21:05, 12 March 2019 (UTC)
Thanks. I tried it with 17.000 identifiers and even this worked. --GPSLeo (talk) 21:26, 12 March 2019 (UTC)

Dorvitsa

Hi there are many names a remote village in Greece went by throught the years. While I tried to add them all, a user always removes them. These names are not used anymore but there are found in historic sources like goverment gazettes which refered to this village with those names. The village is Dorvitsa (Dorvitsa (Q5299063)). Please take a look at the wikidata's item history and inform me who is wrong. Thank you.(TakisA1 (talk) 23:42, 9 March 2019 (UTC)) t @Chalk19: Xaris333 (talk) 10:54, 10 March 2019 (UTC)

@Chalk19: the summary is strange, for me this is exactly what aliases are here for (that's my interpretation of Help:Aliases anyway). Cheers, VIGNERON (talk) 11:12, 10 March 2019 (UTC)
@VIGNERON: "Obscure" or lost-in-time-and-space variations of place names like this, not in use for centuries, or perhaps with a very limited usage (like in a family circle, if one specific variation appeares just once in a dowry contract of 1774) does not mean "also known as". Variations, say, found in manuscripts layng in dust on the shelves of a local archive, or other similar sporadic versions or even misspellings by scribers or writers who put down a name as they thought it sounded etc. 300 years ago does not mean "also known as". "Also known as" means alternative, or even completely different names as recorded in older school textbooks, old encyclopeadias etc. ——Chalk19 (talk) 22:22, 10 March 2019 (UTC)
PS. Most places in Greece have tenths of variations of their names like those of Dorvitsa, starting from time immemorial: variations found in old manuscripts or some very old books, like with a "v" instead of a "b", or with a "p" in the place of a "b", or a "g" in the place of a "k", an accidental interchange of letters, a "t" replacing "d", or a "th" (Greek δ, sounds like in the) replacing "d", and an "o" instead of "ou", a sometimes missing "o", a "tz" in the place of "ts", just a stressing mark in another syllable etc. etc. etc. Several irregular and incontinuous forms that don't mean that the place is "also known" by all these alternate, sporadic forms, that most of them just appeared somewhere because in those days there was not a "standard" version of the name of the place, because a sriber or an author was changing the name accoding to what was closer to his (probably not "her" in those times) cultural backround (if he were of this or another ethnic origin etc.) Variations as the abovemationed are not "other common names", or "alternative names" to the "most common name […] known by to readers", as requiered in Aliases: Criteria for inclusion and exclusion.——Chalk19 (talk) 22:39, 10 March 2019 (UTC)
PS2. Sometimes variations of this kind may be included (according to the reliable sources available on them) in a summary in a section on older names, or name forms recodered of a place in its article in WP. ——Chalk19 (talk) 22:57, 10 March 2019 (UTC)
@Chalk19: hmm, I agree, too rare variations found in old manuscript are not what alias is intended for (but still can be used to store them) but here, according to TakisA1 these come from « goverment gazettes ». So it seems ~correct to me, and there is no such thing as having too much aliases, the more the better. Anyway, if not in aliases these names can also be stored in properties (name (P2561) or a more specific one) where references can explicitely be added. Cheers, VIGNERON (talk) 08:00, 11 March 2019 (UTC)
PS: « translations and transliterations, should be recorded as aliases » (Help:Aliases so yes a "tz" in the place of "ts" is acceptable per this rule (and it's a good thing as most people don't know that 'tz' and 'ts' are equivalent in Greek).
@VIGNERON: Well, does anybody really think that a Greek village actually has 17 (!!) different, alternative common names? Not even Constantinople, an imperial capital of a 1,600 years doesn't have so many! ("Βυζάντιο", "Νέα Ρώμη", "Κωνσταντινούπολη", "Πόλη", "Βασιλεύουσα", "Ισταμπούλ").
TakisA1 claim that all these "are found in historic sources like goverment gazettes" is a totally misguiding statement. According to his own source (provided in this edit summary), only Δοροβίτσα is from a 1836 goverment gazette, "Δοροβίτσα, (εφημερίδα κυβερνήσεως 1836)". For the rest we get no information, neither wher there have been found, nor (and this is crucial) how widespead was the use of them (if any, in public). Finally, please note that TakisA1 source is not a reliable source; it is just a post in the website of a local recreational club providing something written in 1973 by the amateur historian Sokratis A. Liakos (obviously a reproduction from a book or an article of his, not mentioned in the post). ——Chalk19 (talk) 09:05, 11 March 2019 (UTC)
@Chalk19: why do you think that aliases have to be « alternative common names », it's is just for « alternative names » (no matter how common they are, we do avoid the more rare variations but it doesn't have to be common, look at the examples on Help:Aliases). That said, TakisA1 could you provide good references, it would be useful for name (P2561) (and maybe also for Lexemes). Cheers, VIGNERON (talk) 10:32, 11 March 2019 (UTC)
@VIGNERON: According to Wikitada policy on the matter that I have already quoted above (Criteria for inclusion and exclusion): "The label on a Wikidata entry is the most common name that the entity would be known by to readers. All of the other common names [my emphasis] that an entry might go by, including alternative names; acronyms and abbreviations". So, we clearly talk about "other common names" (my emphasis). Furthermore we "should not include […] spelling mistakes". So, what is the proof that, say, the forms "Τεροβιτζιά" or "Τιροβήτσα" found somewhere (where? in an official document? in a entry by some semi-illiterate book-keeper of the area? on a gravestone?) in 1770 and 1791 respectively (according to TakisA1 source [11]) how widespread actually were? Meaning, were they "common names" or "other common names" of those times? Moreover, couldn't be "Τεροβιτζιά" the "common name" and the similar sounding "Τιροβήτσα" an accidental misspelling of it, or vice versa? And what about "Ντερβιτσά" recorded (according to the same source) by an anonymous French traveller who passed by the early 1800s? Did he put down the name in his notebook in Greek as it appears in the post? Or in French=latin scripture, so what is the original entry, and who had it transliterated to the Greek alphabet? And, then, isn't it highly probable, as were the case with foreigner travellers in those days, that he didn't know Greek, so he misspelled the name of the village? Isn't it possible that, since he was French, he wrote a "D" in the place of the initial Greek letter "Δ", or a possible initial "Τ"? So, why we must include "his" version of the name, "Ντερβιτσά", in owr "Also known as" list of the "other common names"? In other words: has TakisA1 provide any reliable secondary source about all these 17 alternative forms of the village name as its "other common names"? Not, so far. ——Chalk19 (talk) 11:35, 11 March 2019 (UTC)
I found this source [12] which says that François Pouqueville was the french traveler. Although this source at first doesn't seem accurate, the information provided by this article seems well researched. The first source comes from the official site of the union of people from Dorvitsa (Dorvtisa.gr). Those versions indeed are not yet used but being a person from this village I can tell you we only use Dorvitsa or Dorvitsia.(TakisA1 (talk) 18:56, 11 March 2019 (UTC))
The "official site of the union of people from Dorvitsa"! What a euphemism for just the website of just a local recreational club! "[S]eems well researched"? hmmm, but is it, or it just seems so (to you perhaps, but not to me). ——Chalk19 (talk) 19:36, 11 March 2019 (UTC)
Here, in this official document of the Hellenic Ministry of Environment and Energy [13] in page 132 is a reference to all the names.(TakisA1 (talk) 15:14, 12 March 2019 (UTC))
You are still trying to misguide us; of course I am fully aware of these tactics of yours from el-WP. This is not any "official document of the Hellenic Ministry of Environment and Energy"; don't try to fool us again as you did before with the "goverment gazettes". This "official document" is just an application to the Ministry by some individuals (engeneers and architects) in order to get funds for a project. Somewhere in there description of the area, they write a few words about its villages, and their history: on Dorvitsa they copy-paste the other "source" of yours, i.e. the post at the wabiste of the local recreational club. This is my last comment to the subject: I am "escaping" of this fallacious discussion that leads nowhere. ——Chalk19 (talk) 07:51, 13 March 2019 (UTC)
I did not try to fool anyone. The official name of ΦΕΚ is Government Gazette. Also this is an official survey for the Ministry, in the minitry's official website making this an official docyment.(TakisA1 (talk) 12:45, 13 March 2019 (UTC))

Suggestions based on constraints: next step

Hello all,

Last year, we enabled suggestions based on constraints values for the constraints section of a property as a beta feature. You can also have a look at the documentation and the list of supported constraint types.

After a few months of testing, we would like to enable it for all users. Before that, we would like to know more about your experience with that feature.

  • Did you encounter issues or unexpected behaviours?
  • Is there anything that should be improved before enabling it for all users?

When reporting an issue, please give specific examples and what you would have expected instead, so we can figure out the best way to solve it. You can also leave a comment in the related ticket.

Thanks! Lea Lacroix (WMDE) (talk) 13:21, 11 March 2019 (UTC)

I still have the feeling that the feature isn't ready for deployment yet. There hasn't been any work on it since it's release as a beta feature. Important things as sorting based on usage is still missing, making the feature useless for me. For example, genders are sorted very weirdly. Also a Phabricator task about the automated results not being linked (aka not possible to open the property or item in a new tab) is still open. Sjoerd de Bruin (talk) 13:34, 11 March 2019 (UTC)
I see radically improved suggestions for “gender” in the last couple of weeks (male and female first, thank you!). All in all, I find the feature really useful - no complaints now that gender is better. - PKM (talk) 23:07, 11 March 2019 (UTC)
Thanks for your replies! @Sjoerddebruin: this is exactly why we're coming to you right now and ask for your feedback :) We will make sure to take this ticket in account. Can you check again the order of genders and let me know if there is still something going wrong? Is there anything else that we should know about and fix? Lea Lacroix (WMDE) (talk) 11:22, 13 March 2019 (UTC)
The order of the genders have improved indeed... If I find more, I'll add it to the task. Sjoerd de Bruin (talk) 11:31, 13 March 2019 (UTC)

How do i send a query that searches for a lexeme with some label?

I need to do the same as search for an item, but in wqs. Easy as pie (I'm newbie).

example search for the french word 'maison'.

thanks.  – The preceding unsigned comment was added by 167.57.173.254 (talk • contribs) at 19:33, March 12, 2019‎ (UTC).

Have you tried "L:maison" in the "Search Wikidata" box on the top right? Autocomplete doesn't find it, but if you follow the "containing ..." link it is there. If you were looking for ways to do it with our "Query Service", see the list of "useful queries" here: Wikidata:Lexicographical data/Ideas of queries. ArthurPSmith (talk) 20:05, 12 March 2019 (UTC)
And if you really want to a WQS SPARQL query, here it is :
SELECT ?l WHERE {
  ?l dct:language wd:Q150 ; #lexemes in French
     wikibase:lemma ?lemma . #with a lemma
  FILTER regex (?lemma, "^maison$"). #this lemma being exactly "maison"
}
Try it!
Cdlt, VIGNERON (talk) 23:02, 12 March 2019 (UTC)
Thank you very much. Is it that too expensive? Should I search in the box or is it the same thing? for last any idea how can i paste that to wdq? That program is awfully explained.
Hey dont plublish my ip everywhere!
unknownnewbie
@VIGNERON: much more efficient:
SELECT ?l WHERE {
  ?l dct:language wd:Q150;
     wikibase:lemma "maison"@fr.
}
Try it!
--TweetsFactsAndQueries (talk) 08:55, 13 March 2019 (UTC)
@unknownnewbie: when you edit while not logged in, your IP address is public on the page history, whether someone adds {{Unsigned}} or not – there should have been a warning about this when you started editing. If you don’t want that, create an account. (And I think you can contact the Administrators' noticeboard to have your IP address hidden, if necessary.) --TweetsFactsAndQueries (talk) 09:00, 13 March 2019 (UTC)
How do i paste that query here: https://query.wikidata.org/bigdata/namespace/wdq/sparql?query={SPARQL} , or more precisely how to send a query from bash. I'm using wdq ( https://github.com/nichtich/wdq ) at the moment, but seems to function at too elementary level.

February Facto Post/systematic reviews event in Cambridge UK

w:User:Charles Matthews/Facto Post/Issue 21 – 28 February 2019 for the recent issue of the Facto Post newsletter — just a reminder that it is delivered on enWP, and you can subscribe or unsubscribe by following links in each number. The editorial there is on systematic reviews. As part of the Cambridge Science Festival this year, I'm leading a workshop on systematic reviews and related material to do with evidence-based medicine: official page ScienceSource workshop: how do scientific discoveries become clinical medicine?, and Eventbrite signup page.

The workshop is not an introduction to Wikidata, as such. I'd like to think it is an introduction to a major use case for Wikidata. Abstracting from current practice on systematic reviews and trying to think in structured data terms, one does reach areas around tagging, metadata, MEDRS and so on, quite quickly. All this material is very much adjacent to Source MD and WikiCite.

I'll be posting a more detailed programme to the Eventbrite page in the next few days. Charles Matthews (talk) 11:33, 13 March 2019 (UTC)

Missing edit buttons

Is anyone else having interface issues? Jc86035 (talk) 12:02, 17 March 2019 (UTC)

I did and hope I fixed it. There was an error in MediaWiki:Gadget-SimpleTransliterate.js. Matěj Suchánek (talk) 12:11, 17 March 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 18:45, 19 March 2019 (UTC)

Could someone fluent in Russian have a look at Special:Contributions/Алексей_Скрипник, and help this user to understand the difference between data items for works versus data items for editions. I have found at least one instance where he merged a literary work with one of its editions. Some of his other edits seem odd as well, such as removing language of work or name (P407) from publications. --EncycloPetey (talk) 13:58, 13 March 2019 (UTC)

✓ Done. --Ksc~ruwiki (talk) 19:52, 13 March 2019 (UTC)

How to parse queries from bash linux?

Im trying with wdq ( https://github.com/nichtich/wdq ), but it seenm too restrictive. Also I tried parsing queries at https://query.wikidata.org/bigdata/namespace/wdq/sparql?query={SPARQL} , but i have no true idea about how should the sparql be parsed inside that uri. Btw Have you wondered implenting an ssh or telnet service? Thanks --167.57.34.226 21:40, 13 March 2019 (UTC)

  • The output from https://query.wikidata.org/... will be in RDF or JSON, which I imagine wouldn't be much fun to parse in a shell script. You could write something in some other language (say with a JSON library) that outputs simple text for shell, but if you have a decent language, why use shell? Another thing you could do is run the query interactively at https://query.wikidata.org/, download the results as CSV and process the CSV from the shell. Ghouston (talk) 07:00, 14 March 2019 (UTC)
wdq that you mentioned is the thing that outputs simple text for a shell, but a more flexible version could take a SPARQL query as the parameter, instead of limiting it to specific kinds of queries. Ghouston (talk) 07:50, 14 March 2019 (UTC)

Schedule of Wikidata entity dumps generation - important if you use them!

There is a discussion going on about changing the frequency and schedule with which these dumps are generated, see the phab task. Please weigh in over the next few days if you have a project that uses these dumps and need the schedule to be a certain way. If we hear no objections then mid-next-week we'll start figuring out how to best shuffle the start dates around. Also, if you know others who use these dumps and might not see this message, please poke them. Thanks in advance, -- ArielGlenn (talk) 09:38, 14 March 2019 (UTC)

Nonsense elevation values

As my bot request was ignored for half year already - will we ever do anything about the bogus elevation above sea level (P2044) values especially for hills and mountains imported from the Cebuano Wikipedia (Q837615)? The way these values were generated has both the inaccuracy of the altitude model, but much more severe the inaccuracies of the coordinates, thus that algorithm only give credible results for relatively flat landscapes, quite the opposite of hills. In the past months, whenever I came across such an item, I added the missing reference, set the status to deprecated and if had time even looked for the correct value. So now the following query (Kudos to @Tagishsimon:) can illustrate how much our data on the height of hills is only for entertainment purposes.

SELECT ?item ?itemLabel ?normal ?deprecated ?diff ?unitLabel WHERE {
  ?item p:P2044 ?statement.
  ?statement psn:P2044 ?statement_psn .
  ?statement_psn wikibase:quantityAmount ?normal .
  ?statement_psn wikibase:quantityUnit ?unit .
  ?statement wikibase:rank wikibase:NormalRank .
  {?statement prov:wasDerivedFrom ?statement0 .
  ?statement0 pr:P143 ?normal_ref . 
  filter (?normal_ref!=wd:Q837615) }
  UNION
  { filter not exists {  ?statement prov:wasDerivedFrom ?statement0 . } } 
  ?item p:P2044 ?statement1 .
  ?statement1 psn:P2044 ?statement1_psn .
  ?statement1_psn  wikibase:quantityAmount ?deprecated .
  ?statement1 wikibase:rank wikibase:DeprecatedRank .
  ?statement1 prov:wasDerivedFrom ?statement2 .
  ?statement2 pr:P143 wd:Q837615 .
  bind(?normal - ?deprecated as ?diff)
 SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
Try it!

We must systematically set all the heights imported from ceb to deprecated, and add the missing references! Ahoerstemeier (talk) 11:56, 14 March 2019 (UTC)

I don't know why but I happen to think cebuano-inspired wikielements has frequent issues... But you can filter them easily out Bouzinac (talk) 13:48, 14 March 2019 (UTC)

Light-on-dark color scheme for wikidata

Checking Light-on-dark color scheme on the English Wikipedia this is what I want for my interface but on wikidata. If I hit Preferences --> Appearance my skin is Vector. Does anybody have any Custom CSS for me so I can enable night mode/dark theme/dark mode? Even if you recommend a resource on let's say Wikibooks or Wikiversity I'd be happy to read up on anything you might recommend that after studying it might help me learn how to do it. Btqfshfst (talk) 21:52, 9 March 2019 (UTC)

@Btqfshfst: There are a number of Chrome extensions that purport to do this for any website. You might also want to look into https://www.mediawiki.org/wiki/Skin:Vector-DarkCSS Bovlb (talk) 20:26, 11 March 2019 (UTC)
@Bovlb: I did look into the https://www.mediawiki.org/wiki/Skin:Vector-DarkCSS link. User:Dbfyinginfo/vector.css has now been modified and a lot is now in "dark mode"/"dark theme". Not this edit screen which happens to be Dark-on-light but that's ok. I fixed most of my problems and I thank you for that! I can probably experiment more myself to perfect it Dbfyinginfo (talk) 19:30, 14 March 2019 (UTC)

Hello. Can someone set a request listing files with interior in their title on the talk page for that property? It would be very useful to easily find potential values for image of interior (P5775) statements. Thierry Caro (talk) 00:36, 13 March 2019 (UTC)

@Thierry Caro: Here's a first stab:
SELECT ?item ?itemLabel ?image WHERE {
    {
        SELECT ?item ?image WHERE {
            ?item wdt:P18 ?image .
        } LIMIT 1000000
    }
    FILTER (CONTAINS(LCASE(str(?image)), "interior")) .
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!
The LIMIT is needed because otherwise the query times out: add eg OFFSET 1000000 etc to look at further sets.
Note that at higher Qids this returns quite a lot of paintings containing the word 'interior', attached to the item for the painting -- you might want to filter these out.
A different approach might be to look for Commons categories containing the word "interior" -- I'm slightly reserved about the idea of looking at P18 statements for possible P5775 candidates, because on the one hand I am not sure that duplication of an existing P18 image is necessarily very helpful; while removing an existing P18 statement could if anything be worse, if that is the best representation of the subject. But see what you think. Jheald (talk) 09:47, 13 March 2019 (UTC)
@Jheald: OK. Thank you very much. I'm going to try to improve this. No image of interior (P5775) statement and multiple image (P18) statements would be nice filters to add in order to find even better candidates for a potential move. Thierry Caro (talk) 11:34, 13 March 2019 (UTC)
@Thierry Caro:
SELECT ?item ?itemLabel ?count ?image 

WITH {
   SELECT ?item ?image WHERE {
       ?item wdt:P18 ?image .
   }  LIMIT 1000000
} AS %images
   
WHERE {
    {
       SELECT ?item (COUNT(?image) AS ?count) WHERE {
           INCLUDE %images
       } GROUP BY ?item
      HAVING (?count > 1)
    }
    INCLUDE %images .
    FILTER (CONTAINS(LCASE(str(?image)), "interior")) .
    MINUS {?item wdt:P5775 [] }
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!
-- Jheald (talk) 13:18, 13 March 2019 (UTC)

See also Wikidata:Request a query. Visite fortuitement prolongée (talk) 19:12, 14 March 2019 (UTC)

Query for songs whose title contains a proper name

My try was this:

SELECT ?compositorLabel ?nacionalidadLabel ?nombreLabel ?cancionLabel WHERE {
  ?cancion wdt:P31 wd:Q7366. #there is some song (obvious)
  ?cancion wdt:P86 ?compositor. #that has some composer
  ?compositor wdt:P27 ?nacionalidad. #this composer has born at these place
  ?nombre wdt:P31 wd:Q1071027.  #this proper name
   FILTER(CONTAINS(LCASE(?cancionLabel), ?nombrelabel)).  #is part of the song title.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
Try it!

But it takes too long. --167.57.34.226 21:27, 13 March 2019 (UTC)

See also Wikidata:Request a query. Visite fortuitement prolongée (talk) 19:12, 14 March 2019 (UTC)

You can search for exact string matches (identical case) quickly, since it's an index lookup. But if you want to search case insensitively, or for a fragment within a string, I think it will always need to scan all potential records, like you are doing with FILTER. This can timeout if you don't have a way to restrict the number of candidates. It can be done in stages using LIMIT and OFFSET. Ghouston (talk) 23:34, 14 March 2019 (UTC)

Peter Smit (Q2247768) Wikipedia disambiguation page

I have added Peter Smit (politician) (Q62030208), but how do I connect the 3 items ( Peter Smit (politician) (Q62030208), Peter Smit (Q2786858), Peter Smit (Q1991362)) to the wikidata disambiguation page. I suppose wikidata disambiguation pages combine all the underlying Wikipedia pages. Note that Peter Smit (politician) does not have a NL page, but already has a Commons page. Het was an alderman in the The Hague city council, but do I use the past tense? From year x to year y.Smiley.toerist (talk) 10:50, 12 March 2019 (UTC)

PS: I would like to add the picture: File:Viering 150 jaar HTM 07.jpg. How do I do this?Smiley.toerist (talk) 10:53, 12 March 2019 (UTC)

You normally link to disambiguation pages using different from. I hooked up the three items in question for you, have a look. Moebeus (talk) 12:12, 12 March 2019 (UTC)
It is easier to change and add () to the label. Then no disambiguation is needed.Smiley.toerist (talk) 13:01, 12 March 2019 (UTC)
@Smiley.toerist: No, this is wrong. Please read Help:Label. "The label is the most common name that the item would be known by. It does not need to be unique, in that multiple items can have the same label ..." ArthurPSmith (talk) 13:37, 12 March 2019 (UTC)

I have problems completing the alderman functions. He was municipal executive of The Hague from march 2007 to 2014. Before that the 'municipal executive of Westland' from 2004 to 2006. Source vvd website. I have added (Q62067625).Smiley.toerist (talk) 11:21, 15 March 2019 (UTC)

Code review request to fix Wikidata Tours

Hi all

After some digging the bug which causes Wikidata Tours not to load properly has been identified and some code has been written which works on test.wikidata.org. Could someone who is able to review and approve code please take a look? Having Tours working will be extremely helpful for new contributors.

https://phabricator.wikimedia.org/T213704

Thanks very much

John Cummings (talk) 14:50, 15 March 2019 (UTC)

From the task it isn't much clear how it should be fixed. Post the exact steps for fixing it to MediaWiki talk:Guidedtour-lib.js. Matěj Suchánek (talk) 16:40, 15 March 2019 (UTC)
@Sebastian Berlin (WMSE):, could you do this? --John Cummings (talk) 16:48, 15 March 2019 (UTC)

How to deal with a large quantity of duplicates

There are currently two and a half sets of items for the 450 or so constituencies of the district council of Hong Kong (Q836365).

  • One mostly complete set (434 items) was created by Twly.tw's bot, Taiwan democracy common bot, without matching the items to sitelinks on the English or Chinese Wikipedias. These items currently have the label format "District Councils Constituency in [name], [district]"/"[district][name]區議員選區". (I think this is incorrect, since the labels should generally match the Wikipedia article titles.)
  • One partially complete set (284 items) has been created over time through auto-creation based on English Wikipedia pages. This overlaps with the mostly complete set (462 items + 7 pages with no item) auto-created from Chinese Wikipedia pages, but there are a number of duplicate items here as well.

In total, there are 1,036 items (not accounting for errors; e.g. w:en:Tung Chung North (constituency) appears to be about two different districts which have each had that name). Would it be possible to auto-match these, or does someone have to go through all of these manually? Jc86035 (talk) 10:03, 18 March 2019 (UTC)

I think either way it would need to be done by someone who understands Chinese, since with items like Wang Tau Hom (Q61057511) the only thing you've got for matching is the Chinese label. Ghouston (talk) 01:15, 19 March 2019 (UTC)
@Ghouston: (As noted on my user page, I can speak Chinese.) It would be fairly trivial to match the items, assuming that Twly.tw's labels are accurate. I didn't realize that QuickStatements could merge items, so that basically resolves the issue. Jc86035 (talk) 08:34, 19 March 2019 (UTC)
I've cleaned up just about all of the items (total 582 merges, leaving 431 constituency items with the correct statements). Jc86035 (talk) 16:41, 19 March 2019 (UTC)
This section was archived on a request by: Ghouston (talk) 21:29, 21 March 2019 (UTC)

Likely duplicates Brazilian economist Francisco Diógenes de Araújo and Brazilian politician Francisco Diógenes de Araújo

If someone with a better mastery of Portuguese than me could have a look, it seems Francisco Diógenes de Araújo and Francisco Diógenes de Araújo might be duplicates. Both have wiki articles in Portuguese, blocking a merge. Much obrigado Moebeus (talk) 15:17, 21 March 2019 (UTC)

Definitely looks like a duplicate to me - somebody needs to merge the pt articles first though. ArthurPSmith (talk) 16:55, 21 March 2019 (UTC)
Hello, @Moebeus, ArthurPSmith:, I merged the articles in ptwiki and resolved the merge. Thank you for your contributtions, Ederporto (talk) 17:25, 21 March 2019 (UTC)
That was quick, thanks a lot! Moebeus (talk) 17:27, 21 March 2019 (UTC)
This section was archived on a request by: Moebeus (talk) 17:27, 21 March 2019 (UTC)
@Ederporto: Any chance you'd be able to check Jorge Wicks Côrte Real (Q18276239) vs Jorge Wicks Côrte Real (Q48871884) as well? They seem like the same person to me, but again have two articles on ptwiki (Jorge Corte Real vs Jorge Côrte Real). --Oravrattas (talk) 07:02, 22 March 2019 (UTC)

LinkedIn personal profile URLs

We still need to convert P2035 (P2035) to an external-id datatype; or create a new property, migrate the data, and then delete the old one. See Wikidata:Project chat/Archive/2018/08#LinkedIn personal profile URL. Which would be preferred? Are there any objections? Is anyone prepared to work with me on this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:31, 14 March 2019 (UTC)

I’m in support of making this change one way or another. If we’re going to make it an external ID, then I think it should be named “LinkedIn personal profile ID” and use a formatter URL. That's probably enough changes to justify a new property to replace the existing one, which allows for a “deprecated” period on the existing property and an orderly conversion process before the old property is deleted. - PKM (talk) 20:15, 14 March 2019 (UTC)
 Support propose a new property to replace the old one. ArthurPSmith (talk) 14:22, 15 March 2019 (UTC)
@Pigsonthewing: And yes, I am willing to work on this with you. - PKM (talk) 19:12, 15 March 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

OK, now at Wikidata:Property proposal/LinkedIn personal profile ID. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 15 March 2019 (UTC)

Spanish speaker needed to check on Q8778498

España sagrada (Q8778498) is for a book published in 1700s but one of it's authors died in 1972. It seems odd, but sources point to Spanish Wikipedia and I do not speak Spanish. Can someone that does verify? --Jarekt (talk) 03:12, 15 March 2019 (UTC)

  • While the first volumes came out in the 1700s, parts of this were published well into the 19th century, and there have been various later editions, including one in the present century.
  • I presume you are referring to Ángel Custodio Vega (Q6173105). That looks like an error. According to es-wiki, he gave a lecture about about España Sagrada" in June 1950, La "España Sagrada" y los Agustinos en la Real Academia de la Historia; the lecture and some related discussion were published later that year. - Jmabel (talk) 03:29, 15 March 2019 (UTC)
Thank you for looking into it. So we should remove Ángel Custodio Vega (Q6173105) from list of authors. Right? --Jarekt (talk) 18:44, 15 March 2019 (UTC)
@Jarekt: Yes. - Jmabel (talk) 19:53, 15 March 2019 (UTC)

Scholarly articles and main subject P921

I've been busy with disambiguating author strings in scholarly articles and I am wondering how main subject is added to them.

  • Is it done programmatically ?
  • What is the heuristics behind it ?
  • Can it be done by humans ?

For example

RNA sequencing (Q2542347) has been added [14] as the main subject (P921) of

Exonuclease hDIS3L2 specifies an exosome-independent 3'-5' degradation pathway of human cytoplasmic mRNA (Q24294915)

How can one arrive at this decision ?
--Kpjas (talk) 14:16, 11 March 2019 (UTC)

I think its just done by taking keywords from the article title. 94.217.191.11 18:35, 11 March 2019 (UTC)
It certainly can be done by humans - I do that. I generally scan the first page of the actual article via the DOI, but I am mostly working with articles on costume and textiles. There’s a discussion of approaches in relation to the genewiki project here. Automated keyword scraping needs to watch out for book reviews, where the “main subject” should be the edition of the book and not the subject of the book. - PKM (talk) 23:01, 11 March 2019 (UTC)
It feels to be problematic to me that this statement is added by the QuickStatementBot without any ability to see which user is responsible for it. Having this way of easily adding batch statements is valuable but if the provenence information is lost and in cases like this the responsible user can't be asked, that's problematic. @Lydia_Pintscher_(WMDE): @Magnus Manske: ChristianKl19:27, 15 March 2019 (UTC)

Can given name and family name additions be somewhat automated?

Many person items are missing name fields: on Commons, there are currently over 260,000 person categories in Uses of Wikidata Infobox with no family name, and over 60,000 in Uses of Wikidata Infobox with no given name. There are likely many, many more "unnamed" people on Wikidata without a presence on Commons. Since given and family names are pretty fundamental biographical properties, it follows that they should be given some priority. I've been adding names to Wikidata piecemeal, but a semi-automated approach would be more efficient. However, this might be easier said than done, especially for non-Western or non-Latin script names: the Western surname Abraham (Q13367920) appears to have only one form/item here on Commons, while variants of the Japanese family name "Abe" alone include Abe (Q26000282), Abe (Q18645909), Abe (Q24091156), and Abe (Q27156022). Another potential snag is the distinction between multiple given and surnames (e.g. double-barreled surnames): "Jacob Thomas Spencer Smith" may have three given names with one surname, or perhaps two given names, with Spencer a maternal and Smith a paternal surname. Spanish-language names also often involve a matronym and patronym, one of which may be dropped in common usage. I don't claim to have any knowledge of how a semi-automated drive may proceed, but hopefully some wizards can figure it out. Perhaps start with the simplest scenarios first (whatever that may mean)? Animalparty (talk) 18:54, 14 March 2019 (UTC)

We also need to consider that some authorities will include multiple treatments of “double-barreled” surnames, and all of these should be included with references, the versions most used being preferred. That may be hard to automate. - PKM (talk) 20:22, 14 March 2019 (UTC)
IMO we also need to ask what is our preferred best practice for “double-barreled” surnames? I am far from convinced that we should be creating a new item for every such pair, which could be a huge number of additional names, sometimes vanishingly infrequent. What is our current recommended practice on this at present? Jheald (talk) 14:24, 16 March 2019 (UTC)
Not to mention Abe (Q11160829) and Abe (Q56247486). I'd say the latter is the right one to use when adding a Surname "Abe" from a Latin script document, but I'm not sure that the former should ever be used in a Surname statement. Actually, Abe (Q56247486) doesn't have a script specified. It should probably be made the Latin script version, and also used for people like John Abe (Q6218046). Ghouston (talk) 22:04, 15 March 2019 (UTC)
  • yes (if you can determine it fairly reliably) and no (if you can't). Approaches I used for given names worked fairly well. Some people tried it for family names ended up stopping it. If you want to do family name, maybe try people of the same nationality. --- Jura 08:53, 16 March 2019 (UTC)

Please let us input Q/P-number just as is

gibt es einen grund. warum man nicht die Q/P-nummer einfach als solche eingeben kann? W!B: (talk) 19:33, 22 March 2019 (UTC)

Do you have an example? --Succu (talk) 19:35, 22 March 2019 (UTC)
sorry, please forget this silly question ;) - of course that works. I just used a invalid number. W!B: (talk) 20:03, 22 March 2019 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 22 March 2019 (UTC)

Wikidata - now the most edited wikimedia website

fwiw, the number of #wikidata edits caught up with the number of en #wikipedia edits at 14:05 on 19 March 2019, at 883,173,630,[15] and thus wikidata is now the most edited wikimedia website. Yay us. --Tagishsimon (talk) 14:25, 15 March 2019 (UTC)

March 19? What's it like in the future? :P Also, yay! Nicereddy (talk) 18:56, 15 March 2019 (UTC)

That's very exciting! :D
I wonder if this is partially due to wikidata-driven infoboxes becoming more popular thus convincing Wikipedia editors to contribute to Wikidata. ElanHR (talk) 21:55, 15 March 2019 (UTC)
@Tagishsimon: In a highly automated project this is not very surprisingly. Any idea about the amount of real manual edits? --Succu (talk) 22:03, 15 March 2019 (UTC)
Plus the tendency to add labels in different languages one by one. Ghouston (talk) 00:41, 16 March 2019 (UTC)
Plus the fact that users can only change a single item at a time. If Wikipedia only allowed you to add one sentence per edit... well, everyone probably would have abandoned the project on January 17, 2001. Animalparty (talk) 01:32, 17 March 2019 (UTC)

Q256916

Can someone lock Fiona Caroline Graham (Q256916), there is a movement to remove the information on the birth information of geishas, because they are are never supposed to reveal their age. A fan of this geisha from Australia and I think a second fan from Brazil has a campaign to remove her age from all the Wikipedias (or one person spoofing a Brazil IP). They emailed me asking to remove it, when I said the info came from the Library of Congress, they wrote the LOC to have it removed from their website. We now link to the cached version. However it is public information, and accurate. Even if the geisha age rule was a real thing, the person in the entry is not a licensed geisha according to the Asakusa Geisha Association. --RAN (talk) 00:26, 17 March 2019 (UTC)

Semi'd for a month. Take protection requests to WD:AN next time, RAN. Mahir256 (talk) 03:20, 17 March 2019 (UTC)

New data type: musical notation with Lilypond format

Hello all,

Following a request from community members, we just deployed a new data type called “Musical Notation” in order to store musical notation in Wikidata. Property creators can now find this new data type in the list and create new properties with it.

A property with musical notation data type will display the notation in Lilypond format, using the score extension.

For example, if you enter this code as a value: \relative c' { c d e f | g2 g | a4 a a a | g1 |}, it will be displayed as such:

The score also appears on the diff pages.

The existing property P5482 (P5482) is used on around 300 items. If you need any help from the developers to change the datatype of the the property or to migrate the content, please let me know.

One bug is already known and we’re working on fixing it: if the score is long, it gets out of the statement box and overlaps with the edit button.

If you encounter any issue, feel free to create a subtask of this ticket.

Cheers, Lea Lacroix (WMDE) (talk) 20:03, 14 March 2019 (UTC)

Not described (yet?) in Help:Data type. Any list of supported syntax? Can we use a test property on Test Wikidata? LaddΩ chat ;) 23:34, 14 March 2019 (UTC)
There's a test property on test and on beta :) Lea Lacroix (WMDE) (talk) 06:25, 15 March 2019 (UTC)
I introduced that type in Help:Data type but I noticed it is not described in mediawiki:Wikibase/DataModel either. LaddΩ chat ;) 12:13, 15 March 2019 (UTC)
Nice! ArthurPSmith (talk) 14:19, 15 March 2019 (UTC)
I look forward to using this on Q12030. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:35, 15 March 2019 (UTC)
I’ve proposed a sandbox property for this datatype; I’ll leave the discussion about real properties (convert P5482 (P5482)? replace it with one new property? split it into several new properties?) to others :) --Lucas Werkmeister (talk) 00:42, 16 March 2019 (UTC)
This issue is now resolved, it seems. LaddΩ chat ;) 14:27, 17 March 2019 (UTC)

Translating

My wikidata is set for the language Welsh, I'm trying to find how to translate the 'potential issues' box that can be seen in the following screenshot. Could anyone explain how I can translate this. Thanks

Johnogwen123 (talk)

@Johnogwen123: I think you need to find the relevant message at translatewiki.net. A separate account on that website is needed to contribute translations. Jc86035 (talk) 10:14, 17 March 2019 (UTC)

Proper way to mark uncountable/mass nouns as such?

See Lexeme:L4592 for an example of an uncountable/mass noun. Gold is a word, but golds isn't. Is the correct way to mark uncountable nouns as such has characteristic (P1552) with mass noun (Q489168)?  – The preceding unsigned comment was added by SixTwoEight (talk • contribs).

Pretty sure Lexicography uses instance of (P31) just fine. Judging by the examples on its page, has characteristic (P1552), seems to call for a quality that can be further defined (animacy (Q1250335) is a quality, inanimate (Q51927539) is not). Instance of noun have a grammatical gender (P5185) property that applies to them, but it is the word class of noun/adjective/determiner which, depending on language, has characteristic (P1552) of animacy (Q1250335) or grammatical gender (Q162378).
Being a mass noun is clearly not a quality to me, it's a lexical category (the actual quality, for which no item exists yet, is "countability"). Honestly Looking at uses of "has quality", I don't see a lot that unambiguously belong there, but I suspect that the problem is really that the base properties to use for lexemes have seen basically no discussion whatsoever before the feature was launched, so it's a massive mess of inconsistent usage because nothing is being checked by bots.
I think implementing word classes as a weird supra-category that is not actually handled via an actual property was an error, as it is causing people to assume it basically supplants and prevents use of instance of (P31) for the entire Lexeme namespace. Circeus (talk) 01:27, 17 March 2019 (UTC)
  • There is some debate how and if P31 should be used in Lexeme namespace. (To those not aware of it: each entity in Lexeme namespace has a lexical category (e.g. noun) and language defined. Lexical categories are similar to P31 statements)
    For the above, some users use has characteristic (P1552) (as you did). This does seem compatible with the property definition.
    Others use instance of (P31) for the same, even if they don't use P31 in all other cases. The result is that a query based on P31/P279 that isn't limited to property entities and item entities includes some odd results.
    A third option could be to add the lexical category systematically as a statement in P31 or have Wikibase generate a P31-triple automatically based on the lexical category. --- Jura 09:00, 17 March 2019 (UTC)

Domain names

How are Internet domain names supposed to be modelled in Wikidata? Should they have their own items?

  • At least one Wikidata property, Alexa rank (P1661), is linked to particular domains, rather than to the service(s) hosted on those domains.
  • Domains and subdomains do not necessarily have one-to-one relationships with services. For example, both Google Images and Google Maps are currently served through www.google.com, and Google has a large number of international domain names through which those services are also served. It would be difficult to map Alexa rank (P1661) for these services, since either (1) all the data would have to be linked to one service or one company, or (2) all of the data would have to be duplicated across all of the items.
  • Domain names may have their own properties: their owners, when they were first registered, their HTTPS information, and so on, which would be difficult to model without items for those domain names.
  • Services can change domain names (e.g. TheGuardian.com (Q5614018)/The Guardian (Q11148), Fandom (Q17459)). This can be reflected using official website (P856), but it makes it much more difficult to associate data with the domains themselves.
  • Some subdomains (e.g. for Tmall (Q2829108) and Tumblr (Q384060)) also have their own Alexa data. It could be appropriate to create items for them.

Jc86035 (talk) 10:12, 17 March 2019 (UTC)

Q54933327 strange thing

There is a strange thing happening on Q54933327. There are three articles linked to this data, one on the pt.wiki, another on the es.wiki and another on the en.wiki. If you go to the article on the en.wiki and click on the hyperlinks, it'll redirect you to the correct articles on pt.wiki and es.wiki. If you go to the es.wiki article and click on the hyperlinks, everything is ok too. But on the pt.wiki, if you click to go to the en.wiki article it'll redirect you to an article on en.wiki which not even exist. I tried to edit Q54933327 to fix it, but I do not even know what is wrong. SirEdimon (talk) 04:00, 23 March 2019 (UTC)

Issue is now resolved.SirEdimon (talk) 06:02, 23 March 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 13:26, 23 March 2019 (UTC)

Automated processes and references

Here’s a question that may lead to an RfC, depending on your responses:

At this stage of Wikidata's evolution, should automated processes/bot jobs that add statements without also adding references for those statements be strongly discouraged?

I would assume there would be exceptions for statements like <instance of>, <subclass of>, and external identifiers, and for self-referencing items like books. Thoughts? - PKM (talk) 20:31, 14 March 2019 (UTC)

Different areas of Wikidata are more developed than others, and different areas are more in need of references than others, or more in need of raw quantity than others. There are many areas in which bots adding unreferenced statements would be less than welcome, and others where bot-added unreferenced (but hopefully at least minimally curated) statements would be a useful addition. --Yair rand (talk) 20:45, 14 March 2019 (UTC)
I do not think we should require references for automated editing, for several reasons:
  • You mention that there will be exceptions, but who defines which ones would be acceptable? I think there will be lots of exceptions and also exceptions from exceptions, which could make it difficult to comply with such a complicated policy.
  • Mandatory references complicate the batch/bot editing process, so new and less tech-savvy users might find it difficult to contribute to Wikidata.
  • There are plenty of worthless references available already now, often from batch jobs where users wanted to do it correctly, but their references are either not well-shaped, or the sources do not support the actual statement. I’d expect reference quality to decay a lot once we made their addition mandatory.
MisterSynergy (talk) 20:50, 14 March 2019 (UTC)
Which particular bots do you think should be discouraged? ChristianKl14:07, 15 March 2019 (UTC)
I've looked at item maturity in the past. A proto-item is for example a new empty item just created with one sitelink to Wikipedia. On the other end of the scale we have items that are very extensive and very well sourced. For proto-items I'm quite happy to just get some statements on them, with or without references.
These days most automated tools and bots add references, right? Do you have some examples without references? I'm especially interested in items that don't link to Wikipedia. Multichill (talk) 14:42, 15 March 2019 (UTC)
Sometimes applying Help:Edit summary (Q4533519) is enough. --Succu (talk) 21:54, 15 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Thanks, all, for the comments. Clearly further action is inappropriate at this time. - PKM (talk) 19:52, 17 March 2019 (UTC)

Indicating verified accounts

There seem to be two approaches for indicating "verified" accounts on social media - has characteristic (P1552):verified account or profile (Q28378282) 110 times, or has characteristic (P1552):verified badge (Q48799541) (example query for twitter)

Overall, a reasonably even split between calling it an "account" or a "badge". I don't have any strong feelings on which one we use, but it feels like we ought to be consistent and pick one. Any thoughts as to which is more appropriate? They have quite different class hierarchies but seem to be tied together by has effect (P1542) and has cause (P828). Andrew Gray (talk) 23:30, 15 March 2019 (UTC)

verified account or profile (Q28378282) seems like the right one to me, since that would be an account quality, while verified badge (Q48799541) would be a badge quality. Ghouston (talk) 00:39, 16 March 2019 (UTC)
I agree that verified account or profile (Q28378282) reads like a better target for has characteristic (P1552), though verified badge (Q48799541) does seem like it's a more precise item to use, and might have been the more obvious choice with a slightly different qualifier property. It's probably also worth noting that instance of (P31) seems to be used even more as a qualifier for this purpose (>300 times on X username (P2002), all with verified account or profile (Q28378282)), so if we're going to run a bulk migration to tidy these up, it might be worth looking at fixing those too. --Oravrattas (talk) 07:34, 16 March 2019 (UTC)
Oh, well spotted - I didn't think to look for non-standard qualifiers. Instagram username (P2003) (which allows P31 in its constraints) has 59 "verified account"; Instagram username (P2003) has 131; YouTube channel ID (P2397) has seven (plus a couple of values for other things). So those are consistent, at least, even if possibly on the wrong qualifier. Andrew Gray (talk) 11:42, 16 March 2019 (UTC)
Great initiative! One observation: not all verified accounts have verified badges, but all verified badges belong to verified accounts. Facebook specifically operates with different colored badges to reflect this, Youtube has verified music accounts with or without badges, there are probably more examples. Moebeus (talk) 12:11, 16 March 2019 (UTC)
I'm thinking it would be a good idea to rename en:Verified badge to Verified account, for this reason. It has already gone wrong with "In February 2012, Facebook introduced verification badges for profiles and pages", trying to describe all such systems as "badges". Ghouston (talk) 22:05, 16 March 2019 (UTC)
But that name redirects to en:Account verification. Amazingly, the Verified badge article doesn't mention the former. Perhaps these two articles should be proposed for merging. Ghouston (talk) 22:02, 17 March 2019 (UTC)

New tool: QuickCategories

Hi folks! I want to announce a new tool I’ve been working on: QuickCategories (documentation), a tool to quickly add or remove categories from pages. It’s not especially useful for Wikidata directly, but it’s kind of Wikidata-adjacent, so I still want to announce it here :D

I assume most people here are familiar with QuickStatements. Harmonia Amanda suggested that something similar for categories instead of statements would be useful, and so that’s what I built. You specify the page to edit and the categories to add or remove in a big text box:

Page 1|+Category:Category to add|-Category:Category to remove
Page 2|+Category:Category to add|-Category:Category to remove

Like in QuickStatements v2, you can use keyboard-friendly | or spreadsheet-copy+paste-friendly Tab characters as separators (or mix them). At the moment, there’s no support for running commands in the background (in that respect it’s more like QuickStatements v1), but I plan to add that in the future (hopefully soon).

You can also generate commands via a Wikidata query. For example, running this query lists all Members of Parliament of the United Kingdom whose Commons category is not a subcategory of commons::Category:Politicians of the United Kingdom. You can copy the last two columns of the results (in Firefox, hold down Ctrl while dragging the mouse across them) and paste them directly into the tool.

The tool supports all Wikimedia wikis, but it’s probably especially useful on Commons, that’s why for now I’m only announcing it there and here. Feel free to copy or crosslink the announcement on the village pump (equivalent) of other wikis you think might be interested, or let me know if you think I should do it. If you have any questions, please contact me on the tool’s talk page, preferably with a {{Ping}} (I don’t check my watchlist on Meta that often). --Lucas Werkmeister (talk) 21:57, 17 March 2019 (UTC)

Let's talk about gender

The property sex or gender (P21) seems like it could use improvement.

The good: The property allows for an impressively diverse range of values including "two-spirit", "transfeminine", "agender", etc.

The bad: because the property only allows you to pick one single value, it is very inflexible. For example, when describing a woman you have to pick between "female" and "transgender female". This ghettoizes transgender people: the question of whether someone is female should be considered seperately from whether they are cisgender or transgender. Also, look at the case of Mauro Cabral Grinspan. Over on Wikipedia, sche pointed out to me that Grinspan identifies as transgender, male, and intersex, and all three are important parts of his identity as an activist and a human being. However, currently, P21 does not allow you to select all three. Instead you must choose between "transgender male" or "intersex". (Currently he's listed as transgender male.)

One obvious solution: allow multiple values. I found a report about cataloging gender that advocates this approach. Here is what that might look like:

Alternatively, instead of allowing multiple values, perhaps we could keep the one value constraint but open things up to qualifiers, to similar effect:

etc.

Note that in my view, strong preference should be given to current self-identification (as recorded in reliable sources). For example, a trans woman should not be listed under both "female" and "male" but just "female". The RDA cataloging standard, which I believe is considered pretty authoritative in the library world, has a similar view. It says, under "instructions for recording gender": Gender is the gender with which a person identifies.

Related to the above, my biggest fear with opening up the gender category like this is that editors will just indiscriminately slap both "male" and "female" onto practically any trans or queer person. Perhaps, to avoid this kind of "excessive gendering", it would be better to go with a single value + qualifiers approach.

Anyway, that's my two cents, but note I'm very new to Wikidata don't claim to be an expert on either cataloging or gender. :)

(*) Why didn't you list Shakespeare or Chastain as cisgender? While it would seem fairly reasonable to describe them as cisgender, if someone hasn't identified as such in a reliable source, perhaps it's best to leave it out. (Jeffrey Tambor, meanwhile, has publicly called himself cisgender.)

(**) Why did you list Rebecca Sugar as both nonbinary and female? Because she identifies as a "nonbinary woman". Again, self-identification is king. (...Or queen. Or monarch.)

WanderingWanda (talk) 03:05, 9 March 2019 (UTC)

Note: There's quite a bit of previous discussion at Property talk:P21. Just a thought: if we're going to use self-identification as a qualifier, we should try to use qualifiers that are commonly and consistently used (as we should for any label, really). I myself am a cis-gender male, biologically. I identify simply as male, even though I just said I am cis-gender one sentence ago, and my future identification might change depending on whether I'm speaking on chromosomes or gender studies. The majority of male and female humans in history probably are or were cis-gender. As far as I know, Jeffrey Tambor (Q320204) referred to himself as a cis-gender man exactly once in a speech directly related to him playing a transgender character. Does that mean Tambor "identifies as cisgender male"? Is that enough for a qualifier? I'd argue no, unless he regularly corrects people when they call him an unqualified man. But gender and sexuality are certainly fluid and complex. I'm no expert either, and perhaps the rigid granularity of Wikidata doesn't fully allow for proper record keeping in this field. Animalparty (talk) 05:44, 9 March 2019 (UTC)
Animalparty I understand what you're saying but I think you're coming at this from the wrong angle. I don't think someone's cisness disappears just because they don't talk about it. Same with someone's transness or maleness or femaleness or straightness or gayness or whiteness or blackness. I rarely mention the fact that I'm white, but that doesn't mean I'm not white! It's also worth noting that people in a dominant majority group will naturally talk and think about that group a lot less than people in a marginalized minority group. Anyway, in my view Jeffrey Tambor said he's cisgender, and he's never indicated he's not cisgender, therefore, I think it's perfectly reasonable to label him as cisgender. WanderingWanda (talk) 07:12, 9 March 2019 (UTC)
I'll add that the only reason I used the word "qualifier" is because that's the Wikidata terminology and I was a little uncomfortable using that specific word. (Hmm, perhaps the fact the word "qualifier" is a little uncomfortable in this case is a reason to avoid using qualifiers to solve this.) WanderingWanda (talk) 07:21, 9 March 2019 (UTC)
I think it would be better to have two different properties. One for the sex just defined by the chromosomes and one for gender defined by the person them self. --GPSLeo (talk) 11:10, 9 March 2019 (UTC)
How do you propose we get people's chromosome data, exactly? Is Wikidata going to start commissioning large scale blood tests? :) WanderingWanda (talk) 16:26, 9 March 2019 (UTC)
I would only differ in has a Y-Chromosom or dose not have it. Of course we do not have the data in most cases, but then we just should not imply that we have that information like it is now. --GPSLeo (talk) 17:28, 9 March 2019 (UTC)
Unlike blood type (P1853), we do not actually need blood tests to determine this. Property_talk:P21#Reasonable_inferences. --Yair rand (talk) 18:41, 10 March 2019 (UTC)
I was going to argue but....it seems like the decision to combine sex and gender was made years ago, do we want to relitigate it? I feel like I went "what if we made these tweaks" and you came in with "ah but what if we just throw out what we have and start over?" :) WanderingWanda (talk) 04:36, 11 March 2019 (UTC)
(Was this a reply to my comment, or GPSLeo's? I'm in favor of maintaining one unified property using the current format.) --Yair rand (talk) 06:23, 11 March 2019 (UTC)
I might have misunderstood your position. WanderingWanda (talk) 15:38, 11 March 2019 (UTC)
@GPSLeo: (Via edit conflict) Very problematic. Just for some examples:
In most cases we have no idea who has XYY syndrome (Q267602) rather than simply being male.
Most transgender people see it as insulting to focus equally on their biological gender.
If we really want to model this, there is also presentational gender, which may be multiple for the same person: consider drag performers. And drag performers also can bring up some interesting issues about self-identified gender. Most identify with their biological gender. Some are transgender. Some start by identifying with their biological gender, then become increasingly transgender-identified over time. Many prefer a different set of pronouns depending on their presentation at the moment. - Jmabel (talk) 16:30, 9 March 2019 (UTC)
I admit I don't know much about drag culture, so maybe this is the wrong way to look at it, but: if we wanted to model a drag queen's in-drag gender presentation, my thought is that it should essentially be treated as the gender of a fictional character, like the gender of Harry Potter. WanderingWanda (talk) 16:51, 9 March 2019 (UTC)
The way Wikidata currently treats drag queens seems fine to me, though. As it is now: the label is the performer's drag/stage name, and then the performer's less-well-known non-drag name is listed as an alias, and the gender is listed as whatever the performer currently identifies as outside of drag. So the drag performer Eureka O'Hara is listed with the alias "David Huggard" and the gender of "non-binary" (because the performer identifies as, according to Wikipedia, "genderfluid and gender-neutral.") Meanwhile Alexis Michelle is listed with the alias "Alex Michaels" and the gender "male" because apparently the performer identifies as male outside of drag. WanderingWanda (talk) 17:54, 9 March 2019 (UTC)

Technical question: is it possible to set things so that a statement can have multiple values but certain combinations of values are constrained? For example, could the gender property be set so that you can combine the value “transgender” with the value “male” but there’s either a hard or soft restriction on combining “male” and “female”? WanderingWanda (talk) 01:34, 10 March 2019 (UTC)

I would support allowing the property to have multiple values to cover these cases. An alternative would be to simply expand the number of values, so that besides "transgender female" one could have "intersex female", "cisgender female", "intersex transgender female", etc, but the number of such values would be large (consider that it already allows things like "kathoey" and "two-spirit", and any of these might co-exist with "intersex"), and besides there are the other aforementioned conceptual reasons (the distictness of being trans/cs from being male/female) that simply allowing multiple values would be more sensible. (I would oppose a "chromosomal sex" parameter, since for almost all people, the parameter would be guesswork, and why add a field for something you know going in is going to be unverified and unverifiable guesswork in the vast majority of cases? Perhaps something like "assigned sex", while still very problematic, would at least be somewhat less farcical... but in most cases, we only know someone's gender: whether they present themselves, dress, etc as a man, woman, etc.) -sche (talk) 22:19, 10 March 2019 (UTC)
No, it is actually quite possible to infer it. See the linked section above. --Yair rand (talk) 00:03, 11 March 2019 (UTC)

One more thing: The fact that Caitlyn Jenner and other trans people have a "start time" qualifier added to their gender feels off to me. Gender transition is a lifelong, multistep process and someone coming out as trans is best thought of as a reveal rather than a sudden change. Caitlyn Jenner may have announced that she was a woman on "1 June 2015" but that doesn't mean that's the official start of her womanhood. In fact, if you read the Vanity Fair article that is used as a reference for that "1 June 2015" date, you'll discover that Caitlyn Jenner's family had been discussing her gender for decades before she publicly came out. I recommend we create a new "coming out date" property and use that instead of "start time". WanderingWanda (talk) 23:54, 10 March 2019 (UTC)

See significant event (P793), although I think that would be supplementary data rather than a replacement for start time. Note that start date properties can have variable precision. --Yair rand (talk) 00:03, 11 March 2019 (UTC)
Maybe instead of "coming out date", I'll propose new property "announcement time". That could be used for a lot of different things, including the date when someone came out as trans, and could also, presumably, be made to allow for variable precision. WanderingWanda (talk) 04:15, 11 March 2019 (UTC)
Personally, I think using P793 in more cases has many advantages over creating different properties, although some think otherwise. See Wikidata:Properties_for_deletion#.7B.7BPfD.7CProperty:P606.7D.7D for an ongoing discussion mostly about whether P793 should be used instead of many separate properties. --Yair rand (talk) 06:23, 11 March 2019 (UTC)

Looking into things a bit more, "sex or gender" originally did allow multiple values, and, unfortunately, it resulted in exactly the "excessive gendering" problem I was worried about. At one point Chelsea Manning, for example, was listed as "male" and "female" and "transgender female". Yikes.

The way Wikidata handles gender now is problematic but it apparently is a big improvement on how things used to be. Suddenly I'm much less inclined to try and change things, lest they regress.

Still, I think opening the gender property back up to multiple values could allow us to paint a better, more accurate, and more nuanced picture of who a person is, if we worked towards the goal of reflecting and respecting a person's latest self-identification and shared the basic understanding that trans women are women and trans men are men. WanderingWanda (talk) 16:00, 11 March 2019 (UTC)

sex or gender (P21) is in some languages named now nonly "sex", as it was proposed years ago. Mixing two concepts is not good, there are tools (categorization, grammatical case, inflection etc.) which requires binary input - man/woman/other (not specified, unknown, special). Everybody was born as man or woman (And have this information in birth certificate (Q83900)), but some of them identify himself as something other. So I thing everybody should have Template:P21=man/woman (in special cases (deprecated?) with qualifier at birth) and these special cases can have second statement something other. JAn Dudík (talk) 07:31, 13 March 2019 (UTC)

  • No, actually [:en:Intersex|not everyone was born as man or woman]. For several percent, it's really a matter of gender assignment at birth. - Jmabel (talk) 15:45, 13 March 2019 (UTC)
  • The claim that multiple values aren't allowed on Wikidata for sex or gender (P21) is false. The one value constraint indicates that a property generally has only one value, but doesn't say that it's forbidden to have more then one value. There's nothing standing in the way of adding multiple values and qualifying them with start time (P580), end time (P582), subject has role (P2868) and similar properties to describe the status of the relevant claim. If you do make multiple claims, the constraint warning even goes away when you flag one of them as the "preferred value" (and it makes sense to use the most recent self-identfied value for that).
When it comes to "announcement time" feel free to propose the property with multiple examples from different domains where it would be useful. I don't think significant event (P793) is good as a qualifier for claims about when a claim started being true. significant event (P793) doesn't subclass point in time (P585).ChristianKl15:11, 14 March 2019 (UTC)
  • I could be wrong but I believe, when I first looked at the property, the one value constraint was set to mandatory. I do see that multiple values are currently allowed, however. WanderingWanda (talk) 03:27, 16 March 2019 (UTC)
In 2014 the constraint was first set to the current wording, because in cases like this it's useful to enter multiple values. When WMDE implemented the features that make constraints more visible they tasked an UX person with writing texts that explain the constraint that had no experience with using Wikidata. That UX person thought that the constraint should be mandatory and wrote corresponding texts. Unfortunately, they didn't check in with the existing Wikidata community about whether we want the constraint to be mandatory. It wasn't clear to the person that it's important to have the flexibility in cases like that. It was up a while in that wording till I changed it back to the original wording. ChristianKl11:04, 17 March 2019 (UTC)
I don't think setting start and end dates helps (some or all of) the cases we're talking about, unless it's considered sensible and acceptable for multiple Qs to cover the same period and for that period to sometimes or often be the individual's whole life. Indeed, the ability to set start and end dates in this case seems more liable to be misused, if someone wants to pick a moment (of whatever degree of precision) and say "before then this trans woman was a man" (which is ... fraught with problems), than to have a good purpose. I don't know that setting a "preferred" value and other values as less-preferred helps either, in cases like e.g. the aforementioned Mauro Cabral Grinspan, an intersex trans man who is both an intersex and a trans activist and thus might not see one of those as more primary/privileged than the other. The solution seems to be to set multiple values at the same top level of "preferred"-ness, and I'm pleased to see that this appears to be possible. (Now to see if the edits stick...)
The remaining question is, I suppose, whether to continue handling trans women with the "transgender female" label or to prefer using "female"+"transgender", the latter of which I am pleased to see seems theoretically/technically possible since Q189125 exists. :) -sche (talk) 07:12, 18 March 2019 (UTC)
I didn't said anything about setting values as less preferred. You might want to read up what the preferred rank happens to be within Wikidata. There are many cases where a data-consumer does want a truthy value of what someone's gender is. I consider it to be a resonable expectation for data consumers to treat properties that are tagged with 'single value constraint' as providing reasonable truthy values. Using "transgender female" has the advantage that this is a value that can be truthy while the combination of two labels would mean that only of of them would be returned when a data-consumer asks for a truthy value. ChristianKl12:37, 18 March 2019 (UTC)

Abuse, gender category

The gender property is being used to abuse transgender people by outing them as transgender, or to abuse people who are not transgender by assigning them as transgender. Malign editors are adding "transgender" without any reference to authoritative statements. How do you propose to address this? There is no recourse at the moment for people to remove such abusive categorisation.--Esterazy (talk) 16:04, 22 March 2019 (UTC)

@Esterazy: They can be summarily removed if they are unreferenced - see Wikidata:Living people. Contact an administrator if a user is systematically causing harm. ArthurPSmith (talk) 17:09, 22 March 2019 (UTC)

I wonder whether artistic creation (Q47407603) and artistic creation (Q29586009) should be merged. - The former refers to the "process during which a work of art comes into being", while the latter is defined as "economic activity involving the creation of artistic works". Any thoughts? --Beat Estermann (talk) 07:54, 11 March 2019 (UTC)

@Valentina.Anitnelav, Andrawaag: who created these artistic items. Multichill (talk) 16:57, 11 March 2019 (UTC)
I'm not sure if I fully understand the scope of artistic creation (Q29586009), but according to the description and a catalog code (P528) for the Statistical Classification of Economic Activities in the European Community, Rev. 2 (2008) (Q732298) artistic creation (Q29586009) represents artistic creation as an economic activity, which is not the case with artistic creation (Q47407603) which also includes notions of artistic creation outside the economical system (e.g. as a self-sufficient activity). I think it is safe to say that artistic creation (Q29586009) is a subclass of artistic creation (Q47407603). - Valentina.Anitnelav (talk)
That is a good question. Although related I would argue that both terms are distinct enough from each other to stay separate, as much as Apple can be refering to a fruit or a computer. artistic creation (Q29586009) is a term from a vocabulary of economic activities use to meassure economic activity with a country. --Andrawaag (talk) 21:57, 11 March 2019 (UTC)
@Valentina.Anitnelav, Andrawaag: Ok, I've followed Valentina's argument and have defined artistic creation (Q29586009) as subclass of artistic creation (Q47407603) (and of "economic activity"). Cheers, --Beat Estermann (talk) 14:04, 18 March 2019 (UTC)

Best place to discuss schema?

I have some potentially-elaborate questions concerning the way we represent things such as:

  • time zones, especially "this entity is in this time zone during part of the year (and this other one during another)"
  • qualified geographic coordinates, such as "coordinates of geographic center" and "coordinates of river mouth"

(But don't answer these yet; I already know the easy answers.)

Is this the right place to discuss things like those, or is there some other forum dedicated to the schema? (And when I say "schema", do I really mean "ontology"?) Scs (talk) 03:26, 13 March 2019 (UTC)

Traditionally, discussions happen on the talk pages for particular properties. I don't think this tradition is that great, from the point of view of sustained documentation, and building on the data modelling work that goes on. You can start a discussion in that way, and ping people who you think would be interested. Or you can just use user talk pages. Or you can try a general forum, or a WikiProject talk. To move things on, you may need a few attempts. Charles Matthews (talk) 11:39, 13 March 2019 (UTC)
We got WikiProject Ontology and Help:modeling was an attempt to centralize or give an entry points to all such discussions. author  TomT0m / talk page 11:50, 13 March 2019 (UTC)
Eventually there should be a consensus that a detailed "manual of style" is really needed. Right now people tend to adopt what they see as good practice on items. That's the wiki way, emergence of norms because they make sense. I'm more interested in biography than geography, but these are areas with millions of items. I think the community here should move ahead from single properties and try to develop a manual. This and referencing are the fundamental issues on content. Charles Matthews (talk) 16:59, 13 March 2019 (UTC)
@Scs, Charles Matthews, TomT0m: Note Wikidata:WikiProject ShEx is working on implementing a type of schema definition language within Wikidata - this project is in testing now, and you probably should try it out and give the developers some feedback! ArthurPSmith (talk) 17:21, 14 March 2019 (UTC)
Mmmm, I rather imagined that "shape expressions" were there to extend constraints for properties. Perhaps I misjudged them. Charles Matthews (talk) 17:57, 14 March 2019 (UTC)
I think we have attempted to use property constraints to define reasonable schemas in the past, but this is a more direct approach. ArthurPSmith (talk) 14:24, 15 March 2019 (UTC)
In the past I have repeatedly asked to explain the reasons behind a schema that is largely opaque. I have often questioned all kinds of arbitrariness and the only result has been silence. Making for stronger restrictions is not acceptable because it means that you insist to move away from the Wiki way.
As long as there is no time taken to explain what in my views is hardly any relevance. I am flat against any increased restrictions. Thanks, GerardM (talk) 16:39, 16 March 2019 (UTC)
Thanks for all those answers. I appreciate what Charles Matthews said about "emergence of norms because they make sense"; I guess I didn't realize wikidata was still that fluid.
For the sake of the discussion, I'll flesh out my (now three) hypothetical questions slightly:
  1. Some entities (e.g. Cambridge (Q49111)) are located in time zone (P421) with a numeric value such as UTC−05:00 (Q5390) (or often two, qualified by valid in period (P1264) standard time (Q1777301) or daylight saving time (Q36669)). Some entities (e.g. Boston (Q100)) link to named timezones like Eastern Time Zone (Q941023). Some entities link to entities for IANA timezones like America/New_York (Q28146035). Some entities (e.g. Italy (Q38)) do more than one of the above. What's the right way?
  2. Some entities use property coordinate location (P625) to associate more than one geographical coordinate. For example, rivers (e.g. Charles River (Q794927)) often have two, qualified by applies to part (P518) river source (Q7376362) and river mouth (Q1233637). But on the other hand, there's property coordinates of geographic center (P5140). Why does it exist? Why not use plain P625 with a qualification, just like river sources and mouths?
  3. Many cities are instance of (P31) city (Q515). But many others are instances of narrower classes, like city in the United States (Q1093829). (And of course city in the United States (Q1093829) is a subclass of (P279) city (Q515).) But should all cities explicitly be plain city (Q515)s (to make it easier for people writing queries for things like "all cities with population greater than 123456")? Or do people writing queries always have to worry about subclasses?
These are the sort of questions that (a) I'd hope one day anyone could answer by reading a nice document describing the wikidata schema, or if not (b) I was wondering where one ought to ask about them. (For now I guess I'll ask them here, albeit in new threads below.) Scs (talk) 17:10, 16 March 2019 (UTC)
On the last one: despite the similarity of names, city (Q515) and city in the United States (Q1093829) are quite different sorts of things. Q515 means a larger urban agglomeration, the usual meaning of "city". Q1093829 means an entity in the U.S. that is officially a "city", which is a form of administrative unit in the U.S. (which differs a bit from state to state). Some of these Q1093829 "cities" are quite small, even populations under 1000, so the are by no means Q515 cities. Conversely, to stick to a U.S. example, city in the United States (Q1093829) has a population of 43,713 but is a village of New York (Q55237813), a New-York-State-specific designation for a different form of administrative unit, even though it dwarfs many Q1093829 cities. - Jmabel (talk) 03:04, 17 March 2019 (UTC)
@Jmabel: Thanks for the reminder that terms like "city" mean different things to different people. That wasn't really my question, though -- my question would have remaind the same if I'd been asking about finding instances of, say, human settlement (Q486972). And I've since learned that the answer is basically "Yes, Wikidata type-class entities are typically deeply nested, but that's okay, because everyone knows to write their ordinary is-a queries using wdt:P31/wdt:P279*." Scs (talk) 14:57, 22 March 2019 (UTC)
@Scs: On time zones - all the items you list are instances of (instance of (P31)) time zone (Q12143) either directly or indirectly (via time zone named for a UTC offset (Q17272482) which is a subclass (subclass of (P279)) of time zone (Q12143). The values allowed for a property like located in time zone (P421) are specified in its property constraints - you will notice there is a "value type constraint" that specifies the values must be instances of time zone (Q12143). This is common across Wikidata properties - to the extent we can, we attempt to document the way properties should be used via their constraints. Similarly, the shape expressions I mentioned would be a way to improve documentation of items (within a specific class of items) to show what properties they should have, etc. ArthurPSmith (talk) 14:15, 18 March 2019 (UTC)
@ArthurPSmith: Thanks, although that much, at least, I'd figured out already. See link to further discussion just below. Scs (talk) 14:57, 22 March 2019 (UTC)
Thanks again for the various replies. For now, the only big new thread I'm starting on any of this is on time zones, at Property talk:P421. Scs (talk) 14:57, 22 March 2019 (UTC)

Rank for fictitious authors listed alongside actual authors of a paper

At The Morphology of Steve (Q50422077), there is some disagreement whether only the 3 actual authors should have normal or preferred rank in author (P50) and the others deprecated rank.

The reference for this was added https://www.wikidata.org/w/index.php?title=Q50422077&diff=859685070&oldid=859683269 but deleted by some user. --- Jura 09:42, 16 March 2019 (UTC)

WikiProject Books has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. pinging project --- Jura 09:45, 16 March 2019 (UTC)

Why have you repeatedly marked the named, cited, editors as deprecated? some user; Talk to some user 14:52, 16 March 2019 (UTC)
This sounds like a technicality in how "author" is defined: the names listed on the article, or the people who actually wrote it? They will almost always be the same, or at least assumed to be the same for lack of other evidence. Ghouston (talk) 22:08, 16 March 2019 (UTC)
I suppose a relatively common situation would be ghostwriter (Q623386) or some kind of fraud in publishing somebody else's text. Ghouston (talk) 22:16, 16 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── If the named authors were not consulted, then qualifiyng with a "has role"-"unconsulted author" may be appropriate; deprecation - and especially deprecation with no reason as a qualifier - is not. This has nothing to do with ghostwriting. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 17 March 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

I think we agree that an author can be added, even if not stated on the publication, if there's a reliable reference that says they were an author. So it's consistent to also say that authors can be removed if there's a reliable reference that says they didn't contribute to it in any way, at least in cases like this where's there's no dispute. If you were generating a list of works for one of those fake authors, it doesn't seem right to include this article. Ghouston (talk) 23:05, 17 March 2019 (UTC)
No, that's not consistent; not what was proposed (the issue was around improper deprecation, not removal); and not something we agree on. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:21, 18 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── There is nothing on Help:Ranking that supports removing such data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 18 March 2019 (UTC)

Where I said removal, I'd support deprecation as a better alternative, and maybe a new reason for deprecation. Ghouston (talk) 22:32, 18 March 2019 (UTC)

Importing UIDs for people, from Wikispecies

The page I have just at species:Wikispecies:Biographies with no identifiers contains a Wikidata query which returns a list of people with a Wikispecies biography, but with no UIDs (VIAF, ISNI, ORCID, IPNI, Zoobank, etc) on Wikidata.

There are currently 20,183 people in the list! Some of them, such as species:A. Murdoch, have an ID (Zoobank, in this case) as part of links in the Wikispecies article text. These are often not templated (as in Murdoch's page), or use a template which is ambiguously used for both people and works, such as species:Template:ZooBank, where we have two or more ID properties (e.g. ZooBank author ID (P2006)/ZooBank publication ID (P2007), so the HarvestTemplates tool cannot be used).

Can anyone help with automating the importing of such values? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 16 March 2019 (UTC)

You can harvest in demo mode, download the data and then process it further using other tools such as PetScan and PagePile. Thierry Caro (talk) 20:28, 16 March 2019 (UTC)
Thank you. That's useful tip, but turns out to have a very small return. It seems the vast majority of such IDs are not in templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 16 March 2019 (UTC)
Can anyone assist? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 22 March 2019 (UTC)

MESH ID should be split?

--Vladimir Alexiev (talk) 13:43, 17 March 2019 (UTC)

I agree with this, basically. But when it comes to "absolutely no need to scrape it", then I disagree. I can see use cases for having the information on Wikidata (which of course motivates the proposal, filed under "authority control" even though it is not directly about an identifier). One that I didn't mention on the proposal page relates to the WikiJournal, and some good kind of "hovercard" (see mw:Page Previews) for it involving MeSH. Charles Matthews (talk) 06:48, 18 March 2019 (UTC)

Why does the second complex constraint does not yield any results? If I run the query on the talk page, I get 12000 results. 129.13.72.197 08:15, 18 March 2019 (UTC)

I think it was because the query was returning more than one field named "item". I've changed it from "SELECT ?item ?itemLabel WHERE {" to "SELECT DISTINCT ?item{" in order to match the first constraint. Hopefully it will pick it up in the next run through. *shrug* ElanHR (talk) 01:00, 20 March 2019 (UTC)
Ok, thanks, lets see.... 129.13.72.197 09:19, 20 March 2019 (UTC)
Looks like that was the issue! :) ElanHR (talk) 06:25, 23 March 2019 (UTC)

Washout of dam and bridge by Niobrara river

Any Nebraskans here? I tried to start making some sense of the flooding occurring from the Spencer dam blowout like my edit here U.S. Route 281 (Q2175059). How can an interstate blockage be modelled? Thx. Jane023 (talk) 09:13, 18 March 2019 (UTC)

@Jane023: Try significant event (P793) with point in time (P585). Snipre (talk) 10:53, 18 March 2019 (UTC)
Sorry, I think the best is
Snipre (talk) 11:05, 18 March 2019 (UTC)
Thanks - I ended up making a WP article for Spencer Dam (Q34942691) since it was done on dewiki through cebwiki (see? Cebuano wiki is good for these things!). I suppose the significant event on the interstate can be linked to the bridge that is gone (some memorial highway, can't find it though). What amess. Turns out the dam was scheduled to be decommissioned. Jane023 (talk) 11:58, 18 March 2019 (UTC)

Open Company Data Donation

As a side effect of one of my commercial projects I have curated a dataset of companies which I would like to donate. I started to build a company search engine (work in progress), but it might do more good for more people here at wikidata. Some of the columns which could be suitable for wikidata are  : company name, company HQ address, founding date, number of employees(bracketed 1-50 50-200 ... 1000+ ) , gov business legal entity ID, founder names, list of references to the company in the news (not all of this data is visible in the search engine at the moment).

The data I derive from multiple sources: the homepage of the company, gov data repositories like companies house, and news written about a company and in some cases directly submitted or verified by the company owner.

I have >3million companies currently but we will probably want to filter it to only those with doubly verified information.

Rubenwolff (talk)Rubenwolff

@ChristianKl: Not sure what kind of permissions this bot would need but I went ahead and named it Wikidata:Requests for permissions/Bot/CoRepoBot Rubenwolff (talk) 16:28, 18 March 2019 (UTC)

Calabi–Yau threefolds in $${\mathbb {P}}^6$$ P 6

The title of the item at first glance looks like some sort of vandalism, however Calabi–Yau threefolds in ℙ⁶ (Q59472728) is absolutely legit but our quickstatments bot is not math-friendly it seems. See the original scientific article. Is it serious enough to file an issue ? Kpjas (talk) 12:42, 18 March 2019 (UTC)

Both labels and titles are supposed to be unicode and not math-ml or wikitext formatted. It's the problem of the person who enters data to provide it in unicode and not quickstatements to do that conversion. ℙ⁶ is well supported by unicode. ChristianKl13:06, 18 March 2019 (UTC)
@ChristianKl: but mass importers rarely review what lands eventually in WD items, do they ? Kpjas (talk) 13:33, 18 March 2019 (UTC)
@Sohmen: Can you see that in future the data you enter is unicode? ChristianKl15:52, 18 March 2019 (UTC)
I used SourceMD to enter the article which only lets you enter DOIs. I filed an issue for this at the SourceMD repository. --Sohmen (talk) 15:31, 21 March 2019 (UTC)

Wikidata weekly summary #356

Removing mandatory constraints when data quality is low?

As I just got into a little edit war at Common Database on Designated Areas ID (P4762) with @Abián: and @Sjoerddebruin: - do we now remove mandatory contraints simply because our data does not match them? In this case there are currently 2000+ items which lack the second identifier which they have, we "only" need to fix our data to make that constraint covered again. In this case, it is just one week now that @GPSLeo: added the only one identifier, so this I would consider this "work in progress" (see the history of Wikidata:Database reports/Constraint violations/P4762). And even if there really were so many violations for months/years - hiding the fact that our data is incomplete will not solve the problem! Only if they show prominently, someone will choose to work on them. 16:48, 18 March 2019 (UTC)  – The preceding unsigned comment was added by Ahoerstemeier (talk • contribs) at 17:48, 18 March 2019‎ (UTC).

Can't you just make it "non-mandatory"? I would think "mandatory" implies it needs immediate fixing (within hours). If it's not that urgent, it shouldn't be marked mandatory. ArthurPSmith (talk) 17:48, 18 March 2019 (UTC)
@Ahoerstemeier: don't edit war. A constraint that has 2172 constraint violations shouldn't be marked as mandatory. Solution is quite simple. You clean up the constraints so the number is zero and you add the mandatory constraint again. Everyone will be happy. Multichill (talk) 18:19, 18 March 2019 (UTC)
Great, put the work and blame on the messenger. So what we need is a new constraint type "could be mandatory once someone cleans up the data". 11:35, 19 March 2019 (UTC)
No, we don't. Matěj Suchánek (talk) 18:39, 19 March 2019 (UTC)
There are three cases: A constraint which has some exceptions in the real world already, a constraint which has zero violations in the real world but many here due to lack of maintenance , and a constraint which has no violations here. But OK, I see nobody cares about how to improve the data, removing the warnings is a solution for most it seems. Ahoerstemeier (talk) 09:55, 20 March 2019 (UTC)
It's still a constraint and violations are highlighted immediately in the UI. Once the current violations have been addressed it would be fine to make it 'mandatory' again. Leave a note on the talk page as a reminder so anybody can fix it at the right time. ArthurPSmith (talk) 17:43, 20 March 2019 (UTC)

OCLC Control number (P243)

Currently this is an instance of Wikidata property to identify books. Can this be changed to be an instance of Wikidata property for an identifier?

(OCLC includes many more items than books, including all forms of published and manuscript material, realia, even service dogs.) It would be good to have this property to describe non-book items.  – The preceding unsigned comment was added by 128.103.224.4 (talk • contribs) at 16:01, 19 March 2019‎ (UTC).

Changed instead to Wikidata property for authority control for works (Q19833377). Do you have examples of other classes of items that are represented in Wikidata and have OCLC iDs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 20 March 2019 (UTC)

When a Wikipedia article is cited

I have found a peer-reviewed academic article, refereed paper Birmingham's new dental school and hospital - A real Peter Pan of dentistry. (Q62116481), that cites a Wikipedia article. How can this be modelled, given that the subject of the equivalent Wikidata item is not what is cited? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 20 March 2019 (UTC)

Sounds like another item about the Wikipedia article is needed :) ArthurPSmith (talk) 14:41, 20 March 2019 (UTC)
It would be a Wikimedia article page (Q15138389). Showing that the current practice of linking Wikipedia articles as sitelinks isn't sufficient to describe them to Wikidata standards? Ghouston (talk) 21:33, 20 March 2019 (UTC)
Good question. Citing the language edition item e.g. English Wikipedia (Q328) and using something like section, verse, paragraph, or clause (P958), title (P1476) or URL (P2699) as a qualifier could work. Do we have a way to model the citation of a work in a Wikipedia article? Simon Cobb (User:Sic19 ; talk page) 22:33, 20 March 2019 (UTC)
That seems sufficient for referencing. Otherwise, creating items for Wikipedia articles, the next thing you'd want is items for all its authors ... at least it would be more easily automated than for the academic journal articles :P Ghouston (talk) 11:24, 21 March 2019 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

I've done this, for now. I'm not convinced it's the optimal solution. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:26, 22 March 2019 (UTC)

elemento fusionado o borrado?

No se pudo guardar debido a un error. The save has failed. El enlace del sitio svwiki:Ahmad Yamani ya es usado por el elemento Q6248873. ¿Quizás el elemento se debe fusionó y/o borrado? No dude en preguntar en el "Project chat" si no está seguro.  – The preceding unsigned comment was added by Hayateouamioubalhi (talk • contribs) at 14:28, 20 March 2019‎ (UTC).

Translation (punctuation is weird, so it's hard to tell what part of this is the quoted error message)
Title: element merged or erased?
Could not be saved due to an error, "The save has failed. The sitelink svwiki:Ahmad Yamani is already used for element Ahmad Yamani (Q6248873). Perhaps the item ought to be merged and/or erased. Don't hesitate to ask at 'Project chat' if you are not sure." - Jmabel (talk) 16:34, 20 March 2019 (UTC)
Nothing here indicates what the user was trying to save. - Jmabel (talk) 16:34, 20 March 2019 (UTC)

Revision-deletion policy

Do we have a policy on revision deletion? If not, what should we follow? I somehow thought we had one, but I could not find any.--Ymblanter (talk) 20:41, 20 March 2019 (UTC)

Wikidata:Deletion policy#Revision deletionMisterSynergy (talk) 20:43, 20 March 2019 (UTC)
Great, thanks.--Ymblanter (talk) 20:46, 20 March 2019 (UTC)

Google Knowledge Graph issues

Hello! One reader of Slovak Wikipedia posed a question on why there are two persons (both of them having their Wikidata entry) who do not have date of death in Google Knowledge Graph (one of them was shown as 150 years old). However, date of death is included in their Wikidata entry. I just want to make sure there is no issue on our (Wikidata’s) part. Any further info (e.g. links) about Wikidata–Google Knowledge Graph relation are welcomed.--Lišiak (talk) 14:01, 21 March 2019 (UTC)

@Lišiak: Which two people have this issue? Jc86035 (talk) 14:10, 21 March 2019 (UTC)
@Jc86035: Q1027978, Q12035527.--Lišiak (talk) 14:18, 21 March 2019 (UTC)
Google makes their own decisions about what to sync and you shouldn't expect that everything gets synced automatically. Neither of the two has a reference for the claim about their date of death, which means it's not trustworthy data and it makes sense when it doesn't get picked up by the Google Knowledge Graph. ChristianKl17:14, 21 March 2019 (UTC)
@ChristianKl: Actually, Q12035527 has reference for his date of death, but I understand it is problem on Google's part and we are in the clear. I will try to find references for Q1027978, though. Thank you!--Lišiak (talk) 17:55, 21 March 2019 (UTC)
  • I noticed it a few weeks ago, a bug by Google, they had 150 year old and I added the birth and death date at the same time here in Wikidata. --RAN (talk) 12:55, 22 March 2019 (UTC)
  • So it's not just me that noticed that someone who has a death date on Wikidata doesn't have it on their Google Knowledge Graph even though they have a death date in Wikidata and Google Knowledge Graph has the birth date. — Jeluang Terluang (talk) 09:24, 23 March 2019 (UTC)

time zones

If you're interested in time zones and the way property located in time zone (P421) is used, I have started a discussion at Property talk:P421. (This is, again, the question of whether it's preferable to use time zones named for a UTC offset (Q17272482), named time zones such as Q941023, IANA time zones (Q17272692), or some combination.) Scs (talk) 10:20, 23 March 2019 (UTC)

A minor enigma

Hello. Man with Guitar (Q60300562) is a wedding gift (Q60965053) by Pablo Picasso (Q5593) to Guillaume Apollinaire (Q133855). How can I store this? The question comes from the Bistro. Maybe, I'm not sure, we can have significant event (P793)change of ownership (Q14903979) with object has role (P3831)wedding gift (Q60965053) and donated by (P1028)Pablo Picasso (Q5593) as qualifiers but I'm then left without knowing how to store Guillaume Apollinaire (Q133855) under that very same property. Should this be split under two totally different statements? Do we need a 'transatcion type' property? Thierry Caro (talk) 03:33, 19 March 2019 (UTC)

I like what you propose here. You could add a qualfer “owned by” to the change of ownership. - PKM (talk) 20:22, 20 March 2019 (UTC)
Yes. But the use of owned by (P127) under change of ownership (Q14903979) remains quite confusing, obviously. It may mean either the former owner or the new one, in my example either Picasso or Apollinaire. Of course, used together with donated by (P1028) set to Picasso, it becomes clearer that if owned by (P127) is set to Apollinaire, this guy must be the new owner, but still. Thierry Caro (talk) 20:20, 21 March 2019 (UTC)
@Thierry Caro: To me the actual enigma seems to be that so many people would use the vague significant event (P793) when there are dedicated properties ;). Ownerships (and their changes) are recorded through owned by (P127), so it's just a question of finding an appropriate qualifier. Why not use subject has role (P2868), it seems fine to me. Granted, that property's french label is somewhat odd here, but it just means "en tant que" applied to the subject of the claim. And that sounds quite right in conjunction with donated by (P1028). What do you think? --Nono314 (talk) 20:41, 22 March 2019 (UTC)
We would then have owned by (P127)Guillaume Apollinaire (Q133855) with donated by (P1028)Pablo Picasso (Q5593) as a qualifier. And what you are suggesting is subject has role (P2868)wedding gift (Q60965053) as another qualifier, right? Well, it is understandable to a human, but strictly speaking, isn't this saying that Guillaume Apollinaire (Q133855) (or that the fact that he is the owner), not the painting itself, is the wedding gift? This is a bit unclear to me. Thierry Caro (talk) 22:39, 22 March 2019 (UTC)
No, we have subject has role (P2868) applying to the subject of the claim and object has role (P3831) to the object. So if you use the former it is unambiguously about Man with Guitar (Q60300562) while the latter would be about Guillaume Apollinaire (Q133855). It is actually clear semantically speaking for machines, only humans may be distracted by the awkward wording. I think the english labels and descriptions for the properties make it very clear, but in french it is much less clear if not misleading as the subject is not always acting.--Nono314 (talk) 14:43, 23 March 2019 (UTC)
OK. Thank you. We've then found a solution and I have tried a better wording for both subject has role (P2868) and object has role (P3831) French labels. Thierry Caro (talk) 12:17, 24 March 2019 (UTC)

WORK IN PROGRESS

THIS IS THE PROJECT PAGE FOR A PROJECT CALLED WORK IN PROGRESS

"Work in Progress" is an ebook by Cliff Holden (published as a pdf file) ...

It was first printed and bound by the author on 7th March 1999.

A printed copy was presented to the Tate Archives in 2004.

Subsequently it was proofread and reformatted in 2011 by one of Cliff Holden's students.

The text may also be found on the author's website ...

http://www.cliffholden.co.uk

However it is the version dating from work done in 2011 which provides the starting point for this project.

https://upload.wikimedia.org/wikipedia/commons/c/c2/WORK_IN_PROGRESS_-_CliffHolden_-_07.03.1999.pdf

Wikidata:Project_chat#WORK_IN_PROGRESS

Bughub (talk) 16:19, 22 March 2019 (UTC)

@Bughub: It's not clear what you're asking here, please clarify Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 22 March 2019 (UTC)
@Pigsonthewing: Hello Andy ! (User:Pigsonthewing) Is this the correct way to reach you ? My name is Douglas Westbury (User:Bughub) ... I am glad you have asked me to clarify what I am asking for because I am new to this kind of work ... and I am trying to learn the rules as quick as I can ... However whatever the rules may be ... I can assure you I am not in breach of copyright ... I have been working on this article offline with the author Cliff Holden for over twenty years ! Bughub (talk) 16:17, 22 March 2019 (UTC)
@Pigsonthewing: Hello Andy ! I am writing here to update you on changes I have been making ... but I have to confess I am still out of my depth ... so any help you can give me would really be appreciated ... I have written to "Permissions - Wikimedia Commons" (permissions-commons@wikimedia.org) concerning the permission information for the file I uploaded (https://upload.wikimedia.org/wikipedia/commons/c/c2/WORK_IN_PROGRESS_-_CliffHolden_-_07.03.1999.pdf) and I have a ticket [Ticket#2019032210007545] Bughub (talk) 19:07, 22 March 2019 (UTC)
@Pigsonthewing: At present the file is subject to speedy deletion unless it is relicensed according to the Commons licensing policy. Bughub (talk) 19:07, 22 March 2019 (UTC)
@Pigsonthewing: "This media file is missing evidence of permission. It may have an author and a source, but there is no proof that the author agreed to license the file under the given license." So my question is this : Can I relicense the file under the Creative Commons CC0 ? Will that make the problem go away ??? Bughub (talk) 19:07, 22 March 2019 (UTC)
Convenience link: File:WORK IN PROGRESS - CliffHolden - 07.03.1999.pdf. - Jmabel (talk) 20:04, 22 March 2019 (UTC)
No, claiming to offer a different license will not solve the problem. The issue is that if Cliff Holden is the author and copyright holder, then only Cliff Holden can offer such a license, and there is no evidence that Cliff Holden has offered such a license. - Jmabel (talk) 20:06, 22 March 2019 (UTC)
@Jmabel:I am trying to establish that this work is in the public domain
I do really think it is up to someone else to step forward and challenge me on this
Putting the interests of the overall wikipedia project to one side for a moment ...
I will certainly continue to disseminate and discuss this material ...
I will certainly continue to pay myself for the printing of the book and give it away freely to whomever I choose ... for them to use in any way they wish !!!
If I wanted to I believe I would be quite within my rights ... (whatever rights they might be) ... to ASSERT MY OWN CLAIM TO AUTHORSHIP HERE (all be it as a claim to "joint authorship" for myself together with Cliff Holden)
I would be prepared to do that if it solved the problem
But I don't want to
It was always understood between Cliff Holden and myself that the name of the author should be given as Cliff Holden (and that the book would be in the public domain)
So when I am asked to provide evidence that the "author or copyright holder" has "agreed to license the file under the given license" ... I don't think you really have any understanding of what it is you are asking for ...
Do you think anyone else knows more about this than I do ?
Then let them come forward and challenge me
Until then I will take it as an established fact that the licensing of the uploaded file should be as follows ...
Creative Commons license name : Zero Public Domain, "No Rights Reserved"
Abbreviation : CC0
The very last line of the first page of the document states quite clearly "copyright © CLIFF HOLDEN 2011". That's not "in the public domain". But discusison of copyright should take place on Wikimedia Commons, not here, on Wikidata, as it is there where the decision on its future will be made. It is still not clear what you are asking for here on Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 22 March 2019 (UTC)
Thank you Andy Mabbett ! It is so nice to hear that someone has actually opened the file and read the first page (by the way ... I should know what it says since I wrote it) Perhaps you would like to explain to me (somewhere else ... in some other thread) what you think Wikidata is for ?
WORK IN PROGRESS is a digital arts project initiated by User:Bughub
https://www.wikidata.org/wiki/Wikidata_talk:Project_chat#WORK_IN_PROGRESS
Bughub (talk) 21:32, 23 March 2019 (UTC)

Disambiguation

PROBLEMS ARISING FROM THE TITLE OF THE TEXT

It occurs to me that there may be some confusion caused by the name of the project "Work in Progress" ...

This is the title of the text "Work in Progress" (2011 ed.) [16]" written by Cliff Holden (1999).

https://en.wikipedia.org/wiki/Work_in_Progress_(disambiguation)

Bughub (talk) 22:03, 23 March 2019 (UTC)

Q6517416 and Q61881575

Should nobility of Sweden (Q6517416) and Swedish noble family (Q61881575) be merged? --RAN (talk) 12:52, 22 March 2019 (UTC)

I think they serve two (slightly) different purposes: social classification = nobility of Sweden (Q6517416), while family = some Swedish noble family (Q61881575). At least that's how I've seen it being used. Moebeus (talk) 16:07, 22 March 2019 (UTC)

Thanks! Yes, a bit confusing, but not as confusing as historic Swedish name places for parishes, villages, and farms, and other divisions, all with the sane name, all corresponding roughly to the same area, all at different times. --RAN (talk) 15:03, 24 March 2019 (UTC)

What to do if the same edition has multiple ISBNs?

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

Some books have an ISBN for the printed edition and a different ISBN for the e-book. Others, like FRBR, Before and After: a Look at Our Bibliographic Models (Q56487853), have distinct ISBNs for the PDF, EPUB and Kindle version. In such cases, should I add a qualifier like applies to part (P518)print edition (Q59466300) or applies to part (P518)ebook (Q128093) to each ISBN? There are two issue:

  1. the ISBN-13 (P212) property constraints allow only one ISBN per item and
  2. currently, there aren't items like "PDF version", "EPUB version", etc. Create them is easy but I don't know if this is the best approach.--Malore (talk) 00:53, 20 March 2019 (UTC)
Side note: the "ping" to Wikiproject:Books did not work. There are too many participants, and when the number of participants passes a certain threshold (I do not recall what that threshold actually is), then participants are not notified. You must post in the Project's talk page to guarantee notification. --EncycloPetey (talk) 02:22, 20 March 2019 (UTC)
That threshold is 50 [17]. 129.13.72.197 09:30, 20 March 2019 (UTC)
"constraints allow only one ISBN per item" As I've often said; if the constraints are wrong; fix them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:10, 20 March 2019 (UTC)
I always make separate “version or edition” items for each ISBN/edition/distribution format, although I usually only add the editions I am actually using as references (generally the hardcover and/or ebook, especially when the ebook is online and searchable). - PKM (talk) 20:18, 20 March 2019 (UTC)
@Pigsonthewing:Before fixing the constraints I wanted to be sure there isn't a better approach like creating an item for each version (as PKM pointed out) or using a different property. --Malore (talk) 00:42, 21 March 2019 (UTC)
ISBN's are stock numbers, there are cases with multiple numbers for the same edition, and also more numbers for several editions. you should just list them all at the work item. OCLC number would work better, as a unique identifier. Slowking4 (talk) 15:36, 25 March 2019 (UTC)

Item not fully loaded

"You may have reached this special page because the item you tried to edit wasn't fully loaded for label/description edits to work there."

How do i fix this?  – The preceding unsigned comment was added by Trade (talk • contribs) at 20:35, 22 March 2019‎ (UTC).

Wait till the page is fully loaded. Sjoerd de Bruin (talk) 21:24, 22 March 2019 (UTC)
This have lasted for more than a day. Surely, this can be how it's supposed to work? Trade (talk) 13:32, 24 March 2019 (UTC)
Could be a symptom of some hidden problem. Try appending ?safemode=1 to the URL and see mw:Help:Locating broken scripts. Matěj Suchánek (talk) 19:26, 24 March 2019 (UTC)

Wikidata weekly summary #357

inverse constraint

Hello. I have added inverse constraint (Q21510855) with participant in (P1344) to the property participating team (P1923). I think is correct. But I want also to have the opposite. So I have added inverse constraint (Q21510855) with participating team (P1923) to the property participant in (P1344). But that is not always correct since P1344 can be use for any event, not just for sport events. How to solve that? Xaris333 (talk) 15:54, 25 March 2019 (UTC)

Problems with adding sitelinks

There's a serious issue with adding sitelinks to Wikidata at the moment - it's being tracked on phabricator at phab:T219452. Thanks. Mike Peel (talk) 22:01, 27 March 2019 (UTC)

Yes, I have the same - can not add links from another project nor directly here.--Ymblanter (talk) 22:14, 27 March 2019 (UTC)
Same here! I just created CGCG box (Q62554958) but I can't add the en-Wikiversity link to v:Gene transcriptions/Boxes/CGCGs. --Marshallsumter (talk) 00:32, 28 March 2019 (UTC)
I can't add a Wikipedia link (to my newly created German article de:Christian Gottlieb Lorek) to Q21519496; I suppose that's the same issue... Gestumblindi (talk) 01:48, 28 March 2019 (UTC)
The issue occur this morning permanently. --Derzno (talk) 06:05, 28 March 2019 (UTC)
Thanks for reporting. The issue may be connected to the last Mediawiki deployment. We'll work on it as soon as possible, you can follow the updates in the task. Lea Lacroix (WMDE) (talk) 06:59, 28 March 2019 (UTC)
Small workarround till it works agin. It works if you're blowing into with quickstatements. Use Q....|Scommonswiki|"Category:bla bla bla" --Derzno (talk) 07:09, 28 March 2019 (UTC)
I think my problem (milk glass (Q1543091)) comes from the same origin, I just pressed "publish" and has erased the whole entries--Mcapdevila (talk) 08:27, 28 March 2019 (UTC)
Yes, spotted this last night (about 8pm UK time). Thought it was just me, but still the same this morning. Thanks to everyone who's helping with this. Lugnuts (talk) 08:54, 28 March 2019 (UTC)
It started from yesterday's night and a day later still same problem :( --Armineaghayan (talk) 10:15, 28 March 2019 (UTC)
Works for me now. Thanks Adam, Alaa, and others.--Ymblanter (talk) 10:26, 28 March 2019 (UTC)
The problem should be solved now. Feel free to try again and ping me or comment in the ticket if you encounter any new issue. Lea Lacroix (WMDE) (talk) 10:33, 28 March 2019 (UTC)
Thank you, now it works :) --Armineaghayan (talk) 11:20, 28 March 2019 (UTC)

Wikidata element Q1543091

The software has eliminated 10 entries (in https://www.wikidata.org/wiki/Q1543091) without intention from my part, could someone return it to its primitive status, and just add the catalan entry (Vidre opalí) and the italian entry (Vetro opalino)?

Thanks--Mcapdevila (talk) 08:18, 28 March 2019 (UTC)

Link to Commons

Linking to Commons:Category, or linking from Commons:Category to a Wikidata item doesn't seem to work anymore. See Q2285105 (Dion Graus), and many more. Have I missed an update? Vysotsky (talk) 08:50, 28 March 2019 (UTC)

Please see Wikidata:Project_chat#Problems_with_adding_sitelinks. --M2k~dewiki (talk) 09:13, 28 March 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 08:22, 31 March 2019 (UTC)

WikidataCon application, program submission and scholarship processes are now open

Hello all,

As you may know, the WikidataCon 2019 will take place on October 25th-26th 2019 in Berlin. The conference will host 250 people from the Wikidata community, but also the emerging Wikibase community, as well as partners, organizations and companies the organizations who may be interested in using Wikidata and Wikibase, or contributing in various ways to the evolution of Wikidata. The event will be focused on networking and strategic discussions around Wikidata and Wikibase, with a special focus on languages and Wikidata.

Because the number of seats is limited and in order to make sure that the access to the conference is fair, we decided to set up a selection process. People who wish to attend the conference can now apply by filling in the application form. A committee equally composed of volunteers and staff will evaluate the applications against criteria that are already published onwiki.

This application form aims to gather all of the useful information at once, that’s why it also contains the program submissions (limited to 3 per person) and the scholarship application if needed. You can find more information about the content of the form on this page.

Part of the attendees will be also invited directly by the organizing team, based on the connections we want to build with organizations during this conference, and the input they can bring to Wikidata’s strategy.

The deadline to fill out the application form is April 26th. No application can be considered after this date. Over the following month, the committee will evaluate the applications, and the applicants will receive an answer latest on June 12th.

Here are a few tips to help you prepare your application:

You can find a lot of information regarding the conference on Wikidata:WikidataCon 2019. If you have any question or issue, feel free to share it on the talk page onwiki or to reach the organizing team at info@wikidatacon.org

Finally, feel free to share this message with your local community, networks, or projects you’re working in! We want to make sure that everyone who’s involved in Wikidata or Wikibase has a chance to apply.

We're looking forward to receiving your applications!

Thanks for your attention, Lea Lacroix (WMDE) (talk) 11:24, 26 March 2019 (UTC)

How to model Academic coordinator when publish academic articles

We have a publisher of scientific articles that have a quality process link with peer-to-peer reviews and an Academic coordinator. The Academic coordinator is the person who will coordinate the peer to peer review etc...

Question Any suggestion how to model this? I did a test using affiliation (P1416) / subject has role (P2868) = academic co-ordinator (Q62415224) see link - Salgo60 (talk) 13:36, 26 March 2019 (UTC)

How available is that data? If there's a lot of it it would make sense to have a specialized property. ChristianKl14:39, 26 March 2019 (UTC)
@Fnielsen, Daniel_Mietchen, Egonw: is this a candidate for a Wikidata property? - Salgo60 (talk) 15:21, 26 March 2019 (UTC)

Requiring sibling properties only when the item is an instance of a certain type

So the PCGamingWiki ID (P6337) property has a bunch of violations (database report) caused by a required platform (P400). While this is true when the item in question is an instance of video game (Q7889), if it's a video game controller or something else it doesn't make sense for it to have a platform (P400).

Is it possible to require a platform only in the case where the item is an instance of a video game? I assume it'd be poor practice to have potentially hundreds or thousands of "exceptions" for the constraint. Would it be preferable to split PCGamingWiki ID (P6337) into separate properties for video games vs. companies vs. controllers?

Thanks, Nicereddy (talk) 18:00, 22 March 2019 (UTC)

Maybe a job for Wikidata:WikiProject ShEx? ArthurPSmith (talk) 20:39, 22 March 2019 (UTC)
Why not just make a Complex Constraint? 147.142.76.28 08:18, 24 March 2019 (UTC)

Because I didn't know about Complex Constraints :D It seems like exactly what I want, I just need to figure out the right SPARQL query for it. Thanks! (See also: Template:Complex constraint) Nicereddy (talk) 19:51, 26 March 2019 (UTC)

Phone number for Brexit (Q7888194)

@Manu1400: added a telephone number for Brexit (Q7888194) and a matching constraint exceptions. It seems to me a misuse of the property. ChristianKl18:25, 26 March 2019 (UTC)

I've removed the number, but you should have talked to them before coming here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:16, 26 March 2019 (UTC)

items for box-header and box-footer portal subpages

Just saw that we have at least ~400 items for portal header and footer subpages like Portal:Contents/box-header (Q17434151) and Portal:Japan/box-footer (Q15614596). And pretty much all of them have instance of (P31)Wikimedia portal (Q4663903) statements, along with corresponding descriptions in many languages (probably because they are in the Portal namespace). What would be the correct instance of (P31) statement here, Wikimedia template (Q11266439)? --Kam Solusar (talk) 16:51, 23 March 2019 (UTC)

Yes, though a new, separate item for templates not in template space may be useful here. Circeus (talk) 16:20, 27 March 2019 (UTC)

How to deal with incorrect data on external identifiers?

Sometimes external identifiers have incorrect data, to say nothing of unreliable yet widely indexed websites. As an example, the artist Katherine Porter (Q19276859) (born 1941), is most widely known as simply "Katherine Porter". Her correct middle name appears to be "Pavlis", as she is named "Katherine Pavlis Porter" in several editions of Who's Who in American Art, the cover of Noon Knives (2002), the 1963 Colorado College commencement program (her alma mater), and as suggested in the contact email at her official website. However, some websites and databases give the (probably incorrect) name "Katherine Page Porter", e.g. Skinner Auctions, invaluable.com and even the Getty Union List of Artist Names. The Getty list cites a 2003 query of Askart.com., whose current entry on "Katherine Page Porter" clearly refers to a different person (born 1903). I removed "Katherine Page Porter" from the "Also known as" label, but given that secondary sources have conflated Katherine Page and Katherine Pavlis, and thus perpetuated falsehoods, what's the best way to handle such data, given that "Katherine Page Porter" is now a plausible search term for the artist born 1941, even if incorrect? Is Wikidata a repository of all 'data' regardless of veracity, or is it better than that? -Animalparty (talk) 21:55, 25 March 2019 (UTC)

First, you contact them about their errors. And then, IMO, you don't add it here. Sometimes they create new pages for each entity, sometimes they keep it for one of the entities and create new ones for the others. If it already exists, again IMO, you would either delete it from WD, or at least use the depreciated feature. Lazypub (talk) 22:01, 25 March 2019 (UTC)
Especially if that external source is one which otherwise is considered very credible, or widely used, it might be useful to add the wrong data here, but giving it deprecated rank and a fitting reason for deprecated rank (P2241) qualifier. Ahoerstemeier (talk) 10:43, 26 March 2019 (UTC)
  • One may be a middle_name and the other a maiden_name that just happen to be similar, I have seen this situation before but some research on Familysearch usually cleared up which name was which, she may appear in the 1940 census and that may help clear up what her maiden name was. However, I agree to add it here and deprecate the value. This is the only way to let people know which is correct and which is wrong. If we only present the one we think is correct, when confronted with a different value, people will flip a coin to decide which is more likely to be correct. Of course add the qualifier "stated in" and the evidence you used to judge it more likely correct. See for example the one I just completed at Livingston Farrand (Q6659644) for the "date of birth". --RAN (talk) 17:01, 26 March 2019 (UTC)
It looks like her birth name was "Katherine Louanne Pavlis" according to her birth certificate. --RAN (talk) 18:06, 27 March 2019 (UTC)

Telegram bot

Usage scenario

Inline Telegram bot similar to @wiki, but for Wikidata: https://telegram.me/wkdt_bot.

Usage examples

  • Search for Q-items:

    @wkdt_bot telegram

  • Search for P-items (properties):

    @wkdt_bot -p part of

  • Search for L-items (lexemes):

    @wkdt_bot -l google

-- Luitzen (talk) 07:29, 27 March 2019 (UTC)

Severe problems editing Wikidata

part of a screenshot showing the issue - Andre Engels (talk)

Hoi, I just added an item Q62519158 and, I cannot use it in this form editing a related item. In effect it means that not only does query not work it is now also impossible to reliably edit based on the Q item itself. This means that the usability of Wikidata is severely compromised. Thanks, GerardM (talk) 08:27, 27 March 2019 (UTC)

Hello @GerardM:,
Can you give us more detailed information about what you tried to do? As far as I understand, you created Sigal Lahav Scher (Q62519158), added some statements, and then you wanted to use this item as a value in another item? Which one? What did go wrong? Did you get an error message? Lea Lacroix (WMDE) (talk) 08:52, 27 March 2019 (UTC)
Having the same problem with David Verey (Q62519569). I am trying to add him as spouse in Rosemary Verey (Q2166949), but when I fill in 'Q62519569' as the target there, I get 'No match was found'. - Andre Engels (talk) 08:57, 27 March 2019 (UTC)
There were a few publications I created with a tool. I wanted to link them by hand (tools fail me) and I cannot reply to an ORCID tweet as a result. It seriously sucks. What is the plan? Thanks, GerardM (talk) 09:03, 27 March 2019 (UTC)
What the issue seems to be to this layman's eyes is that new pages are not being added to the search database any more. - Andre Engels (talk) 10:11, 27 March 2019 (UTC)
It seems OK up to Optimisation of quantum dot infrared photodetectors (QDIPs) for imaging applications (Q62518560), but not for p-doped 1.3μm InAs∕GaAs quantum-dot laser with a low threshold current density and high differential efficiency (Q62518561) or later. Ghouston (talk) 10:14, 27 March 2019 (UTC)
The issue seems to have been repaired for new creations, but not yet for the elements previously affected. - Andre Engels (talk) 11:37, 27 March 2019 (UTC)
Per the phab ticket, the catching up is in progress but could take a few days. ·addshore· talk to me! 13:45, 27 March 2019 (UTC)

Q925929 Leroy P. Steele Prize

Could someone remove all the 61 awardees of this award (P166). It allows me to restructure this award in its composite parts. Thanks, GerardM (talk) 18:26, 19 March 2019 (UTC)

When I know how to do it automagically I will do it myself but I will not make a bigger mess by introducing all the versions of the Steele Prize.. Thanks, GerardM (talk) 13:13, 28 March 2019 (UTC)

A lot of partners

A question asked on frwiki : there is a lot of (work) partners (partner in business or sport (P1327) View with SQID) for this person. It seems there are two kinds of collaborations involved, apparently (two fields of work), and there is a grouping/filtering according to some field of work value for the partnership. Is there a known solution on Wikidata to help build this, like using field of work (P101) View with SQID as a qualifier ? Or the opposite, to qualify « field of work » with the partners

⟨ Herbert ⟩ field of work (P101) View with SQID ⟨ Tennis ⟩
partner in business or sport (P1327) View with SQID ⟨ Mahut ⟩
partner in business or sport (P1327) View with SQID ⟨  ⟩

(maybe not the right one since each partnership can have a begin and end date)

PS: do we have a dedicated wikiproject for this kind of question ? I found the obsolete WD:WikiProject Infoboxes/persons and Wikidata:WikiProject Biographies which is not a fit either (redirect to an identifier project). author  TomT0m / talk page 18:37, 27 March 2019 (UTC)

(it seems that actually there is some usage for this qualifier :
select distinct ?prop ?qualifier ?qualifierLabel {
  ?prop a wikibase:Property 
          ; wikibase:claim ?stProp
          .
  []    ?stProp [?qual []]
        .
  ?qual ^wikibase:qualifier ?qualifier .
  
  values ?stProp { p:P1327 }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!
) — created a template to query the qualifiers used to qualify statements used with a property, {{Qualifier used for}} author  TomT0m / talk page 19:56, 27 March 2019 (UTC)

Any efforts on making some more advanced query-generator for wikidata?

Hi everybody,

the standard-query-builder (query.wikidata.org) is great thing to begin exploring Wikidata. Are there any projects for a more advanced query-bulder, where one can expand edges/relations and filter values (property x > some value) without knowledge of the query language?

Cheers, Datawiki30 (talk) 21:21, 27 March 2019 (UTC)

Hello,
Yes, it is in the roadmap of the development team for this year. Lea Lacroix (WMDE) (talk) 09:28, 28 March 2019 (UTC)

Help on operating system constraint

I need help on the property constraint for operating system (P306). It should allow either instances or subclasses of operating system (Q9135), but should also allow the specific value cross-platform (Q174666). Daask (talk) 17:09, 26 March 2019 (UTC)

I think cross-platform (Q174666) relates to platform (P400), not to operating system (P306). Ghouston (talk) 10:46, 27 March 2019 (UTC)
operating system (P306) is really a more specific use case of platform (P400), and cross-platform (Q174666) is entirely appropriate for it too (indeed the wikipedia articles about computing platforms explicitly include operating systems in this context). Circeus (talk) 16:14, 27 March 2019 (UTC)
Of course operating systems are generally designed to be platforms, but I don't think there's anything to be gained by mixing operating system (P306) and platform (P400) on items about software. It just makes it harder to enter the data and query it. I think it's more consistent to use platform (P400) on items about software and operating system (P306) on items about devices. On items like Minecraft (Q49740), the platforms are a mixture of operating systems and games consoles, and splitting the operating systems into a different statement wouldn't be helpful. Ghouston (talk) 01:30, 28 March 2019 (UTC)
Isn’t it smarter to list the different supported platforms ? cross-platform (Q174666) is meaningless and can mean something between « several gaming platform » to « a platform like java who can run on multiple OSes ». author  TomT0m / talk page 12:07, 28 March 2019 (UTC)
Yeah, I agree. But put them all in platform (P400). Ghouston (talk) 21:27, 28 March 2019 (UTC)
I've proposed this now at Property_talk:P306#Restrict_to_devices. Ghouston (talk) 22:01, 28 March 2019 (UTC)

Awards not accepted

Do we record awards not accepted? (using award received (P166) or otherwise)

eg Yeshayahu Leibowitz (Q215927) and en:Yeshayahu_Leibowitz#Awards_and_recognition. Jheald (talk) 21:20, 28 March 2019 (UTC)

There was something about that at Wikidata:Project_chat/Archive/2018/08#Awards refused or returned, although not much discussion. Ghouston (talk) 22:12, 28 March 2019 (UTC)

Incorrect Wikisource links

We have a number of items with links to Wikisource, for example:

which link to works about the subject of the item, not to an equivalent Author: namespace page.

How can we fix this? And how can we use an edit filter or similar to prevent recurrence? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:46, 18 March 2019 (UTC)

Fix by moving the Wikisource link to described by source (P1343)? Ghouston (talk) 22:08, 18 March 2019 (UTC)
and optionally create an article like Elliott, Stephen (Q28032076), although it seems like overkill for a one-paragraph encyclopedia article. Ghouston (talk) 22:53, 18 March 2019 (UTC)
You'd need to create the data item regardless in order to use described by source (P1343). Beleg Tâl (talk) 23:07, 18 March 2019 (UTC)
Not necessarily, Albigence Waldo Cary (Q18819010) already has such a statement that just links to Appletons' Cyclopædia of American Biography (Q12912667). Ghouston (talk) 00:03, 19 March 2019 (UTC)
Can described by source (P1343) have a URL qualifier? There's also described at URL (P973). Ghouston (talk) 00:09, 19 March 2019 (UTC)
@Ghouston: Albigence Waldo Cary (Q18819010) is set up incorrectly. The link to Wikisource is to a biographical article which will have its own publication data that need to be included. The person who is the subject of the article will not have publication data. So you cannot add a Wikisource link that way. It may seem like "overkill" to you, but unless the full information for the citation of the article is included, then citation data for the article cannot be pulled from the data item. See for example DGRBM-1870 / Oedipus (Q47507582), which contains full publication data allowing the linked article to be cited, by using the data in the corresponding data item. With all the publication data available in the data item, a Wikipedian wishing to cite the article could use a tool to generate the citation, without having to manually retype all of the data. --EncycloPetey (talk) 01:58, 19 March 2019 (UTC)
I'm not sure, isn't the described by source (P1343) on Albigence Waldo Cary (Q18819010) that sources Appletons' Cyclopædia of American Biography (Q12912667) not also a valid way of doing it? You can add another qualifier for the page number, and there doesn't seem to be any further publication data. Ghouston (talk) 02:41, 19 March 2019 (UTC)
The described by source (P1343) linking is correct, but not the link in the Wikimedia links section of the data item. There is a lot of other publication data: identity / title of the work in which the article was included, volume / pages in the volume, date of publication, and author of the article. This should all appear in a data item about the article, regardless of the article's length. Every published work gets its own data item, from Leo Tolstoy (Q7243)'s massive novel War and Peace (Q161531) to the 17-syllable Frog Poem (Q11411329) by Matsuo Bashō (Q5676). Length of the publication is irrelevant. --EncycloPetey (talk) 03:00, 19 March 2019 (UTC)
An aside: persons on Wikisource can be either in Author space (if they are authors) or in Portal space (if they are not authors), but never in mainspace (unless the person is themselves a written work). Beleg Tâl (talk) 23:07, 18 March 2019 (UTC)
This is true on most Wikisource projects, but not all. The German Wikisource puts its Author pages in the Main namespace instead of in an "Author:" namespace. E.g. s:de:Johann Wolfgang von Goethe --EncycloPetey (talk) 02:01, 19 March 2019 (UTC)
i would not say "they are incorrect" but that the ontology is not settled. subjects of encyclopedic articles are notable at wikidata, so a migration path from wikisource page to wikidata item would be nice. we need a systemic way of indicating "depicts" or "is the subject of article" statements. and a author / portal subject infobox at wikisource. Slowking4 (talk) 11:37, 19 March 2019 (UTC)
The ontology is not at issue. If we allow such links to a Wikisource biographical article from a Wikidata item for a person, then the system fails whenever we have two different articles about the same individual on the same Wikisource project. Only a single link to a particular project is possible from any given data item. So this method would say that "link to the article about the person, unless there is more than one article about the person, in which case, (pick one of them?) (do it differently somehow?)". Any proposed system that breaks that easily is untenable. --EncycloPetey (talk) 14:08, 19 March 2019 (UTC)
Sounds like Wikidata's issues with the different spaces on Commons are not a problem unique to Commons. - Jmabel (talk) 16:14, 19 March 2019 (UTC)
"Any proposed system that breaks that easily is untenable." = sounds like wikipedia. the ontology is the issue. the fact that wikisource does not have a convenient "depicted" page for wikidata is interesting. maybe wikidata should create such pages, either in wikidata or wikisource. sources for those depicted people would then be citations. chapters in works in wikisource are citations. do not know why you would consider them a data item. that is until you roll out wikicite. Slowking4 (talk) 13:32, 20 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── The ontology is not "broken", the wikidata item just was linked improperly to the Wikisource page (not everyone is well acquainted with every Wikimedia Project!). This is not different than people accidentally linking the wrong items together across two wikipedias. Compare ACAB-1 / Bell, Alexander Graham (Q21508901), which is a properly formatted page for an Appleton Cyclopaedia article. Circeus (talk) 15:00, 24 March 2019 (UTC)


So, how can we fix this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:58, 29 March 2019 (UTC)

Unlinking the items is a solution enough. Or create quick'n'dirty items about the articles themselves. Aside from the (likely) "mass edit" angle, it's not exactly a complicated situation at all. Circeus (talk) 02:49, 30 March 2019 (UTC)

Q321014 error

Can someone peek at A. P. Carter (Q321014) and explain a little bit better why I get the error message for the image. --RAN (talk) 17:02, 26 March 2019 (UTC)

Given that the name contain 'carte' it matches a regex that suggests to the user to use locator map image (P242) instead of the regular image property. ChristianKl17:28, 26 March 2019 (UTC)
I added another exception in image (P18). Ghouston (talk) 00:39, 27 March 2019 (UTC)
And some more that I found in the constraint violations. That makes 23 exceptions to the constraint, so far. Ghouston (talk) 10:26, 27 March 2019 (UTC)
According to Help:Property constraints portal, "Constraints are hints, not firm restrictions". If this is correct, it shouldn't be necessary to list exceptions, particularly as there could be many more - people with the surname Carter, and place names (Carterton, Mapperley, etc.) and buildings in those places. It may be possible to improve the regex - "Carte de/des/du", "MapOf/Map showing/Map South" are all likely to be maps, but "Carter", "Maple" and "Mapp" are not. Peter James (talk) 21:00, 29 March 2019 (UTC)

Sitelinks to Wiktionary

I just tried to make a sitelink to wikt:nitrox on the page nitrox (Q898391) without success. What's the secret code to use, and why does the interface need it anyway (the box is labelled "Wiktionary")? --RexxS (talk) 14:24, 27 March 2019 (UTC)

You need to add the language code of the Wiktionary you want to link to. - Andre Engels (talk) 14:34, 27 March 2019 (UTC)
Thank you. I just reached the same conclusion by using WDQS to find some items that had Wiktionary links and inspecting them. It really does need some better documentation – Help:Sitelinks doesn't even mention Wiktionary at all. Cheers --RexxS (talk) 14:38, 27 March 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── So now I get this warning:

"Warning: Wikidata's notability policy does not allow links to Wiktionary entries unless the interlanguage links cannot be automatically provided. By clicking on "save", you confirm that this is the case. In general, connecting Wiktionary words to Wikidata concepts is not correct"

What on earth is all that about? I thought the whole point of having sitelinks on Wikidata is to provide interlanguage links for other sister projects? What does "unless the interlanguage links cannot be automatically provided" mean? The interlanguage links don't get created by magic, so they are never going to be "automatically provided". Why is it so difficult just to get a link from en:nitrox to wikt:nitrox? --RexxS (talk) 14:48, 27 March 2019 (UTC)

Hello,
I think the page Wikidata:Wiktionary/Sitelinks can bring some answers to you. Basically, the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, but only to connect pages outside the main namespace (for example Help:Contents (Q914807). A link to a Wiktionary entry should not be linked on a Q-item on Wikidata, since Q-items are about concepts and Wiktionary pages are about words, which are two different things. If you want to connect a Wikipedia page to a Wiktionary page, you can use Wikipedia's local "in other projects" template, that would be placed in the content of the page. If you have more questions, feel free to ping me. Lea Lacroix (WMDE) (talk) 14:55, 27 March 2019 (UTC)
Hi Lea, thanks for the response. If the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, then what was it made for? The sitelinks part of a Wikidata entry only has functionality in the context of making links between sister projects. If someone is reading an English Wikipedia page on en:Berlin, they will see in the "in other projects" section (above the language links in the left-hand column) links to Commons, to Wikinews, to Wikiquote, and to Wikivoyage – all automatically provided from Wikidata. There is no need for an '"in other projects" template' because we use Wikidata. But by your logic, a link to a Wikinews entry should not not be linked to a Q-item on Wikidata, since Q-items are about concepts and Wikinews pages are about news stories, which are two different things. I can level the same argument to Commons, which is about media; to Wikivoyage, which is about travel destinations and so on.
You have missed the point: we need the purpose of sitelinks on Wikidata to be functional and to link related items, not identical items. Of course items on Wiktionary are going to be words, not concepts, by the definition of a dictionary. In just the same way, items are Wikivoyage will be concrete destinations not concepts.
In this case, striving for some sort of inconsistent rigour (presumably because you're all currently preoccupied with the difference between concepts and lexemes) by insisting that we can't link a concept to its related definition on a particular sister site, has no practical effect other than to cripple the functionality of Wikidata in handling inter-site links for one sister project. Please rethink your stance on this. --RexxS (talk) 15:55, 27 March 2019 (UTC)
I think the goal is to eventually link wiktionary entries with the Lexeme space, but they haven't figured out how to do that yet. Circeus (talk) 15:58, 27 March 2019 (UTC)
@RexxS: This is very old news and was much discussed here and on the Lexicographic Data page. If you were to take a look at a handful of lexemes you would see that there are frequently multiple "senses" which link to Wikidata items for a given lexeme, and conversely there are multiple lexemes that can link to a single Wikidata item. The concept/word linkage is intrinsically many-to-many even within a single language, and the Wikidata sitelink mechanism simply cannot handle that. ArthurPSmith (talk) 19:21, 27 March 2019 (UTC)
@RexxS: I’m sorry, but I think it’s you who are missing the point. The Wikimedia Commons page for Leonardo da Vinci is still a page about Leonardo da Vinci (Q762), though focused on his work as an artist. His Wikiquote page is also about that same subject, now focusing on a different aspects, his quotes. The Wikivoyage page about Prague and the Wikipedia article of the same name are also the same subject (the capital city of the Czech Republic), though viewed through different lenses, so to speak (travel guide and encyclopedia). And Wikinews articles are indeed rarely about the same subject as other items, that’s why they usually get linked to separate items (random example: Q57630492).
Wiktionary works differently: a single Wiktionary page contains information for multiple languages, each possibly listing multiple words (e. g. homographs), and often with several meanings per word. Would you link stress to stress (Q123414), mechanical stress (Q206175), or stress (Q181767)? Is handy a mobile phone (Q17517) (German) or a handjob (Q1480864) (English)?
The Wikidata team already worked on a different solution for Wiktionary sitelinks: Cognate. Trying to tie Wiktionary pages to Wikidata items is terribly wrong on a conceptual level. (And no, Lexemes are not a replacement for Cognate, because Wiktionary pages don’t correspond to Lexemes either.)
And specifically in response to If the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, then what was it made for? – Léa already answered that: it’s for pages outside the main namespace, such as help pages, project pages, templates, or modules. Those are the parts of Wiktionary that can be linked to Wikidata items and pages on other wikis. —Galaktos (talk) 21:26, 27 March 2019 (UTC)
@ArthurPSmith, Galaktos: I couldn't care less how old the news is. The problem remains and you offer no solution. Let me make this clear: lexemes have nothing to do with making a sitelink from English Wikipedia to Wiktionary.
I assure you I haven't missed any point. The English Wikipedia page en:Leonardo da Vinci is a narrative summary of his life and works; the Commons page c:Leonardo da Vinci is a gallery of images (and potentially other media) illustrating his work. If as Lea claims, the Wikidata page, Leonardo da Vinci (Q762) is about the concept of Leonardo da Vinci, then it's abundantly clear that those are just as different from one another as the words Leonardo da Vinci are.
Have you ever visited Wiktionary? The wikt:Main page starts with the words "Welcome to the English-language Wiktionary", not "the multi-lingual Wiktionary", nor "the combined German and English Wiktionary". Each page contains a dictionary definition in precisely one language, and there is absolutely no reason why any unambiguous term should have a link to each and every site where that term exists.
I'm not asking how I would link wikt:stress to a wikidata item. I'm asking why I can't link the article en:Nitrox to its dictionary definition wikt:nitrox – an exact one-to-one relationship. You've offered no explanation of how that is not feasible or why that is not allowed.
Cognate is jam tomorrow. I've been using Wikidata for over seven years productively, and I've yet to see any convincing explanation of why inter-site links have to exclude Wiktionary's mainspace. I understood that Lea thinks "Basically, the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, but only to connect pages outside the main namespace (for example Help:Contents (Q914807)." but that is simply an assertion, not an argument, and it doesn't address the question of why the functionality exists if we're not allowed to use it. --RexxS (talk) 22:12, 27 March 2019 (UTC)
@RexxS: I’m sorry, but this is ridiculous. Have you ever looked at a Wiktionary page other than the main page? “the English-language Wiktionary” means that it is written in English, not that it is about the English language exclusively. Go to wikt:a and you will see entries in over a hundred different languages, all on one page. I really don’t understand how you can possibly claim that [e]ach page contains a dictionary definition in precisely one language. —Galaktos (talk) 22:52, 27 March 2019 (UTC)
@Galaktos: Ridiculous is it? Take a look at the very page I've quoted to you as needing a link from the English Wikipedia: wikt:nitrox - the full url is https://en.wiktionary.org/wiki/nitrox and note the "en" in the url. Nothing there in a hundred different languages. Look at the left sidebar. There's a set of "in other language links". There are two links: to https://hr.wiktionary.org/wiki/nitrox the entry for nitrox on the Croatian Wiktionary and https://ru.wiktionary.org/wiki/nitrox the entry for nitrox in the Russian Wiktionary. Yes I know that they only exist because they are written in Croatian and Russian, but it doesn't matter which one you look at, they provide a dictionary definition of the concept of nitrox. The related item on Wikidata is still nitrox (Q898391), the related article on English Wikipedia is en:Nitrox and the related article on Russian Wikipedia is ru:Нитрокс (дайвинг) in every single case. What is so problematical about making them link to each other using the very mechanism that Wikidata provides? --RexxS (talk) 23:23, 27 March 2019 (UTC)
@RexxS: While it might be correct that in this particular case there's only one page on En.Wikidictionary, there will be many cass where there are multiple matching pages. ChristianKl11:15, 28 March 2019 (UTC)
Indeed, ChristianKl, and I can see good reason why we would not want to link to those cases. But the analogy is the Bonnie and Clyde (Q219937) problem. It's obvious that we shouldn't create the interlanguage links to all three of Bonnie and Clyde (Q219937), Bonnie Parker (Q2319886), and Clyde Barrow (Q3320282) for every article about any of them, but we don't put a blanket prohibition in making the links where there is a one-to-one relationship between one of the items and a corresponding article in a Wikipedia. So it should be with Wiktionary: not every entry has a one-to-one relationship with an an article in a language Wikipedia, and so we shouldn't link them. But for the cases where that one-to-one relationship exists, it insults the editor's intelligence not to allow them to make use of a facility that the software has built-in. --RexxS (talk) 16:14, 28 March 2019 (UTC)
The current goal is to have sooner or later sitelinks that go from lexemes (or senses) to Wikidictionary pages which then results in a good solution. If we add a bunch of links from the Q-namespace to pages like https://en.wiktionary.org/wiki/nitrox that will make it later more complicated to get the proper links later in place. ChristianKl17:20, 28 March 2019 (UTC)
@RexxS: This is WikiMedia, it is all a work in progress. Yes it's related to the "Bonnie and Clyde" problem that would be nice to solve for Wikidata and its sitelinks - but it's much much worse in the Wiktionary case. Wiktionary pages are not structured data, they are a mish-mash of languages and parts of speech and etymologies. Lexemes in Wikidata are designed as structured data for words, and we have a mechanism for interlinking them with Wikidata items, so that's progress. Conceivably Wiktionary pages could be redesigned to draw from Wikidata lexemes, and so the links you desire would eventually be there. But as with enwiki but perhaps more so, it's been hard to make progress on integration. Lydia and the developers may have something more concrete in mind going forward that I'm not aware of of course. This fall's Wikidatacon is going to be talking a lot about languages and lexemes, so if you have concrete ideas you can propose something there. ArthurPSmith (talk) 11:46, 29 March 2019 (UTC)

State of the art of the commons category problem

I’m translating the question on Commons category on the FAQ : Help:FAQ#Other_Wikimedia_sites and it seems to me that this remains kind of mess. Question : is this the best we can do right now or is this the result of the history of Wikidata and should now be simplified one way or another ?

Jheald (talk) 06:27, 17 August 2014 (UTC) Micru (talk) 07:20, 17 August 2014 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 17 August 2014 (UTC) Sannita - not just another it.wiki sysop 12:50, 18 August 2014 (UTC) Susannaanas (talk) 08:05, 19 August 2014 (UTC) Mushroom (talk) 12:02, 21 August 2014 (UTC) I do think Commons is the better place to talk about this. Multichill (talk) 18:50, 21 August 2014 (UTC) Jarekt (talk) 04:38, 3 September 2017 (UTC)  徵國單  (討論 🀄) (方孔錢 💴) 11:23, 14 November 2017 (UTC) Mike Peel (talk) 22:50, 12 May 2018 (UTC) Yann (talk) 23:27, 7 July 2018 (UTC) John Samuel (talk) 10:10, 22 September 2018 (UTC) 99of9 (talk) 06:27, 12 July 2019 (UTC) Christian Ferrer (talk) 18:05, 19 July 2019 (UTC) Jura GPSLeo (talk) 13:30, 29 July 2019 (UTC) Tris T7 TT me
Juandev (talk) 17:35, 7 September 2019 (UTC) Jean-Fred (talk) 15:21, 26 September 2019 (UTC) Premeditated Vahurzpu Dr Isaac Andy (talk) 05:21, 29 January 2020 (UTC)

Notified participants of WikiProject Commons author  TomT0m / talk page 18:04, 27 March 2019 (UTC)

@TomT0m: The Commons category point was added quite recently by @Ghouston:, [18], and seems reasonable to me - the important thing nowadays is to add the commons sitelink so that the Wikidata information can be used in the Commons category. Thanks. Mike Peel (talk) 18:57, 27 March 2019 (UTC)
There’s 3 different models for the same kind of information. Is not it a bit much ? author  TomT0m / talk page 19:01, 27 March 2019 (UTC)
The text could probably be simplified. The sitelink goes in the topic item unless topic's main category (P910) exists, in which case it goes in the category item, but Pi bot will move it over to the category item if needed. I'm hoping that Commons category (P373) can be deprecated later this year, as >95% of the time it just duplicates the sitelink now, but the remaining edge cases need to be sorted out (anyone interested in helping to clear Wikidata:Database reports/Constraint violations/P373 and Wikidata:Database reports/Complex constraint violations/P373?) Thanks. Mike Peel (talk) 20:31, 27 March 2019 (UTC)
The pragmatic consensus based solution. Seems to work just find. Not worth starting yet another fruitless discussion to change it. I'm not in favour of deprecating Commons category (P373). It has quite a few downstream users.
With structured data on Commons the whole landscape will change anyway. I would keep an eye on that if you want to change things. Multichill (talk) 20:33, 27 March 2019 (UTC)
@Multichill: The current system is a pain since it requires two copies of the data - one in Commons category (P373), the other in the sitelink - and they have to be kept in sync. The sitelink allows access to Wikidata from the Commons categories, and it also auto-updates when a category is moved, which is why I'm hoping we can migrate to that fully in the future. There are solutions for downstream users, such as the code in en:Module:WikidataIB that is now used in en:Template:Commons category to use the sitelink in preference to P373, and I hope that we can migrate users to that over time. This may all change with structured data on commons, but it's not there yet. Thanks. Mike Peel (talk) 21:00, 27 March 2019 (UTC)
The purpose of deprecation is to leave time to clients to adjust. If we’re not deprecating things just because there is client it’s just useless to deprecate anything at all — no need to adjust anything if nothing changes :) If we reason like this on anything on Wikidata we’ll never change anything, or maintaining compatibility will soon become a big burden. author  TomT0m / talk page 21:01, 27 March 2019 (UTC)
Given that a PfD was only just closed on this, I don't see any value in opening this up again after a mere three weeks. Come back in six months time, or a year, and see if things have changed. Jheald (talk) 21:19, 27 March 2019 (UTC)
@Jheald: See my comment in that deletion discussion. Most of the !votes in that discussion were based on old information, things have already changed in practice but the people commenting there haven't caught up yet. Above I said "later this year" - about six months time sounds right. Thanks. Mike Peel (talk) 21:24, 27 March 2019 (UTC)
Are the comments I made on that deletion discussion out of date? I'm not sure that anything has changed since then. Ghouston (talk) 00:58, 28 March 2019 (UTC)
@Ghouston: Yours were relatively up-to-date (you've been following the practical changes over the last year!). I think there's consensus nowadays to just create a category item if a gallery sitelink is blocking it from the topic item, but that's not yet updated in the notability guidelines. The other main point you raised is still valid, I've asked about that at Wikidata:Contact_the_development_team#Using_commons_sitelinks_rather_than_P373_in_the_sidebar?. Thanks. Mike Peel (talk) 19:29, 29 March 2019 (UTC)

Hill and mountain class structure

I've been working with summit data recently (instances of hill (Q54050) and mountain (Q8502)) and wanted to tidy up the class structure of these landforms a bit (they differed and as far as I have found there is no official difference between these terms - just various height based distinctions that aren't agreed upon). Previously hill was a subclass of landform (Q271669), but not an instance of. Meanwhile mountain was an instance of, but not a subclass.

I've just changed hill to match mountain, as it made sense to me that these items should be instances of something. However, on further thought I'm thinking they should both be subclasses and not instances at all. Does this sound correct?

Another point I find a little confusing is that mountains are subclasses of summit (Q207326). Currently hills aren't - and both items have summit listed in has part(s) (P527). Something seems incorrect there to me. --SilentSpike (talk) 22:49, 26 March 2019 (UTC)

Relation between the two

Something else worth discussing is how to model the relation between the two. As there is no globally recognised difference (at least that I have found in my research) then any instance of one can be said to be the other. --SilentSpike (talk) 11:52, 30 March 2019 (UTC)

Started by User:Rschen7754? --Succu (talk) 22:28, 29 March 2019 (UTC)

Clearly part of the consensus reached on the linked discussion pages. Sjoerd de Bruin (talk) 08:41, 30 March 2019 (UTC)

Predicato onomastico vs Particella nobiliare - should they be merged?

It seems to me that nobiliary particle and nobility predicate are covering the same subject, but two distinct wikipedia articles in Italian are blocking a merge. If someone with better italian skills than me could have a look, that would be great. If the distinction in Italian is in fact great enough to warrant two articles, the english labels need to be edited to avoid confusion, I think. Moebeus (talk) 18:24, 30 March 2019 (UTC)

Listeria and long pages

Listeria sometimes produces very long pages. It it possible to instruct it to break at a given page size, and to create pages as, say, Foo (part 1), Foo (part 2), and so on? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:08, 30 March 2019 (UTC)

Currently Listeria only works on a single page between the two templates. You can use sections, but that doesn't really serves your purpose.
I usually end up splitting up the list myself by something that makes sense. For paintings it usually makes sense to split up by time period. So for example the Finnish National Gallery has a separate list for the 19th Century (more examples in Category:WikiProject sum of all paintings huge collections). Maybe something like this works for your case too. Multichill (talk) 15:31, 31 March 2019 (UTC)
Alternatively you could create multiple pages distinguished by different values of LIMIT and OFFSET. Jheald (talk) 17:03, 31 March 2019 (UTC)

title (P1476) and paintings

Input appreciated at Property_talk:P1476#How_to_use_for_paintings?. Multichill (talk) 15:26, 31 March 2019 (UTC)

Inferring notability from external-id properties

Many of our external ID properties do not give an indication of notability (e.g. X username (P2002)).

A few, however do (e.g. JSTOR article ID (P888), under Wikicite), and several with sets in Mix'n'Match.

I have therefore created:

to be used in place of Wikidata property for an identifier (Q19847637). This will facilitate including, or excluding, people with a type of identifier from queries regarding notability (e.g "all humans with no links to other items, and no interwiki links, but exclude those with IDs that confer imply notability").

All properties that have the attribute eventually complete (Q21873974) should use Q62589316, but the inverse is not necessarily the case.

Please help by applying these items to external-ID properties, and by making use of constraints to make the most of their deployment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 30 March 2019 (UTC)

You should have discussed this first before having a bot tag a ton of properties with this. Adding the claims to properties like BAG building ID (P5208), Playboy Plus ID (P5346), IPv4 routing prefix (P3761) makes hits a poluted concept and very much biased to in the direction of expanding notability. This looks like a back door to get around Wikidata:Notability. Multichill (talk) 13:58, 30 March 2019 (UTC)
Please don't issue instructions (even retrospectively); and please remember to assume good faith. This is not in the least about "expanding notability", and our notability policy is unchanged by it. Please also note my comment about eventually complete (Q21873974); which applies to each of the examples you cite. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 30 March 2019 (UTC)
I'm assuming good faith and improved the property so people don't get the wrong impression. Multichill (talk) 14:12, 30 March 2019 (UTC)
Accusing me of creating "a back door to get around Wikidata:Notability" is "assuming good faith"? Your change did nothing to improve Q62589316 (which is an item, not a property), as "suggest" is a synonym for "imply". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 30 March 2019 (UTC)
I don't see any instructions or accusations being thrown around here. In the interest of keeping things civil, could you explain why eventually complete (Q21873974) implies Wikidata property for an identifier that suggests notability (Q62589316)? As I'm not sure I see that this is necessarily true for all cases (see mix n' match where many entries are marked as not applicable to wikidata) --SilentSpike (talk) 15:02, 30 March 2019 (UTC)
"You should have...". Q21873974 means that we will create an item for every valid entry in the database concerned. An item marked "not applicable to wikidata" will clearly not have a value for the respective ID in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 30 March 2019 (UTC)
I suppose I am conflating two different ideas (not applicable + not notable). --SilentSpike (talk) 15:28, 30 March 2019 (UTC)
grumble break all my queries why don't you grumble Jheald (talk) 14:50, 30 March 2019 (UTC)
You seem to have mistyped "allow me to improve". HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 30 March 2019 (UTC)

Scientific names of taxa should be a separate entities from the taxa themselves

Currently, a scientific Latin name for an organism is a property of a taxon, rather than an entity in of itself. However, this causes inconsistencies. Each Latin name has one or more authors, an associated protolog, a publication and a type specimen in a collection. These pieces of information are only related to the Latin name and not the taxon. The taxon is a scientific concept and the earliest valid name is chosen as a label for this concept. This problem with the data model means that the International Plant Names Index (Q922063) identifiers are being used as properties of taxa, which they are not. They are identifiers for published Latin names (valid or not). This is causing me problems because I want to link nomenclatural type specimen details with the name that they are types of, but I can only link them to taxa.

How do we go about getting this change?

Is there a will to fix this?

How do we represent type specimens in Wikidata and their links to names?

I imagine it will be painful, but it is better to do this sooner rather than later Qgroom (talk) 09:20, 17 March 2019 (UTC)

  • I agree with the general problem and think it would be desireable to the taxons in the Q-namespace and the names in the L-namespace, where names belong. ChristianKl20:57, 17 March 2019 (UTC)
At this stage, this involve splitting hundreds of thousands of items from each others. As much as I like the idea myself, I don't think it's realistically feasible whatsoever (not to mention how the distinction is completely lost of most people who are not deeply familiar with codes of nomenclature for organisms). Circeus (talk) 11:29, 17 March 2019 (UTC)
It might be hard, but if the data model is demonstratably wrong isn't the situation only going to get worse the longer it is left? It may be hundreds of thousands of items now, but it will be millions of items eventually. The problem will mean that Wikidata will fail to be useful for biodiversity informatics, where it could be a real game changer. Wikidata's unique selling point it that it can be fixed. Qgroom (talk) 12:15, 17 March 2019 (UTC)
@Qgroom: Some thoughts from 2016. --Succu (talk) 13:06, 17 March 2019 (UTC)
The opposite of what? Qgroom (talk) 12:16, 17 March 2019 (UTC)
I suppose Wikidata could get so big that it just grinds to a halt, but there are an estimated 9 million species. Not all of these are described, but even if they were and each one had two names then it is not going to be a number that Wikidata can't handle. Apparently, there are 2.5 million scientific publications published every year and these are getting added to Wikidata Qgroom (talk) 12:33, 17 March 2019 (UTC)
  • I think it's already being done. If homo sapiens is or was also called something else, there would be a separate item for that name. We just generally don't have an item like Q5. --- Jura 12:45, 17 March 2019 (UTC)
Although Q5 has the description "common name of Homo sapiens..." it is clear from its properties that it is refering to much more than the name. I suspect Q5 and Q15978631 should be merged, because they both describe the concept of humanness and neither describes the name, whether Latin or English.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 12:58, 17 March 2019‎ (UTC).

────────────────────────────────────────────────────────────────────────────────────────────────────

Wikidata asserts that this is a picture of a common name

This is certainly a serious concern, which is stopping the use of Wikidata in other WMF projects, and externally. It's also internally incongruent - we don't define table (Q14748) as "name of a piece of furniture". One of the many prior discussions is "What heart rate does your name have?". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:59, 17 March 2019 (UTC)

Thanks @Succu: and @Pigsonthewing: for those links to earlier discussions on the topic. I had imagined the subject was going to be difficult, I was not wrong.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 14:12, 17 March 2019‎ (UTC).
@Pigsonthewing: No, please don't merge human (Q5) and Homo sapiens (Q15978631), they reflect closely related, but distinct concepts. When we started out with reflecting human genes on Wikidata, we used the statement found in taxon (P703) human (Q5), however, this lead to inconsistencies, basically because of human (Q5) not being a taxon (Q16521) and as such didn't fit with genetic models. You could argue that by simply making human (Q5) instance of (P31) taxon (Q16521) fixes this, however there are examples (e.g. Lexa (Q23023325) where an item is righteously instance of (P31) human (Q5), but not instance of (P31) Homo sapiens (Q15978631). --Andrawaag (talk) 10:13, 18 March 2019 (UTC)
Don't worry I've no intention of messing with humans. The point is, humans are exceptional in a number of ways and in this case we should not get deflected by these special cases.Qgroom (talk) 11:49, 18 March 2019 (UTC)
@Andrawaag: Where did I propose such a merge? I've fixed Q23023325, which should not have been using Q5. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:09, 18 March 2019 (UTC)
@Pigsonthewing: You were the first signature after "I suspect Q5 and Q15978631 should be merged". It seems that I was wrong there, appologies. --Andrawaag (talk) 22:23, 18 March 2019 (UTC)
I'm hardly a WikiData expert, but about all i do on here relates to taxa. Here are some thoughts:
  1. Many common names relate to more than one taxon, so if this separation happens, it needs to accommodate many q-items using the same common name item.
  2. Many taxa already have more than one scientific name, mainly in the form of synonyms. I am under the impression that each synonym should have it's own separate q-code. Even if this is not the desired policy, it is certainly happening in many cases. In these cases, it approaches the situation requested above. I think if we want one item for a common name and scientific name, we'd have to combine more than one scientific name. Personally, with how names change back and forth this may be unwise.--NessieVL (talk) 01:41, 19 March 2019 (UTC)

Here are some thoughts...

Use cases

  • Finding where type specimens are
  • Testing that there is only one holotype, lectotype or neotype.
  • Testing other rules of nomenclature
  • Testing that the authorship of names is correct
  • Finding the literature on the naming of taxa
  • Linking names of taxa to authors
  • Testing that the name has been legitimately typified
  • Identifying syntype material

Ways forward?

  • Ignore the cases of cats, dogs and humans and start with the more obscure and therefore less controversial taxa.
  • Continue labelling taxon concepts as they are now as Instance of P31 Taxon Q16521 with a label, such as "Viola lutea"
  • Add new scientific name items as Instance of P31 name Q82799 (or preferably a new item class - scientific Latin name)
  • Label these new scientific name items with something like "Viola lutea Huds. (name)"

Doubtless I'm being too naive, but if there are ways to breakdown a difficult problem into manageable chunks then perhaps it is solvable.  – The preceding unsigned comment was added by Qgroom (talk • contribs) at 14:12, 17 March 2019‎ (UTC).

PS: One thing I note is that previous discussions have conflated taxonomy and nomenclature. The later is concreate, has tightly defined rules and is therefore much more tractable in a database than taxonomy, that often comes down to a matter of opinion.  – The preceding unsigned comment was added by Qgroom (talk • contribs).

  • I think we should get inspired from Darwin Core, with their occurence system that allow to store, and then retrieve, the infos about specific specimens into databases. If we allow that a specific specimen, or group of specimens, can have an item, then it will be easy to store a lot of infos including something like subject has role (P2868) holotype (Q1061403) of (P642) of the taxon of your choice.
    Furthermore in the perspective of the future that binds more and more Wikimedia Commons and Wikidata, it will be great if one day we can import with automated tools the images of free datasets into Wikimedia Commons and the and related information into Wikidata, example see this occurence and this image manually uploaded into Commons and where related information is currently poorly rendered and used (+the work is too important to be done manually in the long run). I dream that one day the free datasets of gbif be imported into the Wikimedia Project (medias in Commons and infos in Wikidata). Christian Ferrer (talk) 21:30, 17 March 2019 (UTC)
Yes, but one specimen can be the nomenclatural type of multiple names and be cited in several publications. So it doesn't get around that the name is an entity in of itself. All the nodes of the biodiversity knowledge graph are individual entities (http://bionames.org/~rpage/towards-knowledge-graph/).
If you have an issue with the current system, then with the name as an entity, you move this issue to this new entity, but you solve nothing. Christian Ferrer (talk) 12:15, 18 March 2019 (UTC)
Example, here Dermechinus horridus (Q2743032) and the synonym (also the original combination) Echinus horridus (Q62085775). If you have two different name, and that you need the both names here for a strucutred data purpose, then create a new item, as I show in my example. Or as much as you need. Christian Ferrer (talk) 12:25, 18 March 2019 (UTC)

Two properties pointing to the name

I am wondering if the convention used in Wikicite wrt to author names in using both author (P50) and author name string (P2093) can apply here as well. The ideal solution would be to change taxon name (P225) to accept items instead of string, but given that taxon name (P225) is already in widespread use changing seems impossible. Hence mimicing the wikicite solution with authors helps? Just my 2cts. --Andrawaag (talk) 22:06, 17 March 2019 (UTC)

Yes, I think that taking inspiration from the item/ string split between author (P50) and author name string (P2093) looks promising. In that vein, I think the current taxon name (P225) should remain as a string property, and the only thing we would have to change there would be the labels of P225, to "taxon name string" (and equivalents in other languages). This would then be complemented by a new property "taxon name" (or perhaps better "taxon name item", to reduce the ensuing confusion) that would point to an item. Once we have a P50 statement on a publication item, we usually remove the P2093 one (storing its value via object named as (P1932)). I think the "taxon name string" statement would eventually have to be deleted from the taxon item (and migrated to the taxon name item), but perhaps we should allow for some more time here than for the P50-to-P2093 conversion. --Daniel Mietchen (talk) 03:23, 18 March 2019 (UTC)
No. That will not work. Properly done, a taxon has four parts; the name (ie taxon), the author (ie possibly multiple names), the publication and the date. This is what it takes to uniquely describe a taxon. I have said it before and I say it again. Thanks, GerardM (talk) 06:23, 18 March 2019 (UTC)
I am not sure I understand. Isn't the issue here that there is a need to distinguish between a taxon and a taxon name. You argue that a taxon is described by 4 concepts of which its name is one. But you also argue that the name is the taxon, which at the same time is one of the four characteristics of a taxon. Isn't this the kind of Droste effect being addressed here? --Andrawaag (talk) 09:36, 18 March 2019 (UTC)
I think the anology with author (P50) and author name string (P2093) is a good solution that is non-disruptive, but allows progress. How do we get this done? Qgroom (talk) 11:57, 18 March 2019 (UTC)
  • There is no need to separate the taxon from the taxon name, an item about a taxon is and should stay an association of different things (name, author, date). In case of synonymy, then this is not anymore the same association and a new item is needed and have to be "instance of/ synonym of..". In the extend, of course, that we think relevant to have this item here, example in case of original combination, but we don't need to list all synonyms IMO, though the debate can stay open. But in all case when a species is "renamed" and that the a new name is accepted, we must absolutely create a new item, not change what is written in the string field "taxon name", as it is sometimes the case here. To come back about a potential separation of the taxon name, this will solve nothing of any potential issue (if any), it will just complicate things. A taxon is absolutly not "a thing with potential different names", because when the names are different then we talk about different taxa. A taxon without "taxon name" is not a taxon. We are not going to reinvent science. Christian Ferrer (talk) 12:12, 18 March 2019 (UTC)
@Christian Ferrer: "A taxon without 'taxon name' is not a taxon" – the ICZN in the glossary entry for "taxon" says it's a taxonomic unit whether named or not, so you are using a different definition to the Code. Peter coxhead (talk) 17:27, 19 March 2019 (UTC)
@Peter coxhead: There is no need to push the ontology so far. As a data, yes of course yes, a taxon is not a taxon without a name and without the resulting properties of that taxon name. Christian Ferrer (talk) 17:59, 19 March 2019 (UTC)
There is a need. As said before, a taxonomic name is linked to a type specimen, an author and a protologue and these are not properties of the taxon, they are properties of the name. The taxon, is a biological hypothesis and is much more fluid in its scope. There is no single authority for which name is accepted. What is accepted is always a matter of opinion. On the other hand taxonomic names are concreate, founded on clear rules. Taxonomic synonyms are not just different names for the same thing. A name can even exist even if we don't know what taxon it is supposed to represent. These names are an important link between the biology, collections and scientific literature. Qgroom (talk) 14:21, 18 March 2019 (UTC)
Each taxa item here has currently only one taxon name, almost all if not all the other properties (included, and in addition of what you quote yourself, the parent taxon, and all external identifiers) are relative to that specific name, you said it very well, and if you move the name then you need to move all the rest, therefore you move nothing. The only thing that can stay, and not for all cases, is the common name. Christian Ferrer (talk) 17:46, 18 March 2019 (UTC)
@Christian Ferrer: each item incorrectly claimed to be an instance of a taxon has only one taxon name, because it is actually an instance of a taxon name, not a taxon. See #Previous discussion below. Many taxa are represented here by multiple taxon names. Peter coxhead (talk) 17:02, 19 March 2019 (UTC)
@Peter coxhead: Yes and no. What would be an instance of taxon otherwise? what will be the label? it is just a concept that take consistency only when it is named and defined. And as I noted above, absolutly all the other properties currently used are depending of that name and definintion, therefore if you have an item for the taxon name, you have in this item all the other properties too (external identifiers, rank, parent taxon, publications, author, sitelinks, ect...). What will be in this item "taxon" in addition of a property taxon name where the value will be the Qitem of the taxon name? absolutly nothing because everything flows from this taxon name and from all the properties that are unique to that taxon name. The only thing that it will allow to do it is the possibility to add multiple values to that property taxon name, but ultimately it does not bring nothing because currently you can create synonym items as much as you need. Therefore to change completely will create a lot of issues to solve none. Christian Ferrer (talk) 17:50, 19 March 2019 (UTC)
Assuming that we were changing "instance of taxon" to "instance of taxon name", not a single property of Holothuria scabra (Q2395506) will be changed. And what? The only result will be a potential (big) disrupion of the Wikimedia projects that are currently using tools that works with "instance of taxon", but what's new? What is the interest to materialize the "true" concept of "taxon" in a structured data? what will be the name of that item "taxon", what label? the accepted name, maybe? but this is the current situation, ....no?!? the other names are synonyms, thing that they can currently be, so what new? Christian Ferrer (talk) 19:00, 19 March 2019 (UTC)
In my opinion Wikicite is a disaster creating wrong titles, duplicated items etc. example often making it hard to add basionym (P566) or original combination (P1403) based on sources. --Succu (talk) 21:28, 18 March 2019 (UTC)

Possible solution

With our existing infrastructure we can use lexemes for the latin names and use item for this sense (P5137) to link them to our taxon items, the new lexeme/sense items can get the information about taxon author and publication. A bot could simply do this for all the existing taxons that we have. As a next step we can merge items that describe the same taxon via the existing information from taxon synonym (P1420). Does anybody see problems with doing that? ChristianKl12:09, 18 March 2019 (UTC)

Though this solution is at the opposite of the original subject, that tend to divide than to merge. For a structured purpose, e.g. if we need to link a specimen as to be a specific type, example "holotype", of a specific taxon with a specific name (even if is not the current accepted name) then we need an item for this specific taxon. And this is currently possible with the current system, see my example. You can very well have a specimen that is the holotype of Echinus horridus (Q62085775), while the accepted taxon is Dermechinus horridus (Q2743032). For that purpose of what is needed is that we allow to create items for specific zoological specimen (Q2114846) or something similar. No really, no, in taxonomy, the same thing with two different name is not the same thing but well two different things, we need to keep the item separate. Christian Ferrer (talk) 12:55, 18 March 2019 (UTC)
Yes, I agree Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) should be merged, because they refer to exactly the same species concept. However, these items have conflated name information and taxon information. So that the properties taxon author citation (P6507) and P5326 (P5326) would then need cleaning up. If names were separated from the species concept then multiple species concepts could coexist, as they already do in the real world. Qgroom (talk) 14:35, 18 March 2019 (UTC)
I fail to understand why we should clean up the original publication of the original name, this is useful information. As well as the author citations of both items are useful, as these both citations are (different) currently used, example. Further more a taxon name is linked to one specific author citation, therefore if you quote the name somewhere you have to quote the author citation too. Christian Ferrer (talk) 18:13, 18 March 2019 (UTC)
@Christian Ferrer:Why do you consider that to be important. Why isn't it enough when we store the orginal name in the source document with some form of 'states as'? ChristianKl15:48, 18 March 2019 (UTC)
@ChristianKl: Here the taxa items currently need a rank, a name and a parent. A taxon synonym have obvioulsy a different name, may have a different rank (e.g. a species can be a synonym of a subspecies), and may have a parent taxon different (in the facts all is (or may be) different, as pointed there). I fail to understand what is the interest to merge such things, in addition of that I fail to understand how can work well a taxon chain like that. Though this is not because I don't understand it that it is impossible. Christian Ferrer (talk) 17:58, 18 March 2019 (UTC)
I've listed a few of the use-cases above. These can't be resolved by treating taxonomic names and taxa as the same thing, nor by treating names as mere labels. The inconsistencies are already apparent in the Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) example. Qgroom (talk) 17:40, 18 March 2019 (UTC)
What kind of "inconsistencies"? could you please more specific? --Succu (talk) 21:31, 29 March 2019 (UTC)

@ChristianKl: I'm a Wikidata beginner. Could you point me to some material to explain your lexeme proposal? Qgroom (talk) 14:40, 18 March 2019 (UTC)

Lexeme's are entities that represent how a given concept is called in a given language. The were recently introduced to map to Wikidictionary entities. https://www.wikidata.org/wiki/Wikidata:Lexicographical_data/Documentation provides more information. ChristianKl15:48, 18 March 2019 (UTC)
I doubt binomen (Q864016) should be treated as lexemes. --Succu (talk) 20:46, 18 March 2019 (UTC)
Claiming that Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) refer to "the same species concept" is a huge stretch. In almost all cases it is impossible to say to what species concept a name refers to without citing at least one actual taxonomic paper. There are very few Wikidata items that refer to a particular species concept; this is only possible if the taxon is very well-known and uncontroversial or if an item is defined in terms of a particular taxonomic position.
        The basic issue is that scientific names can be databased very easily, and one name per item allows adding all nomenclatural information, such as authorship of the name, and any detail on typification (in principle, we may need extra properties).
        On the other hand taxa can not be databased at all (with a few exceptions) except by using scientific names. And scientific names can refer to any number of differently defined taxa.
        Having one item for one scientific name allows any bit of data from the literature to be databased accurately. Recording information accurately surely should be the foundation of any database policy. - Brya (talk) 17:51, 19 March 2019 (UTC)
"refer to "the same species concept" is a huge stretch." yes, and this is why there is currently two different items. Christian Ferrer (talk) 18:03, 19 March 2019 (UTC)

Types

We have taxonomic type (P427) to add them. What we are missing is a data model for types at species rank and below. This are your major use cases above, Qgroom. How should we do this? --Succu (talk) 19:09, 18 March 2019 (UTC)

taxonomic type (P427) is about type species, despite the similar sounding name, this is something completely different to a type specimen. Qgroom (talk) 20:17, 18 March 2019 (UTC)
No. Please see Rausch 572 (Q19359611). --Succu (talk) 20:30, 18 March 2019 (UTC)
I don't understand. Rausch 572 (Q19359611) is a type specimen, it is not a necessarily a taxonomic type (P427) as it is defined (BTW that's a terrible label). Qgroom (talk) 21:27, 18 March 2019 (UTC)
Hopefully [19] Acanthocalycium thionanthum (Q337710) and Acanthocalycium ferrarii (Q337692) are not based on the same type. If the would be the case replaced synonym (for nom. nov.) (P694) should be applied. --Succu (talk) 21:42, 18 March 2019 (UTC)
The replaced synonym (for nom. nov.) (P694) is being used incorrectly in the item Acanthocalycium thionanthum (Q337710). The definition of replaced synonym (for nom. nov.) (P694) is "the type genus of this family (or subfamily, etc), or the type species of this genus (or subgenus, etc)". It is therefore referring to a taxon, not a specimen. So it can't be Rausch 572. This is the sort of logical inconsistency I want to resolve by making a clear distinction between taxa and taxonomic names. --Qgroom (talk) 05:51, 19 March 2019 (UTC)
I assume what is intended is taxonomic type (P427) in Acanthocalycium ferrarii (Q337692). This P427 when proposed was indeed intended for taxa, but it is not inconceivable to expand its use to include type specimens / illustrations / descriptions. However, that would mean creating an item for every type, which seems like an enormous, even a practically impossible (?) amount of work. So maybe we do need new properties. And yes, "taxonomic type" is a terrible label, but pragmatically it does need "taxon" or "taxonomic" in the name, in order not to be lost here, in this database with a huge span of coverage. - Brya (talk) 05:09, 20 March 2019 (UTC)

Sitelinks

Where to put them? Do Wikimedia project describe taxon concepts or only list names according to a special source? This includes the automatic creation of items here based on an external id. --Succu (talk) 19:38, 18 March 2019 (UTC)

Note that I don't know exactly how that works but in case of synonym in Wikimedia Commons the links may be given, example. Christian Ferrer (talk) 19:58, 18 March 2019 (UTC)
Commons prefers this taxonomic viewpoint. This includes the renaming of pictures to their preferred view point. I very bad practice. --Succu (talk) 20:17, 18 March 2019 (UTC)
Wikimedia uses taxon concepts, anything else would be odd. The case of Index Fungorum you mention is interesting. Index Fungorum is a list of names, like IPNI, however it links to Species Fungorum where a list of accepted taxa is maintained. A clear case of maintaining separation between nomenclature and taxonomy. Qgroom (talk) 20:26, 18 March 2019 (UTC)
Hard to believe Wikimedia uses taxon concept (Q38202667). Hard to believe all Wikimedia projects follow the same concept (birds, mammals, …) unisono. --Succu (talk) 20:38, 18 March 2019 (UTC)
Of what I point is not Wikimedia Commons practice but the fact that the sitelinks ca be retrieved from Rhodocybe nitellina (Q10434744) to Rhodophana nitellina (Q51954845), I guess with taxon synonym (P1420), the illustration can be seen in the Commons category that I have pointed. In summary the current system is good : no matter that a specific project use one name and another project use another name, because the current system allow the navigation in despite of that. And it is unrelative to the category redirect that you have pointed, there was a discussion about this feature on Commons, but I'm not able to find it, I know that taxon synonym (P1420) and our local infobox are involved. Christian Ferrer (talk) 21:11, 18 March 2019 (UTC)
The statement in Wikimedia Commons example is wrong. Index Fungorum make no judgement about whether Rhodocybe nitellina is an accepted name or a synonym. Index Fungorum is just a list of names. However, it does state that Rhodophana nitellina (Fr.) Papetti is the accepted name in Species Fungorum. Qgroom (talk) 21:26, 18 March 2019 (UTC)
Yes it does, though the link on Commons leads indeed to another page. But this is out of topic here, as we talk about sitelinks. Christian Ferrer (talk) 21:40, 18 March 2019 (UTC)

External IDs

Some of them are more dedicated to a nomenclatural act (eg. IPNI, IF, Mycobank, Zoobank should). A lot of them (NCBI, FishBase, IUCN …) follow a certain taxonomic viewpoint. That means the same ID can point to different scientific names. Others (e.g. WoRMS) are in between, they have Ids for accepted/valid names and earlier ones. Same question: where to put them? --Succu (talk) 20:06, 18 March 2019 (UTC)

Well that's why I'm asking for name items separate from taxon items, but perhaps the question was not directed at me. Qgroom (talk) 20:36, 18 March 2019 (UTC)
Where to put them at your proposed name centered items? --Succu (talk) 22:15, 18 March 2019 (UTC)
@Qgroom: Any proposal? --Succu (talk) 21:25, 29 March 2019 (UTC)

Previous discussion

The issue of representing taxon names versus taxa has already been discussed in great detail, more than once. See e.g. Property talk:P1420#data model.

The main points to be clear about first are:

  • A taxon is not the same as a taxon name. Explaining clearly is complicated by the different terminologies employed in the nomenclature codes, but using the ICZN here, a taxon or taxonomic unit, whether named or not, is "a population, or group of populations of organisms which are usually inferred to be phylogenetically related and which have characters in common which differentiate .. the unit .. from other such units."
  • A taxon can properly (validly, legitimately) have more than one name, if it is given a different placement within another taxon, and/or a change of rank. Thus precisely the same group of organisms may be given the name Muehlenbeckia florulenta (Q1101419) or the name Duma florulenta (Q18081078) depending on which genus a taxonomist considers them to belong to. Precisely the same group of organisms may be given the name Hyacinthaceae (Q13833438) or Scilloideae (Q133292) depending on whether the differences between them and other groups are considered sufficient to treat them as a separate family or to merge them into another family as a subfamily. There is no absolute right or wrong name in most such cases; it's a matter of legitimate taxonomic opinion.
  • In my examples, Muehlenbeckia florulenta (Q1101419), Duma florulenta (Q18081078), Hyacinthaceae (Q13833438) and Scilloideae (Q133292) are claimed to be instances of Q16521, currently labelled "taxon". They are not instances of taxon. They are instances of "taxon names". There are only two instances of "taxon" here: Muehlenbeckia florulenta (Q1101419) and Duma florulenta (Q18081078) are two names for one instance of a taxon; Hyacinthaceae (Q13833438) and Scilloideae (Q133292) are two names for another instance of a taxon.

For me, there are two issues:

  1. Wikidata should stop claiming that instances of taxon names are instances of taxa.
  2. Ideally, Wikidata should represent taxa as well as taxon names.

I have no idea why there seems to be resistance to (1).

(2) is, however, difficult, as is explained in detail at Property talk:P1420#data model. Here's another example. There are two ways of classifying the genus Hyacinthus used in the current botanical literature, as shown in the table below. 1–6 are the six taxa involved; the others are taxon names. (There's implicitly another taxon, with two possible names: for those who use the left hand column, Family Asparagaceae is a different taxon from #2, a taxon treated as a subfamily by those who use the right hand column).

1 Order Asparagales
2   Family Asparagaceae
3 Family Hyacinthaceae Subfamily Scilloideae
4 Subfamily Hyacinthoideae Tribe Hyacintheae
5 Tribe Hyacintheae Subtribe Hyacinthinae
6 Genus Hyacinthus

So

  • the same taxon (defined as the same group of organisms) has more than one name – Subfamily Hyacinthoideae in the left-hand column is the same group of organisms as Tribe Hyacintheae in the right-hand column
  • the same name applies to different taxa – to know the composition (circumscription) of "Tribe Hyacintheae", you need to know which system is being used.

As far as I am aware, no-one has yet shown in detail with a worked example how best to represent data of this kind in Wikidata. Peter coxhead (talk) 12:26, 19 March 2019 (UTC)

This mostly very good.
  • However, "A taxon can properly (validly, legitimately) have more than one name," is not a fruitful way to phrase it. A taxon can properly have only one "correct"/"valid" name (some exceptions in higher ranks) from any one particular taxonomic perspective. This is the whole purpose of the nomenclature Codes. The problem (if it is that) is that there may exist any number of taxonomic perspectives, each representing a particular scientific approach. These may be regarded as several mini-universes alternate realities, which are mutually exclusive. In each mini-universe alternate reality a taxon may have a different name, but only one name at a time. For it to have a different name, there needs to be a switch to a different mini-universe.
  • The "instance of: taxon" is a historical oddity. Basically it means nothing more than that a P225 statement is present, and "instance of: taxon name" could also have been used. However, "instance of: taxon" is not wildly inaccurate, as such things go, since any taxon name is not only a name, but is also used to refer to a taxon (that is what it is there for). Somebody, somewhere, somewhen did use it to refer to a taxon, at least once. - Brya (talk) 18:15, 19 March 2019 (UTC)
@Brya: sure, the switch of perspective is what the two columns in the tsble above show. But changing the perspective on a taxon doesn't change the taxon, when this is defined as a group of organisms. There are properties of the taxon that are independent of the perspective. Japanese knotweed is the same invasive plant whether it's called Fallopia japonica (Q899672), Reynoutria japonica (Q18421053) or Polygonum japonicum (Q15250539). Taxa exist independently of what we choose to call them. So it seems that Wikidata should be able to model this, but it may be too difficult. Peter coxhead (talk) 23:14, 19 March 2019 (UTC)
Actually, the "perspective on a taxon" includes the definition of the taxon, called "circumscription". Sometimes, a change in perspective just means a change of rank, or assignment to a genus, but it can also mean a change in size of the taxon, sometimes quite drastically. Without citing a taxonomic reference, there is no certainty what a scientific name refers to, although often enough it can be inferred from context. - Brya (talk) 05:22, 20 March 2019 (UTC)
@Brya: a person may have had or beeen known by multiple names during their lives. But we wouldn't say that "Carl von Linné" is an instance of person and "Carolus Linnaeus" is an instance of person, yet to paraphrase what you wrote above, any person's name is not only a name, but is also used to refer to a person. It's a serious category error to confuse the name of an entity with the entity. "Carl von Linné" and "Carolus Linnaeus" are names for the same person, just as Fallopia japonica (Q899672), Reynoutria japonica (Q18421053) and Polygonum japonicum (Q15250539) are names for the same taxon. Peter coxhead (talk) 23:14, 19 March 2019 (UTC)
"Carolus Linnaeus" is listed as an instance of "human". But humans are more or less fixed single entities, legally anyway, going through several development stages. There is a lot that can be said about names for humans, too much to go into: it is not a simple topic.
        Taxa are rather fluid, or more precisely "serially fixed", that is they are fixed in a particular taxonomic paper, but the next taxonomic paper may fix them differently, and so on, ad infinitum. There is also a lot that can be said about scientific names for taxa, but these are regulated in several Codes, each applying to certain groups of taxa. These provide order and certainty, as long it is recognized that one is dealing with multiple alternate realities.
        The only way to have one name for each taxon would be to adopt an official WMF-Taxonomy. The objections to this are obvious: 1) it would be an Original Research endeavour, while Wikipedia's have a NOR-policy; 2) at present all Wikipedia's make their own choices for taxonomy to be used in taxoboxes, and imposing a WMF-Taxonomy on them would be unpopular; 3) any WMF-Taxonomy would go out of date quickly. - Brya (talk) 05:54, 20 March 2019 (UTC)
Adopting one name for a taxon would, I agree, be completely wrong, and I certainly have never suggested it. Wikidata must represent what all reliable data sources say, whether these sources agree or not. I made two points, which I will repeat one last time:
  1. Wikidata should be accurate and make it clear that what are currently called instances of taxon are actually instances of taxon name. I still have no idea why this is opposed.
  2. Ideally, there needs to be some agreed way of representing taxa (for one thing, Wikipedia articles are usually about taxa, not taxon names). However, this is a difficult problem, it turns out, and no-one has yet demonstrated a working solution. As Brya rightly says, part of the difficulty is that taxa are not as clearly defined entities as, say, people. Maybe it can't be done within the constraints of Wikidata. (Representing alternative classifications in Taxonomy templates in the English Wikipedia involves a combination of ad hoc data "fixes", like skip and variant templates, plus special programming to respond to these data fixes. And it still causes problems that are currently under discussion.) If it can't be done in Wikidata, this needs to be made very clear, so that it's understood that Wikidata cannot be used for purposes that require taxon data (e.g. taxoboxes). However, it's not quite as problematic as Brya says above. Those alternative views that concern the placement or rank of a taxon, rather than its circumscription, leave the taxon (=group of organisms) unchanged.
Peter coxhead (talk) 13:50, 20 March 2019 (UTC)
Though a taxon may have several names, when you talk about a specific taxon name then you talk about one and only one taxon. Without an author, a name, a description, ect... a taxon is just a concept absolutely indistinguishable from another taxon, it is just an idea. The "instance of taxon" here must be understood as "instance of a specific taxon as defined and described under that name". This is absolutely not untrue. Christian Ferrer (talk) 22:37, 20 March 2019 (UTC)
A general point: it is not a requirement that a taxon have a name. It is not unheard off for a taxonomist to publish a description of a recently recognized taxon without naming it. Sooner or later, after hearing the responses of collaegues, he will follow this up by naming it (or not). - Brya (talk) 18:27, 21 March 2019 (UTC)

Comment

  • I would like to make a couple of comments from the point of view of a nomenclatural taxonomist. However I work with the ICZN code and the other four codes of nomenclature are different in some aspects.
    • A name on its own for the species level cannot be used without a genus. However names have an original combination and then can have multiple subsequent combinations. One way would be to have q items for every original combination and include on that page subsequent usages. This would then link to the q item of the current combination. This can likewise be done for synonyms. I am still only referring to species level only. For example the original combination for the mata mata is Testudo fimbriata, it was later moved and became Chelus fimbriata before its spelling was corrected (gender agreement) to Chelus fimbriatus. All this info would go on the q item for Testudo fimbriata with original refs, then link the item to the current species page for the Mata mata. As there are some 15 synonyms of the Mata mata you would need to do this for all of them. Which leads to a problem posed above which is that this is a lot of work.
    • Higher orders would be simpler but also follow the same principal for synonyms. It would still be a lot of work.
    • As noted above it would be easier to start this on small groups (at order level) to trial out the best way to do it before doing anything to complex groups such as vertebrates which can have 15-20 synonyms per species.
    • I agree that you should list the type specimen and the type locality.
    • This would be a high maintenance and highly specialised endeavour, do you really have the editors that can do this at a significant rate, and have the skills to do it. If not and be honest this is a massive undertaking and would require detailed policies for new editors to learn exactly what your doing.
    • Apart from the initial undertaking this is also a significant undertaking in terms of maintenance, in reptiles over the last 20 years the number of species has gone from 6000 to 10500, with many new combinations and synonymies proposed. This is just the reptiles. The people doing this also have to maintain it, this can mean up to 10 or even more edits per year per page that would be major updates that would effect multiple pages at the same time. Of course this is actually ignoring anything outside the major divisions, so I have ignored anything prefixed by sub or suffixed by inae.
    • Lastly you will need your editors of this to be very aware of the difference between nomenclature and taxonomy, to truly understand terms such as type, taxon, and many more, ie memorise the glossary of the code. You are going to have to make some decisions, there are many instances of multiple papers coming out with differences of opinion on what the correct nomenclature for a group is. How will you decide which one to use? In other words some groups are extremely dynamic and in a state of flux.
  • In summary although some great ideas, I think this idea is a big ask of the relatively few people who are well vrsed enough in the complex field of nomenclature to actually do it.
Scott Thomson (Faendalimas) talk 20:00, 19 March 2019 (UTC)
For plants there is IPNI. When it is willing to collaborate with us, a lot of the work can be shared. I personally have an 80MB database with normalised data bringing literature author references et al together for succulents. I am of an opinion that the only copyright IPNI has is the copyright on its original database, my database is based on IPNI but is a distinct database in its own right. I am willing to make it available under cc-0. Thanks, GerardM (talk) 09:42, 20 March 2019 (UTC)
Please share your database with International Plant Names Index (Q922063). Hopefully they can normalize more entries in their database. Then we can improve WD. --Succu (talk) 22:35, 27 March 2019 (UTC)

Failure of logical types

As far as I can see, you guys are arguing like words and names have a special truth. Let me see if I can give an example that explains why scientific names of taxa are not separate entities from the taxa themselves. When you imagine that you know the etymology (Q35245) of a word, how do you know that it is not a false etymology (Q17013103)? The answer is, you only have as much certainty as you can put in the linguistic comparative method (Q950464). Now, this method in linguistics is indistinguishable from those used in phylogenetics (Q171184) to elucidate taxonomy (Q8269924). What is being proposed above is to elevate folk taxonomy (Q10751930) as equal to or above scientific taxonomy. Abductive (talk) 02:51, 28 March 2019 (UTC)

[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)]
Yeah, I must be bewildered. Bewildered at people who think they know what other people are saying when they use words. As I say above, in the case of scientific names, the name of the taxon is the taxon. For most other things, the name of the thing is not the thing. Abductive (talk) 06:09, 28 March 2019 (UTC)
[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)]
Do you suppose that the word bewildered has the root "wild" in it? You are playing a game of IDONTHEARYOU, but it doesn't change the fact that the name of a species and the species are the same thing. Abductive (talk) 21:46, 28 March 2019 (UTC)
[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)]
As an example, I am going to quote from the en.wiki article on Quercus insignis (Q6324634). "Quercus insignis is a Mesoamerican species of oak in the white oak section, (Quercus section Quercus) within the beech family. It is native to southern Mexico and Central America, from Veracruz to Panamá. Quercus insignis is a tree. It has leaves up to 15 cm long and 8 cm across." Do you notice that the species is referred to in the singular? It is a tree. It has leaves, it is native to... We don't say "they are a bunch of trees" or "they live in Mexico". It. The species is the name, and the name is the species. Abductive (talk) 05:33, 29 March 2019 (UTC)
[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)]

Abductive: Could you please give some references for your POV: „it doesn't change the fact that the name of a species and the species are the same thing”. --Succu (talk) 21:06, 29 March 2019 (UTC)

Maybe you are confusing ontology (Q44325) and ontology (Q324254)? --Succu (talk) 20:37, 2 April 2019 (UTC)
Maybe I am. Abductive (talk) 08:07, 3 April 2019 (UTC)
Just curious: are you referring with "logical type" in your heading to Bertrand Russell (Q33760)? --Succu (talk) 21:30, 3 April 2019 (UTC)
"What is somewhat surprising, however, is that Russell himself seems not to have realized that he was describing a new theory of logical types in his later philosophy, and that as a result of the change some of his earlier logical constructions, including especially his construction of the different kinds of numbers, were no longer available to him." I dunno, are we? Abductive (talk) 09:26, 5 April 2019 (UTC)
If a species is an individual, it’s to be seen of a population (Q2625603)  View with Reasonator View with SQID. Then any individual of this species is a part of it, and not an instance. This is to discriminate with the view of a species/taxon as a type or class, which associate to a species a criteria or a set of criteria to say if an individual is or not an instance or an example of individual of a species. This is the difference between part of (P361) and instance of (P31). Note that in that case, the parent taxon relationship and the relation between a dog and its species differs with how we choose to model taxons. If taxons are populations, then wolves are part of mammals as well as an individual dog is part of dogs. If taxons are classes, then dogs are subclass of mammals (as any wolf has all the characteristics of mammals) and an individual dog is an instance of wolf if he has all the characteristics of wolves. author  TomT0m / talk page 16:05, 12 April 2019 (UTC)

Owl on Main Page

For some reason owl (Q8021345) is the #1 Current highlight on the Wikidata Main Page. Weirdly, this is a separate item from Strigiformes (Q25222). Some Wikipedias have an article attached to Q8021345, but most are attached to Q25222. What is going on? Abductive (talk) 05:17, 26 March 2019 (UTC)

[deletion of comment, provided when this was a straightforward question, wanting a straightforward answer. Out of place in the esoteric thread it has been moved to. These threads have as little in common as two threads possibly can that both mention taxa. The thread above deals with an philosophical question if it is possible to model (circumscriptions of) taxa other than by using scientific names (short answer: no, except in a minute minority of cases). This question deals with how animals as perceived by the general public relate to taxa. - Brya (talk) 05:28, 28 March 2019 (UTC)]
This is absurd. The above "concept owl" is linked to a handful of Wikipedias; the Spanish Wikipedia, the Nahuatl Wikipedia, and the Korean Wikipedia, plus some others. There is no way these disparate people, with different native owls, are talking about the same thing. Abductive (talk) 18:31, 26 March 2019 (UTC)
And all Strigiformes are owls. I would say this is one of the few cases in which the scientific name and the common name overlap perfectly. Abductive (talk) 18:33, 26 March 2019 (UTC)
@Abductive: You're correct; but note the existence of - for example - pt:Coruja and pt:Strigiformes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:24, 26 March 2019 (UTC)
@Abductive: See the above discussion (under which I have moved your post); and the earlier discussions it links to. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 26 March 2019 (UTC)
All Strigiformes are owls? No. I suspect that in Russian Tytonidae (Q27112), one family of Strigiformes (Q25222), are not called сова. --Infovarius (talk) 14:47, 29 March 2019 (UTC)
Google Translate says that Сипуховые means "swan". They're still owls. Abductive (talk) 09:39, 30 March 2019 (UTC)

Sub-headings

For the second time, I have fixed the sub-headings in this section so that subsections are nested under those to which they are direct responses e.g. (as currently numbered) "9.6.1 Comment" is one level lower than "9.6 Previous discussion", as the former is a comment on the latter, as can be seen in the version of the page before the subheading was inserted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 29 March 2019 (UTC)

This continuous tinkering with headings, changing the meaning of the comments of users is a really bad idea (and a violation of the ban that applies here). The relevant edit makeas it clear that the user in question intends a heading at the same level as the others. The same with the other heading. The "as can be seen in the version of the page" is based on adding a meaning to indentation; in as far as there is anything in this (only the user in question might know this, and there is no indication that he was asked) the user corrected this by inserting the heading. - Brya (talk) 04:12, 30 March 2019 (UTC)
In what you describe as the "relevant edit", the editor moves the "Comment" heading from level three to level four. Which is exactly what I restored in my fix. Furthermore, the indentation in the comment preceding the heading is ::* and in the comment following the heading is :::* . Both comments pre-date the insertion of the heading. [On reflection, this sub-secion probably belongs on the talk page.] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 30 March 2019 (UTC)
You must be operating in a parallel universe: in this universe the user did not move a heading but only inserted a heading at the same level as all the other headings in the thread. You changed all the other headings (without any reason other than an apparent wish to show you can get away with violating your topic ban). And your comment about indentation may have meaning in your religion, but this does not necessarily have any meaning outside it. - Brya (talk) 17:34, 30 March 2019 (UTC)

East Jerusalem

Hi, I have a problem with places located in the Israeli occupied territories, that is, the territories Israel has occupied since the 1967 war.

After 1967, Israel has unilaterally annexed part of East Jerusalem, this annexation is accepted by exactly 0 other countries. My 2 cents is that we should follow what the international community says, and therefore should not say that they are in Israel.

Comments? (It was partly discussed here Huldra (talk) 20:55, 18 March 2019 (UTC)

In these situations, we should include all the most relevant points in the data. I outlined many of the relevant issues on relating countries and territories and subdivisions at Wikidata:Project_chat/Archive/2018/10#Countries_and_their_subdivisions_and_territory. We need to be able to specify recognition, administration, claims, control, domestic status, subdivision structure source, etc. so that any relevant attribute can be queried. The difficulty is figuring out a data model. In the case of East Jerusalem, we must include the data that the area is administered, controlled, and claimed by Israel, and the data that it is not recognized internationally as being part of Israel. We need to establish a broad data model for dealing with this and the dozens of similar cases, rather than simplifying each situation to pick whichever side of the conflict is more popular among the people arguing the point at the moment. --Yair rand (talk) 04:29, 19 March 2019 (UTC)
Do not we already have enough qualifiers to represent both point of view?--Ymblanter (talk) 20:33, 19 March 2019 (UTC)
Thank you Yair rand, that was interesting. And yes, I absolutely agree; we should get a consensus for this, as it concerns all the articles in East Jerusalem (ie, quite a lot).
Actually, we are in a somewhat similar situation for the articles about the Golan heights: also occupied and annexed by Israel since 1967, while the international community still consider it a part of Syria.
To start with "the top" question, that is, what country they are in:
If (and it's a big IF) we have a country (P17) label, then we should have, say 2 answers;
first: Country A (with the subfield that this is according to the international community, with the exception of country 1, 2 and 3)
second: Country B (with the subfield that this is according to country 1, 2 and 3)
Or: We do NOT use a country (P17) label at all for these places, but only the territory claimed by (P1336) label. Then we will still need a field indicating who accepts the claim. Comments? Huldra (talk) 20:48, 19 March 2019 (UTC)
To clarify the relevant scope here: I'm talking about every territory held in every one of the 165 military occupations listed at w:List of military occupations plus all prior military occupations, all territorial disputes, every state with limited recognition (current and former), and so on. These must all share one broad model.
country (P17) can't be limited to detailing recognition, unless another property stores other data of how the area is related to countries (control, administration, etc).
Regarding recognition itself, the "international community" is too vague to use as a single point anywhere. The individual countries' positions would need to be listed. That would take up a lot of space, though, so perhaps recognition should be split into a separate item which could be referenced by qualifier. However, that might make it a bit harder to query, so it's not ideal... --Yair rand (talk) 22:07, 19 March 2019 (UTC)
I agree that the scope should be all present disputed territories; I am not sure that I agree that it should include all pasts form of disputes.
I think we absolutely need another property which included who support the claim. Otherwise we would show that, say 2 countries have the same claim to a territory, without (in the most extreme case) telling the reader that one claim is supported by every country on the planet - 1, the other claim is supported by 1 country. If we don't have a "qualifier", we would be giving each claim "equal weight", and in effect misleading our readers. Approximate numbers could be used, where the individual countries' positions could be listed as a sub property, Huldra (talk) 20:49, 20 March 2019 (UTC)
Approximating numbers seems like it would be subject to dispute. Why approximate when we can be precise about which countries in particular support a claim? Do you agree that we also should include information on which country actually governed an area at a particular time? For example, almost the entire world recognizes Taipei as being part of the People's Republic of China, although Taiwan (ROC) actually governs the area, and all countries that recognize it as being part of Taiwan also recognize Beijing as part of Taiwan, but we wouldn't want Beijing to have the exact same statements as Taipei. --Yair rand (talk) 00:56, 21 March 2019 (UTC)
Do we have a property or qualifier for what country has de facto control of a territory? - Jmabel (talk) 15:12, 21 March 2019 (UTC)
No, I don't think so. There probably should be, but it's quite a complicated thing. Is Autonomous Republic of Crimea (Q756294) a territorial entity controlled by Russia? Russia doesn't consider that administrative division to exist, as it considers the Republic of Crimea (Q15966495) to be the relevant subdivision, whereas Ukraine wouldn't consider itself the rightful government of Republic of Crimea (Q15966495), since it doesn't recognize that subdivision. There are also different degrees of "control". Is the territory run by the military, or does the country run a functioning civil administration for the area within the country's regular framework? In internal disputes by subdivisions, one side typically administers the area, but there are (usually) no militaries involved. In some areas, a military can control an occupied area without the country setting up a local government to properly administer it. "Control" and governance/administration are sort of separate things, but sometimes closely related. --Yair rand (talk) 00:13, 22 March 2019 (UTC)
@Yair rand: I think that would come down to what we consider acceptable citations for de facto control. But China presents a clear example: two governments both claiming the same territory de jure, with one in de facto control of the bulk of the territory, and the other in de facto control of the remainder (Taiwan and a few small islands in the South China Sea). - Jmabel (talk) 01:21, 22 March 2019 (UTC)
@Jmabel: While it is technically true that, for example, the United States was de facto in control of South Korea in 1945, I think that saying just that is insufficiently specific to have as the entirety of the statement (although that would be more specific than the kinds of statements we have now). Taiwan isn't just de facto controlling the islands, it is (in contrast to the 1945 South Korea situation) running a full civil administration there in the context of the country's regular governance. I think it's important to make the distinction. --Yair rand (talk) 07:23, 27 March 2019 (UTC)
@Yair rand: I don't know much about South Korea immediately after WWII, but certainly in Germany there was a period where the various allied powers established administrations that were the effective governments of their respective zones. - 15:26, 27 March 2019 (UTC)  – The preceding unsigned comment was added by Jmabel (talk • contribs).
@Jmabel: If I understand correctly, in e.g. American-occupied Germany, the area was not considered part of the US (by the US or any other country), American law was not applied to the area, and the highest authority was a military government rather than a civilian one. It still seems to me like there should be a distinction between how the US controlled that area and how Taiwan controls its territory. I'm not sure those particular attributes show such a clear division, though. Some entire countries are run by their own militaries, and plenty of countries have dependencies with separated legal systems without that tending to work like cases like occupied Germany... --Yair rand (talk) 06:06, 2 April 2019 (UTC)
Re Germany: absolutely. Never de jure even under the laws of the Occupying Powers, but certainly de facto.
In China: both governments claim de jure rule over the whole of China, but it is very clear who controls what de facto. - Jmabel (talk) 15:36, 2 April 2019 (UTC)
@Jmabel: Okay, that seems workable. I've started writing up a draft for an RfC at User:Yair rand/Disputed territories RfC draft to try to fit this into a comprehensive setup. --Yair rand (talk) 02:12, 4 April 2019 (UTC)

Korea was supposed to be a United Nations trust territory (Q985073) back then but not materialized which was not really the same as the situation of some other discussed territory. C933103 (talk) 09:54, 2 April 2019 (UTC)

@C933103: [citation needed]. --Liuxinyu970226 (talk) 04:29, 10 April 2019 (UTC)
en:United Nations trust territories gives a citation for this; it's an offline citation in Korean, so I have no idea how well it backs up the statement. - Jmabel (talk) 04:56, 10 April 2019 (UTC)

Deteoriorating P131

Once I had a hope that I can get all geographic object in Russianany country by running a query "wdt:P131* wd:Q159". But now I see a trend in geographic ontology when countries cease to be administrative territorial entity (Q56061)s, city (Q515) (and similar city or town (Q7930989)) cease to be administrative territorial entity (Q56061)s. As a consequence more and more P131s become violations and should be replace with like location (P276) or located in/on physical feature (P706). Look e.g. Vladimir (Q4113022). Is it ok? --Infovarius (talk) 20:22, 31 March 2019 (UTC)

One of the previous discussions: Property talk:P131#City: ATE or not ATE --Infovarius (talk) 20:27, 1 April 2019 (UTC)
You don't have to replace located in the administrative territorial entity (P131) by location (P276) but you should use the correct values for P131. Russia knows a lot of different types of cities and that information should be added to Wikidata. Tagging a place with city (Q515) or city or town (Q7930989) is useless because these terms are as general as human settlement (Q486972). --Pasleim (talk) 15:52, 3 April 2019 (UTC)
@Infovarius: The problem is that there are different ideas about the boundaries of administrative territorial entity (Q56061). The more restricted definition is reflected in many subclass trees, while the broader definition is reflected in P131's constraints. If the more restricted definition is to be used, we should update the constraints to use a superclass, and if the broader definition is to be used, the subclass tree should be modified. --Yair rand (talk) 19:57, 7 April 2019 (UTC)