Commons-l August 2007

commons-l@lists.wikimedia.org

55 participants
42 discussions

{{EXIFDATE}}
by Magnus Manske 20 Aug '07

20 Aug '07

For a tool that tries to fill in {{Information}} templates on commons based on the current, unstructured text, I have it fill in the "Date" parameter from the EXIF data of the image, if available. I just thought: How about a new magic word, {{EXIFDATE}}, that would extract EXIF data from the image? It could be used in {{Information}} as a default in case no "Date" parameter is provided. {{EXIFDATE}} would return blank on namespaces other than "Image:", of course, and for files that have no EXIF data. There could be {{EXIFTIME}} and {{EXIFTIMEDATE}} as well, but that would be luxus :-) Shouldn't be too costly for the parser (on image pages, image data will be needed anyway). Anyone opposed? Anyone willing to code? ;-) Cheers, Magnus

3 2

State of the projects and other tips on how to make sure projects are well known (was: All about Wikimania...)
by Delphine Ménard 20 Aug '07

20 Aug '07

I like clear threads. On 8/12/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote: > know about Wikipedia, so they ignore the rest. So then the thing to do > is change the journalists. :) As Florence mentionned, this has been done, especially in countries where 1) there is a chapter 2) there is a strong figure in one of the projects but no chapter 3) there is both In short, it takes people on the ground to change the journalists, it's not something that happens on a top down basis. Most European press has now learned to address either the chapter/the community members responsible for press or the Foundation depending on the nature of the article they want to write. And if not, it should be a very clear things for the chapters as well as for the Foundation to direct them to the right people, "on the ground". > On 12/08/07, Florence Devouard <Anthere9(a)yahoo.com> wrote: > > What would be real cool would be to try to keep a written state of each > > project, what is hot, what is working, what is not working, technical > > wish list, biggest issues, big figures etc.... so that all participants > > could "follow" what is going on. I know all this is actually available, > > but only in a very dispersed manner, so not so easy to find out. > [snip] On 8/12/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote: > OK here is an idea for Florence. Write a post to foundation-l > addressing all projects (e.g. enwikipedia, frwikisource). Ask them to > put together a 'state of the wiki' report, with the things you > mentioned: > * progress reports on pages, users, admins, policies > * success of any special projects like printed material, wikiprojects > * any special policy or practice that they have developed, that is not > seen on other projects > * technical wishlist > * "perennial debates" - controversies that often come up in the community > > Tell them it's optional to submit a report, and they have a month to write it. > > If nothing else it would make for seriously interesting reading. :) > And the Board can just, you know, publish it on the foundation wiki. > They don't have to do anything else with it. But just having this kind > of 'official' request may make people think about these kind of > things. This is, unfortunately, not a new idea. Quarto [1] lived and died a beautiful death and was exactly about that. Making sure that all projects had a place to express themselves, raise their issues, tell about the state of their project. So let me try a different approach. Rather than waiting for Florence to try again something that she and other people have tried before, or for "the Foundation " to issue a dealdine, why don't you, Brianna, come up with a "state of commons" that you broadcast across lists and projects and ask for the same from other projects, just because you're interested? I am a fervent believer that top down has its limits, and that a call from a "fellow community member" might be better heard altogether. My take being that an "official" request is not always the answer to everything, on the contrary. Delphine [1]http://meta.wikimedia.org/wiki/Wikimedia_Quarto -- ~notafish La critique, art aisé, se doit d'être constructive. -- Boris Vian in *Chroniques du menteur* NB. This address is used for mailing lists. Personal emails sent to this address will probably get lost. NB. Cette adresse est utilisée pour les listes de diffusion. Tout email personnel envoyé à cette adresse sera probablement perdu.

4 6

Towards a Commons API
by Brianna Laugher 20 Aug '07

20 Aug '07

