Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc. Please take a look at the frequently asked questions to see if your question has already been answered. Also see status updates to keep up-to-date on important things around Wikidata.
Requests for deletions can be made here. Merging instructions can be found here.
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2025/06.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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. --- Jura11:18, 5 November 2015 (UTC)[reply]
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. --- Jura15:50, 5 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[1] - 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'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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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 page20:10, 8 November 2015 (UTC)[reply]
@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)[reply]
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)[reply]
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).
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 page11:47, 9 November 2015 (UTC)[reply]
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)[reply]
@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 page12:22, 9 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
Category hierrachy
Helllo I need a category hierarchy of wikipedia more specifically I need a category tree .Can I get that through wikidata ? If yes could you please tell
how to get it .
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).
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.
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.
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)[reply]
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)[reply]
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)[reply]
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. — billinghurstsDrewth21:07, 10 November 2015 (UTC)[reply]
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)[reply]
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:
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)[reply]
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. --- Jura11:32, 11 November 2015 (UTC)[reply]
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. --- Jura18:42, 12 November 2015 (UTC)[reply]
No problem. It just seems a bit dated. I should probably try to find a way to exclude them from the reports. --- Jura20:45, 15 November 2015 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
There are nationality, birth/death dates, and websites encoded in the short description. I plan to extract those after item creation. Might seem the odd way around, but I believe there are more items with such data than just YourPaintings ones, where the same code could be applied. --Magnus Manske (talk) 15:56, 11 November 2015 (UTC)[reply]
In progressJobu0101, 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)[reply]
DoneJobu0101, 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)[reply]
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. -- Agabi10 (talk) 19:03, 15 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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).
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 page20:59, 11 November 2015 (UTC)[reply]
@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".
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)[reply]
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)[reply]
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)[reply]
How to link a region with the list of municipalities in it
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)[reply]
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:
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.
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Agabi10 (talk) 16:02, 15 November 2015 (UTC)[reply]
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)[reply]
Maybe the official name would be "New York International Airport" and native label "Idlewild Airport". At least, pre-1963. --- Jura13:58, 14 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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).
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)[reply]
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 page15:51, 15 November 2015 (UTC)[reply]
"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
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 page11:23, 15 November 2015 (UTC)[reply]
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)[reply]
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)[reply]
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.
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.
detail map (P1621) is for a detailed map or plan of the item, which is probably already too 'busy' to allow further annotation
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.
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)[reply]
@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.
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)[reply]
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)[reply]
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:
Report the error to the external dataset and mark it as an exception.
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)[reply]
Not quite: I'm aware of two cases (VIAF cluster 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)[reply]
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)[reply]
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)[reply]
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)[reply]
Some are probably subclasses of others, with a more generic and some dedicated to a specific field of application/knowledge. author TomT0m / talk page12:36, 16 November 2015 (UTC)[reply]
@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)[reply]
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?
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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?
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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')).
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.
item with the common cat property ? author TomT0m / talk page 18:39, 8 November 2015 (UTC)
Done. --Epìdosis 20:41, 8 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)
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.
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
_p2.300_-_Map_of_Northumberland.jpg?lang=de)
