Wikidata:Project chat/Archive/2015/11

From Wikidata
Jump to navigation Jump to search

Announcing templates for the query service

I just created a few templates to help to write query to answer a question on the french project chat : {{Wdquery}}, an equivalent of {{WDQ}} and {{Query}} for the query service, example :

{{Wdquery}}
  • {{wdquery|
prefix schema: <http://schema.org/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX wd: <http://www.wikidata.org/entity/> 
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX v: <http://www.wikidata.org/prop/statement/>

SELECT ?item ?itemLabel (COUNT(distinct ?sitelink) as ?count) WHERE {
   ?sitelink schema:about ?item .
   ?item wdt:P279*/wdt:P31 wd:Q215206 .
   FILTER EXISTS { ?wen schema:about ?item . ?wen schema:inLanguage "fr" }
   FILTER NOT EXISTS { ?wfr schema:about ?item . ?wfr schema:inLanguage "ar" }
   SERVICE wikibase:label {
    bd:serviceParam wikibase:language "fr,ar,fr" .
  }
} GROUP BY ?item ?itemLabel ORDER BY DESC(?count) LIMIT 20
}}
[1]
{{Query prefixes}}
to include the regular namespaces 
  • PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX wd: <http://www.wikidata.org/entity/> 
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX v: <http://www.wikidata.org/prop/statement/>
prefix schema: <http://schema.org/>
{{query Instance of|?item|Q5}}
to filter the instances of some class for some variable, here ?item
{{Articles not in a language}} 
higher level template to generate a query to find articles present in a wikipedia that are not in another sorted by number of sitelinks.


items with wikipedia articles in "fr" but not in "ar

items with wikipedia articles in "fr" but not in "ar

items with wikipedia articles in "ar" but not in "fr

 – The preceding unsigned comment was added by TomT0m (talk • contribs).

Thank you! See also {{SPARQL}} and {{SPARQLText}} --Laboramus (talk) 06:19, 1 November 2015 (UTC)

Merge needed but can't be done automatically

Colectiv nightclub fire (Q21282871) and Colectiv nightclub fire (Q21282415) need to be merged but the automatic tool fails but I don't have time to figure out why or how to resolve it. Thryduulf (talk: local | en.wp | en.wikt) 10:13, 31 October 2015 (UTC)

The redirect on the second item blocks it. If you delete it, you can merge the two items.
Normally, the wikinews article would be on a separate item that would link to this. --- Jura 10:19, 31 October 2015 (UTC)
I've merged the items, but don't understand what you mean about the Wikinews items? Thryduulf (talk: local | en.wp | en.wikt) 18:33, 31 October 2015 (UTC)
The Wikinews articles would be on a separate item as on Q17599976. See Wikidata:Wikinews/Development#Interwiki links. --- Jura 23:29, 31 October 2015 (UTC)
So how should items be linked to wikinews articles if not through the sitelink to Wikinews? Thryduulf (talk: local | en.wp | en.wikt) 11:45, 1 November 2015 (UTC)
Q17599976 includes sitelinks to Wikinews and main subject (P921) to whatever it describes. --- Jura 11:51, 1 November 2015 (UTC)

Images - no value - not in Commons

Hi! I have a very single doubt. ...Is it correct adding image statements (P18) and sourcing old pics (portraits for example) not in the public domain yet (so not hosted in Wikimedia Commons) but accessible through public online repositories with a "no value" rank instead of Commons link? (journals, newspapers,... with publishing date, issue, page, photographer, url...). I just wanna be sure it's valid and no bot is going to delete after several months this statements because of some kind of strange restraint. Cheers! Strakhov (talk) 12:27, 31 October 2015 (UTC)

That doesn't seem correct to me. image (P18)no value would mean there is no image at all (100% certainty) anywhere in the world (whether it's a free image or not) and there will never ever be one. Mbch331 (talk) 16:20, 31 October 2015 (UTC)
Thanks! So... is there any way to add the "journal/newspaper, issue, page, and url" sourcing that precious singular rare old pic of that old minister of Justice and Tourism which cannot be uploaded to Commons yet because the photographer died only 64 years ago... or not? It's data and this is a database, isn't it? Strakhov (talk) 16:35, 31 October 2015 (UTC)
Don't know how to store that link and if the link to a non-free image can be considered free data. (We're here to share free data/knowledge.) Mbch331 (talk) 17:31, 31 October 2015 (UTC)
Well, since we store stuff like reference URL (P854) archive URL (P1065) official website (P856) IMDb ID (P345) Google Books ID (P675) X username (P2002) Facebook username (P2013) I do not think the second part about "free data/knowledge" (related to including a simple url to "free access content" as qualifier) would represent a problem, nevertheless url could be even omitted, adding only bibliographic data sourcing where the image is located (that's free for sure...) ...But thanks, anyway. Strakhov (talk) 01:44, 1 November 2015 (UTC)
full work available at URL (P953) is to link to online versions of creative works. I think an 'image available at' property with url datatype would probably get approved if it were proposed. Joe Filceolaire (talk) 05:48, 1 November 2015 (UTC)
Thanks! I have doubts about that hypothetical new property, since it would imply (I guess) "coat of arms image (P94) available at", "locator map image (P242) available at", "bathymetry image (P207) available at", "image of grave (P1442) available at" and so on... and I don't believe that's the correct approach. I think the most proper solution would be some kind of new claim/rank/whatever for image properties such as "not available in Commons/no value in Commons". Instead of the infamous "no value". Strakhov (talk) 16:37, 1 November 2015 (UTC)

Template:Recentchangestext (Q18711941) - delete?

I think Template:Recentchangestext (Q18711941) should be removed - it refers to a special page and also mixes special pages from three projects. If it is important to have wikidata item for those, then it needs to be cleaned up and separated by project.

Should not be removed IMO, but all links that are on MediaWiki namespace should be removed from the item. --Stryn (talk) 08:05, 1 November 2015 (UTC)

format of a competition

Is there currently a way to describe the format of a competition, e.g. best of n games, single game, knockout (one match), knockout (aggregate of two matches), league/round robin, group stage followed by knockout, etc? Thryduulf (talk: local | en.wp | en.wikt) 13:51, 1 November 2015 (UTC)

Primary sources statistics

In the past I asked for statistics for the primary sources. They only show "current" data and currently there is nothing to show. Can we please have some proper statistics and retain information at every end of month so that we can at least understand how the primary sources are doing? Thanks, GerardM (talk) 15:14, 1 November 2015 (UTC)

Women biographies on the English Wikipedia

There have been discussions in various places about the number of biographies of women hosted on the English Wikipedia. One figure quoted is that 15.5 percent of the 1,445,021 biographies on enwiki are of women, as of January 2015. A source for that figure is this article, which cites DBPedia.

But where does DBPedia get its information? Persondata did not mention gender. Infoboxes don't either. Categories sometimes do, but we have no Category:Woman, or Category:Biography of a woman. WikiProject Biographies tags on talk pages don't. The new WikiProject Women tags don't either.

So – does anyone here know whether and how the English Wikipedia's biographies of women are being counted? SlimVirgin (talk) 23:11, 25 October 2015 (UTC)

Using WD http://tools.wmflabs.org/autolist/autolist1.html?q=claim[31%3A5]%20AND%20claim[21%3A6581097]%20AND%20link[enwiki] - 1,102,304 (male human with enwiki link) and http://tools.wmflabs.org/autolist/autolist1.html?q=claim[31%3A5]%20AND%20claim[21%3A6581072]%20AND%20link[enwiki] - 435,677 (female human with enwiki link). --Jklamo (talk) 01:24, 26 October 2015 (UTC)
By my maths that's 28.3% - which is better than 15.5% but still not good. Part of this will be that there are more sources for men than for women, particularly the further back you go. Is it possible to get counts of just those biographies with a birth date of 1915 or later? Thryduulf (talk: local | en.wp | en.wikt) 02:17, 26 October 2015 (UTC)
Yes, we can - 580,172 vs 130,432 (that is even worse with 18.4%). --Jklamo (talk) 02:40, 26 October 2015 (UTC)
Thanks. Thryduulf (talk: local | en.wp | en.wikt) 12:34, 26 October 2015 (UTC)
I count 208,294 female human with enwiki link. That's 15.9% and in good agreement with the number in the article. --Pasleim (talk) 12:42, 26 October 2015 (UTC)
  • That study mentions a specialized dataset it used for some of it. The dataset seems to be based on text analysis. BTW what would be a "good" ratio? Same as BL? --- Jura 12:45, 26 October 2015 (UTC)
    • Well I'd assume that "ideal" would be approximately 50%. However the world is not ideal and I don't think that 50% of the potentially notable (with the en.p definition) people are female, simply because sources do not exist for as many woman as men through history (which is why I asked about 1915 or later births), as (at least from a Western European perspective) things should in theory get closer to 50% the more recent we get. Even in a perfect world however it will never be exactly 50% as (a) gender is not binary, and (b) there is an element of chance in what makes some people notable (e.g. Jack Whittaker (Q6115780)). Thryduulf (talk: local | en.wp | en.wikt) 01:57, 27 October 2015 (UTC)

I already compiled some statistics here: User:Jane023/Gendergap report. I will update this occasionally based on wikidata query. --Jane023 (talk) 15:42, 27 October 2015 (UTC)

Jklamo, thank you, but I can't get either of those links to work. My question is how does anyone know which bio are of men and which of women on the English Wikipedia? We don't signal it with infoboxes, categories, project tags, etc, so what is the source of the 435,677 figure? SlimVirgin (talk) 02:32, 28 October 2015 (UTC)

Read the study, if you don't read our comments. --- Jura 06:30, 28 October 2015 (UTC)

@SlimVirgin: What is your problem exactly? Is it that you want to be able to run the M/F queries yourself? This should be possible and if you are having problems, I can probably help you fix them. Just post a screenshot of the problem. --Jane023 (talk) 07:11, 28 October 2015 (UTC)

@Jane023, Jura1, SlimVirgin: I think what is being asked for is the source of the Wikidata data. i.e. Wikidata has 435,677 entries for biographies of Women with a link to en.wp, but the question is how were those 435,677 biographies identified as being of women? In some case it will be manual entry, but I don't think that would account for all of them? Thryduulf (talk: local | en.wp | en.wikt)
I think a lot were added manually and of the original import items with no statements, the gender statements were probably added through the Wikidata game here Jane023 (talk) 18:41, 28 October 2015 (UTC)
A substantial number of gender:female statements were added by working down category trees - while most wikis don't have "Category:Women", they do have "Category:Women artists", etc. Andrew Gray (talk) 18:10, 2 November 2015 (UTC)

Wikidata Tours

Hi

Are there plans to create more Wikidata Tours? Currently only Items and Statements are available, it says References, Qualifiers, Ranks and Special Values are coming soon. I really found them helpful and hope that the rest will appear soon :)

Thanks

John Cummings (talk) 16:31, 26 October 2015 (UTC)

I don't think anyone is working on new ones right now. Bene* made some improvements to the existing ones the other day. Anyone up for making additional ones? --Lydia Pintscher (WMDE) (talk) 11:41, 2 November 2015 (UTC)

How manage part of the series (P179)

How is better manage part of the series (P179)? With one claim and more qualifiers (example) or with more claims (example)? --ValterVB (talk) 08:48, 31 October 2015 (UTC)

@ValterVB: I'd push the "One claim" solution because a series member might be part of several series, like several musical albums or part of a season, with a sequence number in the season, and a sequence number in the whole series (S2E01 or 14th episode) for example. The number or the prceeding item is a function of both the work and the series itself. author  TomT0m / talk page 15:37, 31 October 2015 (UTC)
OK, In past I used more claims, but probably one claim is also more understandable. I try to prepare a bot to migrate from more claims to one claim. --ValterVB (talk) 15:53, 31 October 2015 (UTC)
@ValterVB: I ran that WDQ query. The is something like 16 000 results. Items like Don't Walk on the Grass (Q1006858)  View with Reasonator View with SQID showed up in the result. There is for example no mention of the season in that one. author  TomT0m / talk page 17:07, 2 November 2015 (UTC)
@TomT0m: For now I work on television series season (Q3464665) (...claim[31:3464665]). For the episodes I'm not sure if is correct to use P179=the series (ex. Desperate Housewives (Q131758)) or P179=the season (ex. Desperate Housewives, season 6 (Q1094210)) --ValterVB (talk) 17:25, 2 November 2015 (UTC)

@ValterVB, TomT0m: I think that the way it should be is with one claim and qualifiers, the problem is that the other approach was taken before the qualifiers were implemented. The ideal solution would be changing all of them to claim + qualifiers but this change can make the information on the client side not being displayed correctly. part of the series (P179), follows (P155) and followed by (P156) have notified external uses in their discussion page, so before changing all the claims to qualifiers I think we should say something to the affected sites and give them some time to change the templates first if any change is required. -- Agabi10 (talk) 17:41, 2 November 2015 (UTC)

Two languages in one Wikipedia

The content of Armenian Wikipedia is divided in two sectors: in Eastern Armenian language and in Western Armenian language. Sometimes there are 2 pages on the same theme. Pages writen in Eastern Armenian are linked to Wikidata pages with data and links. Wikidata pages in Western Armenian are usually empty.

The purpose is to link Wikidata pages in Western Armenian to pages with data and links.

For example Q21209621 and Q92032.

What can be suggested? - Kareyac (talk) 07:22, 1 November 2015 (UTC)

Take at look at sv:Mall:Interwiki extra which is used for Bonnie and Clyde-cases. It is based on sv:Modul:Interwiki which you can feel free to import if you like. ladwiki also has a version of this module and uses it for articles in two different scripts.
The module imports the missing interwiki from the other object which is linked in the qid-parameter or the P460-property. . -- Innocent bystander (talk) 08:15, 1 November 2015 (UTC)
I added properties to Q21209621. For a similar case, see Q13202704. All these end up on Wikidata:Database_reports/Identified_duplicates. --- Jura 10:00, 1 November 2015 (UTC)
I updated Armenian Wikipedia (Q1975217) as well. To identify these wikis, I made multi-script Wikimedia site (Q21286559) and multi-languoid Wikimedia site (Q21286561). --- Jura 11:13, 1 November 2015 (UTC)
@Jura1: nnwiki is also (at least) a two-language-wiki (nynorsk and högnorsk). And many Wikisources can be described as mulitlanguage-projects. -- Innocent bystander (talk) 11:24, 1 November 2015 (UTC)
Thanks, I flagged nnwiki as well. I'm sure there a few more (overview).
Wikisource is generally less an issue, as it shouldn't interlink with Wikipedia on the standard items. --- Jura 11:35, 1 November 2015 (UTC)
Agree! -- Innocent bystander (talk) 11:38, 1 November 2015 (UTC)

@Innocent bystander: It works! Now Andreas Acoluthus (Q21209621) / Անդրէաս Ակոլութ has interwiki links as Andreas Acoluthus (Q92032) / Անդրեաս Վրատիսլավ Ակոլութոս. Thank you! I added "wikidataficated" template to the article, but it doesn't bring data from here. Deleting link to Andreas Acoluthus (Q21209621) did not help. - Kareyac (talk) 12:20, 1 November 2015 (UTC)

@Jura1: Thank you for adding. The pairs can easily be found by {{արևելահայերեն|}} template, leading from Western to Eastern, and {{արևմտահայերեն|}} template, leading from Eastern to Western. Can this job be done (semi)automatically? - Kareyac (talk) 12:20, 1 November 2015 (UTC)

@Kareyac: A "wikidataficated" template probably do not work as you intended here, but with Arbitrary access it is possible to access the other items statements. -- Innocent bystander (talk) 13:19, 1 November 2015 (UTC)
Yes, we should be able to do that. As Wikimedia duplicated page (Q17362920) is currently used on permanent and temporary duplicates, we should probably make a separate one for these cases. --- Jura 12:26, 1 November 2015 (UTC)
I made Wikimedia permanent duplicate item (Q21286738) for that. --- Jura 12:34, 1 November 2015 (UTC)
The steps to do that semi-automatically would probably be:
  1. create items for all articles that don't have one yet with https://tools.wmflabs.org/wikidata-todo/creator.html (one or several categories in hywiki would be needed to be identified).
  2. add property:P460 based on the two templates with https://tools.wmflabs.org/pltools/harvesttemplates/ (Parameter: 1)
  3. check the result with TAB: items should be included here (among others)
  4. add missing P31 with value Wikimedia permanent duplicate item (Q21286738) to the "second" item with https://tools.wmflabs.org/autolist/ or QuickStatements (Q20084080)
  5. double check the result.
--- Jura 13:06, 1 November 2015 (UTC)
Hi guys, thanks for your help. Is there a way to call for qid value of the defined article on hywiki? I'd like to make interlinking by extra interwiki automatic, so when someone puts a template defining that "This article has also an Eastern Armenian version", which is the one interlinked to other languages, it will take the qid value of that article and put the extra interlink automatically. --David Saroyan (talk) 08:12, 2 November 2015 (UTC)
The Interwiki-module described above, has a function, that can make that. You can (instead of adding the module to a dedicated template like "Interwiki extra") add the module to your template that tells "This article has also an Eastern Armenian version". The qid-parameter is optional. If there is a P460-statement, it will follow that (as long as you do not add any qid-parameter, since it overrides that property). -- Innocent bystander (talk) 08:48, 2 November 2015 (UTC)

Languages with Roman script

Is there a list with all Wikidata-supported languages with Roman script and their respective language code? Yellowcard (talk) 19:08, 1 November 2015 (UTC)

Here's a list of language codes which looks like it might be used by MediaWiki. I'm not sure, because I'm not familiar with the source, just found it by chance about a month ago when looking for something else. In this folder is a set of json documents which show the messages of each language. I haven't found a list of languages by script used, but those json documents can surely be used to determine that, using a program. --BurritoBazooka (talk) 20:51, 1 November 2015 (UTC)

Wikidata weekly summary #182

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

birthday present: Special:Nearby

Hey folks :)

Have you ever wondered what is happening on Wikidata around you? What does Wikidata know about the building next door? Or the tube station a few blocks away? Now you can find out. Head over to Special:Nearby and you will know. This is another piece in the puzzle to making it easier to get an overview of the data you care about.

Share if you find something cool and unexpected around you!

Cheers --Lydia Pintscher (WMDE) (talk) 17:09, 29 October 2015 (UTC)

Both Firefox 41 and Chromium 46 just say "Loading" on that website, even after I allowed sharing my location. The consoles don't log errors and there's no network activity. --Mineo (talk) 17:25, 29 October 2015 (UTC)
It only shows one item for me. And no, I don't live in a forest. --Stryn (talk) 17:45, 29 October 2015 (UTC)
No problems on my side (FF 41). The first three items are somewhere in my quarter and have no distance indicated. Then the nearest item is the fourth one (which I can always look at through the window). Matěj Suchánek (talk) 17:59, 29 October 2015 (UTC)
I was suprised that it could find were I live at all. Normally such tools tends to locate me about 30 kilometer to the North. -- Innocent bystander (talk) 20:06, 29 October 2015 (UTC)
It works pretty well for me, although it seems to think I'm slightly northwest of where I am but only by slightly less than a kilometer. I'll have to start improving the entries for these items :) Thryduulf (talk: local | en.wp | en.wikt) 20:29, 29 October 2015 (UTC)
We've made a few fixes. Are people still having issues with the page? (Besides accuracy.) --Lydia Pintscher (WMDE) (talk) 11:43, 2 November 2015 (UTC)
@Lydia Pintscher (WMDE): a Very nice, useful feature, Thank you to all concerned. It would, though be even better if it were available as map overlay. We had a similar feature in early versions of the Wikipedia Android app, but that too was sadly replaced by a list similar to that produced by this tool. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:22, 3 November 2015 (UTC).

wikidata game doesn't open

wikidata-game/distributed doesn't openYamaha5 (talk) 21:47, 2 November 2015 (UTC)

Widar is down. Sjoerd de Bruin (talk) 22:28, 2 November 2015 (UTC)

How to search by property

Is there any easy way to search by property using a gadget or external tool? I would like to find people that (1) are women (2) are painters, writers, possibly other related careers TBD (3) were born before 1800 (4) do not have an article on en.wiki. Even better would be to sort by the number of interwiki links. I see there is https://query.wikidata.org/ but it is not terribly user-friendly... Thanks, Calliopejen1 (talk) 02:48, 3 November 2015 (UTC)

130 female painters born before 1800 who do not have an associated en.wiki article. --Yair rand (talk) 05:23, 3 November 2015 (UTC)
@Yair rand: Thank you! This helped me build the worklist for w:Wikipedia:Meetup/Aphra Behn Society Editathon. Calliopejen1 (talk) 13:48, 3 November 2015 (UTC)

Question about a merge

Philg88 has merged Hill, Rowland (1772-1842) (DNB00) (Q19038799) with Rowland Hill, 1st Viscount Hill (Q336485) and now there are lots of constraint errors in the resulting element. Does the merge need to be reverted or are the constraints the ones that have to be changed? And if the merge has to be reverted, how can we revert merges? -- Agabi10 (talk) 11:59, 3 November 2015 (UTC)

@Philg88: To revert the merge, see Help:Merge#unmerge Help:Merge#unmerge. Please translation administrators, don't block the translation :) author  TomT0m / talk page 12:12, 3 November 2015 (UTC)
Sorry about that - it looks like the merge has been reversed by a bot. Philg88 (talk) 13:40, 3 November 2015 (UTC)

Most used descriptions on Wikidata?

Is it possible to make a list of most used descriptions on Wikidata (by language)? Looking at User:Pasleim/Language_statistics_for_items we have almost 50% items that contains description in English. If we know the most used descriptions it would be easier to run a bot and fill those popular descriptions for other languages also. --Stryn (talk) 17:36, 2 November 2015 (UTC)

It's more urgent to add statements so that the automatic description works well in all language. Or to make the autodescriptions better. author  TomT0m / talk page 18:02, 2 November 2015 (UTC)
In my experience, one of the most commonly used and least helpful description is "human". We should run a bot to delete these descriptions. Jonathan Groß (talk) 18:43, 2 November 2015 (UTC)
Already done, see Wikidata:Bot_requests/Archive/2015/10#Remove_English_description_.22human.22. --Stryn (talk) 18:46, 2 November 2015 (UTC)
I agree with TomT0m. Please do not add descriptions via bot. I really believe the future is auto-descriptions based on properties. These can be generated in many languages and they will automatically improve as statements are added. Just make sure those villages have <instance of:village> and <country:Iran> and the auto-description will be as good as the English description. Add a statement using 'is in the administrative territorial entity' and the auto-description will be better. Joe Filceolaire (talk) 22:56, 3 November 2015 (UTC)
I really don't think we should discourage all bot-generated descriptions. Having descriptions automatically generated from statements would be absolutely great and would remove the need for bots, but we don't have that and, as far as I can tell, there are no plans for it to happen any time soon. We need descriptions now to be able to pick the right item in search results. If bot-generated ones aren't allowed, people are left with no choice but to add them manually or go through numerous identically named items until they find the one they want. - Nikki (talk) 06:23, 4 November 2015 (UTC)
  • Joe Filceolaire, the auto-description is not the same as a description generated by a bot? Or is the software going to generate automatically a description based on the statements when the description is not provided? If so can you provide the phabricator link to suscribe to the progress? It would be interesting knowing how it is going. -- Agabi10 (talk) 23:50, 3 November 2015 (UTC)
Yes. By auto description I mean a description generated on the fly, based on statements so it changes and improves as statements are added. phabricator T91981 covers this. It's actually a mobile App action as they use wikidata descriptions in their search function. Joe Filceolaire (talk) 02:13, 4 November 2015 (UTC)

Fusionproblems

Can someone fusion en:Category:Wedding traditions (Q8150028) with de:Kategorie:Eheschließung ? 898989gt (talk) 17:54, 3 November 2015 (UTC)

✓ Done StevenJ81 (talk) 19:59, 3 November 2015 (UTC)

Main Page in Hebrew

For some reason, the main page in Hebrew (d:Wikidata:עמוד ראשי) does not come up automatically when one changes the interface language, as happens with other languages (I checked fr and de). Can someone please check that? StevenJ81 (talk) 19:53, 3 November 2015 (UTC)

