OOWiki
Here are some rough notes in advance of talking about "A Smarter Wiki" at MooseCamp? on Feb 23 (see http://wiki.northernvoice.ca/Moosecamp2007)
A wiki is a big flat namespace of content objects. You navigate it by object names. Ward says "Wiki is a system of names."
In the interests of "the simplest thing that could possibly work," wiki objects have traditionally been text files (or worse, strings).
There is no typing. In the mainstream wikis—C2, Wikipedia, etc.—structures like tags, categories, indexes, people, etc. are all implemented by just using wiki pages with a naming convention. This works. But it's very limited. Note that Mediawiki starts to experiment with "namespaces" to gain some leverage here.
Basic wiki object model:

This raw material is actually quite a bit. It is sufficient for reference/documentation wikis; blogging platform (OrganizingPrinciple); and even a CMS, if used with a well-understood set of policies.
But... seems to me this is also a very decent basic object class to build a CMS around. Rather than thinking of CMS in terms of modelling content workflows, just start with a collection of content objects that have wiki functionality. Then build out... If this basic page object is the base class, then specialize it where needed.
Some trivial examples of such subclasses, driving custom views, navigation, edit templates, etc.:
- Reference pages
- News pages
- Comment pages
- User pages
Ideally, the business of subclassing content types should be as simple as possible—something that can be done in the browser, ideally. The only system that really gets near this kind of flexibility is Pier.
An alternative direction might be to simply tag pages (in the Web2.0) sense, but write conditionals into the page rendering so that certain tags (say, "blog post," "person," or "approved") would result in particular template or stylesheet options (this is more or less how TKBR's blogging support is implemented). This is much less robust than actual subclassing, but it has the advantage of extending right into user space, which is where is ought to be.
