• View
• Edit
• History
• Print

Technology

Various software technologies will be used to develop the new apps:

Mostly Python

• Basic Python libs, apps and plugins
• Event frameworks such as Twisted, Gevent
• Various engines, asynchronous event engines

Some PHP

• Tools like phpMyAdmin
• pmwiki, maybe with a backtracing engine.
• Semantic Mediawiki still possible, certainly as a model for Semantic Web apps.
• Currently, there are currently no workable engines in PHP

Ruby ?

• Rails
• Rulby

Java

• not sure, big memory/capacity footprint
• New server will be able to host Openfire

1.  Lessons Learned - Trac Plugins

Whenever possible, the functionality for all the new !SemWeb type of functionality will be implemented as plugins. Inference engine functionality may require some modifications to the core code.

I started out with Trac and TracPlugins. Certainly, the architecture of plugins made a lot of sense and is one of the major 'buy ins' of the project. Trac Plugins may still be the best bet in developing something with a common core of functions even if I am not using Trac itself, in other words, not "reinventing the wheel" for a plugin standard.

There has been interest in a semwiki type of thing within the Trac community ( but nothing tangible yet ). As far as I can tell, Semantic MediaWiki continues to provide much of the inspiration.

Core functionality for the Trac approach would be RDF and RFD store. The easiest approach in the short run might be:

 * generalize TracTags and extend with RDFlib, would require a TracTag-like plugin for each new type
 * some sort of RDFstore
 * a modest extension of Trac Forms
 * a simple 'on-demand' relational interference engine for navigating through properties and relationships.

In other words, skip the dynamic type creation, powerful template language and tools. It's not exactly a 80-20 decision, more like a 60-20 decision. It might have better performance than a full blown SemWeb plugin.

See examples of plug-ins at Trac Hacks.

• Interesting Plugins
  • Tags Plugin - big ( 260K .egg ), lots of functionality, some MVC design, installs to site-packages.
  • BackLinks Macro - small very useful in category hierarchy.
  • SectionEdit Plugin - for big pages, installs to site-packages.
  • Menus Plugin - looks count.
  • XML-RPC Plugin - configuration and maybe security issues, better handled in Twisted ?.
  • FullBlog Plugin - basic type, uses blog: realm, customize for weblog: realm, compatibility with Trac 0.12 and Menus plugin ?
  • Support for Python RDFlib. See http://trac-hacks.org/wiki/DoapViewMacro

See Proposed Wiki Extensions.

Translating HTML/Wiki Dialects See Drupal to FullBlog converter.

• The Trac Wiki Engine

2.  Lessons Learned - Wiki Markup Conversion

Converting wiki markup can be a challenge, somewhat parallel to database conversion.

The PmWiki Custom Markup Engine has an interesting approach to the translation process, by dividing into into a discrete number of phases:

 _begin      start of translation
 fulltext    translations to be performed on the full text            
 split       conversion of the full markup text into lines to be processed
 directives  directive processing
 inline      inline markups
 links       conversion of links, url-links, and WikiWords     
 block       block markups
 style       style handling       
 _end        end of translation

Clearly, the designers have given the parsing process a great deal of thought.

• Wiki Conversion Links
  • Trac MediaWiki Plugin Macro
  • Django MediaWiki-style markup
  • Trac Wiki Processors
  • A Universal Wiki Converter ( implemented in Java )
  • Example of Wiki Properties

3.  Lessons Learned - Semantic MediaWiki

Security and language usability aside, the quickest and easiest way to implement a working semwiki is still MediaWiki plus Semantic MediaWiki extensions.

SMW has some really interesting features, such as properties and types, semantic 'type' templates, enhanced forms, semantic drilldown tools, etc etc. Basically, the new functions should create a blend of data model with document model. The end result seems to be a richer navigational environment for the user, allow access by properties, types or values as well as by categories and page links.

• Semantic Forms Extension
• SMW Extensions

I probably will have either a localhost or heavily firewall-ed installation SMW to extract useful features. It's still pretty much the only game in town semwiki-wise. Maybe I'll figure out how to protect the dang thing from hackers in the meantime. ( Flat-file systems with 755 'permission lockdown' seems to be an effective and workable solution, though admittedly awkward at times. )