PyWacketPyWacket|
Project /
RuleForgeProject.RuleForge HistoryHide minor edits - Show changes to output Changed lines 93-95 from:
Well ... there is another thing that Trac does well - [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because TracLinks implement flexible 'realm:' type prefixes, such as "person:Bob". This type of data structure is notoriously difficult to deal with in a many-to-many table, but realm: prefixes can also enable 'multiway' RDF relational semantics very directly. In other words, it allows dynamic relational expressions such as <person:bob | address: | '2211 First Street'>, in So, a basic implementation of semantic extensions already exists within the 'namespace' feature of the Trac database. And, by the way, [[http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki | Mediawiki's Semantic Extension]] requires a largish amount of code just to deal with functionality that is essentially free in Trac. to:
Well ... there is another thing that Trac does well - [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because TracLinks implement flexible 'realm:' type prefixes, such as "person:Bob". This type of data structure is notoriously difficult to deal with in a many-to-many table, but realm: prefixes can also enable 'multiway' RDF relational semantics very directly. In other words, it allows dynamic relational expressions such as <person:bob | address: | '2211 First Street'>, in an object/relation/value pattern. So, a basic implementation of semantic extensions already exists within the 'namespace' feature of the Trac database. And, by the way, [[http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki | Mediawiki's Semantic Extension]] requires a largish amount of code just to deal with functionality that is essentially free in Trac. Very tempting ... Changed lines 93-95 from:
Well ... there is another thing that Trac does well - [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because to:
Well ... there is another thing that Trac does well - [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because TracLinks implement flexible 'realm:' type prefixes, such as "person:Bob". This type of data structure is notoriously difficult to deal with in a many-to-many table, but realm: prefixes can also enable 'multiway' RDF relational semantics very directly. In other words, it allows dynamic relational expressions such as <person:bob | address: | '2211 First Street'>, in a entity/relation/value pattern. So, a basic implementation of semantic extensions already exists within the 'namespace' feature of the Trac database. And, by the way, [[http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki | Mediawiki's Semantic Extension]] requires a largish amount of code just to deal with functionality that is essentially free in Trac. Changed line 93 from:
Well ... there is another thing that Trac does well to:
Well ... there is another thing that Trac does well - [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, such as "person:Bob". This type of data structure is notoriously difficult to deal with in a many-to-many table, but realm: prefixes can also enable 'multiway' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within a 'namespace' feature of the Trac database. And, by the way, [[http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki | Mediawiki's Semantic Extension]] requires a largish amount of code just to deal with functionality that is essentially free in Trac. Added lines 64-65:
The Rule Forge part of this project had a previous incarnation as '''ruleforge.com''' ( now defunct ) running on a Trac Wiki. It was bit of a challenge. Changed line 89 from:
Unfortunately, I speak from hard experience to:
Unfortunately, I speak from hard experience. The task of re-theming Trac turned out to be a major sub-project I had not anticipated. Changed line 106 from:
There may be some more configuration issued based on your particular situation, such as the port assignment ( 8080 or whatever). Obviously, this is a solution for a localhost or VPS hosting and won't work as a public site on a shared server, but the same brutalist approach might work for cgi or fastcgi shared hosting. I now have a VPS to:
There may be some more configuration issued based on your particular situation, such as the port assignment ( 8080 or whatever). Obviously, this is a solution for a localhost or VPS hosting and won't work as a public site on a shared server, but the same brutalist approach might work for cgi or fastcgi shared hosting. I now have a VPS so a public Trac standalone site is an option ... the security gods willing. Changed line 106 from:
There may be some more configuration issued based on your particular situation, such as the port assignment ( 8080 or whatever). Obviously, this is a solution for a localhost or VPS hosting and won't work as a public site on a shared server, but the same brutalist approach might work for cgi or fastcgi shared hosting. to:
There may be some more configuration issued based on your particular situation, such as the port assignment ( 8080 or whatever). Obviously, this is a solution for a localhost or VPS hosting and won't work as a public site on a shared server, but the same brutalist approach might work for cgi or fastcgi shared hosting. I now have a VPS now so public Trac standalone is an option ... the security gods willing. Changed lines 87-88 from:
Well ... there is another thing that Trac does well: [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table, can also enable 'multiway' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within a 'namespace' feature of the Trac database. And, by the way, to:
Well ... there is another thing that Trac does well: [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table, can also enable 'multiway' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within a 'namespace' feature of the Trac database. And, by the way, [[http://www.mediawiki.org/wiki/Extension:Semantic_MediaWiki | Mediawiki's Semantic Extension]] requires a largish amount of code just to deal with functionality that is essentially free in Trac. Changed line 100 from:
That is basically it, no setup.py. Just unzip to a user lib, copy, configure a bit and then run it. At that point, I can go right in to the core code and savage it at will. to:
That is basically it, no setup.py. Just unzip to a user lib, copy, configure a bit and then run it. At that point, I can go right in to the core code and savage it at will. Barring a few Python dependencies, this will not disturb anything else on the system, for instance a system-wide or virtualenv install of Trac. Changed lines 20-21 from:
''Note: I've never heard a business user request a ' to:
''Note: I've never heard a business user request a 'complicated' feature for their system - they always say something like "I want to integrate order entry, manufacturing and shipping ... but keep it simple". :-)'' Changed lines 58-60 from:
!!!! Taming the Trac Software Management ... Whatever Trac to:
!!!! Taming the Trac Software Management ... Whatever Trac is an interesting animal. It is like several animals successfully patched together - it does a couple of different things very well at the same time, a claim which few applications can boast of. Changed lines 79-82 from:
Again, Trac does all these things well. So why do I say, "taming Trac". For example, styles are essentially hard coded into the Trac system - developers aren't supposed to care about looks to:
Again, Trac does all these things well. So why do I say, "taming Trac". Maybe taming is the wrong word, the phrase 're-purposing Trac' is better. That doesn't make the task any easier. For example, styles are essentially hard coded into the Trac system - developers aren't supposed to care about looks, I guess. In principle, the site environment overrides the core content generation templates, but it's not as clean as a separate theme library with its own directory, etc. There is a [[http://trac-hacks.org/wiki/ThemeEnginePlugin | Trac Themes plugin]], but it has the feeling of something tacked on 'after the fact'. Changed lines 85-88 from:
So, why bother Well, to:
So, why bother with it at all ? There other fish in the Python-powered wiki scene, maybe I should find them and move on with my life. MoinMoin has got good stuff in it too. Well ... there is another thing that Trac does well: [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table, can also enable 'multiway' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within a 'namespace' feature of the Trac database. And, by the way, Mediawiki's Semantic Extension requires a largish amount of code just to deal with functionality that is essentially free in Trac. Changed line 100 from:
That is basically it to:
That is basically it, no setup.py. Just unzip to a user lib, copy, configure a bit and then run it. At that point, I can go right in to the core code and savage it at will. Baring a few Python dependencies, this will not disturb anything else on the system, for instance a system-wide or virtualenv install of Trac. Changed line 97 from:
# copy trac/web/standalone.py to the 'root', to:
# copy trac/web/standalone.py to the 'root', above the /trac code base Changed line 96 from:
# run Apache htpasswd for Trac admin to:
# run Apache htpasswd in the /mytrac directory for Trac admin Changed line 89 from:
!!! A Brutal Solution to:
!!!! A Brutal Solution Changed line 104 from:
Anyway, it working for me to:
Anyway, it's working for me so far, if not in the way that the Trac developers intended. More to come ... Changed line 60 from:
Trac is an interesting animal. It is like several animals to:
Trac is an interesting animal. It is like several animals patched together in that it does a couple of different things very well at the same time, a claim which few applications can boast of. Changed lines 62-63 from:
to:
Trac describes itself as "an enhanced wiki and issue tracking system for software development projects" and an an "interface to Subversion (and other version control systems)". It also has a good plugin system and reporting subsystems. Changed lines 79-83 from:
Again, For example, styles are essentially hard coded into the Trac system I to:
Again, Trac does all these things well. So why do I say, "taming Trac". So maybe taming is the wrong word, maybe 're-purposing Trac' is better. That doesn't make the task any easier. For example, styles are essentially hard coded into the Trac system - developers aren't supposed to care about looks ? In principle, the site environment overrides the core content generation templates, but it's not as clean as a separate theme library with its own directory, etc. There is a [[http://trac-hacks.org/wiki/ThemeEnginePlugin | Trac Themes plugin]], but it has the feeling of something tacked on 'after the fact'. Unfortunately, I speak from hard experience. The Rule Forge part of this project had a previous incarnation as '''ruleforge.com''' ( now defunct ) running on a Trac Wiki. The task of re-theming Trac turned out to be a major sub-project I had not anticipated. Changed lines 81-82 from:
For example, styles are essentially hard coded into the Trac system. In principle, the site environment overrides the core content generation templates, but it's not as clean as a separate theme library with its own directory. to:
For example, styles are essentially hard coded into the Trac system. In principle, the site environment overrides the core content generation templates, but it's not as clean as a separate theme library with its own directory. There is a [[http://trac-hacks.org/wiki/ThemeEnginePlugin | Trac Themes plugin]], but it has the feeling of something tacked on 'after the fact'. Changed line 87 from:
Well, there is another thing that Trac does well: [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table to:
Well, there is another thing that Trac does well: [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table, can also enable 'multiway' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within a 'namespace' feature of the Trac database. And, by the way, Mediawiki's Semantic Extension requires a largish amount of code just to deal with functionality that is essentially free in Trac. Changed line 87 from:
Well, there another thing that Trac does well to:
Well, there is another thing that Trac does well: [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table ), can also enable '3-way' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within the design of the Trac database. And, by the way, Mediawiki's Semantic Extension requires a largish amount of code just to deal with functionality that is essentially free in Trac. Changed lines 60-61 from:
Trac is an interesting animal. It to:
Trac is an interesting animal. It is like several animals patch together in that it does a couple of things well at the same time, which few applications can boast of. Changed lines 65-67 from:
to:
** Creole Markup, mostly standard ** Trac Links, realm: preface similar to a namespace Changed lines 69-71 from:
to:
** Tickets, Workflow and Scheduling ** Report Subsystem Changed lines 73-76 from:
to:
** Mostly Subversion, some GIT ** Source Browser, Changesets *Plugins ** For instance, Tags and [[http://trac.edgewall.org/wiki/PluginList#WikiMacrosExtensions | WikiMacros]] Again, it does all these things very well. So why say "taming Trac". So maybe taming is the wrong word, maybe 're-purposing' is better. That doesn't make the task any easier. For example, styles are essentially hard coded into the Trac system. In principle, the site environment overrides the core content generation templates, but it's not as clean as a separate theme library with its own directory. The is a [[http://trac-hacks.org/wiki/ThemeEnginePlugin | Trac Themes plugin]], but it has the feeling of something tacked on 'after the fact'. I speak from hard experience. The Rule Forge part of this project had a previous incarnation as '''ruleforge.com''' ( now defunct ) running on a Trac Wiki. The task of re-theming Trac turned out to be a major sub-project I had not anticipated. So, why bother ? There other fish in the Python-powered wiki scene, find them and move on with your life. MoinMoin has got good stuff in it too. Well, there another thing that Trac does well, that is [[http://trac.edgewall.org/wiki/TracLinks | Trac Links]]. They deserve special attention because realm type prefixes, while admittedly hard to deal with in a many-to-many table ), can also enable '3-way' RDF relational semantics very directly. In other words, the basic semantic extensions already exist within the design of the Trac database. And, by the way, Mediawiki's Semantic Extension requires a largish amount of code just to deal with functionality that is essentially free in Trac. One potential approach ( the 'brutalist' approach) to the themes issue is to create a monolithic standalone Trac installation using the following steps. # unzip the Trac zip file. # copy trac/admin/console.py to the 'root' directory, above the trac code library. # run console.py as if it were tracadmin, initializing a site directory mytac off the root # run Apache htpasswd for Trac admin # copy trac/web/standalone.py to the 'root', sibling to /trac code base # start standalone.py as if it were tracd, with appropriate parameters and port of choice. That is basically it. At that point, I go right in to the core code and savage it at will. Baring a few Python dependencies, this will not disturb anything else on the system, for instance a system-wide or virtualenv install of Trac. There may be some more configuration issued based on your particular situation, such as the port assignment ( 8080 or whatever). Obviously, this is a solution for a localhost or VPS hosting and won't work as a public site on a shared server, but the same brutalist approach might work for cgi or fastcgi shared hosting. Anyway, it working for me, if not the way that the Trac developers intended. More to come ... Changed lines 20-21 from:
''Note: I've never heard a business user request a complex feature for their system, to:
''Note: I've never heard a business user request a 'complex' feature for their system, they always say "I want to integrate order entry, manufacturing and shipping ... but keep it simple". :-)'' Changed lines 56-58 from:
Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible ''in practice'' without an advanced truth maintenance engine of some sort. to:
Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible ''in practice'' without an advanced truth maintenance engine of some sort. !!!! Taming the Trac Software Management ... Whatever Trac is an interesting animal. It does a couple of things well at the same time, which few applications can boast. It describes itself as "an enhanced wiki and issue tracking system for software development projects" and an an "interface to Subversion (and other version control systems)". It also has a good plugin system and reporting subsystems. * Wiki *Issue Tracking *Interface to Version Control Changed lines 16-19 from:
Note that most business rule and rule engine sites concentrate on technical capabilities, that is code and complex algorithms. I think that there is so much more to be said about the formal, logical structure of rule bases themselves than just rule engines and computer solutions. For Of course, the basic content will cover the traditional technologies and components used to build rule-based systems, that is specific components to implement complex rule-based workflow engines. to:
Note that most business rule and rule engine sites concentrate on technical capabilities, that is code and complex algorithms. I think that there is so much more to be said about the formal, logical structure of rule bases themselves than just rule engines and computer solutions. For example, I would to have a repository of several sets of customer order validation rules and associated workflows, based on business design patterns and an analytic framework for real-world business problems. Of course, the basic content will still cover the traditional technologies and components used to build rule-based systems, that is specific components to implement complex rule-based workflow engines. But implemented in a simple way, of course. Changed lines 24-25 from:
* * The to:
* the [[http://billbreitmayer.com/static/drupal/ | old BBcom rule engine technical site]] * the [[http://billbreitmayer.com/static/home/ | old BBcom business rules home site]] Changed lines 27-28 from:
!!!!Objectives to:
!!!!Secondary Objectives Changed lines 33-38 from:
* Run * Provide a high level of host/localhost integration with peer-to-peer capabilities to:
* Run more complex rule/inference engines, extending event and workflow mechanism for rules. * Provide a high level of host/localhost integration with peer-to-peer capabilities, for desktop tie-back. !!!!Extended Functions Deleted line 40:
Changed line 53 from:
** an engine to drive Semantic Mediawiki to:
** an engine to drive Semantic Mediawiki type templates, maybe Changed line 20 from:
''Note: I've never heard a business user request a complex feature for their system, it's always "I want to integrate order entry, manufacturing and shipping ... but keep it simple". :)'' to:
''Note: I've never heard a business user request a complex feature for their system, it's always "I want to integrate order entry, manufacturing and shipping ... but keep it simple". :-)'' Changed line 20 from:
''Note: I've never heard a business user request a complex feature for their system, it's always "I want to integrate order entry, manufacturing and shipping to:
''Note: I've never heard a business user request a complex feature for their system, it's always "I want to integrate order entry, manufacturing and shipping ... but keep it simple". :)'' Changed lines 5-10 from:
* A small rule/inference engine capable of running simple examples of rule sets. The content management system for the RuleForge site to The basic content will cover the technologies and components used to build rule-based systems in general and also include specific components used to implement rule-based workflow engines. to:
* A small rule/inference engine capable of running simple examples of rule sets. Subjects will be: Changed lines 12-13 from:
* Semantic Web to:
* Semantic Web, more specifically as knowledge representation The content management system for the RuleForge site to be developed will be new functionality from the semwiki part of the project. The key subject will be rule engines and rule-based systems, including to some extent workflow engines. There should be just enough machinery beneath the hood to run simple examples of rule sets. Note that most business rule and rule engine sites concentrate on technical capabilities, that is code and complex algorithms. I think that there is so much more to be said about the formal, logical structure of rule bases themselves than just rule engines and computer solutions. For examples, I would to have a repository of several sets of customer order validation rules and associated workflows, based on business design patterns and an analytic framework real-world 'situation-based' business analysis. Of course, the basic content will cover the traditional technologies and components used to build rule-based systems, that is specific components to implement complex rule-based workflow engines. In a simple way, of course. ''Note: I've never heard a business user request a complex feature for their system, it's always "I want to integrate order entry, manufacturing and shipping, but keep it simple".'' Deleted line 27:
Changed line 52 from:
Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible ''in practice'' without an advanced truth maintenance engine. to:
Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible ''in practice'' without an advanced truth maintenance engine of some sort. Changed line 52 from:
Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible to:
Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible ''in practice'' without an advanced truth maintenance engine. Changed lines 41-42 from:
** some classic "customer order", to:
** some classic "customer order", family tree and diagnostic examples Changed lines 46-49 from:
** post processing for discovered external links in a master links DB Note that these requirements may to:
** post processing for discovered external links in a master links DB * Type and Form Templates ** an engine to drive Semantic Mediawiki Note that some of these requirements may overlap those of the Semantastic project. In fact, rule engine type functions may be required for 'truth maintenance' in a highly complex, non-relational RDF type of table ( with 3-way -> 5-way relationships ). It may not be feasible ""in practice"" without an advanced truth maintenance engine. Changed lines 34-49 from:
** realm for tags ** extend sub-page mechanisms such as as top-down hierarchy of categories, unlimited depth, clone and split TitleIndex * Embedded HTML Content ** realm for HTML documents:, similar to Blog Plugin, maybe call realm "weblog:" ** can display as weblog: or as embedded HTML via include macro, render safe HTML ** no wiki search but uses tags ** there may be document repository functions as well * Links and Resources ** realm for links: ** uses wiki and tags ** extended to blob stores and local files, MIME handling to:
RuleForge semantic functions extending [[Semantastic]] are: Changed lines 48-56 from:
** use or convert different wiki dialects, such as Creole, MarkDown, Mediawiki ** safe includes and embedding of external HTML from trusted sources * Ontology server API for wiki/links and categories/tags ** should it be a micro-format ? Note that these requirements to some extent overlap those of the Semantastic project. to:
Note that these requirements may to some extent overlap those of the Semantastic project. In fact, they may be required for 'truth maintenance' in a highly complex, non-relational RDF table. Changed lines 21-23 from:
Objectives to:
!!!!Objectives Changed line 32 from:
Major to:
!!!!Major functions Changed lines 54-69 from:
** some classic "customer order", genaeology and diagnostic examples to:
** some classic "customer order", genaeology and diagnostic examples * A Full-Featured Search Engine ** probably external to RuleForge app, ** include objects from all realms, including weblog: ( likely to be too big for wiki search ) ** post processing for discovered external links in a master links DB * Wiki Language Extensions ** use or convert different wiki dialects, such as Creole, MarkDown, Mediawiki, etc. ** safe includes and embedding of external HTML from trusted sources, such as Wikipedia and other 'interwiki' sources. * Ontology server API for wiki/links and categories/tags ** should it be a micro-format ? Note that these requirements to some extent overlap those of the Semantastic project. Added lines 1-55:
The future, possibly never-to-be developed RuleForge site will be a combination of: * Content about business rules and rule engines, based on old billbreitmayer.com content. * A Semantic web, RDF style CMS supporting the RuleForge content. * A small rule/inference engine capable of running simple examples of rule sets. The content management system for the RuleForge site to be developed will be newly developed functionality. The key subject will be rule engines and rule-based systems, including to some extent workflow engines. There should be enough machinery beneath the hood to run simple examples of rule sets. The basic content will cover the technologies and components used to build rule-based systems in general and also include specific components used to implement rule-based workflow engines. * Rule Engines and Rule-Based Systems * Knowledge Engineering * Business Rules * Semantic Web Much of the content for the Rule Forge site will come from: * The old BBcom rule engine/technical site * The old BBcom business rules/home site Objectives * Create new content types while maintaining simple and direct path/content type mapping. * Use plug-ins and a component architecture as much as possible, keeping the upgrade path in mind. * Run simple rule/inference engines, extending event and workflow mechanism for rules. * Provide a high level of host/localhost integration with peer-to-peer capabilities. Major functions will include: * Categories and Tags ** realm for tags: ** Tags Plugin, minor customizations ** extend sub-page mechanisms such as as top-down hierarchy of categories, unlimited depth, clone and split TitleIndex * Embedded HTML Content ** realm for HTML documents:, similar to Blog Plugin, maybe call realm "weblog:" ** can display as weblog: or as embedded HTML via include macro, render safe HTML ** no wiki search but uses tags ** there may be document repository functions as well * Links and Resources ** realm for links: ** uses wiki and tags ** extended to blob stores and local files, MIME handling * A Simple Inference Engine for "Semantic Tagging" ** at least some capability for relationships between tags * A Simple Inference Engine for Running Rule Base Demos ** some classic "customer order", genaeology and diagnostic examples |