Wikidata:Requests for comment/Category commons P373 and "Other sites"
An editor has requested the community to provide input on "Category commons P373 and "Other sites"" 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.
This request aims to standardize the model about Commons catégory, especially for items of the french heritage monuments wikiproject, but its conclusion could be generalized as the problem is project wide.
If a commons cat (Commons category (P373)) is set and if in "other sites" Commons is not, can me put this category in abscence of a wikipage ? (example of a page and of a catégorie)
Some users adds categories, others removes them.
The last discussion about this is Wikidata:Requests for comment/Commons links, but it begins to be a little old. Its conclusion were to wait until the devteam amended the software, but nothing moved on the devteam side. Maybe its time to reopen the question as it is unlikely that this will change rapidly.
@Lea Lacroix (WMDE): Any comment on this ?
DiscussionsEdit
- RTFM Wikidata:Requests for comment/Commons links. Visite fortuitement prolongée (talk) 20:06, 20 June 2015 (UTC)Reply[reply]
- @Visite fortuitement prolongée: C'est certainement pas un manuel, c'est une RfC, et c'est clairement ultra visible. C'est quoi la conclusion ? C'est dispo sur une autre page du site plus visible ? Parce que bon, ça fait un an et demi et on voit toujours rien venir ... TomT0m (talk) 16:57, 21 June 2015 (UTC)Reply[reply]
- +1 avec TomT0m, on voit bien que les points I et II ont globalement eu le même nombre de votes et au final chacun fait comme il lui plaît. Quant au point III qui a été plébiscité, à ma connaissance, absolument rien n'a été fait… Cdlt, VIGNERON (talk) 18:00, 26 June 2015 (UTC)Reply[reply]
I think it is waste of patience to expect that Wikimedia Commons ever will create categories for every entity in the universe (Q1) and beyond. sv:Junsele landskommun, sv:Junsele socken, sv:Junsele församling and the future sv:Junsele distrikt are all Swedish adminstrative entities who cover almost exactly the same area. I do not expect Commons to create catogories for all of them. Instead there is a category for the main populated place and namesake of all these entities. Wikimedia Commons is about files, not about much more. Almost any file that can be used to illustrate the civil parish, can be used to illustrate the district, the municipality or the parish. And since I do not expect that it ever will be possible to connect one page in Commons, with more than one item here, I think P373 have to stay as a solution. -- Innocent bystander (talk) 07:15, 25 June 2015 (UTC)Reply[reply]
- @Innocent bystander : that doesn't at all the question. « Wikimedia Commons is about files, not about much more. » If it was really true there wouldn't be this big how-to-link-to-Commons problem. Beside files, Commons has a lot of categories and some galleries (30 times less). The question is « when there is no gallery, can we put the category instead ? » If we refer to Wikidata:Requests for comment/Commons links, it's a compromise between point I and point II : « Articles with galleries if exist, if else article with categories. » PS: your exemple is too specific and not representative of how Commons or Wikipedias are structured.
- Personnaly, I think there is something wrong with the whole model, not only the categories but how all the namespaces are not dealt by wikidata.
- Cdlt, VIGNERON (talk) 18:00, 26 June 2015 (UTC)Reply[reply]
- @VIGNERON: On Wikipedia and Wikidata, we are very specific to describe if something is located on the island of Iceland or in the country of Iceland. If a picture of a house is located in the country or on the island, is not a big deal for the users at Commons. It's possible that there are two categories for Iceland in this specific case, but normally there isn't. My example describes the extreme situation in Sweden, who has a long range of administrative entities, with almost the same size and boundaries. But they have very different administrative purpose and history. Therefor, we have specific WP-articles about each of them. But it is not the purpose of Commons to describe such things, the hierarchy of categories are therefor much more simple than the article-set on Wikipedia. The exception is the "categories by year"-tree, that is much more specific on Commons than on Wikipedia. (Another big difference is that on Commons, Wikimedia-users can be regarded as Authors. If the file-namespace would have been included here, it should have be necessary to include the user-namespace here at Wikidata.)
- To make it possible to handle these big differences between Commons and Wikipedia, I think it is necessary to keep P373, to solve the interwiki-asymmetry.
- If we should match ns:0@Commons with ns:0@Wikipedia is another question. I do not have a simple answer here. Interwiki can be solved by the help of topic's main category (P910) and category's main topic (P301) when we have Arbitrary Access on Commons and all of Wikipedias, but I think that would be counterintuitive for the users at Commons and Wikipedia. We are used to regard ns:Category as the main namespace on Commons (when file-namespace is excluded). If we insist to match ns:0@Commons with ns:0@Wikipedia, we have to be prepared to fight an eternal war against the intuition of the users on WP and Commons. How many among us are prepared to fight that eternal war? We can set up a policy on Commons, on every Wikipedia and here. But as long as we accepts new users and we have a counterintuitive policy, there will be complaints and unrest.
- I do not know how many of the newbies, who even know about the Gallery-namespace on Commons. And to be honest, I do not know if many users on Wikipedia care about it at all. I have never seen any link to it on WP, and users on Wikipedia still make local Galleries on Wikipedia with their own preferred set of files. I therefor think that the matching of ns:0@Wikipedia with ns:category@Commons should be the first choise even when there exists a Gallery. How the Gallery-namespace should be linked here, is also a headach. I do not have an answer to that today. -- Innocent bystander (talk) 06:31, 27 June 2015 (UTC)Reply[reply]
- Galleries? What about Property:P935? --Jklamo (talk) 13:37, 30 June 2015 (UTC)Reply[reply]
- As you can see, Wikidata:Requests for comment/Commons links was closed with some conclusion, but there was no consensus in fact. As result conclusion of that Rfc is widely ignored by lot of wikidata users (including me) and by majority of commons users. --Jklamo (talk) 13:37, 30 June 2015 (UTC)Reply[reply]
- Sure. NP. I think it's already being done. --- Jura 10:49, 28 August 2015 (UTC)Reply[reply]
- I had hope that the Commons-linking problem could be solved through category's main topic (P301). If a category-item here has P301, I expect it to be not really troublesome to have the sitelinks at the P301 target item presented as interwikilinks (seperate section of the categories of course) at Commons. I think that would take away the problems, being a problem at commons rather than here. But I am not capable of implementing that. Lymantria (talk) 08:39, 14 November 2015 (UTC)Reply[reply]
- I agree. There is no real good reason to treat Commons categories differently from any other category. We should create items for commons category if there is no wikimedia category item for the subject, and link them with "Category"/"subject of the category" property pair. author TomT0m / talk page 19:39, 15 November 2015 (UTC)Reply[reply]
- Is this a theoretical point of view or do you have any specific categories in mind? --- Jura 20:26, 15 November 2015 (UTC)Reply[reply]
- I'm not much into commons category, so it's a theorical point of view. Anyway, since it seems annoyingly complex to be solved by community and keep coming over I suggest what seems to me the less complex solution. I know this just add an option in the end but, pardon my french fuck that useless complexity induced by searching an impossible concensus because people fears whatever they fear because of the history of commons, this is unreadable to outsiders. Let's keep things simple on the conceptual point of view, we can manage commons category items. author TomT0m / talk page 20:35, 15 November 2015 (UTC)Reply[reply]
- Well, wikisource is even more complex .. there you drive directly into the wall with your namespace 0=0 approach. --- Jura 12:27, 17 November 2015 (UTC)Reply[reply]
- I agree common files need to be handled some way differently (although ... I would not oppose having them here. This would speed up stuff and relieve the dev team of work that could happen not before a long time, this could be a not that bad compromise) , however Wikisource does seem not that complex, we mainly have works and part of works, nothing we can't deal with. It's a question of number of items. author TomT0m / talk page 14:18, 17 November 2015 (UTC)Reply[reply]
- Well, wikisource is even more complex .. there you drive directly into the wall with your namespace 0=0 approach. --- Jura 12:27, 17 November 2015 (UTC)Reply[reply]
- I'm not much into commons category, so it's a theorical point of view. Anyway, since it seems annoyingly complex to be solved by community and keep coming over I suggest what seems to me the less complex solution. I know this just add an option in the end but, pardon my french fuck that useless complexity induced by searching an impossible concensus because people fears whatever they fear because of the history of commons, this is unreadable to outsiders. Let's keep things simple on the conceptual point of view, we can manage commons category items. author TomT0m / talk page 20:35, 15 November 2015 (UTC)Reply[reply]
- Is this a theoretical point of view or do you have any specific categories in mind? --- Jura 20:26, 15 November 2015 (UTC)Reply[reply]
- I agree. There is no real good reason to treat Commons categories differently from any other category. We should create items for commons category if there is no wikimedia category item for the subject, and link them with "Category"/"subject of the category" property pair. author TomT0m / talk page 19:39, 15 November 2015 (UTC)Reply[reply]
- I had hope that the Commons-linking problem could be solved through category's main topic (P301). If a category-item here has P301, I expect it to be not really troublesome to have the sitelinks at the P301 target item presented as interwikilinks (seperate section of the categories of course) at Commons. I think that would take away the problems, being a problem at commons rather than here. But I am not capable of implementing that. Lymantria (talk) 08:39, 14 November 2015 (UTC)Reply[reply]
- I agree with @VIGNERON: above, something is wrong with the whole model. Before anything else, Wikidata should have a W: namespace and accept some degree of specialisation of its database towards the Wikimedia projects. The current universalist approach leads to absurd contradictions such as all the “instance of (P31) : Wikimedia category (Q4167836)” elements, which are things we certainly don't want in the main space of a universalist database. They are an aberration to begin with. Second, the 1:1-link principle should be dropped ; this would have been a mess without Wikidata but centralization made it possible to have more relevant systems. Of course we want to link c:Category:November 2015 Paris attacks to both w:en:November 2015 Paris attacks and w:en:Category:November 2015 Paris attacks, and both c:Pablo Picasso and c:Category:Pab~lo Picasso to w:en:Pablo Picasso. There are also plenty of cases where one Wikipedia article corresponds to several Wikidata items, that's the redirection issue. The 1:1-link principle is terrible, absolutely inappropriate. Tinm (talk) 16:28, 16 November 2015 (UTC)Reply[reply]
- We could do with a sitelink per site per namespace, of course, but as the devteam has other priorities unless you find people to conceptualize, discuss and implement that in cooperation with them this won't happen. So this is out of scope of this discussion right now. author TomT0m / talk page 17:20, 16 November 2015 (UTC)Reply[reply]
- I know that very well. It was actually what I argued, that thinking hard about “how to add new exceptions in the data model but not too dirtily” was a waste of time, and that a quicker and better solution (solving this and other issues) can be achieved by stepping back. Making the Wikidata's data model cleaner should be in the devteam priorities — that's of course my egoist opinion as an anonymous contributor. Tinm (talk) 18:52, 16 November 2015 (UTC)Reply[reply]
- You must understand that dealing with other projects or namespaces was not at all in the initial plan of the devteam, although they after community demand spent already quite some time on this. On the other hand some key features such queries and quantity with units had to wait until some initially secondary points were addressed. We must understand that the devteam has still a lot on his plate. author TomT0m / talk page 19:49, 16 November 2015 (UTC)Reply[reply]
- If interwiki issues don't have priority, so be it, and I can understand that. I'm only saying that if this
W:
namespace existed, not only would the Wikimedia projects-unrelated part of the database be cleaner, but everything regarding interwikis would become much simpler. If you ask me, asking the devteam to implement little exceptions is a waste of their time, because it'll only lead to asking them more of these little exceptions. Tinm (talk) 21:34, 16 November 2015 (UTC)Reply[reply]- To be honest, that sounds to me that instead of serving the community, the dev team serves its own goals. Unfortunately, that would be on par with what I have come to expect, but this is really not the way it should be. We spent thousands of hours working with a sub-optimal model that needs to be fixed later, because the dev team does not understand the real, day-to-day needs of the project and community? --Srittau (talk) 08:06, 9 December 2015 (UTC)Reply[reply]
- If interwiki issues don't have priority, so be it, and I can understand that. I'm only saying that if this
- You must understand that dealing with other projects or namespaces was not at all in the initial plan of the devteam, although they after community demand spent already quite some time on this. On the other hand some key features such queries and quantity with units had to wait until some initially secondary points were addressed. We must understand that the devteam has still a lot on his plate. author TomT0m / talk page 19:49, 16 November 2015 (UTC)Reply[reply]
- I know that very well. It was actually what I argued, that thinking hard about “how to add new exceptions in the data model but not too dirtily” was a waste of time, and that a quicker and better solution (solving this and other issues) can be achieved by stepping back. Making the Wikidata's data model cleaner should be in the devteam priorities — that's of course my egoist opinion as an anonymous contributor. Tinm (talk) 18:52, 16 November 2015 (UTC)Reply[reply]
- We could do with a sitelink per site per namespace, of course, but as the devteam has other priorities unless you find people to conceptualize, discuss and implement that in cooperation with them this won't happen. So this is out of scope of this discussion right now. author TomT0m / talk page 17:20, 16 November 2015 (UTC)Reply[reply]
- The easy wikidata solution is to make it a Wikipedia problem.
- Allow Wikidata to have multiple links to the same wiki.
- Put links to Category and list pages on the same wikidata item as the corresponding wikipedia article
- Where a wikipedia has duplicates that have't been merged or multiple versions of the same article in different dialects link them to the wikidata item for that topic
- Put Commons galleries and categories on the same wikidata item as well
- tag duplicate links (category, duplicate, dialect etc.) to make clear why they exist (We could probably use badges for this)
- Rewrite the wikipedia language links routine (in wikidata client) to cope with this change. Use the tags to help with this.
- This will get rid of all the "Category" items from wikidata
- It will also make it simple for Commons Category pages to link to wikipedia articles or to wikipedia categories - Commons gets to choose, it is no longer part of the structure.
- At least that is what I would do. Joe Filceolaire (talk) 03:05, 30 November 2015 (UTC)Reply[reply]
- This still seems like the best solution. It is also conceptionally the best, in my opinion. If I understood correctly, this also was considered the best solution in the last RFC. But it needs software support, and the development team doesn't seem to be in a great hurry to implement that solution. --Srittau (talk) 07:49, 9 December 2015 (UTC)Reply[reply]
- My assumption is that the Wikidata developers are still working on option VI from Commons links, however they are still at the first step of implementing Arbitrary access on Commons. Apparently the feature doesn't work yet on multi-lingual wikis. After that they'd still have to develop the templates, and presumably a bot to fix all those cross-namespace links that now exist. In the meantime, it seems pointless for people to revert site links from Commons categories to article-type Wikidata items manually. Perhaps this could be an outcome for this RFC: tolerate the cross-namespace links until Wikidata support on Commons is fully implemented. Asking for the outcome of the previous RFC to be changed will probably either fail to gain enough support, or just be ignored by the developers. Ghouston (talk) 01:48, 12 December 2015 (UTC)Reply[reply]

