Technology

(:toc-float:)

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. )

 links       conversion of links, url-links, and WikiWords     

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.

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.

Security and language usability aside, the quickest and easiest way to implement a working semwiki is still MediaWiki plus Semantic MediaWiki 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.

• The Trac Wiki Engine

Lessons Learned - Wiki Markup Conversion

The PmWiki 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

• 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

Lessons Learned - Semantic MediaWiki

Security and language usability aside, the quickest and easiest to implement a working semwiki site 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

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.

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, http://semantic-mediawiki.org/wiki/Semantic_MediaWiki Semantic MediaWiki continues to provide much of the inspiration.

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.

• Event frameworks such as Twisted, Gevent
• Various engines, asynchronous event engines

• Semantic Mediawiki still possible, certainly as a model for Semantic Web apps.

• Rulby

• New server will be able to host Openfire

• New server may be able to host Openfire

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

Mostly Python

• Basic Python libs, apps and plugins
• Twisted
• Various engines

Some PHP

• Tools like phpMyAdmin
• pmwiki, maybe with a backtracing engine.
• Semantic Mediawiki, as a model for Semantic Web apps. This may become semantastic.com.
• Currently, there are currently no workable engines in PHP

Ruby ?

• Rails
• Rulby

Java

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