This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Notice: this page is a sketchy layout of something I hope to develop in the next few days (yeah, the very last weeks before a customer release are always the best times to breathe some fresh air at lunch time by doing something completely different like adding stuff to JspWiki's site). So this is a draft, a sketch, and, well, an intermediate unfinished work


People, myself included, sometimes mention Wiki as Database, even if not explicitly, without a clear definition of what they expect from such a Vision. I started this page to try and list some of the features that could be expected, in order to form a request for enhancement in this direction.

Shortly put, WikiAsDatabase obviously refers to using a Wiki, a JSPWiki instance in our case, to do CRUD operations on a database-like model.

The motivations probably are:

  • ease of use (Wisiwig, thin-client GUI)
  • ease of setup (JspWiki is quite admin-friendly, probably more than most DB-backed systems, e.g. some bug trackers)
  • homogeneous integration with other content management (documentation Wiki,...)
  • genericity (the engine and interface might even not need to know the "database" model)

The alternative could be:

  • specific DB-software, offering CRUD on a specific DB schema from a specific UI
    • Too expensive and too specific
  • Classical DB client: generally too technical for Mere Mortals
  • generic DB-software, offering a CRUD on whatever DB schema from a generic UI
    • Beside the fact I know none of such software, they probably do not offer the same level of ease of use and integration

Expected Features#

The term "Wiki as Database" itself probably denotes a technical orientation on the speaker's part. Let's try however, to describe features expectations from a mere mortal's point of view (couldn't help adding the mapping to the tech vocabulary).

Abstract Model#

A Wiki as Database displays, and enables to manipulate, entities, which adhere to a model.

Such a Wiki needs to provide:

  • a notion of entity, that is something with displayable properties
  • Model edition: a way to specify, preferrably in Wiki markup, the structure and rules of entities and their properties
  • Entity edition: a way to edit entities with Wiki markup
  • Entity browsing: a way to list, search, and display entities
  • Entity requesting: a more elaborate way to list, search and display, part of entities, of aggregations of (part of) entities

In techies words, or at least RDBMS techies, an entity is a row in a table, each table has a model described in a schema, each property is a column of the table, and rules are, well, constraints.

Model = Structure#

The entity structure need to be homogeneous within a given type of entities:

Homogeneous structure is required technically, so that an engine can execute queries on the properties, but also desired for functional reasons, to provide a homogeneous display to the user.

Rules = Constraints#

Properties of en entity need some form of rules, to ensure that, e.g. the Severity of a bug report is one of the known severities (see e.g. Bug Criticality).

The necessity of rules (or, let's call them constraints now that I've let the word slip) impacts both the model and entity edition. In particular it requires additions to the existing WikiMarkup

Request != Display#

Ideally, requests should define what to extract from entities, but not how to display it. The way SQL or XSLT for example, mix requests and display, although practical for the techies, is just confusing for the Mere Mortal for whom learning Wiki Markup was already a hassle.

A Wiki as Database should provide some way to specify requests that select things to diaplay, and apply some sort of for each structure were the display is specified in Wiki Markup. This enables to limit the required Wiki Markup extensions mentioned above, to the request part, using plugins for example.

Request = Dynamicity#

Although some functionalities already exist in JspWiki core or in plugins to provide static requests on pages (such as: list all pages that point to this one), the full extent of a Wiki as Database can be reached only if such requests can be composed dynamically by the casual user (i.e., specify all bug reports open by Janne, in 2006, and now fixed, all that without editing the wiki markup).

As far as I foresee it, the dynamic part is composed of only the specific values the user might provide: this means that:

  • the display part need not be dynamic, and can be edited in the Wiki Markup.
  • the static part of the request maybe only needs to specify a form, with the allowed fields for the request.

Model 1: One Entity = One Page#

In this model each page describes an entity, with the type of entity dictating the structure.

E.g. a bug report has a title, severity, open date and status; each Bug Report page should list those fields, structured in the same way.

Model = Page Structure#

This implies some way to structure a page, which can take various forms (see dedicated paragraph).

A lot of request engines already exist on JspWiki pages, based on links between them. Requests can be constructed leveraging that, for example, the name of the person which fixed a bug be linked to in the bug page.

Although it certainly is good practice that both the properties definitions and their values be links, it is neither necessary, nor sufficient, to qualify as a full-fledged Wiki as Database.

  • Not sufficient, because e.g. all bug pages that link to Janne are not necessarily bugs that were fixed by Janne. So you really need some way to specify that the link to Janne is the value of the Fixer property.
  • Not necessary (or unnecessarily contraining), because you may want to query your Wiki as Database for all bugs that concern, e.g., "user profiles", even when the bug reports do not link to such a named page.

Model 2: One Entity = One Row of one Table in one Page#

This is the paradigm of the TasksPlugin, which solves nicely the problem of specifying a structure (constraints apart), and is the model followed by JSPWiki's bug reports display (see e.g. Bug Line Breaks With CSS Formating). The drawback is that this constrains the markup in the contents, which have to fit into a JspWiki table (awkward line feeds, no bulletted lists,...)

In this model, an entity is defined as one link, with attributes that enable to specify the properties. e.g.: ...the schedule is tight bla-bla-bla and we still miss the [Build Machine|TODO{title='Purchase Build Machine';deadline='12 may';responsible='jduprez'}]... The TODO page would be able to list all such notes, not only the pages where they come form, but also the properties text.

This model needs more work to describe it, but is roughly waht would fulfill my expectation of a TODO manager, something available in another Wiki engine (TODOfind the link :o).

Expected Usages#

To be completed, mention Wiki as Bug Tracking, Project documentation Wiki, Wiki as Project Tracking,...

Implementation notes#

To be completed.

Mention TasksPlugin and related search/aggregation plugins, form handling, display,...

Lunch time is over, have to postpone completing this page to another day... :-(

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 03-Apr-2007 15:54 by JeromeDuprez.