I was reading my feeds a few weeks ago when I realised it had been ages since I’d seen any images come through on the category feed for Category:Featured pictures. I was sure FPs wouldn’t have gone anywhere, so I thought maybe the Catfood tool was broken.
MediaWiki at its base is almost entirely structure-free. The value comes from the structure created by the community, via categories, templates and links. The good and bad thing about that structure is that it can be easily changed. If Creative Commons releases a new license version, we can quickly incorporate that (well, if we want :)). But if someone decides to rename your category (and because categories can’t be renamed that actually means instructing a bot to manually edit each page in the category), if you’re a third party, you’re not going to notice.
Free content is only as good as its search ranking. Creating free works is good, but encouraging easy and innovative re-use is just as important.
For English Wikipedia, it’s not a big deal. They are already a destination. They don’t need people to take their content and use it elsewhere. They are a big enough gorilla that it doesn’t matter. For maybe five or ten other Wikipedias, it’s the same situation.
For every other project under the Wikimedia umbrella — we have serious problems.
Creating free cultural works is pointless if nobody knows about them, if nobody uses them. Maybe wiki-editing for yourself is soothing technological masturbation, but don’t pretend you’re helping anyone else.
So, search ranking. Part of the problem is that our projects often tend to be broad and all-encompassing. For example, if I’m researching Lewis Carroll, there are probably fan sites that only have Lewis Carroll content. Those sites will have much higher search rankings than Wikisource, which carries a few Lewis Carroll titles among hundreds. Unless you are, like, literally Wikipedia, being all-encompassing is not good for search rankings.
Second thing. Practically the whole point of the wiki thing is for people to be able to interact with the things we create. Anyone can edit. But that’s not enough. We should be working more on enabling people to interact with our works in a way that suits them. Currently we only support coming to our site and editing using our software and our syntax. (OK sure, we offer dumps, but have you ever seen anyone do anything with them besides create a mirror?) That’s lame support. Again, Wikipedia can get away with it, but the rest of are not so lucky. We shouldn’t be complacent and think that we’re doing good things. Doing good things is only half of it. People using them is the other half.
(Brief aside about APIs. If I tell you API stands for Application programming interface, that probably won’t be very enlightening. APIs are the things that enable mash-ups. They are the things that enable widgets, like thumbnails of your latest Flickr uploads on your blog. Or any of those Facebook applications. They would all be thanks to APIs.)
MediaWiki has an API. Write capability is slowly happening. Write capability is really cool because it means then you could edit a MediaWiki wiki without touching MediaWiki at all. Imagine that. You could build your own interface and make it as cool as all get-out. Like what? Oh, how about Flommons? That’s “Flickr-like Commons”. If that had write capability that would be pretty damn neat.
A good API is powerful. I signed up with identi.ca, Evan Prodromou’s baby, virtually as soon I heard about it. Evan choose to copy the Twitter API. That means that all these cool add-ons, toys, widgets, whatever, all those cool things that work off Twitter data, can instantly work off identi.ca data just by changing one line of code — the URL of the API.
Now imagine if the Commons API emulated the Flickr API. We would have an instant, humungous load of ways of easily distributing our content just by changing one line.
And because we (potentially) have a lot more metadata than Flickr, that would just be the start. We could extend it hugely.
Sure, parsing the descriptions is messy, but we keep the messiness on our side. It’s our thing, we’ll deal with it. Everyone else is welcome to just deal with our neat, stable community API.
C’mon, is there anything more sexy than a good API? :)
My previous post about the Commons API: APIs: Ask, and ye shall receive (01 April, 2008)
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.