Hello, First, an anecdote. I have had on my Google Reader for a while now, a feed from Technorati which picks up any blog posts with the words 'wikimedia commons'. A lot of crud comes through, but also a fair number of real bloggers who use our photos to illustrate their blog posts. And let me say, they almost always get it wrong. They fail to link. They fail to mention the license. They fail to mention the author. Probably we are lucky if they manage to mention the site name. While I look at all these random blogs, I notice the proliferation of Flickr plugins...part of Flickr's success, I feel certain, is due to their API which allows anyone to easily "plug" Flickr into another application - a blog, a website, facebook, etc. And in multiple ways: by license, by keyword, by author(or, close enough: uploader). They also have that Commons could do this, but first we need to standardise. Anyone who actually has tried to write a tool to pick up this stuff will know it is hit and miss. So, I am not really planning to work on this in any big hurry, but I'm just saying it for reference and in case anyone else has a particular interest in it. The two main problems are keywords and licenses. Uploaders at least MediaWiki takes care of. :) first, the easy one: licenses. There is a painful problem at the moment that we have no way of knowing which templates are license templates and which ones are not. New ones are created all the time and old ones may be converted to deletion templates. (ook.) so, my proposal. 1. ask for new License: namespace to be installed at Commons. 2. move all license templates into the License: namespace. 3. separate any template which conflates license and source, e.g. "PD-NASA", "GFDL-GeoDB" (or whatever). Anything which is in the public domain, regardless of how it got there, should have {{License:Public domain}}. Indicating source by text + template is fine. Now I am not sure if there is actually a good reason we have license categories. Is it safe to assume that no one ever searches via license? If so, is there any extra functionality we gain from having the category? If not, we can quit using categories as well as templates to indicate licenses. If it is useful, we should change all license categories to be prefixed with License:. So instead of [[Category:GFDL]] we would have [[category:License:GFDL]]. I know technically "Public domain" is not a license. but close enough. So, the second problem, keywords. Let's reduce this to an easier (although less complete :)) problem: categories. Being able to have per-category feeds would be extremely cool. Imagine such a feed on QI or FP. Totally awesome. So in general we can assume that categories on a file act as describing keywords. There are two exceptions. One is license categories (see above). The other is maintenance categories, such as deletion, cleanup, user. So I propose we rename all these kinds of categories, to "Maintenance:X" or "Meta:X" for deletion and cleanup, and I guess "User:X" for user. I dunno. maybe these don't interfere too much. Sometimes they are useful. This change is not as important as the license one. In general, I think it is good for us to look at Flickr and say: how do they facilitate sharing their content? how can we do that too? cheers, Brianna user:pfctdayelise -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

8 29

Does Commons need a separate server for external tools?
by Brianna Laugher 19 Aug '07

19 Aug '07

Re: the discussion about an API and external tools, We have a bit of a problem in that we are using both the toolserver and the regular servers in ways they were not intended for. They are both really intended for Wikimedia-internal use. If we use them for external tools, Wikimedia does not directly benefit. If we were to have any great success, it would likely backfire and result in the thing being shut down or restricted. So, do you think we should (sometime in the future, not tomorrow :)) consider approaching a chapter or outside org to donate hardware specifically for this purpose? Call it the Commons thumbcache server. cheers Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

3 2

Swiss images needed for Wikipediaday Berne
by Robin Schwab 19 Aug '07

19 Aug '07

Hello I'm part of the organization commitee for Wikipedia Day Berne 2007 which will take place Sept 29th. To show that Wikimedia is not equal Wikipedia we decided to print 12 images about Switzerland poster size and glue them on aluminum plates. The images will be shown on Open Expo in Zurich on Sept 19th too. So all we need is good nominations of Swiss images. You know some? Nominate here: http://commons.wikimedia.org/wiki/Commons:Wikipediatag-2007-Galerie Thanks! Robin Schwab OK Wikipediatag Wikimedia CH - Verein zur Förderung Freien Wissens

2 1

Proposed deletion of images by Luc Viatour
by Rémi Kaupp 19 Aug '07

19 Aug '07

Dear all, You may have heard of Luc Viatour, aka [[User:LViatour]] : he is one of our best contributors on Commons, has uploaded hundreds of very good quality pictures and about 30 of his pictures have received the "Featured Pictures" status. Now someone has proposed his "copyright template" for deletion, while saying "Unless his template is moved to userspace and substed in all cases, it and all it tags (all images of Lviatour) should be deleted", which I think is very rude and aggressive. The deletion request is on http://commons.wikimedia.org/wiki/Commons:Deletion_requests/Images_of_Lviat…. Now I'm asking, what is this stupid rule about about personal copyright template ? This one (ie http://commons.wikimedia.org/wiki/Template:LviatourCredit ) doesn't do any harm : 1) It includes a double license GFDL-CC-BY-SA, and that's all. 2) It tells people who is the author and how to re-use the image, which is very good (see the related discussion about people not knowing how to reuse images from Commons) 3) It says that "an email would be appreciated", which is not against the rules as it is not mandatory. Now if we start deleting templates like this, we can surely say goodbye to our best contributors. We surely do not want people like Luc Viatour to get out from Commons, do we ? Regards, Rémi http://commons.wikimedia.org/wiki/User:Korrigan