Wikidata:Main Page/Content and other main page stuff ([https://www.wikidata.org/w/index.php?title=Special:Translate&group=agg-Main_Page&language=fi&action=page&filter= all in same page) should be translated first in Hebrew. --Stryn (talk) 20:47, 3 November 2015 (UTC)

Non english name for a country

Hi

I have just found a cluster of entries for the non-english name (used in a number of non english languages) for Australia

Australie - https://www.wikidata.org/wiki/Q13431386

It looks like a bot placed the entries.

I have specifically changed a number of entries where the usage of the non english spelling does not make sense in the text of other entries,

do the properties of ''Australie'' sufficiently link/direct to the english term, and still maintain the non english usage ok?

I hope the question makes sense - I will try re-stating - when a foreign name of a country is a disambig -

is there anything needed other than a link/redirect/property that identifies a non english usage ? JarrahTree (talk) 00:30, 4 November 2015 (UTC)

Your example (Q13431386) isn't about the country. It's a DP, so it can be named Australie. Only when talking about the land Australia using Australie is wrong, in other cases it depends on the context. Mbch331 (talk) 05:56, 4 November 2015 (UTC)
OK - thanks. It is just that I have found other entries where Australie is used very specifically in the english label, about australia, I have been correcting them , as something that has English: for the label, and Australie is the spelling - it seems illogical to me as no one in Australia refers to foreign names for their country, as far as I know JarrahTree (talk) 13:49, 4 November 2015 (UTC)

Producing lists of articles that do not exist in each language for certain Wikidata properties

Hi all

I'm looking for a way to give users an easy to understand list of articles that do not exist for a specific topic in their languages e.g Wikipedia articles for World Heritage Sites that do not exist in Welsh.

I know that Mix n' Match can do this for lists that are added to the tool but I'm looking to do it for any Wikidata property.

Any suggestions would be greatly appreciated

Thanks

John Cummings (talk) 15:03, 4 November 2015 (UTC)

Have a look at the "French" sample query in #Wikidata_weekly_summary_.23182. --- Jura 15:13, 4 November 2015 (UTC)

For people who like reflexion

Hello, I found an interesting problem in the use of part of (P361) and has part(s) (P527) and which would prevent the symmetry between these two properties. If you are interested and have suggestions please have a look at Wikidata_talk:WikiProject_Ontology#Problem_with_has_part_.28P527.29_and_part_of_.28P361.29. Snipre (talk) 15:30, 4 November 2015 (UTC)

Script/gadget required creator template from a page of interest

It would be great if someone could create a script/gadget that puts into the sidebar an active means to utilise user:Magnus Manske's toollabs:wikidata-todo/creator_from_wikidata.php to produce Commons {{creator}} template for the person of interest's WD page with a click. If some smart cookie has already done this then please point that script to me. Thanks.  — billinghurst sDrewth 00:24, 2 November 2015 (UTC)

Maybe someone needs to make a gadget to manage those extra links in the sidebar, instead of making single gadgets everytime. Sjoerd de Bruin (talk) 07:52, 2 November 2015 (UTC)
Multiple gadgets works fine for me, it enables the fine control. Otherwise it will require gadget, with subsidiary choices for those that you want.  — billinghurst sDrewth 09:51, 2 November 2015 (UTC)
Is there a page to park such requests? Or do you store them in phabricator and the are retrieved from there.  — billinghurst sDrewth 05:32, 5 November 2015 (UTC)

Birth or death at sea

Is there a standard way to handle births and deaths at sea? I think legally you are born at the port where the ship lands. I have been adding the body of water, and the port where the ship lands. Should we add an entry for "born at sea" and "died at sea"? --Richard Arthur Norton (1958- ) (talk) 16:05, 2 November 2015 (UTC)

In the United States in recent decades, if a birth or death occurs on a moving conveyance, the birth or death is recorded at the place where the person was removed from the moving conveyance. If the birth or death occurred in the US, the place where the person was removed from the moving conveyance is considered the place of the event. If the birth or death occurred in international waters or a foreign country (including the air space above these) the actual place of birth or death is recorded, as best as can be determined.
The Centers for Disease Control offers a model law on this topic, which some states have adopted:
http://www.cdc.gov/nchs/data/misc/mvsact92b.pdf
Jc3s5h (talk) 17:57, 2 November 2015 (UTC)
There was a previous conversation related to this at Wikidata:Project chat/Archive/2015/06#place of death (P20) - at sea. Thryduulf (talk: local | en.wp | en.wikt) 18:14, 2 November 2015 (UTC)
You are born "at sea" (a place) and generally under the jurisdiction of the country of the carrier, however, there is so much county law that comes into play. Read w:Birth aboard aircraft and ships for a starter. 07:28, 3 November 2015 (UTC)
  • I guess it varies from state to state. In California and New York you are not dead until a physician declares you dead. I just finished a biography where his obituary listed him dying in Arizona in a car accident, but he died on the flight to the hospital on his way to California when he was evacuated. His place of death was listed as the hospital. Should we created an "At sea" parameter? --Richard Arthur Norton (1958- ) (talk) 16:24, 4 November 2015 (UTC)

Areni cave merge

Dear friends, Items Q1007510 and Q4069034 are about he same subject, Areni cave, https://en.wikipedia.org/wiki/Areni-1_cave_complex

I tried to merge them, but there's apparently some conflict. Please, could someone look into this? Thanks. Y-barton (talk) 07:36, 4 November 2015 (UTC)

The problem is that hywiki has 2 articles about this subject. They need to be merged. But I don't speek hy, so I can't be of much further use. (I used Google Translate to see the contents in a language I could understand). Mbch331 (talk) 09:24, 4 November 2015 (UTC)
Thank you, Mbch331!
It looks like the smaller 'Արենի-1_քարանձավային_համալիր' should be merged into 'Արենիի_քարանձավ' (Areni cave). I don't speak Armenian either, but this should be an easy job. All the best. Y-barton (talk) 14:03, 4 November 2015 (UTC)

Thank you for fixing the problem. Y-barton (talk) 18:12, 5 November 2015 (UTC)

Nothing is fixed yet. There are still 2 articles about that cave on hywiki. I only marked 1 as duplicate of the other and moved all non-duplicate sitelinks to 1 item. Mbch331 (talk) 18:31, 5 November 2015 (UTC)
The scope of the two items isn't the same, so I don't see why one would mark them as duplicates. --- Jura 18:52, 5 November 2015 (UTC)

Notability of Commons categories

I asked about the notability of Commons categories at Wikidata talk:Notability#Are Commons categories notable by themselves?. The notability policy currently addresses this area ambiguously, and clarification would be useful. Harej (talk) 19:04, 4 November 2015 (UTC)

The problem is not if category are notable or not but we need to create an item to link categories from the different WPs. Here we see a limit of WD: we didn't split the items used only for interwikis purpose from other which correspond to a real concept. We assume that everything from WPs was good as item and I think this was a mistake. We should found a way to separate items from interwikis management but this is not the case so we have to be coherent. Snipre (talk) 15:10, 5 November 2015 (UTC)

Persons born in certain day

Is there some easy possibility (Query) how to get list of people born e.g. on 5th november? P31=Q5 and P569=+0000000????-11-05 JAn Dudík (talk) 06:30, 5 November 2015 (UTC)

Not sure about WDQ without doing each year separately, but in SPARQL you could adapt the "people or things born or created on the same day of the year as Wikidata" example query mentioned in #Wikidata_weekly_summary_.23182 or the "Whose birth is today" in the list of samples directly on https://query.wikidata.org --- Jura 07:47, 5 November 2015 (UTC)

Area

I invite interested users to discuss how area (P2046) should be used at Property talk:P2046#Standard. -- Innocent bystander (talk) 09:18, 5 November 2015 (UTC)

{ and (

To me { and ( in lightgray on white background look almost the same.

Is there a way to improve this on https://query.wikidata.org ? --- Jura 12:56, 5 November 2015 (UTC)

Jonas is looking into it. --Lydia Pintscher (WMDE) (talk) 14:11, 5 November 2015 (UTC)
Patch up at https://gerrit.wikimedia.org/r/#/c/251241/ --Lydia Pintscher (WMDE) (talk) 14:39, 5 November 2015 (UTC)
That was quick. Thanks to both of you! --- Jura 15:53, 5 November 2015 (UTC)

Wikidata Query: AND NOT?

How do I exclude fictional persons (instance of (P31):fictional human (Q15632617)) with WDQ?--Kopiersperre (talk) 16:32, 5 November 2015 (UTC)

and noclaim[31:15632617]--- Jura 16:45, 5 November 2015 (UTC)
Or if you don't have anything else in "WDQ" part, you can use claim[31:15632617], and mode WDQ: "NOT" so it will exclude all that are fictional human (Q15632617). --Stryn (talk) 16:58, 5 November 2015 (UTC)
Thanks.--Kopiersperre (talk) 18:03, 5 November 2015 (UTC)
@Kopiersperre: For a more efficient request which would also exclude instances of subclasses, you can use : CLAIM[31:(TREE[15632617][][279279])]. (produced in this message with {{WDQ/instances}} author  TomT0m / talk page 12:32, 6 November 2015 (UTC)

ORES or anti-vandalism tool

Hey all. I just made WD:ORES which gives you lots of details about our artificial intelligence anti-vandalism system for Wikidata. Please use them and report mistakes so we make it better and after a while we can have an anti-vandal bot for Wikidata. Thanks Amir (talk) 22:00, 5 November 2015 (UTC)

Average depth and max. depth of a lake

How do I add this information? At Q4127 (Lake Constance) I have added p2048 (height of an object) with the value -251,14 Meter. This would be the max. depth of this lake, the average depth would be -90 m. To add both values I have to qualify the value, but I don´t know how. Another way would be to add two new properties, but I don´t like this solution. --Molarus 08:25, 6 November 2015 (UTC)

What do you think of this? As Qualifier P459 (determination method) and creating two new items "average value" and "minimum value" (with no Wikipedia articel. --Molarus 08:35, 6 November 2015 (UTC)
There is definitely a need for ways to express average and maximum. At Wuppertal cable car line (Q256964) there are two entries for speed 60km/h and 27km/h but no qualifier or other way of expressing which is which. For gradient there is average gradient (P2198) and Maximum gradient (proposed at the same time) is awaiting a decision at Wikidata:Property proposal/Transportation#Maximum gradient. Thryduulf (talk: local | en.wp | en.wikt) 10:43, 6 November 2015 (UTC)

Add Special:Nearby to navigation

I've asked on a somewhat hidden talk page to add Special:Nearby to the site navigation, because in my opinion the feature is somewhat hidden on the desktop version. Please add you comments here. Sjoerd de Bruin (talk) 09:13, 6 November 2015 (UTC)

Descriptions for Wikinews articles

RFC here. --Superchilum(talk to me!) 13:56, 6 November 2015 (UTC)

Use of demonym (P1549)

Was this edit correct, or should the demonym be singular, i.e. instead of Europäerinnen – simply Europäerin? And whilst I'm here, is the qualifier female (Q6581072), as used in this instance, alright, or would have feminine (Q1775415) been better, as per the anonymous posting on the property's talk page? Has anyone got a good overview of these? Jared Preston (talk) 16:43, 5 November 2015 (UTC)

I would say use feminine (Q1775415) (more technically correct). It says singular masculine is preferred, so persumably singular is also preferred in the case of the female gender. Popcorndude (talk) 17:15, 5 November 2015 (UTC)
Why female (Q6581072)? I always use feminine (Q1775415). And I'd add all forms that I know: e.g. feminine, masculine, plural for Russian (where pl.f.=pl.m.). --Infovarius (talk) 20:26, 6 November 2015 (UTC)

SSIDs

It seems that some of the interwiki links on service set (Q1043562) might be better on service set (Q16324483). Would someone who understands the technolgy care to take a look, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:09, 6 November 2015 (UTC)

Fusionproblems

Can someone fusion en:Category:Cyprus Ministers of Finance (Q13259310) and de:Kategorie:Finanzminister (Zypern) ? Rhintoquato (talk) 00:35, 7 November 2015 (UTC)

I've merged them. Silverfish (talk) 00:49, 7 November 2015 (UTC)

How to add dates with undefined calendar ?

If a source specifies a date that could be either in Gregorian or Julian calendars. What is the current recommendation on how to proceed?

  1. don't add
  2. add as Julian
  3. add as Gregorian
  4. guess if it's Julian or Gregorian
  5. add with default calendar
  6. round to months
  7. round to years
  8. wait till the source gets edited to include the calendar
  9. wait till WMDE comes up with a solution
  10. create a new calendar for these
  11. any option I may have missed:
    • 12. add as Julian with a precision range of (e.g.) -0/+10 days (option mentioned by Jc3s5h below)
    • 13. add the value twice, with each calendar, to highlight the uncertainty. One is correct (option mentioned by Filceolaire below)
    • 14. add with one calendar and a qualifier to highlight the uncertainty (similar to option in Phabricator:T105100)
    • 15. attempt to determine the calendar based on context (see comment below).

Have we defined this somewhere? --- Jura 13:43, 25 October 2015 (UTC)

I support option eight. --AmaryllisGardener talk 02:26, 26 October 2015 (UTC)
I would suggest rounding to the extent to allow either possibility. If you are using the user interface to add the data, you do not have the ability to add a tolerance (such as January 5, 1600, Julian, -0 +10 days). So you would have to round to one of the quantities the user interface allows, which might be as much as a decade, depending on what the date is.
However, since it isn't feasible to enter a time zone offset other than zero, I suggest not adding any dates at all until this flaw is fixed. Jc3s5h (talk) 02:42, 26 October 2015 (UTC)
en:Proleptic Gregorian calendar says the number of days differs depending on the date. - Nikki (talk) 04:04, 30 October 2015 (UTC)
Fixed. --- Jura 11:50, 30 October 2015 (UTC)
I'm not an expert in calendar issues, so please do correct me if I've misunderstood something. Anyway, my opinion is: 1 is not a solution, it's just ignoring the problem. It would be nice to be able to enter dates even if we're not sure which of the two options is right instead of having no information at all. 2-5 would mean picking a potentially incorrect calendar with no indication that we don't know if it's correct (which could then lead to incorrect conversions to the other calendar). 6 and 7 could still be wrong around the beginning/end of a month or year and using month or year would make the date even less precise than it really is (as I understand it, if we have a date but don't know whether it's Julian or Gregorian, there are only 2 possibilities for the real date and we can rule out the rest of the days in the month or year). 8 is not really a solution either, what if the only source we can currently find is something like a book? We can't just wait for it to be edited. 9 might work, but WMDE have lots of things to do, we could be waiting a very long time, depending on how high priority they think it is. 10 sounds like it could work. - Nikki (talk) 14:42, 26 October 2015 (UTC)
@Lydia Pintscher (WMDE): is there anything in the pipeline or should we consider this? --- Jura 18:12, 27 October 2015 (UTC)
I'd go with 4 if a reasonable guess can be made. I don't think a technical solution can solve this problem because if we don't know the calendar model for sure we don't know it for sure. No technical magic can solve this. I am hesitant to add an unknown calendar model because this is getting us into all kinds of other issues like being unable to compare points in time. Also it'd not be possible to restrict that to just Gregorian and Julian - we'd also push things in there like stardate. Not good :( --Lydia Pintscher (WMDE) (talk) 11:49, 2 November 2015 (UTC)
So, I take it we can cross out #9.
We are not necessarily looking for a technical solution. We just need to find a way to reflect what can be found in the sources we use. Currently, e.g. the BnF additions are limited as this question is still undecided.
The suggested option #4 seems somehow contradicted by #14: people did guess and now an approach has to be found to correct this.
The scope of #10 would need to be limited to Julian/Gregorian dates, probably within a defined period of time. It would need WMDE to add this to the options in the interface. --- Jura 12:10, 2 November 2015 (UTC)
13. Add both values to highlight the uncertainty - we know it is one of the two. Joe Filceolaire (talk) 20:09, 27 October 2015 (UTC)
Potentially, this could increase the number of statements massively. Sample: for P570, in the years 1582-1922, there are 309294 dates with proleptic Gregorian calendar (Q1985727) and 2180 with proleptic Julian calendar (Q1985786). --- Jura 13:57, 28 October 2015 (UTC)
You should be aware of that the Julian and Gregorian calendars are not the only options. Battle of Poltava (Q152486) took place in June 27, 1709 (Julian), March 11 (Gregorian) but June 18 according to the Swedish calendar. -- Innocent bystander (talk) 14:22, 28 October 2015 (UTC)
I would interpret two statements as meaning both are stated somewhere, which is not the case. - Nikki (talk) 04:04, 30 October 2015 (UTC)
Personally I tend to go with (5), and assume a bot will come along later and flag instances where the only date we have is given in a calendar that wasn't prevalent in that country in that particular year.
As more cross-references to other databases get added, cross-checking should increase and help sort this out.
For the moment, I would regard all existing calendar indications as potentially unreliable. Jheald (talk) 16:09, 28 October 2015 (UTC)
"I would regard all existing calendar indications as potentially unreliable." Absolutly, there have been to many misunderstandings about this model that we can rely on any date except those for the last 100 years. -- Innocent bystander (talk) 06:05, 30 October 2015 (UTC)
  • It's important to be aware that the beginning of the year also changed to 1 January fairly recently. And that some older far eastern dates are given in western months, though they don't actually correspond. (There are even contemporary calenders which I can't find thorough and reliable sources for.) All the best: Rich Farmbrough, 01:27, 3 November 2015 (UTC).
  • We could keep this on hold or, if we want to move ahead, I think we can either go with #14 or #10. I added a number #15. To some extent, I think people do that first. It might also be a better formulation than #4. #12 could be a technical alternative for #10. How shall we conclude this? --- Jura 11:15, 7 November 2015 (UTC)

Automatic label for music albums and singles

Hi, I have a proposal: since the title of a music album or single is the same in every part of the world in every language, I propose that if an item has the property Property:P31 (instance of) as Q482994 (album) or Q134556 (single) a bot can automatically fill the labels with the name of the items. What do you think about it? --Superchilum(talk to me!) 08:19, 4 November 2015 (UTC)

That's not entirely true. Names from different scripts are rarely kept the same and names are sometimes translated (e.g. Harry Potter and the Philosopher's Stone – Music From and Inspired by the Motion Picture (Q1138738)) or changed for other reasons. - Nikki (talk) 09:40, 4 November 2015 (UTC)
I guess this could often be done by editions of such works. But I am not sure it can be safe to do that today, since we cannot be sure that such items have been created/used in a correct way. -- Innocent bystander (talk) 09:49, 4 November 2015 (UTC)
ok, if we exclude non-latin alphabets and soundtracks, do you think it could still be true? --Superchilum(talk to me!) 09:55, 4 November 2015 (UTC)
I don’t think it would be good to automatically set the label, since it’s completely redundant information. However, it might be a good idea to display the automatic labels in certain contexts (Wikidata, possibly WD-using apps), similar to the automatic descriptions proposed elsewhere. —Galaktos (talk) 11:50, 4 November 2015 (UTC)
Some time ago I already done something like this for human, in en, es, fr, and it. I think is useful and I can do this task. Automatic label isn't a solution because it work only on wikidata we need label to use on Wikipedia or other site not in Wikimedia project. --ValterVB (talk) 09:41, 7 November 2015 (UTC)

Protection concept against vandalism

Due to the last developments in Wikidata, especially the activation of arbitrary access, the number of Wikipedia articles that obtain data from Wikidata increases. Therefore the Wikipedia versions have to think about an easy and comfortable way to lead unexperienced users to Wikidata items to update data. However, this will also increase the amount of vandalism significantly. Is there any concept to protect against vandalism? I think of two general options, but both of them need software development:

  • Patrolled versions, comparable to the patrolled versions in the Wikipedias, and
  • the possibility to protect statements against changes, once these statements have been checked for correctness, have a reliable reference and are very unlikely to change in future (it is statements like birthday for a person etc. – once they are checked and referenced, there is no need to change them ever again).

Is there any discussion on this topic? Or any concept? How are Wikidata items protected against vandalism at the moment? Yellowcard (talk) 09:44, 5 November 2015 (UTC)

Currently the same system is in place as on most Wikipedias: Page protection. If someone reports repeated vandalism (or an admin notices this himself/herself) an admin can protect a page against edits by unconfirmed users (users with an account that's less than 4 days old and not-logged-in users). For example see: project:Sandbox (Q3938). Mbch331 (talk) 09:53, 5 November 2015 (UTC)
(edit conflict) This system helps against systematic vandalism in one particular item, but does not help to check edits by new users. To decide to semi-protect an item, we have to find out that it was subject to vandalism in the past, but the tricky part is finding the vandalism in between of lots of good edits. Furthermore, protecting the item prevents useful edits by anonymous and new users, too – but we want those edits. Therefore I think a system of flagged revisions could help to investigate edits, accept good ones and revert bad ones such as vandalism. Yellowcard (talk) 09:55, 5 November 2015 (UTC)
Wikidata has patrolled versions. On Special:RecentChanges the unpatrolled edits are marked with a red question mark. However, in contrast to a system with flagged versions unpatrolled edits are public visible. --Pasleim (talk) 10:14, 5 November 2015 (UTC)
The flagged version is not possible for WD due to the number of items and edits compare to the number of contributors: too many changes won't be checked. IMHO we should use some dynamic checking according to proofed versions of items or create external data sets and perform regularly some checks with the current version to spot changes and validate them or not. For data from online databases the dev team is looking for some automatic and online check but this is a future development and not a ongoing task. Snipre (talk) 14:38, 5 November 2015 (UTC)
Hi Snipre, that sounds reasonable. The patrolled versions might be a good tool against vandalism, at least on long distance view. However, I think a way of protecting single statements or snaks should be implemented as well. Yellowcard (talk) 17:03, 6 November 2015 (UTC)
Is it possible to infect Wikipedia page with unpatrolled state if it uses Wikidata and one or more items is in unpatrolled state? We need something that works with en:Wikipedia:Flagged revisions/Sighted versions, which are enabled in plwiki. I expect that any sighted version of page never loads unpatrolled changes from wikidata. Paweł Ziemian (talk) 22:46, 6 November 2015 (UTC)
+1, that would be a very good step. Yellowcard (talk) 16:35, 8 November 2015 (UTC)

Big mistakes (but no vanalisme or bad intent)

Here is one example of what I mean, and this is happening a few times over the day. An article is loosing *all* of it's interwiki-links, plus all the properties, and for one or two language links a new item is created. When I go out to the talk page of the user, I either get no answer because the user never visits the WikiData-project, or they have no idea why it happened, because they are not active WikiData-users and simply have no clue. What I have seen, is that it has to do with some kind of renaming articles, maybe with an old script. But it's pretty time consuming to repair, at least, I do not know a one minute solution to clean this up. Edoderoo (talk) 07:14, 6 November 2015 (UTC)

I think it has something to do with people don't understanding the UI. Sjoerd de Bruin (talk) 07:48, 6 November 2015 (UTC)
I had a case too: see Talk:Q3804639. No answer either. author  TomT0m / talk page 12:36, 6 November 2015 (UTC)
Did you leave a message on the talkpage of the user? More chance of an answer then the talkpage of an item. Mbch331 (talk) 15:17, 6 November 2015 (UTC)
It seems to come from an incorrect sitelink (1 of 37) to vi:Gonal, Gangawati when the item was first created (November 2012). --- Jura 15:37, 6 November 2015 (UTC)

Once I had interesting answer: User talk:Kaiketsu :) --Edgars2007 (talk) 15:14, 8 November 2015 (UTC)

Well, if they actually started out from vi, they might have been doing what the UI there suggests ("Edit interlanguage links"). --- Jura 15:22, 8 November 2015 (UTC)

Thijs

What the hell does that mean? I merge the articles about the name into a single item and then someone comes and breaks everything. What could ever make one think that nl:Thijs and en:Thijs talk about different things? --Qbli2mHd (talk) 16:56, 7 November 2015 (UTC)

nlwiki seems to say that it's a first name and combines it with "Tijs"
enwiki takes it as a surname and a first name and has a separate page on the first name "Tijs". Not sure what the other 200 wikis will do. --- Jura 17:06, 7 November 2015 (UTC)
@Qbli2mHd: Note that as a rule, we try to have different items for first names and surnames, with further different items for each possible spelling. This is so that we can have the items in place to be able to code occurrences of the name very precisely. Jheald (talk) 17:10, 7 November 2015 (UTC)
see WikiProject Names author  TomT0m / talk page 12:49, 8 November 2015 (UTC)

Phase 2

Hi, folks! What is the Phase 2? I saw it on news... --Almondega (talk) 17:43, 7 November 2015 (UTC)

Phase 1 is about adding stuff of a sister project to Wikidata, phase 2 is the other way around: adding stuff of Wikidata to a sister project. Sjoerd de Bruin (talk) 21:21, 7 November 2015 (UTC)

I thought it was:

  • Phase 1: Collect all the data
  • Phase 2: ???
  • Phase 3: PROFIT!

SCNR Jonathan Groß (talk) 21:27, 7 November 2015 (UTC)

If so I guess ??? can be described as "make people dependent on that data" ;) --Pajn (talk) 21:41, 7 November 2015 (UTC)

Thanks! --Almondega (talk) 22:26, 7 November 2015 (UTC)

no any one our try to do something because the african people have no are comfidance to any of place where are many human being so the african union must be to make sure our country are equctor than ather country in african continante,tanzani people are not understand about multipart system so can have enjoy about this programe ,the multipart in tanganyika start in 1997 after independance the ageint of this multipary system is julius kambarage nyerere from tanzania now have new system of multipart  – The preceding unsigned comment was added by 197.250.195.181 (talk • contribs) at 10:02, 8 November 2015 (UTC).

Phases were formulation of the initial developpement plan. A lot of things happenned since and "phases" formulation was abandonned a long time ago :) author  TomT0m / talk page 12:51, 8 November 2015 (UTC)

There is an overview at sitelinks and number of claims. --- Jura 23:07, 8 November 2015 (UTC)

Category Tree

Hello , I need the category tree i.e hierarchy of categories of wikipedia . Can I get that using wikidata

No you can't. Each wikipedia has its own category, you can retrieve with for example pywikibot or by analysing Wikipedia dumps. author  TomT0m / talk page 15:56, 9 November 2015 (UTC)
There's a tool: Vcat. Just change the category name on the URL. --Stryn (talk) 17:04, 9 November 2015 (UTC)

Wikidata weekly summary #183

Here's your quick overview of what has been happening around Wikidata over the last week.
Highlights of 3 years of Wikidata by Madgalena Wiegner

Good to see "Open requests for adminship" being properly maintained, again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:41, 9 November 2015 (UTC)

What percentage of biographical entries is sportspeople?

Just a quick query request: what percentage of our total biographies is sportspeople (Q5984861)? And if there's a better place to ask such queries, do let me know. Cheers, --Piotrus (talk) 05:21, 3 November 2015 (UTC)

Of the ones we know, about 17% (of 2.9 million). Some may be known for other things as well. --- Jura 07:17, 3 November 2015 (UTC)
@Jura1: Can you tell me how was this number calculated? --Piotrus (talk) 03:00, 10 November 2015 (UTC)
@Piotrus: I used AutoList with the WDQ query claim[31:5] (instance of (P31):human (Q5)) which returned 2956761 items. I then used the query claim[31:5] AND claim[106:(tree[2066131][][279])] (instance of (P31):human (Q5) AND occupation (P106):(anything which has subclass of (P279):athlete (Q2066131)) which returned 477749 items. 477749 / 2956761 = 0.161578. I'm not sure what Jura1 used, but I got a similar number, so maybe it's a similar method. --BurritoBazooka (talk) 03:50, 10 November 2015 (UTC)

Special:ItemByTitle + Special:GoToLinkedPage

Hello,

Is there any special page or parameter of one of these special pages that allows doing both in one hop? For instance, a link like Special:GoToLinkedPageOfItemByTitle/frwiki/enwiki/Univers that would send directly to en:Universe. The goal is to create a template on the French Wikipedia that takes the title of a French article and produces a link to the English version (and for now, I can't get do ItemByTitle in Lua).

Orlodrim (talk) 21:47, 9 November 2015 (UTC)

We have discussed it before, so there is a bug for it somewhere! -- Innocent bystander (talk) 18:28, 10 November 2015 (UTC)

Community Wishlist Survey

Hi everyone! Apologies for posting in English. Translations are very welcome.

The Community Tech team at the Wikimedia Foundation is focused on building improved curation and moderation tools for experienced Wikimedia contributors. We're now starting a Community Wishlist Survey to find the most useful projects that we can work on.

For phase 1 of the survey, we're inviting all active contributors to submit brief proposals, explaining the project that you'd like us to work on, and why it's important. Phase 1 will last for 2 weeks. In phase 2, we'll ask you to vote on the proposals. Afterwards, we'll analyze the top 10 proposals and create a prioritized wishlist.

While most of this process will be conducted in English, we're inviting people from any Wikimedia wiki to submit proposals. We'll also invite volunteer translators to help translate proposals into English.

Your proposal should include: the problem that you want to solve, who would benefit, and a proposed solution, if you have one. You can submit your proposal on the Community Wishlist Survey page, using the entry field and the big blue button. We will be accepting proposals for 2 weeks, ending on November 23.

We're looking forward to hearing your ideas!

Community Tech Team via MediaWiki message delivery (talk) 21:57, 9 November 2015 (UTC)
I added a very Wikidata related proposal: Structured metadata for Commons. You might want to endore that one! Multichill (talk) 18:50, 10 November 2015 (UTC)

Wikimania 2016 scholarships ambassadors needed

Hello! Wikimania 2016 scholarships will soon be open; by the end of the week we'll form the committee and we need your help, see Scholarship committee for details.

If you want to carefully review nearly a thousand applications in January, you might be a perfect committee member. Otherwise, you can volunteer as "ambassador": you will observe all the committee activities, ensure that people from your language or project manage to apply for a scholarship, translate scholarship applications written in your language to English and so on. Ambassadors are allowed to ask for a scholarship, unlike committee members.

Wikimania 2016 scholarships subteam 10:47, 10 November 2015 (UTC)

Why do we need to write the same item description over and over again? for Cats and disambigs?!

As we all know, the standard description for Cats on Wikipedia and other projects is "Wikimedia category" (en), "page de catégorie d'un projet Wikimédia" (fr), "Wikimedia-Kategorie" (de), "维基媒体项目分类" (zh), and so forth. Right now the situation is, for EVERY such item, we (including the bots) have to import (from Wikipedias) these descriptions, every time; may I ask why? Does it give us any usefulness, other than wasting storage space of wikidata like crazy?! How much space do we have, for a hundred thousand Cats, each taking 4,000 Bytes, merely for their entitlement?! Well maybe it's not much, but it's still ridiculous. And the funniest part is, sometimes the description ain't identical, some are older ("Wikipedia category"), causing mergers to fail, and we have to fix it manually.

I know this situation has been existing for years, so maybe there're some reasons for this I'm ignorant of, and maybe I'm a bit silly to shout it out---but if I happen to be not silly, do you all agree, to deprecate the descriptions for a Cat item? We should, we really should, make a special flag (property or something, invent one if need), for all these lovely and annoying Cats that we have raised up in Wikipedias. Oh right, and the dabs, the disambig pages!! Wikipedia disambiguation page, Wikimedia-Begriffsklärungsseite, ウィキペディアの曖昧さ回避ページ, страница значений, Oh God! Gees Christ!! Sorry I need to clarify that, there are cases where a namespace is disambig in one lang but article in another; so, to be applicable to my proposed description-free status, one item has to be declared as a "global disambig", being disambig everywhere globally; this might be a bit tricky to establish and do maintenance, but I think it's doable at bot level. -- SzMithrandir (talk) 09:35, 5 November 2015 (UTC)

A further point I should make: to do this thoroughly, we need to disable descriptions (make them grey) if the item is truely a Cat or a Disambig --- in fact I believe this can totally be handled by the Statement. -- SzMithrandir (talk) 09:49, 5 November 2015 (UTC)
  • The problem is there are in many cases more items with the same label. Currently the search function only displays the label and description. If we don't have the description for Wikimedia Category or Wikimedia Disambuguation Page, people don't know what item they are looking at and the chances for wrong items getting linked are much larger. Mbch331 (talk) 09:43, 5 November 2015 (UTC)
@Mbch331: Well, then it's a technical issue, and need to be fixed, not to be left like this. Why only the description text be displayed in searching? Or, why can't the description text be controlled and "called from" the Statement (as I added above)? --- I wanna point out, this is a mistake from the beginning of wikidata; namespace prefixed should be treated carefully and should not be just truncated like the global contribution tool does (the links are really buggy, especially the non-articles). Oh right, this reminds me, we have Template: and WP: as well! But let's talk about Cats first, since the number is too huge. (And I take back part of what I said about disambig) -- SzMithrandir (talk) 10:05, 5 November 2015 (UTC)
It indeed is a technical issue. What you are proposing is some kind of autodescription. For Wikidata itself, this is already possible by using a script (//tools.wmflabs.org/wikidata-todo/autodesc.js), but that doesn't work outside Wikidata (for example it doesn't work with WE-Framework). And not everyone is that pleased with the idea of autodescriptions (mostly because a lot of items lack enough statements to make a good description). For example if the only statement about a cat is that it's a taxon, that won't be helpful (witch categories of course, you are finished quickly). So the usefullness of automated description depends on the number and quality of statements. Mbch331 (talk) 10:20, 5 November 2015 (UTC)
@Mbch331: eh ... I'm not following you very well. Are you saying, that, the status quo is (already) AutoDesc, and is not satisfactory? --- What I don't understand from you is that, you seem to say that people (including you) have a quite high expectation for the description, wishing them to be detailed and accurate. May I ask why, and to what extent are you expecting? Personally, probably because I'm just a plebian Wikipedian, I don't expect them to give any useful function, as far as my user experience tells.
　To clarify, I only know one instance of wikidata showing its power of description on WP, that is, say w:en:Futian Middle School (a middle school in Shenzhen), such link (only when the article is not yet created), will automatically display global search results---however my example here is not best, since such school cannot be found unless we search for 福田中学 on WikiData---gees, even w:en:福田中学 doesn't give results now?! It is only in search of 福田中学 on Wikipedia.
　I hope I've made points clear so far, that the description barely help at all, for a common Wikipedian. -- SzMithrandir (talk) 01:55, 6 November 2015 (UTC)
  • For disambiguations and categories? Currently these are mostly bot generated. Probably because these descriptions are not considered sufficiently important for development time to be spent on it. --- Jura 11:18, 5 November 2015 (UTC)
Not sure, it might be opposite: disambiguations and categories generally just have one statement per item and there isn't much benefit in generating a dynamic description based on the increasing depth of the item. --- Jura 15:50, 5 November 2015 (UTC)
Yes, Jura understands my point correctly :D --- there's no dynamic changing at all; unless the world changes, the seas rise up as mountains, and domain names of Wikipedia is lost. -- 01:55, 6 November 2015 (UTC)　　And by the way I just fixed w:en:Patrick Joseph McCormick for ye. -- SzMithrandir (talk) 02:39, 6 November 2015 (UTC)
  • Even I, who is such an advocate for autodescriptions that I have stopped adding descriptions and now I only add basic statements to bare items I come accross, even I agree that for these particular cases it makes sense for a bot to add a standard description. I would just ask that you get the bot to add the "instance of" statement and to add descriptions in multiple languages as well as the English description. Joe Filceolaire (talk) 04:01, 6 November 2015 (UTC)
By the way my impression is that there is a bot out there doing this. Is that so? Joe Filceolaire (talk) 04:03, 6 November 2015 (UTC)
User:Popcornbot was adding category descriptions based on the labels of Wikimedia category (Q4167836), but I seem to have missed a pywikibot update and haven't been running it recently due to it producing incorrect results. Popcorndude (talk) 15:53, 6 November 2015 (UTC)
Thank you so much guys! If this could be done, for Cat:, Template:, WP:, it will be so great and saving so much pain!
To repeat a previous point, beware the disambig cases. The disambig has to be "global" for the bot to exercise such standardization --- there are cases where one language does disambig and others don't! --- And the criteria of global disambig is probably ... say, if it's already identified in a main language (presumably en)(for cyrillic, ru; for kanji, zh/ja) as a hard-core disambig, e.g. a given name, a surname, a common toponym, a page with (disambiguation) suffix, etc. And maybe we should allow editors (Wikipedians) to turn the standardization on somehow, some button in the statement area? (Or still in the description/alias area?) -- SzMithrandir (talk) 23:06, 6 November 2015 (UTC)
  • I added a lot of this descriptions and labels with my bot. The useful thing is that with standard descriptions we can found a lot of problematic items. ex. someone don't use the merge gadget to merge items for category, disambiguation or template, but move the sitelink, with my bot the next week I can detect this and I can fix the problem. With disambiguation I can found duplicate item or wrong disambiguation item. I don't think that with dynamic descriptions is possible detect this--ValterVB (talk) 09:36, 7 November 2015 (UTC)

I plainly agree that descriptions for disambiguations and other items of the kind are useful.

However, when an item has been wrongly tagged as "disambig." and all labels have been added, it is really, really long to clean up the mess like I had to do on Harold Long (Q5661558) [2] - it would be nice to have something to clean all those wrong labels in 1 swipe, when the error is obvious, considering the item :/

I stumble upon those rather often… — sometimes it's a clear mistake, sometimes it is the consequence of moving links, or renaming… --Hsarrazin (talk) 14:12, 11 November 2015 (UTC)

@Hsarrazin: Try MediaWiki:Gadget-dataDrainer.js. --Stryn (talk) 16:49, 11 November 2015 (UTC)
Thanks Stryn, is it a Gadget ? I can't find it in Preferences… --Hsarrazin (talk) 17:27, 11 November 2015 (UTC)
Hsarrazin, you have to add a following line into your common.js
importScript( 'MediaWiki:Gadget-dataDrainer.js' );
--Stryn (talk) 18:07, 11 November 2015 (UTC)

Honorary citizenship

How to express honorary citizenship received by person? --EugeneZelenko (talk) 15:51, 11 November 2015 (UTC)

Q21197409

This was a data item for the Commons category for the Sophocles play Electra, and was the main category for Q733444. It has been deleted as "not notable", and I believe this deletion was made in error.

If the "notability" requirements do not permit such data items to exist, then they need to be adjusted. They should allow for data items for Commons categories that are separate from their primary data item. --EncycloPetey (talk) 18:03, 8 November 2015 (UTC)

@Ymblanter:: the deleter. author  TomT0m / talk page 18:05, 8 November 2015 (UTC)

The item contained no sitelinks. An item about a Wikimedia Category without sitelinks isn't notable. Mbch331 (talk) 18:11, 8 November 2015 (UTC)
@EncycloPetey: Why not linking the category directly to the Electra (Q733444)  View with Reasonator View with SQID item with the common cat property ? author  TomT0m / talk page 18:39, 8 November 2015 (UTC)
@TomT0m: Some prefer to link directly, some prefer to have a separate data item. The latter approach makes more sense to me, but the category was linked both ways for this item, because there is disagreement on Wikidata concerning the "correct" way to link categories. --EncycloPetey (talk) 19:07, 8 November 2015 (UTC)
There was no category on any project linked from the item.--Ymblanter (talk) 19:02, 8 November 2015 (UTC)
There is a Commons category for the play commons:Category:Electra (Sophocles), and that's why the item existed. --EncycloPetey (talk) 19:03, 8 November 2015 (UTC)
It wasn't defined in the item. Sjoerd de Bruin (talk) 19:09, 8 November 2015 (UTC)
I have no means to verify that claim. --EncycloPetey (talk) 19:12, 8 November 2015 (UTC)
It contained no sitelinks and 2 statements: instance of (P31)Wikimedia category (Q4167836) and category's main topic (P301)Electra (Q733444). That was all (and some labels/descriptions). Mbch331 (talk) 19:16, 8 November 2015 (UTC)
I have no means to verify that claim. All I know is that, if the claim is true, I can't add the Commons link because the data item has been deleted. I guess the correct procedure here is to create a whole new data item and add the link there. --EncycloPetey (talk) 19:58, 8 November 2015 (UTC)
You can't, but what you can is trust the administrators on this project. By repeatedly saying that you can't verify it, you are implicitly saying you don't trust the admins that respond here. Mbch331 (talk) 20:03, 8 November 2015 (UTC)
No, I am saying exactly what I am saying. I have no ability to access the deleted information, so I cannot verify the claim. It is true that I have little faith in the admins here (even less so in light of this pointless conversation), but that's not the same as not trusting them. --EncycloPetey (talk) 20:14, 8 November 2015 (UTC)
Why didn't you contacted the deleting administrator then, if that's what you want... Sjoerd de Bruin (talk) 20:07, 8 November 2015 (UTC)
I have no idea what procedures are in place here and what is not. Procedures differ wildly among the several different projects to which I contribute. And my experience is that issues like this always end up moving to a larger forum anyway. So why did the deleting admin not contact me about the deleted item? Surely an admin ought to know the correct procedure? --EncycloPetey (talk) 20:14, 8 November 2015 (UTC)
I must say I'm also annoyed when I see in my watchlist that someone deleted one item, that I might have created, and that no one noticed me. It leaves a weird taste in the mouth and I don't like to have to ask "what was this again ?" to the deleter. author  TomT0m / talk page 20:10, 8 November 2015 (UTC)

So, I have created Q21408077 as a placeholder with the aforementioned Commons link. It needs to be merged with the data in Q21197409, but I cannot do that because the item has been deleted. --EncycloPetey (talk) 20:18, 8 November 2015 (UTC)

@EncycloPetey: ✓ Done. --Epìdosis 20:41, 8 November 2015 (UTC)

This thread does not make much sense: The new item Electra (Q21197409) does not comply with the notability guidelines and should be deleted. Commons:Category:Electra (Sophocles) is already linked to Electra (Q733444) though Commons category (P373). @EncycloPetey: you seem to be trying to prove some point started in this other thread. In the future, please consider if it is in the best interest of the project before posting yet another thread. Andreasm háblame / just talk to me 01:53, 9 November 2015 (UTC)

@Andreasmperu: That other link did not exist at the time. Also, as pointed out in both this thread and the other thread, there is not yet any agreement on the correct way to link Commons categories, so your complaint makes no sense unless you are pushing for some other agenda. The item Electra (Q21197409) does comply with notability guidelines since it contains a valid sitelink. Please stop assuming that I do not have the best interest of the project in mind; that is insulting. --EncycloPetey (talk) 02:36, 9 November 2015 (UTC)
There is another discussion further up at Wikidata:Project_chat#Notability_of_Commons_categories (most of the discussion is on the page linked from there) about what the section about Commons categories in the notability guidelines actually means. - Nikki (talk) 05:51, 9 November 2015 (UTC)
For the time being (until some other decision has been taken) items only consisting of a Commons category are not notable. This is the result of an RfA about two years ago.--Ymblanter (talk) 06:23, 9 November 2015 (UTC)
I've asked you about that on Wikidata talk:Notability#Are_Commons_categories_notable_by_themselves.3F (trying to avoid this turning into another parallel discussion about it :)). - Nikki (talk) 09:14, 9 November 2015 (UTC)
I have to say, I don't see the value supposedly added by creating a category-like item Electra (Q21197409). As a basis for a sitelink from Commons, it's not much use, because there's no other wiki that the sitelink would link the category page to. The main effect (AFAICS) will just be to confuse the drop-down menu if people are wanting to add Electra (Q733444) as the value of a property.
I do see value in adding a Commons category (P373) from Electra (Q733444) -- in fact, over the weekend I have just added 80,000 of them. And I can see why people would want to add a cross-namespace sitelink from the Commonscat directly to the article-like item Electra (Q733444) (even if the community's position is currently ambiguous on such cross-namespace links?) -- not everybody has the wdcat.js script enabled to show incoming P373 links to Commons categories (in fact pretty well nobody does).
So one way or another, I can definitely see the value in associating the Commons cat with the article-like item Q733444. But perhaps people can add to the discussion at Wikidata talk:Notability#Are_Commons_categories_notable_by_themselves.3F, and say why, if they think items for lone Commons categories are a good idea, because at the moment I'm not seeing what such items would be supposed to give us. Jheald (talk) 11:37, 9 November 2015 (UTC)
Because there is a singularity on how we handle Commons category wrt. usual wikimedia categories, and because we fail to have a concensus on how to handle them. The most parcimonious solution is "handle them exactly like any other category. The current situation is actually weird, it seems that everybody prefers a statu quo of an historical hardly justified and unredable situation. It's time we settle this. All this discussions are annoying. author  TomT0m / talk page 11:47, 9 November 2015 (UTC)
I'm not sure if I would describe a plan that calls for the creation of 2.5 million new items, with no prospects of content or usefulness, exactly "parsimonious". (Doesn't parsimony have something to do with not multiplying entities beyond what is necessary?).
In the future, each Commons category will automatically have a page on the Commons wikibase instance ("CommonsData" ?) That page will be automatically created when the category is created, automatically removed if it is deleted. If we do want to have a wikibase page for every category on Commons, that would seem to be the place to have it. Jheald (talk) 12:02, 9 November 2015 (UTC)
@Jheald: "Among competing hypotheses, the one with the fewest assumptions should be selected." => Assumption : a common category is a wikimedian category as the other ones, and should be treated as such. That means, no required hypothesis at all. We can get rid of the properties specific to commons cat. I fail to see how having them is this repository or in another one does actually change anything. author  TomT0m / talk page 12:22, 9 November 2015 (UTC)
So, If there is only a Commons category, the proposal is to treat it as a property. But if that category exists on both Commons and a Wikipedia, then the category deserves a data item? That's a weird way to handle it, and terribly inconsistent. Whether it is a data item or not then depends not upon the quantity itself, but upon parallel quantities at other projects. --EncycloPetey (talk) 14:02, 9 November 2015 (UTC)
You can (and should) set a Commons category (P373) if there is a corresponding article-like item whether or not the category exists on both Commons and a Wikipedia. But there's not a lot of point in creating a category-like item, if there aren't going to be any Wikipedia categories to sitelink to, because that's about all a category-like item lets you do.
(Besides, most Commons people would seem to prefer their categories to sitelink to articles anyway, whatever we say here.) Jheald (talk) 15:57, 9 November 2015 (UTC)
Wikidata is so confusing. I've been told in the past that sitelinks from Commons categories aren't permitted on "article" wikidata items. There was an RFC about Commons links with a lengthy discussion, which resulted in an outcome that was later overturned, apparently because changing the software would have been too hard. The "solution" instead is that Commons categories would link only to "category" items and there'd be some template hackery to make things work. That means the Commons sitelink to Electra (Q21197409) is invalid, and a "category" item should be created to hold that site link. Personally I think it's insane, but that's what Wikidata people decided. Ghouston (talk) 21:46, 9 November 2015 (UTC)
The number of such "cross-namespace" sitelinks, from Commons categories to article-like wikidata items, is now over 200,000 -- and has more than doubled in the last 12 months. As far as I can see, whatever that RfC might or might not have decided, the community appears simply not to care. Jheald (talk) 22:21, 9 November 2015 (UTC)
Like that RFC says "Commons has been deployed long enough and it is now starting to get beyond a joke at the fact we have yet to establish any suitable norms for how to handle Commons." Ghouston (talk) 22:57, 9 November 2015 (UTC)
@Jheald: So, what do we do then if there is a both page on Commons AND a category. We can't have two links to Commons from the same data item, so again, how the Commons category situation is handled has so many unresolved issues that affect what is done, that it would be impossible to explain it to anyone. The longer this goes unresolved, the worse the problem becomes. --EncycloPetey (talk) 19:44, 11 November 2015 (UTC)
It looks like there are two conflicting issues here. First, many non-Wikidatians see Wikidata mainly as a repository for Interwiki. That is not an unique problem with Commons. On the other hand, from Wikidata point of view, the Category-namespace maybe in fact is the main namespace on Common. And we tend to link also non-ns:0 in other projects (like Author-ns in Wikisource and Appendix-ns in eswp) to Wikipedia ns:0-pages. If we regard Commons category-namespace as the main namespace of Commons, what to do with the Gallery-namespace? Well, why not leave them out of our scope until we have solved the category-pages? We may find a way on the road! -- Innocent bystander (talk) 20:15, 11 November 2015 (UTC)
That would be preferable to creating millions of category items for Commons categories that don't link directly to anything else. I don't know how you'd make an idea like that "official" though, I guess it would need a whole new RFC process. I still think the best solution was the original outcome of that RFC above: that Wikidata items should be considered to correspond to real world concepts, instead of wiki objects such as articles and categories. Ghouston (talk) 21:57, 11 November 2015 (UTC)
To many RfC's has failed to give any results at all. We have to reform that process to get a system that support the community. I do not see the problem with having items about Commons categories here. We have items related to disambigs, and personally, I do not see any value with that at all. I can tell the same thing about items for templates and modules. What value do they bring to this project? Some Commons-categories adds very little value, but some could add a lot. One example is categories about architectural details in buildings. I see a lot of value in such items, no matter if there ever will be any article on Wikipedia about them. I am currently doing experiments with arbitrary access in taxonomy, and I have found great value of collecting information from > 100 item, even if the WP-project itself ever will have articles about only a fraction of them. -- Innocent bystander (talk) 07:40, 12 November 2015 (UTC)

Wiktionary redirect Q21278897

Based on their category at enwiki, I added this to a series of items.

These items link to a "soft" redirect at enwiki. Sample: w:Museophile.

Shall we change the label of Q21278897 to "term" or delete these items? --- Jura 17:32, 10 November 2015 (UTC)

Well, if they could be usefull in statements, I see no point in deleting them. -- Innocent bystander (talk) 18:26, 10 November 2015 (UTC)
See Wikidata:Notability/Exclusion criteria, soft redirects are already considered not notable. - Nikki (talk) 06:06, 11 November 2015 (UTC)
If we delete them, we would need to find a way to avoid that they get re-created.
If they are useful in statements, we could still keep them. In that case "Wiktionary redirect" might not be the ideal concept for P31.
@GZWDer, Ladsgroup:, what do you think? --- Jura 11:44, 11 November 2015 (UTC)
That's a much broader problem which applies to everything we exclude. phab:T97577 would help a bit by letting us remove the pages from Special:UnconnectedPages, but I'm not aware of a way to prevent people from adding sitelinks. - Nikki (talk) 12:14, 11 November 2015 (UTC)
I suppose this item will eventually contains sitelinks for Wiktionary. --Infovarius (talk) 14:56, 11 November 2015 (UTC)
Not according to the most recent proposal for Wiktionary support. The proposal is that interwiki links would use a different and automatic system (because interwiki links on Wiktionary link spellings, not concepts) and the data items would have new ID prefixes ("L", "F" and "S" instead of "Q"). - Nikki (talk) 18:48, 11 November 2015 (UTC)

Per what Nikki said. I don't think we should keep them. Excluding them from unconnected pages is not possible AFAIK. We can focus on excluding them in gadgets, etc. I think that would be easy. Amir (talk) 07:42, 12 November 2015 (UTC)

Guidance requested on PREVIEW function

The Wikisources are available through the preview function on items, however, they are not suitably functioning. I will hazard a guess that it is due to the header/author templates that is used, but I have no idea why. Is it possible to get some guidance whether the Wikisources can do anything to make the preview feature functioning, or is it something that needs to be done at the Wikidata side of operations. Thanks.  — billinghurst sDrewth 21:07, 10 November 2015 (UTC)

@Hoo man, Lydia Pintscher (WMDE): can one of you please point me to a person for this question?  — billinghurst sDrewth 02:50, 12 November 2015 (UTC)
Are you using the preview gadget for this? Katie has been working on a new version in phabricator:T86755. Could you maybe try and see if that copes better with the Wikisource pages? I'd also love for someone to get Katie's work finished and live here. --Lydia Pintscher (WMDE) (talk) 11:48, 12 November 2015 (UTC)

Heads-up: ~14K painters inbound

I will soon start importing "missing" ~14K painters from YourPaintings. These have all been automatically and manually checked against Wikidata, but that process took months (damn volunteers!), so there may be a few duplicates that have been created in the meantime. --Magnus Manske (talk) 14:16, 11 November 2015 (UTC)

If anyone wants to do a last quick check for new bluelinks, there's a bluelink/redlink list for the collection vs en-wiki at en:Wikipedia:GLAM/Your_paintings/Painters_born_1200-1399.
@Magnus Manske: Does your import script check to see whether a Art UK artist ID (P1367) value may have been claimed and added to an item independently of Mix'n'Match ? -- ie whether there may be some P1367 values that now do have items, but that Mix'n'match doesn't yet know about ? Jheald (talk) 14:49, 11 November 2015 (UTC)
Are you importing birth and dates? As seen in this example, BBC Your Paintings includes birth and death dates, but does not seem to provide any explicit statement about whether the dates are in the Julian or Gregorian calendar. How will you know which calendar to use, since Wikidata requires this be explicitly indicated? Jc3s5h (talk) 14:59, 11 November 2015 (UTC)
@Magnus Manske: Looks like from eg Henry John Stock (Q21453397) that you're not initially importing dates or nationality. Please do -- it saves a lot of work, and makes it far easier to assess the collection for duplicates. @Jc3s5h: It's not as if they're going to be worse than any other date on Wikidata regarding Julian / Gregorian -- this indication should always be regarded as unreliable, unless explicitly sourced. Jheald (talk) 15:14, 11 November 2015 (UTC)
If automatically adding birth/deaths for an actual person (doesn't apply to fictional characters) the Gregorian date is less than or equal to 13 calendar days greater than the Julian date. So if you know it's one of these two calendars, but not which, you could enter the date, precision day, before = 0, after = 13. Jc3s5h (talk) 16:10, 12 November 2015 (UTC)

A few answers:

I have recently created about 1500 items from missing ULAN entries. It might be worth double-checking entries whose name match an item with a Union List of Artist Names ID (P245).-Zolo (talk) 21:12, 11 November 2015 (UTC)

Redundancy between Position held and Head of government

It seems there are two ways to record that someone was a mayor : either the Position held property on the person item, or Head of government property on the city item.

What is the recommended way to enter such information? I am just starting here, but as I tried to have a look around, I saw both ways used, sometimes for the same position (for example Manuel Cobo in Madrid).

Koxinga (talk) 20:16, 11 November 2015 (UTC)

There is no way to query atm. inverse properties on client wiki to build infobox, so at this point there is no real other way to use both ways to be able to show the information on both articles. author  TomT0m / talk page 20:59, 11 November 2015 (UTC)
@Koxinga: you shouldn't be using P6 for a person. P6 is used for the corporate body (country/state/area), not on a people page (should be explained on the talk page for each property) but in short "A corporate body has a head of government".

On people pages you utilise P39 to show the position that a person held, and as such they can have many positions over time, even concurrently. In short "a person holds a position".

The last one in the mix is the position itself that shows the officeholders (over time), and the corporate body for which it applies.  — billinghurst sDrewth 02:44, 12 November 2015 (UTC)

Do labels need to be updated following a page move?

I just carried out a number of page moves. (100 or so) For example:

(Page moved from [enwiki:Igbo American] to [enwiki:Igbo Americans])

I notice (as expected) that the link to the Wikipedia article is updated from Igbo American to Igbo Americans.

Is it considered acceptable that the label is singular? The entire point of the page move was a decision that the plural was the preferred approach. If the label should be changed to plural how does this happen? Is it done manually, is there a bot that can do something like this, is there a way when doing the page move to have it happen automatically?--Sphilbrick (talk) 02:31, 12 November 2015 (UTC)

No bot can easily see if a page-move require a change of label. If you think the label should be changed in your items, you can require help from a at botowner at Wikidata:Bot requests. -- Innocent bystander (talk) 08:21, 12 November 2015 (UTC)
Singular labels can more easily be reused in wikipedia infoboxes so I prefer them to plural labels. Joe Filceolaire (talk) 16:41, 12 November 2015 (UTC)

Q2393193

I want to know why the article "Time complexity" on English Wikipedia doesn't show the language links which are already here.--Alexander Misel (talk) 07:55, 12 November 2015 (UTC)

It does to me, you are probably affected by some kind of cache-problem. -- Innocent bystander (talk) 08:17, 12 November 2015 (UTC)

One item, two IMDb ID (P345)

Is it allowed that one item like Q3346699 has two IMDb ID (P345) claims? I think the better way would be to create two new items, the two parts of Q3346699 and link them to Q3346699 and put the IMDb ID (P345) claims there. What do you think? --Jobu0101 (talk) 20:14, 11 November 2015 (UTC)

In some cases an item can have 2 IMDb ID (P345) claims, however, they must be about the same subject. These are two movies and should be 2 items. An item can almost never have 2 tt id's, 2x nm of nm+ch is possible (although should still be checked). Mbch331 (talk) 21:11, 11 November 2015 (UTC)
How is 2xnm possible and who wants to fix Q3346699? --Jobu0101 (talk) 22:16, 11 November 2015 (UTC)
I've been thinking and actually Nymphomaniac (Q3346699) should be 3 items: 1 movieseries (with the interwiki links) and the seperate movies linked to Nymphomaniac (Q3346699) using has part(s) (P527) / part of (P361). And I wasn't planning on doing the split. Mbch331 (talk) 22:21, 11 November 2015 (UTC)
I did it: Nymphomaniac (Q3346699), Nymphomaniac: Volume I (Q21468403), Nymphomaniac: Volume II (Q21468405) Queryzo (talk) 09:25, 12 November 2015 (UTC)
And what about 2xnm? How is that reasonable? --Jobu0101 (talk) 23:47, 11 November 2015 (UTC)

There is also another case that it hasn't been mentioned here. It can be that one of the two is a redirect to the other. In this case the redirection should not be deleted, it should be ranked as deprecated instead. I think that the constraint reports ignore the deprecated values when checking everything is OK, so it wouldn't suppose any violation. And about the 2xnm if you notify the duplication to IMDb they usually merge the elements, but they are so slow doing it (I'm waiting about two months to know if they're going to merge some duplicate characters or not), other way is adding them as exceptions of the constraint, but ideally when they correct the duplication the exceptions should be removed and the redirection ranked as deprecated. -- Agabi10 (talk) 23:51, 11 November 2015 (UTC)

Indeed in case of a redirect, the redirected id needs to be deprecated (and needs a reason for deprecated rank (P2241) that explains that the id has been merged with the other id). If you're waiting for 2 months for a merge on IMDB it is safe to conclude the merge has been rejected by IMDB (According to http://akas.imdb.com/czone/times there is no real backlog in merges). Mbch331 (talk) 09:52, 12 November 2015 (UTC)
Mbch331 I didn't know about that, I posted a message in the costumer service forum and I didn't get an answer, maybe it get unnoticed. By the way, what value should be used in the property-value pair with reason for deprecated rank (P2241) should be used tell that it was merged? -- Agabi10 (talk) 20:36, 12 November 2015 (UTC)
Agabi10 you can use merged value (Q21469979) as a value for reason for deprecated rank (P2241). There wasn't any item yet, so I created it. Mbch331 (talk) 20:46, 12 November 2015 (UTC)

Geographical queries

I've recently noticed that a large number of items marked with continent:Antarctica (continent (P30):Antarctica (Q51)) are in fact not in Antarctica at all; this mostly seems to affect places in the Falklands and South Georgia but it also caught a few places in South America, such as various Chilean islands.

Most of these have coordinates, and it feels like it should be easy to say "tell me everything which is north of 60S and has this tag" (or conversely, south of 60 and does not). I don't think this is practical with WDQ (which uses "around a point" queries - can it be done with SPARQL, and if so, how? Andrew Gray (talk) 22:13, 12 November 2015 (UTC)

This query (largely based on [3], I'm not that good at SPARQL yet) seems to work. - Nikki (talk) 11:01, 13 November 2015 (UTC)
(ec) There are some examples of queries with coordinates at Wikidata:SPARQL_query_service/queries#Working_with_co-ordinates
Here's a query for everything north of 60S: tinyurl.com/qcdreef, sorted by latitude and also giving the value of located in/on physical feature (P706) where available. It finds 1021 matches. Jheald (talk) 11:05, 13 November 2015 (UTC)
998 distinct items: tinyurl.com/q2v676b (Some were duplicated in the above queries because of multiple values for co-ordinates or for P706). Jheald (talk) 11:17, 13 November 2015 (UTC)
Is there a reason you're not linking to the queries? - Nikki (talk) 13:15, 13 November 2015 (UTC)
Just a personal dislike of long blocks of unreadable line noise in wikitext editing pages. Jheald (talk) 13:43, 13 November 2015 (UTC)

Wikimania 2016

Drop everything you are doing right now and head over to Wikidata:Wikimania 2016. It is time to organize the sessions and the conference! I am posting this on English and German and would be thanksful if you could post it in any language you know. --Tobias1984 (talk) 22:39, 27 October 2015 (UTC)

Preventing archiving. --Tobias1984 (talk) 08:02, 3 November 2015 (UTC)
Around 2 weeks left for comments! Don't put if off for too long. --Tobias1984 (talk) 22:38, 7 November 2015 (UTC)
Around 1 week left for comments. --Tobias1984 (talk) 09:29, 14 November 2015 (UTC)

nickname (P1449)

Are there any restrictions on nickname (P1449) entries, like, not violating BLP? I ask this since my edits on CY Leung (Q15023) had been rollbacked and warned. But I think politician nicknames are often humiliating or insultive. If there is a restriction, it shall be stated explicitly (perhaps in the discussion page of nickname (P1449)). --578985s (talk) 10:23, 14 November 2015 (UTC)

@Carrotkit, Liuxinyu970226: notification.--578985s (talk) 10:23, 14 November 2015 (UTC)

native label (P1705) and official name (P1448)

Someone can explain the different use of this 2 properties? I really don't found differences. Example in John F. Kennedy International Airport (Q8685) John F. Kennedy International Airport is native label (P1705) or is official name (P1448)? --ValterVB (talk) 13:18, 14 November 2015 (UTC)

Maybe the official name would be "New York International Airport" and native label "Idlewild Airport". At least, pre-1963. --- Jura 13:58, 14 November 2015 (UTC)
But in this case I must to use qualifier. Is an official name but with "start time" = 1963 --ValterVB (talk) 14:27, 14 November 2015 (UTC)
@ValterVB: Yep, and/or use the "preferred" rank for the nowdays official name.
So we back to the original question: how to use native label (P1705)? :) I ping @Paweł Ziemian: that is the proposer of the property. --ValterVB (talk) 15:53, 14 November 2015 (UTC)
I proposed the property because I need it for native language name. However it is helpful in every situation described below by Thryduulf. Official name is defined in some official documents, or acts. Otherwise it is native name. I think business uses official names. The simple definition for native name of some place would be the name used for taxi driver to get there. Paweł Ziemian (talk) 21:16, 14 November 2015 (UTC)
You can follow the pre-1963 sample. --- Jura 15:54, 14 November 2015 (UTC)

I use native label (P1705) for things that do not have an official name, e.g. a person or an event, but do have a native language. Many things also have official names in more languages than the native language, e.g. countries have official names in English even if English is not a native language of that country. Thryduulf (talk: local | en.wp | en.wikt) 18:34, 14 November 2015 (UTC)

Hi, in eswiki we would like to show on the infoboxes a link to the list of municipalities in a region when there is a local list about it and we would like to get the list through Wikidata when possible. For that in Wikidata we have Spain (Q29) and we have list of cities of Spain (Q189098) and some people were changing the instance of to link to the list element, but I'm not happy with this solution (and I think it is incorrect). Is there any suitable property to link this elements or we should open a new property proposal? -- Agabi10 (talk) 17:33, 13 November 2015 (UTC)

This is probably a case where you have to directly specify list of cities of Spain (Q189098) into the template as a supplied parameter-value.
At the moment (as far as I am aware), Lua does not let you show the results of simple queries, ie all items that have a particular property that has your item as its object, so you can't show results of a sort-of "what links here" lookup in the way that Reasonator does. (Is there a ticket open for this?).
But in any case, "list of municipalities in region X" or "... in country Y" wouldn't even have X or Y as a direct object of is a list of (P360), but only as the object of a qualifier:
⟨ list of cities of Spain (Q189098) ⟩ is a list of (P360) [[Special:Search/Property:is a list of (P360)|Search]] ⟨ municipality (Q15284) ⟩
country (P17) [[Special:Search/Property:country (P17)|Search]] ⟨ Spain (Q29) ⟩
,
so even if Lua did allow stored results of simple queries, it would need to know to look at qualifiers, which starts to be quite a complicated query.
You are quite right though that Spain (Q29) instance of (P31) list of cities of Spain (Q189098) would be entirely wrong and inappropriate. Jheald (talk) 17:50, 13 November 2015 (UTC)
Jheald, what we want is to have in the entity Spain (Q29) some property with the value list of cities of Spain (Q189098), we already have the list articles created and for now that part would be out of scope.
⟨ Spain (Q29) ⟩ some property Search ⟨ list of cities of Spain (Q189098) ⟩
And I forgot saying that we also would need the list linked into the municipalities, which can be problematic but can be achieved with LUA following the located in the administrative territorial entity (P131) chain until the country or an element with the list in it. -- Agabi10 (talk) 18:08, 13 November 2015 (UTC)
If we were to go down the road of creating a new property, it should probably be something quite widely usable, for instance
⟨ Spain (Q29) ⟩ "has list" Search ⟨ list of cities of Spain (Q189098) ⟩
of (P642) [[Special:Search/Property:of (P642)|Search]] ⟨ municipality (Q15284) ⟩
using "has list" to indicate that a list exists that the infobox may wish to link to, and of (P642) to indicate what the list covers as it may or may not be relevant to what the infobox is looking for -- we do have rather a lot of lists that apply to Spain, some others of which might also be present (presumably not all). Jheald (talk) 08:39, 14 November 2015 (UTC)
Instead of list of cities of Spain (Q189098) you should be using municipality of Spain (Q2074737) which is a proper wikidata entity. Joe Filceolaire (talk) 08:57, 14 November 2015 (UTC)
@Filceolaire: Don't you mean "instead of municipality (Q15284) we should be using municipality of Spain (Q2074737)" ? Jheald (talk) 09:03, 14 November 2015 (UTC)
We often have iw-conflicts between "lists of X" and "X". And many articles includes both pieces of information. -- Innocent bystander (talk) 10:32, 14 November 2015 (UTC)
By now I created a property proposal in unsorted (I don't know where to put this kind of properties) -- Agabi10 (talk) 16:02, 15 November 2015 (UTC)

Indian nobility

Hoi, when you compare nobility of the Netherlands and nobility of India, it is clear that much more can be done for the nobility of India. The number of people involved and the scale of events is a magnitude bigger in India and it is therefore great to notice that much information is available in English Wikipedia.

I do not have the time to make a dent in there. It is fairly easy to make a difference and add the familial relations and how positions shifted over time. With this information it becomes easier to address associated issues as well like battles and who was involved. Thanks, GerardM (talk) 08:51, 15 November 2015 (UTC)

Map-valued properties

Can I check whether my understanding of locator map image (P242), location map (P1943) and detail map (P1621) is correct, in particular the difference between the last two ?

Am I right in the following, taking Northumberland (Q23079) as an example:

and we also have

-- so that if I have an annotated plan of a place that doesn't currently have a map, it may be P1621 that it might be worth considering it for ?

Thanks, Jheald (talk) 10:43, 15 November 2015 (UTC)

  • locator map image (P242) is a map suitable for an infobox for the item itself, showing where an entity is located in a wider area
    locator map image (P242) is a map suitable for an infobox for the item itself, showing where an entity is located in a wider area
  • location map (P1943) is a largely blank map, suitable for a push-pin to be added in an infobox for a place within the item -- the most major roads, railways and rivers are marked, but not the details of most settlements.
    location map (P1943) is a largely blank map, suitable for a push-pin to be added in an infobox for a place within the item -- the most major roads, railways and rivers are marked, but not the details of most settlements.
  • detail map (P1621) is for a detailed map or plan of the item, which is probably already too 'busy' to allow further annotation
    detail map (P1621) is for a detailed map or plan of the item, which is probably already too 'busy' to allow further annotation
  • relief location map (P1944) for a relief variant of the location map, such as
    relief location map (P1944) for a relief variant of the location map, such as
I made your post into a gallery above. Looks good. --- Jura 11:00, 15 November 2015 (UTC)

Areni cave merged

Proposal to merge is finally implemented. Now Արենի-1 քարանձավային համալիր is link page to main Areni-1 cave complex (Q1007510) / Արենիի քարանձավ and Areni-1 cave complex (Q4069034) has no link to hywiki.

Any question about Armenian (Q8785) now can be given in Wikidata:Project chat/hy. Welcome! - Kareyac (talk) 17:06, 15 November 2015 (UTC)

Items without claims categories

For a few wikis, there are now reports showing how Wikipedia categorized pages linked to items that don't have any claims at Wikidata:

  • Sample for English Wikipedia: Wikidata:Database reports/items without claims categories/enwiki
    • Some of these categories can be used with Autolist to add one or several properties (e.g. "2015 films").
    • Others are more complicated to use ("Coordinates not on Wikidata")
    • Several are of use only to Wikipedia ("All stub articles").
  • One item can appear in several categories :)
  • Due to a database issue, it may be that only about 50% of the items without claims appear on the reports. This should eventually be resolved.
  • Update should be daily.
  • More sites can be added.

For an overview of available reports: Wikidata:Database reports/without claims by site.

Thanks to Pasleim for helping me set this up.

For more statistics on claims by site, see above: #Sitelinks_and_number_of_claims --- Jura 00:55, 11 November 2015 (UTC)

Nice! It might be an idea to look for the talk-page categories on en-wiki as well, to see which wikiprojects are claiming the articles. (On fr-wiki I think this is done on the article pages themselves, but on en-wiki it is the talk pages that have the categories).
It would also be nice to try to separate off maintenance categories from the main lists, but I imagine you may already be working on this. Jheald (talk) 01:42, 11 November 2015 (UTC)
I'm still wondering how to do the sorting. Many of the maintenance categories aren't that useful, but I used a few to create a large amount of claims. There still a few ".. missing geographic coordinates" categories. I'm thinking about adding the QID of the category to make it possible to display whatever property we use there. --- Jura 11:32, 11 November 2015 (UTC)
QID should be possible, but we would need to start adding info to templates and categories that help making use of it. Not sure how to do the talk page part. --- Jura 18:42, 12 November 2015 (UTC)
Looks a bit like what I did with User:NoclaimsBot. I haven't worked on this for a while. Turned out that templates were quite useful for automatic claiming. Multichill (talk) 10:21, 11 November 2015 (UTC)
Unless you decide to revive it, I could add lists by template as well. --- Jura 11:32, 11 November 2015 (UTC)
@Multichill: here we go: templates and items with 0 claims. --- Jura 18:42, 12 November 2015 (UTC)

Wikidata:Database reports/items without claims categories/svwiki shows a lot of new bot created articles. Oddly the data is all template-based and not in Wikidata. --- Jura 19:34, 14 November 2015 (UTC)

There is no hurry, a large set of these articles can suddenly be deleted when errors are detected in them. Let them stay in that way at least a month. See log1 and log2. -- Innocent bystander (talk) 19:48, 14 November 2015 (UTC)
No problem. It just seems a bit dated. I should probably try to find a way to exclude them from the reports. --- Jura 20:45, 15 November 2015 (UTC)

Merge conflict

What can we do with Q482436 and Q16644175? Do we have to wait until the guys in eswiki have solved their problem or can we act already? --Jobu0101 (talk) 18:58, 11 November 2015 (UTC)

You can empty the deprecated item and mark it as Wikimedia duplicated page (Q17362920). But that's all you can do as long as there are two articles. Matěj Suchánek (talk) 19:23, 11 November 2015 (UTC)
 In progress Jobu0101, I already make the content of both articles the same (they were very similar so it wasn't hard to merge the information) and made a request to merge the history of the articles. Thanks. -- Agabi10 (talk) 19:50, 11 November 2015 (UTC)

Okay, thanks for your answers. --Jobu0101 (talk) 20:11, 11 November 2015 (UTC)

✓ Done Jobu0101, and in process of merging some other elements I discovered checking the constraint reports for the IMDb ID. In probably less than a week all the others can be merged here also. -- Agabi10 (talk) 19:03, 15 November 2015 (UTC)

Encyclopedia of Life

Why are we bothering to link to the EoL? like this

It is a crap website, full of more errors and typos than actual information. Just follow this link (the one added to the page noted above), and you'll see some of what I mean. Marchantiopsida is listed as a class under "Bryophytes", which is not a taxon, but Bryophyta (mosses) are not listed as bryophytes. Marchantiopsida is actually a class of Hepaticophyta, which is listed seprately on the page as "Hepatophyta" (a spelling error). They list both Anthophyta and Magnoliophyta, which are both names for the same taxonomic group. They also list "Tacheophyta", which is a typo for "Tracheophyta", which is also listed. All of these errors appear on a page that says essentially nothing more than "bryophytes are green plants" and has a few bad pictures of a very black moss (possibly Grimmia, but it's not identified).

There may come a time when EoL is worth linking to, but right now it is more of a joke and embarrassment. --EncycloPetey (talk) 16:00, 14 November 2015 (UTC)

+1. Lymantria (talk) 17:59, 14 November 2015 (UTC)

Addendum: Here is another egregious example added today. The page is for a group of small tropical plants, but the accompanying image is for a large fossil elk. Can we please agree that EoL should NOT be linked from Wikidata? --EncycloPetey (talk) 22:41, 14 November 2015 (UTC)

Sure you can ask, EncycloPetey, but it's a hopless case. --Succu (talk) 22:46, 14 November 2015 (UTC) PS: Termininja?
The property was proposed and created per Wikidata:Property_proposal/Archive/13#P830. --- Jura 22:50, 14 November 2015 (UTC)
@Jura1: Thanks for the link. So, how do we go about reversing the decision? --EncycloPetey (talk) 00:26, 15 November 2015 (UTC)
An older discussion: User talk:Lockal/Archive/2014/10. --Succu (talk) 22:56, 14 November 2015 (UTC)
Arguably there are many issues with our approach to taxonomy. Throwing stones at others does not help. GerardM (talk) 08:44, 15 November 2015 (UTC)
Neither do aphorisms. The only thing that will help is action, but that is in short supply here. I do not dispute that there are many issues, so why don't we work on this one? --EncycloPetey (talk) 15:44, 15 November 2015 (UTC)
I don't really get the problem. Is having a property identifier on Wikidata is a statement of quality ? I don't think so. And having a property does not imply you have to work on it if you don't think it is worth it. author  TomT0m / talk page 15:51, 15 November 2015 (UTC)

How to make "unique value" constraint violations report ignore deprecated values ?

Is there a way to make the "unique value" constraint violations report ignore deprecated values ?

I thought it already did, but when I added/merged a number of retired Art UK artist ID (P1367) identifer values, (usually reflecting pages that have been merged on the target site, with only one kept) -- for example for William Raymond Dommersen (Q3070720) -- suddenly the number of items in the constraint report has jumped from 93 to 122.

User:Gymel thinks it would be better not to remember such previous values at all (see discussion on my talk page); but, as with this mailing list discussion (continued), I think there can be value in keeping a note of old identifiers, even if they no longer work.

But they certainly shouldn't be appearing in constraint reports. How do I stop this? Jheald (talk) 17:54, 15 November 2015 (UTC)

The merge of the 2 items about William Raymond Dommersen (Q3070720) was done yesterday after 11 AM CET. That means the merge wasn't present in the dumps used for today's report and the bot making the constraint reports didn't know about the merge and still saw 2 items with the same value for Art UK artist ID (P1367). In tomorrows report all entries merged before 11 AM CET today will be removed from the unique value constraint. (There is a long time between the last accepted edit and the creation of the dump.) Constraint reports aren't run against live data, but against daily dumps. Mbch331 (talk) 20:30, 15 November 2015 (UTC)
@Mbch331: I am talking about a different report. I am not talking about two items with one value (that might be sorted out by merging the items). What I am talking about is one item with two values (as might be created by merging previously distinct items). For example, Dora Meeson (Q5297435), where the merge was done at 17:31 GMT on 13 November, in time to be picked up at 10:00 GMT on 14 November, and now appears in the 'not single valued' constraint violation report -- despite one of the values clearly being marked as deprecated.
How can I tell the constraint engine to ignore values marked as deprecated ? Jheald (talk) 21:03, 15 November 2015 (UTC)
I think you are mixing up 2 terms: "unique value" means that only 1 item can have a certain value for a statement (2 or more items with the same value for a statement is a violation of unique value). What you are talking about is "single value". That's where an item can only have 1 value for a certain property. That's the constraint Dora Meeson is violating. In this case you should contact User:Ivan A. Krestinin as he is the person behind Wikidata:Database reports/Constraint violations/P1367. His bot updates those reports. Mbch331 (talk) 21:17, 15 November 2015 (UTC)
Thanks! I've left a message on his talk page. Jheald (talk) 21:59, 15 November 2015 (UTC)

OK, Jheald actually had single value reports in mind, this should be clear enough by now. However the scenario he has in mind may eventually also trigger unique value constraint reports, e.g. when one external identifier was used for two items here, and later the external site corrected the situation: This identifier then is oboslete/deprecated for one item but current for the other one. So issues of keeping ceratin things out of constraints report is not unique to the single value one. In a more general vein: Constraints reports are signalling "issues" to users. Usually they will be "dealt" with, preferably yielding a situation where the isses are "resolved" and automatically vanish once the report is regenerated. For unresolvable issues we have the exception lists in the constraints definition on the properties talk page. However we are increaslingly facing more complex workflows or cooperation models than these most simple cases: For example unique value violations may be indicative of problems here (items should be merged) or on the external dataset (they are conflating something which really shouldn't). And single value violations could mean that the item here should be cleaned up or that the external dataset should perform a merge. So even if all of the issueas are "dealt with here", some of them remain to be dealt with elsewhere: They either should vanish from the constraint reports to prevent editors here to check them ever and ever again, or the should absolutely not vanish from the constraint report since the external dataset is also monitoring it and relies on it as a source for their cleanup actions. JHeald's scenario is comparable, it covers the case where issues have been dealt with here and at the original dataset, but "historical" identifiers should be stored here for the benefit of thirdfourth parties. The recently introduced property reason for deprecated rank (P2241) may have the potential to shape all kinds of workflows like sketched above, i.e. having "dealt with here" could be expressed by marking one or several values as "deprecated" and providing an appropriate reason for it. What's simply missing is a strategy how these differently flavored deprecations can influence constraints reports: Neither "all in" (as it's currently implemented) nor "deprecations generally out" (as in JHealds use case) seem to fit all possible situations. A finer control could be exerted by adding to the report paramters on the talk page a list of specific values for reason for deprecated rank (P2241): (Deprecated) Identifiers qualified by one of these values will be filtered out (or in?) before the actual comparisons for the report in question are executed. With that mechanism (sadly I don't know if that degree of inspection is technically feasible for the reporting mechanics) one could even define several e.g. single value reports for a property: One targeted at editors here listing only issues still undealt with, and one signalling open issues to external datasets. -- Gymel (talk) 22:21, 15 November 2015 (UTC)

As I see it the workflow we should follow is something like this depending if the error is an error of our data or of the external dataset. If the error is ours we solve it and if it is not it will be a longer process:
  1. Report the error to the external dataset and mark it as an exception.
  2. When it is solved there (if it is) mark it as deprecated and remove the exception (we don't want to keep exceptions that have no reason to be because that can cover new errors to either dataset)
It doesn't look so complicated and most of the cases it should have been solved this way and it should not appear in the constraint reports. For more complicated cases we should have to adapt to get the better solution for that specific use case.
Related to the deprecation reason we could create a new constraint to check valid deprecation reasons the same way we do with the qualifiers constraints but only applied to the deprecated ones. That way we should also count the deprecated values for each property, that all deprecated values have heir own reason for deprecated rank (P2241) and that the value of reason for deprecated rank (P2241) is an accepted one. -- Agabi10 (talk) 00:24, 16 November 2015 (UTC)
Not quite: I'm aware of two cases (VIAF ID (P214) and RKDartists ID (P650)) where the constraint report is the reporting mechanism you imply at 1. The "workflow" here does not rely on agreements and reporting channels to and from the maintainers of the external dataset, but rather on the consensus that each side is aware of the other one. In the VIAF example a bot regularily harvests VIAF dumps and adjusts identifiers here accordingly, in the RKD case apparently the maintainers remove identifiers here as part of their cleanup (I have noticed several times RKD identifiers becoming inoperational within 24 hours after a Dutch IP had been removing them here). -- Gymel (talk) 05:38, 16 November 2015 (UTC)

Q482980

Hello,

I'd like to raise the issue of author (Q482980), which I already mentioned several times, for example here. The problem is that "author" is too generic a word to translate properly in many languages, most notably French. 95% of the time, it actually means writer (Q36180), but it also has other meanings depending on the language (songwriter, etc), which often creates confusion. As there are now biographical templates which import raw data from here, it creates a direct problem on some wikipedias. Since I find a bit tiresome to do this kind or this kind of things all the time, I think we should try to find a solution. We might simply remove the "profession" property from the element, so it never appears as a profession, but since it will impact a great number of pages, we should, before that, replace it everywhere with a more appropriate item, basing ourselves on wikipedia's categories. Most of the time, writer (Q36180) is the more appropriate item, but we could use more precise one,s like novelist (Q6625963) or essayist (Q11774202). What do you think ? Jean-Jacques Georges (talk) 12:07, 5 November 2015 (UTC)

First we need a overview of possible subclasses for author. People don't have a picture of what they can use so I think they prefer to let a general term instead of putting a more precise but wrong occupation. Then use of filters can solve most of the problem: if X is an author and an item Y about a song says that the author of the song is X, then you can change author to song writer in X item.
This is a three steps action: 1) you take the list of all persons items with author as profession or occupation, and for one you look for link with an work item (instance of (P31) =book, edition, song, poem, film,...). 2) Then you convert the result in a external tool: for each person item connected with a book/edition, you replace author with writer, if connected with a poem you replace with poet,... and 3) finally you import the new set of data. Snipre (talk) 14:58, 5 November 2015 (UTC)
It's not only a matter of subclasses, but of confusion : "author", depending on the context or the language, can mean "poet", "songwriter", "screenwriter", "non-fiction writer", "novelist", "short story writer", etc. Indeed, I think we should search by categories and replace "author" step by step (i.e. all people listed as "poet" should be listed as such, with "poet" replacing "author"), then, when it has been replaced everywhere, remove the "occupation" attribute from author (Q482980). How do I link the "occupation=author" with a work item ? Jean-Jacques Georges (talk) 16:02, 5 November 2015 (UTC)
I don't understand the problem. Often the same person will do all or many of the things you have just listed; "author" is an appropriately inclusive/non-specific way to cover that.
If the problem is the translation into French, then why not just change the French label for the item ? Jheald (talk) 17:01, 5 November 2015 (UTC)
It's not appropriate because "author" is not really a profession, and the word actually covers several different, unrelated professions. Moreover, the word cannot be properly translated into French, because in that language - and probably others - "auteur" can either be a very generic term (too broad to convey anything meaningful) or mean several, different things depending on the context. IMHO, "author" is just too broad a term to be used as a profession, even in english. If a person is the "author" of several things (books, songs, whatever...) then we should have different items. Moreover "author" is sometimes used in a completely confusing way : many times, I have seen poets who only wrote poetry being listed as "authors" and not as poets. Jean-Jacques Georges (talk) 17:17, 5 November 2015 (UTC)
How is being the author of poetry "completely different, unrelated" to being the author of novels ?
A quick look at the some of the sitelinks for author (Q482980) finds that all the languages I looked at seem to have a compatible view of the word "author" to that in English.
I do note that there is no French sitelink for author (Q482980), and it seems correct that the French label 'auteur' is wrong. So it seems to me that the appropriate thing for the way the item is being used (and the way it is being written about on the sitelinked pages) would be to change the French label to 'écrivain' (which incidentally Google translate is quite happy to back-translate as "author". Or alternatively, perhaps "auteur littéraire" Jheald (talk) 20:30, 5 November 2015 (UTC)
I should add that in English I think the term "author" is more specific, higher status, and (according to ngrams) used more frequently than the term "writer". Used as a general term "writer" might include such writing jobs as, say, a journalist on a newspaper. Whereas to be an "author", IMO implies the writer is the creator of whole works. So a journalist might become an "author" if their newspaper pieces were collected and published as a distinct volume, identifiably theirs. Jheald (talk) 21:05, 5 November 2015 (UTC)
WD shouldn't follow any particular culture so argument like "in English ... the term"author" is more specific, higher status, and (according to ngrams) used more frequently than the term "writer"" can't be valid to let the current situation like it is.
I support the idea of Jean-Jacques Georges but not for the same reason. WD should be able to provide accurate and complete lists for queries. If we start to use sometimes author and sometimes writer to describe the same kind of activities we won't be able to generate correct answers to queries. Instead of using a generic terme we have to use the more specific occupations.
So author should be used only if no more specialized term exists to describe the activity of one person. Snipre (talk) 00:38, 6 November 2015 (UTC)
That's also what I think. My impression is also that there is always a more specialized term to describe such activities. "Author" is just too broad a term to be used in data, especially since data do not give the professional context : its meaning is so wide that it its virtually useless. If take the case, for example, of people who write books, there's no denying that "writer", "novelist", etc, are more precise terms than "author". Jean-Jacques Georges (talk) 08:20, 6 November 2015 (UTC)
In what sense is there "no denying" that "writer" is a more precise term that "author" ? I've denied it directly above. In English "author" is a more precise term than "writer" -- and I suspect the same is true of most other languages that have sitelinks for author (Q482980) -- i.e. almost everywhere except France. Jheald (talk) 08:58, 6 November 2015 (UTC)
  • I'm definitely not sure that it is the case "almost everywhere except France". In Italian, for example, "scrittore" is definitely more precise than "autore" which can mean pretty much anything. I'm not a native English speaker but I'm surprised to read that "writer" is less precise than "author", which often means "writer" but can also mean "author" of anything. Anyway, it is true that "writer" can also mean, in English, things like "screenwriter" or "journalist", which it doesn't mean in French or in Italian. However, if "writer" is not precise enough in English, then we should use things like "Novelist" or "Poet", or "journalist" (or "songwriter", etc) which, if I am not mistaken, are definitely more precise than "author". The fact is that, for the moment, we have many pages which use "author" in a completely imprecise and misleading way (i.e. "author" for poets who only write poetry, for people who are actually songwriters or playwrights, etc. I suspect that this is sometimes due to mistranslations...) so we should find a solution. IMHO, replacing "author" by things like "novelist" or "non-fiction writer", basing ourselves on the categories, would be the right thing to do. Jean-Jacques Georges (talk) 10:18, 6 November 2015 (UTC)
  • Currently author is not more precise that writer if you look at the class structure of WD. So we have to first define the correct structure. Snipre (talk) 11:16, 6 November 2015 (UTC)
I think if "writer" (or "novelist", or "author", or "essayist", or) could be sourced with a database or a secondary source we must not change (with a more precise term or not) or remove the claim. If not... it doesn't matter much at all. Strakhov (talk) 13:03, 6 November 2015 (UTC)

In that case the correct approach would be not removing the "writer", "novelist", "author",... but adding the most specific one as a preferred value. That way it is possible to get only the most specific value/values ignoring the others. -- Agabi10 (talk) 13:31, 6 November 2015 (UTC)

That's one possibility but it seems that most issues on wikidata do not have a preferred value : that would require a lot of work. Jean-Jacques Georges (talk) 13:36, 6 November 2015 (UTC)
I know, but I mean in the case that the generic value is correctly sourced and we can't change the it for a more specific one only. Changing all the values to preferred is not a good idea doing it by bot for most of the cases, so it should be updated manually when we found ourselves in that situation. Doing that work with bots would make it everything even harder to correct than the current situation. -- Agabi10 (talk) 13:50, 6 November 2015 (UTC)
I don't understand why we should keep a generic value when it can be replaced by a more specific - and therefore more useful - one ? Jean-Jacques Georges (talk) 14:41, 6 November 2015 (UTC)
@Agabi10: Please be very sparing in using 'preferred value'. The effect of 'preferred value' is to make all other values cease to exist for people using the most common wdt: representation of properties in SPARQL queries.
A good heuristic is only to use 'preferred value' if other values would be actively misleading to people/bots/scripts that are unable to read qualifiers. Jheald (talk) 17:04, 7 November 2015 (UTC)

Jheald, at this moment I only use the preferred value in cases where all the cast members where listed in cast member (P161) to mark "the main cast members" to avoid adding the full cast to the "protagonists" section of our infoboxes. Anyway, preferred values aren't suppose to "cease to exist" the other values, at least it should not be like that. Only the "deprecated" values should be ignored and only if we don't specify that we want to take them. The preferred values are supposed to be to allow filtering of the most important ones in properties where claims with different importance between them as for example the current population of a city between all of the population data of different years. If SPARQL is not able to handle the preferred values and the normal priority values correctly I would consider it a bug instead of an incorrect or not recommended way to use the preferred value. -- Agabi10 (talk) 18:09, 7 November 2015 (UTC)

@Agabi10: The simple RDF export, which the 'truthy' SPARQL versions wdt: of the property reflects, includes only statements with rank equal to the best ranked statement, for a particular property on a particular item.
So in effect, the preferred values do make all other values "cease to exist", as far as simple SPARQL searches using wdt: properties are concerned.
This is actually very useful, because it excludes values which are true, but only true given a particular qualifier.
However, it means people should be in general be very careful using preferred value, because this will mean other values will not be seen, by the majority of people/bots/scripts/searches looking at the item.
If you have an issue with this, take it up with the developers -- but recognise that it is what is in place now, and that there is some reason at least for it. Jheald (talk) 18:35, 7 November 2015 (UTC)
I must admit that I don't really understand the above.
Anyway, one solution might be to translate "author" as "écrivain" in French, since "auteur" is much too generic. However, if I do so, I'd just have to hope that author (Q482980) hasn't been used erroneously, for people who are actually playwrights or songwriters and not writers of books. Jean-Jacques Georges (talk) 15:02, 9 November 2015 (UTC)
@Jean-Jacques Georges: Is a playwright not a writer in French then ? Jheald (talk) 15:51, 9 November 2015 (UTC)
@Jheald: Nope. One might say that it's a "subcategory" of "writer", but in French (and in other languages probably) "writer" ("écrivain") commonly refers to people who write books (novels, essays...), not plays, poetry, screenplays, etc. Jean-Jacques Georges (talk) 16:54, 9 November 2015 (UTC)
I've been thinking about this issue and it appears that I may have underestimated the differences between French (and other languages) and English : in English, "author" can definitely imply that it refers to an author of books, while the French word "écrivain", which translates as "writer", can carry other meanings in English. So, while I think that the best solution would be to replace author (Q482980) by novelist (Q6625963) or essayist (Q11774202) wherever it can be replaced, I could simply start by changing the way author (Q482980) appears in French, so it appears as "écrivain" instead of "auteur". The same thing could be done for other languages. What do you think ? The problem, then, is that with writer (Q36180), we would have two items with the same name in French, i.e.... Does anybody know how we could fix that ? Jean-Jacques Georges (talk) 14:51, 16 November 2015 (UTC)

For those of subprefecture in Hokkaidō (Q2330190)

In year 2010, the 14 w:Subprefectures of Hokkaido get reorganised and renamed in Japanese, which the article on English, Chinese, Min-Nan-ese, and etc. Wikipedia have already changed their article name to account for the name change, however Japanese and Korean Wikipedia created new articles under the 14 new name and they used different wikidata entry, which mean for all other Wikipedia they're now linking to the historical entry of these subprefectures. How should those wikidata be changed to make entry on all other Wikipedia match those new articles on Japanese and Korean Wikipedia instead?C933103 (talk) 21:06, 15 November 2015 (UTC)

Looks like the simpliest way to solve this is to switch sitelinks, so that the new japanese and korean articles match the en/zh etc-articles. Then the historical articles in japanese and korean only matches each other. -- Innocent bystander (talk) 13:19, 16 November 2015 (UTC)

Academic discipline

I was trying to sort out the differences between:

They all seem to be much the same thing. Any nuance that might distinguish them doesn't seem to be followed consistently between the various language sitelinks. Does anyone have any suggestions on how to sort this out? Merge them all? Cheers, Bovlb (talk) 22:56, 15 November 2015 (UTC)

According to the labels, they all describe a different thing. Also, we can't just merge items with sitelinks, the first three all contain a sitelink to nlwiki. Sjoerd de Bruin (talk) 23:48, 15 November 2015 (UTC)
Some are probably subclasses of others, with a more generic and some dedicated to a specific field of application/knowledge. author  TomT0m / talk page 12:36, 16 November 2015 (UTC)
@Sjoerddebruin: Yes, I realised that, for some pairs, certain language wikipedias have distinct sitelinks, but so far as I can make out, those languages aren't making consistent distinctions. Are you positively asserting that all four are different concepts? Bovlb (talk) 16:35, 16 November 2015 (UTC)
I can't speak for the last one, as I can't read those languages. Sjoerd de Bruin (talk) 16:38, 16 November 2015 (UTC)

Wikidata weekly summary #184

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

formatter url property

The formatter url for Dewey Decimal Classification (P1036) doesn't work.

I get "This website not available" using Chrome on Apple Mac. Joe Filceolaire (talk) 17:31, 16 November 2015 (UTC)

See property talk page or http://www.oclc.org/developer/news/2015/dewey-down.en.html. It's a known issue. Mbch331 (talk) 18:40, 16 November 2015 (UTC)

What is Q3754723?

I have been completely unable to work out what value instance of (P31) and/or subclass of (P279) should have for overspeed (Q3754723). The first time I've been completely stumped in my time here. Thryduulf (talk: local | en.wp | en.wikt) 18:42, 14 November 2015 (UTC)

@Thryduulf: usually i leave such items untouched because i am also not sure. But i noticed something which is done for many comparable items, see Special:WhatLinksHere/Q151885. So maybe add P31=concept (Q151885)? additional qualifiers could make sense, see example Altstoff (Q445722). here it could be "of (P642)=Mechanical engineering" or similar. Holger1959 (talk) 21:11, 14 November 2015 (UTC)
@Thryduulf, Holger1959: Per Help:Classification, the first question to answer to is
  • "does this item is an object or a concrete event ?
    " Example of concrete events beeing "French revolution" or "Kennedy's murder", ... and object are "my computer". This is not. Then if not ...
  • Has this item tokens, and is so, what are they ?
    Here the answer is "yes" : there is a lot of situations in which an engine can overburn. This item is the class of all the times when engine runs two fast. It's a class of events. A class of events involing an engine, obviously, so I'd go for putting a
    ⟨ overspeed (Q3754723)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ mechanical event ⟩
    or a
    ⟨ overspeed (Q3754723)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ engine event ⟩
    , creating the items if needed, with upper the chain a
    ⟨ ... ⟩ subclass of (P279) View with SQID ⟨ event ⟩
    What characterize this kind of events if that the speed of the engine goes of the limits of this engine. So we could further subclass this item with specific events for a more specific model of engines, if we want to. Wealso need a property, if it does not exist yet, to link a kind of events to the kind of items it involves ("engine" here. author  TomT0m / talk page 11:23, 15 November 2015 (UTC)
  • concept or term or event generally works for me --- Jura 12:00, 15 November 2015 (UTC)
    Term is incorrect, in my opinion. We're not dealing with the term "overspeed", we're dealing with overspeed itself. Event probably also isn't really right. Concept might work, but it's broader than is probably necessary. --Yair rand (not logged in) 08:58, 17 November 2015 (UTC)
    @Yair rand: I agree "Term" is not appropriate, as if we were talking of a term we would deal with properties such as "grammatical type" / "ethymology", ... It's not an event, but a class of events. There is clearly a set of events in which an engine overruns/overspeed/whatever. Whever or not an engine is in an overruns state depends on the motor spec, which allows us to say, knowing at a moment the speed of an engine, if or not he is in overrun state, hence wether or not the event qualifies to be classified in that class. author  TomT0m / talk page 11:37, 17 November 2015 (UTC)

A more flexible approach for sources

stated in (P248) and in some cases "imported from" is the preferred way to describe sources here. I would like to open for another approach.

I have realized that such claims like those in Ireland (Q27): "population (P1082):2,828,600 as of 1960; stated in (P248):World Bank (Q7164)" do not gives the expected result when you decode that claim in the client by the help of such tools as Module:Wikidata. The user who added these claims, took the data from the "World Bank", that far is most likely correct. And based on how Help:Sources is written today, the user could most likely not have stated this source in any other way.

But World bank is not the document that support that claim. World bank is rather the publisher of that document. Then it would probably be better to add "publisher (P123):World bank" in the source instead of "P248:World bank". It would be even better if we also add such things as "title:20th century demographics of Ireland/page:127/chapter:10" here (or whatever the title/page/chapter of the document was), but I guess we often do not have that information. The approach of creating a source-item for every single used document is a tiresome work. Often they are used only one single time. And in such cases, adding the source like we do with internet-based sources is maybe a good enough alternative?

Thoughts? -- Innocent bystander (talk) 07:04, 16 November 2015 (UTC)

Agree with the problem between the document and the publisher and perhaps we should create a constraint report about that property in order to detect this kind of misuse.
The addition of all source data in the reference section is possible too. But just be aware if we multiply the data structures (once in a dedicated item, once in the reference section) people (and lua modules) will have some difficulties to extract the data later to display the source data in WP articles.
The problem you point is the good choice of the source. If people take time to select the good source you can find one official source which can be used for dozens or hundreds claims. Typically for census data just use national census documents which provides all the data you want at a certain date for country, regions and sub administrative units like villages and cities. Snipre (talk) 14:39, 16 November 2015 (UTC)
The Wikidata-module I use on svwiki is designed to extract data both from the references in the claims itself AND the statements in the item linked with P248. It was a little tricky to accomplish that, but I think it works fine. -- Innocent bystander (talk) 16:23, 16 November 2015 (UTC)
You answer yourself your question: "The Wikidata-module I use on svwiki". Unless you ensure that all modules in all WPs can do the same, you can't propose to use different ways to store data because this will imply that some WPs will be unable to extract data. This is a strong position but we have to be careful with this kind of decision because WD is not working alone but should propose stable environment in order to let WPs the possibility to create their own modules. I had the same idea as your before but after we started with help:Sources we can't modified every 6 months our policies. Nobody will trust the stability of WD in the other case and use of WD will be avoided. Snipre (talk) 21:51, 16 November 2015 (UTC)
@Snipre: We already have the internet-based sources who already demands us to add a lot of properties in the reference part of the claim. And a source like: "P248:Encyclopedia Galactica" can be supported by such things as "volume:75/page:459/url:example.org/v75p459" that probably cannot be added to the specific item about "Encyclopedia Galactica". The step to create Module:Wikidata more flexible is then not so big as it may look.
Since this is a wiki, we cannot expect everybody to be consistent when they add sources. The newbies on WP often add: The sun is a star<ref>example.org</ref> or The sun is a star (Doe, John, ''Some facts I learned in College.'').
It often take years for us until we format such sources that they are in according to the guidelines on WP. In the meantime, they are still understandable for most of us.
Many of the Properties that themself have formatter URL (P1630) is often used in the sources. See Q140#P141 for a good example. It is impossible to constantly update a module when new such Properties are added almost every week here. But it is possible to make the Module flexible enough to create an external link to almost all of them. See sv:Lejon and the first footnote, how the module solved it. It is maybe not perfect, but probably good enough. -- Innocent bystander (talk) 08:51, 17 November 2015 (UTC)
I formatted the World Bank references incorrectly in those items. I wrote a script a while ago to fix all of those references, but I couldn't find a consistently used name of the database, and then I forgot about it a while later. If no one objects, I'm going to just create an item for "World Bank Database", and then run the script to change the references to point there instead of to World Bank (Q7164).
With regards to the more general issue, I think the solution here is better tools to more easily create items, not to relax the sourcing standards. Anyone know whether the developers are working on anything like that?
Incidentally, the property stated in (P248) already has a constraint limiting values to information (Q11028). I don't know why they're not showing up in the constraint reports. --Yair rand (not logged in) 08:05, 17 November 2015 (UTC)

Ask for help in Lua for modules of the French Wikipedia

Hi everybody and sorry for my English. We are currently fighting on the French Wikipedia about the use of datas from Wikipedia, it is like The Young and the Restless.

We have developped some modules, but it rests little problems that everybody wants to solve. On fr:Module:Infobox/Fonctions/Personne, there is a function function p.mainimage(), it use another function written on fr:Module:Infobox/Fonctions on function p.mainimage(). I think the line to modify is defaultcaption = function() return defaultcaption end, to include the property media legend (P2096). The goal is to make possible to take the data of the caption if it exists and if there is no data on the french infobox.

Then, on fr:Module:Infobox/Fonctions/Personne, we have two functions, function p.birth() and function p.death(). The problem is we don't have again the age of the person when he is alive, and its age at the death when he died.

So, my question is : Is there somebody here that can help me or give me the name of an user that is able to solve these problems. These two points are very important for most user, pro or anti-Wikidata. Jérémy-Günther-Heinz Jähnick (talk) 08:23, 17 November 2015 (UTC)

For the time stuff, you can import Module:Time we use on Czech Wikipedia. If you use Time.newFromWikidataValue, you will get a table with year, month etc. If you want to retrieve the current date, use Time.new(os.date('!*t')).
Some functions, including age computing, are in w:cs:Modul:Wikidata/datum.
For the caption stuff, the mistake is that you sometimes assign defaultcaption a plain string like 'signature' and here an anonymous function function() return defaultcaption end. Captions on Wikidata are stored as qualifiers of the images, so you need to write and invoke a method which can access, filter (by language) and format qualifiers. Then you have to pass caption to the general module as you do with cat, defaultimage, size and change that line to defaultcaption = caption,.
If you had more questions, feel free to ask me on any talk page of mine.
Matěj Suchánek (talk) 09:51, 17 November 2015 (UTC)
Thank you Matěj Suchánek. I let the message on our Wikidata page on FR Wiki. I read the modules, and start to understand the code. Jérémy-Günther-Heinz Jähnick (talk) 15:53, 17 November 2015 (UTC)
We should finally start to develop the Wikidata-related modules in a global module on beta. It does not make sense that every Wikipedia language version develops its own module, but all versions should profit from each other. Yellowcard (talk) 16:49, 17 November 2015 (UTC)
@ Yellowcard : we must share the same modules and the same infoboxes. It is useless to work here together and to work only for our language when we are on Wikipedia. Jérémy-Günther-Heinz Jähnick (talk) 16:40, 18 November 2015 (UTC)
There is an open task on phabricator for this: phabricator:T1238 --Pasleim (talk) 16:54, 18 November 2015 (UTC)

University rectors

How do I tag the rector (P1075) of a university? The solution employer (P108):University of Mannheim (Q317070) (as an example) is not very good in my opinion.--Kopiersperre (talk) 09:38, 17 November 2015 (UTC)

If you are referring to person item, employer (P108):University of Mannheim (Q317070) not bad solution (but can be broader) and can be supplemented by rector (P1075):rector (Q212071):of (P642):University of Mannheim (Q317070) (or you may create new position item "rector of University of Mannheim"). --Jklamo (talk) 11:15, 17 November 2015 (UTC)
Mostly, a position item is the way to go. Also the easiest to generate lists with. Sjoerd de Bruin (talk) 11:23, 17 November 2015 (UTC)
  • I would think the following claims would do the trick:
⟨ University of Mannheim (Q317070)  View with Reasonator View with SQID ⟩ rector (P1075) View with SQID ⟨ Rector Foo ⟩
⟨ Rector Foo ⟩ position held (P39) View with SQID ⟨ Rector of the University of Mannerheim ⟩
or
⟨ Rector Foo ⟩ employer (P108) View with SQID ⟨ University of Mannheim (Q317070)  View with Reasonator View with SQID ⟩
position held (P39) View with SQID ⟨ rector (Q212071)  View with Reasonator View with SQID ⟩
Josh Baumgartner (talk) 18:53, 17 November 2015 (UTC)
I would like to ask a somehow related question: how does one connect the position item to the institution which it leads, in this example "Rector of the University of Mannerheim" with "University of Mannerheim"? Another example I found is United States Secretary of the Treasury (Q4215834) connected with United States Department of the Treasury (Q648666) via part of (P361), which to me is a bit abstract and generic. Do we have a property that best describes this relation?Andrei Stroe (talk) 13:04, 18 November 2015 (UTC)
PS: I think officeholder (P1308) is a better choice to link Rector Foo to the position item than employer (P108).Andrei Stroe (talk) 13:18, 18 November 2015 (UTC)
@Andrei Stroe: Currently, it is not possible. That is why I have proposed two properties for that: Wikidata:Property_proposal/Organization#Office_held_by_head_of_the_organisation and Wikidata:Property_proposal/Organization#Organisation_directed_from_the_office. You are welcome to voice your opinion over there. Andreasm háblame / just talk to me 18:54, 18 November 2015 (UTC)

Stated by / According to

Is there a way, as a qualifier or reference, to attribute a statement to a specific person or organisation. For example

⟨ Eckwersheim derailment (Q21482333)  View with Reasonator View with SQID ⟩ has cause (P828) View with SQID ⟨ excessive speed (Q21482425)  View with Reasonator View with SQID ⟩

is not formally established and en:Eckwersheim derailment#Investigation is careful to note that this is sourced from Agence France-Presse (Q40464) quoting "Dominique-Nicolas Jane, chief of staff at the Alsace regional prefect." I can't find a way to represent that currently? Thryduulf (talk: local | en.wp | en.wikt) 14:22, 17 November 2015 (UTC)

Is this stated by "Alsace regional prefecture" and according to "AFP" or is it stated by AFP referring a quote from the prefecture? -- Gymel (talk) 18:32, 17 November 2015 (UTC)
In this case I'd say it was stated by "Alsace regional prefecture" according to "AFP". However for a demonstration you would have say Participants: 1000 according to "Protest organisation" and 400 according to "Police". Thryduulf (talk: local | en.wp | en.wikt) 01:20, 18 November 2015 (UTC)
Thus in the demonstraction case the number of participants was stated by no one? I wasn't asking for proper English usage which announces a potential controversy already in the wording. I think "our" has cause (P828) points to the source accessible to us and a (one) new qualifier or reference property should be introduced for the source they are relaying. So "according to" would be misleading in many situations and we should rather implement "origin of the information as stated" which may be a bit clumsy. -- Gymel (talk) 05:40, 18 November 2015 (UTC)

The meaning of the deprecated rank

I've noticed a few people lately recommending marking redirecting identifiers as deprecated. On phab:T115112 though, when I mentioned it as one of the reasons to make deprecated statements less prominent, adrianheine commented saying that they think marking redirecting identifiers as deprecated is semantically incorrect because deprecated is for statements which are wrong and Lydia (@Lydia Pintscher (WMDE):) thinks using normal rank for redirecting identifiers would be closest to the intended use of ranks.

Also, there aren't that many deprecated statements yet, but a lot of the deprecated statements I've seen are things like historical population data, old software versions, etc, which Lydia says is definitely wrong.

There's clearly disagreement about how "deprecated" should be used, so it seems like it needs discussing.

(also pinging people involved in earlier discussions on this page: @Jobu0101, Mbch331, Agabi10, Jheald, Gymel:)

- Nikki (talk) 11:01, 18 November 2015 (UTC)


  • "depreciated statement = frequent, but erroneous statement"?
    An example for an identifier might be that "GB" is sometimes mistakenly used, but it's really "UK". One could consider giving preferred rank to current identifiers, compared to redirecting ones with normal rank.
    --- Jura 11:08, 18 November 2015 (UTC)
Lydia points to Help:Ranking and when I read that page, I would say the redirects should be depricated because of the reasons for depricating:
  1. The deprecated rank is used for statements that are known to include errors or that represent outdated knowledge.
  2. it allows other users to know not to re-add the value to the item
  3. it upholds and establishes the integrity of Wikidata as a secondary knowledge base (that collects and links to references), rather than a primary database of facts. Wikidata simply provides information according to specific sources; those sources may or may not reflect contemporary thought or scientific consensus
The redirected items were once correct claims for that item. If I follow the help page correctly I would say, the no longer correct statements should be depricated and if it leaves 1 correct statement that one should be preferred. That's how I read the help page. Mbch331 (talk) 11:10, 18 November 2015 (UTC)
I use "deprecated" for historical population when the data has been republished and updated.
I have one source that tells me that the population of Stockholm was 962,306 as of 1965 and another that it was 965,434 the same date. I marked the first claim here as "deprecated" not because it is old, but because it was wrong. -- Innocent bystander (talk) 11:16, 18 November 2015 (UTC)
Personally I use "deprecated" for VIAF ID (P214) to mark them as "not usable here" (e.g. if the target entry actually conflates different entities). In the P214 case identifiers which are deprecated by the target database (i.e. they implement a redirect) are automatically adjusted by User:KrBot to the preferred / currently used value. I think that's quite o.k., VIAF has about 28M current identifiers plus 7M redirects from obsolete Identifiers, and they have implemented said redirection mechanism: Recording "historical" identifiers here would be redundant and additionally would leave us with the problem of associating this identifier to an entity which doesn't really fit like in the example above. In other cases like RKDartists ID (P650) there are identifiers which "suddenly" don't work any more: Obviously RKD does not implement a redirection mechanism and simply deletes entries which were detected as duplicates or which under ongoing processing were determined as not relevant to them: IMHO these too should be deletede here since there is no way to verify what they have been intended for (and they well never have been distinctive enough to justify association with an WD entry).
So generally we should have very strong reasons to attempt "supporting" historical identifiers by keeping them at all. And I see the abiguity wether "deprecation" is some assessment performed by us or rather records a deprecation decision by external sources. -- Gymel (talk) 11:27, 18 November 2015 (UTC)
  • As we probably wont be doing any maintenance on redirecting identifiers for external identifiers with a large number of identifiers (e.g. VIAF, Imdb), it might be worth using "depreciated rank" for these. --- Jura 11:32, 18 November 2015 (UTC)
But by general consensus identifier properties don't acutally need references when they are entered here based on inspection of the authoritative, online database (we won't find anyone we can quote for the identification of IMDb entry X with WD item Y, we're doing that by ourselves). This "instant verifiability" usually breaks when an identifier is "not supported any more" by the authoritative database. Continuing to maintain the identifier here would imply to provide a reference where one can verify its historical meaning. This could be achieved by accompanying each identifier we enter here with a screendump to be stored at commons - just in case the identifier becomes obsolete one day without prior notice? -- Gymel (talk) 11:44, 18 November 2015 (UTC)
I do not see the value of these identifiers being kept. They are like our sitelinks to different projects. We do not mark the sitelink to "xywikiz:Whatever" as deprecated and add a new one with normal rank. We simply replace them and leave it to the excavators of the edit-history to see what have happend. -- Innocent bystander (talk) 12:25, 18 November 2015 (UTC)
I find it useful to be able to look up what language "be-x-old" related to. --- Jura 12:29, 18 November 2015 (UTC)
@Gymel would imply to ? Why ? No reason to be too much rigorist on deprecated identifiers. It's just here "for information only". It could maybe be useful to interpret subsequent mistake or weird things and correct them, that's all. No reason to overthink this. author  TomT0m / talk page 12:44, 18 November 2015 (UTC)
We would maintain claims which cannot be verified at all just because they once have been in the item (had they been verified then? By whom? How skilled?). Wikidata is a wiki and has its own history built in, I don't see the need to implement its own archive in a competing way again and usually it should'nt be our task to be the archive for 3rd parties. Recently, when User:KrBot was going to import VIAF-generated associations for Wikidata items it took the history of the items into account in order not to import identifiers which alhready had been present at some time and were subsequently deleted. So we have mechanisms to spot mistakes and track weird things. -- Gymel (talk) 13:26, 18 November 2015 (UTC)

In more languages: Switzerland

Tracked in Phabricator
Task T95877

Dear all, I have understood that the section "In more languages" is connected with the country. Strange to see Swiss German for Switzerland and to miss two national languages like Italian and Romansh. Who should correct it? --Ilario (talk) 13:31, 18 November 2015 (UTC)

I thought they are derived from the #babel settings on the user's userpage. Maybe in your case this doesn't work since the page is trancluded from Meta? -- Gymel (talk) 13:43, 18 November 2015 (UTC)
When #babel is missing, it follows the localisation of your ip. I used to have Meänkieli (Q13357) from my computer and it proves that the system is far from flawless. I think I have met one person here who talks Meänkieli. I know there are some more, but I think we have by far more who talks Arabic here. -- Innocent bystander (talk) 14:00, 18 November 2015 (UTC)
This is a bug already tracked in Phabricator, when solved it should read your settings from your languages instead of the default values even if you have your user page on Meta. What I don't know is how the default values are working, maybe Lydia Pintscher could give us some more information about that... -- Agabi10 (talk) 14:12, 18 November 2015 (UTC)
We get the default guesses from Universal Language Selector that takes a number of things into account like location and browser language. Whatever it gives us we take. So if it is not good enough it is best to get improvements done there. --Lydia Pintscher (WMDE) (talk) 14:15, 18 November 2015 (UTC)

Searching for location maps wrongly used as images

We have some tens to hundreds of items about cities and administrative divisions with image (P18) set as the image of a location map, which is wrong and should be fixed. Most of those items should be easy to find because their locator map image (P242) is usually set to the same map. Therefore my question is: Is there an easy way to find items with P18=P242?

I think I can't do it with Autolist or Wikidata Query. I suppose I could get it using SQL, but I never used SQL in Wikidata.

I would thank any help to make the query.--Pere prlpz (talk) 14:25, 18 November 2015 (UTC)

[4] gives you all items with P18=P242 --Pasleim (talk) 14:34, 18 November 2015 (UTC)
Great. Thank you.--Pere prlpz (talk) 14:36, 18 November 2015 (UTC)

data access for Wikispecies, MediaWiki, Meta and Wikinews is coming

Hey everyone :)

Things seem to be going well so we'll move forward and give another bunch of projects access to the data on Wikidata. They so far only have access to the sitelinks. This will be: Wikispecies, MediaWiki, Meta and Wikinews. We'll do this on 2. December. --Lydia Pintscher (WMDE) (talk) 16:58, 18 November 2015 (UTC)

I recently created a new page on en:Wikipedia and when I tried to link to to the German page in the way I was used to, I suddenly was confronted with all sorts of interrogation pages. After spending a while puzzling over why I was looking at all this stuff, I eventually worked out how to make the link. But I must admit that I think its still takes longer than it used to. Did I wonder into unfamiliar ground, or has the process been changed? Leutha (talk) 17:31, 16 November 2015 (UTC)

Both. It all depends on your personal definition of "recently". --Jane023 (talk) 09:38, 20 November 2015 (UTC)

Merging a painting by Gauguin

Please, double check if Q19869305 and Q20381008 should be merged. Note that they have the same inventory number (P217) althoug with different wording and located at different collection (P195). I'm not sure how inventories are organized in Denmark. --Vriullop (talk) 09:57, 17 November 2015 (UTC)

It is one of 30 paintings that belong Statens Museum for Kunst (Q671384) and long-term loan to Ny Carlsberg Glyptotek (Q1140507). --Steenth (talk) 12:24, 19 November 2015 (UTC)
Thanks, I understand. Merged. --Vriullop (talk) 09:36, 20 November 2015 (UTC)

Interwiki

Hi,

i wanted just to add interwiki from Commons to cs.wp. This time traditional dialog box didnt appeared, insted I was moved here to fill in the property. So I have filed the property: Lšelín (Q21503551) and than I wanted to add interwiki. There was an error, because there is allready a property existing. Could you fix it please and link w:cs:Lšelín with c:category:Lšelín. I dont want to study it, nor debug it, nor spend my time on Wikidata. Sorry!--Juandev (talk) 07:13, 18 November 2015 (UTC)

And the same for w:cs:Ostromeč and c:category:Ostromeč. Why this is happining - I want just to add interwiki. I dont want to create new items on d!--Juandev (talk) 08:17, 18 November 2015 (UTC)

It seems to me, that there is no category for Lšelín on cs.wiki to be linked with the category on commons, and there is no gallery page on commons to be linked with the cs.wiki article. Technically, you probably still can add interwiki by editing the source code, but it wouldn't be systematic and I'm afraid some other editor would remove them soon.--Shlomo (talk) 11:22, 19 November 2015 (UTC)

parishes turning deprecated as of 2016

You who know how to question things to the databases here. Do you know if there are any statements like:

located in the administrative territorial entity (P131):QX where QX has statement instance of (P31):parish of the Church of Sweden (Q615980)?

We should put an end date to such statements (if we have any). From 2016, such statements are only legitimate within the Church of Sweden (Q749243). Technically such statements became deprecated already in 2000 when the Swedish lutheran church finally lost its status as national church. But the parishes have not been replaced with districts until now. -- Innocent bystander (talk) 10:55, 18 November 2015 (UTC)

Lots of things are located in administrative territorial entities which are not themselves administrative territorial entities - every informal village for instance. I believe that pretty much every road, museum, monument, church and parish should have a 'located in the administrative territorial entity (P131) statement. As well as this Parishes should also have a 'location (P276)' statement linking them to their diocese (Q665487) - i.e. the next larger religious administrative entity.
In the case of parish of the Church of Sweden (Q615980) there is a problem in that these were both instance of (P31):civil parish (Q4976993) and instance of (P31):parish (Q102496) (religious) until some date when their legal status (but not their location) was changed. Maybe we should just add a statement <instance of:civil parish of Sweden>, with an end date, to each of these parishes? Joe Filceolaire (talk) 19:16, 19 November 2015 (UTC)
Detail (There are levels between Parish and diocese (Q665487) in the Swedish church.)
To make it more complicated. These parishes are in fact the "religious parishes". That they kept some parts of the civil administration until today, was because it was in the 19th century regarded as a religous responsibility to educate children and keep record of birth/deaths and draft soldiers. The civil parishes (socken) have today lost almost every part of their civil administration but are still regarded as an territorial entity used in registration of the cultural heritage.
A very large part of these parishes has since 1999 been merged. We who are not employed by the Swedish church (I am not even member) have very little interest in how the Swedish church today is organised and the notability of new parishes in the Swedish church is an unsolved issue on svwp. -- Innocent bystander (talk) 08:32, 20 November 2015 (UTC)

Copy references

Hello. I enable DuplicateReferences: Adds a link to copy references and add them to other statements on the same item. gadgets but is not working. Am I doing something wrong? Xaris333 (talk) 14:44, 20 November 2015 (UTC)

I did the same yesterday, but although I had the "paste reference" links, I did not manage to "copy" a reference ... Is a link to do that supposed to be shown next to already created references ? author  TomT0m / talk page 14:47, 20 November 2015 (UTC)
Few days a ago I was using User:Bene*/DuplicateReferences.js (See User:Xaris333/common.js). Refreshing tha item page, a copy option was showed near every references. By select copy, the insert reference option was enable. Xaris333 (talk) 14:54, 20 November 2015 (UTC)
See Wikidata:Contact the development team#Adding reference. -- Innocent bystander (talk) 15:39, 20 November 2015 (UTC)

504 Gateway Time-out

API is down. --Jobu0101 (talk) 07:14, 20 November 2015 (UTC)

It is down since thursday night (CET). Actually I have no idea where to report, or where to trace the actual status. Edoderoo (talk) 08:57, 20 November 2015 (UTC)
Phabricator or the development team page would be a good start. Mbch331 (talk) 09:17, 20 November 2015 (UTC)
I thought Phabricator is for bugs, is it also for incidents like this? And "development team page" could be a good place indeed, but I had issues finding it. Sooner or later someone else will fix it I hope. Edoderoo (talk) 09:37, 20 November 2015 (UTC)
If something doesn't work, that should work, that's a bug. Mbch331 (talk) 09:44, 20 November 2015 (UTC)
Hey :) This is Magnus' tool so please do reach out to him. The contact page for the development team is at Wikidata:Contact the development team‎. --Lydia Pintscher (WMDE) (talk) 10:18, 20 November 2015 (UTC)
It's working fine now ... I guess a 20 hour down time, time to catch up ;-) Edoderoo (talk) 20:13, 20 November 2015 (UTC)

What's in Wikidata? New pie chart

Statements by property gives another pie chart. This time by number of statements for a group of properties. --- Jura 11:55, 20 November 2015 (UTC)

Great, tanks for sharing--Ymblanter (talk) 20:14, 20 November 2015 (UTC)
Jura, what is subsumed as bibliographic fields? --Succu (talk) 23:00, 20 November 2015 (UTC)
Good question. It's mainly "publication date (P577), collection (P195), record label (P264), published in (P1433)", but also "title (P1476), publisher (P123), title (P357), volume (P478), page (P304), issue (P433), short author name (P2093), subtitle (P1680)". Not entirely optimal. --- Jura 08:27, 21 November 2015 (UTC)

Does a screenwriter of director have to be an individual or can it also be a group of persons

Currently a lot of director (P57) and screenwriter (P58) claims are added for a group of people (mostly because Wikipedias use the groups instead of individuals). I recently asked for a bot to change that to the individual members of a group (for property P57. The result was that the participants in that discussion said that a group of people could also be a director (Q3455803). The same would then apply to screenwriter (Q28389). P57 requires P106 to be one of film director (Q2526255), director (Q3455803), television director (Q2059704),theatrical director (Q3387717) to not violate that constraint, P58 requires P106 to be screenwriter (Q28389). Problem however is that if we apply P106 to non-individuals they violate the constraints of P106. So what is the best solution in this case? Allowing groups for P57 or P58? Clean up P57 and P58 to individuals (probably using a bot)? Allowing groups to have P106 too? Something completely different? Mbch331 (talk) 12:14, 18 November 2015 (UTC)

I think our constraint system isn't flexible enough. The perfect solution would be:
Checking Claim = P57/P58:Item
If Item has claim P31:Q5 then
 Item has claim: P106 is in {{Q|2526255}}, {{Q|3455803}}, {{Q|2059704}},{{Q|3387717}}, {{Q|28389}}
 Item as claim: P21 is in male, female, etc.
ELSEIF Item has claim P31 subclass of group of people THEN
 Item has claim {{P|527}}:Items
  Items of P527 have claim P31:Q5, P106 is in same list as above, P21 is in same list as above
ELSE Claim violates constraint
But I don't think the current constraint system (or the new one) can handle this. Mbch331 (talk) 15:05, 18 November 2015 (UTC)
That would be a great improvement to how the constraint system is, but probably is hard to do it in an easy to use, but still machine readable way. Also I don't know how it can be represented using properties, which is the way in which it seams that constraints will work in short/medium time. At least is what I suppose we are going to do with the property constraint (P2302) property created a couple of days ago. -- Agabi10 (talk) 20:16, 18 November 2015 (UTC)
I don't know when we're actually going to switch to property based constraints, but the plan is to switch to that system. The properties like P2302 have been created so it can be tested how it works. When we're going to switch I don't know. Also there are 2 type of constraint reports that need to be adapted before we can fully switch from template based to statement based. (The daily reports by KrBot and the reports behind Special:ConstraintReport). Mbch331 (talk) 21:08, 18 November 2015 (UTC)
I think it wouldn't be too difficult to extend the current syntax to allow some conditional constraints while still being easy to use and machine readable, but I don't know how it could be done with properties/statements. For this example, I think adding support for a "when" parameter to constraints might be enough (e.g. {{Constraint:Target required claim|property=P21|when=P31:Q5}}, which would mean that the constraint applies only when the item has P31:Q5). Something like that would be very useful for postal code (P281) too (postcode formats vary from country to country so being able to apply different format constraints based on the value of country (P17) would let us make much better constraints). - Nikki (talk) 07:55, 19 November 2015 (UTC)
I wonder - how about SPARQL-based constraint system? Such thing would be easier to express in SPARQL. --Laboramus (talk) 00:25, 21 November 2015 (UTC)
SPARQL of LUA based are good options (I would prefer PHP-style, but that's only because I know that language better). But this whole discussion about flexible constraints isn't of much use if only humans can be a director (P57) or a screenwriter (P58). And I haven't heared any opinions on that part of the discussion. Mbch331 (talk) 10:20, 22 November 2015 (UTC)

Wiktionary support

Is there an update to the plans for Wiktionary? I just noticed that most supporting properties suggested in preparation at Wikidata:Property_proposal/Sister_projects#Wiktionary got closed as "not done". --- Jura 10:13, 21 November 2015 (UTC)

The most recent proposal is Wikidata:Wiktionary/Development/Proposals/2015-05. It's not being worked on yet. I think it's far too early to propose Wiktionary properties (it's still only a proposal) so I think it would make sense to collect a list of things Wiktionary can store (and whether there's an existing property that might be suitable) somewhere else first (maybe at Wikidata:Wiktionary). - Nikki (talk) 13:19, 21 November 2015 (UTC)
I thought contributors were encouraged to formulate proposals even for in-existent datatypes and not-yet integrated sister projects. This way, they are ready when needed. --- Jura 00:03, 22 November 2015 (UTC)
I didn't say that proposals have to wait until Wiktionary support is finished. I just think it's too early to start deciding how we're going to store the data in Wikidata when we don't even know for sure how the Wiktionary support will work. - Nikki (talk) 10:08, 22 November 2015 (UTC)
Part of the proposal process is that this is being sorted out. --- Jura 11:59, 22 November 2015 (UTC)

delete aspect of history (Q17524420)  View with Reasonator View with SQID ?

These articles are about sequences of events, as we discussed earlier, so I think we should delete this item. What do you think ? author  TomT0m / talk page 13:03, 21 November 2015 (UTC)

There is also history of a country or state (Q17544377). --- Jura 00:21, 22 November 2015 (UTC)
@TomT0m: aspect of history (Q17524420) was relabeled in English to "aspect of history" after the discussion back in September. Several other languages still have the old "Wikimedia history article" label, which is problematic. I don't know exactly how history items should be handled, but I don't think deleting this item outright would make sense now. --Yair rand (talk) 10:24, 22 November 2015 (UTC)
@Yair rand: : Why not just ... story ? If a story is a sequence/set of related events, then of course a story is an aspect of story ... It's the story itself. author  TomT0m / talk page 12:46, 22 November 2015 (UTC)
The purpose is history, not stories. --La femme de menage (talk) 13:08, 22 November 2015 (UTC)
Both are sequences of real events anyway, if not fictional anyway. News articles are called "stories" in english for example (of course I don't speak of fictions here). author  TomT0m / talk page 13:11, 22 November 2015 (UTC)

Please delete a links page

Reliable Bot imports from wikipedias?

In a Wikipedia discussion I came by chance across a link to the following discussion:

Not seeing that this was already an archived discussion, I accidentally posted some commentary there, so now I delete it there and repost it here:

To provide an outside perspective as Wikipedian (and a potential use of WD in the future). I wholeheartedly agree with Snipre, in fact "bots one running wild" and the uncontrolled import of data/information from Wikipedias is one of the main reasons for some Wikipedias developing an increasingly hostile attitude towards WD and its usage in Wikipedias. If WD is ever to function as a central data storage for various Wikimedia projects and in particular Wikipedia as well (in analogy to Commons), then quality has to take the driver's seat over quantity. A central storage needs a much better data integrity than the projects using it, because one mistake in its data will multiply throughout the projects relying on WD, which may cause all sorts of problems. For crude comparison think of a virus placed on a central server than on a single client.The consequences are much more severe and nobody in their right mind would run the server with even less protection/restrictions than the client.

Another things is, that if you envision users of other Wikimedia projects such as Wikipedia or even 3rd party external projects to eventually help with data maintenance when they start using WD, then you might find them rather unwilling to do so, if not enough attention is paid to quality, instead they probably just dump WD from their projects.

In general all the advantages of the central data storage depend on the quality (reliability) of data. If that is not given to reasonable high degree, there is no point to have central data storage at all. All the great application become useless if they operate on false data.--Kmhkmh (talk) 12:00, 19 November 2015 (UTC)

I agree with you that the quality is important, but I think that we'll always will need bots to import the data. The quantity of "relevant" information generated each day is too big for the people adding data to do it manually and what we need is not preventing the inclusion of that data. What we need is to continue improving the constraint reports to detect more errors and inconsistencies and also improving the tools we have to solve the detected errors. Also we can automatize the correction of some errors that are easily correctable.
The problem we have it is not that there are bots importing information to Wikidata from the different Wikipedias, the problem is that not all the people adding the information checks the constraint violations reports and that there are bots that don't make all the corrections they should.
I think that telling that we should stop adding information with bots from the different Wikipedias is the same as telling that we should not be allowing the IPs to edit entities because most of the vandalism is generated by IPs. It goes against what I think Wikidata is. As it is said in the Main Page "Wikidata is a free linked database that can be read and edited by both humans and machines" and I don't like the idea of putting most machines out of the equation. -- Agabi10 (talk) 12:57, 19 November 2015 (UTC)
  • Well, I don't agree with your analogy as it ignores my main point above. Wikipedia is not central data storage hence IP vandalism does not cause any central damage (aside from that WP is using a lot of resources (human and software (various bots, flagged revisions) to combat IP vandalism). For central storage as WD however you need a different even stricter paradigm.
Also I made no arguments against bots as such (you can't run reasonanly WD without any), but that the use of writing bots should be handled more restrictively and more importantly that Wikipedia should not be treated as a reliable source. It would be much better to restrict writing bots to import data from scientific and federal databases that are considered to be reliable. Or to but it this way import from Wikipedias sources rather than from Wikipedia and use stricter rules than Wikipedia for data integrity.
Of course it also depends as what you ultimately envision WD. It is supposed to be only a "Wikidata is a free linked database that can be read and edited by both humans and machines" or is it supposed to be a reliable central data storage for other Wikimedia project (but also external projects) as well. If WD is just the former and not the latter, you might be right, but if it is supposed to be the latter as well, then imho Snipre's criticism is spot on and the current practice isn't really working.--Kmhkmh (talk) 13:23, 19 November 2015 (UTC)
  • @Agabi10: Please read the comments. Nobody requests to stop all data imports but data import from Wikipedias. If you want to use the big sentences just take account on that definition of WD in the Wikidata:Introduction "A secondary database. Wikidata can record not just statements, but also their sources, thus reflecting the diversity of knowledge available and supporting the notion of verifiability".
If adding data is kind of right, adding sourced and verified data is a duty. We agreed to import quite a lot of data from WPs at the beginning because we needed data but since people are working and curating the raw imported data bots can't continue to add unverified data (data from WPs are not sourced because WPs are not a source).
We can't continue to curate the data using constraint reports (I took several weeks to do that job for chemicals) and encourage people from the different WPs to correct and add data when a bot can destroy all the work in some hours (I experienced that situation and now I prefer to stop to correct items until I get an insurance we can work without risk). The main problem with imports from Wikipedias is the articles connected to the wrong items. As people can't correct most of the time the sitelinks due to language barriers they just correct the Wikidata data and assume that Wikipedians will correct their sitelinks when they won't find the data they want to see in their articles.
We finished the first phase which focused on populating the items, now we have to focus on data curating and on quality improving. So only data import from external databases recognized as references should be approved. Snipre (talk) 14:12, 19 November 2015 (UTC)
It would be so wrong to do this. Wrong on several levels. First of all, you conflate two issues. The existence of statements and the existence of sitelinks. When sitelinks are wrong, they need to be aggressively remedied. This means not only removing the wrong links but also to ensure that items exist that relate to the old link. In this way we prevent imports that are wrong. There is no helping it. It needs to happen and the incorrect import is EXACTLY how we know that these sitelinks are wrong.
When statements are wrong, when Wikipedia is wrong, it needs attention. By importing data, such errors get exposed. It is the only way whereby we improve quality not only but also in Wikidata. There is no helping it, and certainly not importing is ignoring the facts without any other mechanism that brings solace.
If anything, we NEED to concentrate on comparison of our data to other sources. Not only to Wikipedia but to any source. When we have lists that indicate issues, we can concentrate on where the problems are. We can signal to the Wikipedias, to other sources that issues exist. This is a much better way of dealing with issues. Wikidata is a tool, it is a mechanism that allows us to make a difference. Only storing data is so little of what we can do... Thanks, GerardM (talk) 16:08, 19 November 2015 (UTC)
  • We have no way of communication back to the Wikipedias. This list is two years old. Nothing happend. --Succu (talk) 16:32, 19 November 2015 (UTC)
  • GerardM Managing sitelinks is not the work of Wikidata: we have no way to force some WPs to link articles to some items. Your aggressively remediation will be kind of attack to the freedom of WPs. Then even when you inform the WPS and the corresponding projects about errors, no answer is providing because some WPs and some projects have no enough contributors to do it or with the skills to judge how they have to manage their articles and sitelinks. Then you have the famous problem of some articles mixing different concepts into one article even when several items exist for them. Data should be splitted into different items but no bot is doing that. All data are just imported in the linked item. And you can't force WPs to split their articles. So Wikidata should focus on data and good data. Snipre (talk) 10:42, 20 November 2015 (UTC)
I concur, Communication beetween Wikipedias and Wikidata is a keypoint. In frwiki a lot of users considers Wikidata as a totally outside project, and it's very hard to communicate on Wikidata on Wikipedia. For example, a simple thing such as translating Wikidata Weekly on a project talk page fr:Discussion Projet:Wikidata is hard, and some people keeps ... asking this to stop because they don't understand how it can help to use Wikidatas datas on Wikipedias. This does not work :/ We certainly MUST tight more the projects to Wikidata, by helping information to go back and forth, and make Wikidata a home for Wikipedians. author  TomT0m / talk page 16:41, 19 November 2015 (UTC)
  • @Snipre: If the main problem are the incorrectly linked articles the problem will still continue existing independently of importing or not the data. What we have to do in that situation is creating ways to solve that problem. Importing data from Wikipedia helps detecting this kind of problems even if we have to clean elements after, the problem is if we only clean the wrong statements. If we only clean the wrong statements our work is worthless, the incorrect sitelinks should be also corrected. Yeah, the person who corrects the data can have language barriers to understand the content of the Wikipedia page, but the good part is that they can easily get in contact with people that can understand them. We have a Project Chat in lots of languages here in Wikidata, and also the Village Pump of the different Wikipedias. Babel also does a good job with the categorization of users depending on the languages they know. When the incorrect statements have imported from Wikimedia project (P143) added it's easy to know to which language we have to go to ask for help.
@Succu: Having that link in Wikidata is completely useless, most of the Wikipedians don't care about what happens in Wikidata and they probably don't know even about the existence of that list if you don't tell so. Have you tried to add that link into the local Wikipedia and to ask for help in the local Village Pump? For most of the people Wikidata is no more than a tool that the Foundation want to force them to use and we are the ones who have to make the difference, not Wikipedias. Wikipedians are used to the way they work until now and they don't want to change that. So we just can't expect that the ones who edit in Wikipedia will be editing in Wikidata, no at this point at least. -- Agabi10 (talk) 16:52, 19 November 2015 (UTC)
  • Sure we did, Agabi10. Most of the problematic cases in taxonomy are caused by bot generated content. --Succu (talk) 17:11, 19 November 2015 (UTC)
  • The problem of sitelinks is not a problem of Wikidata but of WPs: something that is a real choice of some WPs. Example: the case of drug articles which mix commercial data, medical data and chemical data. In Wikidata we have two items for that case, one for the commercial product and one for the active molecule. depending on the choice of the WPs, you can import chemical data in the commercial item or the inverse. Snipre (talk) 10:42, 20 November 2015 (UTC)
For Wikipedians Wikidata is a tool (with central storage aspect across all Wikipedias), they will use it when it is convenient and helpful and otherwise they won't. However the lower data integrity/correctness are (and the less restrictive the procedure to create such data are), the less inclined will be Wikipedians to use use it and to maintain/service WD entries on the side. Or to put it this way, the current practice makes it less likely for Wikipedians to help out.--Kmhkmh (talk) 17:31, 19 November 2015 (UTC)
And if there is not Wikipedian who use Wikidata datas, except in a few cases where there is good opendataset, there won't be any good datas on Wikidata because there won't be anybody to work on it. Deadlock. author  TomT0m / talk page 17:59, 19 November 2015 (UTC)
Can anyone write a bot that runs through all Wikidata edits ever, and undoes all bot reverts of humans? (And maybe notifies the bot author if it happens a lot?) Is that even possible?
I agree that we need to stop, or at least slow down, the uncontrolled bot imports from Wikipedias. There's a lot of problematic data being added. Wikipedia imports, where done, must be supervised by a human. If there are sources on Wikipedia, importing those is important. In many situations, it's important to get another user to look over the job before running the import. Also, it would help if, after doing a full (careful!) import from a Wikipedia in an area, the Wikipedia had its local data cleared out, to prevent the kind of problem where Wikidata gets something fixed and the fix gets overridden by the old data being pulled back from the Wikipedia again. Or, if another import doesn't happen, and the data is left duplicated on a Wikipedia, then editors will continue editing the local versions, and Wikidata will become out of date.
There's a lot going on, and the speed of imperfect data imports is more than we can handle right now. We need more human manual editors curating data, and their work is becoming near impossible with the bots running wild. Curating existing data is more important than adding new data which won't be usable until sufficiently curated anyway. --Yair rand (talk) 20:09, 19 November 2015 (UTC)
  • Running a bot that runs through all Wikidata edits ever is not impossible, but it should not be done to the live data, because it would be generating a lot of unnecessary load to the servers, instead it should be done with a database dump.
Related to the removal of the imported data into the local Wikipedias is something that is hard to do, because even if the objective is being able to use templates without local parameters this is something that at least for now it's impossible for us (the people from eswiki). There are neither all the needed properties created nor all of the current values of the infoboxes in most of the "Wikidata friendly" templates. In that situation what I think we need is even more information here, because even if we try to teach to the users that empty templates can also have information this is not always true, and it is never true for all the parameters (I don't think that we have any infobox with all the parameters connected to Wikidata yet).
I don't agree that we have to stop the import of data from Wikipedia, but I agree that the person importing the data should check at least that the imports they made don't add a new errors in the constraint reports, and if violations are added they should be responsible of checking and solving the problems. The thing is that we can't force them to do that. -- Agabi10 (talk) 21:04, 19 November 2015 (UTC)
  • Removing local data after import sounds nice, but isn't workable. There are wikis that currently don't use data from Wikidata for their infoboxes or other templates (nlwiki is such a wiki). I know that the Dutch community sees using data from Wikidata as a restriction on the possibilities to edit Wikipedia. Mbch331 (talk) 21:30, 19 November 2015 (UTC)
    I can understand the Dutch WP community well. Even if the Wikipedian cares to learn about WD and edits a statement there, his work is often soon destroyed by some bot or WiDaR mass action. As for now, there is no way to prevent it or to protect your work, the complaints to admins are beeing thoroughly discussed and then archieved without any action. In this situation, the Wikipedians (Wikisourcians, Wikiquotians a.s.o.) are completely right, that using data form Wikidata means losing control over them.--Shlomo (talk) 08:59, 20 November 2015 (UTC)

 Off topic: Stop changing the title, I am tired to enter in the topic to see that the only change is the title. -- Agabi10 (talk) 23:22, 19 November 2015 (UTC)

If we would add a property into an item as soon as the item is used in a wiki (<item used in wiki> <wikipedia x> ), this could tell bots and wikidata editors to be very careful with changing data. This would give wikipedia editors same control over the data they will see in the infoboxes. --Molarus 01:39, 20 November 2015 (UTC)

Remarkable to me, the intro suspects that bots are the root cause of all problems, where my experience is that bots are operated by users that have very valuable knowledge of Wikidata, but that most issues are created by (often one-time) users that have no idea what they have to do, and that what they did is causing issues. On my home wiki we have several articles every day that loose all there interwiki links, because users are renaming/moving around articles, and I've never seen this being caused by a bot. For me it's a bit obnoxious to blame bots without proving that bots are the cause of the exposed headache. Edoderoo (talk) 06:41, 20 November 2015 (UTC)
Not the bots, but irresponsible bot users. I don't think there are many of them here, the problem is, that one ore two of them can destroy or devalue the work of hundreds.--Shlomo (talk) 08:59, 20 November 2015 (UTC)
That would make it simple. Every bot has an owner, and when the owner is irresponsible, action needs to be taken. But no specific users has been named, but all the bots have been blamed. To me this sounds like bot-o-phobia that is not solving the problem. On the other hand, interwiki-links has been named as an issue, and before there was WikiData, interwiki-links was also an issue, as for some items it's not always possible to get a true 1-on-1 link with *all* the languages, especially not when one is not speaking the languages to see if it's about exactly the same item or not. Edoderoo (talk) 09:45, 20 November 2015 (UTC)
Often the owner is not responsible of bad data imports: someone comes and just ask him to perform that action and he does it in good faith. We don't say that bots are the problem but that bot work is source of problems. This is not a problem with bots this is a problem with people who extract data from WPs with bots. Snipre (talk) 11:04, 20 November 2015 (UTC)
@Edoderoo: As soon as your "action needs to be taken" changes to "action is taken", we can have a new situation here and we can start working on improving the bots' performance and afterwards trying to convince wikipedians, that cooperation makes sense. Trying it the other way round is waste of time. Specific users have been named in specific discussions to specific issues, no need to crush down this general discussion into single issues.--Shlomo (talk) 11:32, 20 November 2015 (UTC)

At one point, it will be a self-reliant system. ;)

Wikidata - Wikipedia relationship.
Wikidata - Wikipedia relationship.

Mustard of the sunshine (talk) 09:08, 20 November 2015 (UTC)

We can't ask WPs to delete data after import because not all WPs agree to use Wikidata. We have to stop to thing about a close relationship between WP and WD because it doesn't exist. WPs want to keep their freedom and be able to overwrite the data coming from WD with their chosen data. We can't expect to find solution for WD by doing any modification in WPs. WPs won't accept that. Snipre (talk) 11:04, 20 November 2015 (UTC)
  • Are there fields where people think WD is particularly unreliable? This given that most of Wikidata are P31-statements, identifiers, basic infobox data about persons, taxonomy, location and country statements? --- Jura 11:17, 20 November 2015 (UTC)
One often contentious piece of data that comes to mind are dates of births I assume. They are often unsourced or based on unreliable sources (as IMDB, external Wikis) and as a result they often get removed, modified or at some point later point properly sourced. Other infoboxes data often has outdated (sourced or unsourced) or sometimes plain false (unsourced) data, for for geographic objects data on size, length or inhabitants. With taxoboxes there are as far as i know issues with different methodologies in different wikipedias rather unreliable data as such.
And then again there is the general storage problem, meaning as long as it is as easy or even easier to intentionally or accidentally vandalize data in WD, Wikipedias will be unlikely to outsource their "live" data to WD. Even more so since local data in (local) Wikipedias gets increasingly sourced (by reliable external sources), switching to (possibly or even likely unsourced) data (as in reliable external sources not Wikipedia itself) seems like a step back for them.--Kmhkmh (talk) 13:23, 20 November 2015 (UTC)
According to my experience with persons: citizenship, ethnicity, religion, academic degree, occupation, employer.--Shlomo (talk) 14:20, 20 November 2015 (UTC)
As the Project chat is not the best to keep the discussion for a long time so I started a RfC about bot policy in order to see which is the trend in the Wikidata community. See Wikidata:Requests for comment/Improve bot policy for data import and data modification. This is not a decision only a survey of the opinion of the community. Snipre (talk) 13:46, 20 November 2015 (UTC)
Maybe we should try to define how the various elements mentioned by Kmhkmh should be addressed. The approach for supplanting a local infoboxes isn't necessarily the same as to provide infoboxes (or fields) to articles that don't have them yet. I don't think we have that much of "size, length or inhabitants" data yet. Location data consists mainly of P131 and coordinates. --- Jura 14:38, 20 November 2015 (UTC)
Snipre: What about users relying upon tools based on OAuth (Q743238)? I know some users who never reacted at theit talk page. --Succu (talk) 22:26, 20 November 2015 (UTC)

Quality and quantity

This whole point has been talked about often enough. Ask yourself, does Wikidata have sufficient statements for all the items it holds. The answer is obvious; no. With 50.13% of all items having two or fewer statements we do not have a viable set of information. Yes, it is improving rapidly but that is only because of bots are being operated. There are many reasons why statements added may be wrong, this has been extensively covered above but it is important to understand the issue. The issue is that Wikidata is incomplete and immature. That is not a problem, the problem is to wish this away.

As data is added to Wikidata, a large percentage is wrong. The quality of the imports by bot is however improving. Kian for instance calculates the likelihood if something is correct and it has humans make the decision if it is not certain. That is a clear win. Comparison of data between Wikidata and other sources including Wikipedias is how we can find data that has issues, it has been promised to us for a long time. When it finally becomes available and when it comes with a workable user interface and workflow it will drive quality in both Wikipedia, the sources and Wikidata.

What people do not appreciate is that bots typically are much better at importing data than people are. Once it has been determined that something is correct, it makes no difference if 1, 10 or 1000 statements are imported. The consequence is that as a percentage a bot makes fewer mistakes than a human. There are mistakes but the reason why is likely to be found in the underlying data not in the algorithm.

It does not help that Wikipedias insist in doing things their way and expecting Wikidata to follow. It cannot, it should not. Particularly when from a data point of view the Wikipedia way is inconsistent. When this means that Wikidata is not good enough at this point, so be it. We should have time to grow up.

At the same time, increasingly there are collections of data that are good enough. Things like links to external sources, person data like date of death. There are plenty of people who are happy to maintain those but to make it shine, we should have ways to report issues with other sources. Again this has been promised for quite some time. It is however the best way to make our work relevant and it will drive quality at both ends. This in turn will have an effect on the whole of Wikidata.

In conclusion, Wikidata bot operators add so much data that they cannot remedy every possible error. Their work is very much required because there is too little data to work with. When you compare data, no data in Wikidata means no comparison OR you add the data. When we focus on quality by determining what is likely correct and likely incorrect, we will actually achieve something. By looking at Wikidata from the perspective of set theory our work will have the biggest impact and we will achieve more in less time. Thanks, GerardM (talk) 08:19, 22 November 2015 (UTC)

While I agree with much of what is said above in particular with regards to the need of bots, nevertheless it misses 2 points of the discussion.
There is no dispute about the usefulness if and need for bots, the dispute is about the management/authorization/supervision of those bots.
From Wikipedias' perspective, they don't expect WD to do it their way, in fact in some regards they don't care at all how WD does it, but they do care about the quality of the result if it is to be used in Wikipedias.
With regard to your "so be it" in my perception there are many WDian who seem to push use case and usage scenarios (which as such is not a bad thing), but exactly for many/some of those the data quality needs to be better. Or to put it this way, "en:You can't have your cake and eat it".
--Kmhkmh (talk) 15:19, 22 November 2015 (UTC)
When people work towards particular use cases, they do it within an environment ie Wikidata. Everything is connected and when their assumptions do not jive with what others assume it will fail. I have my pet projects and typically my assumptions are fine because it fits in with what we do. When this is not the case, these people are out of luck. As long as Wikidata is this immature, we need at least 500% more statements and it has to start with "instance of" and "subclass of". The biggest hurdle is that many items have no single subject. This will have to improve dramatically. Thanks, GerardM (talk) 19:59, 22 November 2015 (UTC)

Wikidata weekly summary #185

Wikidata weekly summary #114

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

Preferred and normal rank

What is the proper use of "preferred rank" ?

Is it appropriate to use it if a property has many values for an item, to choose which ones should be included in an infobox (and which should not be shown) ?

Or, should somebody writing a query be able to assume that eg a SPARQL search using the wdt:... version of a property (and corresponding 'simple' RDF dumps) will usually include all values for that property that are 'true without qualification' ?

--

The issue has been brought into focus by attempts to make the standard place-infobox template on es-wiki draw directly the value of instance of (P31) to state the nature of the place.

However, for an item like Frankfurt (Q1794), which currently has seven different active values for P31, this leads to a pile-up of descriptions, as seen in the the infobox at es:Fráncfort_del_Meno in the section between the name and the picture.

After some discussion on es-wiki's equivalent of Village Pump, the plan was therefore developed to mark the value city (Q515) as 'preferred' on all items for which it occurs (and presumably, similar action would follow for other types of settlements etc). [pinging: @Greenny, Agabi10, Shadowxfox, Metrónomo: ]

However, it is not clear whether this is always correct. For Rennes (Q647), as User:VIGNERON has raised, there may be other values -- eg commune of France (Q484170), and/or regional capital -- that may be more significant. (Plus, also, different wikis may disagree about what is the 'most important' value to show).

The other issue about marking some values as preferred is that it makes other values disappear not just from infoboxes, but also from 'simple' RDF dumps, and from SPARQL searches using wdt:... versions of properties.

So for example, making city (Q515) the preferred value of instance of (P31) for Cardiff (Q10690) means that the value principal area of Wales (Q15979307) is no longer visible for simple searches, as in eg the search queries in column 2 and column 4 of the following template, which now sees only 21 principal areas of Wales instead of 22:

--

It is possible to work round this in SPARQL by always using the two-part expression p:P31/ps:P31 for the property instead of wdt:P31; but this will introduce an extra join every time the query is run, which may make it significantly slower (and may confuse the query optimiser, potentially making the query a lot slower, or requiring it to be hand-optimised).

Having to use this syntax also has the effect of including all deprecated statements, and statements which may be true only subject to qualifiers.

From a query-writing point of view, it would be nice if "preferred rank" could be used principally to distinguish statements that are true without having to consult qualifiers from statements that are true, but only if qualifiers are taken into account. Of course, it is possible (in principle) to then filter these out, but that is then more time and more complexity -- potentially for every property used in every query.

As an example of this, consider the located in the administrative territorial entity (P131) statements for the Scottish ceremonial county of Banffshire (Q806432), which (as marked up on the item) is partially located in Aberdeenshire (Q189912) and partially in Moray (Q211106). For people using the version of the RDF dump without qualifiers, it is useful to give the P131 as just Scotland (Q22), because this is true without qualification. Using the 'preferred rank' setting for Scotland does this -- it hides the other two values from simple searches and simple dumps, so that a simple recursive search for places in Moray does not see Banffshire as being in Moray, and then include all the places in Banffshire that are not in Moray but are actually in Aberdeenshire.

So from a search point of view, this can be a really useful effect of "preferred rank".

On the other hand, for something like Cardiff (Q10690), one would like to be able to retrieve using just a simple search that it is a principal area of Wales (Q15979307), to include it in the list of principal areas, and not have this hidden at the simple level.

--

SO: Given these two different potential objectives, what are the right circumstances to use or not to use "preferred rank" ? Help:Ranking isn't particularly clear on this point, so wider input would be useful. Jheald (talk) 23:08, 20 November 2015 (UTC)

My English is very bad, so I apologize in advance.
We have several cases to take into account for this:
In the case of Frankfurt (Q1794), the features "big city, city with over a million inhabitants, imperial city and college town" can be summarized as simply "City", that is certainly the best item that includes all these features described above.
For other cases, not all items should be removed since they reflect a different or higher territorial order in several instances. For example, a city can also be a state or a district, like Bremen (Q24879).--Shadowxfox (talk) 01:00, 21 November 2015 (UTC)
First of all, and before starting to analyze another alternatives: would it be possible to ask to the developers an alternative to wdt:... which includes all the statements that are not of "deprecated rank"? This would solve the problem of the deprecated statements showing up. Here we still have the problem of having to get the values that are true only subject to qualifiers as you described, but in this case having both options easily usable and it should be the job of the person creating the query to choose the one that fits more in their scenario. -- Agabi10 (talk) 01:22, 21 November 2015 (UTC)
Currently "preferred rank" is set by bot for some properties to define values without end-date (incumbents) or most recent data (population, if I recall correctly).
What should get preferred rank probably varies depending on the type of property. P31 is different from most other properties. --- Jura 00:44, 22 November 2015 (UTC)
No, we can't use rank to select preferred data from query in the case of P31. P31 is used in the structure of WD classification and not as other data. It is like the WP categorization meaning this is a definition chosen by WD. Snipre (talk) 08:00, 23 November 2015 (UTC)
Actually we usually refers to real world definitions, such as commune of France (Q484170)  View with Reasonator View with SQID who is indeed used by WD but defined by France. author  TomT0m / talk page 11:23, 23 November 2015 (UTC)
But this implies a cultural or linguistic definition. Suppose X defined as commune de France by WP:fr, town by WP:en, ciudad by WP:es ? Who is right ? Snipre (talk) 21:14, 23 November 2015 (UTC)
It's not cultural or linguistic. French commune are defined by french administration and state. It's true in all languages. Of course "french commune" cannot apply to a german city. Maybe WP:es do not have a special treatment for any municipalities in the world, then as it's a subclass of "municipalities in the world", it knows maybe how to find the right label. But of course Wikidata is here to reflect cultural differences, it's a NPOV project ! and NPOV is not achieved by losing informations, but by retying several aspects of the reality. author  TomT0m / talk page 21:53, 23 November 2015 (UTC)
@TomT0m: The question is not so much which statements are true (many of them may be), but how eg es-wiki can select which one(s) out of those statements to present in the sub-title section of its infobox. To step us aside from the ville/city/commune discussion, consider Glasgow (Q4093). Which of the different P31 classes that Q4093 is an instance of should be displayed at the top of a Spanish infobox? Is the answer the same for the top of a Scottish infobox? And what is the best mechanism to achieve this? Jheald (talk) 22:30, 23 November 2015 (UTC)
@Jheald, Snipre: I guess as every spanish speaking person knows about the terms used in spain and/or other spanish speaking countries, there is no real problem using the specific classes. When referfing to localities outside of their regions, it might be required to "fallback" to more generic concepts such as "commune du monde". The infobox can be the right place to present the information right. I don't think there is a generic solution we can apply here that would not imply information that would not need treatment on how to present the information, obviously Wikidata is not the place to do it. author  TomT0m / talk page 11:47, 24 November 2015 (UTC)
TomT0m Concerning your first comment you assume that only the French definition can be applied to communes of France, this is typically a cultural bias. WP:es can considered the communes of France in the same way that their municipalities in Spain. And the French administration or the WP:fr can't do anything to prevent that.
It's not a cultural bias to say that communes as defined by french administration, that is "settlements in the France territory that have eligible to have a mayor" and so on are ... french commune. This is just an objective transcription of the fact, there is just no bias at all. It occurs that other state have similar regulations and that we can regroup settlements in a broader class. It's irrelevant to invoke a principle of cultural bias in this case. We need to reflect all, not simplify everything and do not catch a lot of informations. You don't seem to acknowledge we can do both, why ? What's wrong in my proposition ? And you escalate to broad and vague principles and you don't answer to my proposition ... author  TomT0m / talk page 12:55, 24 November 2015 (UTC)
Jheald No WP:es can't select the "instance of" they want to see in their infobox by using the rank. Simply because the WP:fr will the same, WP:de too and I don't speak about WP:en. So at the end we will get several "instances of" with rank preferred and nothing will be solved.
The problem you present is the result of the accumulation of data coming from different WPs without any global view. We have to define a structure to avoid accumulation of instances of by 1) creating a classes structure and 2) by transferring some information in specific properties. A class of items is the set of items sharing some special properties so we can always create new properties to avoid class creation. For Frankfurt (Q1794), we have instance of financial centre (Q1066984). We can transform this instance of into a property like "activity":"finance". Then big city (Q1549591) can be deleted and the data can be retrieved by doing a query with two constraints instance of (P31)=independent city of Germany (Q22865) and population (P1082)>100'000. We have to create a new system of classification for cities which can be applied to all cities around the world and which is independent of the cultural systems and definitions.
So instead of commune de France we could have something like "instance of": "smallest administrative unit" and "located in":"France" and by doing the correct query we can retrieve the same items as using a class system. Snipre (talk) 12:35, 24 November 2015 (UTC)
"smallest administrative unit" => Good luck to define this. We have administrations who defines all this for them, not all their definitions are consistent from one state to another, it's far more simple just to reflect them in classes defined the same way administrations define them and to regroup similar definitions ourself. Plus there is regions defined for statistical purpose like "urban unit" that might not reflect the administative definitions. Your scheme is unapplicable and biased because it just loses a lot of informations, overall a mess because you just push the classification complexity in the specific properties that will not be usable with generic tools because they will all have their own instructions. What we need to focus on is the general scheme and make it able to be able to express local peculiarities while beeing able to express the information in less specific classes everybodu can retrieve that going up the class tree, and document those more generic concepts. author  TomT0m / talk page 12:55, 24 November 2015 (UTC)
Also, please don't forget the possibility to use metaclasses to class classes. If different culture/countries have different concepts and different definitions for the smallest kind of municipalities, they all can be tagged instance of (P31) which is also a way to reconcile Snipre's view and more specific classes modelling. author  TomT0m / talk page 13:15, 24 November 2015 (UTC)

Link class of event / body part

I'm thinking of brain damage (Q720026)  View with Reasonator View with SQID. Do we have an appropriate property to express that a brain injury occurs or damages some brain ? author  TomT0m / talk page 13:58, 21 November 2015 (UTC)

I suppose you could use the property of (P642) = brain (Q1073) as a qualifier to the statement subclass of (P279) = lesion (Q827023); but it might be useful to have something more made for the purpose. Jheald (talk) 08:40, 22 November 2015 (UTC)
Indeed, subclass of is not naturally "parameterized". We don't have any way to express that a damage, in general, of a body, applies to parts of the body usually. Hence the "of" qualifier is note really linked to anything. author  TomT0m / talk page 12:49, 22 November 2015 (UTC)
I basically agree with you.
But it is not unheard of for P279 to be "parametrised" using P642 -- indeed, this query tinyurl.com/pkue6xq for properties that P642 is most commonly used to qualify currently reports 649 cases it being used to qualify P279 -- and 8248 for it being used to qualify P31. Possibly some of these uses may also deserve investigation, and (perhaps) some more specific created properties. Jheald (talk) 13:28, 22 November 2015 (UTC)
Amended query: tinyurl.com/nt2llru, showing the values as well for these properties that are qualified by P642. Jheald (talk) 13:34, 22 November 2015 (UTC)
I have added afflicts (P689) brain (Q1073) . Not sure if that is what you meant, though. --Andreasm háblame / just talk to me 18:01, 22 November 2015 (UTC)
looking at the breakdown of values that other uses of P683 have (tinyurl.com/oqkjbmv), it looks perfect.
(This query now available as a link from the top-right of the property box on every proprty talk page. Big thanks to whoever added it to the template.) Jheald (talk) 18:38, 22 November 2015 (UTC)
Thanks Andreasmperu, that's what I was looking for. author  TomT0m / talk page 11:42, 24 November 2015 (UTC)

New Wikibase datatype - GeoShapeValue

GeoShapeValue is a long expected and as-of-yet unimplemented data type in Wikibase. Wikipedia needs geographic data attributes for it's articles, but it's being held up by this. Since it seems there's little momentum, I've proposed WKT be used. Talk:Wikibase/DataModel#Use_WKT_for_GeoShapeValue. esbranson (talk) 21:24, 22 November 2015 (UTC)

An alternative would be to link to a value stored somewhere else (maybe even in a specialist repo on Wikimedia's own servers), via a URL-valued property -- quite a semantic web approach. Jheald (talk) 23:06, 22 November 2015 (UTC)
The challenge of a GUI for calendar and quantity still needs addressing ..
Obviously, if you are merely interested in storing strings, you could try string-datatype. --- Jura 18:12, 23 November 2015 (UTC)

Property creation backlog

If one or the other administrator, property creator or other experienced editor could help us out. Several properties currently proposed at Wikidata:Property proposal/Unsorted can be created.

Experienced editors (who already proposed and reguarly used various properties) can request the necessary access at Wikidata:Requests_for_permissions/Other_rights#Property_creator after reading Wikidata:Property creators. --- Jura 11:48, 24 November 2015 (UTC)

Need help splitting item

I need help sorting out the sitelinks to Category:Literature of Greece (Q7316804) (literature from Greece) and Category:Greek literature (Q10004556) (literature writen in greek). /ℇsquilo 13:37, 24 November 2015 (UTC)

WDQ not working(?)

I'm trying to use WDQ in Autolist to find items that feature both of two claims, e.g. redundant ones. Now if I put a query of the form "claim1 AND claim2" into Autolist, it finds me no or only some of the matching items, although I know there definitely exist some it doesn't turn up.

Example: I want to find software that is redundantly stated to be under GPL and under GPL version 3. So I search with the following query: 

claim[275:7603] AND claim[275:10513445]

It returns only item Q1252773, which is an expected match. But for example Q2737776 is missing, although it should be there.

What's up? Is WDQ broken? Or Autolist? Should I file a bug report or am I missing something?--Frysch (talk) 20:55, 23 November 2015 (UTC)

Somethings wrong. I have noticed that Wikidata:Database reports/Recent deaths is not showing any deaths for the last couple of days.--Racklever (talk) 23:18, 23 November 2015 (UTC)

Could it be that problem? That one doesn't look like it's going to resolve itself like they seem to hope...--Frysch (talk) 00:46, 24 November 2015 (UTC)

As I said in about 50 other places, WDQ is currently stuck around the 17th of November. Not sure what's wrong. Debugging will take a while. --Magnus Manske (talk) 09:50, 24 November 2015 (UTC)
Fixed it quicker than anticipated. ~1 day behind now, catching up fast. --Magnus Manske (talk) 17:53, 24 November 2015 (UTC)

Confirming it seems to be fixed.--Frysch (talk) 23:13, 24 November 2015 (UTC)

Deaths at hospitals being deleted at Wikipedia

If you have an opinion one way or the other, please express it here: w:Talk:Mount Sinai Beth Israel. Here at Wikidata we list the place of death as the exact location, not just the city, but we are about to lose that information from Wikipedia before it gets migrated here. Each article on a major hospital lists the notable deaths. The majority opinion is that it is trivial at Wikipedia. --Richard Arthur Norton (1958- ) (talk) 14:54, 24 November 2015 (UTC)

Maybe we should think about a way to make place of death (P20) either state the location of the hospital (New York City) or the hospital itself. Jonathan Groß (talk) 09:02, 25 November 2015 (UTC)
To make it even more complicated: Official Swedish sources normally tells where somebody lived when somebody died, not the location of the event. -- Innocent bystander (talk) 10:25, 25 November 2015 (UTC)

Adding sources for every statement when using identifier to external database

Hi everyone! I'm in the middle of editing Joseph Bradley (Q21546271), using information from an entry in Australian Dictionary of Biography (Q672680).

I'm wondering: do I have to attach references to each of the statements I make? And do I list the source as the ADB in general, or as the specific volume of the ADB in which this person is described?

Atroceh (talk) 02:19, 25 November 2015 (UTC)

  • To start with: Are you aware of the DuplicateReferences-Gadget, that allows you to copy-paste references at least within one single item? -- Innocent bystander (talk) 07:24, 25 November 2015 (UTC)
  • Please read help:sources. Then the good practice is yes for several reasons. Some databases are closed system and no open url is available to check in the database if the identifier is correct. In that case we need the references. Typical example, the CAS registry number which is a wildly used identifier from a non-free organization. Then if you can't create an url link to the database because the url doesn't contain the identifier or the url is not stable, we need the reference. So instead to spending time to judge if the reference is necessary put it and you avoid plenty of problem for the other contributors. Snipre (talk) 08:45, 25 November 2015 (UTC)

Erasmus prize awarded today, thanks in part to you, the Wikidata community!

Hi all, as part of the activities surrounding the Erasmus prize I attended several presentations from the Dutch academic world in Amsterdam yesterday and Wikidata featured in many of them. I realize now that Wikidata has been a force of change in my life as a Wikipedian and now I realize it is a game-changer for others who study Wikipedia projects as well. From here let me extend my thanks to this community for your part in making my Wikidata experience so positive and enjoyable. I hope see some of you at the prize ceremony this afternoon. --Jane023 (talk) 11:04, 25 November 2015 (UTC)

Wikimania 2016

Only this week left for comments: Wikidata:Wikimania 2016 (Thank you for translating this message). --Tobias1984 (talk) 11:07, 25 November 2015 (UTC)

Overlapping administrative territorial entities

Hi, I've noticed a worrying pattern in Australia, but I think it's probably one that people have run into all over the world. Hopefully someone can shed some light on the problem for me.

I've noticed that Melbourne is used as the value for “located in the administrative territorial entity” for ~100 items in the region. By contract, the City of Melbourne is only used for a handful.

An “administrative territorial entity” is defined as a “territorial entity for administration purposes, with or without its own regional government”. But “Melbourne” as an entity isn't used by anyone as an administrative region: Australia is divided into states, and then into local government areas. But at the same time, Melbourne is an instance of city, which is a subclass of administrative territorial entity.

So we have overlapping entities for the same territory, even though in Australia there really isn't any sort of overlap when it comes to having responsibility for administering an area.

Has anyone dealt with this in other places? Is there a way to mark things inside the boundaries of Melbourne as located there geographically, but not administratively? --Atroceh (talk) 01:48, 17 November 2015 (UTC)

I guess “Melbourne” has man made borders, and that is enough to describe it as an "administrative territoral entity" in the Wikidata perpective. To what extent those borders fullfill an administrative purpose is of less importance.
Take administrative entities in contrast to islands which have borders created by God/Nature or however you prefer to describe it. We have other properties for those kinds of entities. -- Innocent bystander (talk) 07:48, 17 November 2015 (UTC)
I don't think Melbourne has man made borders. It's a large settlement covering multiple administrative divisions while not being an administrative division as a whole. - Nikki (talk) 09:01, 17 November 2015 (UTC)
The borders are maybe not well defined, but my opinion is that they still are man made. They are not a creation of nature. Ethnic regions like Sapmi also fails to have well defined borders, but the area is (by man) more or less defined as the area where the semi-nomadic sami-people had their home.
That an entity cover "multiple administrative divisions" is also often true for a typical "administrative entity". In Q34 the municipalities are today divided in districts. The common rule is that they are inside one municipality only, but it is not difficult to find exceptions from that rule. Boteå district in the neighbour municipality also cover one building and its surrounding area in the municipality where I live. -- Innocent bystander (talk) 10:59, 17 November 2015 (UTC)
There's location (P276) for locations in general. It seems wrong to me that city is a subclass of administrative territorial entity. The meaning of "city" varies from country to country (and even within countries) - that's why we have a number of more specific "city of (country name here)" items for the more formally defined types of cities. - Nikki (talk) 09:01, 17 November 2015 (UTC)
The word city in Swedish (stad) in itself has many different meanings. One is "populated place", and such have very vaguely defined borders, like Melbourne above. A "municipality of stad-type" (which there are several only in Sweden) definitely have administrative borders. "Urban areas" have man made borders, but they only have statistical purpose and are unknown for those who do not have access to the maps which define them. -- Innocent bystander (talk) 10:59, 17 November 2015 (UTC)

Some more data points:

As discussed at en:Glasgow and en:Greater Glasgow, the conurbation around Glasgow in some directions extends well beyond the boundaries of the council area. However for the most part, the council area does seem a useful delimitation for maybe what people think of as the boundary of the city -- compare the two iterations of c:File:Glasgowareas.jpg, with the one restricted to the council area currently being used on the en-wiki article. (Or at least its current boundary: the administrative area has shrunk compared to the earlier 20th century). So it doesn't seem unreasonable to me to equate Glasgow with its council area, since essentially this is how people have been using P131 anyway.

Belfast is currently the opposite, with two different items, even though it seems people are mostly using the 'city' item Belfast (Q10686) as the target of P131s -- and the en-wiki article en:Subdivisions of Belfast although presented as about the city seems to identify this mostly with the council area. The situation may be complicated because the council area has recently (for the elections this year) been enlarged; I haven't checked whether that en-wiki article (and articles like en:Electoral wards of Belfast) reflect the old boundary or the new. We also have Belfast metropolitan area (Q769573) / en:Belfast_Metropolitan_Area for the wider metro area.

We seem quite happy (both here and at en-wiki) to identify Manchester with the borough council area -- even though the built-up area extends continuously around it (c:File:Map_of_Manchester.png) -- perhaps because Salford and Stockport either side of it are well-defined entities, and also because Greater Manchester (Q23099) exists, as a well-defined administrative area in its own right, for the wider area. (c:File:Greater_Manchester_County_(2).png)

As regards London, the striking thing to me is that 343 returns for P131 seems quite few. Yes there are only 66 returns for Query: CLAIM[131:23306] (Greater London); but compare it with 3538 returns for one of the London boroughs CLAIM[131:(CLAIM[31:211690])]. That probably reflects that London is divided up into well-defined and well-known administrative subunits; and also that there is a distinction between London and Greater London, in that Greater London does include areas that are perceived as distinct from London itself.

Turning to smaller cities in the UK, currently we make no distinction between Cambridge (Q350) and the corresponding city council area -- the two are considered equivalent. On the other hand we do make a distinction between Carlisle (Q192896) and Carlisle (Q1094110) -- perhaps paradoxically (but very English), the first refers to the city proper; whereas the second is the name for a wider administrative area, including quite a lot of rural land well outside the built-up area.

So what to conclude? The above mostly reflects the distinctions that the totality of wikis have or have not made, which may not be that bad a first starting point for what entities do or do not deserve distinct items. For myself I think, as far as possible, that I would like to see the same item used for a city and for the territorial area corresponding to the city administration -- unless there is a clear mismatch in perception between the two extents (eg Carlisle). So, myself, I would prefer to see the territorial information moved from Belfast (Q1140130) to Belfast (Q10686); with the former perhaps being re-purposed as an item relating purely to the City Council itself, as an administrative/legislative organisation.

But I do agree with whoever suggested that city (Q515) should not by default be a subclass of administrative territorial entity (Q56061). In countries where a city by law a particular type of administrative entity, with particular powers and responsibilities, then it makes sense to have an item "City of Country X". Otherwise, as per Manchester above, to me it makes sense to have the item be a separate instance of both city (Q515) and its precise administrative class, eg metropolitan borough (Q1002812) -- and only being a subclass of administrative territorial entity (Q56061) through the latter.

Jheald (talk) 12:05, 17 November 2015 (UTC)

en:Local government areas of Victoria tells me that there are many cities in "Greater Melbourne" and "City of Melbourne" is just one of them. "Greater Melbourne" is an alias for the article "Melbourne". Therefore, I would add into "Melbourne" P150 with all the cities (City of Melbourne, City of Port Phillip, City of Stonnington, ...) and into the cities P131 "Melbourne". I guess that below a city there are suburbs of which Melbourne has ~400. If the item "City of ..." get the property P150 too, it will be possible to use this property for queries the same way as we are using P31. --Molarus 15:06, 17 November 2015 (UTC)
In my opinion very few things should be described as being <located in the administrative territorial entity (P131):Melbourne (Q3141)> because it is too big. The P131 statement should give the smaller local government area where the thing is located - the City of Melbourne for instance. In the meantime saying stuff is <located in the administrative territorial entity (P131):Melbourne (Q3141)> is not actually wrong - Melbourne (Q3141) Region appears to be an actual administrative territorial entity with legally defined borders. There are cities however which sprawl over multiple and have no defined borders or unitary authority and so those cities are not 'administrative territorial entities' - in my opinion. Joe Filceolaire (talk) 19:34, 19 November 2015 (UTC)
It's not clear to me whether statistical concepts like urban area (Q702492) or metropolitan area (Q1907114), that may well correspond to no local governmental authority, should be considered 'administrative territorial entities', but we should maybe have properties to link to them, given that there are infoboxes that want to link to them and give their respective populations (for example en:Template:Infobox UK place on en:Derry). Jheald (talk) 20:14, 19 November 2015 (UTC)

@Jheald: I'm fairly new to WikiMedia projects. How do we go about changing city (Q515) so that it's not an administrative territorial entity (Q56061)? It seems like it'd be a large change with far-reaching effects. Atroceh (talk) 02:06, 25 November 2015 (UTC)

We maybe should not describe "local governmental authorities" as territories at all. It is not a part of Earth (Q2) that has a "govermental authority", it is a group of people. That you live within an area does not necessarily make you a "part of" that entity. That a road is located in an area, does not always mean that the local goverment has any influence over that road. There live a group of immigrants not far from here, I am not sure that they are subjects to the local authorities, even if they live here and are counted in the census. The governor and the county board in Q34 is not a local authority, it is a local branch of the central goverment in Stockholm. Their authority was from the beginning limited within each county. But in last decades, each county board has specialised in some subjects. The county board of Jönköping for example is responsible for the Agricultural business in the whole nation. The county counsils here is a "local authority" but is very hard to describe as "territorial" since their authority is limited to only a few sections of the daily life. If you go to a private doctor, you do not have to deal with them at all, except for the tax you pay.
It is maybe not the "statistical" entities we should be carefull about, it is maybe rather the "administrative". Historically in Q34 also "administrative entities" lack the "transitivity" you demand from them. A Swedish municipalsamhälle, could be located in several municipalities and even several counties. The municipalsamhälle was responsible the urban planning (Q69883), something the rural municipalities didn't have to bother with. You payed tax to the parish to pay for the gravyard, the municipalsamhälle to pay for the urban planning, the municipality to pay for the social aid (schools, elder care, poverty) and to the county counsil to pay for the health care. There is then four levels of local administrative entities but they have not always been transitive. -- Innocent bystander (talk) 10:02, 25 November 2015 (UTC)
@Innocent bystander: For most administrative areas in England there are separate Wikipedia articles for the administrative territory and the administrative body -- compare en:Category:Non-metropolitan counties and en:Category:County councils of England. The Wikidata items for the administrative bodies mostly still need to be marked up with properties -- in most cases they don't even have a P31 yet. That's some work I still need to do. But something like North Yorkshire Council (Q17017103) shows a start, linking to the corresponding administrative territory via applies to jurisdiction (P1001), which in turn links back to it using legislative body (P194); with the administrative body being an instance of county council (Q4321471), which in turn is a subclass of local government (Q6501447)
Away from England, eg in Scotland, there is a tendency (inherited from Wikipedia) to conflate the administrative territory and the administrative body onto the same item -- the item for the territory. But this is no different to so many other areas on Wikidata, where a single item (like a single WP artice) quite often covers different aspects of the same thing, or closely-related things. That may even be inevitable -- there's only ever going to be a finite granularity with which we carve up all the concepts of the world into different items, there are only ever going to be a finite number of items. There is always going to be some point at which one says "these concepts are closely enough related that we are going to consider them together -- at least for now". So, for the most part, I have taken as I have found, and not created new items (eg for different (even purely territorial) aspects that an entity may have, sometimes even with different borders). There's enough work to do with the items we've already got. Besides, once we start hiving aspects of entities off into different items, that makes it quite hard, both for infoboxes to pull everything together again, and for sitelinks. So, for the most part, I have found enough other priorities needing work, without thinking about creating any systematic new sets of items. The "co-classes" links, and explicit list queries, on the various sub-pages of Wikidata:WikiProject UK and Ireland/adm show the range of multiple roles various items may be sharing -- or at least, those so far marked up on the items.
Regarding transitivity of P131: for England it almost holds, with just a couple of glitches. For Scotland things are more complicated, particularly between different types of (partly but not wholly) historical entities and the current primary divisions. Banffshire (Q806432) gives an example of what I have tried to do. The historical/ceremonial/land-registration county is split between two different top-level council areas, so I have given each of these as a P131 at normal rank with an applies to part, aspect, or form (P518) qualifier. But I have also put in located in the administrative territorial entity (P131) Scotland (Q22) at preferred rank, because that is as much as can be reliably said (transitively) for people/scripts/bots eg using the wdt:P131 form of the P131 property, working without qualifiers. Jheald (talk) 12:30, 25 November 2015 (UTC)
@Jheald: Well, I have this far added both P131:Municipality and P131:Province since there is no or very poor transitivity between Municipalities and Provinces. Hästhagen (Q3352829) is a good example. Nacka Municipality and Södermanland (province) is what it can be described as being located in today. Nacka city was dissolved as an entity 1970 and it therefor have a "normal rank" and an end date. Setting P131:Södermanland to a "normal rank" would imply that it like Nacka City is a dissolved entity, but it isn't. Provinces have (since 17th century) lost their administrative function. What remains of them are the ethnic identities, languages and the lines on the map. There are of course smaller entities than municipalities, like parishes, civil parishes and districts. There is no guarantees about transitivity between such entities and municipalities either. But larger urban areas are often larger than such entities. (A handfull of urban areas are larger than municipalities, but they are the exceptions.) If I would like to know the language and ethnicity of somebody, then I would prefer to know the Province. But if I would like to know what political landscape (s)he lives in and what tax (s)he pays, I would like to know which Municipality. If I want to know the religious background, I would like to know the parish. And if I would like to know how the cultural heritage is treated in hir surroundings, I would like to know which County (s)he lives in. It is complex, and I think I would like that we forget the whole transitivity-thing with P131, because it so very seldom looks that simple in the items I edit. -- Innocent bystander (talk) 15:03, 25 November 2015 (UTC)
@Innocent bystander: What I've started trying to do in cases like that is to add the qualifier P794 (P794) to the P131 statement -- eg on Renfrew (Q7313155), where I've given the present-day administrative area unqualified as the preferred value, but also the historic administative area at the time this district existed as a normal-rank value, qualified with P794 (P794) = local government area of Scotland 1975 to 1996 (Q383493), so that in time (with more work) somebody should be able to check for that qualifier and pull out the whole administrative hierarchy as it was at that time. I'm not sure whether this is considered an approved use of P794, but it seemed the best choice available.
PS: Is "hir" the possessive of hen (Q10521894) ? I only met the latter for the first time this week, in the first episode of the new series of The Bridge (Q1211796), when Saga Norén was queried on her use of it by her Danish colleague. Now impatient for Saturday and episodes 3 & 4. :-) Jheald (talk) 15:31, 25 November 2015 (UTC)
But I do think transitivity is important to try to preserve as far as we can with P131, because the P131 tree is really the only way for users to be able to localise places and events within a part of the country as whole -- whether a province, a region, a municipality or whatever. Since each of those may include multi-level subdivisions, it's important to at least try to make such searches possible, without too many items leaking in from adjacent provinces/regions/municipalities etc if subdivisions in one system cross the borders of subdivisions in a different system.
In the Scottish context, I also thought it was important to try to record how alternative and historic divisions relate to the present primary set of Scottish council area (Q15060255) divisions. Jheald (talk) 15:47, 25 November 2015 (UTC)
One question: Is a Province in a County or is a County in a Province? Wikipedia tells me both! Sometimes the first is smaller, sometimes the latter is smaller. In two cases (today), there is an exact match. -- Innocent bystander (talk) 16:17, 25 November 2015 (UTC)
@Jheald: Using P794 for P131 probably works when the item has multipurpose (both an urban area and a municipality or both an island and a province). But when there is no doubt that "Rohan" is a "kingdom of Middle Earth", I cannot see such need. That Rohan is a kingdom in Middle Earth is already stated in the item about Rohan. Your approach would probably work with the two Swedish provinces that the articles also describe as (islands|group of islands). -- Innocent bystander (talk) 09:59, 26 November 2015 (UTC)
@Innocent bystander: Looking at the infobox on en:Södermanland, it does note the counties that parts of this province are contained in -- en:Södermanland County, en:Stockholm County, en:Västmanland County, en:Östergötland County.
So there's a case that one could make Södermanland (Q626062) P131 Sweden (Q34) (or Svealand (Q203835) ?) at preferred rank, and then P131 Södermanland County (Q106915), Stockholm County (Q104231) etc at normal rank, with the qualifier applies to part, aspect, or form (P518) = "some value". Then an infobox could automatically pick this up if it wanted to.
You're right, that maybe it is superfluous to also add the qualifier P794 (P794) = county of Sweden (Q200547), when "Stockholm county" by definition is a county of Sweden, so it is already implicit. But all the same, if various different P131 relationships are being stated for an item, I think it can be helpful (at least for human readers) to indicate the nature of those relationships on the item itself, rather than forcing the reader to click through to see what kind of P131 relationship each statement is giving. But there are also people who really do not like such redundancy, so I accept that there are arguments both ways. Jheald (talk) 10:24, 26 November 2015 (UTC)
You can make the Modules clicking around themself. In here you see an example of a template I have done some experiments with. That the template is "pink" does not depend on any statement in the item about Canis lupus, it rather comes from the item about Animalia several clicks up the hierarchy of taxnomic rank. The module which draw this template uses information from 49 different item. -- Innocent bystander (talk) 10:41, 26 November 2015 (UTC)
@Atroceh: The actual edit is very simple -- just go to city (Q515), hit "edit" on the statement in question, then hit "remove".
But I suspect you're asking about a bit more than just the simple mechanics...
There are currently just over 16,000 items that are cities but not subclasses of administrative territorial entity (Q56061) in any other way: tinyurl.com/ovgymz9
Here is a breakdown by country: tinyurl.com/qzuxaar
The first issue is to determine in which of these countries "city" status does in itself imply a municipal / administrative organisation.
A second issue is to think how that should be indicated -- eg does it make sense to mark items as instance of (P31) both a city (Q515) and a municipality (Q15284) in territories where the former implies the latter? Alternatively, should one introduce a second "city" item, a subclass of Q515, for cities that also have municipal administrative authority? (But then could we trust users to consistently choose the right "city" item from a drop-down menu?)
Is the distinction between "city with administrative powers" and "city without administrative powers" in fact worth making, all for the sake of perhaps only a handful of cities (for example Inverness (Q160493)) that are not administrative units ?
The key question is how and where to get the attention of the people most interested in administrative areas, and the located in the administrative territorial entity (P131) hierarchy, to get a sense of their perspectives on the above two issues, and so how as a community as a whole we think we should go forward.
There is Wikidata talk:WikiProject Country subdivision, which may be a good place to start a discussion thread. However, I am not sure how active that WikiProject is. But perhaps it is a place to start a thread, and then perhaps advertise that thread with a new section on this page, and the sister pages of this page in other languages -- eg the Bistro page in French, the Forum page in German, etc -- to get the attention of more of the community, to discuss how to go forward. Jheald (talk) 09:26, 25 November 2015 (UTC)

Q18900373 empty

I've noticed that the English Salt Administration Regulations (Q18900373) is completely empty, besides a Wikisource link to another language. Can someone who knows the language translate it to English?  – The preceding unsigned comment was added by SadisticSouls (talk • contribs).

The language is Chinese (zh). Jonathan Groß (talk) 09:06, 25 November 2015 (UTC)
I could suggest the description "page to read once I have learned zh" --- Jura 13:32, 25 November 2015 (UTC)
Google translate has no problems with this and the translation made enough sense for me to add an English label and a 'subclass off' statement. Joe Filceolaire (talk) 12:16, 26 November 2015 (UTC)
Actually, it's a topical page in wikisource (not a source text). So yes, translation is needed. --- Jura 12:20, 26 November 2015 (UTC)
This reminds me that zhwikisource ranks 2nd on the (incomplete) Database reports/without claims by site. --- Jura 12:29, 26 November 2015 (UTC)

Your input requested on the proposed #FreeBassel banner campaign

This is a message regarding the proposed 2015 Free Bassel banner. Translations are available.

Hi everyone,

This is to inform all Wikimedia contributors that a straw poll seeking your involvement has just been started on Meta-Wiki.

As some of your might be aware, a small group of Wikimedia volunteers have proposed a banner campaign informing Wikipedia readers about the urgent situation of our fellow Wikipedian, open source software developer and Creative Commons activist, Bassel Khartabil. An exemplary banner and an explanatory page have now been prepared, and translated into about half a dozen languages by volunteer translators.

We are seeking your involvement to decide if the global Wikimedia community approves starting a banner campaign asking Wikipedia readers to call on the Syrian government to release Bassel from prison. We understand that a campaign like this would be unprecedented in Wikipedia's history, which is why we're seeking the widest possible consensus among the community.

Given Bassel's urgent situation and the resulting tight schedule, we ask everyone to get involved with the poll and the discussion to the widest possible extent, and to promote it among your communities as soon as possible.

(Apologies for writing in English; please kindly translate this message into your own language.)

Thank you for your participation!

Posted by the MediaWiki message delivery 21:47, 25 November 2015 (UTC) • Translate • Get help

Items with administrative unit set to a disambiguation page

Over 1200 items have located in the administrative territorial entity (P131) set to an item with instance of (P31) set to Wikimedia disambiguation page (Q4167410). Some of them (maybe a few tens) are my mistake and I'm trying to find and fix them, but we should find a way to fix all them.--Pere prlpz (talk) 14:15, 25 November 2015 (UTC)

I guess what you're asking for is could we make a "dab solver", that suggests items of the right class with a similar label, to replace property values that are disambiguation pages.
Interesting challenge.
I think, even if a list were created, one would still wish for manual supervision of the proposed changes, or at least manual checking + quick statements, rather than full automation. Jheald (talk) 15:05, 25 November 2015 (UTC)
Some of those items already have a right value of located in the administrative territorial entity (P131) beside the wrong one. Just removing the wrong ones while leaving the right ones that are already there would be a good improvement - my first thought was to use Autolist2 "en masse" to remove P131 from those items, but as far as I know that would delete right values, too.
Having a dab solver to fix all links to disambiguation pages in Wikidata would be even more useful. I found 1200 wrong links because I just checked P131, but there are likely a lot of other properties set to disambiguation pages.--Pere prlpz (talk) 15:59, 25 November 2015 (UTC)
Yeah, "remove statements" in Autolist2 was my first thought too, when you were talking about right statements alongside wrong ones -- but in this case the Autolist search is only giving you part of the wrong statement, not the whole wrong statement to remove. Given some scripting and the SPARQL search, it would be easy enough to construct a list of superfluous apparently wrong statements to remove -- but I'm not sure whether Magnus provides a "Quick statement removal" tool to accompany his "Quick statements" tool. If he did, that might be a way to go; but I'm not sure if he does. Jheald (talk) 16:23, 25 November 2015 (UTC)
This should appear in the "value type"-violation section of Wikidata:Database_reports/Constraint_violations/P131, but it's buried within 14000 total (for 2.4 million items). --- Jura 16:29, 25 November 2015 (UTC)
I am fixing these frequently, as they are also appearing at first report of Wikidata:Database reports/Constraint violations/P625‎. Mostly they are products of bad mergers and sometime they are not easy to fix, mainly if bad merger is older and bots already start to import "non-disam" properties to disam item or disam labels to non-disam item. --Jklamo (talk) 18:24, 25 November 2015 (UTC)
  • @Pere prlpz, Jura1, Jklamo: Here's a query to try and get a sense of what might or might not be possible: tinyurl.com/pj5chte
In the first pair of columns is the item; in the last (fourth) pair of columns is the current value of its P131 (a disambiguation item).
In the third pair of columns is any item with a matching English-language label, that is considered an administrative territory, and therefore might be a possible dab-solution.
In the second pair of columns is any value that the item already has for P131 that is considered an administrative territory.
The sample is slightly limited, in that I have restricted to cases where both the item and the disambiguation item have English labels; and also to items that where there is an administrative territory with a exactly matching English-language label. (So I'm ignoring near but non-exact matches, and matches in other languages; and probably almost all of User:Jklamo's bad merges.) This cuts things right down, to results for only about 100 items.
Each item can have several rows, however, if the search finds multiple possible matches for the dab; and/or multiple existing P131s that are adms. The two multiply, so if there are 2 valid P131s and three proposed dab matches, that will give six rows.
Despite being very much cut down from Pere prlpz's initial 1200 items with problems (and despite almost certainly missing many of the actual dab solutions), I think at least a couple of things are evident:
(i) there can very often be several candidate solutions for a particular dab.
(ii) in most cases, the value needing to be disambiguated is on a different administrative level than the value that is 'good' -- so it is probably not a good idea to just delete such dab-item values blindly, as that would lose information; rather, it is worth trying to solve them -- even if that is probably substantially going to need to be done by hand. Jheald (talk) 21:53, 25 November 2015 (UTC)
Having looked at the results of this a bit more, I find that the correct dab solution is very likely not to be on the list in the above query (often because it may include a suffix) -- and even for those that are on the list, the list presentation is not the most helpful, because you still have to click through to see the description.
So, unfortunately, the best approach seems still to be to open up the item in one of the larger Wikipedias, also open up the dab page, and try to spot the right dab-solution from the Wiki page.
A better tool might present the Q-numbers for all of the dabs from all of the wikipages, together with their descriptions (falling back to the Wiki page if the description on Wikidata was blank). But a pop-up tool like that is well beyond my capabilities. Jheald (talk) 22:37, 25 November 2015 (UTC)
I've checked some items while fixing those caused by me and from what I saw:
  • Most mistakes seem to come in groups (same wrong redirection need to be changed by the same administrative unit). Those could be fixed in groups using Autolist - I did for the biggest ones.
  • There are very few items with a right and a wrong administrative unit, and most of them were my mistake and are now fixed. Most of the remaining items just have the wrong value. Then, if nobody wanted to hand fix by hand all those items, I would delete located in the administrative territorial entity (P131) using autolist. Anyway, I think items are more likely to get the right administrative unit if they don't have any than if they have a wrong one.
  • If there was a tool to delete just the located in the administrative territorial entity (P131) set to a desambiguation page while leaving in place all other values, it would be the best way to delete the wrong statements. Can this be done with SQL?--Pere prlpz (talk) 23:29, 26 November 2015 (UTC)

There should be "suggest feature" while inputting statement's value

For example, when I input sex or gender, the value is usually male or female. It would be convenient if the system suggests these values automatically, so that I don't need to type the whole word "male" or "female" to select these values. The system can count the most popular values for each statement, and suggest these popular values when someone input a statement. --Yourwoood (talk) 06:44, 27 November 2015 (UTC)


Fusion problems

Can someone fusion de:Kategorie:Richter (Portugal) with en:Category:Portuguese judges ? MariaTheresaSanSebastiana (talk) 21:15, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Türkei) with en:Category:Turkish judges (Q8876344) ? MariaTheresaSanSebastiana (talk) 21:18, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Ghana) with en:Category:Ghanain judges ? MariaTheresaSanSebastiana (talk) 21:20, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Bolivien) with en:Category:Bolivian judges (Q8304451) ? MariaTheresaSanSebastiana (talk) 21:22, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Uganda) with en:Category:Ugandan judges (Q8854684) ? MariaTheresaSanSebastiana (talk) 21:24, 2 December 2015 (UTC)

→ ← Merged. With the gadget merge you can also do it by yourself. --Pasleim (talk) 21:26, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Neuseeland) with en:Category:New Zealand judges (Q7001281) ? MariaTheresaSanSebastiana (talk) 21:27, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Kenia) with en:Category:Kenyan judges (Q8572696) ? MariaTheresaSanSebastiana (talk) 21:30, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Kanada) with en:Category:Canadian judges (Q8339799) ? MariaTheresaSanSebastiana (talk) 21:33, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Belgien) with en:Category:Belgian judges ? MariaTheresaSanSebastiana (talk) 21:36, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Richter (Ägypten) with en:Category:Egyptian judges (Q7090626) ? MariaTheresaSanSebastiana (talk) 21:38, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Notar (Frankreich) with en:Category:French notaries (Q8474051) ? MariaTheresaSanSebastiana (talk) 21:40, 2 December 2015 (UTC)

→ ← Merged. You can do this yourself. Just link the English categories to the German categories on the German category page using the pencil in the left column. Mbch331 (talk) 21:46, 2 December 2015 (UTC)
i tried, but i think i'm too stupid for that or there is an other problem. MariaTheresaSanSebastiana (talk) 21:49, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Notar (Spanien) with en:Category:Spanish notaries (Q8787741) ? MariaTheresaSanSebastiana (talk) 21:42, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Notar (Kanada) with en:Category:Canadian notaries (Q9230718) ? MariaTheresaSanSebastiana (talk) 21:44, 2 December 2015 (UTC)

Can someone fusion de:Kategorie:Rechtsanwalt (Georgien) with en:Category:Lawyers from Georgia (country) (Q9503187) ? MariaTheresaSanSebastiana (talk) 21:49, 2 December 2015 (UTC)

→ ← Merged Del♉sion23 (talk) 22:21, 2 December 2015 (UTC)

Fusion problems

Can someone fusion en:Category:Turkish police officers (Q7016378) with de:Kategorie:Polizist (Türkei) ? 188.96.177.113 23:03, 2 December 2015 (UTC)

Can someone fusion en:Category:Uruguayan police officers (Q6300301) with de:Kategorie:Polizist (Uruguay) ? 188.96.177.113 23:07, 2 December 2015 (UTC)

→ ← Merged --BurritoBazooka (talk) 23:48, 2 December 2015 (UTC)

Can someone fusion en:Category:Civil service by country (Q6987680) with de:Kategorie:Beamter nach Staat ? Lisoratis (talk) 00:09, 3 December 2015 (UTC)

Can someone fusion en:Category:Canadian civil servants (Q8338917) with de:Kategorie:Beamter (Kanada) ? Lisoratis (talk) 00:13, 3 December 2015 (UTC)

→ ← Merged ---- LaddΩ chat ;) 15:47, 3 December 2015 (UTC)

Fusion problems

Can someone fusion de:Kategorie:Finanzminister (Portugal) (Q7847599) with en:Category:Finance ministers of Portugal ? 88.70.210.234 02:24, 3 December 2015 (UTC)

✓ Done at Category:Finance ministers of Portugal (Q7847599) ---- LaddΩ chat ;) 15:43, 3 December 2015 (UTC)

