What is a "structured wiki", and what does it mean in Foswiki?
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://www.foswiki.org/Support/WhatIsStructuredDataInFoswiki). You're reading a topic right now, called WhatIsStructuredDataInFoswiki.
, 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. Don't confuse DataForms with HTML Forms. A DataForm 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 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. See AutoViewTemplatePlugin
for details of this feature.
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.
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:
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.
So, here is a rough dependency graph for a typical DataForms
("structured") Foswiki application:
- 12 Jan 2010
There are mistakes in the diagrams regarding the Cohabit field. The example SEARCH is wrong. They should contain FruitSampleNNN
references. Cohabit should probably be renamed to "SeeAlso", perhaps, to make it more obvious.
- 29 Jan 2010
Interesting, when I saw the mention of Page Type it reminded me of a conversation about Page Content Types
back on TmWiki.
I agree that Structured Data is one of the most powerful but underused features of Foswiki and applaud the effort to make the feature more prominent. That said, the there are many parts to data forms that are not easy to bring together.
I have started to deploy the page WebFormManagement
to help me picture what is going on. Maybe that can be part of your documentation.
- 03 Feb 2010