If you want Commons' community opinion, you'd better see commons-l. (CC'd)
-- Sent from Android --
2015. 9. 30. 오전 6:19에 "Jane Park" <janepark(a)creativecommons.org>님이 작성:
> Hi everyone,
> I lead platform work
> <https://github.com/creativecommons/platform-initiative> at Creative
> Commons. As part of that work, we are exploring the potential of a standard
> field in EXIF that could make attribution and license info more sticky
> across the web. We are currently in the research phase -- talking to major
> image hosting platforms (and platforms that read and ingest images) about
> what kinds of image metadata they read and retain. Zhou and his engineering
> team at Wikimedia directed me to this list as I am seeking feedback from
> the Wikimedia community.
> Ultimately, we want to make it easier for platforms to display provenance
> and license info -- increase the likelihood that when a user lands on an
> image, they know who created it and what license to use it under. For
> example, images from Wikimedia Commons may get tweeted, but the image
> metadata is not retained in tweets. How can we work with platforms to use
> the same metadata standard so that info can be retained across them?
> Since we are just in the research phase now, I welcome your thoughts on
> Wikimedia Commons' and Wikipedia's own uses of image metadata. Specifically:
> 1. The most common image metadata standards we know about are EXIF and
> XMP. Which does Wikimedia primarily read and retain? Are there others that
> are more widely used?
> 2. Which standard does Wikimedia prefer? What would be easiest to
> implement? for Wikimedia, but also for the platforms that Wikimedia
> interfaces with. Aka, what are the pros and cons of each?
> Lastly, welcome any general thoughts about the feasibility and need for
> such a project.
> Jane Park
> Creative Commons | Los Angeles
> Make a donation to support CC in 2015: http://bit.ly/supportcc2015
> Multimedia mailing list
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
> 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.
> 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:
>> 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
>> 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
>> 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,
>> Wikidata mailing list
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)».
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.
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
> >> 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?
> Wikidata mailing list