Fusion problems

Can someone merge en:Category:Spanish sculptors (Q7069056) with de:Kategorie:Bildhauer (Spanien) ?

Can someone merge en:Category:Slovak sculptors (Q8753002) with de:Kategorie:Bildhauer (Slowakei) ?

Can someone merge en:Category:Norwegian sculptors (Q7486041) with de:Kategorie:Bildhauer (Norwegen) ?

Can someone merge en:Category:Canadian sculptors (Q8340640) with de:Kategorie:Bildhauer (Kanada) ?

Can someone merge en:Category:Chinese sculptors (Q7486082) with de:Kategorie:Bildhauer (China) ?

Can someone merge en:Category:Brazilian sculptors (Q6523524) with de:Kategorie:Bildhauer (Brasilien) ?

Can someone merge en:Category:Armenian sculptors (Q8264164) with de:Kategorie:Bildhauer (Armenien) ?

Can someone merge en:Category:French sculptors (Q7031318) with de:Kategorie:Bildhauer (Frankreich) ?

Can someone merge en:Category:Peruvian sculptors (Q8759470) with de:Kategorie:Bildhauer (Peru) ?

Can someone merge en:Category:Italian sculptors (Q7024575) with de:Kategorie:Bildhauer (Italien) ?

Can someone merge en:Category:Uruguayan sculptors (Q9256794) with de:Kategorie:Bildhauer (Uruguay) ?

