Thoughts on Structured/Unstructured and Shared Information Management
using Wiki and other emerging technologies
What is the "right" wiki to install and use? I have experience with twiki. While I don't recommend it whole-heartedly, one should consider it seriously. Let me give various factors that you should consider to make a decision. And apply these to other wikis.
- Feature Set: Authentication, Access Control framework. Wiki is an environment that allows edits from web, and with a simplified markup, makes it easy to create and manage information. However, a typical corporate deployment will require a lot of other capabilities: Access control to pages, hierarchical webs, groups capability, and so on. You will also require authentication capabilities against sources such as LDAP servers. TWiki scores very well in all these. However, security is bit week.
- Feature Set: Plugins for Integration with other data sources: One of useful functionality of twiki framework is its capability to integrate with databases and other data sources.
- Deployment Environment.. Within an organization, you have to provision lot of users, make sure that performance characteristics are met. Security is another consideration. (And twiki has many security holes - Limiting access to a closed group.) If you are installing it with ISP, then you would typically want a CGI solution, which you could probably install in your area in the server. Twiki scores well in this aspect.
- Manageability
- Plugins
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.
James Britt's Weblog - on Information management and related issues is here: http://www.jamesbritt.com/
Sean McGrath's article in ITWorld.com: Realities of electronic information management . Do you have time to choose data models for the organization? And most of the data models are extensions of what was used for the very first time the information system was designed anyway.
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).
"Organization is a Giant Spreadsheet." - Vinod Dham, in: Economist.com: "How about Now". From John Rob's (http://jrobb.userland.com/2002/02/14.html) Weblog.
And on the subject of Information Management, another link: Zen, flow and emergence in information models.
