I think Wikimedia Italia is not in the English Wikimedia ‘planet’ (although they are on identi.ca), so lest anyone miss this, I thought I must post it – it’s a video explaining and showing Wikimedia Commons (it has English subtitles):
This is so well done! Bravo WMIT. I can’t imagine how long it must have taken to plan the text and choose the images. The text is nicely concise, doesn’t belabour any points, and is quite comprehensive – from OTRS to Meet our photographers … I thought it was quite funny at first, seeing the narrator in the menu on the left, but it is a nice way to see him and also see lots of colourful images. :)
There is information about it in Italian on the Wikimedia Italia site.
Ben fatto, Wikimedia Italia!
Waldir has previously guest-blogged here and I am happy to welcome him back for his second post. Congrats on helping make this cool project happen! —Brianna
written by Waldir Pimenta
Did you know that the most venomous insect in the world is an ant? That’s right. One sting from the Maricopa Harvester Ant is equivalent to twelve honey bee stings — the required amount to kill a 4.5 pound rat.
I found that over a year ago, through University of Florida’s Book of Insect Records. I immediately headed to Wikipedia to see what it had to say about it, but to my surprise there was no such article! I thus started one from scratch, using some information I found in several ant-related websites. Eventually people started adding information to the article, up to the point that it contained a fairly good collection of information about this fascinating species. But still one thing was missing — something that single-handedly could make the article ten times more useful: an image.
So, when searching for images to illustrate it, I found the fantastic images from AntWeb, a project from The California Academy of Sciences, which aims to illustrate the enormous diversity of the ants of the world. I was especially happy to find that they were using a Creative Commons license — but soon after I was disappointed to find that the specific one they used (CC-BY-NC) was not appropriate for Wikipedia (or, more generally, free cultural works, and thus discouraged by Creative Commons itself).
So I sent them an email suggesting them to change the license. When they replied, I found out that they actuallly had been internally discussing license issues for quite a while. I kept in touch, and made sure to let them know the advantages of having their work showcased in such high-traffic websites as Wikipedia, Commons or WikiSpecies.
I like to think that my two cents helped in their decision, some time later, to not only change their license to CC-BY-SA, but also upload all their images to Commons themselves! This was part of their overall mission: “universal access to ant information”. Before, the AntWeb project focused only on digitization of content and development of the web portal; but now they also decided to “export” AntWeb content to improve access. Putting the images and associated metadata in Commons was an example their outreach initiatives.
This was very welcome by the community, and there was a lot of input on how best to perform the mass upload in order to make the images easy to find and be used to illustrate articles and other relevant pages. The process took several days, but finally, over 30,000 images were uploaded, full with EXIF tags, taxonomic data, and geographic information when available.
This is just the beginning, though! As usual in the wiki world, you can help! There are articles to be illustrated in the various Wikipedia language versions (Magnus’ FIST tool comes in handy for finding them!). There are WikiSpecies pages to be illustrated. There are categories in Commons to be created to allow the ant category tree to be navigated and have every ant image reachable through it. And more importantly, there are these great news to spread and let people who are interested in ants know that they can now count on what’s possibly the greatest online repository of free, high-quality ant images.
Many thanks to Brian Fisher, AntWeb Project Leader, who coordinated the license change process, Dave Thau, AntWeb Software Enginer, who wrote the upload script and performed the upload, and to all the AntWeb staff for their outstanding work!
Voting has closed and vote verification is taking place, but assuming none of the pages have been massively tampered with, this is what the top 5 will look like:
#2 – Horses by Flickr user Mikel Ortega, with modifications by Richard Bartz. (finals voting) 74 votes. Because of the closeness I wouldn’t call the real winner until both of these had all their votes checked for validity.
#3 – Locomotives Roundhouse, a 1942 photograph from the “Office of War” Information Collection at the Library of Congress, with modifications by Durova. (finals voting) 48 votes. I am so pleased to see one of Durova’s images here, because in 2008 and 2009 she has had a huge impact on Featured Pictures and even more importantly has been helping others learn how to do this useful work, which puts a shine on important historical works. She is pretty inspirational as an example of “leading by doing”, if I can put it that way, and her blog is a decent read too, frequently interesting, incisive and/or funny. To do so well in what is blatantly a populist pretty picture comp is a real achievement. :)
#4 – Sun rays by Mila Zinkova. (finals voting) 45 votes. Mila also has a huge number of Featured Pictures (including third place in the 2007 Picture of the Year competition!). It’s great to see regular contributors gratified in this event. I would also wait for a final vote-check before confirming the order of results for this one and the previous one.
It utterly boggles my mind that there are now at least 27 photographers who have > 10 Featured Pictures each. It represents an outstanding amount of dedication, and I hope that Picture of the Year is a little thank you to everyone who puts themselves through the ringer to have their work recognised as a Featured Picture.
My category finalist graphical summaries:
- Emblems and diagrams
- Non-photographic art and historic maps
- People and human activities
- Objects and outer space
- Cities, architecture and constructions
- Nature views
- Plants and fungi
- Other animals
Here are the finalists from the category other animals:
(“Other animals” means not birds or bugs, BTW :))
Voting closes like… today! It’s time to make a tough decision and cast your vote for 2008’s Picture of the Year.
Here are the finalists from the category birds:
Voting closes 30 April.
Here are the finalists from the category arthropods:
Again another strong category of photography for the Wikimedia Commons community, with all but one of the awarded works being created by editors. And remarkably, among these eight, there are two photographers who have two entries each!: Kevincollins123 and Richard Bartz. Congrats guys.
Voting closes 30 April.
Here are the finalists from the category plants and fungi:
Plant photography has always been a strength of the Wikimedia Commons photographer community, so it is no surprise that these finalists are all home grown. I would be surprised if there was any more than a handful in this entire category that weren’t created by Wikimedians, actually.
These are Osteospermum_Flower_Power_Spider_Purple_2134px.jpg, Narzisse.jpg, Nelumno_nucifera_open_flower_-_botanic_garden_adelaide2.jpg, Dew_on_grass_Luc_Viatour.jpg and Alberi_AlpediSiusi.JPG (these last two are tied equal 4th).
Voting closes 30 April.
Here are the finalists from the category panoramas (they’re pretty huge!):
Voting closes 30 April.
Here are the finalists from the category nature views:
Voting closes 30 April.
Here are the finalists from the category cities, architecture, constructions etc:
Voting closes 30 April.
Here are the finalists from the category objects and outer space:
Voting closes 30 April.
Here are the finalists from the category people and human activities:
Voting closes 30 April.
Here are the finalists from the category non-photographic art and historic maps:
As per yesterday, voting closes 30 April.
You may remember me mentioning the 2008 Picture of the Year (2008) competition during February and wondered what happened to the final round of voting. Well, it’s finally upon us :) and take this opportunity to appreciate the wonders of automated voting systems!
From 501 contenders, 51 have made it to the final — the top proportional number from each category. For the first time, we have category winners, which I think is a great idea. The single final overall winner will be drawn from this pool of 51.
Here are the finalists from emblems and diagrams:
These are 8-cell-simple.gif, Simple_CV_Joint_animated.gif and Wrist_and_hand_deeper_palmar_dissection-numbers.svg. You can find the total vote counts for each image in this category here. Only four images in this category gained over 100 votes — these three and the unlucky Rubik’s Cube SVG.
With any luck I will make a series of these images for each category. Remember, in the final you can only vote for one of the 51 choices. Check out the voting page for more information about how to cast your vote. Voting closes at the end of the month. And if you’d to vote for something that doesn’t require as much agonising, vote YES for licensing sanity! :))
It’s called Masca-2009.jpg and the English caption is View near Masca in sunset. Masca is a small mountain village in the Canary Islands. The user who uploaded it, Kallerna, is a sysop in the Finnish Wikipedia, and licensed the image into the public domain. They also geo-tagged it.
Thanks, Kallerna, and everyone who contributes to Wikimedia Commons, for making it what it is today — despite all the difficulties.
3M was July last year, 8 months ago, about the same length of time it took us to get from 2M to 3M. During the last few months, Commons has received a significant boost from the Bundesarchiv project, which will eventually end up as 100,000 images donated. So it seems that the contribution growth is basically steady since 2007.
See also my post around the time of 3M, The coming challenges for Wikimedia Commons.
The 2008 competition is now open! So if you registered before 1 January 2009 and have at least 200 edits on any Wikimedia project, you’re eligible to vote. They’re pretty lenient guidelines so I hope there is a big turnout.
Again, voters may cast as many votes as they like in as many categories as they like. Last year, the top 28 across all categories went to the final round. This year,
Each category of images will have a first, second, and third place award in that category, plus a number of honourable mentions sufficient to make sure that 1/10th the number of images in each category get an award.
The winners and honourable mentions in each category will go on to the final round to determine the picture of the year.
The categories are Emblems and diagrams, non-photographic art and historic maps, people and human activities, objects and outer space, cities, architecture, constructions and related (one, two), nature views, panoramas (one, two), plants and fungi, arthropods (one, two), birds and other animals. You may notice there is quite a bit of overlap between the categories, some of which mark subjects (nature views) and others which mark formats (panoramas) or even meta-data like date. Having constructed the categories for 2007 I can only say it is a thankless task that will never please everyone. However this does a reasonable job at having all categories roughly the same size, and comparing “like with like”. (For some reason practically no one chooses historical restorations over cute mammals…)
Having about 50 images in the final round seems about right, too — enough to pore and agonise over without being a chore. I like that there will be category winners (new!) and so many “honourable mention” awards. We have so much talent, we can afford to recognise it all. :)
For more info you can also check out the excellent Signpost write-up. But for now, get voting, and spread the word! You have until February 26, when Round 1 is closed.
Please read the start of part 1 to find out how you can try out these features too!
OK so part 2 is about in-browser video transcoding. So…what does all that jargon mean and why should you care?
Just as image files come in different formats (BMP vs JPG vs TIFF vs PNG vs SVG vs …), so too do videos. In fact it’s rather more complicated because there’s these things called codecs. As far as I understand it, different codecs are different methods of compressing audio/video – codes that say how to pack the raw (and huge) audio/video file in a particular way to save space. But because each codec has its own particular way, you need to unpack it in that same particular way otherwise your computer won’t be able to understand it, and you won’t be able to play the file. MP3 is an audio codec. MPEG-2/3/4 are video codecs.
Unfortunately it’s not even as simple as equating file format == codec, because some file formats are “container formats”. AVI and OGG are container formats, and it means that inside, the audio/video can be encoded in a variety of different codecs. So basically it’s more pain.
Now some codecs seem free, but some codecs really are Free, and hopefully this coincides with being patent-free so no one will sue you just for using them. The Wikimedia Foundation, bless their cotton socks, recognise through their Values statement the importance of free formats and codecs:
An essential part of the Wikimedia Foundation’s mission is encouraging the development of free-content educational resources that may be created, used, and reused by the entire human community. We believe that this mission requires thriving open formats and open standards on the web to allow the creation of content not subject to restrictions on creation, use, and reuse.
Consequently, Wikimedia Commons has a policy on which file types may be used:
Patent-encumbered file formats like MP3, AAC, WMA, MPEG, AVI and the like are not accepted at Wikimedia Commons. Our mission requires content to be freely redistributable to all. Patent-encumbered formats fail to meet this standard.
So what is allowed? For audio/video, it comes down to Ogg container format with Ogg Speex/FLAC/Vorbis (audio) and Ogg Theora (video) inside. Yay Ogg! There’s only one tiny problem… no Windows software plays anything Ogg by default, no recording devices produce Ogg files by default, and this means users have to convert their files before uploading. Blah! What a hassle! Why can’t using free software and free formats be easy?!? (I’m not being facetious… I half know what I’m doing and it’s still a pain.)
Well, soon things are going to get a whole lot better: with Firefox 3.1, due next month in February, by default Firefox will support Ogg Theora. That means you’ll be able to play Ogg video in your browser without any extra software.
But even better: someone has written an extension called Firefogg which will transcode a file for you when you upload it. So, if you have Firefox 3.1+, and you have the Firefogg extension, and you come to a site that only accepts Ogg and you have a something-else file, now you just need to upload it as normal and Firefogg will convert the file for you before uploading it to the site.
I don’t know about you but I think that’s some serious genius. And Michael Dale has an implementation of it for Wikimedia Commons! Here’s what it looks like:
So we make it to the Commons upload form, and notice a new option saying “Enable video converter”. So if we tick that…
… then we can choose some random video format (in this case, AVI). And instead of just uploading, it will do transcoding (converting the format) and then uploading.
And, uploading! (Nice to get progress meters “for free” with this extension)
And… wala! Here’s my uploaded file, now in Ogg format, and playing using just the browser because that’s how awesome Firefox 3.1 is going to be.
As it transcodes, it also writes a copy of the final Ogg file next to your original file – handy to have both around.
One of my favourite things about this is that it removes the need for me to figure out all the configuration options in transcoding files. There’s so many and figuring out the optimum ones can be very tedious. With Firefogg, the site that is accepting the Ogg file tells your browser what settings it wants you to use — and you don’t have to see or deal with any of it! Total win. :)
So, to recap, how you can play with this awesomeness:
- Add this to your /monobook.js:
- Install the Firefox 3.1 beta (…or wait til February and it won’t be beta anymore)
- Install the Firefogg extension for Firefox
- Go and upload videos with the greatest of ease!
Again this is something I hope that will become available as a Gadget for people’s user preferences, so if you like to experiment a bit please do so and report back, so it can be stable enough by the time Firefox 3.1 is released to be a Gadget for everyone.
Long live the Ogg! :D
So at LCA I was able to catch up with Michael Dale, who is doing some very interesting video work for the Wikimedia Foundation. Michael was talking about his development work, as well as taking part in the Foundations of Open Media Workshop which is collocated with LCA.
I had noticed some recent posts by Michael to the mailing lists inviting people to trial some new features he was working on, so after his talk I cornered him to get a personal demo and make sure I didn’t miss anything. :)
There are two separate features that are bundled together in the demo: one is an in-browser video transcoder, and the other is a cool add-media wizard. The add-media wizard works on Firefox right now, while the video transcoder needs just a couple of extra steps, so I will cover the add-media wizard first.
First of all, go to your user monobook.js subpage on whichever wiki you want to try this on. Mine, on Wikimedia Commons, is at http://commons.wikimedia.org/wiki/User:Pfctdayelise/monobook.js. Edit it and add this line:
(note the trailing semi-colon)
Do a shift-refresh, and then open a page for editing. If you’ve cleared your cache you will see a new little icon above the edit box, at the far left:
To my mind it looks a bit like the Ubuntu icon, but I think it’s actually a film reel with a plus symbol. :)
So if you click it, you will get a box coming up with some thumbnails of images, searching on whatever the name of the page you edited was.
So what we get is some thumbnails from an image search, and we can see different tabs for different media archive sources. At the moment there is just Wikimedia Commons and Metavid. Obviously we could add other license-suitable archives as we become aware of them (eg Flickr’s CC-BY and CC-BY-SA images). Currently it mixes together all media types.
So, let’s choose one…
Now I can write a caption, and either preview the insert, insert it directly, or cancel the insert. This is what the preview looks like:
Note the “preview” notice at the top of the drop box, and at the bottom the options “Do insert” or “Do more modification”. Hmm, so what was that crop option?
Clicking on the “Crop image” option gives a “box drawing” cursor where we can draw a box over the image to choose what crap we want. Everything not in the crop is shadowed.
So how does this crop actually work? At the moment, it relies on a template called Preview Crop. So if you’re testing this feature out, check that your wiki has that template. In the future, hopefully crop functionality could be added directly to the MediaWiki image syntax, so it might be equivalent to something like
[[Image:Foo.jpg|crop,10,10,120,150|thumb]] or something. For now, you need the template.
And… it works! :)
So that is the add-media wizard. If it is very well designed, it may remove the need to search Wikimedia Commons separately to writing your Wiki* article. (I mean, it wouldn’t be hard to improve on the default search.) It would be neat to integrate some of the features from Mayflower, including hover-over indication of license, description and metadata, and advanced search options such as searching by file type.
A few more things:
- Currently, as I understand it, Wikimedia Commons is kinda “hard coded” into the wizard. For Wikimedia wikis that makes sense, but this could be used by any MediaWiki and also take advantage of any specified foreign API repo.
- Possibly wikis could specify which images should not be indexed by listing deletion templates somewhere, but OTOH, if the description info is displayed, I guess the user can figure that out for themselves.
- If you search in a non-Wikimedia resource and insert a file from one, the wizard will transparently copy the file to the local wiki (along with any appropriate metadata it can get I suppose). Depending on which third party archives get added, I guess the Wikimedia Commons community will like to have some say about how that copied info is formatted.
That’s about it for now; I will cover the in-browser video transcoder in a second post. If you think it looks interesting I encourage you to try it out, and report any problems or suggestions you have. Or if you have no problems: that’s also good to know! If a few more people try it out in its current form, I think it would be a great thing to enable as a Gadget then people can easily choose to use it by turning it on in their preferences. Ultimately it may even be best as a default thing turned on for everyone, by being integrated into MediaWiki core.
I recently learned of a most interesting project currently taking place on the French Wikipedia. It is called WikiPosters. At each image page on the French Wikipedia, an unobstrusive link is inserted that says “Get a poster of this image (new!)”. Clicking on it drops down a short menu that provides a link to purchase a poster of that particular image through the WikiPosters website.
The “purchase a print” menu on the French Wikipedia image page (link)
Ordering the poster on the WikiPosters website (link)
(And it works with SVGs!!!)
What’s interesting is that this project was organised by the French Wikipedia community, originally spearheaded by Plyd. The printer is a commercial printer. They make a small donation to Wikimedia France for each poster purchased, but they have no contract or arrangement with them. And why would they? Wikimedia France no more controls the French Wikipedia than the Wikimedia Foundation (or Wikimedia Australia :)) controls the English Wikipedia. It is right, I feel, that the agreement should be with the French Wikipedia community.
I emailed Plyd to get some more information about the project. He sent me an excellent reply that I have just copied below.
In my opinion, free knowledge should leave online-only.
Printers are ready to spread free knowledge,
demand of printed knowledge is big,
we have numerous valuable pictures :
let’s just link pictures and printers !
That’s what I proposed in 2007. A test-link “Get a poster of this picture” had a great success on fr.wikipedia.org (over 6000 clicks a day). Unfortunately, I did not spend enough time to get in contact with a first printer. But one year later, in May 2008, a French printer contacted me. He was convinced of the potential of such project and proposed himself as a pilot of the project. That’s how it really started. The project took long discussions on French Wikipedia, about how to respect free licences, about the donations the printers could do, about legal issues etc. We eventually draw an open partnership, without signatures.
Then, the pilot printer developed his specific Website that could receive links from Wikipedia. We made the menu and the generator of licence data to provide along with the poster.
The menu was activated for all accounted-users during one month and we just activated it for everyone yesterday. [that would be 2008-12-16]
Main points of the partnership :
- A page is provided with every poster containing the Image page and, if it is GFDL only, the licence. This page is sent by the menu to the printer, along with the full-resolution picture url.
- For legal issues, only pictures from commons are allowed (no fair-use – actually it is already forbidden on fr.wikipedia.org -, no logos, no “non-commercial”, …). Commons respects these criteria.
- The printers are only encouraged to make donations, either to the Foundation, either to the Local Chapter, in order to get a tax cut. The first printer, WikiPosters, will donate 1,50€ per command to Wikimedia France (e.g. 0,60 with tax cut).
As a first start, they donated 500€ to the Foundation and 500€ to Wikimedia France.
We are impatient to know how many posters will be distributed…
If it works as much as I hope, there are many ideas for next steps :
- add new printers not only sending from France…
- help other projects get such a menu…
- provide a similar “Get a booklet of this article”…
I asked Plyd if he had had trouble getting the community to accept the idea. While it seems an obvious benefit to me, for contributors to a “non profit” project it can often be confusing that commerce might have any place at all.
Actually most (I’d say 90%) of the community was really defending the project, but some voices did not like the ‘for-profit’ aspect of the printer. We put a parallel with search engines on Wikipedia search page, the booksellers on isbn pages or the geolocalisation tools also provided on French Wikipedia. […] [T]he partnership does not require any donation. his is up to the printer. I think it’s a good point for the printer to help the project by a donation. In my humble opinion, his 1.50€ donation will more convince poster buyers, like the first 1000€ donation helps to convince the community.
[…] They (a really minority part of the community) did not like that some people could make some money from contributors work, without even telling them. This shows that the free licences important lines are still not fully nderstood by everyone. Fortunately, other Wikipedians helped me explain differences between commercial and non-commercial free licences.
I really appreciate that a large majority was supporting the project.
If the project turns out to be a success on French Wikipedia, the Wikimedia Commons community will just about have to look at implementing it. I think they would be crazy not to. Again it goes back to the mission — disseminating free educational content. What wonderful classroom posters would some of our SVG masterpieces make?
The tricky, or rather interesting, part, then, may be finding suitable printing partners in enough countries in the world. (Although WikiPosters does worldwide shipping, the cost is prohibitively expensive.) Interesting because understanding free content is difficult enough, let alone how to massage the caprices of an amorphous online community. The WikiPosters folk are brave — I commend them.
Purchasing statistics seem to be available (not sure how often that is updated), so it will definitely be an interesting thing to keep an eye on over the next few months.
The other interesting aspect is how Plyd managed to pull this off, that is convince the community enough to take part. It’s well known that the Wikipedia communities (maybe all online communities? maybe all communities?) become increasingly petrified as they age. Petrified in place, and petrified of change.
And why we may all rejoice at the joys of a volunteer-driven non-hierarchy (or something), we rarely recognise the missed opportunities of our leaderless groups. As an example, I think that Wikibooks may be floundering a bit without formal links to curricula, publishers and other open courseware folk. They are in a more crowded “open” field than many of the other Wikimedia projects and struggle to distinguish themselves. (On a side note, I wonder what will come of Neeru Khosla of an “open source textbooks” group joining the WMF Advisory Board. I could not help but think of Wikibooks, but it didn’t rate a mention.)
Maybe Plyd is one of those magical people who can draw people together and convince them to put aside their differences, like a wiki Mary Poppins. But I hope not. I hope he is an ordinary person and that his success in this “real world” endeavour, will convince other ordinary folk in all the Wikimedia projects, to think about how they might pursue “real world” engagements that, yes, disseminate our works effectively and globally.
(Worrying about) Usability seems to be all the rage in Wikimedia at the moment. I think it’s an important thing to worry about, but we have this problem that we are unable to tell and often even guess, how our projects are perceived by people not already familiar with them.
I decided to give it a spin for some aspects of Wikimedia Commons. For US$7 for 10 responses, why not? I sent people to look at Image:Easter_Island_map-en.svg, which was yesterday’s Picture of the Day. Here’s the instructions I gave them:
This is testing the usability of the site, not your ability. If you can’t find the answer to any of the questions, that is itself a valid answer.
- What is this a picture of?
- Who created this picture?
- What file format is this picture in? Is there anything special about it?
- Has this picture been judged to be a good one or not? How can you tell or not tell?
- How many versions of this picture have been uploaded? By which users?
- Would you be allowed to use this picture to create a paper map for sale? How can you tell or not tell?
- What date was this page last edited?
And a few questions about you:
- Are you male or female?
- What is your age?
- Have you ever edited a wiki before?
#1 is a gimme to make sure they’re sensible people. #2 is asking people to find the “Author” field in the description below the image. #3 was partially just curiosity about people’s awareness of SVGs, although most respondents picked up on the template:translation possible.
#4 is about the FP (featured picture) and POTY (picture of the year) markers. #5, as a couple of respondents noticed, was ambiguous — unintentionally on my part. I was actually referring to different uploaded versions present under the “File history”, but different translated images are listed in a section called “Other versions” so that was poorly worded on my part. 5 people responded about the translated images, 3 about the file history section, 1 pointed about the ambiguity and 1 didn’t respond.
#6 was about the Creative Commons BY-SA license. Partly it tests if they can locate that information, and partly it tests if they know (or can quickly find out) what that means. So partly it is a test of Creative Commons’ marketing I think. :)
#7 is one that is intentionally a bit confusing. The last version of the image uploaded was at 23:43, 22 October 2008, which is available directly on the page, but the time the page was last edited has to be found from the History tab. (It is 22:11, 24 November 2008.) Exactly half of respondents picked each answer, October or November.
#8, 9 and 10 are just basic demographics.
So these are just some very quick checks. Other interesting things to check would be if people can navigate and understand history pages, navigating categories, and then obviously editing and uploading.
What questions would you ask? Would you change any of the above questions?
FLOSS Manuals’ head honcho Adam Hyde explains:
The One Laptop per Child (OLPC) roll out of 100,000 laptops has begun. The exciting news is that the laptops now carry the documentation created in FLOSS Manuals embedded within the ‘Help Activity’. […] The manual was written in FM and then remixed using our remix feature, output to HTML and included on the laptop. Since all chapters are written in a modular way it was possible for the OLPC crew to add chapters from other manuals in FLOSS Manuals.
The main exciting bit is the OLPC Laptop Users Guide, which is also available to purchase. The Wikimedia Commons material really got tacked on the end. But still: 100,000 OLPCs going out into the world inviting people to contribute to Wikimedia Commons! It gives me a little spine tingly. Thankyou Adam and FLOSS Manuals for providing the platform and encouragement to make this possible. :)
OK, my NaBloPoMo definitely failed. Nonetheless.
Something that was introduced to MediaWiki with little fanfare was wgForeignAPIRepo. This allows a MediaWiki install to specify another wiki to pull images and other media files from. Like, say… Wikimedia Commons!
This is an idea that has a long history under the name InstantCommons. One of the main reasons Wikimedia Commons is cool is that it can be used as a media resource as if the files were uploaded locally by all the Wikimedia wikis. So “InstantCommons” is about extending this aspect of Wikimedia Commons behaviour to any MediaWiki wiki.
Now, on the front page, there is a colourful map. Clicking through to the image page shows the full image information from Wikimedia Commons, as well as a subtle hint as to the image’s origin:
There are two big obvious gaps in the functionality at the moment. The first is that third parties using InstantCommons don’t have any way of knowing what happens to the images they are using. While wiki resources such as Wikipedia and Wikimedia Commons may look stable from the outside, editors know that they are anything but. Especially with images, as there is no straightforward way to move/rename images. This means images get deleted and re-uploaded under their preferred name. Copyright violations are also rife among uploaded files, much more so than contributed text I would guess. Not to mention that the community understanding of international copyright is constantly being negotiated and argued. It’s very tricky; not straight-forward at all.
So this is one thing. It is nice to know when images that you use are deleted so that you can remove the ugly redlinks from your pages. But you on your third party wiki have no way to find this out locally: deletions at the other location won’t appear in your local logs. There are a couple of choices:
- When first using an image from the central repository, copy it locally and from that point on only refer to the local copy.
- Create an automated log that you can follow that lists changes at the central repository, that relate to images that you have used.
- Allow a bot from the central repository to update/remove images for you.
The first option seems good but depending on what your wiki is and how you run it, you may well want to keep up to date and, for example, remove known copyright violations.
The second is a good option but may not be very popular. A similar concept was created for Wikimedia wikis, known as CommonsTicker. However my observation is that using the CommonsTicker has not been a very popular choice. Wikimedia wikis might get pissed when an image gets deleted that had been on their front page, but that doesn’t mean they’re prepared to drudge through the CommonsTicker log on a regular basis.
The third has been most popular in the Wikimedia universe. CommonsDelinker is a bot that runs over all 800+ wikis of Wikimedia and removes redlinks to images after they have been deleted at Wikimedia Commons (if the local community has not, in the meantime, removed the link themselves). CommonsDelinker also comes with a manual (the code is under the MIT license) and with some minor tweaking might be usable by third parties. It makes more sense for third parties to run the bot themselves, rather than Wikimedia Commons, due to configuration differences.
The other gap in the functionality is that there is no way for the central repository to know which of their files are being used and where. For Wikimedia Commons, we generally like to be able to find out what impact our actions will have — especially if, say, WikiTravel was using our content. Actually this problem is by no means well-solved even for the Wikimedia universe — we rely on a toolserver tool called CheckUsage. If the toolserver goes down, Wikimedia Commons admins have no way of knowing what impact their deletions may have. This still needs a MediaWiki-native solution.
Why is InstantCommons important? The Wikimedia Mission is to disseminate freely-licensed educational content effectively and globally. For Wikimedia Commons, what could constitute more effective dissemination than letting every MediaWiki wiki use its content so easily and transparently? Not a single thing that I can think of.
“Oh Brianna,” you may ask, “What is that most interesting tome you’re reading?” Why, I’m so glad you did. It’s a Lulu-printed version of a short manual I wrote called How to contribute to Wikimedia Commons.
So, I spent the week before Wikimania in France. The purpose was to hang out at the FLOSS Manuals Inkscape documentation booksprint and also to hang out with my French friend (un-wiki related). As you may have guessed I am a big Inkscape fan. (Inkscape is the premier open source software for creating and editing vector graphics, i.e. SVGs.) But I definitely don’t know enough to really help out with writing documentation. I would be too busy reading it. So I decided to write some documentation to help people who might be familiar with Inkscape, i.e. accomplished or semi-accomplished illustrators and artists, but new to the complex and confusing world of Wikimedia. That is the aim of my manual, to be a self-contained introduction to contributing to Wikimedia Commons, without information overload.
So you can read the manual online at http://en.flossmanuals.net/WikimediaCommons/. You can also check out the editor’s view at http://en.flossmanuals.net/bin/view/WikimediaCommons/WebHome. FLOSS Manuals uses a highly customised version of Twiki — yes, a wiki. The most immediate difference between Twiki/FM and MediaWiki is that Twiki/FM uses a WYSIWYG interface that converts directly to HTML (which you can also edit directly if you really want) — no “wiki markup” intermediary. I thought it would bug me (Wordpress’ annoys me immensely), but I soon got used to it and didn’t find it slowing me down at all.
Twiki/FM is great for planned-ahead books with a small number of authors where the bulk of content is written over a known time period, but MediaWiki is definitely better suited to laissez-faire, largely unstructured book development by an unknown number of authors over an essentially unbounded time frame. That’s not to say that there aren’t a significant number of improvements that MediaWiki requires to really meet the needs of book authors and their enablers.
I also feel that Twiki/FM is a better choice if you want your manual to have an offline life, whereas MediaWiki is much better if you intend it to stay all linked-up on the web. The killer feature here for Twiki/FM is Objavi. It’s a wiki-to-pdf converter that uses CSS for styling and most importantly, actually looks great.
Basically double-handling is the killer. If you are doing speedy wiki-based authoring the last thing you want to do is have to edit a version specifically for print. It’s intolerable.
MediaWiki/Wikimedia is supposed to be getting its own whiz-bang PDF generator, via a partnership with Pediapress. So far it’s only enabled on a test wiki. The interface for creating a new “collection” (for Wikibooks, this will be usually equal to a book) is really awkward. But if admins get the hang of it and create nice PDFs for everyone else that will be nice. OTOH that won’t work on Wikipedia at all, where people will most likely creating their own custom grab-bags of articles. And unlike Objavi there is no way to specify print-specific style at all. Having said that, I just looked through a sample pdf (log in and click “Load collection” on the left, then follow the prompts) and it is quite impressive.
The issue that both Objavi and Pediapress seem to struggle with is that of images — their size and placement. Web-appropriate proportions just don’t suit normal portrait-orientation books. Someone should do a PhD on figuring out a good algorithm to convert them automatically. :)
Anyway! Back to my manual. It’s dual licensed under the GPL and GFDL, as GPL is the license ordinarily used by FLOSS Manuals, and I asked for GFDL licensing for obvious reasons. My hope is that chapters and similar groups will keep a copy to share with people who prefer book documentation.
I haven’t yet sorted out a pricing thing on Lulu, but I was hoping that it could be sold for cost + 2 euro (1 for FLOSS Manuals, 1 for the Wikimedia Foundation).
I also hope to see simple Wikipedia introductory manuals developed. English and Spanish ones in time for Wikimania would be nice!
This is thought to be the three millionth file for Wikimedia Commons. We celebrated two million files on October 9, 2007. That was exactly a month after English Wikipedia reached two million articles. Currently, en.wp contains 2.47 million articles. (En.wp is three years older than Commons, but the difference in absolute numbers is not so surprising. Probably most articles can be illustrated in some way, and many in a number of different ways.)
So, Commons is growing fast. Adding over 100,000 files per month. That’s well over 3,000 files every single day.
3M is a friendly warning. It’s another nice milestone but most of our current contributors probably were around for 2M, and a good chunk of them are likely to be around for 4M. The part that makes me wary is the rapid growth we’re facing, and how prepared we are to not only cope with that, but make the most of it.
In my talk at Wikimania, I finished with what I saw as the four big challenges facing Wikimedia Commons in the near future:
- Project relationships
There is an excellent post at the Powerhouse Museum’s “Fresh and New(er)” blog about their experience with three months of contributing to Flickr’s “The Commons” project. Compared to the kind of great statistics (and, it must be said, control) that Flickr offers, Wikimedia Commons offers zip. Although we are taking a lot of excellent content from Flickr, we currently give those authors and institutions next to no information about how we use their image. (In fact for a good long time we didn’t even have a regular practice of leaving the author a comment to let them know we’d copied their image.)
Of course, according to the licenses we accept (PD, CC-BY, CC-BY-SA) we don’t have to notify the authors or collection owners of anything. But it would be damn nice if we could. It might go a long way in making instutions feel more comfortable upon discovering their content let loose in Wikimedia Commons.
Which is why we need to create and offer institutional stats reports. What we do after that, I’m not too sure, but it’s a start.
Here I mean the relationship between the Commons community and each community of each other Wikimedia wiki. If I ever see another project get so annoyed that they threaten to (or actually do) tell their users to stop uploading to Commons and just upload locally, then I will consider that the Commons community has massively failed. Luckily I haven’t seen too much sign of this for a while. I think perhaps we are much better integrated with other communities now than we used to be, and that will definitely continue with SUL (Single User Login). SUL should mean more participation from non-regular users, I think, so it will definitely be interesting to compare the activity levels on Commons 6 months before and 6 months after SUL.
I would like to see an automatic move-to-Commons functionality in MediaWiki. I would like to see more communities choosing to turn off local uploads. (As a listener in my talk pointed out, that probably means more communities need to choose to reject fair use.)
If you talk to me for long about Commons, you will soon find out I have a list of feature and bug requests as long as my arm. Major functionality required includes file rename capability, increased file size limit, bulk uploading, format transcoding on upload, global Whatlinkshere, search improvements (incl. specific template fields), category improvements, i18n improvements, write/upload via API, integrated workflow processes, integrated feeds and geo-info. Yeah, a bunch of stuff!
(I am glossing over here how tech improvements are going to make sorting and searching a trillion times better, somehow…)
Now having worked a bit on the most recent incarnation of our upload form’s interface, and now having used it a bit, I’m sad to say: it still pretty much sucks. It’s still way too freaking long and picky, with requirements that are annoying when all you want to do is upload.
So, um, it’s not all just lack-of-tech that makes the Commons user experience pretty disappointing. It’s also the Commons community effort (and this definitely includes me) to desperately request every conceivable useful piece of information right at upload.
I think there’s a few reasons for this:
- It’s hard to correct mistakes, so we try to pre-empt them with warnings. (e.g. renaming files, hence lots of warnings about choosing a descriptive filename)
- It’s not as straight-forward to add information after uploading as it is at upload-time. (Afterwards, you have to deal with template syntax, rather than a nice database-like form. This generally reflects the Commons community’s wish to have an underlying database-like structure rather than free-form text.)
- The Commons community is obsessive and loves metadata. (This results in a rich experience for the later image browser, but a generally poor one for the image uploader. Unfortunately we lack good methods of obtaining such data apart from asking for it.)
- The Commons community is vigilant against copyright infringements and copyright fraud. Having your content deleted is about the most crushing thing that can happen to you on a wiki, so we try to annoy you so much that you don’t upload in the first place… unless you’re really, really sure.
Yeah, see how that’s not a great strategy, there?
So our usability problems boil down to two things: Missing functionality, and the balance of discouraging copyright violations against ease of access.
If we were able to handle copyvio deletion more agilely (maybe each file has a tab “flag as copyvio”? and then admins can view that queue of flagged files?), it may be that we would feel comfortable lowering the barrier of ease of access.
Or, alternately, we grow ever more anal with upload requirements, and piss everyone off to the high heavens. :)
Anyway it looks like Commoners generally suffer from the same instruction creep as Wikipedians. That poor Uploadtext …
Saving the most difficult for last.
Just as Wikipedia has WP:IS and WP:NOT, Commons has COM:SCOPE. The Project scope describes the boundaries of acceptable content for Wikimedia Commons.
The problem is, those boundaries tend to be pretty freaking wide, when you want to serve media for an encyclopedia in every single language, and textbooks and courseworks and dictionary definitions and all the rest of it, oh and mind your historical shortsightedness (what is pop-junk today may be sociology gold in 5, 10, 50 or 100 years).
If I read the Village pump, I see concerns raised regularly that Commons is not exactly being used in the way it was intended. Let me elaborate.
And according to wikistics (thankyou Melancholie), the most popular category, by page views so far this month, is Vulva (NSFW). The most popular image (that hasn’t been deleted) is Vagina,Anus,Pereneum-Detail.jpg (NSFW).
OK, these pages are graphic. Is it such a shock that they’re so popular? Is it necessarily a bad thing?
Although for each individual image you could probably mostly construct a more-or-less encyclopedic use for it, taken as a context-less whole, it’s hardly surprising that many users are, well, taken aback. Is this what was envisaged when the project was started?
And yet we are hardly going to delete sex- and nudity-related content wholesale (you’ll never be allowed to forget that Wikipedia is not censored!!) — so where and how can we draw a line?
After my Wikimania talk, one listener essentially suggested we introduce an adult-content filter. After thinking about it for a while, I think this may be a very good compromise. Such a filter amounts to a “warning” (or probably an account preference) before viewing potentially shocking/NSFW content.
If you have different opinions about what the major challenges facing Commons over the next 3-5 years will be (and their potential solutions), I’d love to hear them.
…well, far more fun than profit :)
And now, a brief interlude from Liam Wyatt: you can work for him!
The Dictionary of Sydney is hiring.
If you are based in Sydney and have experience in multimedia researching, especially within a historical context, then I encourage you to look into a new job being offered by the Dictionary of Sydney.
The Dictionary is an online history project covering the whole Sydney basin. To find out more about the project, visit: http://www.dictionaryofsydney.org/
For the full details of the position, visit: http://positions.usyd.edu.au/ and search for position reference: 134833
I have tons to blog about, but I thought I would quickly relay that Wikimedia Commons has now reached three million files. :) We’re still working out what we think the 3 millionth file was. Maybe this metro station.
Wow. Wikis just gave me another lesson in awesome. I love it.
While thinking about the problem of Zemanta attribution strings, I mused that we really needed to develop a “Commons API”. There is a MediaWiki API for Commons, but there are more project-specific pieces of information we would like to provide. The big three are
- Deletion markers (warning to machines: don’t use this file)
- License info for a given file
- Author/copyright holder attribution string for a given file
So I made a bit of a start at Commons:API, thinking we could use the wiki pages to write psuedocode algorithms for the different problems. Already I knew at least I, Bryan and Duesentrieb had run across these problems before, and definitely others too. Therefore it made sense to combine our individual algorithms together and define a single, strongest-possible-permutation version and recommend others to use it. I imagined we could describe the algorithm in psuedocode and let people provide implementations in various programming languages. Versioning would kind of suck but hey, an imperfect solution is better than nothing.
However, a perfect solution is even better than both! I barely raised the topic when Magnus actually implemented it (warning: seriously alpha).
First, Magnus is one of my wiki-heroes. You could not ask for a more responsive developer, so it is just delightful when he chimes in on a “what if” discussion. Cool new shiny things are never far away. (Surely one of the strangest things to ever grace the toolserver is still Flommons, the “Flickr-like Commons” interface. Cut away the cruft!) And he is a lovely chap to boot. He tirelessly tweaks and prods any number of “what about…” or “why not move this here?” queries.
My pythonfu is not strong enough that I could code something like this up as he does, in half an hour, but I could probably practice and make some effort and manage it in a period of time. I recognise the neat or nifty factor in creating stuff that was previously just a “what if”. Programming rocks.
Secondly, I love how responsive a wiki community can be. Sure, for every five ideas you might have, four will garner a lukewarm response at best, but every now and then one will strike a chord and get some momentum. “Build it and they will come”; wikis can also obey “name it and they will build it”. [Of course, I’m hardly the first person to suggest Commons needs an API.]
Thirdly, thinking about the other Wikimedia projects — and indeed a good many third-party MediaWiki installs — it is obvious that all the projects may like the chance to define their own API. If nothing else, to define the “deletion markers” and the featured content (rather like another of Magnus’ tools, Catfood – category image RSS feed).
So, what does that suggest… that suggests wiki users need a flexible method of defining new parts of the API. Special:DefineAPI? Probably not, too subject to change.
Extensions can define API modules. So perhaps we should develop Extension:WikimediaCommonsAPI? If every project wanted to do this it may get a bit messy, but most projects wouldn’t bother I imagine.
Again we run up against the need for Commons to have a more structured database, rather than just store all information about an image in a big text blob.
At any rate, I hope we can set the current “pre-alpha” API up as a serious toolserver or svn project with multiple contributors. Wikimedia Commons is lucky to have attracted a relatively techy community of contributors, with a number of people MediaWiki- or toolserver- savvy. Let’s see how we go.
suggest pictures, links, articles, and tags related to your blog postings. Using proprietary natural language processing and semantic algorithms, Zemanta compares the words in a blog post to their pre-indexed database of other content in order to suggest related items which will display next to your blog post.
The articles Zemanta suggests come from 300 or so “top media sources” as well as the other blogs of Zemanta users. The images suggested come from Wikimedia Commons, flickr, and stock photo providers like Shutterstock and Fotolia.
In their FAQ they say All content that we are suggesting is copyright cleared – either clearly licenced as Creative Commons, or approved by stock providers.
I am happy to see such a service provided. I did think there was a space for it some time ago. If they do it right, then hey, win-win.
As I don’t have a Blogger, Wordpress or Typepad blog, this is a request: if you have one of these blogs, please try it out and let me know what it’s like.
- Where are the images hosted? Are they hotlinking from Commons, hosted on their own servers, or they do some voodoo and a local copy gets uploaded as part of your blog? Are there options about file sizes?
- Can you get SVGs?
- When you use it can you easily see which source the image results are from? Is it possible to restrict them to only use one image source?
- Does it seem that they are indexing all of Wikimedia Commons, or only Creative Commons-licensed content? (try to find and insert a GFDL image, or public domain)
- What is the attribution like? Are they able to extract the author information? Do they provide an automatic link back to the Wikimedia Commons page? Do they provide the license name and link?
While watching the latest featured pictures arrive at Wikimedia Commons, I noticed a few types that are new for us. While we have always had some pretty outstanding nature/architecture photography, SVG diagrams and arthropod/plant macros, these ones below represent an expanded repertoire.
Weeki Wachee spring
1947, by Toni Frissell
This is an unusual restoration of a historical photograph, because it is more notable for its author than its subject matter. In this way it is more like a restored art piece than the photographs which have been making their way across FP lately. The impressive and prolific work of Adam Cuerden and Durova have greatly expanded our collection of historical and art works — previously a weakness of our collection, now becoming something of a niche strength.
CC-BY-3.0 by Niabot
Definitely a first: an SVG of an anime character. Hopefully there won’t be too many to follow, but it does show the breadth of experience of our contributors.
CC-BY-SA-3.0 by Alvesgaspar and Tony Wills
A new presentation style for a familiar subject. In a similar vein, there is a mustard collage. I do like these posters. Is there a name for this style of work? I am sure more will turn up, so we should collect them.
To pot the red
CC-BY-SA-3.0 by Michael Maggs
I don’t know what you’d call this style of photograph but they are few and far between at Commons. [This nomination only just scraped by in FPC. I will not be too surprised if it scrapes out again soon…]
I remember a few months ago, searching for a photo of a person using a mobile phone. There were hundreds of photos of all kinds of models of mobile phones, sitting all on their lonesome on a desk or table. I don’t think I found even one that showed a person using a mobile phone.
I suppose this points to one of our greatest content weaknesses, which is that of portraits. Simple people.
Most of our Featured Pictures of people are historical portraits, or pictures of activity, or “exotic” travel photography. There are relatively few that would show the everyday life of the photographer or their family, even though these are the photos we would have the most time to practice and perfect.
Maybe in another six months, or a year, or two, the situation will change, and I will be able to show off some loving attention paid to the very domestic and everyday situations that surround our excellent photographers.
- Not the Wikipedia Weekly has arrived at Episode 3., in four parts. The first three parts are mostly talking to Sue Gardner, the WMF Executive Director. The last part contains some excellent discussion with Mark Pellegrini about scientists, journals, copyright, Wikipedia, free science and free culture.
- MediaWiki Easter egg hunt: There’s a SUL pilot coming up! (I confess I stumbled across something SUL-like in my Commons prefs last week, and now it is gone.)
This is a preview of what the Commons upload form may look like one of these days… if I have anything to do with it :)
Things to note:
- separate fields for separate pieces of info
- pop-up tooltips (one pointed at), providing extra information about what info is expected, without crowding out the form
- categories are added via HotCat, which means you don’t have to know the name of the category before you start uploading (!)
- the license preview is also provided via a tooltip, so you don’t get the annoying “jump” of the default form (licenses also tend to take up rather a lot of space, and a tooltip can be dismissed, unlike a preview)
- there’s now a preview button for the whole page (unfortunately not the actual image — that will require MediaWiki hacking directly — but all the text)
I love this form :) Try it yourself, if you’re logged in at Commons.
I have subscribed to the RSS feed for the Featured Pictures category, so I frequently have the latest and greatest pictures from Wikimedia Commons weaved among the more mundane feeds on my feed reader. There are some really spectacular finds, and today’s latest caught my eye.
What does anaglyph mean? It means get out your red-and-cyan 3D paper glasses, baby! :D
Commons even has a category of such images – 270 and counting. Wow.
As far as I know, it is the first anaglyph FP. A cool milestone. I love when a project is so big that you can get a great surprise by some activity going on in earnest in another corner that you had no idea about.
- OggSearch: Slick toolserver-based search specifically for Ogg audio and video on Commons. It also uses the plugin player so you can play directly from the results – without visiting the Commons page. Bryan = awesome. :)
- Seems like Commons finally has a media move/rename bot. About time…
- Durova has been working on a really cool encyclopedic image restoration project. Give her kudos, ideas and help! This kind of thing is a shining example of Wikimedia culture at its best.
- The Signpost has a useful brief WMF overview of 2007
- Wikitravel has announced Wikitravelpress. Congratulations to Evan and the communities he has facilitated.
- OMG, there’s a new skin! It’s pretty nice. I’m tempted to swap…
- Sue has started a trial of sending her reports to the Board to foundation-l as well. Awesome. See her report for late December. I have to say that since my last post about the institutional feeling at WMF being one that was closed and swirling with change, it has changed dramatically in the four odd weeks since then, largely thanks to how the Kaltura discussion was handled, this post from Sue and numerous initiatives from Florence. It’s very heartening. Although change is still very much in the air, it now feels so much more right.
This year’s winner has much less of a “wow” factor than last year’s Aurora Borealis. It marks the first time for a Wikimedian to win this honour (although, an absent one).
Full results are available here.
Much of the work at Wikimedia Commons revolves around identifying and removing copyright violations. So it is unusual to find that someone copyio’ed our content rather than the other way round.
Few days ago I got e-mail from London. The guy e-mailed me that he saw my image of a puffer fish at the posters advertising Kleenex in London tube. I asked him, if he could take an image of this poster and he was kind enough to do it for me. He e-mailed the image of the poster to me. There was my fish at this poster all right. I felt “all puffed up” and I e-mailed to Kleenex for the explanations. Today they called me. They admitted they took my image from Wikipedia and they told me that the artist, who did it, was told that Wikipedia is the place to get free images. [..] They apologized, they are going to pay me 700 Pound sterlings, send me the copy of the poster and a letter with the admission they violated my copy rights. My main condition was that I did not want them to punish the artist, who I sure, has not had a bad intention and took my image by mistake.
LOL. I’m pretty sure taking the time to read the license would have been cheaper than £700.
Well. After 31,000 votes were cast by over 650 users, I’m sure glad we didn’t count by hand this year. :)
The votes are in, the sockpuppets are discounted, and the finalists are decided. Twenty-eight worthy finalists await your consideration.
Voters cast, on average, about 48 votes. Over a third of voters chose each the tower, the squirrel and the turtle. Water strikes me as a strong theme, being present in 13 (nearly half) of the finalists.
Works by Wikimedians also dominate. Only four of the works are by non-Wikimedians: two from Flickr (the car and the NYC night shot), one (the mosquitoes) is from a Public Library of Science biology article, and one (the firefighting) is from our old friends at the US Air Force. So the odds seem good that this year’s winner wil be by a Wikimedian.
Of the 14 images created by Wikimedians, no less than three photographers have two entries:
- Malene Thyssen has the brown bear and the Egeskov castle
- Luc Viatour has the two cool green plant shots
- David Iliff has the Colosseum and the Palace of Westminster
It is no coincidence that seven of the Wikimedian photographers are featured on the Commons Meet our photographers page!
As with Round 1, eligible Wikimedians can get a voting token at the Voting page. Unlike Round 1, in the final you can only cast one vote. You can also optionally leave a comment about the image you vote for. The comments are collated for the presentation of the final winner, as seen in the 2006 results.
There are a huge 514 images in contention, all of which became Featured Pictures (FP) during 2007. This is the second year the competition has run. The 2006 competition had around 350 images, so there has been a very impressive growth in the FP process during 2007.
When the competition was first proposed in late 2006 I was quite sceptical. But when I saw how much everyone enjoyed it, and what a good opportunity it was to demonstrate some things that Commons is doing really well, I was converted. It sounds shallow to say that it is a feelgood exercise for Commons but if people from other wikis come and spend some time looking at our images, and feel impressed or enjoy the experience, it can only be a good thing that they will take that good feeling about Commons back to their wiki.
So, I put a lot of effort into organising this one. As a result I am a core committee member and have dealed myself out of the right to vote. And we have complete translations and committee members in a dozen or so languages, and I am so indescribably happy that Japanese is one of them. I really hope it will encourage more Japanese speaking Wikimedians to participate at Commons.
So anyway, the point is that I CAN’T VOTE and therefore YOU MUST TAKE PART ON MY BEHALF so I can experience vicarious joy. :)
Round 1 is open for a week. Any Wikimedian with > 200 edits in a single account is eligible to vote. I will probably post a couple more times about it before it is over, so for now, all I can say is please vote and please enjoy it. :)
Today I am guest-blogging at the WMF fundraiser blog, Wikimedia Commons: The Power of Free Content Media. I am not sure if I am happy with the piece or not. Maybe there are too many leaps of logic. Maybe not. I was happy to find natural ways to give links to all the Wikimedia projects except for Wikispecies. :)
I considered writing something more “promotional” but it seems a bit pointless when 99.9999% of the world has never heard of Commons. It’s certainly useful within the Wikimedia community, but for the outside world it seems best to let the success become self-evident.
The other thing is that Commons is seriously unusable. :( I can’t in good conscience encourage non-Wikimedians to flock there. I sincerely hope that at least some of my software requests will be implemented in 2008.
The first couple of posts in the fundraiser blog got hundreds of comments. Seriously, 405... that’s insane. It seems to have died down significantly now, which might mean the novelty has worn off, or people are just busy with their holidays now. The voices who responded on the blog seem very different to the voices that I typically see on talk pages on Wikipedia, so it seems like the blog was maybe an outlet for people who appreciate Wikipedia but don’t feel able or are unwilling to contribute to it by editing.
The end of the year is typically a time for reflection and planning. Planning is much easier than reflection :) so here’s my list of the top ten MediaWiki extensions that Wikimedia Commons (hereafter, just “Commons”) needs.
Ah, SUL. No acronym brings wry grimaces to the face of a Wikimedian better than this one, and perhaps no issue better demonstrates the consequences of the Wikimedia Foundation’s shoestring budget. Bug 57, Single user login, unified login, CentralAuth — whatever you call it, it should mean that an account created at any Wikimedia wiki allows one to log in at any Wikimedia wiki. Promised since at least 2006, you can currently take part in the testing at test.wikipedia, so there is progress. The full spec is on meta at Help:Unified login.
Why is this relevant to Commons? Because it’s the most likely wiki that editors are likely to use after their “home wiki”. SUL can reasonably be expected to indirectly promote uploading at Commons for Wikimedians, as another barrier to doing so is removed. (Spare a thought especially for the Spanish and Portuguese Wikipedians, who have disabled local uploads entirely.)
#1. Image search
AKA inbuilt Mayflower. Mayflower exists, is open source, and rocks the socks of everyone who uses it. All that’s needed is for some bright spark to specialpage-ize it, and then a little fairy dust to have that as the default search engine/page to be used within Commons.
#2. Multilingual categories/tagging
Commons is a multilingual project, but since category redirects don’t work as desired, any given category can only work if everyone uses the same name. The category needs to “work”, so that a visitor can go there and expect to find all the media relevant to that concept. But the redirect/alias bizzo also needs to “work”, so a user can tag /categorise their files using their native language.
The urgency of this task is the great shame of a multilingual project having to enforce a single language description on its users. Seriously uncool.
#3. Rating system
Someone did contact me about making progress in coding this up, but I haven’t heard a progress report lately, so it’s definitely something I need to follow up. As Commons grows, it becomes the case that for any given query there may be dozens or even hundreds of relevant files. So having a rank-by-quality or rank-by-average-rating option in the search engine can make a dramatic improvement to the search results.
People love rating stuff, so hey, free data on quality. Off the top of my head I can’t think of any other image database that has a rank-by-rating option but I would be pretty surprised if no one had done it yet.
#4. SVG editing as text
#5. SVG display – pick language labels
#6. SVG display – animated SVGs
These three are naturally related, and arise from the project that’s currently occupying my thoughts (if not my time). SVGs are like the wiki version of an image, as I recently said, because they are so easy to edit. You can open a SVG in a text editor and twiddle with it and save it, and you’ve got a brand new SVG.
But, that’s kind of annoying if MediaWiki wants you to download the file first, and then re-upload it again. Instead, it would make more sense to be able to edit an SVG in a wiki page — exactly the same in fact. Have the edits be recorded in the image history just like text page revisions. It would be a little bit tricky because you would still want to retain the ability to upload a new version of the file, but is surely doable.
From there, it should only be a small hop-step-and-a-leap to a special page extension that allowed one to easily translate text labels inside SVG diagrams.
Take for example this diagram of a biycle. There are currently five different files: Bicycle diagram-en.svg, Bicycle diagram-es.svg, Bicycle diagram-fi.svg, Bicycle diagram2-fr.svg, Bicycle diagram-pl.svg. But there is no need to have five different files. Instead, it would be better to condense all the labels within a single document and extend the image syntax to allow something like this:
So the main part of this request is for the image syntax extension. A tool could be hacked up fairly easily for easy label-translating on the toolserver, I think, although of course it would be preferable within MediaWiki natively.
#7. Gallery preview
The idea of InstantCommons is to let any MediaWiki wiki use Commons media as easily and transparently as the Wikimedia wikis do — that is, ‘‘as if the media were uploaded locally’‘. Such a feature would be of immediate interest to Wikitravel and Wikia, both non-Wikimedia projects, and really be a huge leap forward in Commons’ success at sharing free content.
Current status is unknown, but there’s some code in SVN.
#9. Native CheckUsage
As a consequence of #8, this one becomes much more pressing. CheckUsage exists on the toolserver and tells you in which projects a Commons image is being used. Indirectly that tells you how many people you’re likely to piss off if you delete the image without delinking it first.
This is basic necessary functionality for the Commons community. It would be like if you removed the ability to unblock users. We have the ability to do the damage, but we also need the ability to survey the scene and minimise it. So, it is an uncomfortable situation that we rely on half-hacked-up tools for such a critical task, and it would only be moreso the case if InstantCommons was enabled.
ImportFreeImages allows the user to search Flickr and transfer an image locally all within MediaWiki. Because Flickr enables Creative Commons licensing, it is a major source of freely-licensed media. But there are two problems. One is that Flickr also allows non-free licensing, so we have major headaches in teaching people the fine distinction between tiny icons. The second is just that it’s annoying to have to manually save the image locally, upload it again, make sure you copy all the relevant author info and so on, and asking people to do that leaves a lot of room for mistakes.
So ImportFreeImages saves all those problems, and because you can restrict which licensed-images you want it to show from Flickr, you can solve the licensing confusion as well. It acts as a filter on Flickr, and just makes the whole thing a breeze for the user. So — awesome.
There are at least 55,000 images from Flickr in Commons at the moment. (Around 2.5% of the total.) It’s common enough, and causes enough confusion, that the community has built a plethora of tools to try and make it easier:
- Flickr upload bot in conjunction with a toolserver tool
- FlickrReviewR bot trys to automatically confirm any Flickr licensing claims
- Trusted users double-check any that FlickrReviewR couldn’t automatically confirm
(The main reason Commons instituted the flickrreview system was because Flickr lets people change their licenses without any kind of historical display, which is seriously uncool, as far as trying to figure out if a stated license was ever valid goes.)
If we had ImportFreeImages, we could more or less forbid people from manually uploading Flickr images, and goodbye Flickr hassle!
So that’s my list. There are other things that I want, such as structured data, but I don’t really see it as likely to happen by the end of 2008. 2010, maybe. These ones all seem within reach (OK, with the exception of #2, but you have to dream big, right?). If there’s anything you think I missed, drop me a note and let’s hear it.
There is a profound movement that in recent years has changed the way everyone uses and understands the web. I am talking, of course, about lolcats.
Lolcats have been around for a while, but I had my attention returned to them recently when I discovered LOLpols (politicians). Australia just had a federal election and the results are much to my liking, so I was feeling inspired.
(This is Maxine McKew, a “star recruit” who campaigned her butt off to win the Prime Minister’s seat, which is an impressive feat in anyone’s book.)
Let the lolcats be free!
I am proud of this one because I think the cat really is investigating the sock quite thoroughly. :)
Now inspiration is spreading:
© Gurch, CC-BY-SA.
© bainer, CC-BY-SA.
© Gracenotes, CC-BY-SA.
Very clever. I wonder if we will end up with a lolcat for each major policy?
Tonight I realised the natural progression of this theme: the LOLjimbo.
“no sé qué licencia aplica”:
© Stephan Baum, Sanbec, ttog, CC-BY-SA-2.5
It is commented sometimes that Commons is a haven for a particular variety of wikilawyering known as copyright wikilawyering. It is one of the most irritating types of wikilawyering to be on the receiving end of (and I have, several times), because for Wikimedians there is no trump to the “non-free content” card. It can seem utterly petty and pointless.
But (although we don’t have to be jerks about it) we have no choice. There are two ways to protest the current copyright system: use the existing system to subvert the traditional conclusions from within the system; or fight through courts and parliaments to have the system changed. If you use Creative Commons, or like to think of yourself as part of the “free content movement” like Wikimedia does, then you are part of the former.
And if you choose to play the game, you have to play it better than anyone. You accept the limitations as soon as you deal yourself in, and you work within those parameters. And that’s why you learn about freedom of panorama and sadly find yourself applying it to all kinds of previously-thought-free scenes. Just as Wikiquette has “Assume good faith”, Free content has “Assume unfree content”. They play off each other uneasily at times.
The benefits of this approach, of playing the copyright game, are that anyone can do it, today, right now. They can give up some of their copyrights and let people copy their work as suits them. Fighting in courts and parliaments is expensive and difficult with no great hope or guarantee of victory.
It would be nice if our lawmakers would go back to the drawing board and write a new copyright that made sense in the era of the Internet, but all efforts to “fix” copyright since the passage of the US Digital Millennium Copyright Act (DMCA) in 1998 have only made things worse, granting more unenforceable exclusive rights to an ever-increasing pool of “authors” who have no need or desire to sue the people with whom they are engaged in the business of “culture” — holding conversations, publicly re-imagining the stories that make up their lives.
Creative Commons aims to do what Congress won’t or can’t do — offer an approach to copyright that helps those of us who don’t want deal that Disney and their pals have insisted on for every snatch of creativity. Creative Commons achieves this through a set of licenses, legal notices that set out permitted uses for creative works.
In explaining the benefit of Creative Commons, he also exactly highlights its weaknesses. Lawmakers have failed us (most jurisdictions worldwide now have ridiculous copyright terms). Creative Commons is a soothing non-answer to this failure.
It reminds me, in a strange way, of how the media promotes outrageous ideals of beauty for women, and many women feel it is their personal failure for not meeting these ideals rather than the extremity of the outrageous system in the first place. It’s the twisted system that needs your attention, not your personal behaviour.
I like Creative Commons. But I wish I had an angry noisy anti-copyright-system movement to go along with it.
Virgin Australia has been hit with a lawsuit for its use of a photograph from Flickr in an ad campaign. The girl in the photo is underage and her-friend-the-photographer naturally didn’t get any kind of model release before licensing the photo CC-BY on Flickr.
Lawrence Lessig has a copy of the lawsuit on his blog which explains why Creative Commons has been named as a party in the lawsuit. It basically amounts to “they didn’t explicitly warn me something like this could happen”.
My thoughts are that I’m glad Virgin is being sued over this. They were jerks to use this photo in the first place. I understand that stupid multinational corporations can use works I license under CC licenses, but I’m happy they’re being pulled into line. I think CC being named in the suit is just misguided, but maybe it won’t hurt for the licenses to be tested in court. :) Is a URL without a username sufficient attribution?
Second thought. This confirms my belief that conscientious photographers should avoid CC licensing photographs of people. I would never CC license a photo of my friends. Famous people are fair game.
Third thought. I hope this inspires CC users to read up what they’re actually agreeing to. Like something interesting I discovered: the version 1.0 licenses have this clause:By offering the Work for public release under this License, Licensor represents and warrants that, to the best of Licensor’s knowledge after reasonable inquiry:
1. Licensor has secured all rights in the Work necessary to grant the license rights hereunder and to permit the lawful exercise of the rights granted hereunder without You having any obligation to pay any royalties, compulsory license fees, residuals or any other payments;
2. The Work does not infringe the copyright, trademark, publicity rights, common law rights or any other right of any third party or constitute defamation, invasion of privacy or other tortious injury to any third party.
Hm, well that makes all my CC-BY-SA-1.0 releases invalid, because I sure as hell never checked those things. And I sure as hell don’t intend to. Happily, CC seems to agree that those things don’t in fact belong in copyright licenses.
On the cc-community mailing list, there has been a killer thread about what “NC” (non-commercial, as in “this photo can be used for non-commercial purposes”) means (entitled “What does NC means?”). Many people are confused about this, and CC doesn’t seem in any rush to clear up the confusion. They seem happy with the poorly defined but vaguely comforting terms. Terry Hancock writes eloquently here about how NC and ND licenses betray the tradition that the “commons” part of the Creative Commons name lays claim to.
There seem to be plenty of people within CC culture who are pissed about this, but CC doesn’t seem willing to act to even encourage people towards freer license terms. They emphasise the clarity of “choice” to the individual licensor at the expense of benefit to the commons they purport to help create. It is kinda annoying.
I am starting to think we need a http://www.NCandNDarenotfree.org/ with arguments and polite form letters that people can send to probably-misguided NC and ND license users. Especially people who set site-wide licenses, like wiki administrators: these people need a clip around the ear if they choose a NC or ND license. Well, first they need a persuasive argument, then if they persist, the clip. It could be like GNU’s campaign to end Word attachments, Although they appear to have lost the war, but small individual battles are won each day.
And the last mention must go to the recent iCommons iHeritage event, celebrating South African Heritage day. They were uploading media to Wikimedia Commons and Flickr. There is probably still a bit to go as they were recording audio as well. I helped out a bit by creating some help files on Wikimedia Commons.
I’m sure there is much more content on Flickr. I can’t really blame anyone who chose to upload there instead of Commons. I suppose the good thing is our Flickr transfer service making copying them over nice and easy. :)
I wrote an article for the iCommons newsletter, which is probably due to come out soon, and in the meantime it’s been published on the iCommons front page. (I don’t quite know how the voting works but I suspect it got some behind-the-scenes tweaking to push it through…) In the meantime I thought it might be useful for the Wikimedia Foundation wiki , hopefully as a decent introduction for people who’ve never heard of the project.
I am nothing if not a diligent recycler!