Can someone merge en:Category:Czech sculptors (Q7486111) with de:Kategorie:Bildhauer (Tschechien) ? 88.70.210.234 15:46, 3 December 2015 (UTC)

Can someone merge en:Category:Spanish photographers (Q6446024) with de:Kategorie:Fotograf (Spanien) ?

92.76.123.166 16:43, 3 December 2015 (UTC)

Can someone merge en:Category:German printmakers (Q8490644) with de:Kategorie:Grafiker (Deutschland) ? 92.76.123.166 16:47, 3 December 2015 (UTC)

Can someone merge en:Category:Printmakers by nationality with de:Kategorie:Grafiker nach Staat ?

Many German categories for printmakers by nationality state are not interwikilinked. If i try to do it, i get always an error in Wikidata. 92.76.123.166 16:52, 3 December 2015 (UTC)

Can someone merge en:Category:Spanish printmakers (Q6409405) with de:Kategorie:Grafiker (Spanien) ? 92.76.123.166 16:54, 3 December 2015 (UTC)

Can someone merge en:Category:Italian printmakers (Q8558969) with de:Kategorie:Grafiker (Italien) ? 92.76.123.166 16:57, 3 December 2015 (UTC)

Can someone merge en:Category:British printmakers (Q7708720) with de:Kategorie:Grafiker (Vereinigtes Königreich) ? LirobellaGrat (talk) 17:06, 3 December 2015 (UTC)

