Archive of Structured Wiki Discussions

I do this by creating a Web per table - at some stage in the TopicObjectModel we want to add SQL querying, but in essence, its what is going on in the Bugs web.

-- SvenDowideit - 24 Jun 2005

StructuredWiki is also the driving principle behind FormQueryPlugin. An interesting consideration is how you successfully mix structured and unstructured data. IMHO this is the strongest argument for separate wiki webs ever invented; I often have "structured webs" versus "unstructured webs", simply because people find it easier to deal with (this is why FormQueryPlugin works on a per-web basis, BTW).

-- CrawfordCurrie - 25 Jun 2005

I am working on a framework called "Flexischema Framework". The idea is to apply wiki concepts to database concepts, and this means:

• Creating a new datasource should be as easy as creating a new topic. Indeed, every topic is a datasource.
• The new datasource created can reuse all aspects of another datasources, such as:
  • Schema; complete or partial
  • Subset of data - specified by either named keys or a query criteria (for e.g. all users belonging to a specific project)
• Row and column based access controls.
• Formats to specify information about schema in incremental manner (with standard defaults) - for e.g. type, range, how to render for HTML/Email etc. and so on.
• Options can be static (i.e. enumerated within the schema) or can be keys of remote topic.
• Mechanisms to allow new keys (i.e. row id's) to be either auto-generated, user input, static list or a dynamic list from another datasource.
• Control over ordering of keys (for e.g. latest updates first) during the table view.
• Flexible front ends (TWiki, Ajax, email) and backends (Multiple wiki's, DBM files etc.).

The current implementation is in perl, and has twiki front end (with Template toolkit for table and entry displays). An older version had ajax as well (for view/edit of tables/entries), but we need to make use of Dojo (http://www.dojotoolkit.org/) as front end.

The current implementation is several of above capabilities, and is currently testing it for production runs. We will eventually release it, once we have achieved a usable set of features.

The focus of the work is to ensure a microformat for structured data (i.e. tables etc.) , while allowing a lot of control to be added with help of plugins. This table microformat should be independent of any particular wiki, easily editable in any editor with visible scalability to any no. of rows and columns, and a bunch of capabilities to create new datasources and to sync among existing datasources.

If anyone is interested in checking it out you could write to me.

-- VinodKulkarni - 26 Jun 2005

Vinod - yes, i'd say there are a few f us that would be interested - do you want to use out Subversio repository?

-- SvenDowideit - 26 Jun 2005

StructuredWikis do not necessarily make use of the FormQueryPlugin. Most of the time the same can be achieved using parametrized INCLUDEs and SEARCH but less efficient. Doing a step forward and quit the pure TWikiML way and go for a FormQueryPlugin implementation is not as direct and obvious as one might think.

These are all key technologies to leverage TWikiApplications so far. Much more important is the concept of TopicClassification or - how I use to call it - TopicTypes (and presumably TWikiForms). The core of TWikiApplications is a way of bridging TWikiML towards a scripting environment around TWikiForms that enables to implement an arbitrary TWikiApplication. To say it beforehand: TWiki is not there yet. Programming in TWikiML can be compared to standard programming techniques stating that parametrized INCLUDEs are methods on TopicTypes. Thus TWikiForms can bee seen as a kind of class definition. Actually there's nothing like polymorphism and inherritance in TWikiForm. Nor is there a kind of type checking, like INCLUDEs that are only allowed to certain TopicTypes. However, adding such a power is problematic: first, technically speaking, adding turing potentials to a TWikiML scripting language - object oriented or not - introduces the termination problem, that is: a wiki author can write a TWikiML script and DOS the wiki server. Second, and more important, TWikiML is the whiteboard markup that shall ease writing content as well as a scripting language for TWikiApplications with its own needs. Any further development of TWikiML must take this twofoldness into account. Today, TWikiML is simply not powerful enough to go the path of a pure TWikiML implementation. But there's always the possibility to back off into perl and extend TWikiML for a specific application. The decision, when to use TWikiML means and when to go for a perl plugin solution is unclear at least. Sometimes the TWikiML way can be very clumsy solving a relatively simple problem. Lots of "simple problems" occured over the time and TWikiML has become rather exotic and complicated in some respect.

About structured vs non-structured wikis: I am not so sure that there is so much synergy between a TWikiApplication and the default whiteboard. From the application writer's point you might even want to further hide the wiki whiteboard and restrict it to just the implemented application, that is: restrict the TWiki using a kind of kiosk mode, something going beyond access control. for example switch off standard url parameter (raw=on) and some cgis in part of the site. You also might simply hide the implemtation of a TWikiApplication. ALLOWTOPICVIEW does not distinguish a direct access using a view url from an INCLUDE call. And last not least, there are multiple levels of views on the applications or call it roles of a TWikiUser. For example in a blogging application there's one or more blog author posting articles. Then there are commenters, possibly anonymouse. Then there's the blog admin role that for example creates new categories. And you might enter the application on the implementation level fixing TopicTypes and TopicFunctions. Surely roles might overlap and users can have more than one role. Each role should just be presented with a limitted level (of complexity). The blog author gets a "New Posting" button, the blog admin gets a "New Category" button, the blog hacker gets the "New TopicFunction" button etc. You name it. In turn the blog author shall not fiddle with the TopicFunctions and types. Nor should a blog commenter.

Note, this is just about how to carry common application design techniques over to TWiki. Nothing really new. But also note, however, that as common as it might be to a common application designer to think this way, the avenue towrads a complete application framework in TWiki is just opening and steping on to it will need to look backwards in order not to forget that, hey, this still is a wiki software. In the end, the whiteboard application of TWiki might just be levelled to just another TWikiApplication. The synergy between structured and nonstructured wikis will likely be the same as between any pair of applications in the same framework.

-- MichaelDaum - 08 Oct 2005

Can someone leverage me some synergy and translate MichaelDaum's comment?

-- RandyThomas - 04 Mar 2006

Hm, guess Michael stated:

• Doing TWikiApplications with TWikiML is still too difficult and complex
• It should be easier to use different user roles in applications to hide compexity
• We are not there yet.

-- FranzJosefSilli - 04 Mar 2006

Those interested in the idea of a structured Wiki should check out ProWiki -- I've been playing pretty deeply with these concepts for my own work. Whereas TWiki has the idea that pages can have attached metadata, ProWiki goes further: a page may be entirely made up of properties, which can be either textual or links to other pages. Combined with a simple query language built into the markup langage, and I've found the results to be impressively powerful, even in what amounts to a prototype implementation; I'm using it mainly for game development, but it's clearly usable in many arenas. There's a prototype-style object-oriented data model implicit in the system, with property value inheritance a la Javascript or MOO, and display templates that allow you to define how the page gets rendered.

I'm beginning to dive into the development of Querki ("queryable wiki"), which is going to be the next generation of the same idea. I've come to the conclusion that you need to have a real DB in back to really make the idea hum, so I'm examining candidate technologies now: open-source Wikis that are based on MySQL, that could be enhanced to be more structured under the hood. Suggestions are welcome...

-- MarkJustinWaks - 11 May 2006

Thanks for the pointers. You're not alone in thinking there needs to be a real DB in back for performance, especially with large numbers of topics. It's unclear at this point whether it will be possible to have a real DB backend with TWiki, but it's early days in the development cycle for the next release.

-- MeredithLesly - 22 May 2006

I refactored the top. Please feel free to enhance.

-- PeterThoeny - 05 Jun 2006

I moved off-topic content to ConvertPdfFileToWikiFile.

-- PeterThoeny - 31 Oct 2007