PyWacketPyWacket|
Project /
RuleForgeProject.RuleForge HistoryShow minor edits - Show changes to markup Changed lines 93-95 from:
Well ... there is another thing that Trac does well - 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, 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 - 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, 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: 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. to:
Well ... there is another thing that Trac does well - 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, 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. 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. 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 lines 87-88 from:
Well ... there is another thing that Trac does well: 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. to:
Well ... there is another thing that Trac does well: 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, 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. 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 'complex' feature for their system, they always say "I want to integrate order entry, manufacturing and shipping ... but keep it simple". :-) 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 ... WhateverTrac 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. to:
Taming the Trac Software Management ... WhateverTrac 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". 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 Trac Themes plugin, but it has the feeling of something tacked on 'after the fact'. 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 Trac Themes plugin, but it has the feeling of something tacked on 'after the fact'. Changed lines 85-88 from:
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 is another thing that Trac does well: 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. 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: 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. 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. 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 87 from:
Well, there another thing that Trac does well, that is 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. to:
Well, there is another thing that Trac does well: 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 does a couple of things well at the same time, which few applications can boast. 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:
Changed lines 69-71 from:
to:
Changed lines 73-76 from:
to:
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 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 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.
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, 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, 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 ... WhateverTrac 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.
Changed lines 27-28 from:
Objectivesto:
Secondary ObjectivesChanged lines 33-38 from:
Major Functionsto:
Extended FunctionsDeleted line 40:
Changed line 53 from:
to:
Changed lines 5-10 from:
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. to:
Subjects will be: Changed lines 12-13 from:
to:
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. Changed lines 41-42 from:
to:
Changed lines 46-49 from:
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. 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 34-49 from:
to:
RuleForge semantic functions extending Semantastic are: Changed lines 48-56 from:
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:
ObjectivesChanged line 32 from:
Major functions will include: to:
Major functionsChanged lines 54-69 from:
to:
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:
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.
Much of the content for the Rule Forge site will come from:
Objectives
Major functions will include:
|