Can someone merge en:Category:French printmakers (Q8474320) with de:Kategorie:Grafiker (Frankreich) ? LirobellaGrat (talk) 17:08, 3 December 2015 (UTC)

Can someone merge en:Category:Czech printmakers (Q8441193) with de:Kategorie:Grafiker (Tschechien) ? LirobellaGrat (talk) 17:10, 3 December 2015 (UTC)

Can someone merge en:Category:Russian printmakers (Q7708790) with de:Kategorie:Grafiker (Russland) ? LirobellaGrat (talk) 17:12, 3 December 2015 (UTC)

Can someone merge en:Category:Polish printmakers (Q7132479) with de:Kategorie:Grafiker (Polen) ? LirobellaGrat (talk) 17:17, 3 December 2015 (UTC)

You can either use Edit links on the wiki on the page you want to have linked, or go here on Wikidata to Special:MergeItems, or read something at Help:Merge. Matěj Suchánek (talk) 17:17, 3 December 2015 (UTC)

Can someone merge en:Category:Romanian printmakers (Q7708796) with de:Kategorie:Grafiker (Rumänien) ? LirobellaGrat (talk) 17:20, 3 December 2015 (UTC)

Can someone merge en:Category:German painters (Q3920052) with de:Kategorie:Maler (Deutschland) ? LirobellaGrat (talk) 17:27, 3 December 2015 (UTC)

