Wikidata:Bot requests

From Wikidata
Jump to: navigation, search

Bot requests
If you have a bot request, create a new section here and tell exactly what you want. You should discuss your request first and wait for the decision of the community. Please refer to previous discussion. If you want to request sitelink moves, see list of delinkers. For botflag requests, see Wikidata:Requests for permissions.
On this page, old discussions are archived after 2 days, if they are marked with {{Section resolved}}. An overview of all archives can be found at this page's archive index. The current archive is located at 2015/01.


Add descriptions[edit]

In this days I'm working on item of Category. Someone ask to me to add descriptions also for other languages. So if user add in this table correct description and also if is necessary replace if already exist description, I can do it. I can use descriptions in MediaWiki:Gadget-autoEdit.js, but not all are correct (Wikipedia/Wikimedia) and there aren't indication about replace or not. --ValterVB (talk) 19:50, 29 October 2013 (UTC)

Shouldn't it just be the same text as in Wikimedia category page (Q4167836), Wikimedia disambiguation page (Q4167410) and Wikimedia template (Q11266439)? --тнояsтеn 20:46, 29 October 2013 (UTC)
I guess it would ideally be the same, but by default the label of Wikimedia category page (Q4167836) is equal to the sitelink, and in many languages we still have things like "Wikipedia:Disambiguation" instead of the more elegant "Wikipedia disambiguation page".
I think the auto-edit descriptions are ok except that in the "wikipedia" has been to to "wikimedia category" at some points and some languages have not yet been updated. --Zolo (talk) 22:35, 29 October 2013 (UTC)

Shouldn't we then also update pages like Help:Description#Non-article_items and Help:Description/de?--Zuphilip (talk) 14:16, 1 November 2013 (UTC)

Maybe objects with type Wikimedia list article (Q13406463) could be handled similarly? --Zuphilip (talk) 18:37, 2 November 2013 (UTC)

The French translations are wrong: Wikimedia must NOT be translated to Wikimédia (corrected in the table below). See w:fr:Wikimedia. -- Bjung (talk) 22:02, 27 December 2013 (UTC)

OK none oppose so I start to replace "Wikimédia" with "Wikimedia" --ValterVB (talk) 10:44, 11 January 2014 (UTC)

Lang description Replace(Y/N) Sign
it categoria di un progetto Wikimedia Y ValterVB (talk)
fr page de catégorie d'un projet Wikimedia Y Zolo (talk)
de Wikimedia-Kategorie Y тнояsтеn
pt categoria de um projeto da Wikimedia Y ValterVB (talk)
pt-br categoria de um projeto da Wikimedia Y ValterVB (talk)
ru категория в проекте Викимедиa Y Infovarius (talk)
sv, da, nb, nn Wikimedia-kategori Y --October wind (talk)
nl Wikimedia-categorie Y --October wind (talk)
es categoría de Wikimedia Y --October wind (talk)
gl categoría de Wikimedia --October wind (talk)
en Wikimedia category --October wind (talk)
eo Vikimedia-kategorio לערי ריינהארט (talk)
ro categorie pe paginile Wikimedia לערי ריינהארט (talk)
fi Wikimedia-luokka --October wind (talk)
cs kategorie Wikimedie Y --October wind (talk)
pl kategoria w projekcie Wikimedia --October wind (talk)

Next task:

Lang description Replace(Y/N) Sign
it pagina di disambiguazione Y ValterVB (talk)
fr page d'homonymie d'un projet Wikimedia Y Zolo (talk)
de Wikimedia-Begriffsklärungsseite Y тнояsтеn
pt página de desambiguação de um projeto da Wikimedia MisterSanderson (talk)
pt-br página de desambiguação de um projeto da Wikimedia MisterSanderson (talk)
ru страница значений в проекте Викимедиа N Infovarius (talk) 10:01, 15 August 2014 (UTC)
sv grensida 20:59, 6 November 2013 (UTC)
eo apartigilo לערי ריינהארט (talk)
ro pagină de dezambiguizare לערי ריינהארט (talk)
Lang description Replace(Y/N) Sign
it template di un progetto Wikimedia Y ValterVB (talk)
fr modèle d'un projet Wikimedia Y Zolo (talk)
de Wikimedia-Vorlage Y тнояsтеn
pt predefinição de um projeto da Wikimedia MisterSanderson (talk)
pt-br predefinição de um projeto da Wikimedia MisterSanderson (talk)
ru шаблон проекта Викимедиa Y Infovarius (talk)
eo Vikimedia-ŝablono לערי ריינהארט (talk)
ro format pe paginile Wikimedia לערי ריינהארט (talk)

disambiguation pages with additional statements[edit]

Hi! re: Wikimedia disambiguation page (Q4167410) I noticed that more and more disambiguation pages contain additional statements. Please do not add the descriptions in this case. Please let us know what pages are affected (please let us know an url). לערי ריינהארט (talk) 08:36, 26 March 2014 (UTC)

disambiguation pages causing constraint violations[edit]

Hi! Archetype (Q346973) caused a constraint violation. See . I removed the relation see .
Please verify if "special:WhatLinksHere" links to a relevant Wikidata object ("Qxxxx") and generate a report on the identified pages. Thanks in advance! לערי ריינהארט (talk) 08:55, 3 April 2014 (UTC)

@לערי ריינהארט, ValterVB, Thgoiter, Zolo, Infovarius: Let's continue below in the section wrong category item descriptions. Matěj Suchánek (talk) 09:47, 10 May 2014 (UTC)

{{Section resolved|1=Matěj Suchánek (talk) 09:47, 10 May 2014 (UTC)}}

@Matěj_Suchánek I added new languages to the list but did not see any change since then.
I think that this task should be done on a regullary base. With a report if the disambuguations are "clean"
a) no additional statements to WD dis pages
c) no normal articles from WMF projects linked to WD dis pages
d) no WD items linking to WD dis pages
e) label should always start with capital letters
f) basic quality validations (as namespace consistency across linked WMF pages, no redirect pages and no anchors at WMF project links, etc.)
The bot run should be transparent. A report and to do list should be generated. לערי ריינהארט (talk) 10:58, 10 May 2014 (UTC)
@לערי ריינהארט: I missing your request, sorry, It was a "one shot" task, but naturally I can add "eo" and "ro" label description. I can replace existing label or not? --ValterVB (talk) 12:26, 10 May 2014 (UTC)
Thanks @ValterVB for the feedback. Please add the descriptions to the set of languages. During the last months I created hundred of new WD dis pages. Maybe you start from WLH from=16800000 .
Regards gangLeri לערי ריינהארט (talk) 13:07, 10 May 2014 (UTC)
@לערי ריינהארט: I can start from beginning, but is necessary that you say how do if already exist label: replace with new label or not? --ValterVB (talk) 13:14, 10 May 2014 (UTC)
Another thing: only disambiguation or disambiguation, template and category? --ValterVB (talk) 13:17, 10 May 2014 (UTC)
@ValterVB I think it is best to start with disambiguations.
Regarding labels I think that the WMF page labels have a higher priority (for disambiguation pages). To my understanding pipes should be removed.
For disambiguations pages without English labels and with labels in languages using LATN scripts I think it is wise to add the most appropriate label. Maybe we can use the "hierarchy" defined in the list of WMF projects sorted by the number of articles.
Adding descriptions for template and category can follow later. There I have seen many descriptions added manually . They sould be preserved.
Note: If WD develops to an ontology (consists of ontological object) labels would need to describe the items and may differ from the WMF articles (explaining some aspects of these items). Normally only humans can see the differences and can chose the proper label. לערי ריינהארט (talk) 13:33, 10 May 2014 (UTC)
 ::@לערי ריינהארט: Sorry I mean descriptions not label: replace with new description or not? I don't add or change label. --ValterVB (talk) 13:41, 10 May 2014 (UTC)
@ValterVB Please replace the description(s) with the description texts from listed in the requirement in the main paragraph. These texts are up to date using Wikimedia and not Wikipedia. I have seen some English descriptions worded only as "disambiguation". לערי ריינהארט (talk) 13:54, 10 May 2014 (UTC)

Freebase identifiers[edit]

According to Wikidata:Database reports/Popular properties we currently have only about a million Freebase identifiers here (the next most common identifier is VIAF). It makes little sense to have this property half used; please import the remaining million items from [1] (CC0). --Nemo 14:31, 27 April 2014 (UTC)

Don't have sense to have freebase propriety is unuseful, don't is an ufficial source, don't is an Authorities --Rippitippi (talk) 23:40, 2 July 2014 (UTC)
It's useful for cross-referencing with other databases, as for all the other identifiers. The usefulness of the property should be discussed on its talk page, IMHO; we already have a million items using it, so it only makes sense to do it properly and finish the job. Half-baked choices don't help anything. --Nemo 11:20, 16 October 2014 (UTC)

Intel processors[edit]

Hello. Can some bot please read Intel's site and gather information from that database for the Wikidata? Its needed that it catches the name of the processors, create an item corresponding to each one and complete the item with the properties sockets supported (P1041), instruction set (P1068), manufacturer (P176) and number of processor cores (P1141).--MisterSanderson (talk) 15:58, 17 May 2014 (UTC)

Why don't you write them to ask that they release that data via a dump/machine readable API under a free license (or rather CC-0)? Even better, they could add it themselves here on Wikidata, to save us some work. --Nemo 17:16, 17 May 2014 (UTC)
I could not find an appropiate e-mail adress at, so there is no way to contact them.--MisterSanderson (talk) 18:45, 17 May 2014 (UTC)
Try any of the first four in "Intel PR Departments" [2] (calling yourself an analyst) and [3], you'll be fine. --Nemo 15:51, 23 May 2014 (UTC)
Ok, I sent them a message.--MisterSanderson (talk) 11:37, 25 May 2014 (UTC)
The contact was closed without response.--MisterSanderson (talk) 16:50, 29 May 2014 (UTC)
So the creation of the items needs to be made by Wikidata robots...--MisterSanderson (talk) 15:32, 4 July 2014 (UTC)

Today I found the link "Export Full Specifications" that generates a XML file with the data. I think this will turn easy to gather the information with bots.--MisterSanderson (talk) 15:06, 2 October 2014 (UTC)

Here, I even extracted myself manually the data and created a table: I think that now there is no excuse to not include these informations on Wikidata.--MisterSanderson (talk) 18:52, 3 October 2014 (UTC)

The table looks good. However, we can't yet add values with a dimension (e.g. Hz, MB, nm) so the only information we can now extract is the number of cores (number of processor cores (P1141). Are there already items on Wikidata about intel processors or should a new item be created for every row in the table? --Pasleim (talk) 19:15, 3 October 2014 (UTC)
Not only number of processor cores (P1141), there are other properties too: sockets supported (P1041), instruction set (P1068) and manufacturer (P176). I think that maybe there is a "release date" property too, but I could not find. And there is the subclass of (P279): all Celeron models are a subclass of the Celeron family. Some processors already have an item, but in Wikipedia is more common to create articles about a family of processors, not to individual models, so I think that each row must be an item.--MisterSanderson (talk) 22:39, 3 October 2014 (UTC)

New table: .--MisterSanderson (talk) 23:20, 6 December 2014 (UTC)

Importing coordinates from Polish Wikipedia[edit]

