The need for community APIs

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.

I went on-wiki and checked it out. It turned out that some bright spark had decided to move the entire category to Category:Featured pictures on Wikimedia Commons. The correct feed is now here.

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)

11 August, 2008 • ,

Comment

1

Freebase uses the WP dumps, extracts them into a semi-structured form (see http://download.freebase.com/wex/), then uses that to extract 'facts' to feed into FB. There's a quite interesting presentation on the topic at http://blog.freebase.com/2008/06/10/brian-karlak-on-mining-wikipedia/

Kirrily Robert · 12. August 2008, 02:37

2

Oh... bah. I even knew that. That's what I get for giving in to the temptation of exaggeration... contradiction. :)

pfctdayelise · 12. August 2008, 14:50

3

Appropedia:Moving category pages ... it's fiddly, you need to be an admin, and you still need to edit all the pages in the category, but at least the history is preserved.

(I put it on Mediawiki.org too -- it got moved, but it's there somewhere.)

Textile markup?

Chriswaterguy · 16. August 2008, 15:32

4

@ Chriswaterguy,

Meh, most category pages don't have a history really worth preserving, so I find your procedure fairly overkill. IMO the killer thing about moving a category is the editing-each-page-in-it part, not the lost-history part.

(Looks like you got the hang of the Textile markup btw :))

pfctdayelise · 16. August 2008, 20:13

5

You’re right about the value of editing-each-page thing. Building semi-automated editing into the wiki itself is one approach, so bots become less necessary… not the best solution for this particular issue, but it prompts an interesting thread of thought, which I’ll blog on sometime soon.

There are times when the category history is important – depending on the structure of the wiki. Appropedia uses categories for topic content (so that how-tos and project write-ups can be listed under the topical info about the category) but there’ll be a better solution in time. Probably Semantic MediaWiki.

Re Textile – better than most other markups I’ve seen, but I think I still like the idea of reStructuredText best.

Chriswaterguy · 18. August 2008, 07:56

6

reStructuredText looks OK, although the link syntax seems pretty bizarro. I hope WikiCreole takes off any time soon.

I only use Textile because my blog software is Textpattern.

pfctdayelise · 18. August 2008, 13:12

Elsewhere on the web...

Commenting is closed for this article.

list of all posts, ever

find articles by tag

monthly archive

most popular articles

  1. [guest] Rethinking the Top Ten
  2. How to use Gmail to manage high-traffic mailing lists
  3. An alternative term for "User-generated content"
  4. NLA Innovative Ideas Forum audio/video now available
  5. Write API enabled on Wikimedia sites!
  6. Top 10 software extensions Wikimedia Commons needs in 2008
  7. Is mass collaboration all it's cracked up to be?
  8. GLAM-WIKI, day one
  9. Free MediaWiki hosting offered by Dreamhost Apps
  10. Reflections on PGIP phase 1

(from the last 30 days)