I keep talking about Structured editing in twiki. Let me give more information about it.
By structured data, I mean typical tables, trees and so on. However, there is more to what I have in mind:
A render of a table in HTML will require different information contents. Wikis make it possible to edit these contents easily. First, let me list different contents:
- MetaData (Schema). These topics define what data elements can exist. The model that I have in mind is based on IMV - a graph like relational system with distributed data in multiple data sources.
- Data: Can come from multiple sources (especialy in wiki environment):
- Database, via a database plugin. Specific columns can be listed.
- Contents within the wiki page, as raw text, with delimiter such as '|'. Example: | email-id | Name | phone number. |'. This will have to migrate to YAML for want of completeness. For example, twiki doesn't easily allow multiple lines in a single cells. We have to use BR.
- Attached document, excel sheet etc.
- Virtual table, where individual rows can come from multiple topics. Twiki allows SEARCH, that can produce a table from data from multiple topics.
- Variety of views on tables already in Twiki. A set of tables together can provide organizational schema. The views may consist of selected columns and selected rows. The selections can in-theory be like SQL selects.
- Mechanisms to modify the data. The rendered views could be
- Style for the table. Individual columns should get their width info from style specification for individual columns.
- We require a clean system that will allow us to use variety of edit mechanisms on structured information. For example, 'edit' view on a table should probably introduce a column that will have 'edit this row' click button. On hitting it, you edit that single row.
- Access controls. Normally this can be specified with schema, and perhaps as additional columns.
The challenge is to enable wiki environments to create organizational schema and extend it on continuous basis. For a smaller organization, we shouldn't require a separate database.
And when performance becomes an issue, the database should be in shadow i.e. no user intervention should be required in managing the database schema. It should be reflective of the schema specified in wiki environment.
Wiki environment will make it simple to manage information in distributed manner. For example, a table that can be specified in a topic may have INCLUDEs that come from other topics. So if you consider a user table, different sets of users are managed in different topics (probably under relevant group), and yet, you can have a centralized user table by appropriate INCLUDEs.
And you require capability to include columns as well. Let me give an example: In one topic, I may maintain user-id, user-name, email, phone-no. In another topic, which is maintained by some other people, they want to create a table with user-id, name, email, project name, role-in-project, and so on (i.e. project specific details.) And only a subset of users may be defined (only those belonging to the project.). This task is part of schema management. Topics can define and extend the schema, and make them available to other topics that will let the table be managed by INCLUDEing the topic schemas.
Advantages with respect to databases are many. Traditionally, the schemas are managed by applications, and databases are used underneath. And you can't easily generate new views and reports. Some specialized applications do provide such capability. But they all require that a database be used and managed. And this requires administrators for that purpose. Wiki environments push this functionality down to users. As a lead for small group in a big organization, I should be able to extend the organizational schema for my purposes. Wikis will allow us to do precisely this.
I have tried to experiment these ideas in twiki, using a modified Pollplugin, and Template toolkit. Only user specific information could be collected (i.e. each row has user-id as its key field.) But that is just a starting point; and a lot of things need to be understood and implemented.
