I think this subject should also be discussed on the Commons mailing list,
as this plan is to demolish the navigational structure of Commons.
2015-08-27 15:03 GMT+02:00 Romaine Wiki <romaine.wiki(a)gmail.com>:
> No we have not a clear policy on only linking sitelinks to categories if
> the item itself is about a category. So not let's not break that.
>
> You suggest to break down almost the complete navigational structure
> Commons has in relationship with Wikipedia, and makes it possible to find
> articles that are about the same subject as the category. Without it
> becomes almost impossible to identify a category on Commons to be related
> to an article in Wikipedia.
> Sorry, but your proposal is insane and making the navigational situation a
> thousand times worse. And does it make anything better? No, totally not.
> Only the opposite: worse.
>
> Wikidata is currently heavily used to connect categories on Commons to
> articles on Wikipedia. This so that interwikilinks are shown on the
> category on Commons to the related Wikipedia article. This for navigational
> purposes but also to uniquely identify categories on Commons to articles on
> Wikipedia and items on Wikidata.
>
> How nice Commons galleries are giving an overview, they are crap in
> speaking of navigational purposes. For every subject a category on Commons
> is created and used and the Commons categories form the backbone to media
> categories.
>
> It has been pointed out for a long time that the linking situation on
> Commons is problematic and this is a software issue, not a user side issue.
> This consists out of:
> * There can only be added one sitelink to an item.
> * If no sitelink added (but only added as property), a Commons category
> can't show the interwikilinks.
> * If a category and an article on Wikipedia/etc exist for a subject, only
> one of them can be shown on the Commons category.
>
> The annoying part is that some large wikis, especially the English
> Wikipedia, creates too many categories that are not created on other
> Wikipedias. This causes that categories on Commons are only linked to a
> category on Wikipedia, which is useless for most other wikis and on Commons
> we miss an interwikilink to the related article.
>
> A gallery on Commons is a great way as alternative to show images, but is
> not suitable for navigational purposes, as that requires a much higher
> coverage and being a backbone everything relies on. On Commons only
> categories have that function. A counter proposal makes more sense: no
> Commons galleries as sitelinks any more and having Commons galleries only
> as property added.
>
> But this only solves a part of the problem: on Commons I would like to see
> somehow that both the related category as the related article are shown.
> Example: on the Commons category for a specific country both the country
> category on Wikipedia is linked as the article on Wikipedia is linked.
>
> Something I have been wondering about for a long time is why there are 2
> places on an item where a Commonscat is added. I understand the development
> and technical behind it, but this should not be needed.
>
> So the developers of Wikidata should try to find a way to show both groups
> of interwikilinks on categories on Commons.
>
> As long as this is not resolved in software, this problem of 2 items both
> strongly related to a Commons category keeps an issue.
>
> Romaine
>
>
>
>
>
> 2015-08-27 11:29 GMT+02:00 James Heald <j.heald(a)ucl.ac.uk>:
>
>> A few days ago I made the following post to Project Chat, looking at how
>> people are linking from Wikidata items to Commons categories and galleries
>> compared to a year ago, that some people on the list may have seen, which
>> has now been archived:
>>
>>
>> https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2015/08#Trends_…
>>
>>
>> A couple of headlines:
>>
>> * Category <-> commonscat identifications :
>>
>> ** There was a net increase of 61,784 Commons categories that can now be
>> identified with category-like items, to 323,825 Commons categories in all
>>
>> ** 96.4% of category <-> commonscat identifications (312,266 items) now
>> have sitelinks. This represents a rise in sitelinks (60,463 items)
>> amounting to 97.8% of the increase in identifications
>>
>> ** 80.0% of category <-> commonscat identifications (259,164 items) now
>> have P373 statements. This represents a rise in P373 statements (8,774
>> items) amounting to 14.2% of the increase in identifications
>>
>>
>> * Article <-> commonscat identifications :
>>
>> ** There was a net increase of 176,382 Commons categories that can now be
>> identified with article-like items, to 884,439 Commons categories in all
>>
>> ** 23.4% of article <-> commonscat identifications (207,494 items) now
>> have (deprecated) sitelinks. This represents a rise in sitelinks (112,595
>> items) amounting to 63.8% of the increase in identifications.
>>
>> ** 91.3% of article <-> commonscat identifications (807,776 items) now
>> have P373 statements. This represents a rise in P373 statements (110,727
>> items) amounting to 62.8% of the increase in identifications
>>
>>
>> * In addition, a recent RfC showed considerable confusion as to what
>> actually was the current operational Wikidata policy on sitelinks to
>> Commons:
>>
>>
>> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Category_common…
>>
>>
>> In view of the trends above; and the need for predictability and
>> consistency for queries and templates and scripts to depend on; and
>> particularly in view of the apparent confusion as to what the operational
>> policy currently actually is, can I suggest that the time has come for a
>> bot to monitor all new sitelinks to Commons categories,
>> * adding a corresponding P373 statement if there is not one already, and
>> * removing the sitelink if it is from an article-like item to a
>> commonscat.
>>
>>
>> I believe we have clear policy on only sitelinking commons categories to
>> category-like items, and commons galleries to article-like items; but there
>> is currently confusion and unpredictability being caused because these
>> relationships are not being enforced -- breaking scripts and queries.
>>
>> It's time to fix this.
>>
>>
>> All best,
>>
>> James.
>>
>>
>> _______________________________________________
>> Wikidata mailing list
>> Wikidata(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>
>
Luca Martinelli, 30/08/2015 12:03:
> Am I the only one that thinks that jheald's .js is a temporary solution?
> Am I the only one that actually appreciate his attempt at solving a
> *practical* problem by providing a *practical* solution,
It might be a practical solution, but I don't understand what it solves:
what's the practical problem?
Quoting from the project chat, the problem to me seems this: «2.4
millions categories are not connected to corresponding Wikipedia
articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)».
Nemo
As I wrote before, that thought is too simple. You only say that a zero
belongs to a zero, and a two belongs to a two, then you only describe the
type of page, but you ignore the subject of a page. That subject matters
much more than the namespace number.
Especially Wikinews is a wrong example, as most categories on Commons do
not have a 1 to 1 relationship with Commons.
However, articles on Wikipedia do have mostly a 1 on 1 relationship with
categories on Commons.
Romaine
2015-08-28 17:09 GMT+02:00 Luca Martinelli <martinelliluca(a)gmail.com>:
> 2015-08-28 12:09 GMT+02:00 Romaine Wiki <romaine.wiki(a)gmail.com>:
> > And I agree completely with what Revi says:
> >> Wikidata ignores this Commons' fact by trying to enforce ridiculous
> rules
> >> like this.
>
> It's not such a ridiculous rule, if you think of the rationale behind
> it: if gallery = ns0 and category = ns2, linking ns0 <--> ns2 in the
> same item is IMHO not a rational thing to do (not even for Wikinews if
> you ask me, but I'm digressing).
>
> So the *practical* problem that we have to address is the list of
> links in the left column. We really don't have any possibilty to
> exploit P373 in any way, not even with a .js, to fix this?
>
> L.
>
> _______________________________________________
> Wikidata mailing list
> Wikidata(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>