Can someone merge en:Category:Turkish painters (Q8876459) with de:Kategorie:Maler (Türkei) ? LirobellaGrat (talk) 17:29, 3 December 2015 (UTC)

→ ← Merged all of them using a cool external tool. Matěj Suchánek (talk) 18:02, 3 December 2015 (UTC)

Still missing two merge problems now: Can someone merge en:Category:Italian sculptors (Q7024575) with de:Kategorie:Bildhauer (Italien) ?

Can someone merge en:Category:Czech sculptors (Q7486111) with de:Kategorie:Bildhauer (Tschechien) ? 178.11.190.24 18:39, 3 December 2015 (UTC)

✓ Done the first one, the second requires merging de:Kategorie:Italienischer Bildhauer to de:Kategorie:Bildhauer (Tschechien) on dewiki. Matěj Suchánek (talk) 19:17, 3 December 2015 (UTC)

Cycle detector

Hey folks,

yesterday afternoon I wrote a little cycle finder prototype making use of the Wikidata query end point. You can find it at https://tools.wmflabs.org/hoo/Wikidata-cycle-finder.php. I have already been able to identify several flaws in our data with it and I'm sure there's more. Cheers, Hoo man (talk) 11:44, 27 November 2015 (UTC)

Great tool. Maybe it's an idea that when there are no results to display the text "no results" or something. Mbch331 (talk) 12:39, 27 November 2015 (UTC)
See also : http://sergestratan.bitbucket.org/?draw=true&optid=s0&item=5 who has also a cycle detector. author  TomT0m / talk page 12:42, 27 November 2015 (UTC)
I've just poked at it some more and it should be way faster now. Also it shows you when it couldn't find anything (like @Mbch331: requested). - Hoo man (talk) 20:14, 27 November 2015 (UTC)

