An Idealized Re-Design of Collaborative Databases


What would an ideal system for collaborative document sharing be like? In particular, what might an individual want to have for a family site, or a college class site, or a personal site? Can a same system satisfy all those wants? Is one technically feasible?

I've had this web site for a few years and I'm wondering what to do with it. I originally expected it to develop non-hierarchically and non-linearly (maybe like e2), and believed a wiki engine would have less influence on the content than some alternatives. Blog engines, for instance, publish sequential notes and tend not to provide controlled access to publications; school notes and project reports and such needed some re-ordering–and co-authoring– and could only be shared with classmates, instructors, and so on, so using a blog for that would have been challenging. It has turned out, though, that it is mainly hierarchical, due to use for school but not only. Other publishing systems, such as spip have some fine features for publishing with a little workflow management and translation management, but no access control once content is published (unless I missed it, or it has been added in the past few years).

The past decades (yes!) have provided many opportunities to use various computerized systems for producing, sharing and modifying what may generically be termed documents or resources. These may be push systems such as electronic mail and instant messaging; pull systems, such as web sites of various sorts; or systems which are both, such as mailing lists with archives to consult and web sites with RSS or Atom feeds. Another aspect of differentiation of systems is access control, whether to publish, to consult, or to respond: who can send, who can be allowed to read or prevented from reading, are comments allowed with or without moderation, is identification required or is anonymity allowed.

These experiences have revealed a large range of problems and questions, many of them unanticipated, at least by many users. They have given rise to a vast portfolio of intellectual property contracts for software, documentation, and other original content. They have drawn attention to the difficulty of ensuring privacy, limiting distribution, and retracting publications. Each of these topics merits an essay (or more), but treating these questions is beyond the scope of this note.

For various reasons1), I'm wondering whether I want to continue to use DokuWiki to manage it, find something else, or try to write my own site management system 2) I suppose I'd like something like a non-push email, wherein I could save drafts, send to the whole world (or to lists of my choosing) but only if they come read.

Since starting this site, I've also had some formal training and education in software engineering, learned a bit about composing documents with LaTeX, started using emacs org-mode. I hope all that will contribute to my doing a better job of the rest of this note. Idealized design (or idealized re-design) refers to a planning and project management framework proposed by Russ Ackoff, in which the starting step is to imagine the most ideal possible state or solution possible with proven technology, then finding a way to achieve it. It deserves an article, but is of general interest so will not be further treated in this note but elsewhere.

Table of Contents



anyone who can –and does–add content, whether it be texts, photos, other media files or links, whole pages or bits.

Privacy and Selective Publishing

Author's Right to Limit Access

Ideally, an author should be the one who chooses the scope of the intended audience, and no one else should be authorized to extend that scope. 3) Authors might also wish to specify the timeframe (start date, end date) during which the document would be accessible.

As noted below, this would enable the author to keep and update draft documents before sharing, a feature not available on wikis I've used.

It would be helpful to propose categories for publication audience. This could contain different types of categories, and the difference should be apparent: groups whose composition the author controls, groups whose composition is controlled by a party the author trusts, groups whose composition is at least known or knowable, and public. Examples of the first category, groups whose composition the author controls, could be nominal lists of individuals, or the circles one can compose on Google+, or friends on facebook. Trusted groups out of the author's full control might be friends of friends on facebook4), or a managed group of users of a wiki or other collaboration system.

Editorial Control

A moderation scheme, such as is common for comments on blogs, might also be desirable. In that case, an editor might be allowed to reduce the scope of the audience or the timeframe. For example, an author could authorize publication to the whole world forever beginning next week, then the editor could limit availability to paying subscribers for the first week, anyone logged in for the following three weeks, back to paying subscribers (archival access) from then on. The editor might also wish to allow some readers to see only part of a publication while others could see all.


These decisions might be expressed as states of a document (or subdocument) rather than date ranges: draft, submitted for editorial approval, published to subscribers, published to all (or some other list), returned to author for revisions, delegated by author to co-author(s), and so on.

More On Permissions

In the workflow examples above, which correspond to real, working systems I've known, a document typically has a set of attributes or properties at each point in time listing:

  1. State
  2. Owner
  3. Authors
  4. Readers
  5. Editors (or admins)

In the systems I've known, the authors had very little control –if any–over their privacy. But one could want a system in which an author keeps drafts, documents not ready for sharing, at least for a while. This could be achieved by applying a “draft” state, or a “share with: self from ddmmyyyy to ddmmyyyy” choice, with some mechanism for dealing with the document after expiry.

1) Dokuwiki developers continue to add features. I'm not sure I need new features. Everybody has to have AJAX search boxes now, but is it really necessary? Is jQuery required? With each update, there are backup copies to make, tests to run, sometimes changes to make in CSS…so I tend to put off doing them. AFAIK, Dokuwiki does not have “save as draft” and some user management features I'd like, which I'll say more about further along in this document.
2) Yes, I have some idea what that entails. Four of us built a smallish, specialized file submission system with limited workflow as a school project a couple of years ago.
3) Unless, perhaps, the author delegates or cedes that authority to others: how might that work?
4) with possible recourse to the blacklist of individuals, if one knows who among one's friends' friends should be screened out
cms/begin_document.txt · Dernière modification: 2013/05/31 17:53 par suitable
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante :CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki