PyWacketPyWacket|
Project /
TechnologyProject.Technology HistoryHide minor edits - Show changes to output Changed line 96 from:
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. to:
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. ) Changed line 70 from:
links conversion of to:
links conversion of links, url-links, and WikiWords Changed lines 29-30 from:
There has been interest in [[http://trac-hacks.org/wiki/TracSemanticPlugin | 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. to:
There has been interest in [[http://trac-hacks.org/wiki/TracSemanticPlugin | 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. Added line 43:
Changed lines 60-70 from:
_begin fulltext translations to be performed on the full text split directives inline links style _end to:
Converting wiki markup can be a challenge, somewhat parallel to database conversion. The [[http://www.pmwiki.org/wiki/PmWiki/CustomMarkup | 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. Changed line 83 from:
Security and language usability aside, the quickest and easiest to implement a working semwiki to:
Security and language usability aside, the quickest and easiest way to implement a working semwiki is still MediaWiki plus Semantic MediaWiki extensions. Added lines 91-93:
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. Deleted line 74:
Deleted line 75:
Deleted line 76:
Deleted line 77:
Deleted line 78:
Added lines 55-84:
* [[http://trac.edgewall.org/wiki/WikiEngine | 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 **[[http://trac-hacks.org/wiki/MediaWikiPluginMacro | Trac MediaWiki Plugin Macro]] **[[http://djangosnippets.org/snippets/139/ | Django MediaWiki-style markup]] **[[http://trac.edgewall.org/wiki/WikiProcessors | Trac Wiki Processors]] **[[https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter | A Universal Wiki Converter]] ( implemented in Java ) **[[https://studio.plugins.atlassian.com/source/browse/UWC/tags/gui-v2/conf/converter.pmwiki.properties | Example of Wiki Properties ]] Added lines 55-66:
!!!!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. * [[http://www.mediawiki.org/wiki/Extension:Semantic_Forms | Semantic Forms Extension]] * [[http://semantic-mediawiki.org/wiki/Help:SMW_extensions | SMW Extensions]] Added lines 30-38:
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. Added lines 21-45:
!!!!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 [[http://trac-hacks.org/wiki/TracSemanticPlugin | 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 [[http://trac-hacks.org/ | Trac Hacks]]. *Interesting Plugins ** [[http://trac-hacks.org/wiki/TagsPlugin | Tags Plugin]] - big ( 260K .egg ), lots of functionality, some MVC design, installs to site-packages. ** [[http://trac-hacks.org/wiki/BackLinksMacro | BackLinks Macro]] - small very useful in category hierarchy. ** [[http://trac-hacks.org/wiki/SectionEditPlugin | SectionEdit Plugin]] - for big pages, installs to site-packages. ** [[http://trac-hacks.org/wiki/MenusPlugin | Menus Plugin]] - looks count. ** [[http://trac-hacks.org/wiki/XmlRpcPlugin | XML-RPC Plugin]] - configuration and maybe security issues, better handled in Twisted ?. ** [[http://trac-hacks.org/wiki/FullBlogPlugin | FullBlog Plugin]] - basic type, uses ''blog:'' realm, customize for ''weblog:'' realm, compatibility with Trac 0.12 and Menus plugin ? ** Support for [[http://www.rdflib.net/ | Python RDFlib]]. See http://trac-hacks.org/wiki/DoapViewMacro See [[http://trac.edgewall.org/wiki/TracDev/Proposals/AdvancedWikiOperations | Proposed Wiki Extensions]]. Translating HTML/Wiki Dialects See [[http://trac-hacks.org/attachment/wiki/FullBlogPlugin/drupal2fullblog | Drupal to FullBlog converter]]. Changed lines 5-7 from:
* * Various to:
* Event frameworks such as Twisted, Gevent * Various engines, asynchronous event engines Changed line 11 from:
* Semantic Mediawiki to:
* Semantic Mediawiki still possible, certainly as a model for Semantic Web apps. Changed lines 16-17 from:
* to:
* [[https://github.com/Ruleby/ruleby/wiki | Rulby]] Changed line 20 from:
* New server to:
* New server will be able to host [[http://www.igniterealtime.org/projects/openfire/ | Openfire]] Changed lines 20-21 from:
* New server may be able to host to:
* New server may be able to host Openfire Added lines 1-20:
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 |