4 3

en.wiktionary discussing disabling local uploads
by Chris McKenna 18 Aug '07

18 Aug '07

There is a discussion that is just starting on the English Wiktionary about the possibility of disabling local uploads. I don't have figures, but there are not many images used on the project and I doubt there are many uploaded anyway. Of the images that are used, I'd be suprised if more than a handful at most were fair use and thus unsuitable for commons. Most of the media is audio files, and again I don't have figures but if even 1% are not suitable for Commons I would be suprised. The discussion is at http://en.wiktionary.org/wiki/Wiktionary:Beer_parlour#Disable_file_uploadin… Chris -- Chris McKenna cmckenna(a)sucs.org www.sucs.org/~cmckenna The essential things in life are seen not with the eyes, but with the heart Antoine de Saint Exupery

2 1

SVG Open Conference: Tokyo, Sep 4-7 2007
by Brianna Laugher 16 Aug '07

16 Aug '07

There's a reasonable amount of stuff about SVG + mobiles and SVG + GIS. If anyone just happens to be hanging around Tokyo in the next two or three weeks it might be worth popping in. ;) cheers Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

1 0

WMI PicWik update
by Brianna Laugher 16 Aug '07

16 Aug '07

WMI = Wikimedia Israel, a chapter PicWik = "pictures for Wikimedia", internal name for their historical picture collecting project An English translation of the project spec is available at meta, who are interested to know more about it: http://meta.wikimedia.org/wiki/Free_image_collection_project cheers, Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/

6 8

Complete brokenness of categories is making me mad.
by Gregory Maxwell 15 Aug '07

15 Aug '07

In short, our category system is completely screwed up. I've complained about this in the past, but it only seems to be getting worse. If you follow the category hierarchy you'll find over 26,000 sub*cats* of Category:GFDL, for example. On the mean number of decedents of commons categories is 110 subcategories after full expansion. There are 29 categories from which you can reach at least 90% of the total categories used on commons. Just a list of all the categories and their children is over 400mbytes of text. Limiting the depth of traversal doesn't work because doing so would result in terrible brokenness, such as randomly failing to return a particular flower picture when someone searches for "flowers" just because someone decided to split Category:White Flowers into "Grey flowers" and "light white flowers" thus moving some of the images a level too deep. Many of the broken linkages aren't especially deep. This is brokenness which goes far beyond the semantic drift issues that I've argued make implicit category assignment fundamentally flawed. (although some of it is through semantic drift, cat:astronomical objects includes everything on earth through a completely useless but piecewise sensible path) What I need to know is: What do you need from me in order to fix this? I can provide, via JS insertion of data from a toolserver tool, a list on the category page of all the children of that category. However, which many cats with over 1000 decedents... you might be waiting a while for some pages to load. Alternatively I could provide. via the same means. a list of the children of a category at the top of the category (working around the subcats display complaint in bugzilla). I can provide reports such as what are the deepest linkages which carry the most children, and which categories have the most descendants. What do we need to fix this? I've already given my solution (apply all categories that make sense to images, and only use the hierarchy to help with finding and suggesting cats). Some background: I recently put up a tool which enables very fast intersections of commons categories. The same back end can be used for blindingly fast geographic searches, and text searches. http://tools.wikimedia.de/~gmaxwell/cgi-bin/cattersect.py It's already a useful tool for finding images, but it's substantially limited by the fact that categories are broken into tiny groups and the tool can not dynamically walk the category hierarchy. I've long argued that we need to avoid the category hierarchy issue by applying all applicable categories directly to the image, and reserve the hierarchy for pure category maintenance purposes. I've realized that despite the merits of my position (argued elsewhere), it simply isn't going to get traction in our community. So in the interest of making progress I started working on finding a solution to making the tool support following the category hierarchy. I've got something which I think will work fairly well, ... it doesn't break live update for image data, though it does require batch updates of the category tree data. ... I would have had it up tonight were our category data not so badly broken.

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Commons-l August 2007