Row and column based access controls in wiki tables
For last couple of weeks, I have been working on row and column based access controls in tables in wiki systems. Topic owner should be able to give selective control over rows and columns to people.
More on this little later in this write up, but consider why tables are important in wiki. When you setup a wiki topic with table definitions (like EDITTABLE in twiki), it becomes very easy for people to add information: They don't have to worry about wiki aspects. This method helps you get contributions from people in organization much more easily. You don't even have to expose the fact that you are using wiki systems. Moreover, organization of information in tables is far more pleasing than (say) lists. And I normally attach columns such as 'last updated' and 'who filed the info'. These help in tracking the age of information, and also, make sure that you indirectly track ownership of information. At the end of the day, the information systems should be able to connect people together (especially in large organization).
My earlier successful attempt in this was to collect a large number (about 5-10 per topic, and 15-20 topic) of skillsets from about 300-400 people in just one afternoon. And we could create this in half a day - primarily being able to put special markup for Poll Plugin in twiki. And though the system was under a lot of stress (leading to high latencies), it never failed.
My effort in table access control is multi-fold: Focus on free-form collaboration, Be able to create ad-hoc processes, create semantic networks (see notes on IMV elsewhere in my weblog), and synchronization based approach towards information systems - to reduce schema management overhead in large organizations. I will comment on only one aspect here today. First, a quick overview of capabilities I experimented with: Specify acl attributes in table definition. For each column, specify who has access controls - something like 'owner:rw,boss:rw,mygroup:ro,all:rn'. This roughly means: Owner (or row, column) should be able to read+write, my boss (boss is usedid here) should also be able to do rw for all rows/columns. My group should be able to only read the rows/columns, and everyone should not be able to even read. (I also defined 'rb' - means, show the row/col as blank.). Columns can therefore be turned read-only, or may altogether disappear for some users. Similarly, rows ('owner' column contains the row owner) can be made visible to only owner and groups. It is even possible to allow users to specify additional 'ro' controls to some users.
Now let me put non-organizational use case: Suppose there are lot of wiki's around (a fact today) which support this model. The users define a table with schema definition pointing to some centralized website. Consider 'favourite movie' list as a wiki table, schema coming from centralized site. I would provide access to only my friends - say I would specify email addresses in ACL column. For now, let us not worry about actual implementation of ACLs. But the effect is: (1) I provide information about movies and ratings that I like/dislike, (2) specify movie lists for which I want similar information from other friends. Assuming we have standard webservices etc. (i.e. parsing tables across the web), an aggregator (much like RSS aggregators) collects movie information from friends and shows as part of same topic.
How we could leverage RSS for this? The designs will become clearer once we get more insights. For example, I envisage a markup in written weblog text - such as: //addtotable:movies/The Matrix, rating=5/. This markup should update the stationary table on my webpage (only once!) with either addition or updation of a row. For more information, check out http://twiki.org/cgi-bin/view/Plugins/EditTable2PluginDev.
