This page is currently inactive and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the project chat.
An editor has requested the community to provide input on "Commons links" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you!
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
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. Therefore I am going to close this now and inform the community of standards reached in this RfC, deal with administrative issues from this RfC and inform Lydia of any possible development changes from this RfC.
Point I. Direct link between article and Commons category.
Statistics: 46% in favour.
Points: It reflects how interwikis are currently dealt with elsewhere. It is a narrow short term solution however. While it is narrow and not preferred it is usable in regards to how Wikidata works at the moment.
Conclusuon: This fails for a lack of consensus.
Point II. Articles only with galleries, categories with categories.
Statistics: 59% in favour.
Points: Can encourage creation of redundant pages on Commons and even disregard of Commons policy. In addition can lead to a large increase in redundant Wikidata items. Semantics, a interwiki should link to an interwiki of the same kind and not cross namespace reference. This allows things to be more consistent across Wikimedia as a general. Logical? This does not require Commons to have coverage over a specific subject. Is this what Commons is actually about?
Conclusion: Consensus wise this is on the end of a very thin boarder over whether consensus exists. Therefore I am going to class this as a fail for now..
Point III. Restructure Wikidata items.
Statistics: 79% in favour of this.
Points: Two things are about the same topic, therefore should be linked to the same topic rather than having to hack (use properties needlessly) to fulfil a core structural requirement. Commons is different, it has usually two un-mergable items about the same thing and thus both should be included. In addition not many (if any) other projects have such a system therefore this is a lacking technical requirements that should have been implemented before Commons got Phase 1. This may lead to 11 months of work being 'thrown away', then again this may lead to a more appropriate and more resilient Wikidata being created. Not practical?
Conclusion: I am going to call this a pass but not have the Wikidata development team bound by policy to do these changes. Lydia is the product manager of Wikidata therefore I will leave this in her discretion as product manager and allow he to exercise her choices. I am going to call this conclusion a 'Serious recommendation' to the dev team.
Point IV., V., and VI. have a lack of consensus immediately see-able. Therefore I will not put time into concluding with those three.
The community will be notified of this closure. No administrative action is needed. Lydia will be consulted immediately have this close for her view. I may make additional comments to this after closure changing decisions of III. and II. depending on what Lydia says. For now, John F. Lewis (talk) 14:20, 16 November 2013 (UTC)[reply]
Addendum: Per discussions with Lydia, the importance of Point III is not urgent at the moment though is going to be considered within the next few months. Until then, Point I and Point II were both considered as a technical step until Wikibase gets III. With consensus and future cleanup being less drastic with Point II, I am going to promote the consensus to successful on the fine line using my discretion so we can finally sort out how we manage Commons. Users with concerns should preferably contact me on my talk page prior to starting a discussion which will override my decision to use II for the mean time. Thanks, John F. Lewis (talk) 15:38, 16 November 2013 (UTC)[reply]
Addendum 2: Per requests for considering V and VI on my talkpage as well as discussions with Lydia about the realistic option of restructuring the whole model, I am going to make a special allowances for VI's lack of time to comment and weightless oppose. Therefore effective when people see this, VI is successful at 100%. Notability will be updated to make changes as well as the development teams support for keeping a gallery-category sitelink relation (See Lydia). John F. Lewis (talk) 20:53, 18 November 2013 (UTC)[reply]
Original RfC was written in Russian. English translation can be inaccurate. Please correct translation if needed.
Wikidata abilities was extended to Commons project. There is question: are we need to change current interwiki links on Commons project? If yes then how?
More than 80% of Commons categories with interwiki links are linked to Wikipedia articles, not to categories. See #Data on Commons interwiki links for details.
About discussion procedure: please add your comments to "Discussion" sections. "Points"/"Limitations" sections can be extended by shortly formulated additional arguments, but discussion of these arguments please make in "Discussion" section.
Oppose this approach would support current Commons categories -> Wikipedia articles links; however it would make a mess for links of commons gallery pages and wikipedia categories. Currently interwiki links from commons are quite unpredictable you might find Category -> article link or Category -> Category link. There is no need to copy this unpredictability to wikidata. We run into software limitation issues, those should be addressed by correcting software and not by using the software in unpredictable way. --Jarekt (talk) 19:38, 2 October 2013 (UTC)[reply]
There can be good editorial reasons for some Commons categories linking to articles, and others linking to categories. Of course, some links will have been added without due thought or understanding, but many are based on good editorial judgment. Which categories should link where is a question for editors of the Commons pages to decide. Wikidata should aim to support these links as they stand, and not impose some rigid structure based on technical limitations of the software.
I agree software limitations need to be addressed. Part of our focus here should be figuring what features need to be added, and part should be on deciding what to do until they are. Can we go ahead with some Commons-Wikidata linking, or would this have enough negative effects on Commons or Wikidata that it's best to just turn Wikidata off on Commons until the software can handle it properly? --Avenue (talk) 05:17, 3 October 2013 (UTC)[reply]
Comment The diagram on the right is a bit misleading, because in most cases the Wikipedia category and its Wikidata item won't exist. In these cases it makes more sense to link to the exising Wikidata entry and use its interwiki links than to create a new one that just says that the Commons category exists. In the other cases, where there is a Wikipedia category, you should have the choice of linking the Commons category to one wikidata item or the other, depending on which is a better match. If the two wikidata items actually refer to the same thing (except that one links articles and the other categories), then I'd prefer that they were combined, as in option 3. Ghouston (talk) 23:15, 3 October 2013 (UTC)[reply]
Support This reflects the reality today on Commons and is the most logical/practical solution (but the be fair maybe not the best semantic solution). Furthermore I will support III. Restructure Wikidata items to make it possible to link pages, categories, and galleries with 1 Wikidata item. Raymond (talk) 09:46, 4 October 2013 (UTC)[reply]
Comment The current approach is that links to Wikipedia categories are preffered (for the most important items) but if there is not a category of such item in any Wikipedia language (most of particular items), a link to the article is used instead of a link to the category. Generally, we should support both. A Commons category should have two blocks if onterwiki links - 1) links to Wikipedia articles, 2) links to Wikipedia categories which both are directly related to an identic real item. Afterwards we can solve technical details - whether the interwiki blocks should be hidden/rolled-up or not, whether we can use links through one Wikidata entry or through two sister-entries etc. --ŠJů (talk) 16:18, 5 October 2013 (UTC)[reply]
Comment. I think we should consider things not with Commons as it is today, but with Commons as it should look like once the changes proposed in Commons:Commons:Wikidata for media info are implemented. The basic idea is that Commons categories are semantically vague and that replacing with Wikidata-like statements would be a large step forward. Of course it will take time to switch from category-based system to a semantic one, but it would help, if we did not constrain the new system with the legacies of a category-based system. Wha we will need instead of categories is easy access to queries about the item. It makes most sense to have that in the main-namespace rather than in categories. That would avoid cross-namespace linkings, and other oddities associated with using a non-main namespace. For instance, templates imported from other Wikis may have a different behaviour outsie the main namespaces. And "category" is the probably the most unwieldy of all namespaces, they can't even be renamed using the standard procedure. --Zolo (talk) 13:20, 10 October 2013 (UTC)[reply]
I understand that file description can be supported through WikiData and can exploit Wikidata links and properties and the structure of file description pages can be essentialy rebuild. But this vision and process has nothing to do with the today's problem. Implementation of file metadata to Wikidata is a separate special problem and should be not mixed with other problems. --ŠJů (talk) 17:59, 12 October 2013 (UTC)[reply]
Also the idea to replace the local categorization systems of separate projects with an united and integrated system is inspirational for the distant future. However, the Wikidata logic and its properties are very immature and imperfect still. It cannot entitle to ignore or destroy the current categorization system which is more consistent, advanced, established and useful, though can be further improved. We should to approximate the categorization principles to property principles and property principles to categorization principles: the relation subcategory-parent category should be tagged by the semantic type of relation (hyponymic, metonymic, locative, timing, attributing, agentive relation, affiliation etc.) and the property system should be inspired by the modularity, universality and conveniency of the categorization system. But that is a long-distance run. Please discuss it separately. --ŠJů (talk) 17:59, 12 October 2013 (UTC)[reply]
I am not proposing to destroy anything. I know Commons categorization system pretty well, and I think anyone can agree that it has structural flaws (semantic imprecision, massive redundancies created by intersection categories..) There is already a proposal to use a property system that may fix that. Obviously, that won't happen in one day and no one can know for sure how well it will succeed, but if we want to try it in the best conditions, we need direct links between Wikidata items and Commons main namespace. If we can restructure Wikidata items so that it also link to categories, I would find it great, but if we only have links to one namespace, it should be the main one. --Zolo (talk) 07:55, 13 October 2013 (UTC)[reply]
Wikidata items should be defined by item, not by namespace. The Wikidata item should link structural subjects related to the real item across projects and across namespaces. --ŠJů (talk) 17:59, 12 October 2013 (UTC)[reply]
Support per Raymond, Cennox. The other ways argument is too formal and doesn't consider the reality and needs of commonscat and wikipedia article linking. If you propose to link only categories you neglect the essentials of commons, which is structured by categories mainly. So the articles (essential on WP) must be linked to the essential of commons (categories). We do not need wikidata on commons, if wikidata does not support this function.--Oursana (talk) 11:54, 18 October 2013 (UTC)[reply]
Commons galleries are not equivalents of Wikipedia articles really. Articles and categories should be unique for an item within one project, galleries are not intended nor required to be unique, and they are a bonus for selected items only, not a basic structural element.
Most categories in Commons have no corresponding categories in Wikipedia. We would need to create a large number of additional elements for Commons categories.
There are no Commons galleries for most Wikipedia articles.
commonscat template in Wikipedia articles can not use links directly.
Main entities of Wikipedia (articles) are often linked with non-main entities of Commons (galleries). Most galleries are poorly maintained, and there seems little prospect of widespread improvement.
Support per Commons:User:Multichill/Commons Wikidata roadmap. This is the only way to keep wikidata database deterministic, but unfortunately it is not compatible with majority of current interwiki links which link Commons categories with wikipedia articles. We will have to keep the current interwiki links in commons categories until wikidata implements some software changes which will allow to pick for the interwiki links to point to either wikipedia categories or/and articles. --Jarekt (talk) 18:56, 2 October 2013 (UTC)[reply]
Comment -- with all due respect, abstract design ideals SHOULD NOT trump usefulness; we (wm as a whole, not just wd) exist to provide an information/education service to users, not to create a "perfect" theoretical data-construct. Lx 121 (talk) 03:31, 22 October 2013 (UTC)[reply]
Is this software change approved by development team and included to roadmap? – The preceding unsigned comment was added byIvan A. Krestinin (talk • contribs).
What software changes would be needed to get this approach to support Commons interwiki links properly? (E.g. categories and galleries both linking to the same set of Wikipedia articles.) Multichill's roadmap/essay doesn't seem to address this. Maybe I'm missing something, but it seems like it would rely on a lot of ongoing bot work keeping interwiki links in sync - the sort of thing I thought Wikidata was supposed to make unnecessary. --Avenue (talk) 05:25, 3 October 2013 (UTC)[reply]
Support, per Jarekt. I m a not sure about what the software changes will be though (bugzilla:p49805 would at least allow to add an interwiki table somewhere in the category page). Also, with Wikidata + Lua, we can much more easily create relatively nice gallery pages, with an automatically created infobox and perhaps links to related concepts. Beside, if commons:Commons:Wikidata for media info gets implemented, galleries should become more useful as a hub to link to queries, while the importance of categories will decline (because they are much less precise than what we can get with queries). --Zolo (talk) 11:37, 3 October 2013 (UTC) (if it was possible to have one link per namespace, per item, that would probably be my preferred choice, but that does not seem to be on the agenda). --Zolo (talk) 11:41, 3 October 2013 (UTC)[reply]
Comment, with all due respect, the above comments show very little understanding of the working REALITIES of wmcommons. we have ~20 MILLION FILES, & growing steadily; & many of them are not even categorised yet. a "spiffy new easy-to-use gallery tool! (^__^)" is NOT going to magically change the entire data-structure there. categories are the PRIMARY unit of organization @ commons. EVERYTHING is sorted on that basis, & unless you radically re-design mediawiki to organize material differently/better, that is NOT GOING TO CHANGE. Lx 121 (talk) 03:31, 22 October 2013 (UTC)[reply]
If by "have one link per namespace, per item" you are just talking about Commons namespaces, I think option IV is the closest we can currently get, and the option with the least extra work once the software is upgraded to allow multiple links.
More generally, I think this RFC should focus on identifying what we want and what's possible, short and long term, before we start choosing from a list of options. --Avenue (talk) 18:42, 3 October 2013 (UTC)[reply]
I would like it if we were able to add both the gallery and the category link to the same page, but I do not want to let the user choose the one he prefers, as that may become quite messy. --Zolo (talk) 21:43, 3 October 2013 (UTC)[reply]
If we have to choose one, I don't object to having rules about which should be chosen. But do you really want to prohibit the most common sort of link (Commons category to Wikipedia article)? That doesn't seem the most sensible rule to me. --Avenue (talk) 23:06, 3 October 2013 (UTC)[reply]
Oppose, should we encourage the creation of galleries on Commons? I don't think so, they are barely updated and most of them have just arbitrary criteria about the media selection, but Commons categories (well categorized) have all the related media. Ideally, should we have one Commons gallery for every Wikipedia article, or create a category on Wikipedia just to link with Commons categories? Most articles will never have any gallery, and in that case, we can use the right wikidata property to link it. --UAwiki (talk) 12:53, 3 October 2013 (UTC)[reply]
Your leading comment is a strawman: No one has suggested we create or even encourage galleries on Commons, which (I'm not sure) seems to make your argument fall apart. --Izno (talk) 15:21, 12 October 2013 (UTC)[reply]
Oppose. It seems like madness to create thousands of Wikidata items that say nothing except that they have a Commons category. I don't think this would be fixed if a link was created from the Commons Wikidata item to the "real" Wikidata item so that the interwiki links can be obtained for Commons. If the Commons category has the same topic as a Wikipedia article, then they should both be linked to the same Wikidata item. Ghouston (talk) 22:58, 3 October 2013 (UTC)[reply]
I see no issue with creating thousands (or hundreds of thousands) of such items. We're already at 13.5 million (with another 1.5 million deleted!). If that's all your argument boils down to, that's not very convincing. --Izno (talk) 15:21, 12 October 2013 (UTC)[reply]
Support Efter some pondering I've decided to support this proposal. It all comes down to semantics; Interwiki-links should not cross namespace-borders. A category is a category and an article is an article. We should not pretend that a category is an article in another language. And no, it is not madness to create Wikidata-items for Commons categories. All items on all Wikimedia projects should have Wikidata items, if only for their multi-lingual labels. However, as UAwiki, I do not want to encourage the creation of Commons-galleries. I believe them to be superfluous. What I want is Commons-categories with interwiki-links to Wikipedia-categories and a top-template that describes the category by fetching the label and link from the category's main topic (P301). /Esquilo (talk) 06:28, 4 October 2013 (UTC)[reply]
Support, best choice of these. Only thing what is not good, is that on Commons even categories with 1 picture are allowed, so most likely they will never have a category on Wikipedia. --Stryn (talk) 10:05, 4 October 2013 (UTC)[reply]
There's also the possibility of linking a Commons category to a Wikivoyage category - and it happened to me in the last days. I think that a large part of all this mess is caused by the fact that, once again, we're forgetting about sister project. :) --Sannita - not just another it.wiki sysop11:16, 6 October 2013 (UTC)[reply]
I know, but I meant with on Commons even categories with 1 picture are allowed especially persons, they will never be on Wikivoyage, and maybe nowhere else than on Wikipedia AFAIK. --Stryn (talk) 13:52, 6 October 2013 (UTC)[reply]
Comment There is a conflict between two uses/meanings of sitelinks. One simply says that we want to maintain interwiki links between these pages, while the other says (at least in its strongest form) that these pages represent the same thing. For Wikipedia pages, these usages did not conflict much, but for Commons pages, they conflict much more often. To say "it comes down to semantics" is IMO to say the latter usage should overrule the former. That seems a poor choice for Commons-Wikidata Phase I, where we are concerned with getting interwiki links working well. --Avenue (talk) 15:32, 5 October 2013 (UTC)[reply]
Which does seem to ignore the point that Wikidata's purpose isn't the interwiki links, it's to create a knowledge base. Interwikis are only a sub-goal of centralizing the knowledge of the wikis. --Izno (talk) 15:21, 12 October 2013 (UTC)[reply]
Support This is IMHO the best choice, since Commons' category namespace would be linked with other WMF projects' category namespace, and Commons' main namespace would be linked with other WMF projects' main namespace. Because this is what should be done in theory. Then, practically, we have the problem of linking Commons categories also to Wiki* articles/pages - but this is another kind of problem, more practical and Commons-related, that should be divided from the main one, i.e. what should be linked here. I'm not saying "let Commons solve its own problem", I'm saying "let's do what is more logical for Wikidata here and, at the same time, let's find an alternate way to solve the problem for Commons". --Sannita - not just another it.wiki sysop15:42, 5 October 2013 (UTC)[reply]
Strong oppose.
Such a solution would deepen the fatal fault of the Wikidata structure and practice that - in contradiction to the claims that Q-entries represents real items - Q-entries represents a type of the linked pages (separately articles, separately categories related to the identic real item). Here is no reason to consider articles (or even galleries) as more representative for real items than categories. Even an article is a grouping of data only, even an article is not the real item itself.
The second clear mistake is the presumption that Commons galleries are equivalents of Wikipedia articles, even though the main project spaces seem to be formally similar. No, they are not. Articles are unique for any item and they are a basic form of the stucture of Wikipedia. Commons galleries can be multiple (we can create a lot of quite different galleries for identic item), and they are not an essential element of the structure but an additional optional bonus for selected most interesting items.
Of course, we should not suppress links to Commons galleries. They should be prominently linked from both, from articles and from categories. However, recommended galleries should be linked rather through Wikidata property than through interwiki links. --ŠJů (talk) 16:48, 5 October 2013 (UTC)[reply]
Oppose per ŠJů & Lx 121: what every supporter talks here is cross namespace, etc. what ppl dont seem to (understand) agree with, is that here (commons) the category namespace IS THE article namespace. it doesnt really matter what's written on it. we use it as such, and its seemingly a good practice to keep so forever. so superficial parallellism is illogical, despite its main and most loved championing of it being "logical" or "consistent". there is a proper invisible reversal of roles in commons. see Lx's writing as well: with multiple galleries, which are a sub-thing, a detail. --Aaa3-other (talk) 14:09, 10 November 2013 (UTC)[reply]
Support This sounds like the most logical solution: link items to the same kind of items on Wikidata. Interwiki links on category pages will have to be provided using a software change. --Stefan2 (talk) 19:43, 5 October 2013 (UTC)[reply]
Support The most logical way to class a item. --Fralambert (talk)
Support this works both in the short and the longer term. In the short term equivalent categories and articles/galleries are connected. Linking from Wikipedia is done with the Commonscat template and for some categories on Commons we can just keep the interwiki links around for now. I wouldn't oppose being pragmatic for the time being. When tracking & purging becomes available we can easily connect whatever we want, see also this roadmap I wrote. Multichill (talk) 09:54, 6 October 2013 (UTC)[reply]
Support This is in effect what we should have been doing all along, I do accept the argument that most wikipedia articles don't have a corresponding Commons category, and that categories are the main organisational tool on Commons, where galleries do not exist or where they are not viable a gallery can be created as a redirect to the relevant category.--KTo288 (talk) 14:24, 7 October 2013 (UTC)[reply]
Not as such, no, but you can create a page with some other content (e.g. a soft redirect), link a Wikidata item to it, and then change it into a hard redirect. Doing that little dance many thousands of times doesn't seem ideal, but none of this is ideal. If we're lucky, maybe the developers will even fix that bug first. --Avenue (talk) 20:45, 7 October 2013 (UTC)[reply]
The current behavior of the redirects is a bug, yes. The behavior as described in the RFC is a feature request that has yet to be meaningfully implemented. --Izno (talk) 23:16, 7 October 2013 (UTC)[reply]
Oppose. This may be the least disruptive option but it doesn't give us what we need. This project is still just beginning. now is the time to get it right - not just sort of nearly. Filceolaire (talk) 17:52, 10 October 2013 (UTC)[reply]
Take a look e.g. to cs:Category:Potštejn and commons:category:Potštejn. There are some articles and almost the same number of categories, so it can be easy connected. We can expct that somebody write some new articles and somebody makes new categories on commons. But creating categories on wikipedia is bad idea - there will be only one article per category.
"As I know page can access Wikidata item that is linked with it only. So sujet de la catégorie (P301) can not be used." This is unfortunate, but I guess the developers have a good motiv to do this limiter. Maybe a fix or a hack will appear in the future, maybe the limit of request level will be increased to 2 in the future. Visite fortuitement prolongée (talk) 21:29, 18 October 2013 (UTC)[reply]
using Wikidata interwikilinks/sitelinks to Wikipedia category, next the user click on "The main article for this category is Pablo Picasso.", as today.
Support per Visite fortuitement prolongée and Esquilo. I see nothing wrong with having to create a lot of items for categories (and even more so as I anticipate Wikidata to be deployed at Wikibooks and Wikiversity — these will surely bring quite a few items on their own.) The Commons’ categories should be linked to Wikipedia articles with category's main topic (P301), and the exact means of rendering such a link at either of the pages is a completely separate matter. — Ivan Shmakov (d ▞ c) 18:47, 18 October 2013 (UTC)[reply]
STRONG Oppose -- WOSRT POSSIBLE OPTION. commons is not "photo-wikipedia", COMMONS IS A CATALOGUE of free media files. we don't do "articles" @ commons, we sort material. galleries are an afterthought; most topics don't have a page (unless it's a redirect to the category) & where galleries do exist, they are rarely maintained/updated, & unlikely to represent either a comprehensive range, or "the best", of what commons has for the subject.
& speaking as someone who spends most of their time sorting materials @ commons, & cross-linking with wp:en, & who has done A HELL OF A LOT of cross-linking, IF you arbitrarily wipe out all of the work that i've done cross-linking, because it's "tider" for wikidata that way, then you can clean up the mess without me. i'm not quitting wm over it, but it'll be a cold day in the-hell-which-i-do-not-believe-in before i create another inter-wiki link, after that...
Oppose per Lx 121 and ŠJů. In most cases Wikipedia articles are best linked with Commons categories, while galleries are rarely used, poorly maintained, and mostly non-existent. --Elekhh (talk) 13:24, 30 October 2013 (UTC)[reply]
SupportWeak support Moving support to VI. The Anonymouse (talk) 16:43, 7 November 2013 (UTC) This is, in my opinion, the simplest, most consistent solution. The entire problem is wanting to modify the way Wikidata is structured to fit Commons's needs. Namespaces should be linked with each other, regardless of their supposed importance.[reply]
Galleries, which are in the mainspace on Commons, should be linked with articles on Wikipedia, which are also in the mainspace. Categories on both Commons and Wikipedia should be linked together because they are both in the category space. This means that there will always be consistency in interwiki links.
If Commons wants interwiki links going from categories to Wikipedia articles, they should use manual interwiki linking, or better yet, a Lua template that extracts that information from Wikidata (if that is possible). Same with Wikipedia articles/categories wanting links going to Commons categories/galleries.
A new Wikidata item can always be created for a Commons category if there is no equivalent category on Wikipedia.
If Commons had a simple, consistent structure, we would have more flexibility. But because the relationship between galleries and categories on Commons (and their relationships to Wikipedia articles and categories) is not consistent, this is really the only consistent solution.
Currently we have 360'151 iwiki links from Commons categories to enwiki articles (number of links from Commons category to enwiki category is 66'347). Why article-category linking is so popular? What we will do with 300 thousands iwiki links? (delete its, stay on Commons, move to template or something else) How to navigate for example from commons:Category:Luna 9 to ru:Луна-9 if iwiki links will be deleted? — Ivan A. Krestinin (talk) 23:23, 7 October 2013 (UTC)[reply]
Yes, this is my biggest concern about this option; it says nothing about how interwiki links will be handled. Various people have suggested using templates, redirects, or Wikidata software changes, but it's all pretty vague.
Commons category about more important items links to Wikipedia categories (just because Wikipedia categories exist; such links are preferred), other Commons categories links to Wikipedia articles (just because Wikipedia categories don't exist and Wikipedia articles exist). In case of photos of real places and real objects, the categorization of Commons is substantially more detailed than categorization of Wikipedias and that's why we have more links category-article than category-category. That's nothing now, nothing mysterious, nothing incomprehensible. If we will have both sets of interwiki links (to articles and to categories of the item), it would be a significant improvement for Commons (and maybe also for Wikipedias) - links to articles are useful even if the primary links are to categories.
Commons need a systematic tool to handle the interwiki links. The tool should handle both sets of interwikis. There exist several ways how to treat this matter. An systematic solution through Wikidata would be optimal. However, Wikidata Team seems to be a bit blocked and not capable of any complete and satisfactory solution (even though it is not so difficult). A template displaying interwiki links through a Wikidata parser function would be an elegant but incomplete (unilateral) surrogate solution. However, not even such simple basic function was not enabled yet. --ŠJů (talk) 18:28, 12 October 2013 (UTC)[reply]
I agree, Commons does need a system for handling interwiki links, and yes, it would be ideal if Wikidata could do this. Maybe some day. --Avenue (talk) 21:34, 13 October 2013 (UTC)[reply]
Is there really a need to put Commons galleries into Wikidata item for Wikipedia article as interwikilinks/sitelinks? If it is postponed, it could save opposition and time. I am not convinced that Commons gallery namespace correspond exactly to Wikipedia article namespace, Commons gallery (P935) might be sufficient. Visite fortuitement prolongée (talk) 20:08, 15 October 2013 (UTC)[reply]
The need arises from the fact that Commons galleries have interwiki links (to Wikipedia articles) and the desire to manage these directly through Wikidata. If a suitable alternative method for managing the interwiki links could be devised, then a lot of the practical difficulties we currently face will be eased, and perhaps there will be less disagreement too. But we have nothing very concrete yet.
I agree that the Commons gallery namespace holds pages that do not correspond closely to Wikipedia articles. But I think that Commons categories are somewhat different beasts from Wikipedia categories too. --Avenue (talk) 21:25, 24 October 2013 (UTC)[reply]
First, opinions differ on that. Second, I was talking about the difficulties "we currently face" back in October, before VI was proposed. I do agree that VI is a much more concrete proposal than II. --Avenue (talk) 03:41, 14 November 2013 (UTC)[reply]
I'm not sure that I accept the conclusion. In some cases pages in different namespaces may have the same name but be about different concepts, but in other cases they are both about the same thing. If Wikipedia articles and Commons categories were always conceptually different, why would we be creating so many links between them? Ghouston (talk) 08:26, 3 October 2013 (UTC)[reply]
Support Categories and articles are different, but that doesn't mean they can't be about the same topic, and so share a Wikidata item. If it happens in some cases that they are about different topics but incidentally have the same name, then it's still possible to create separate Wikidata items for them. Ghouston (talk) 23:34, 3 October 2013 (UTC)[reply]
Support In my opinion, the wikidata item should have exactly 2 commons links: one to the category namespace and one to the main namespace (or any other). And these 2 links should have different titles (for example, "commonswiki" and "commonscatwiki") that allow to avoid an interwiki conflicts from different items and is handy for automatic scripts. --Emaus (talk) 09:07, 5 October 2013 (UTC)[reply]
Strong oppose Such a proposal would mean to re-think completely Wikidata and to throw in the bin 11 months of work on contents and almost two-and-a-half years of work on the structure itself - just because. There is the possibility to solve the problem, this is by far the worst one. There are different namespaces for a reason, and there are reciprocate properties that link articles' items with categories' items - so we already solved this problem too. --Sannita - not just another it.wiki sysop15:58, 5 October 2013 (UTC)[reply]
I know why separate namespaces exist. However I still don't understand why separate namespaces require separate Wikidata entries, if they both refer to the same topic. It's not even done constistently, because "main" namespace Wikidata entries do have items such as Property:P373 that refer to categories. For example, why does Q7149656 exist, when all of the information on that page could have been added to Q84? Q84 has an item for the Commons category, why is that present when that Q84 is supposedly only about stuff in the article namespace? Can random items from Q84, like "headquarters location", also be added to Q7149656? Ghouston (talk) 00:45, 6 October 2013 (UTC)[reply]
Strong support.
The problem was caused by fatal inconsistency and ignorance and misapprehension of the relation between items, articles and categories (and ignorance about existence of Wikimedia Commons). If the Q-entries of Wikidata would represent really the real entities, both the links to articles and the links to categories of the item would be related directly to identic item. It is not very difficult to understand nor to implementation.
It is not needded to "re-think completely Wikidata" - it would be sufficient to think-out Wikidata once but in time (or belatedly). I think, to enable to link both articles and categories from identic item-entry of Wikidata is not so essential change to be feared as a cause of a loss of previous outcomes. I believe, the Wikidata structure is not designed as much badly to be incapable to be improved and developed.
Commons galleries are essentially not elements of the project structure but an accesory presentation form. Structurally, galleries are rather equivalents of files than equivalents of articles or galleries. We should enable to display the interwiki set on the gallery page and to link the galleries from the article and category pages but it should be done rather through Wikidata properties and special parser functions. However, it is possible to create an additional Wikidata feature which would able to deal with not-unique pages (as galleries or files), anchor (#) links, redirects etc. in similar way as with the current interwiki links. If reciprocal properties at Wikidata would work really and automatically as reciprocal and if links to Commons pages in Wikidata properties would work really also as reciprocal links, we can approximate to some solution. --ŠJů (talk) 17:23, 5 October 2013 (UTC)[reply]
Comment Let's start with a basic concept: we are NOT trying to "colonize Commons", we are NOT trying to "impose Commons" other ways to do their job. We acknowledge that both galleries and categories are two different things, with their pros and cons, and that beside that, they should both link to Wikipedia articles. Because the problem we're trying to tackle here is this: how we can continue to allow to link a Wikipedia article from a Commons gallery and a Commons category. In other words: how we can allow Commons to do what they're doing now also in the next future.
Now, this is more a practical problem than a theoretical problem. As I said, we acknowledge that galleries are less used than categories, and that on Commons categories are more useful and more important than in any other project -- but this isn't the problem we're trying to solve here. Ok? We're trying to find a way to preserve this peculiarity of Commons, reducing the impact of the integration with Wikidata on Commons and possibily avoiding to re-invent once again Wikidata, since developers have other priorities, such as completing the number and number-with-measure datatypes or allowing to call certain data from other items. This is basically why I oppose this hypotesis: it would mean to postpone some really useful improvements, to ask for something we don't need now, since there are for sure some practical solutions that can help us to overcome these problems for the time being, while we're waiting for an evolution of the situation. Sannita - not just another it.wiki sysop10:57, 6 October 2013 (UTC)[reply]
Supporting Commons is the topic of this RFC, but the logical structure of Wikidata is also interesting if it's causing problems for Commons support. Perhaps it's not likely that Wikidata developers are going to drop whatever they are currently doing and work on this instead. However if it's true that Wikidata has this flaw, then we can still acknowledge it and add it to the list of things that should be fixed some day, and in the meantime, try to avoid making the problem worse (for example, by creating thousands of pointless Wikidata items for Commons categories). Ghouston (talk) 23:01, 6 October 2013 (UTC)[reply]
Support if we can get software change that would leave the same database structure, however the GUI would display both article and category items on the same page with shared properties. I would Oppose the idea if it required changes other than top level GUI. --Jarekt (talk) 13:58, 10 October 2013 (UTC)[reply]
Support: This is what we need. Means that your project so far is wrong? Good — say thank you for the correction, make a note to do things properly next time (like getting to know the “client” at stage one of your planning), and start working. Tuvalkin (talk) 00:29, 7 October 2013 (UTC)[reply]
The above was added here before, but for some reason it got signed up as my IP, not as my user (reason being — ever since geniuses come up with Vector, centralized login has been broken): «82.154.94.217 16:05, 6 October 2013 (UTC)» It got undone by Sannita as it if were random vandalism, while the text made it clear that this was an established user talking, unaware of being logged off. Big time bad faith, but I’m not surprised — this kind of enlightened geniuses who throw tantrums whenever their pretty schemes collide with reality is well known in IT workplaces, I’m just shocked to see this plaguing non-profit projects. Tuvalkin (talk) 00:29, 7 October 2013 (UTC)[reply]
Good, so I will just repost what I wrote in your IP talk page: «A bit more of courtesy and respect to the work of a team who worked its arse off in the last 18 months would be more than appreciated.» And no, it wasn't that clear that it was "an established user talking". I'm sorry if you felt offended, but I still find your comment too much and uselessly harsh towards people who are working in this project. -- Sannita - not just another it.wiki sysop11:34, 7 October 2013 (UTC)[reply]
And I'll be more clear on the point: I have never come to Commons, telling that your work is awful. I do respect your work you all did in these year, I just ask for the same respect for people who worked here. We're trying to solve a common problem, these kind of comments are absolutely useless and are good only to raise the temperature of the discussion, not to reach a common solution. --Sannita - not just another it.wiki sysop11:36, 7 October 2013 (UTC)[reply]
Oppose on practical grounds. It would take a lot of community work to change the data structure now, as well as scarce developer time. I doubt the benefits are worth the costs at this time. The concept does appeal to me, though. --Avenue (talk) 21:05, 7 October 2013 (UTC)[reply]
I've struck my oppose !vote, because I'm no longer convinced that the work required to adopt this option would be dramatically greater than that required for the other options we're considering. (See discussion below.) --Avenue (talk) 09:50, 11 October 2013 (UTC)[reply]
Support, makes the most sense, and will provide the cleanest structure overall. Transitioning to the new structure will take some work, but will be worth it in the end. Having an item for each combination of topic and namespace makes things far harder than they need to be. It's much better to keep all the content about each topic in one place. --Avenue (talk) 00:12, 23 October 2013 (UTC)[reply]
It seems premature to reject the idea just because it would require some changes. Nobody has even said how large these changes will be or how hard they are. One thing seems to be the assumption that there's only one site link to each external wiki. However if the software changes could be done with a reasonable amount of effort (like weeks, and not years), and the subsequent data changes could be done with bots, then I'd say it should still be listed as something to be done some day. Ghouston (talk) 22:53, 8 October 2013 (UTC)[reply]
The community work required seems really negligible. The only thing you need is to merge items with those to which they are linked to category's main topic (P301). Category items should be essentially empty except for "instance of category" or topic's main category (P910). If there is something else, it is likely to be a mistake anyway. The real questions are development time and the potential overhead in terms of performance and usability. --Zolo (talk) 07:05, 9 October 2013 (UTC)[reply]
It is a trivial bot task, except if the item does not follow the usual structure, and in that case it would require fixing anyway. --Zolo (talk) 09:14, 9 October 2013 (UTC)[reply]
Large work is not trivial for bots too. Many items => much time, many unexpected situations or many false edits and loosed data. Merge algorithm is not trivial (labels, aliases, claims, site-links, references...). Delete rights are required for bot. Please do not say "trivial" before you done a task :-). — Ivan A. Krestinin (talk) 18:10, 9 October 2013 (UTC)[reply]
Fair enough. So let's say that several bots have already a large number of edits and that the task is not very complicated. Descriptions can be ignored, as they are either something like 'category page" or some sort of error. I think labels and aliases can be ignored too: labels for category items have always been unwieldy and semantically problematic. So, we need to check items that use category's main topic (P301), then check if it contains any other claim other than P31: Wikimedia category (Q4167836). If it does, there is something wrong, put it in a list of errors (it would need to be done, even if we did not want to merge the items anyway).Else, move the links to the item linked through the category's main topic (P301) and delete the item. Of course, this is very crude and we may want to do something smarter. But that would be improving our data, not just updating the system. I think the work required is sufficiently small to be neglected when discussing a major structural change such as this one. ~--Zolo (talk) 19:47, 9 October 2013 (UTC)[reply]
Possibly, but we are talking about a major long-term structural change here. There may be good reasons against the change, but I do not think that a few hours of initial coding should weigh on the decision. --Zolo (talk) 11:54, 10 October 2013 (UTC)[reply]
I'm looking back at the claim that the work is negligible because the "only thing you need is to merge items with those to which they are linked to category's main topic (P301)." That seems to assume that all categories are linked to their main topic by P301, which strikes me a dubious assumption. Clicking on Special:Random 10 times gave me 3 categories (Category:1912 Summer Olympics competitors for Finland (Q9490693), Category:Mon, India (Q8638164)), and Q9706476). Of those three, only one had a statement using P301 (or any statements at all). I know this is a very small sample (can anyone provide some better data?), and many categories are unlikely to have a main topic on Wikidata yet, but it still makes me think that matching up topics with categories won't be as simple as suggested above. --Avenue (talk) 03:43, 11 October 2013 (UTC)[reply]
I do not have any data, but regardless of the numbers, if a category matches an article, that is something that would have to be done anyhow. The other possiblity is that the category does not match any article, and in that case we a currently have a rather annoying situation, as we have no good way to tell what the category is about. With the proposed change, items could refer to external concepts just like other items, and that would solve part of the problem. --Zolo (talk) 08:00, 11 October 2013 (UTC)[reply]
Good point. Categories currently without a category's main topic (P301) link do present problems under either structure.
Support. Even if it is weeks of coding that is not a reason not to do it. Wikidata is just beginning and now is the time to make these changes, before we have a ton of third party applications depending on us. Filceolaire (talk) 17:48, 10 October 2013 (UTC)[reply]
Oppose: A category is not an article (topic). Those arguing that it (Sju in particular) is miss the point of categories, which are collections of like objects (sometimes!)—in other words, a collection (most usually) of subclasses of the category topic, but not the category topic itself. Even on Commons, categories are collections of representations of the object, and very rarely the object in question. --Izno (talk) 15:10, 12 October 2013 (UTC)[reply]
A category is not a topic, an article is also not a topic. But both the category and the article are defined by the topic and contain information related to the topic. Words and sentences about the topic are "objects" similarly as articles or files are. Is it so difficult to understand? Even Wikipedia articles are not some Platonic pure and simple ideas of the topic but only collections of information about the topic, just as categories are. Unfortunately, Wikidata Team seems to consist mainly of such people which are not capable to understand the basic relation between items and articles, items and categories and articles and categories and not capable to understand (and implement to Wikidata) advantages of categorization system - especially its modularity, universality, simplicity and easy usability. That ignorance results in increasing chaotic perplexity and often redundancy of hundreds of properties etc. Try to be more respectful toward the established and well-advanced current system of wiki projects which was here before Wikidata and let you to inspire and lead by it. Your help to our other Wikimedia projects is very welcomed but first of all you need to understand and respect the projects and their logic and principles. --ŠJů (talk) 17:25, 12 October 2013 (UTC)[reply]
Let me break it down.
But both the category and the article are defined by the topic and contain information related to the topic. Even Wikipedia articles are not some Platonic pure and simple ideas of the topic but only collections of information about the topic, just as categories are.
True, but from a modeling point of view, it is nonsensical to model categories as anything but collections of articles, not least because categories are "the backend"—the end that most people don't give two hoots about. It is sensible to model articles directly as the domain entities, because why else have a database where we do things with knowledge entities? You are proposing to do the latter i.e. something that is nonsensical. Is that so difficult to understand?
advantages of categorization system - especially its modularity, universality, simplicity and easy usability
Fundamentally, the category system is none of these things. Per Multichill's many arguments made elsewhere, they in fact inhibit expression, classification, and categorization of image topics, rather than aid it. That's why this mess even exists at all. Now is the best time to fix it, and that is by not making the error in judgement that you are.
That ignorance results in increasing chaotic perplexity and often redundancy of hundreds of properties etc
Nope. I don't even feel a need to respond to this.
Try to be more respectful toward the established and well-advanced current system of wiki projects which was here before Wikidata and let you to inspire and lead by it.
What has worked in the past will no longer work going into the future. The very notion of Wikidata upsets the established quo; just look at how many people question why one thing links to one thing and one thing only (you among those!). We should attempt to respect the wikis, but fundamentally, our goal is not necessarily theirs but something bigger. Looking to them only will lead us down false paths. Period.
Your help to our other Wikimedia projects is very welcomed but first of all you need to understand and respect the projects and their logic and principles.
I would ask that you not make assumptions about my understanding—this is an ad hominem argument.
I agree, but then I don't understand Izno's point. I can quote from Wikidata:Glossary that an item is "a page in Wikidata main namespace that represents a real-life topic, concept, or subject." So we have an item London (Q84) that represents "London" and includes the fact that there's an English Wikipedia article about it, for example. But what is the real-life topic, concept, or subject represented by the item Category:London (Q7149656)? It seems to me to be exactly the same London as represented by Q84. The en:Wikipedia and Commons categories do relate to that same London, even if a particular Commons photo, for example, only shows a small part of it. Ghouston (talk) 02:35, 13 October 2013 (UTC)[reply]
Why is Template:Governance of Greater London (Q6601082) also not represented? Template:Areas of London (Q14347060)? So on and so forth. The reason these aren't connected is because it quite frankly doesn't make sense to connect them. The real-life topic that is represented by those items is the wiki template known as "London", or the category of articles known as "London", not London itself. Why do we have namespaces on a wiki? Because each of the namespaces represents a different class of objects. I cannot describe London using a template. I cannot describe London using a category. I can connect London to other topics using those types of things, but never describe it. (You might argue that connection is enough to understand what London is—if it were, there would be no basis for a wiki. Plainly, people care about the application domain (Q5289798) enough to describe it, so we should treat the main space items as being the actual domain for the purposes of modeling.)
That is fundamentally why trying to merge these things is flawed. The domain of objects described by the main namespace is not the same domain as that of the other namespaces—hence the logical separation on the wikis. --Izno (talk) 22:52, 19 October 2013 (UTC)[reply]
Your argument seems to be that sitelinks should only be used to link to pages that describe the entity in question. That the sitelinks are different to the other Wikidata properties, which can have any random factoid, including the link to a Commons category. Do you also oppose the recently implemented sitelinks to Commons galleries? These galleries don't describe an entity but just have a collection of images about it. The same as a Comons category, as far as I can see. Regarding the two templates you mentioned, they seem to have different topics. Template:Governance of Greater London (Q6601082) is about local government of London and Template:Areas of London (Q14347060) is about an enumeration of subdivisions of London, so neither is about "London". Perhaps the latter template should be connected with the Wikipedia category "Category:Lists of places in London", which doesn't seem to have a wikidata item. Perhaps London (Q84) should somehow be linked with a category full of templates about London. Ghouston (talk) 01:23, 21 October 2013 (UTC)[reply]
However the category full of templates already exists, and is a subcategory of the London category, so another link for that isn't needed. Wikidata entries are created for individual templates I'd say only because people want interwiki links between the equivalent template on different wikis, rather than out of a desire to describe them as real-world entities in their own right. I could just as well describe each different language version of the template as a separate real-world entity. Ghouston (talk) 02:34, 21 October 2013 (UTC)[reply]
Neutral Categories and articles about the same concept should be linked somehow. This can be achieved by merging both in a single item or by using "main article" or "category" properties.--Pere prlpz (talk) 21:29, 16 October 2013 (UTC)[reply]
Weak support i think this approach is very close to wikidata purpose. But problem is in categories on wiki and commons itself, as there are real categories (like buildings in London, transport in london, etc..) and "categories" (group of articles that have something common with subject). --Jklamo (talk) 13:36, 31 October 2013 (UTC)[reply]
Update: Filceolaire asked the development team to comment on the technical implications of this option, here and again here. Lydia has responded, saying that it doesn't seem impossible, but it needs much more investigation and due to other priorities progress seems unlikely for the foreseeable future. --Avenue (talk) 22:14, 9 November 2013 (UTC)[reply]
Strong support - i absolutely love this thing. dual namespaces (cat & main) are good on wikipedias, might be more nuanced on other wikis, but seem absolutely unneeded on wikidata. let's unify. as to how to link, one possible idea, which i favor:
on left sidebar, linking lingo-interwikipedia, data, & sisterwiki (eg wiktionary, travel) mains; and commons categories. all except lang-iw-s should be in a separate grouping, just above the languages, and default-open (this is very important - in my imagination, of average joe types no one clicks to open or close, might not even notice all the stuff there, but if open, very visible and useful, ppl will use), and if exists, wiktionary the most prominent place and commons the second, data the third, rest idc; but perhaps these three with a light separator above others like travel etc. perhaps with mini-icons, but idc. preferably items disableable and these ideal default orders changeable by individual wikis.
in page text, either max one, a main, if exists; or, idc, all of the (if there's more than one), commons galleries; as "properties" or idk what these are called (im a data-noob), i just mean regular entries.
and also in page text, category links everywhere exc. commons, also as just a list.
and from allwiki[xc.commons] categories, and commons galleries, a single link, preferably also at the left sidebar at same place as expected, rather than only an inline template, (having both is also ok), to the same data page. from there on they can if they want move on to whereever they like to.
this seems better, than having two interwiki columns beneath each other on the left sidebar, and that yet better than two completely separate pages, with one-one column, with commonsreversing, and that yet better than same with straight-commons.
one-click navigating inter sisterwiki (exc c) and inter language category pages seems vastly less useful, so not a great loss, while some competing proposals would make the most important navigations a very awkward two-tiered system, or some not even that. and as i said, no other reason here to have wikidata-london, and wikidata-category:london here, than sidebar navigation, and even from a data standpoint its a horribly inelegant, illogical, and "wasteful" (duplication) (tho this last is not an actual issue), and from a global standpoint a bad, unpleasant ui (dual hubs, connected with "properties" only (if at all because of hard automation (no one will make em)), many clicks; and noobs confused); and from the commons standpoint it negates namespace issues altogether, as there is only 1 data page to link to--Aaa3-other (talk) 15:26, 10 November 2013 (UTC)[reply]
not sure if this is the right representation of what i wrote
This is the best option available at presentthat could obtain the most interwiki links directly from Wikidata, without requiring templates etc. It would be even better if Wikidata allowed multiple Commons links to each item, so we don't face an awkward choice when a gallery and category should both link to the same item. Wikidata needs to be flexible enough to support existing interwiki linkages, not to force other projects into doing what's easiest for Wikidata. --Avenue (talk) 03:00, 3 October 2013 (UTC)[reply]
And this option can easily be made "deterministic", if that's really important, by setting rules for which link should be chosen when they clash. Personally I like the idea of choosing the page with the highest traffic, but we could simply prefer galleries to categories, or vice versa. --Avenue (talk) 23:15, 3 October 2013 (UTC)[reply]
I've altered my comment above. I now think that getting interwiki links on Commons pages direct from Wikidata is the problem here, not the solution. --Avenue (talk) 06:24, 11 October 2013 (UTC)[reply]
Comment Such solution can be a safeguard against potential rash destructive changes which would disturb and destroy the current system of links. However, also the current form of interwiki links can be more effectively managed by bots using the On Wikidata templates on Commons and Commons category (P373) property here (interwikis on Commons were managed only manually untill recently). If we would have some support at least by some special parser function, the interwiki links can be displayed directly through the On Wikidata templates and the direct form of the old interwiki links can be replaced and abandoned. --ŠJů (talk) 17:45, 5 October 2013 (UTC)[reply]
Comment for the shorter term it makes sense to only gather data, not more or remove. That's actually what I have been doing when I was importing links to galleries and categories. The Wikipedia pages/Commons galleries that link to the same item and the Wikipedia Categories/Commons categories that link to the same item get the benefits, but the other pages where this is not the case don't get the drawback. Multichill (talk) 09:59, 6 October 2013 (UTC)[reply]
It would make sense to me for this to be the case for gallery <-> article links and category <-> category links, as I'm not even certain those are under dispute. Maybe they are. --Izno (talk) 15:27, 12 October 2013 (UTC)[reply]
Oppose Actually sometimes there are interwikis in both gallery and category. So this solution will result as first-come, first-served. --Jklamo (talk) 13:51, 31 October 2013 (UTC)[reply]
Add to the items both gallery and category as properties (possibly one of them as interwiki and another one as property). Commons galleries and categories will be connected to both Wikipedia/Wikivoyage articles and Wikipedia categories via templates similar to Commonscat template at Wikipedia. If designed properly, the template can show all these things as interwiki.--Ymblanter (talk) 13:48, 3 October 2013 (UTC)[reply]
Comment This solution was mentioned in previous discussions as a provisional way how to support the consistency of interwiki links and bot maintenance of interwiki links as long as Wikidata ignored Commons and gave no support to it. There was created Commons category (P373) property here and On Wikidata template on Commons - the Wikidata property should be complementary to the Commons template (as long as MediaWiki doesn't support a real automatic reciprocity). The On Wikidata was supposed to be upgraded by new functions and ultimately replaced by inbuild MediaWiki functions.
the Commons template On Wikidata allow to analyse consistency of the current interwiki links (assign to the corresponding Wikidata items), allow bots to complete and update the interwiki links and allow bots to check and achieve the reciprocity of the templates toward the Commons category (P373) property and mutually. The template can allow to deal more complicated cases than the limited interwiki system of Wikidata (a link to the definition article, to the list article and to the category together).
the Commons template On Wikidata can replace the interwiki links as soon as we will have a simple parser function for this (prospectively, such parser function would be needed anyway). --ŠJů (talk) 18:17, 5 October 2013 (UTC)[reply]
Comment I actually thought of a solution like that. If such a (temporary) solution could work, it'd have surely my Support, since it could solve both the theoretical and the practical problem, until we can enable phase 2 (structured data) for Commons. Is this possible? --Sannita - not just another it.wiki sysop12:18, 7 October 2013 (UTC)[reply]
"If designed properly, the template can show all these things as interwiki." Do you mean it could show them as interwiki links in the sidebar, where "real" interwiki links usually go?
If so, and if we decide that's what we want to do, how would this interact with existing interwiki links - either from the page markup or from Wikidata? --Avenue (talk) 21:10, 7 October 2013 (UTC)[reply]
I do not know, thi probably depends on the implementation, and I am not a lua expert. I just know one can show on the sidebar basically whatever one wants, we were experimenting with this in Wikivoyage, and now we have a template which takes the parameter from the Wikidata Commonscat property and shows it as a Commons link on the sidebar.--Ymblanter (talk) 04:02, 8 October 2013 (UTC)[reply]
Comment - I'm not precisely certain what this solution is about, but I suspect it would fall out of the most deterministic of the solutions, above, as the implementation of that decision. --Izno (talk) 15:29, 12 October 2013 (UTC)[reply]
Support Linking categories to categories in sidebar and categories to articles using "on Wikipedia" template is a good way to show both kinds of interwikis.--Pere prlpz (talk) 21:11, 16 October 2013 (UTC)[reply]
This option is similar to option "galleries with articles, categories with categories", and also similar to the option "with templates". Basically there will be category-items representing either Wikipedia categories, or Commons categories, or both at the same time whenever possible (NOTE: this kind of items already exists for Wikipedia categories, and some of them already represent both a Wikipedia+Common category). Then the items representing Wikipedia articles would be linked to the items representing categories with topic's main category (P910), and the categories would use the inverse property category's main topic (P301) (NOTE: this is already happening for Wikipedia categories, but Commons categories that have no Wikipedia equivalent still have no item. Solution: create one).
Then we would have:
On Wikidata: sitelinks from the category-item linking either to a single Commons category, or to several Wikipedia-language categories (already happening), or both cases at the same time. From regular items representing Wikipedia articles there would be a sitelink to a Commons gallery only.
On Wikipedia: a template that given the article's item, it would inspect if it is the main article of any given category-item (links to it with p310) and if it has a sitelink to Commons-category. If that is the case it would display the sitelink to the category and to the gallery (which is a normal, single sitelink in the wikidata item of the article). If more than one category-item with a sitelink to a Commons category link to the item using p310, then all those site links are displayed.
On Commons: Here the reverse should happen both for the categories and for the galleries. In the case of categories: a Lua would evaluate if the item representing the category is linked to with p910, if that's the case it will display the language links (Wikipedia sitelinks) of the wikipedia article, the Commons gallery linked from that article-item (1 Commons sitelink), the language links of its own item (if it happens to correspond to a Wikipedia category it might have X category sitelinks).
might need an interface to input the relationship between wikipedia categories, wikipedia articles, commons categories and commons galleries (=technical implementation migth be complex)
Most categories in Commons have no corresponding categories in Wikipedia. We would need to create a large number of additional elements for Commons categories.
main Wikipedia entities (articles) are linked with main Commons entities (categories) only indirectly
for readers: links to service Wikipedia entity (category) is shown in main Commons entity (category)
constraint "one article - one Commons category" is not checked by Wikidata engine, many interwiki conflicts (this is needed at least for links Commons to Wikipedia and for infoboxes in ruwiki and possible another Wikipedias)
technical implementation and user model is too complex
Question Just to clarify, I see this option as being essentially options II and V combined, but with the template side of V fleshed out in more detail, specifying which properties would be used and what the scripts would need to handle (and using Lua in one case instead of templates). Is that a fair summary, or am I missing something? --Avenue (talk) 05:13, 7 November 2013 (UTC)[reply]
Answer Yes, that would be it. The main difference with option II is that this option doesn't assume that there is an exact equivalent between Commons and Wikipedia categories. They can be the same or they can be different and this system can handle both cases. Option V is too vague to evaluate how it compares. --Micru (talk) 11:06, 7 November 2013 (UTC)[reply]
Support As Option II with more implementation details. I think there should be some stronger coupling between Wikidata's article items and category items. Their properties should be shared, or kept only with one type or the other (probably article items), and ideally they can be displayed on the same page. But that is just the display part to simplify the complex database relationships underneath. --Jarekt (talk) 14:42, 8 November 2013 (UTC)[reply]
The English description of Commons gallery (P935) says that it "is suitable to allow multiple link to more gallery pages", but if I understand this option correctly, it would only allow a single gallery to be linked to each namespace-0 item. Why then would P935 be deprecated? --Avenue (talk) 12:43, 9 November 2013 (UTC)[reply]
Question How usual is to have more than one gallery link per item? If it is only one gallery, then it is better to use the sitelink, if it is several, then only p935. The best would be to have some statistics.--Micru (talk) 13:56, 9 November 2013 (UTC)[reply]
One of the proposals outlined at Wikidata:Wikimedia Commons had been omitted from this RfC. I've added it as option III above (in English only, sorry; please translate!). Maybe people will decide it's not feasible, but that should be part of the discussion, not taken for granted. --Avenue (talk) 03:15, 3 October 2013 (UTC)[reply]
Comment This RFC focuses on the question: should Commons interwiki links be changed now that Wikidata has gone live there, and if so, how? This seems a poor forum for that question, which I think should be discussed primarily on Commons. That question also doesn't directly address a range of related issues that are more clearly within Wikidata's remit. For example, should the Wikidata software be configured to allow multiple Commons links per item? Should Wikidata disallow cross-namespace links? How well does the current item structure (e.g. separate items for Wikipedia articles and categories) correspond with and support Commons pages and interwiki links? Can it be revised or expanded to work better, and if so, how? Some of the options above address these sorts of questions, explicitly or implicitly, but it would be better if the RFC clearly included such questions were within its scope. --Avenue (talk) 05:10, 3 October 2013 (UTC)[reply]
I've collected some data on the nature of the interwiki links currently in the sidebar of Commons categories and galleries. I took a random sample of 150 categories and 50 galleries by repeatedly clicking on commons:Special:Random/Category and commons:Special:Random.
Of the 150 categories sampled, I found that 31 had interwiki links, of which 28 were to Wikipedia articles. Just 3 of those categories had a corresponding gallery, of which 1 had interwiki links. Of the 119 categories without interwiki links, 3 had a corresponding gallery, and 2 of these had interwiki links.
Of the 50 galleries sampled, I found that 35 had interwiki links (all to articles). Of those 35, all but 2 had a corresponding category. Of those 33 categories, 17 had interwiki links to articles, 15 had no interwiki links, and just 1 had interwiki links to categories. Among the 15 galleries without interwiki links, all but 3 had a corresponding category. Five of these 12 categories had interwiki links, 4 to articles and 1 to categories.
So only a small proportion of Commons categories have interwiki links to Wikipedia categories (5 out of the 54 categories with interwiki links in the two samples combined, i.e. less than 10%).
Only 4 of these 251 pages had been linked to Wikidata, all by bots, and all already had existing interwiki links specified in the page markup.
Good, those figures should give more accurate proportions than the corresponding ones from my samples. They seem consistent with mine, allowing for sampling error. We're not measuring exactly the same thing, since my figures include pages with interwiki links to non-English Wikipedias and without any enwiki link, but there weren't huge numbers of those.
So there are over 30,000 Commons pages outside the gallery and category namespaces with interwiki links to enwiki? That seems like a lot to me. Could you break that down by other namespaces, please?
I think one important result from my study is the prevalence of gallery/category interwiki clashes (i.e. both linking to articles). About half the galleries with interwiki links had a corresponding category that also linked to Wikipedia articles. Scaling that up using your figures suggests there'd be over 30,000 such clashes. Can you derive a more accurate value for this too? --Avenue (talk) 15:11, 5 October 2013 (UTC)[reply]
I repeat my comment from the previous section. In my opinion, the best way is allowing exactly 2 commons links: one to the category namespace and one to the main namespace (or any other). These 2 links should have different titles in the item structure (for example, "commonswiki" and "commonscatwiki") that will preserve the current absolutely deterministic situation but will avoid the current resctiction on one link. --Emaus (talk) 09:29, 5 October 2013 (UTC)[reply]
It is more essential and urgent to achieve that a WD item should allow two Wikipedia links to every Wikipedia language: one to the article namespace and one to the category namespace. Commons galleries are not structural and are not assumed to be unique, we can have more galleries about identic item. Commons galleries (the most representative gallery and whatever number of other galleries) should be linked rather through a property, as really allow the Commons gallery (P935) property already. The remaining problem is that properties (generally) are not really functionall still and are in the stage of a poor demoversion now. However, you are quite right that links to Commons categories should be clearly distinguished from links to Commons galleries. --ŠJů (talk) 17:58, 5 October 2013 (UTC)[reply]
Support Both links are important. Furthermore, some wikipedias have categories one the same subjects other ones just have an article. For example, Thai wikipedia is expected to have categories on a lot of Thailand towns, but Dutch wikipedia is just expected to have an article on them.
There has been attempts in Commons to use iw for categories and commons:template:on Wikipedia for articles. It works but it is still to be widely adopted. Even using such templates, both links should be stored in Commons.
Please notice that storing both links can help Wikidata and the Wikipedias: we would be just storing the main article for every wikipedia category.--Pere prlpz (talk) 11:53, 12 October 2013 (UTC)[reply]
Support wikicommons galleries and categories should provide links to both wikipedia article and categories. And wikipedia article and categories should provide links to both wikicommons galleries and categories. Liné1 (talk) 06:05, 31 October 2013 (UTC)[reply]
Support ca. all the above +s, (tho personally i never saw too much value in commons gallery-pages (vs cats), and from the other 3 also the commons cat and wiki article seem a bit more important, but these may wary with everyone so we need all 4, its also systematically elegant)--Aaa3-other (talk) 13:39, 10 November 2013 (UTC)[reply]
Trying to control in Wikidata how Commons pages link to Wikipedia stuff doesn't make any sense to me. Wikidata is great for grouping links for different languages on some projects, centralising data and linking to related Commons page(s), but it should not try to do the Commons job, that's why we seem to have so many problems. Linking to Wikimedia projects must be done on Commons, according to Commons policy and Commons user preferences. The simplest and most flexible solution seems to be one where each Commons page references the related Wikidata item(s) from which interwiki links can be automatically taken; we can even imagine several policies for links filtering depending on Commons user preferences: categories to articles only, to categories only, to a mix with categories preferred (my personal choice), etc. That would mean much less useless discussions about what kind of page to link to from a kind of page, much less link copy work by bots, and up to date links. There's no need to make Wikidata more complicated, nor increase the potency of Wikidata weaknesses mentioned by ŠJů (I agee completely with him); wikidata already has (without the commonswiki property) all the properties that Commons needs to be able to link to Wikipedia. All it needs is a function to build a list of Wikimedia project links from a Wikidata object that includes links to categories and articles alike; the result is then filtered on Commons at display time according to policy/user preferences. KISS principle at work, and in line with MediaWiki system simplicity and power. -- Bjung (talk) 08:08, 10 October 2013 (UTC)[reply]
It can work this way, but a property "main article" in every wikidata item on a wikipedia category would be a good way to supply article and category links to Commons.--Pere prlpz (talk) 11:56, 12 October 2013 (UTC)[reply]
Question: Could categories and galleries share always the same name?
I don't know if this has been discussed, but if the any given gallery had the same name as the corresponding category, then only one link is needed in Wikidata. From that only link it is possible to check if it exists as a Gallery, as a Category (same name, different namespace), or as both. Could that work?--Micru (talk) 01:03, 27 October 2013 (UTC)[reply]
I see there is potential in this idea. We can create redirects between singular/plural or non-English/English names. Those redirects can also be useful for preventing accidental duplicates, and work nicely with commons:Commons:HotCat. Though if they are updated manually or by bots, there will be always some inconsistencies. --whym (talk) 12:23, 27 October 2013 (UTC)[reply]
The relation between items and categories and typology of categories were supposed to be well-considered before phase I of Wikidata. Generally, we have several types of categories:
categories of individual subjects: (Category:Moscow is a good example). Generally in singular (I think, even Multichill admits that "Moscow" is not plural). Such categories should be directly linked with their item.
categories of abstract terms: (Category:Velocity is a good example). Generally in singular. Such categories should be directly linked with their item.
simple group categories: (Category:Cities is an example). Generally in plural. Such categories have a close relation to two types of articles: a definition article ("City") and a list article ("List of cities").
combined group categories (and meta-categories): such categories can be possibly alternated with some database tools but should be also kept and cross-wiki linked (through specific Wikidata items). Some of them can have also a close relation to special list articles or overview articles of identic item scope.
Galleries are generally not supposed to be unique. One item can have more galleries in different languages, of different conception etc. Generally, the names of basic galleries correspond to the labels of the corresponding item. However, Wikidata should distinguish links to existing categories, links to existing articles and links to existing galleries even though all the linked names can be identic and pertaining to identic item. --ŠJů (talk) 13:29, 28 October 2013 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Oppose this approach would support current Commons categories -> Wikipedia articles links; however it would make a mess for links of commons gallery pages and wikipedia categories. Currently interwiki links from commons are quite unpredictable you might find Category -> article link or Category -> Category link. There is no need to copy this unpredictability to wikidata. We run into software limitation issues, those should be addressed by correcting software and not by using the software in unpredictable way. --Jarekt (talk) 19:38, 2 October 2013 (UTC)
Comment The diagram on the right is a bit misleading, because in most cases the Wikipedia category and its Wikidata item won't exist. In these cases it makes more sense to link to the exising Wikidata entry and use its interwiki links than to create a new one that just says that the Commons category exists. In the other cases, where there is a Wikipedia category, you should have the choice of linking the Commons category to one wikidata item or the other, depending on which is a better match. If the two wikidata items actually refer to the same thing (except that one links articles and the other categories), then I'd prefer that they were combined, as in option 3. Ghouston (talk) 23:15, 3 October 2013 (UTC)
Support This reflects the reality today on Commons and is the most logical/practical solution (but the be fair maybe not the best semantic solution). Furthermore I will support III. Restructure Wikidata items to make it possible to link pages, categories, and galleries with 1 Wikidata item. Raymond (talk) 09:46, 4 October 2013 (UTC)
Strong oppose.
Weak support Moving support to VI. The Anonymouse (talk) 16:43, 7 November 2013 (UTC) This is, in my opinion, the simplest, most consistent solution. The entire problem is wanting to modify the way Wikidata is structured to fit Commons's needs. Namespaces should be linked with each other, regardless of their supposed importance.
Strong support.
Neutral Categories and articles about the same concept should be linked somehow. This can be achieved by merging both in a single item or by using "main article" or "category" properties.--Pere prlpz (talk) 21:29, 16 October 2013 (UTC)
Oppose this is the worse of all 3 options making wikidata non-deterministic and unpredictable. --Jarekt (talk) 19:40, 2 October 2013 (UTC)
Question Just to clarify, I see this option as being essentially options II and V combined, but with the template side of V fleshed out in more detail, specifying which properties would be used and what the scripts would need to handle (and using Lua in one case instead of templates). Is that a fair summary, or am I missing something? --Avenue (talk) 05:13, 7 November 2013 (UTC)
Answer Yes, that would be it. The main difference with option II is that this option doesn't assume that there is an exact equivalent between Commons and Wikipedia categories. They can be the same or they can be different and this system can handle both cases. Option V is too vague to evaluate how it compares. --Micru (talk) 11:06, 7 November 2013 (UTC)
Question How usual is to have more than one gallery link per item? If it is only one gallery, then it is better to use the sitelink, if it is several, then only p935. The best would be to have some statistics.--Micru (talk) 13:56, 9 November 2013 (UTC)
Comment This RFC focuses on the question: should Commons interwiki links be changed now that Wikidata has gone live there, and if so, how? This seems a poor forum for that question, which I think should be discussed primarily on Commons. That question also doesn't directly address a range of related issues that are more clearly within Wikidata's remit. For example, should the Wikidata software be configured to allow multiple Commons links per item? Should Wikidata disallow cross-namespace links? How well does the current item structure (e.g. separate items for Wikipedia articles and categories) correspond with and support Commons pages and interwiki links? Can it be revised or expanded to work better, and if so, how? Some of the options above address these sorts of questions, explicitly or implicitly, but it would be better if the RFC clearly included such questions were within its scope. --Avenue (talk) 05:10, 3 October 2013 (UTC)