And so on. I will add to this list incrementally.
Is wiki useful for serious documentation?
Slashdot posting I made to a 'Ask Slashdot' question: Community Driven Documentation for Free Software? ( My post: Virtual Document: Distributed document editing ).
The discussion was towards whether or not wiki is a good way to do the documentation. Many people feel that it is a bad tool for documentation.
Documentation has more to do with a specific process, and especially so, for Documentation in collaborative, open-source like environments. The community has not matured in this respect, unlike, say, development of software.
What is required is a capability to allow document to be "Virtual" i.e. it is picked up from independent editable pages. This is very much like FAQ-O-Matic, but wiki can help in presenting a proper document structure by including different parts of document from different editable pages.
And each editable page may have a section, or couple of sub-sections. It may have owner or may not have owner. But all contributers may have to learn more than typical wiki formatting - to make sure that the document structure remains intact. And if the wiki tools can ensure document structure compliance by users, we should expect the strategy to result in good document.
As a general remark, the patterns for distributed management of shared information have not yet emerged - in contrast to individual communication tools such as email. Discussion boards are too simple to be useful in this regard; information management is key part of information sharing.
And since people tend to share information more easily in one-to-one emails, we require some good directives to be used during email composition, so that the data can be pushed to shared area. (And how you can format so that it can also be managed, is an interesting challenge.)
Update: This mail about use of wiki for documentation for Zope 3.
Neverthless, the models do influence how you can manage the information. Relational models are solid and proven. But then we also have Treel models (in LDAP), and general trend towards shared information model by multiple applications. Approach of SAP, PeopleSoft etc. is to hide even the relational model (with their supplied schemas), and provide an application layer for integration - but most such integration is custom-made.
In IMV, we believe that graph is the "right model" of data (and metadata), and like LDAP's tree model, it is the next generation model. Views are integral to these, and the actual mappings to underlying Database layers could be hidden. Query mechanisms in graph data will have to be developed, and may not even be optimal. How exactly DB technology can be used as underlying layer is yet to be seen. LDAP itself has not been deployed off DB's; most ldap servers use DBMs (i.e. table model of data).
And on the subject of Information Management, another link: Zen, flow and emergence in information models.