Aaron Swartz recently announced that he was working on the Open Library project. The project is an ambitious attempt to catalog all books ever written using collaborative editing. Think of it as a wikipedia for books.
The whole project was developed by a small team of 8 people. Look at the list and you'll come across Anand Chitipothu. I had the opportunity to meet Anand again at BarCamp Bangalore 4 and we had a discussion about the project.
Anand has been spending most of the year working on the Infogami codebase. Although Infogami has not seen an update in ages and is pretty much dead, Anand has been working with Aaron behind the scenes in completely revamping the codebase. The Open Library project is built on this new Infogami codebase.
One of the cool things is that pages in the Open Library are not just a collection of unstructured text. You can actually store and edit structured data.
For example, a book edition (like this one) is made up of a number of fields. When you edit the page, you don't get one page to edit like you do in wikipedia. Instead you get specific input areas for each field. Click on this link for an example.
How does Infogami know what fields are required for a book edition? Simple. That metadata is stored in another page. The metadata for a book edition is here, for example.
So while the Open Library project uses Infogami to store information about books, the codebase can actually support storing any kind of structured data.
My take is that this kind of structured wiki will get a lot more popular in the next few years, especially in the field of enterprise applications. There are some other players trying to promote enterprise apps over a wiki — Jotspot (now part of Google) and TWiki come to mind — and Infogami looks to be another interesting application in this area.
What kind of enterprise app could be built over a wiki?
Here is a quick example: Take a resume manager. A lot of companies have built custom applications to store resume data in a structured format and later query the data when they have openings. Often, an app like this is a straightforward store and query style application. Enter some data - name, employment history, skill set etc and then query it out again later. Once in a while you may need to update a resume or do something else.
Building such an app is relatively straightforward, but a whole lot of work does into doing common things like the user interface, talking to the database and so on.
To build such an app over a structured wiki is simply a matter of defining a resume object and its fields and you are done. The wiki already implements the code for the UI and talking to the database and providing interfaces to add, edit and search the data, so you don't need to do that work yourself. Most of the wikis also have simple permission control mechanisms. Building such an app on top of a wiki would take a maximum of ten minutes.
Even better: If you need to run some custom queries and are willing to code a bit, you can plug a bit of code into the database interface and have the results show up on the page. Many wikis allow you to do that by writing macros that can be inserted into pages.
Using a wiki platform with custom macros can allow you to build these kind of applications in no time at all.
I can imagine a wide variety of applications for such structured wikis. To be honest, using wiki based applications in the enterprise is still very cutting edge, and enterprises are not the most enterprising when it comes to trying out new stuff (how ironic). For the early adopter crowd though, rapid application development on top of a wiki platform is something to keep an eye on.