Introduction to structured data in Foswiki

Structured wikis are great. They allow savvy users to assemble simple data entry applications, from which mashups, queries and reports are possible.

A quick definition for the uninitiated: "topic" is a Foswiki term for a page. Each topic has its own URL (Eg. This one can be found at http://wiki.trin.org.au/HubRIS/WhatIsAStructuredFoswiki). You're reading a topic right now, called WhatIsAStructuredFoswiki.

In Foswiki, you can read about DataForms to create a form, attach it to some topics, and read some examples to build a QuerySearch to filter and display those topics. A form definition is much like a table definition in a database. If the form is equivalent to a table definition, then a topic which uses the form is much like a row in the table.

A useful core feature of Foswiki 1.1 (still in the works) which is available to Foswiki 1.0 users now via AutoViewTemplatePlugin, is the automatic selection of view and edit templates based on the name of the form attached to a topic. With this we are really starting build up a Topic as something resembling a typed object: its form name being the type identifier, and its form+templates as the details of its implementation.

Anatomy of a Foswiki topic

First, we should clarify the anatomy of what a topic actually consists of.

Important to note is that the server actually stores topics as simple versioned *.txt files you could simply work on using your favourite text editor, Eg. notepad, but you don't need to know that...

There are three main parts to a topic (ignoring history, file attachment and caching related mechanisms):

• Topic text, which ordinary users edit every day.
• "Standard" metadata, automatically maintained by Foswiki, although some parts (Eg. TOPICPARENT and FORM) may be modified by the user.
• "Form" metadata, which ordinary users may edit along with the topic text. Only values are actually stored in a topic. How Foswiki displays the form metadata is defined in the form definition and templates, both of which exist as other topics.

This is depicted below:

"Typed" topics

And now, a rough sketch of what it means for a topic to be "typed":

Putting it all together

This isn't the full story though: topics which are instances of type FruitSample? are just a piece of the puzzle. A practical wiki application still needs:

• A "dashboard" topic (or set of topics) to summarise, query and report on existing topics
• A data entry topic to conveniently create new topics at the push of a button
  • Integration with the summary/dashboard topics is possible, so that certain fields are automatically populated depending on the filtering/query state the dashboard topic was in when the user clicks a "create new entry" link. Eg. If the user was filtering to a particular project, the new topic could have that field set automatically when it opens up for editing.
  • Data entry tool can be made to do some AJAX (Eg., autocompletion)
• Some peripheral topics for the user to maintain any fields that are supposed to hold specific values, Eg. checkbox/drop-down list values.

Dependency graph

So, here is a rough dependency graph for a typical DataForms ("structured") Foswiki application:

-- PaulHarvey - 12 Jan 2010