- I also think option VI from Commons links is the most sensible, but we are still waiting on arbitrary access to start using wikidata on Commons. Some thoughts:
- I do not think we need to "allow Wikidata to have multiple links to the same wiki" as we can use properties to have the same effect.
- I think we should encourage people and bots to be adding and maintaining properties to Commons pages, like
- Property:P373 to Commons categories
- Property:P935 to Commons galleries
- Property:P1472 to Commons Creator pages
- Property:P1612 to Commons Institution pages
- Also links to other Wikidata pages are essential
- Property:P910 to Wikidata category page
- Property:P301 to Wikidata article page
- Site links to Commons, in my opinion, should not cross namespace lines. However they become less relevant as they become less deterministic.
- I assume that once arbitrary access is activated we will write templates or gadgets for Commons categories which will be able to look up wikidata and automatically add interwiki links to wikipedia articles and to wikipedia categories, if present. I imagine something like Other projects sidebar on Wikipedia. This will be a great improvement over current situation where you do not know if clicking interwiki link in the category page will lead you to wikipedia article of category.
- I think we could use greater integration of wikidata article and category pages. They should share properties so I can access date of birth of someone the same way from article and from category namespace. Otherwise we are running a risk that some will start adding properties to Category pages on Wikidata and those will have to be kept in synch with the same properties on the article page. Property:P910 and Property:P301 are good but not enough.
- I do not think we should be creating a category page on wikidata for Commons categories that do not have equivalent categories on wikipedias
- --Jarekt (talk) 16:39, 31 December 2015 (UTC)Reply[reply]
- I am not too happy about having "category" items, so I would prefer if we could find a way to minimize them, instead of encouraging them. While we will always need some kind of "structural" items, having too many of them makes Wikidata more of an "ontology of the Mediawiki projects" than a general "ontology of the world", limiting its usefulness and making it harder to work with. In my mind, generalizing the way sitelinks work, so they fulfill Mediawiki crosswiki needs (e.g. by having the ability to reference categories, articles, galleries, Wiki travel guides, etc.) is preferable to building a fairly complex and hard to maintain "network" of relationships using explicit items and properties. Of course, we would need the buying and support of the dev team to support such a scheme. (How are sitelinks maintained in the data model? Are they even part of it or "hardcoded" in some way for each item?) --Srittau (talk) 19:12, 31 December 2015 (UTC)Reply[reply]
- I like the "ontology of the world" idea as it seems closer to my idea of single set of properties (instead of the same properties for category and article items. I also now see that this is not too far from user:Tinm, user:TomT0m and user:Joe Filceolaire idea that category and article items for the same subject should be merged by allowing multiple sitelinks per project (possibly one per project per namespace). I guess those are all different technical implementations of the same idea. it seems to me that many people seem to be proposing roughly similar approach which is rather different from the current approach. So what should we do next? --Jarekt (talk) 21:35, 31 December 2015 (UTC)Reply[reply]
- That "winning" entry from the previous RFC, VI. Make use of "topic's main category (P910)", does seem to require that Commons categories are always linked to category items in Wikidata if they are going to have sitelinks, so will require creating a lot of new category items that are only linked from Commons.
- As for what to do now, I'd suggest this RFC could have a couple of votes 1) A new vote on what option people prefer from the previous RFC, since the outcome was determined by addendums that ignored the original vote counting. 2) a vote on what should be done with cross-namespace links from Commons to Wikidata in the meantime: should they be tolerated and fixed up later with a bot when Commons support is properly added, or are people right to be reverting them? Ghouston (talk) 07:13, 5 January 2016 (UTC)Reply[reply]
- Or maybe just wait for arbitrary access activation on Commons. That will make Wikidata have some use on Commons (other than interwiki links for templates, which seems to me the main use so far), and hopefully will encourage developments of tools that rely on Wikidata. With those tools the problem might resolve itself if someone comes out with a way to add interwiki links in some way acceptable to Commons through Java scripts or templates. May be by modifying MediaWiki:InterProject.js and embedding Q-code to the article-wikidata page in some template. Once arbitrary access is activated, will there be a way to query wikidata from a category page for article-wikidata page that points to it through Property:P373 page? --Jarekt (talk) 05:31, 11 January 2016 (UTC)Reply[reply]
- I like the "ontology of the world" idea as it seems closer to my idea of single set of properties (instead of the same properties for category and article items. I also now see that this is not too far from user:Tinm, user:TomT0m and user:Joe Filceolaire idea that category and article items for the same subject should be merged by allowing multiple sitelinks per project (possibly one per project per namespace). I guess those are all different technical implementations of the same idea. it seems to me that many people seem to be proposing roughly similar approach which is rather different from the current approach. So what should we do next? --Jarekt (talk) 21:35, 31 December 2015 (UTC)Reply[reply]
- I am not too happy about having "category" items, so I would prefer if we could find a way to minimize them, instead of encouraging them. While we will always need some kind of "structural" items, having too many of them makes Wikidata more of an "ontology of the Mediawiki projects" than a general "ontology of the world", limiting its usefulness and making it harder to work with. In my mind, generalizing the way sitelinks work, so they fulfill Mediawiki crosswiki needs (e.g. by having the ability to reference categories, articles, galleries, Wiki travel guides, etc.) is preferable to building a fairly complex and hard to maintain "network" of relationships using explicit items and properties. Of course, we would need the buying and support of the dev team to support such a scheme. (How are sitelinks maintained in the data model? Are they even part of it or "hardcoded" in some way for each item?) --Srittau (talk) 19:12, 31 December 2015 (UTC)Reply[reply]
- I mostly agree with User:Filceolaire's comments above. I regularly work at the intersection between Wikidata, Commons and Wikipedia, adding commons categories to Wikipedia articles, uploading photos to Commons (and often creating new categories for them), and populating Wikipedia infoboxes with Wikidata values. I particularly find the interwiki links between Commons categories and Wikipedia articles through Wikidata very valuable, and very timesaving. I mostly find Commons gallery pages to be a waste of time, as they frequently haven't been edited this decade, but I gather some people find them useful.
- So I really like the idea of being able to link to both galleries and categories using the 'other sites' option (or, better, a dedicated Commons option), because:
- It avoids the whole debate about whether it's best to link to galleries or categories, and it would mean that interwikis are available from both on Commons.
- It would put an end to the 'commons category' property that links to the categories, often in duplication to the 'other sites' links, but doesn't carry over the interwiki links. (Although, this is useful for linking to Commons categories in infoboxes, so this might need a better way to access the other site links in Wikipedia articles).
- Options that wouldn't work include:
- The status quo. You risk edit wars about whether categories or galleries are the better ones to link to from 'Other sites', and you keep the unnecessary duplication of information.
- Saying 'no cross-namespace linking'. There are frequently only commons categories corresponding to Wikipedia articles (e.g., individual buildings/structures) without commons galleries (and a systematic creation of such galleries is unlikely to happen, and probably not desirable), so this approach is shooting the projects in the foot.
- Counting on 'arbitrary access' to fix everything. It won't help with interwikis, and it's more complex to handle, making it more difficult to implement in practice - it's better to have a simpler solution if possible.
- In the long run, merging Commons and Wikidata might be the best ultimate solution, with Commons categories and pages replaced by Wikidata items and rankings respectively, but that's probably still a number of years of development work away. ;-) Thanks. Mike Peel (talk) 19:36, 16 February 2016 (UTC)Reply[reply]
- I also often work with the project intersections and my own observations are that we need a seperate section just for Commons rather than dumping it into the "Otherwiki" category. If we simply allow both galleries and categories to be linked would be an easy fix but we should also allow linking to the Creator and Institution namespaces here that commons uses as well. If we are going to link to all 4, then it makes a lot more sense to link them all to the appropriate Wikidata item via a commons specific group box than filling to Other wiki group.Reguyla (talk) 17:14, 7 April 2016 (UTC)Reply[reply]