I've noticed that geographical coordinates have already been imported to Wikidata from most language versions of Wikipedia, but I can hardly see any imported from my own home wiki, which is Polish Wikipedia. We've got really loads of articles with coordinates, so I think it would be really beneficial to bring it all to Wikidata. Thank you in advance. Powerek38 (talk) 08:50, 24 May 2014 (UTC)

Hi Powerek38, I've been importing coordinates from several Wikipedia's. Maybe you could set up Wikidata:Coordinates tracking at the Polish Wikipedia? After that I'm more than happy to do the import. Multichill (talk) 09:06, 24 May 2014 (UTC)
Thanks a lot Multichill, I'm not really a very technical user, so I've just set up a discussion in our coordinates wikiproject, so that my more able collegues can check if we can meet this requirement and how to do that. Feel free to join in if you have any hints, all members of that project understand English with no problems. Powerek38 (talk) 09:28, 24 May 2014 (UTC)
@Powerek38: Enabling it isn't that difficult. You just have to get pl:Moduł:Koordynaty modified like en:Module:Coordinates (example). It looks if the coordinates are displayed in the title and than looks for coordinate location (P625) to add the different tracker categories. I'll post this at the Polish Wikipedia too. Multichill (talk) 09:38, 25 May 2014 (UTC)
Ok. The category is created and I'm now importing. You'll see a error message on the coordinates. That's already fixed in the code (see bugzilla:62105 ) and will probably be deployed soon(ish). Multichill (talk) 18:27, 27 May 2014 (UTC)
Thank you very much for your help on this, Multichill! Powerek38 (talk) 16:49, 30 May 2014 (UTC)

We still have the same problem in cawiki. Although Ladsgroup (talkcontribslogs) and others did some work in it, there are still over 15.000 articles with coordinates to be imported in ca:Categoria:Articles amb coordenades sense coordenades a Wikidata (a few of them are people with burial places, but most articles in category are places to be imported). @Multichill:--Pere prlpz (talk) 15:56, 8 September 2014 (UTC)

I wrote and It's part of pywikibot. Anyone else with a Pywikibot can easily do this ( -family:wikipedia -lang:ca -cat:Categoria:Articles_amb_coordenades_sense_coordenades_a_Wikidata). Maybe someone else wants to try this to get the hang of it?
I'm not sure when I get to it myself. Multichill (talk) 19:32, 8 September 2014 (UTC)
@Multichill, Pere prlpz: My bot is doing it now. I hope there aren't too many items in this category which shouldn't have coordinates... — Ayack (talk) 19:45, 8 September 2014 (UTC)
Great Ayack! bugzilla:65430 got fixed so if you import coordinates on persons or companies, people can move them to be qualifiers to for example the place of death and these won't be imported again. Multichill (talk) 19:49, 8 September 2014 (UTC)

@Ayack: ca:Categoria:Articles amb coordenades sense coordenades a Wikidata has grown again to 852 articles with coordinates in cawiki without coordinates in Wikidata, most of them cultural heritage monuments. Could you import coordinates again?--Pere prlpz (talk) 14:03, 8 October 2014 (UTC)

Importing Commons Categories (P373)[edit]

Dutch Wikipedia has a nl:Categorie:Wikipedia:Commonscat zonder link op Wikidata (Commonscat without equivalent in Wikidata). From there the P373 statement could be filled. -- Pütz M. (talk) 23:13, 13 June 2014 (UTC)

In en:Category:Commons category without a link on Wikidata is even more. -- Pütz M. (talk) 23:28, 13 June 2014 (UTC)
 Writing something up for this, I'll work on it as much as I can. George Edward CTalkContributions 19:25, 15 January 2015 (UTC)
@George.Edward.C: any progress in this or do you know how to do that? We would like to import commonscat links from fi-wiki to Wikidata. --Stryn (talk) 17:59, 21 January 2015 (UTC)
Doing the parser right now. Will work on it more at the weekend. If I can figure out the parser, it should be easy to complete the rest of it. When I've written it, and it works, I will run both NL and FI after that. George Edward CTalkContributions 18:05, 21 January 2015 (UTC)
Please don't run a bot on nl. There are a lot of conflicts in them, also a lot of pages with double templates. Sjoerd de Bruin (talk) 18:12, 21 January 2015 (UTC)
Noted. :-) The bot will only run on EnWiki and FiWiki (as long as there's no problems with either of them). (Edit: I will probably need a category similar to those mentioned in the reques') George Edward CTalkContributions 18:23, 21 January 2015 (UTC)

Add instance of (P31) from MusicBrainz Artist Type via MusicBrainz artist ID (P434)[edit]

We can leverage the existing links between Wikidata and MusicBrainz to populate instance of (P31) for the people and groups linked with MusicBrainz artist ID (P434). Specifically, the bot would add human (Q5) if the MusicBrainz Artist Type was "Person", and band (Q215380) if the Type was "Group". The reference would be imported from (P143) MusicBrainz (Q14005), as with the MusicBrainz identifiers. If User:Mineo is interested, this could be an additional task for User:MineoBot -- or someone else could take it on. JesseW (talk) 06:21, 8 July 2014 (UTC)

What about duos, orchestras, non-performing personnel (compsers, producers etc)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:18, 14 September 2014 (UTC)
That shouldn't be a problem for the first case (adding human (Q5)). It's a good point about automatically adding "Group" entries, though. MusicBrainz now categorizes some items in more detail (with orchestras, choirs, etc.) so those might be useful. JesseW (talk) 06:40, 5 December 2014 (UTC)
We should not describe, say, Simon & Garfunkel (Q484918) as an instance of (a) human (Q5). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 5 December 2014 (UTC)
I agree -- and they wouldn't fall under the first case, as they are identified as a Group on Musicbrainz (as can be seen here), not a Person. Do you see any problem with the first case (adding human (Q5) to items linked to "Person"-type MusicBrainz entries)? JesseW (talk) 06:53, 13 December 2014 (UTC)
I think "Group" in MusicBrainz is actually closer to instance of (P31) musical ensemble (Q2088357). According to, orchestra (Q42998) is not currently a subtype of band (Q215380), whereas in MusicBrainz "Orchestra" is a subtype of "Group". -- Nikki (talk) 03:17, 5 January 2015 (UTC)
I agree, musical ensemble (Q2088357) is a better choice. Thanks for finding it. Now we just need to find someone interested in coding and running it... JesseW (talk) 06:01, 15 January 2015 (UTC)
I can take this from 24 January. --JulesWinnfield-hu (talk) 11:55, 15 January 2015 (UTC)

I've made ten test edits. May I proceed? What about types other than “Person” and “Group”? --JulesWinnfield-hu (talk) 15:34, 24 January 2015 (UTC)

Should Anonymous (Q10920) be instance of a musical ensemble? Do anyone know how many groups that aren't realy about music exists on MusicBrainz? If there are only a few then I guess it's better to mark everything up and try to fix the few that's strange, however if there are many I think we need to make sure that the group actually is about music. --Pajn (talk) 09:28, 25 January 2015 (UTC)

English descriptions[edit]

Would it be possible to have a bot go through the items linked on User:Haplology/a_an_the and remove "a", "an", or "the" from the beginning of the descriptions to bring them in line with Help:Description? Cheers. Delsion23 (talk) 20:04, 1 August 2014 (UTC)

@Delusion23, Haplology: I could work on this, but I'm not sure if I can remove all "a", "an" and "the" at the beginning of any English description because in Help:Description it is stated that some phrases require the initial article. --Pasleim (talk) 19:23, 3 October 2014 (UTC)

Move values, qualifiers and references from instance of (P31) to heritage status (P1435)[edit]

A new property, heritage status (P1435), has been created for heritage monuments. Therefore, items in the following list have to be moved from instance of (P31) to heritage status (P1435) with their qualifiers and references.

Thanks. — Ayack (talk) 19:07, 2 August 2014 (UTC)

