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
- 24 Jun 2005
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).
- 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.
- 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?
- 26 Jun 2005
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
. 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
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
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
means and when to go for a perl plugin solution is unclear at least. Sometimes
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
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
" button etc. You name it. In turn the blog author shall not fiddle with the
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.
- 08 Oct 2005
Can someone leverage me some synergy and translate MichaelDaum
- 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.
- 04 Mar 2006
Those interested in the idea of a structured Wiki should check out ProWiki
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...
- 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.
- 22 May 2006
I refactored the top. Please feel free to enhance.
- 05 Jun 2006
I moved off-topic content to ConvertPdfFileToWikiFile
- 31 Oct 2007