first performance vs publication date

When should I use date of first performance (P1191) and when publication date (P577)? Because most of the times I see the first day a film or episode is aired with publication date (P577) but in Space Pilot 3000 (Q185831) for that date of first performance (P1191) is used instead. At least in the example of the first and the description of the second it seems that both can be used -- Agabi10 (talk) 20:42, 27 November 2015 (UTC)

I've been using publication date (P577) for books and date of first performance (P1191) for plays and television programmes/series based on my reading of the description. Thryduulf (talk: local | en.wp | en.wikt) 23:52, 27 November 2015 (UTC)

Import factual data on Wikipedia to Wikidata

For example, the wikipedia page on hydrogen (chemical element) has so much factual information (statements) about hydrogen, unlike the wikidata entry with little information. Is it possible to load a wikipedia article in wikidata and then translate the information on the sidebar into wikidata statements? If such doesn't exist, wouldn't it be a good idea?

Much of this info has been imported from various reliable sources and there are projects to create the properties to enable this info to be imported (now that we have numbers with units) from those sources into wikidata, with references. Importing from the original sources is better than importing from wikipedia because we get the references as well as the latest data. Once that happens then we will be able to add chemical infoboxes to every language wikipedia. Ho[e this helps. 82.23.125.177 11:37, 28 November 2015 (UTC)
Anyway, there is a lot of work in progress to copy information from Wikipedias to Wikidata. Eventually, some of that information may be replaced with well referenced information copied from any reliable source, but meanwhile Wikidata is a great tool for using in one wikipedia information from other wikipedias. For example, a few years ago we used to copy coordinates between wikipedias with bot, but now it's a lot easier just to use the coordinates that we upload from wikipedias to Wikidata.--Pere prlpz (talk) 13:13, 28 November 2015 (UTC)

Order of statements

Newbie here. Could someone explain to me what determines the order in which statements appear in Wikidata? Is it simply a function of when each statement was added to Wikidata?

For example, in IBM (Q37156), within the subsection "industry", the page lists "software industry", "hardware industry", "IT service management" and "information technology consulting". If (just for argument's sake) I wanted the page to list "hardware industry" first, so it comes before "software industry", how would I go about that? Jayen466 (talk) 08:09, 28 November 2015 (UTC)

Currently it is the order in which they've been added. There are plans on creating a specific order, but I don't know what the status is of those plans. Mbch331 (talk) 09:30, 28 November 2015 (UTC)
Thanks, Mbch331. Jayen466 (talk) 09:49, 28 November 2015 (UTC)
Not very simple in this specific case, but Lua contains some functions that allows you to sort claims. Our Module:Wikidata here at Wikidata allows us to sort by such things as the "startdate" or "as of"-qualifiers for example. -- Innocent bystander (talk) 10:40, 28 November 2015 (UTC)

sister city

Yesterday I added twinned administrative body (P190) as a "Conflicts with"-constraints to Swedish urban area code (P775). The database report today gave me 87 detected conflicts. The first row (Lund) had three such statements, which I could move and reference to another item.

I am not aware of any property so poorly referenced as this one. In some cases it is sourced with "imported from Wikipedia" and even those cases are too often wrong. I will spend the next weeks sorting these 87 conflicts out, fully aware of that I will in many cases fail to confirm such relations. Are there any other ways to detect errors with this property? -- Innocent bystander (talk) 08:38, 28 November 2015 (UTC)

Query people of certain age

How do I query with WDQ people born between 1984 and 1986?--Kopiersperre (talk) 20:23, 25 November 2015 (UTC)

@Kopiersperre: Query: BETWEEN[569,1984,1986-12-31] Jheald (talk) 22:01, 25 November 2015 (UTC)
@Jheald: Thanks.--Kopiersperre (talk) 22:52, 25 November 2015 (UTC)
@Jheald: - interested by that last bit. Does WDQ need to specify "up to 31 December" for a range rather than just using a year? (Wondering if I've been using it wrong...) Andrew Gray (talk) 22:38, 28 November 2015 (UTC)
Query: BETWEEN[569,1984,1986] will become Query: BETWEEN[569,1984-00-00,1986-00-00], i.e. it excludes all people born in 1986. --Pasleim (talk) 22:47, 28 November 2015 (UTC)

Merged "Antarctic"

I have reviewed the Antarctic continent, and should merge these pages User:CEM-air/MERGED-ANTARTIDA. But there are many to do it by hand. Anyone can do "fast"? I have separated into two formats or styles:

* Q21474599 (ceb:Wilds Nunatak) and Q8001495 (en:Wilds Nunatak)
* Q8001495 Q21474599

because I do not know the correct data format. --CEM-air (talk) 22:26, 27 November 2015 (UTC)

@CEM-air: Magnus's "Quick Statements" tool can be used to do a list of merges -- see https://tools.wmflabs.org/wikidata-todo/quick_statements.php for the format required. Jheald (talk) 22:58, 27 November 2015 (UTC)
Merged using the merge tool (you can select it in the 'User preferences' and it gets added to every page). Joe Filceolaire (talk) 22:25, 28 November 2015 (UTC)
I'll do these with QuickStatements just now, if they've not been done already. Andrew Gray (talk) 22:32, 28 November 2015 (UTC)
All done. Andrew Gray (talk) 23:32, 28 November 2015 (UTC)
Thanks... I was late with the sentences "MERGED Q21476831 Q2996102" --CEM-air (talk) 23:40, 28 November 2015 (UTC)

How to generate a table listing the stages of a cycling race in Wikipedia ?

Hi everybody. As you know I work on cycling races, on the terrain and here. This year, like in 2013 and 2014, I illustrate the Quatre jours de Dunkerque 2015. Doing photos is interesting, but it is more interesting to be able to produce articles in most langages (because cyclists come from all Europe), and it is my goal for 2017. Since may, five infoboxes have been developed (only for cycling) and three modules for links to databases. See Grand Prix de Fourmies 2015 for a cycling race and 18e étape du Tour d'Espagne 2015 for a stage. I benefit on new properties last week (ProCyclingStats race ID (P2327), ProCyclingStats team ID (P2328), Cycling Archives race ID (archived) (P2330) and Cycling Archives team ID (archived) (P2331)) that offer me new possibilities.

So I come with another question today. When we work on a stage race, we generate a table. For an adaptation to Wikidata, I have theses properties :

For formatting (for example stages and profiles), I can create a dictionary. We have this system for the different types of teams. For the flag of the cyclist, we take this information in his item. It is already the case when we write results in an infobox. The formatting of the table is stocked in Modèle:En-tête de tableau Liste des étapes.

I have an example yesterday, the 2016 Four Days of Dunkirk (Q19859305). I list its stage thanks to has part(s) (P527), and each stage has an item that contained informations. Is somebody able to write for me a module that permits to make a table entirely generated by Wikidata ? I am not able to do this, but I can translate terms in French, I can create a dictionary (for exemple, series ordinal (P1545) ↔ 1 will give in French 1re étape), I can test it on articles, and I can write a documentation easily understanding by lambda contributors. My wish is to share a common module on around twenty Wikipedia, like ProCyclingStats, to boost smaller Wikipedias.

I have another project to display a race result on Wikipedia, but it will be for after. Jérémy-Günther-Heinz Jähnick (talk) 09:22, 28 November 2015 (UTC)

The point is that you want to share a module on many Wikipedias, because each Wikipedia has a different Module:Wikidata. In fr:WP you have fr:Module:Infobox, written by user Zolo, which is the wikidata module that you would need in many Wikipedias, but it isn´t this way. Therefore you have to write a small wikidata module from scratch.
I have written Module:Cycling race, a short demo modul. On the discussion page Module talk:Cycling race you could see the Modul working on Q19859305 (2016 Four Days of Dunkirk). For this to work, I have added at the bottom of the item Q19859305 the diskussion page as the linked article.
In the code you see at the top some strange lines. You will find at the API-Sandbox hier how it looks for the whole item. You will see from this how the lines in the code are build. What is missing, is the code for the time string to look better. Maybe the templates in the Wikipedias could be used for this?
In this way it would be possible to build an infobox the way you want and share the module with different wikipedias. But I don´t know how to code that the infobox translates by itself. The easiest solution would be, that this is done by hand. --Molarus 01:48, 29 November 2015 (UTC)

Added to Q#####

I wish to add several times a link an article (in euwiki without Q####) to another article (eo euwiki that know his Q####) My list is in User:CEM-air/EU-ASTEROIDES.

What tool can I use?

I've only read about merging two Q####. --CEM-air (talk) 23:38, 28 November 2015 (UTC)

Sorry me ... someone already did this weekend. --CEM-air (talk) 23:45, 28 November 2015 (UTC)
CEM-air for the future this kind of tasks are easy to do with Quick Statements, at least if you can format the list in the format required by the tool. -- Agabi10 (talk) 00:02, 29 November 2015 (UTC)

Offline Dictionary for different languages

Why there is no Offline dictionary are available of different languages? After searching there is no Offline positive result.  – The preceding unsigned comment was added by 122.184.129.58 (talk • contribs). 25 November 2015 (UTC)

Official theater release

How do I set the official release in theaters in a country for films? --Jobu0101 (talk) 19:53, 28 November 2015 (UTC)

Is this correct? How do I distinguish between the official release in theaters and a festival? --Jobu0101 (talk) 20:07, 28 November 2015 (UTC)
Use publication date (P577) but use date of first performance (P1191) as well for festival with location (P276) as qualifier, and use date of official opening (P1619) for official release in theatres if the dates for these are different from the the publication or if they give extra info. Joe Filceolaire (talk) 22:18, 28 November 2015 (UTC)
Thank you very much. But why not always use date of official opening (P1619)? --Jobu0101 (talk) 22:44, 28 November 2015 (UTC)
Thinking about it date of official opening (P1619) is probably better for TV shows, films and plays. Keep publication date (P577) for books and CDs and DVDs. Joe Filceolaire (talk) 18:35, 29 November 2015 (UTC)
date of official opening (P1619) is for buildings. In English it reads date of official opening, which looks strange to me for movies, TV shows and plays. If you would have said date of first performance (P1191) it would have been more logic. Mbch331 (talk) 18:42, 29 November 2015 (UTC)

What about place of publication (P291)? That's what I read at the publication date (P577) discussion page. --Jobu0101 (talk) 22:50, 28 November 2015 (UTC)

place of publication (P291) is about places not about dates. Mbch331 (talk) 18:42, 29 November 2015 (UTC)
Emmm... Joe Filceolaire at least as I understand date of official opening (P1619) is intended to be used for inaugurations, no for the first time something is aired... -- Agabi10 (talk) 18:43, 29 November 2015 (UTC)

@Mbch331: The documentation of publication date (P577) tells to use place of publication (P291) as quantifier (and not location (P276) or country (P17)). --Jobu0101 (talk) 23:20, 29 November 2015 (UTC)

The discussion however isn't about which property to use for the place, but the property to use for the date. Mbch331 (talk) 07:33, 30 November 2015 (UTC)
Both. I wanted to know how I set the official release in theaters in a specific country for a film. So I also need to know where to put the country. --Jobu0101 (talk) 08:48, 30 November 2015 (UTC)

Arabic monolingual text

Hello, I filled the property title (P1476) to Dabiq (Q18324560) with "دابق‎". The texte that is displayed is "( (arabe دابق‎" (in French). Is this display issue already known? Pamputt (talk) 20:23, 29 November 2015 (UTC)

That's phab:T107861. - Nikki (talk) 05:03, 30 November 2015 (UTC)
Thanks Pamputt (talk) 06:36, 30 November 2015 (UTC)
Why isn't this fixed? --- Jura 07:08, 30 November 2015 (UTC)

Sandbox-Item (P369)

It says there "you can use this property for your experiments". Does this mean that I may assign and delete a claim with this property in any item for testing purposes? Is there also a Sandbox item to which I may assign anything for testing puposes? --Jobu0101 (talk) 08:58, 30 November 2015 (UTC)

There is Q4115189 and a handfull of others. You most likely find them in Category:Notability policy exemptions.
I would not give you any guarantee that using the sandbox-properties in real items does not affect how data is presented in the Clients. I know there are modules that tries to interpret any statement that is found in an item, including the sandbox-props. But using the sandbox-properties definitly do less harm than using many other properties. -- Innocent bystander (talk) 09:33, 30 November 2015 (UTC)

Wikidata weekly summary #186

Here's your quick overview of what has been happening around Wikidata over the last week.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2015/11&oldid=1102552055"