Symbol oppose vote oversat.svg Strong oppose to removing instance of (P31), I don't care about copying. Multichill (talk) 21:41, 2 August 2014 (UTC)
@Multichill: Could you explain why you are against this, please? Subject has already been discussed here. Thanks. — Ayack (talk) 09:22, 3 August 2014 (UTC)
@Ayack: instance of (P31) can be used for any item, as a universal Help:Classification tools. Anything can be classified as such. This is useful for tools like Reasonator who can search the nature of an item checking this property, and generic tools can show the associated subclass tree. By creating specific typing properties we break that and it's not a path I would like the project to take, it will make harder to build tools and we would have to write a lot of specific code to do things like we did with instance of (P31)/subclass of (P279). Plus in languages like OWL, a reference in the semantic web, there is strong liogical foundation for class definition, classes are defined by queries about the properties of an item (eg. the Woman class can be defined as the set of human beeings with female sex). This could prove very handy and make the whole powerful enough without the need for specific typing properties. TomT0m (talk) 16:54, 5 August 2014 (UTC)
Symbol oppose vote oversat.svg Strong oppose per multichill and me. I'll add this is an opposite work comparing removing 60 search above. If we need a direction, it's not really handy to go one step in one direction and the other step in the other. To be a little bit more soft, I'll say we can use class definitions to link the new property to the already existing classes : We can define the monument historique inscrit (Q10387575) (View with Reasonator) class by an equivalent of the class expression this class is the class of all item who are monument with [the appropriate patrimonial status property values]. TomT0m (talk) 16:59, 5 August 2014 (UTC)
@TomT0m: This is not really comparable with invalid ID (P60). The primary p31 value for the Earth or the Sun should be something like rocky planet and yellow dwarf, so that "type of celestial object" is completely redundant with p31. Not so with heritage status (P1435). The most obvious, and most informative, p31 values for the Palace of Versailles and Notre-Dame-de-Paris should be something like palace and cathedral, certainly not "monument historique classé. Admittedly, we can make as many p31 statements per item as we like, but putting everything in p31 is not really convenient either. For instance, if the Palace of Versailles has only "monument historique" as a P31 value, it would not be returned in a query for items with missing p31, while really it would be better if it did.
On a more structural level, I do not know know what the best supercalss for "monument histirique" should be, but something like "protection status" seems much more useful than "building", and "protection status" would hardly be a fitting superclass for the Palace of Versailles. -Zolo (talk) 17:56, 5 August 2014 (UTC)
@Zolo: We're conflating several things: The <protection status> class, as a set of status, and probably the domain of the protection status property, and the set of all monuments with some status. OWL gives us a method to link the two : let the protected palace the class of all palaces with some protection status. By definition this class is a subclass of palaces. So we can easily define <cathédrale classée> as both a subclass of <cathédrale> and <monument classé> in OWL. This saves headeachs by not to have to make sometimes difficult and arbitrary classification choices, and with a good query engine, if you query all the cathedrals instances, it will return also the instances of the subclasses. This is totally expressable with a class expression in the OWL language and a solid foundation for any classification of real world objects. As I like to say, those kind of class expression makes the definitions of a class by property not redundant : we do not have to choose beetween putting an information on instance of (P31) or in a property, as the definition of classes can be made wrt. the other properties values. Conversely, to class a cathedral, some human can conveniently only put in in the class of <cathédrale classée>, which imply it probably have a statement about its conservation status. This is very flexible. TomT0m (talk) 19:12, 5 August 2014 (UTC)
Of course we could say that. By the same reasoning, we could also say that there is the architectural style as a set of architectural styles and the set of all monuments with some architectural style. It would follow that we should actually have "instance of gothic cathédrale classée". Should we really create, translate and maintain items about the 10000s possible combinations like this ? The type of building has nothing to do with the protection status. Packing them in a single statement, and then unpacking them for analytical purposes adds a layer of complexity, and of fragility (every error in the subclass tree has drastic consequences). If we say that "monument historique" is an instance of protection status there is really no difficult choice. Items like "cathédrale classée" would serve no purpose and could safely be deleted.
"Instance of cathédrale classée" has various issues. A tool autodescribing Notre-Dame de Paris should say it a "cathedral", perhaps a "gothic cathedral" but certainly not "it is a cathédrale classée". And if the p31 value is "cathédrale classée", that would be very difficult to do.
"Notre-Dame de Paris is an instance of cathédrale classée" has been true only since 1862. So "instance of cathedrale classée" would be wrong without temporal restrictions. A "since 1862" qualifier may correct for this, but then we would have no p31 value for Notre-Dame before 1862. And so we would need to add a new "instance of cathedral" statement to correct for this. And then that would start to be real messy. --Zolo (talk) 20:32, 5 August 2014 (UTC)
@TomT0m, Zolo: What about McAdam Railway Station (Q287207) who have four different heritage designations? Create a instance for a unique subject is kind of useless. --Fralambert (talk) 15:16, 12 August 2014 (UTC)
@Fralambert, Zolo: Because we have some combinations does not mean we should have them all. Moreother to state that an object is an instance of several class we do not have to create an item for the most specific class we could create, we can just add several instance of (P31) statements, which will get rid of the combinatorial explosion. It's possible that there should be limit, I don't thik that really strict guidelines are really something we should fighr for when wwe can easily handle some of these class that may be of interest for some reason. There is a lot of monuments, there is less monuments that organisms decided to declare of interest, which make them particulars. TomT0m (talk) 12:11, 17 August 2014 (UTC)
@TomT0m:. You were proposing values like "cathédrale classée". Of course we can have "p31: classée church + P31: cathedral". That clearly requires less items, but it still suffers from the same issues. Even 1 type of heritage status with 5 types of buildings for each country requires 1000 items. And maintaining that seems tedious and pointless. And it also may cause some problems similar to that of Commons "intersection category". If you know that castle (Q23413) has many subclasses, then you know that items that are marked as "instance of castle (Q23413)" could probably use a more specific p31 value, that would better the type of building. But if you have subclasses like "classé castle" that do not tell anything about the building itself, that becomes much more complicated.
Actually, between the two, I like better the solution consisiting in using only values corresponding to a real heritage status ("monument historique classé" rather than "cathédrale classée), but it is still affected by the issues mentionned above. Plus, if you accept my point that it is more useful to see "monument historique" as a subclass of "legal status" than a subclass of "building", then we would have to duplicate every heritage status item ("monument historique" for heritage status (P1435) and "monument historique building" for instance of (P31)).
Sure there are cases, were it would be nice to have info about the heritage status in p31, just like there are cases where it would be convient to have data about a person's profession in p31, but I think it is swamped by the drawbacks in terms of readability. Using p31 for the "type of building" (~form + function) is already tricky enough, better if we can avoid a new layer of complexity on the values. --Zolo (talk) 05:57, 20 August 2014 (UTC)
@Zolo: « Plus, if you accept my point that it is more useful to see "monument historique" as a subclass of "legal status" than a subclass of "building" » Not only I don't accept it, I think this is totally ill defined and not correct. Do we really have a set of particular status, who forms a class of legal status here ? Then monument historique classé is a class of legal status indeed, whose instances are particular legal status. But then the label is misleadinq : it is referring to monuments, not to legal statuses, which suggests its instances are monuments. A better label could then be "statut de monument historique classé". Actually the item about the class of monuments already exists, see monument historique (Q916475) (View with Reasonator) , note that the introduction sentince of the french article is « Un monument historique est, en France, un monument ou un objet recevant par arrêté un statut juridique destiné à le protéger » which is pretty much exactly what I'm trying to express. I think the «Legal status» property is something different, it is more close in essence to a set of laws applying to monuments (or people, …). Note that the «monument classé» class is higher level as it regroups monuments with several particular legal statuses.
But if you have subclasses like "classé castle" that do not tell anything about the building itself, that becomes much more complicated. I don't really see the problem here, someone may add a more specific statement about the nature of the building as there may be several instance of (P31) statements. The combinatorial explosion problem ruled out, I don't understand what problem there is, having a legal status property is absolutely not mutually exclusive, it might not have the same granularity of the general classification system. The problem I see with discriminating the classes we can create wrt. instance of (P31) and the classes if that it is very subjective and that you can use a lot of criteria to class building. Deciding that the castle cathedral axis is better than the building is better than the material they are made of axis as main criteria is not up to us. But what's for sure is that the classe/non classe axis is of general interest : the article preexists. But I think that classes, as a generic mechanism, needs more specific properties (like properties expressing the intended usage of a building or object, or the kind of material he is made of). This indeed can help to define classes of buildings. This needs a little bit of judgment to choose them but I'm against hard principles like intersected categories are evil, the monument historique (Q916475) (View with Reasonator) proves, although it is the intersection of building and object with a legal status, that it is a class of interest.
I realize my initial position was maybe a little hard : I'm for the introduction of the legal status property, I'm just not for the deletion of every and all of the classes. I wold add that it as several advantages : the whole class tree can be presented using templates like {{Classification}} or reasonator, which alloas to present in a concise way with a granularity someone may understand : you may not be am expert in legal statuses but know what a «monument classé» is, the hierarchical nature of classes allows to presnt the relevants information at several granularities in a concise way. Good choices for classes will allow us to be efficient into presenting informations about an item in a useful way both for experts and nonexpert, maybe it should be one of the principles who will guide us in item classification.
@Zolo: One more thought That jist occured to me, about combinatorial explosion and queries : I don't think queries will be of any help in the forseable dev plans: we will have to create an item per query. Which means queries will suffer the exact same problems with intersections and won't help keep the number of items down. Therefore, as both queries and classes are associated to a set of instances in one case and results in the other, they are conceptually very similar and two faces of the same coin. TomT0m (talk) 14:20, 20 August 2014 (UTC)
@TomT0m: But if you have subclasses like "classé castle" that do not tell anything about the building itself, that becomes much more complicated.. What I meant is that the most useful subclasses of castles are things that tell you what type of castle this is. motte-and-bailey castle (Q92062) is a type of castle (a castle built on a motte etc.). But "classé castle" is not really a type of castle - it is just a castle that is at the same time a monument historique classsé. Suppose an expert wants to add better p31 values for castles. The most obvious starting point would be to look for items that are instances of castle, but not instances of subclasses of castle. If something is "p31: classé castle", it will not appear in the list.
We could also get around this issue by using classes like: "castle by type" and "castle by protection level", but that requires a really well maintained class system, and I do not think we should count on that yet.
This question is not really the granularity level but rather: what sort of information do we expect to find in p31. We have separate properties for the architectural style, the material used, the protection status. If we are looking for information about that, we should rather use those properties. Repeating them in p31 has probably some benefits, but it also makes a lot of not-very-useful redundancy and makes the structure of the item harder to grasp.
What I seem to guess from meta:Wikidata/Queries is that it will (at some point) be possible to make queries based on several property-value cconstraints, but it may not be possible to do queries based on subclasses. This would make "intersection items" like "classé castle" unnecessary - and even harmful if this leads some user to remove the additional "instance of castle" that would be of use in other queries. --Zolo (talk) 15:15, 21 August 2014 (UTC)
@Zolo: I think you don't really understand really well the foundations of instance of (P31)/subclass of (P279). We can totally call a type of castle a castle of a certain architectural style of some time period, because experts, for some reason, usually treats those castles together. The solution to group the classes in metaclasses is a promising path : It could gives good foundations to our classes. If an expert built a classification of castles using some criteria, we can regroup the classes he created in a metaclass, and make the classes instances of this metaclass. He could have used any criteria to regroup the castles, he could build a class "medieval castles" because they are very different from post-medieval ones, yet the information is redundant with the year the castle was built. Yet he built a class of castles, and <medieval castle> will be a type of castle in his classification. I don't think it is especially hard to maintain if we find good classifications in litteratures. Good classifications are built with some criteria, this criteria might be informations we already have about castles with other properties. TomT0m (talk) 16:27, 21 August 2014 (UTC)
@TomT0m: i don't know what makes you think I don't understand the foundations of instance/subclass. By type of building, I just mean its purpose/architectural pattern, not anything ontological. That would be the "dénomination" parameter of Mérimée's monuments historiques database (if you don't mind terrible ergonomy, you can find it at -> vocabulaires -> type d'édifice -> liste hiérarchique).
I am not saying it is wrong to use p31 for protection status (depending on how the protection-status items are defined), just that it is not convenient. If we have two separate metaclasses "building by type" and "building by status", that may be manageable, but still much more complicated than using separate properties. --Zolo (talk) 16:55, 21 August 2014 (UTC)
@Zolo: It's because you seem to argue that instance of (P31) is mainly here to add information about the castle that is not present in the other properties. Actually it is quite the opposite : What defines the type of an item is exactly its properties, and we only have a fraction of its properties in the database, and we regroup in classes items with somehow similar properties. Actually I would not oppose having a purpose and architectural pattern properties. Then if we can class buildings (not castle suddenly :)) using their purpose and build patterns. Actually this would make explicit which criteria are relevant to class those objects, even if it is a combination of properties, which is actually very often the case. I think if we do not reason like that this defeats the purpose of having a unique main typing property and we can consider almost each properties as typing properties. The merimée database hierarchical classification of building is clearly a classification choice : The class building first by purpose, putting every building related to the army in the same class. I think it's a legitimate choice and I would support having such a class in Wikidata, which in turn could be marked as instance of <Mérimée building classification class>. But other organisms could class building using other criteria or other hierarchy and that would be another legitimate choice. Another more technical reason, classes are used to be the domain and range of properties. If we know that a certain type of building has always some property, and that it does not follow a natural community classification hierarchy, then it could be technically convenient to create the class to express easily constraints about the domain and ranges of the property for example. If, this does not fit in Mérimée classification, for example if a property apply to buildings in a certain area, then we would have to not follow it and put classes for some castles that absolutely do not follow this scheme. In short I don't think that what you are looking for here to state architectural patterns or purpose of a castle is instance of (P31)/subclass of (P279) at all. Those two properties are more synthetic way of giving information about their instances : if you know an item is a human, this is a lot of informations already. But classes can't solely gives information not countained in the properties of an item, whether or not Wikidata is powerful or complete enough to know them. TomT0m (talk) 18:44, 21 August 2014 (UTC)
@TomT0m:. I do not think the purpose of p31 is to put things that we do not know where to put, but rather that it should be only contains a few values that describe most relevantly and most durably what sort of thing the item is. Just like we use human (Q5) for humans, rather than the tons of other things that individuals are instances of.
I agree that we should try to define better critera for classifying buildings, but the way the "type of building" (church, castle...) mixes purpose and form of the building is rather tricky. I think most people would still call a disused church an instance of church, but inferrence wise, it would not be really compatible with church (Q16970) <use (P366)  cult (Q756820)
@Zolo: It is compatible. It's easy to make the link. Let's define «a church» «a building that once has been used for cult». That should be possible using a well grounded classification systems like OWL classes defined by class expressions (although it does not uses qualifiers), informaly at least. I disagree with your instance of (P31) intended usage, it should be more powerful than that and should allow different POV expressions. Even more advanced classification than just those for which most people would agree on. Even maintenance classes like we have maintenance categories. The question is whether or not those two goals are compatibles and what to do if they are not. Maybe ranking is a partial answer. I think that commons cat are a reference: I think our classification system should allow to do everything commonscat achieves, but in a better defined way. I don't think queries are the ultimate answer to this as both an index-style information browsing and queries have their usefulness, and because good classifications ARE actually knowledge. And sourcable one sometimes. And queries can be hierarchically ordered, just like classes, by for example inclusion of their results. Just using arbitrary queries allows us not to make classification choices. But maybe it would be a lost opportunity to express valuable knowledge in a well thought and defined OWL-like way, and profit the associated toolset and community knowledge (dbpedia uses classes a lot for example). TomT0m (talk) 12:29, 22 August 2014 (UTC)
@TomT0m: to me "use" would be most naturally interpreted as current use (for instance, a disuses church should not appear on a map of cult facilities. There are certainly ways to solve this, but it would mean using somewhat more complicated solution that "some church instance of church; church: use: cult". Anyway, this is probably not the right place to discuss it. --Zolo (talk) 05:56, 23 August 2014 (UTC)
Of course, it's a simple example. But an illustrative one actually : in different context what we refer to a church may differ, which makes not so simple a single value instance of guideline. But in Wikidata (temporal) qualifiers can be a real help to model things : let define a repurposed church a building who had a religious purpose but another usage nowdays.
@Zolo: I guess at that point we can only act the disagreement. I am totally on the same page with Nemo_bis on your initial discussions on the Wikiproject page, I think the issues you mentions about creating a lot of items are not valid. I think OWL class expressions are a really solid base for a generic constraint system ( a little bit too solid actually as we can't use it yet:) ). I can fear emerging tensions between those who understand well our generic classification system and can quickly add relevant classes to items without a lot of noise and quircks and those who will take a longer path with a lot of discussions and all, with imho no clear really outcome, the subclass hierarchy here seemed really fine to me, the objects are classes, and we can(ould)? query them as instances of some metaclass. Maybe what would be important is to make our constraint system more expressive, this would make Fralambert's argument less relevant (Pinging them ^^), is there a Ping project ? this could accelerate the decision, we are not really good at decision making, which is why I enjoy the quiet generic path :) TomT0m (talk) 09:29, 23 August 2014 (UTC)

@Zolo, Fralambert: A more expressive constraint system will be surely welcome. Like Wikidata:Database reports/Constraint violations/P1435 not realy work like I like (I don't want the subclasses of the item, but the list of item itself. The main reason that I approve the cration of P1435 is that the number protection statuses is really diverse. If you look this document between the page 57 and 63, you can see all the possible result only for Canada. There is actually 5 differents protection statuses for the Federal and 13 for my province (Quebec). The other problem is the is not a international register (or at least a international codification like (WDPA id (P809) for protected area). To have something for see result like[17%3A39]%20AND%20CLAIM[1435] is to much to ask? --Fralambert (talk) 14:44, 23 August 2014 (UTC)

@TomT0m: Is heritage status (P1435) a subproperty of instance of (P31)? If so, does it matter much to use heritage status (P1435) instead of instance of (P31), but with the benefit of having specific constraints?--Micru (talk) 14:59, 23 August 2014 (UTC)

Micru, there are no subproperties of instance of (P31). Instance of has the semantics of rdf:type and subproperties of rdf:type are not valid in OWL 2 DL. Emw (talk) 15:24, 23 August 2014 (UTC)
@TomT0m, Emw:. I played around a bit with the data in the past few days. It is true that using p31 as catchall can be convenient. See Template:Is a that returns true if param 1 is an instance of param 2. Stil, and even though they are not standard, I think subproperties of p31 could bring the best of both worlds. --Zolo (talk) 09:06, 27 August 2014 (UTC)
It seems we don't have any consensus on what to do about the change from instance of (P31) to heritage status (P1435) . I am concerned that the lists may be diverging as some editors make the change manually, so that neither query will return a complete list. Is there somewhere else that this has been discussed that I missed? - PKM (talk) 02:52, 23 November 2014 (UTC)

discussion continued on Wikidata talk:WikiProject Cultural heritage#Irksome issues with p31--Pasleim (talk) 10:06, 21 January 2015 (UTC)

Move claims P527 to P1383[edit]

has part (P527), contains settlement (P1383)

Villages and settlements in Belgium and Netherlands (and maybe other countries) which are listed in P527 claims should be moved to a new, (better) property for this purpose (P1383). A bot should loop over all Dutch and Belgium municipalities and move P527 to P1383. Michiel1972 (talk) 13:18, 5 August 2014 (UTC)

I don't understand how this property is useful. did not has part (P527) plus instance of (P31) <locality> statements did a good job ? TomT0m (talk) 16:44, 5 August 2014 (UTC)
True. The new property P1383 was/is in my opinion not needed, see my comment Property_talk:P1383. However, it has been used already on many items. So what to do? Michiel1972 (talk) 16:54, 8 August 2014 (UTC)
The settlements are not parts of the municipality. I would use contains administrative territorial entity (P150), but it can't be used because of a constraint. I propose to use P1383 or merge P1383 with P150 and remove the constraint. --JulesWinnfield-hu (talk) 17:25, 8 August 2014 (UTC)
I started a deletion request because I think P527 is valid. (Wikidata:Properties_for_deletion). Michiel1972 (talk) 11:40, 15 August 2014 (UTC)

Scanning off service as Roman consul[edit]

Could a bot read off en:List of Roman consuls, la:Fasti consulum rei publicae, uk:Список магістратів-епонімів Римської республіки, en:List of Roman dictators etc., and, where the name listed has a blue link, add, as appropriate, position held (P39): Roman consul (Q40779), position held (P39): Consul suffectus (Q629712) (consul suffectus), or position held (P39): Roman dictator (Q236885) (dictator), with start and end dates? As an example, I did one here. N.B. some individuals (e.g. en:Lucius Papirius Cursor) held office more than once (cf. Grover Cleveland (Q35171)). It Is Me Here t / c 12:29, 17 August 2014 (UTC)

wrong category item descriptions[edit]

There should be corrected many wrong descriptions of category items.

  • I’ve often found in the descriptions for Dutch (nl:) "Wikimedia categorie" which had been added by a bot. It has to be "Wikimedia-categorie" instead, that’s no Dutch grammar, see also Wikimedia category page (Q4167836). I’ve corrected a lot of items, but there still are many more mistakes I think.

And there often are descriptions with wrong capitalization of the first letter, also added by bot:

  • It should be "categoría de Wikimedia" in Spanish (es:), not "Categoría de Wikimedia" or "categoría de Wikipedia" (which I also corrected very often, the same is the case for the following errors),
  • "categoria di un progetto Wikimedia" in Italian (it:), not "Categoria di un progetto Wikimedia",
  • "categoria de um projeto da Wikimedia" in pt:, not "Categoria de um projeto da Wikimedia",
  • "page de catégorie d'un projet Wikimedia" in French (fr:), not "Page de catégorie de Wikimédia". But the label of Wikimedia category page (Q4167836) for French isn’t anything with "page", just "catégorie de Wikimedia" (which has been "catégorie de Wikimédia" up to now, but this differs from the French article fr:Wikimedia). So there’s much chaos, but most of the French descriptions are "page de catégorie d'un projet Wikimedia" now, so it would be better to leave that with "page de".
  • I’ve also often changed the Russian description "категория в проекте Викимедия" to "категория в проекте Викимедиа". The я is wrong there, as can be seen in Wikimedia category page (Q4167836) and on the main page of the Russian Wikipedia or in the article ru:Фонд Викимедиа. Also for Russian is another label in Wikimedia category page (Q4167836), perhaps the label there is wrong? I haven’t found that version in any item.
  • I also don’t understand, why there are often Swedish descriptions "kategorisida" which means "category page", while the term should say "Wikimedia category" which is "Wikimedia-kategori" in Swedish, this is also the label in Swedish in Wikimedia category page (Q4167836). I don’t see any need to leave out the word "Wikimedia" just in that language. There exist two different descriptions in Swedish now which means that new categories with "Wikimedia-kategori" as description will not be identified as existing by the system, when there already exists the same label with the description "kategorisida", also the other way round. That means that a person who adds the same label to a new created item will not get an error message, because the descriptions are different.
  • The same is the case in English, where there exist "Wikimedia category" and "Wikimedia category page" and also "Wikipedia category page" (or was it "Wikipedia category"?, too many different versions – i.e. "Wikipedia category" here), so that noone knows which one shall be taken.

It would be the best to have just one description for category items for each language and not two or more different ones. Then wrong descriptions can be identified better, and double items can be found better. --October wind (talk) 22:16, 30 April 2014 (UTC)

@October wind: At the moment I'm trying to replace some descriptions in Wikimedia category page (Q4167836), let's see how many users will (not) agree. There was a discussion above but I suggested to continue here. Matěj Suchánek (talk) 09:52, 10 May 2014 (UTC)
That’s good. There was an old discussion above, where it wasn’t even clear to me, in which direction the descriptions had been changed there, so I thought, it would be better to start the discussion new. Perhaps something can be taken from above, I don’t know.
I changed English to "Wikimedia category" in Wikimedia category page (Q4167836), because I think that is the normal form without "page" (usually taken as descriptions for category items in English and in other languages except French, I think). Therefore, it wouldn’t be good, if only English should be changed back to the version with "page". But perhaps there might be a statistic anywhere, how often the 4 English descriptions are used by now: with/without "page", with "Wikimedia" or with "Wikipedia" (which should not be used anymore). If the version "Wikimedia category page" should be the English description in most of the category items, then the others can also be changed to that version. I just don’t have this impression by now. In French, I only saw descriptions with "page de", but not in English, so I prefer the version without "page" there. If English should use "page", then other languages’ descriptions would also be changed by other people to versions with "page" in the translations, and then we have the same problem again. So, it’s better to have some kind of identical descriptions in many languages, then there will be less chaos later. --October wind (talk) 22:15, 12 May 2014 (UTC)
In the section above, there are listed "категория в проекте Викимедия" for ru: (which is wrong) and "kategorisida" for sv: for example, and I can’t see, if those are replaced by "категория в проекте Викимедиa" and "Wikimedia-kategori" (they should be replace this way) or if other correct (or other wrong) descriptions are replaced by those wrong descriptions, so it is better not to use the descriptions from above for category items. The other category descriptions seem to be right there and don’t need to be replaced, so I don’t know, in which direction descriptions are replaced or added there. There is a Y after those descriptions, which can mean, that those wrong descriptions have been replaced or that correct descriptions and other wrong descriptions are both replaced by those wrong descriptions. That’s a bit confusing to me. And the description for eo: in Wikimedia category page (Q4167836) is "kategorio en Vikimedio" now, above it is "Vikimedio-kategorio". So, was "kategorio en Vikimedio" replaced by "Vikimedio-kategorio" or what? That’s all too confusing. --October wind (talk) 22:37, 12 May 2014 (UTC)
"Y" mean: add label if don't exist or replace existing label with new label, without "Y" I don't replace existing Label. --ValterVB (talk) 19:16, 13 May 2014 (UTC)
Ok, then ru: and sv: should be changed above, so that they aren’t used anymore in that form, and eo: should be discussed. Why is there an Y behind the wrong Russian version (see links in this section)? It can’t be right that the main page of the Russian Wikipedia and the Russian article about Wikimedia and also Wikimedia category page (Q4167836) all are wrong, so I fear there have been replaced and added a lot of wrong Russian descriptions. Who added this description there or the Y? Did noone look at all those Russian spellings (which are all the same and all with a) before changing or adding wrong descriptions? Very strange. --October wind (talk) 23:18, 13 May 2014 (UTC)
  • There are also a lot of Finnish (fi:) descriptions "Wikipedia-luokka" which should be changed into "Wikimedia-luokka".
  • Then, there are the wrong descriptions "kategorie Wikipedie" in cs: and "kategoria Wikipedii" in pl:. Which descriptions with "Wikimedia" are right there, is it "Wikimedie" and "Wikimedii" instead?
  • "Kategorie op Wikipedia" in nds: can be "Wikimedia-Kategorie" instead, perhaps also "Kategorie op Wikimedia"? I don’t know which is better there.
  • "Wikipedia-kategori" in Danish (da:) should be changed to "Wikimedia-kategori". This should be the description in da:, nb:, nn: and sv:, not "Wikipedia-kategori" and not "kategorisida" or something like that.
  • Also gl: "categoría de Wikipedia" should also be changed, perhaps into "categoría de Wikimedia" (the same as in Spanish). Which language is that? --October wind (talk) 23:11, 12 May 2014 (UTC)
In Wikimedia category page (Q4167836), cs: is "kategorie Wikimedie", so it should be changed this way. And pl: is "kategoria w projekcie Wikimedia" there, not "kategoria Wikimedii", so maybe take this one instead? I’ll add those two also above. --October wind (talk) 23:59, 13 May 2014 (UTC)

the bot should check if all linked pages are categories. it's annoying to revert such edits if they are wrong --Akkakk 09:35, 14 May 2014 (UTC)

The bot can check this, if it adds new descriptions, but this bot request is only to correct those lots of wrong descriptions which already exist. The wrong descriptions "Wikimedia categorie" (nl:), "категория в проекте Викимедия" (ru:) or those with "Wikipedia" instead of "Wikimedia" should be corrected in any case, even if in another language there might be a wrong link that doesn’t link to a category or if there might be a bigger error in an item. If those errors would not be corrected, the wrong descriptions would be taken also for other category items. That’s not good, because there are problems with this (see above, there is no error message, when there are two items with the same label and different descriptions). I think a bot should just correct the wrong descriptions, so that there is afterwards just one description for each of those languages and not two or more. I don’t think that anyone would need to revert any of those bot edits, because then also those wrong descriptions would be wrong now which they are anyway (and not after the bot run). It doesn’t matter, if the descriptions are wrong, because it is wrong grammar/spelling or because it is "Wikipedia" instead of "Wikimedia", or if the descriptions are wrong, because it is no category item, they are wrong anyway. So there will be added no error that isn’t already existing now. It could only be that an already existing error could be found by such a bot edit, but then the whole item would have to be corrected anyway and a bot revert wouldn’t be enough.
By the way, wrong spelling and wrong grammar would also be corrected in Wikipedia articles, even if the article is being discussed and isn’t relevant at all, so there’s no reason not to correct errors, because there might be more errors with some of the items. ;-) --October wind (talk) 22:27, 14 May 2014 (UTC)

This section shouldn’t have been archived either. There is no message that anyone has fixed those lots of wrong descriptions. It’s not something that can be done by users, that’s too much work. Please don’t archive sections without resolving the problems. How can this be prevented? --October wind (talk) 18:58, 11 September 2014 (UTC)

@October wind: I can fix wrong description, but is necessary a clear instruction for every language. Maybe is necessary fix also MediaWiki:Gadget-autoEdit.js --ValterVB (talk) 19:26, 11 September 2014 (UTC)
Oh, yes, the gadget should also be changed (if necessary) or something added there. "Wikimedia-categorie" for nl: is missing there, for example. And why is the English description for "Wikimedia category" "Wikimedia category page"? "Wikimedia category" is English already, so the word "page" should be taken away there such as it is in the other languages and in very many English items already. "categoria de um projeto da Wikimedia" for pt: is also missing there. The other descriptions seem to be correct there. Cs: has "kategorie na projektech Wikimedia" there (above there has been also "kategorie Wikimedie" for cs: which doesn’t seem to be wrong either, I don’t know what’s better or more often) and pl: "kategoria projektu Wikimedia" which is different from the wrong descriptions above that I had found before. And "Kategorie op Wikimedia" in nds: is the same, what I supposed above for the language to be right. For pl: it’s also not clear, above I found "kategoria w projekcie Wikimedia", the gadget says "kategoria projektu Wikimedia", this one I don’t know at all. It would be good to ask someone with knowledge of pl: for that. Perhaps first change all those descriptions which are clear to be changed now. And is it possible to get a number of items, if "kategorie na projektech Wikimedia" or "kategorie Wikimedie" is more often for cs:? It seems as if both aren’t wrong, but just different. --October wind (talk) 20:02, 11 September 2014 (UTC)
For cs: kategorie Wikimedie=13, kategorie na projektech Wikimedia=387, Kategorie Wikipedie=199266 --ValterVB (talk) 20:26, 11 September 2014 (UTC)
Then it isn’t clear at all, what should be taken for cs:. "Kategorie Wikipedie" has to be changed anyway (Kategorie has to be lower case and it’s not Wikipedie either), so it doesn’t matter, if 199266+13 or 199266+387 items have to be changed. Perhaps it’s good to ask some user with cs: knowledge (and perhaps also pl:) for that. If "kategorie Wikimedie" should be correct spelling, then it’s not wrong and can also be taken instead of "Kategorie Wikipedie", because it could fit better to the English "Wikimedia category". But in Wikimedia category page (Q4167836), it is now "kategorie na projektech Wikimedia", the same longer version as in the gadget. I’m not sure, if this shall be this way in the future for all categories.
Can you also look up the numbers for pl: "kategoria w projekcie Wikimedia" versus "kategoria projektu Wikimedia" (or whatever may also be there, can you also see, if there’s perhaps another version which is often used instead?), and for en: "Wikipedia category" vs. "Wikipedia category page" vs. "Wikimedia category" vs. "Wikimedia category page"? For pt:, it has been mostly "categoria de um projeto da Wikimedia" up to now, not yet in the gadget, but Wikimedia category page (Q4167836) says now "página de categoria de um ou mais projetos Wikimedia" instead, a very long version, why that? Can you also see the numbers for those pt: versions?
One more question: Will there be one edit for each language change in any item for the bot (such as by editing manually) or one edit for each item changing more than one language description at once? --October wind (talk) 21:18, 11 September 2014 (UTC)
User:Matěj Suchánek might also say something to the cs: and perhaps to the pl: description, maybe he has also added the longer description. Is there any reason for a long description instead of a short one? --October wind (talk) 21:25, 11 September 2014 (UTC)
I am not a pl speaker, for the Czech description there isn't a clear decision (WD:Mezi bajty). I will try to find out soon the correct one. Matěj Suchánek (talk) 12:27, 12 September 2014 (UTC)
Some example of category descriptions: User:ValterVB/sandbox/Category descriptions. --ValterVB (talk) 13:32, 12 September 2014 (UTC)
@ October wind 21:18, 11 September: for the Czech (& other Slave languages) spelling there are two different explanations: Wikipedie (or Wikimedie) ist the correct Czech translation, but in this special case it is full normally to use the English spelling with ~dia, as many users do (i.a. both is correct). The second point, which concerns the most Slave languages is the following: all abjects can be declinated, e.g. "v projektech wikimedie" (= in the projects of Wikimedia), in this case Genitivum, or, possible as well, in nominativ. So you must discus it not only with user who knows the language but with users of the project and ask them for their decision (see Matěj Suchánek) as my home wiki is de:. -jkb- (talk) 22:34, 14 September 2014 (UTC)

If the desired description is in all languages the title of Wikimedia category page (Q4167836), then I believe this bot could be made to do this task by deleting one line of the code. (exeptions would quite easy to handle, should there be any) Popcorndude (talk) 00:13, 5 January 2015 (UTC)

Qualifiers for Pokédex number[edit]

For the following items lists, can a bot duplicate the property Pokédex number for the first list and add to one property :

Here, an example of what I attemps to do.


Thanks! Ju gatsu mikka (talk) 09:45, 20 September 2014 (UTC)

Lists of listed buildings[edit]

As can be seen from[1216]%20and%20noclaim[625], a number of "list of listed buildings in [UK place]" articles (for example, Listed buildings in Brindley (Q15979098)) have multiple English Heritage list number (P1216) values. These should be removed, and replaced by the equivalent Q value, as has part (P527). Where they have multiple coordinate values these should also be removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:14, 20 September 2014 (UTC)

Can anyone help with this? Perhaps User:Magnus Manske has an idea? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:13, 26 October 2014 (UTC)
Note that many of these English Heritage list number (P1216) are Grade II buildings, many of which do not have a Q item yet. The WLM drive only called for grade I and grade II* buildings to get items. If there is will to do this, I recommend quick_statements. To create a new item for value, linking back to list (no leading spaces; separate by tabs):
LAST P361 Qlist
LAST P1216 "value"

plus some "grade II" instance of, if the grade is known. (Note that I am using part of (P361) here; has part (P527) could then be created as "counter-link"?) One should probably clear out double values for English Heritage list number (P1216) first. --Magnus Manske (talk) 23:42, 26 October 2014 (UTC)

@pigsonthewing:@Magnus Manske: I'll take a look at the double values; most of the ones I've spot-checked so far are the list & the building, but not all. - PKM (talk) 18:02, 23 November 2014 (UTC)
Okay. I have cleared out the list of doubles for P1216. There were two cases where two items have the same English Heritage ID because there are separate ENwiki articles for different tenants of the same building. Otherwise the English Heritage list number (P1216) should only be duplicated between a building's item and the list-of-listed-buildings item.
I have not added new, separate items for every boathouse, pumphouse, wall, and gate that are part of an estate, so a few items have multiple EH ID's. Does that need to be done? - PKM (talk) 04:20, 24 November 2014 (UTC)

Corporations infobox data of[edit]

it:Template:Azienda is the infobox for corporations. I'm trying to integrate it with Wikidata a bit (currently it's only fetching the ISIN), but let's see what can be imported immediately, looking at Wikidata:List of_properties/Organization. I suggest that you start testing with the category for publishers, it:Categoria:Case editrici italiane, on which I'm keeping an eye now. Main ones:

  • data_fondazione -> P571
  • data_chiusura -> P576
    • causa_chiusura -> free text qualifier?
  • sede -> P159
  • industria -> P452


  • logo -> P154
  • foto -> P18?
  • tipo -> P31?
  • borse -> P414
  • luogo_fondazione -> P740
  • fondatori -> P112 (one statement per link?)
  • gruppo -> P749
  • filiali -> P355
  • prodotti -> P1056
  • fatturato, margine d'intermediazione, risultato operativo, utile netto -> ?
    • anno_fatturato, anno_margine d'intermediazione, anno_risultato operativo, anno_utile netto -> qualifier date
  • dipendenti -> ? (integer)
    • anno_dipendenti -> qualifier date
  • slogan -> P1451??
  • sito -> P856

--Federico Leva (BEIC) (talk) 12:04, 16 October 2014 (UTC)

Please remove erroneous/unreliable country of citizenship (P27) statements[edit]

Can somebody remove all changes by User:GerardM from July 9th to 10th, 2014, which add a statement country of citizenship (P27) Poland (Q36). They are unsourced, many of them are obviously erroneous and the method of deducing this statements given by the author is (1) not correct and (2) doesn't correspond with all changes he made. Apparently, the author is not going to help with correcting this errors, therefore I suggest to remove all statements of the "infected" group.--Shlomo (talk) 10:17, 23 October 2014 (UTC)

The method is as advertised and yes, there are errors. Errors that exist in the source to the same extend. I am happy to collaborate with people who are civil towards me. I am not willing nor able to check every individual edit. GerardM (talk) 10:32, 23 October 2014 (UTC)
I am not willing nor able to check every individual edit - then please do not edit at all.--Mad melone (talk) 11:38, 23 October 2014 (UTC)
  1. Even if the method were as advertised, the method is bad. Place of birth in today's Polish republic doesn't indicate polish nationality - not even in these days, the less centuries ago.
  2. The method apparently is not as advertised, at least doesn't explain edits like Special:Diff/143458975, Special:Diff/143489927, Special:Diff/143489685 a.s.o.
  3. I asked for your help in a quite civilized manner twice, and the only respond I got was something like Do It Yourself If You Dare. That's why I'm asking for help here.
  4. Other editors are not willing nor able to check every your individual edit either. What do you suggest to do?
  5. This thread is not about whether to remove your edits from the described set, it's about how to do it.
Regards,--Shlomo (talk) 13:08, 23 October 2014 (UTC)

Import Persondata from English Wikipedia[edit]

This is a huge collection of highly valuable human-curated metadata about 1.2 million articles on English Wikipedia (which is in danger of being deleted). Please see the discussion at Project Chat for more details. Kaldari (talk) 18:17, 23 October 2014 (UTC)

Moin Moin, I think it will be make sense to import the data for german Wikipedia, too. --Crazy1880 (talk) 05:30, 24 October 2014 (UTC)
One thing that there is in Personadata is the name in the order it should be sorted in. (Which can be non-trivial). This is something we really ought to have in Wikidata, to be able to easily sort the output of WDQ queries. It would also be useful to have, eg for c:Commons:Structured data, to be able to sort search hits or a category by artist. Can we please import this as a string. This may need the creation of a new property to store it in. Jheald (talk) 09:23, 24 October 2014 (UTC)
Proposal posted; see Wikidata:Property_proposal/Generic#Sort_key. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:47, 24 October 2014 (UTC)
Support: This is useful data, but clearly belongs in Wikidata, not hidden from view (and sometimes duplicating what we already have), in Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 24 October 2014 (UTC)

Not completely feasible: If entered properly, the birth and death dates in Persondata follow WP:Manual of Style; the details are contained in WP:Manual of Style/Dates and numbers (MOSNUM) which calls for using the Julian calendar on and before 4 October 1582. After that, the Gregorian calendar is used, if it was in force in the location(s) discussed in the article. If the Julian calendar was in force in the relevant location(s), it is used. MOSNUM is not explicit about what to do if the relevant location used some other calendar, and it is in the period where the Gregorian calendar had not fully supplanted the Julian calendar. Persondata does not have any flag to indicate if the Gregorian or Julian calendar was used. This makes it essentially impossible for a bot to import dates before 1924, the first full year Greece adopted the Gregorian calendar for secular use. I will repeat this comment in the bot request. Jc3s5h (talk) 14:58, 24 October 2014 (UTC)

Please can you give specific examples of en.WP and de.WP articles where this is an issue, so that we can examine them in order to work on a solution? One answer may be to write such cases (based on date ranges and locations of birth/death) to a list for manual checking. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 24 October 2014 (UTC)
Consider en:Johann Rudolph Ahle; the English Wikipedia asserts his birth and death dates are 24 December 1625 – 9 July 1673. The article does not state, at least in any obvious place, whether these dates are Julian or Gregorian dates. According to Explanatory Supplement to the Astronomical Ephemeris and the American Ephemeris and Nautical Almanac (1961, pp. 414-415), Catholic German states adopted the in Gregorian Calendar 1583 or 1584, but Protestant German states adopted it in 1700. It would require research to find which of these apply to Ahle. Indeed, the answer for the birth date might be different from the death date. I don't read German, so won't attempt to provide an example from the German Wikipedia. Jc3s5h (talk) 17:21, 24 October 2014 (UTC)
Thank you. Incidentally, I note that Johann Rudolph Ahle (Q69440) already has his DoB and DoD, both marked as Gregorian. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 24 October 2014 (UTC)
First, does anyone know the name of whatever it is that displays information when you click on a link to a Wikidata item, or enter the number of a Wikidata item in the search box? Next, when you do that, you see the birth and death dates, with the word "Gregorian" as a superscript next to the dates. But it is misleading to say "both marked as Gregorian." The interface I just described always displays Gregorian dates. What the superscript means is that when the data is presented to the user, it should be displayed as-is. It could have been set to "Julian", which would mean the date should be converted to the Julian before presenting to the reader. Jc3s5h (talk) 18:07, 24 October 2014 (UTC)
No; the dates on, for example, Tim Berners-Lee (Q80) are not marked "Gregorian" (and nether, of course, are they marked "Julian"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:13, 24 October 2014 (UTC)
For whatever reason, the calender in which the date is to be displayed to readers is not stated for Tim Berners-Lee. Nevertheless, the date displayed, 8 June 1955, is almost certainly a Gregorian calendar date, since that is the calendar in force in 1955 in the United Kingdom. Jc3s5h (talk) 18:23, 24 October 2014 (UTC)
So, now that we have established that "the interface... always displays Gregorian dates" is not true (in the logic sense; no dishonesty implied), I can reiterate my statement that "Johann Rudolph Ahle (Q69440) already has DoB and DoD, both marked as Gregorian". We still need examples of en.WP (or de.WP) articles, where the import of ambiguous persondata dates to Wikidata would cause an issue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:42, 24 October 2014 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────I disagree. Lets take this step by step. The interface sometimes shows the name of a calendar as a superscript, and sometimes it doesn't. The superscript is advice to the person or software that has extracted the item from Wikidata that the date ought to be displayed to the reader in the stated calendar. But the interface does not follow its own advice. Whatever has been entered as the date into the database is displayed as-is.

According to date of birth, it contains Data type "time". The associated talk page contains a link to Dates and times which says "The calendar model used for saving the data is always the proleptic Gregorian calendar according to ISO 8601...." Since the interface does not make any conversions when it displays the date, the date displayed is always a Gregorian calendar date (or else the date is wrong). For an example of a birth date that is stored in the database as a Gregorian date but is suggested to be displayed as a Julian date, see Q935. Jc3s5h (talk) 21:27, 24 October 2014 (UTC)

It is patently true, and visible to all, that next to each of the two dates in question is a label which says "Gregorian". Whether those dates and/or labels are correct or not, and whether the method of storing dates in MediaWiki is optimum, are separate issue; the dates are thus labelled. And none of this is relevant to the question at hand; about importing data from persondata in Wikipedias. What is pertinent is that we still need examples as described in my earlier posts. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 24 October 2014 (UTC)
The subscripted words are not labels. You have two English examples. Perhaps a German-speaker will provide some examples from the German Wikipedia. Jc3s5h (talk) 22:17, 24 October 2014 (UTC)
An example of an incorrect Wikidata entry is Johann Sebastian Bach (Q1339), who was born 21 March 1685 (Julian calendar). This may be verified by reading this article from the Guardian. The correct Julian calendar date is contained in the Persondata of the English Wikipedia article. The German Wikipedia article has the German analog of the Persondata template, and contains this: "GEBURTSDATUM=21. März 1685". I don't know what the rules are for filling in values in the German Personendaten template, but the copy from German Wikipedia to Wikidata is wrong; the German and Russian Wikipedias are given as references for the Wikidata value. Jc3s5h (talk) 22:41, 24 October 2014 (UTC)
I have corrected the birth date data for Johann Sebastian Bach (Q1339). Jc3s5h (talk) 18:20, 25 October 2014 (UTC)
My guess is that it is not "in danger of being deleted", but rather "in danger of being moved somewhere else", such as to wikidata. The way wikipedia works is it is almost impossible to delete anything (that is pretty inherent to the Internet too), and without looking at the discussion of deleting it I would guess that the proposal was made "because it could better be centrally located on wikidata". 18:08, 26 October 2014 (UTC)
@Jc3s5h: (about the UI): dates are always stored in Gregorian, but when calendarvalue is set to Julian, it it supposed to (and used to) be displayed in Julian. There is a bad bug at bugzilla:70398.--Zolo (talk) 15:01, 28 October 2014 (UTC)
@Zolo: The bug 70398 has been marked as a duplicate of bugzilla:70395. Jc3s5h (talk) 17:07, 20 November 2014 (UTC)

Clarity of scope[edit]

Discussion of such things as the DoB of Johann Sebastian Bach (Q1339), which was not - and would never be - imported from Persondata, is irrelevant to the issue at hand.

We need to decide whether or not to import Persondata; and if so which data items to import (or discard). If we decide not to import any, or when we are done, we need to let the en.WP and de.WP communities know, so that thy may proceed accordingly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:37, 27 October 2014 (UTC)

Agreed, I'll split this up into separate requests that can be discussed separately... Kaldari (talk) 23:50, 28 October 2014 (UTC)
Good move. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:56, 29 October 2014 (UTC)

Categories of data[edit]

Import NAME from Persondata[edit]

This is supposed to be the sortable name, i.e. "surname, firstname", but isn't 100% reliable. We probably only want to import this if the DEFAULSORT value isn't set (since it's more reliable). Currently there is no property to import this into, but see Wikidata:Property proposal/Generic#Sort_key. See en:Wikipedia:Persondata#Name and titles for more info. Kaldari (talk) 23:50, 28 October 2014 (UTC)

  • Most I see are "firstname surname", not in sortable order. Maybe just write as an alias, if not already present as one, or as the label?
    • Here's my suggestion: If the NAME includes a comma, import it as a sort_key property (once that is available). If the NAME doesn't include a comma, import it as a label or alias (depending on whether the item already has a label or not). Kaldari (talk) 19:57, 2 November 2014 (UTC)
      • Neat idea, but what about names formed in the manner of "John Doe, Duke of Neverwhere"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:07, 2 November 2014 (UTC)
        • Good point. Also "Martin Luther King, Jr.". I guess we should just discard the NAME in that case as it doesn't seem to be reliable. Too bad people aren't good at following template directions :( Kaldari (talk) 19:32, 3 November 2014 (UTC)

Import ALTERNATIVE NAMES from Persondata[edit]

This is a comma separated list of aliases. Should be pretty straightforward to import as Wikidata aliases, just be sure to check for existing duplicates. See en:Wikipedia:Persondata#Alternative names for more info. Kaldari (talk) 23:50, 28 October 2014 (UTC)

Symbol support vote.svg Support. Check they don't match the existing en-label, too. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:50, 29 October 2014 (UTC)

Import SHORT DESCRIPTION from Persondata[edit]

This is a short description of the person, i.e. 'German physicist'. Should be pretty straightforward to import as a Wikidata description, although we may want to exclude any longer than 12 words or so. See en:Wikipedia:Persondata#Short description for more info. Kaldari (talk) 23:50, 28 October 2014 (UTC)

Symbol support vote.svg Support, where no description already exists. Otherwise, discard. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:51, 29 October 2014 (UTC)

Symbol support vote.svg Support, as the only Persondata field that doesn't seem to have any major complaints about accuracy.—Msmarmalade (talk) 12:09, 20 November 2014 (UTC)

Symbol support vote.svg Support, although I am really here to mention (in case anyone missed it) that the Short Description missing category is now empty ie all Persondata has a short description. Periglio (talk) 00:43, 15 December 2014 (UTC)

Import DATE OF BIRTH and DATE OF DEATH from Persondata[edit]

These follow WP:Manual of Style/Dates and numbers (MOSNUM) and may include link syntax (which should be stripped out). The dates are assumed to be Julian calendar dates if they are on or before 4 October 1582. For dates between 1582 and 1923, there is no way to reliably tell which calendar applies, although there are lots of ways to guess. See en:Wikipedia:Persondata#Dates of birth and death for more info. Kaldari (talk) 23:50, 28 October 2014 (UTC)

A lot of data was already imported by Reinheitsgebot, like these.--GZWDer (talk) 05:04, 8 January 2015 (UTC)

Import PLACE OF BIRTH and PLACE OF DEATH from Persondata[edit]

Usually formatted as 'City/Village, State/Province, Country'; or 'City/Village, Country'; or 'State/Province, Country'. May include link syntax. See en:Wikipedia:Persondata#Places of birth and death for more info. Kaldari (talk) 23:50, 28 October 2014 (UTC)

  • How do we disambiguate, if there is no link markup and the text value is ambiguous? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:53, 29 October 2014 (UTC)
    • I guess we would have to discard in that case. Kaldari (talk) 19:54, 2 November 2014 (UTC)

Conversation continued[edit]

My personal analysis seems to be showing that there is only a need for the short description parameter to be copied to the Wikidata description. Combined with the fact that this parameter was successfully completed last month, what do I need to do to make this happen? I can easily provide a complete Persondata extract matching "Q-Code" and "Description" in any format if someone is able to do the updating Wikidata side. Periglio (talk) 02:16, 18 January 2015 (UTC)

If anyone needs convincing a description is needed, try searching for "Charles Robinson" to find a potential match for w:Charles Robinson (cricketer) one of my latest no link to Wikidata flags Periglio (talk) 23:43, 18 January 2015 (UTC)
started my bot, see [4] --Pasleim (talk) 19:40, 19 January 2015 (UTC)
I have suggested some tracking categories to enable easier transfer of information by bots. George Edward CTalkContributions 17:17, 23 January 2015 (UTC)
I have performed a run of 1000 random Persondata records. 25 of these had dates not available on Wikidata. Taking a liberty with my small sample size, this indicates about 30,000 dates that could be copied across from wikidata. (only where no Wikidata dates exist). Having said that, if someone is extracting data, the Birth and Date templates would be more reliable than the Persondata template. Periglio (talk) 17:12, 25 January 2015 (UTC)

Fill out "symmetric" statements[edit]

When X is tagged as father of Y, a bot should really add "Y: child of X". Currently this is done by hand, and this is really not the best use of our time. Beside, it is usually done in a somewhat sloppy fashion, like copying the main part of the statement, so as to remove the "constraint violation" but not copying the qualifiers and sources, because it is so time consuming.

Ideally, the bot should be time-conscious. For instance, if someone removes a wrong "son of X" statement and not the corresponding "father of Y", then the bot should remove "father of Y" rather than readd "son of X".

user:Magnus Manske had proposed to do it once, but gave up during the bot approval process. See Wikidata:Requests for permissions/Bot/ImplicatorBot, apparently, some code is still available. -Zolo (talk) 15:30, 5 November 2014 (UTC)

Perhaps, now that some time has passed, User:Magnus Manske would reconsider? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:08, 5 November 2014 (UTC)
I suggest to wait for arbitrary access in WP and then to delete one half of the symmetric statements. Having redundant information in a database always causes trouble, no matter how intelligent the bots are programmed.--Pasleim (talk) 17:53, 5 November 2014 (UTC)
Arbitrary access alone will not solve the issue. If you want to know who is the father of X, it is of little use that item Y contains the statement "father of: X", because you would not know that you have to look in item Y. --Zolo (talk) 21:14, 5 November 2014 (UTC)
I agree with Zolo here. Emw (talk) 02:58, 6 November 2014 (UTC)
I would support a program like ImplicatorBot that adds certain types of entailed statements (e.g. symmetric, inverse, etc.), as long as how it did so was documented and agreed to by the community for each type of statement. Constraint templates on Property talk pages are likely the best shim for statements on properties for now. Ideally the source code would be publicly available. Emw (talk) 02:58, 6 November 2014 (UTC)
An example for father (P22) / child (P40) is at
It was processed the other day so the number reduced quite drastically.
However, we found that the constraints on these properties weren't set up correctly, so we propagated a few errors that would already have been visible on the constraint reports.
The advantage of the them being made symmetric is that the errors became more visible and easier to fix (mostly done). --- Jura 03:52, 7 November 2014 (UTC)
@Jura: the tool shows the list a little more nicely than the in-wiki constraint violation report, but there is no "process it" option is there ?--Zolo (talk) 10:07, 8 November 2014 (UTC)
You need to reformat it yourself to paste it into ----- Jura 10:13, 8 November 2014 (UTC)
OK, I do not think it is a really good solution. The bot should really keep the qualifiers and source. Plus, rethinking about it, it seems important that when both items have a different values, it should somehow give priority to the more recent one. --Zolo (talk) 11:03, 8 November 2014 (UTC)
The reasoning is probably different for each type of "symmetric" item.
As source I indicated the item it was derived from. This has the advantage that when people fix one, they might also fix the other. --- Jura 11:48, 8 November 2014 (UTC)
Example: Q3260846 --- Jura 11:51, 8 November 2014 (UTC)
Clearly we need to start with properties were the logic is simple (like father/son).
Providing the other item as a source may be better than nothing, but this is clearly subptimal. It is hard to reuse in Wikipedia for example. Also, it seems conceptually incorrect: "imported from English Wikipedia" means imported from the website, not "stated in item English Wikipedia (Q328)", so "imported from Ludovic-François Douillard" should mean imported from the human called Ludovic-François Douillard, not "stated in item Q17486077". A consistency-checking tool would rigthfully find that a bit strange.
There will certainly be tricky cases, but this is the reason why we would need a single bot that we can document, discuss and monitor, rather than various humans hacking various semi-automated stopgaps. --Zolo (talk) 12:23, 8 November 2014 (UTC)

Please be careful before starting a bot to fill out symmetric statements, if the statements are really symmetric according to their definition. E.g. present in work (P1441) and characters (P674) are not symmetric, although they may seem to be. They may become symmetric, but we would have to change one or both of their definitions and the constraints based on them before.--Shlomo (talk) 16:10, 9 November 2014 (UTC)


Is it possible to get following data:

Adding UNII identifiers[edit]

I've noticed that UNII (P652) didn't have much data, while a canonical list from the Food and Drugs Administration (thus PD and freely reusable, cf does exist.

The data is tabulated as follows and has several existing identifiers for cross checking:

007C07V77Z BIBENZYL 103-29-7 C14H14 QWUWMCYKGHVNAV-UHFFFAOYSA-N 203-096-4 c1ccc(cc1)CCc2ccccc2 Ingredient Substance

It is available at :
What I think could be nice are the UNII identifiers, and the data for the other properties when it is not present, and creating any items that would not be present.
But I am not a chemist and while the data seems trustworthy, there might be issues.
I'm interested by this since aside from Wikidata, I contribute to Open Food Facts, a cross language open database (OdBL and CC) of food products, and some of the items of this list end up as ingredients, additives and sometimes Wikipedia articles in various langages :-)

Teolemon (talk) 13:31, 21 November 2014 (UTC)

We're talking 60k+ items --Teolemon (talk) 13:36, 21 November 2014 (UTC)
If the licence is compatible, I think it would be a great idea to import the UNII identifiers. If possible we should also link to Open Food Facts via an identifier. Some food items are notable enough and have a Wikipedia page bzw. a Wikidata item. --Tobias1984 (talk) 16:43, 21 November 2014 (UTC)
Maybe Magnus can add it to Mix'n'Match so id's can be matched to items here. Multichill (talk) 19:28, 21 November 2014 (UTC)
Added (bottom of page). Currently trying to auto-match items. Also working on importing the other data in the set (e.g. SMILES, CAS) to match/import later. --Magnus Manske (talk) 20:18, 22 November 2014 (UTC)
Update: Have ~10K identified through name and/or CAS number. Will update Wikidata with the UNII IDs tomorrow. --Magnus Manske (talk) 23:55, 22 November 2014 (UTC)
@Magnus Manske: Hi, can you just explain which parameter from which data source did you use to match UNII ID with wikidata items ? Thanks. Snipre (talk) 15:24, 24 November 2014 (UTC)
I used RN, which is CAS (for above example). --Magnus Manske (talk) 15:29, 24 November 2014 (UTC)
Mmouais. It would be better first to check the CAS number of the items using a cross-checking between EN, DE and FR WP. Snipre (talk) 13:56, 27 November 2014 (UTC)
Open Food Facts has individual pages for additives (, food categories ( and brands ( in addition to products (which aren't the best option available since there can be dozens of variation and different versions of coke, with identical or different barcodes). If you see fit, I can open property proposals for some of those page slugs Teolemon (talk) 20:21, 28 November 2014 (UTC)

Astronomical objects in the Index Catalog[edit]

There are hundreds of astronomical objects in the Index Catalog which have no label or description in English. I did a hundred or so of these by hand to see what's involved, and it seems to me a bot could generate labels and descriptions fairly easily with this logic:

This would give a description like "galaxy in the constellation Virgo" which is essentially what I was doing by hand (except I was looking them up so I could say spiral galaxy, elliptical galaxy, etc., but I don't think that's necessary for basic disambiguation). Thoughts? - PKM (talk) 03:16, 23 November 2014 (UTC)

PS most of these items don't have articles in EN wiki, but do have articles and infoboxes in BS, UK, SR, SH, KK, RU, etc. - PKM (talk) 20:21, 24 November 2014 (UTC)

batch autopatrol[edit]

If it's possible, could somebody somehow mark all of Special:Contributions/ as patrolled? They come from tools operated by autopatrolled users who are operating tools that log out momentarily apparently due to some high-level changes in the servers happening recently. HHVM or something. There are hundreds of them every hour and it's no fun to mark them all by hand. It's only possible to view RecentChanges for unpatrolled/IP users for a few hours into the past. Alternatively, could somebody please tell me how to set the URL for RecentChanges to go start at a time before the present? I can't get the API flags to work at all. Thanks for any help --Haplology (talk) 00:25, 26 November 2014 (UTC)

Haplology: These edits are happening because the tool isn't using assert to check if it's properly logged in. The flood seems to be over now. Next time I'll put a softblock on it. Multichill (talk) 18:18, 26 November 2014 (UTC)
@Multichill: Just a note: Wikidata:Administrators' noticeboard/Archive/2014/10#Please indef soft block
I don't think it is necessary to mark them all as patrolled unless we use better patrolling system... Matěj Suchánek (talk) 19:07, 26 November 2014 (UTC)

Populated places in Sweden by municipality[edit]

Last week, some categories about populated places in Sweden by municipalities were created. However, many of them still have no Wikidatalinks to Swedish, where such categories also exist.


  • Category:Populated places in Kiruna Municipality

shall have a Wikidata link to

  • Kategori:Orter i Kiruna kommun

J 1982 (talk) 15:20, 28 November 2014 (UTC)

Adding SOC job codes[edit]

I've noticed that SOC Occupation Code (2010) (P919) didn't have much data (, while a canonical list from the Bureau of Labor Statistics (thus PD and freely reusable, cf does exist (we're talking 7K items).

The data is tabulated as follows:

SOC Codes and Job Titles
2010 SOC Code 2010 SOC Title 2010 SOC Direct Match Title
11-1011 Chief Executives CEO
11-1011 Chief Executives Chief Executive Officer
11-1011 Chief Executives Chief Operating Officer
11-1011 Chief Executives Commissioner of Internal Revenue
11-1021 General and Operations Managers Department Store General Manager It is available at : (with more related files at

What I think could be nice are adding the SOC codes based on the 2010 SOC Direct Match Title since so many outside services and pages use the SOC codes (which seems to be a requirement for a lot of job offers in the US).

I've already added manually the French equivalent of the SOC code in Wikidata, so being able to match national codes and job titles through Wikidata would be cool.Teolemon (talk) 18:59, 29 November 2014 (UTC)

SOC is based on an UN standard, ISCO. Each country's bureau of national statistics have their own translation/adaptation of ISCO. There is a standard for historical occupations too, HISCO. In Denmark the national adaptation of this code system is called DISCO, for Norway STYRK and so on. Adding all these codes will be messy, since they may be non-overlapping. But it may also becoma a source for statisticians to get translations from one code to another. H@r@ld (talk) 23:12, 19 January 2015 (UTC)

Add description of categories in Esperanto[edit]

Can someone add description in Esperanto (languagecode "eo") to all items of categories where the description is empty? The description would be "Vikimedia kategorio". --Venca24 (talk) 11:16, 30 November 2014 (UTC)

Would "kategorio en Vikimedio" be acceptable? If so, please see my post in wrong category item descriptions, above. Popcorndude (talk) 00:25, 5 January 2015 (UTC)
Yes, it will. --Venca24 (talk) 20:50, 5 January 2015 (UTC)

Wikipedia soft redirected categories[edit]

This AutoList link lists almost 9,000 items which are connected with a soft redirected category. Anyone able to write a script to reconnect/redirect or delete (ping Ladsgroup whose bot has deletion rights)? Matěj Suchánek (talk) 14:41, 22 December 2014 (UTC)

At first it seems a very easy task but it's not. take this for example: Category:Yokohama Sports and Culture Club players (Q10081029): the sitelink in English Wikipedia is soft redirect but the Japanese one isn't and the target doesn't have item in English Wikipedia so the best solution for this case is to change the site link to "Category:YSCC Yokohama players". I will write the script tomorrow or the day after. Amir (talk) 14:54, 22 December 2014 (UTC)
I ran the bot. it fixed as much as it could and deleted lots of items. It finishes in two hours. Best. Amir (talk) 02:52, 25 December 2014 (UTC)
@Ladsgroup: Your bot reduced the number of those affected items by 66%, that's great! However, there are still items your bot could simply delete (like the first one – Q10006889). Matěj Suchánek (talk) 10:15, 25 December 2014 (UTC)
@Matěj Suchánek: I ran it again and just 700 cases left. It's because the API can't proceed merge in lots of cases. they should be done by hand Amir (talk) 06:39, 26 December 2014 (UTC)


After this discussion, Q18608199 was deleted as non-notable, however, it is still linked from properties. Has anyone a bot which could replace the sources imported from (P143): Q18608199 with reference URL (P854): [5]. Matěj Suchánek (talk) 09:59, 25 December 2014 (UTC)

 Doing… I've made a test edit, [6]. Is it okay? --JulesWinnfield-hu (talk) 19:20, 24 January 2015 (UTC)

NLI identifier (P949)[edit]

Can a bot please check the identifier NLI (Israel) identifier (P949)? Some of the IDs are wrong, see Property talk:P949#Unstable numbers? I don't know if it is only a small or a large percentage. --Kolja21 (talk) 03:24, 27 December 2014 (UTC)

Add data of birth / death to French people[edit]

I noticed that a lot of items about people (instance of (P31) -> human (Q5)) don't have date of birth (P569) and date of death (P570), but do have an article at the French Wikipedia (list of about 78.000 items). I already imported a lot of dates from the Dutch Wikipedia, but that was much more difficult. It looks like the French Wikipedia uses the template Date de naissance (date of birth) and Modèle:Date de décès (date of death). Could someone please harvest these templates? Probably best suitable for a French speaking bot operator. Multichill (talk) 21:31, 28 December 2014 (UTC)

Mayor election results in Hungary[edit]

Good day!

Last year, the mayors voted in Hungary. The French Wikipedia hungarian settlements mayor to update information. The data are available on the [7] --นายกเทศมนตรี (talk) 12:32, 6 January 2015 (UTC)

I will have a look at that during the week-end. Orlodrim (talk) 11:52, 16 January 2015 (UTC)
I updated the data templates on the French Wikipedia.
I don't know if it's possible to put the mayors on Wikidata without creating an item for each mayor, but if someone is interested, I put the list in CSV format on this page.
Orlodrim (talk) 21:56, 16 January 2015 (UTC)

Import 12.000 images from it and[edit]

Hi all,

I have made categories on (10.100 pages) and (2.600 pages), that shows pages with an image where Wikidata does not have an image. All articles are of people and the images are in a template, so they are specific for the subject. Maybe someone can use this category to place these images on Wikidata. Sincerely, Taketa (talk) 20:36, 6 January 2015 (UTC)

PS: The category on (1.600 pages) might also be of interest, since it is on an English language project and should be easy for botusers that speak English. It is not just biographies, but all images are specific for the topic and in a template. All the best, Taketa (talk) 21:26, 6 January 2015 (UTC)
Hi Taketa, do you have Pywikibot installed? You can just use That's the bot I wrote and used to import images from the Dutch Wikipedia and other languages.
For example to import the plwp images: python -family:wikipedia -lang:pl -cat:Grafika_za%C5%82adowana_lokalnie_jest_taka_sama_jak_w_serwisie_Wikidata. I don't think that's the right category btw. I see plenty of articles in there that have an image here, take for example pl:Roberto Aballay. Multichill (talk) 21:41, 6 January 2015 (UTC)
I have no bot. Not technical so that goes beyond me. You are right. I picked the wrong one (I don't speak Polish :P). I have corrected the error. 2.000 images in this category. All the best, Taketa (talk) 22:09, 6 January 2015 (UTC)

Request for archiving old threads here[edit]

A number of these topics are quite old (eg up to 7 months). If they are not active, would it be possible to archive them? Having such a long page is confusing and, for users such as myself who will not always have access to high-speed internet, can be time-consuming and frustrating to load. --LT910001 (talk) 21:05, 10 January 2015 (UTC)

Topics get archived after 6 months or if the template {{Section resolved}} is added to the section. --Pasleim (talk) 23:50, 19 January 2015 (UTC)
Perhaps you could decrease that to 3 or 4 months in the interest of users without high-speed internet or mobile like myself? --LT910001 (talk) 21:06, 25 January 2015 (UTC)


I have set more than 8000 dates via "Wikidata - The Game" and because of that I can safely say that a bot could also do this with a efficiency of 95 - 99 %. The bot should only take a look on articles where two brackets and withing these brackets date(s) are. If the date of the death of the person is missing, the bot should enter the date after the "-", the "†" or the word "death" as the property. If the date of the birth of the person is missing, the bot should enter the date before the "-", the "*" or after the word "born" as the property. This could be also done with other languages just by translating the words "born" and "died". --Impériale (talk) 00:43, 11 January 2015 (UTC)

I have set more than 100,000 dates via "Wikidata - The Game", and I highly disagree that this is something that can be done by bot -- there are just too many irregularities. In the case where dates are added with templates it can be done very reliably, but not in cases where the dates are stored in plain text. Jon Harald Søby (talk) 19:26, 15 January 2015 (UTC)
Haha, good work! What irregularities do you mean? I'll try to explain the bot better (i have a bit experience with programming):

::If in the first line are numbers and parentheses then:
:::If a "*" or a "born" is between the parentheses then:
::::If there is one! date between a "*" or a "born" and a "†" or a "died" then:
:::::If the date of the persons birth is missing in wikidata then:
::::::transcribe it wikidata
::::::go to the next article
:::::go to the next article
:::elif a "†" or a "died" is between the parentheses then:
::::If there is one! date between a "†" or a "died" and the ")" parentheses then:
:::::If the date of the persons death is missing in wikidata then:
::::::transcribe it wikidata
:::::go to the next article
:::elif a "-" is between the parentheses then:
::::If there is one! date between the "(" and the "-":
:::::If the date of the persons birth is missing:
::::::transcribe it to wikidata
:::::go to the next article
::::If there is one! date between the "-" and the ")":
:::::If the date of the persons death is missing:
::::::transcribe it to wikidata
:::::go to the next article
::::go to the next article
:::go to the next ariticle
I know that there are probably some mistakes but in my imagination this bot could not solve set all dates (there would be still a lot of work for us), but I think it should work nearly without mistakes and help us a lot. --Impériale (talk) 17:04, 16 January 2015 (UTC)

I have a suggestion: go over all 8000 additions and make sure you know whether each and every date was in the Gregorian or Julian calendar. This has been discussed before in this forum.
For example, this edit claims that David Leslie Melville, 6th Earl of Leven, was born 4 May 1722, Gregorian calendar. But this source says that he was born 4 May 1722 in Leven, Fife, UK. At that date and place the Julian calendar was in force, so the date 4 May 1722 appears to be a Julian calendar date, not a Gregorian calendar date. Jc3s5h (talk) 02:14, 17 January 2015 (UTC)
Do you probably know how many articles are proximally affected (in percentage) by this? --Impériale (talk) 00:19, 19 January 2015 (UTC)
If you mean how many in all of wikidata, I would say all dates before 1583 are suspect. Also, dates of people from the British Isles, Canada, and American colonies before 1752. Russia before 1918. Greece before 1923. I don't know what the coverage is for persons from various areas and time periods, so I couldn't guess what the percentage is. Jc3s5h (talk) 03:15, 20 January 2015 (UTC)

Hungary Wikipedia + Wikidata[edit]

Hi! I have a category with lot of items: hu:Kategória:Bottal létrehozott olasz vasútállomás cikkek without wikidata contact. I would like wikidata contact, for example: Acquaviva-Casteltermini vasútállomás -> Stazione di Acquaviva-Casteltermin (it), label: Acquaviva-Casteltermini vasútállomás, description: vasútállomás Olaszországban.

Thanks! --B.Zsolt (talk) 16:19, 22 January 2015 (UTC)

I tried to match as many articles as possible. However, it looks like 31 train stations do not have yet an article on itwiki. For those, you can create new items with --Pasleim (talk) 21:40, 22 January 2015 (UTC)

Unlink factual errors[edit]

Please delink given name (P735)  Park (Q18608215) when his/her nationality is South Korea or North Korea.

This is to fix serious factual errors described in User talk:Jura1#Korean family name. Thanks, — Revi 11:29, 25 January 2015 (UTC)