<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments for Cyberstrategics</title>
	<atom:link href="http://www.thecepblog.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.thecepblog.com</link>
	<description></description>
	<pubDate>Tue, 16 Mar 2010 01:49:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Comment on Rules Apathy: Form vs Function by Charles Young</title>
		<link>http://www.thecepblog.com/2010/03/10/apathy-form-vs-function/#comment-34576</link>
		<dc:creator>Charles Young</dc:creator>
		<pubDate>Wed, 10 Mar 2010 16:22:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=501#comment-34576</guid>
		<description>If ayone want to go public with their counter-points, do plase feel free to post at http://geekswithblogs.net/cyoung/archive/2010/03/06/form-function-and-complexity-in-rule-processing.aspx.   I may be a little slow to respond, as I have a major set of deadlines to meet at work between now and next Tuesday.

Just to record, for clarification, that I have not based my career around any particular product or technology.   At this present time in my career, I work for a company that specialises in a particular product set.  My career preceedes the advent of these products by about two decades.</description>
		<content:encoded><![CDATA[<p>If ayone want to go public with their counter-points, do plase feel free to post at <a href="http://geekswithblogs.net/cyoung/archive/2010/03/06/form-function-and-complexity-in-rule-processing.aspx" rel="nofollow">http://geekswithblogs.net/cyoung/archive/2010/03/06/form-function-and-complexity-in-rule-processing.aspx</a>.   I may be a little slow to respond, as I have a major set of deadlines to meet at work between now and next Tuesday.</p>
<p>Just to record, for clarification, that I have not based my career around any particular product or technology.   At this present time in my career, I work for a company that specialises in a particular product set.  My career preceedes the advent of these products by about two decades.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Tim Bass</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34550</link>
		<dc:creator>Tim Bass</dc:creator>
		<pubDate>Sun, 07 Mar 2010 16:48:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34550</guid>
		<description>Note:  I don't think a professional association like we are referring to must be 100% "vendor free";  they can have narrowly defined associate roles that do not drive charter, serve in leadership positions, etc.  All relationships must be disclosed, etc.

For example, Gartner receives consulting" or "seminar" money from the same vendors they are evaluating for their "magic carpet ride".... !!   Vendors wine them and dine them very well.  The entire industry is full of "corrupt" practices accepted as the "standard order of business".

The same is true for all these web sites and trade rags with  "writers" and "bloggers" blogging for money, undisclosed, third party press releases... .the entire industry needs to be reformed, in my biased opinion.</description>
		<content:encoded><![CDATA[<p>Note:  I don&#8217;t think a professional association like we are referring to must be 100% &#8220;vendor free&#8221;;  they can have narrowly defined associate roles that do not drive charter, serve in leadership positions, etc.  All relationships must be disclosed, etc.</p>
<p>For example, Gartner receives consulting&#8221; or &#8220;seminar&#8221; money from the same vendors they are evaluating for their &#8220;magic carpet ride&#8221;&#8230;. !!   Vendors wine them and dine them very well.  The entire industry is full of &#8220;corrupt&#8221; practices accepted as the &#8220;standard order of business&#8221;.</p>
<p>The same is true for all these web sites and trade rags with  &#8220;writers&#8221; and &#8220;bloggers&#8221; blogging for money, undisclosed, third party press releases&#8230; .the entire industry needs to be reformed, in my biased opinion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Tim Bass</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34549</link>
		<dc:creator>Tim Bass</dc:creator>
		<pubDate>Sun, 07 Mar 2010 16:33:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34549</guid>
		<description>Yes, it is wrong for vendors to call themselves "CEP Engines' or "RETE compliant" and other terms without any oversight.     In addition, the oversight should be conflict-of-interest free, completely.    This means no software vendors, no analysts who receive money from vendors (Gartner &lt;em&gt;et al&lt;/em&gt;), no people serving on boards of companies (or advisers or consultants to those software companies) in the same domain.   

Hence, before you can all your software "RETE" you must open the kimono (no licensing muzzle orders) to an independent group of people.   The entire software industry is, for the most part, "marketing fraud", without oversight and controls, but pregnant with conflicts-of-interest, undisclosed relationships, etc.

Of course, there needs to be a well written charter for that organization, with  a set of guiding principles, etc. that defines the organization before it seeks membership.</description>
		<content:encoded><![CDATA[<p>Yes, it is wrong for vendors to call themselves &#8220;CEP Engines&#8217; or &#8220;RETE compliant&#8221; and other terms without any oversight.     In addition, the oversight should be conflict-of-interest free, completely.    This means no software vendors, no analysts who receive money from vendors (Gartner <em>et al</em>), no people serving on boards of companies (or advisers or consultants to those software companies) in the same domain.   </p>
<p>Hence, before you can all your software &#8220;RETE&#8221; you must open the kimono (no licensing muzzle orders) to an independent group of people.   The entire software industry is, for the most part, &#8220;marketing fraud&#8221;, without oversight and controls, but pregnant with conflicts-of-interest, undisclosed relationships, etc.</p>
<p>Of course, there needs to be a well written charter for that organization, with  a set of guiding principles, etc. that defines the organization before it seeks membership.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Peter Lin</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34548</link>
		<dc:creator>Peter Lin</dc:creator>
		<pubDate>Sun, 07 Mar 2010 16:23:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34548</guid>
		<description>My bias perspective, there is a need for vendor free collaboration. There's always going to be vendor driven associations, but having vendor free group provides balance. A safe place where end users can speak freely and not have vendors get all militant.</description>
		<content:encoded><![CDATA[<p>My bias perspective, there is a need for vendor free collaboration. There&#8217;s always going to be vendor driven associations, but having vendor free group provides balance. A safe place where end users can speak freely and not have vendors get all militant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Tim Bass</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34546</link>
		<dc:creator>Tim Bass</dc:creator>
		<pubDate>Sun, 07 Mar 2010 15:32:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34546</guid>
		<description>Hello Peter,

I have seen some strong cross-discipline expertise in the multi-sensor data fusion field, supporting US DOD, where folks seems to collaborate with best-of-breed tools to solve complex multi-agent, multi-discipline architecture, but even then, there does exist professional bias.  

However, in the commercial space where the dialog is most driven by commercial vendors, cross-discipline expertise is rare.   Most people are pressured to be sales people,  not objective system architects recommending various best-of-breed systems and engineering them to work together.

Perhaps we are on the verge of a renaissance in this area as cloud-oriented computing services become more mainstream?

Maybe we should draft a new charter for an organization of people who are not vendor sales driven, not "my company wants me to do this and that driven..." and are truly a federation of objective cross-discipline system architects without conflicts of interest?</description>
		<content:encoded><![CDATA[<p>Hello Peter,</p>
<p>I have seen some strong cross-discipline expertise in the multi-sensor data fusion field, supporting US DOD, where folks seems to collaborate with best-of-breed tools to solve complex multi-agent, multi-discipline architecture, but even then, there does exist professional bias.  </p>
<p>However, in the commercial space where the dialog is most driven by commercial vendors, cross-discipline expertise is rare.   Most people are pressured to be sales people,  not objective system architects recommending various best-of-breed systems and engineering them to work together.</p>
<p>Perhaps we are on the verge of a renaissance in this area as cloud-oriented computing services become more mainstream?</p>
<p>Maybe we should draft a new charter for an organization of people who are not vendor sales driven, not &#8220;my company wants me to do this and that driven&#8230;&#8221; and are truly a federation of objective cross-discipline system architects without conflicts of interest?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Peter Lin</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34544</link>
		<dc:creator>Peter Lin</dc:creator>
		<pubDate>Sun, 07 Mar 2010 15:19:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34544</guid>
		<description>I spend most of my free time reading, researching and experimenting with pattern matching algorithms, temporal logic, production rule engines and AI. From my bias perspective, it's a full time job, so it's really really difficult to master all these related areas at the same time. Just looking at fuzzy logic, natural language parsing and statistical filters, it would take atleast a decade to master each one. To obtain sufficient experience and depth across multiple disciplines requires decades of dedicated study. I think it's safe to say to nobody today has achieved that level of experience and depth. The best thing we can hope for is collaboration between the most experience people and hope it will move the state of art forward.</description>
		<content:encoded><![CDATA[<p>I spend most of my free time reading, researching and experimenting with pattern matching algorithms, temporal logic, production rule engines and AI. From my bias perspective, it&#8217;s a full time job, so it&#8217;s really really difficult to master all these related areas at the same time. Just looking at fuzzy logic, natural language parsing and statistical filters, it would take atleast a decade to master each one. To obtain sufficient experience and depth across multiple disciplines requires decades of dedicated study. I think it&#8217;s safe to say to nobody today has achieved that level of experience and depth. The best thing we can hope for is collaboration between the most experience people and hope it will move the state of art forward.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by is Tim Bass</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34543</link>
		<dc:creator>is Tim Bass</dc:creator>
		<pubDate>Sun, 07 Mar 2010 09:45:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34543</guid>
		<description>I think it is interesting that a number of people have devoted much of their professional lives to optimizing rule-based approaches, especially to inferencing.

When I worked with TIBCO BE, I never considered BE an inferencing engine, because it was not really a "detection engine" as much as a "scheduling engine".  For this reason, I always viewed BE as a type of "core controller" that would be used to schedule complex transactions (which it does very well).   

For me, a forward-chaining event-driven rules-processing IDE such as BE was an excellent Blackboard Controller, scheduling and directing the work of many intelligent agents.     

So, when I worked on these types of projects before, I considered CEP a larger, more complete architecture, that required numerous components to detection complex events and situations.   

The primary reason I placed BE at the center of the BB architecture as the "BB Controller" function was based on the US DOD JDL architecture that is used to process complex events and sensor data.

It make no sense to me to reinvent the wheel, and the JDL is a very good, mature, and quite proven functional architecture for this type of processing.

Unfortunately, I have noticed that TIBCO has (seemingly) dropped this approach, and simplified their marketing material to a version of CEP that looks like a rules-engine; so they have (seemingly) collapsed the vision to match their product v. showing the product as a part of a larger architectural construct.

This is one key problem when vendors are defining the space v. outside experts; i.e. the folks who spent years defining the JDL for the DOD.     The JDL is a large scale distribution processing vision that can be applied to a very large class of complex problems.  

Reducing the vision to what fits a rules-engine is a bit like burning all the books in a library that are not about rules.

Maybe one issue is that that rule-processing, like RETE, is such a fascinating area, that folks who work deep in that area do not really have the time or energy to go deep into other areas?</description>
		<content:encoded><![CDATA[<p>I think it is interesting that a number of people have devoted much of their professional lives to optimizing rule-based approaches, especially to inferencing.</p>
<p>When I worked with TIBCO BE, I never considered BE an inferencing engine, because it was not really a &#8220;detection engine&#8221; as much as a &#8220;scheduling engine&#8221;.  For this reason, I always viewed BE as a type of &#8220;core controller&#8221; that would be used to schedule complex transactions (which it does very well).   </p>
<p>For me, a forward-chaining event-driven rules-processing IDE such as BE was an excellent Blackboard Controller, scheduling and directing the work of many intelligent agents.     </p>
<p>So, when I worked on these types of projects before, I considered CEP a larger, more complete architecture, that required numerous components to detection complex events and situations.   </p>
<p>The primary reason I placed BE at the center of the BB architecture as the &#8220;BB Controller&#8221; function was based on the US DOD JDL architecture that is used to process complex events and sensor data.</p>
<p>It make no sense to me to reinvent the wheel, and the JDL is a very good, mature, and quite proven functional architecture for this type of processing.</p>
<p>Unfortunately, I have noticed that TIBCO has (seemingly) dropped this approach, and simplified their marketing material to a version of CEP that looks like a rules-engine; so they have (seemingly) collapsed the vision to match their product v. showing the product as a part of a larger architectural construct.</p>
<p>This is one key problem when vendors are defining the space v. outside experts; i.e. the folks who spent years defining the JDL for the DOD.     The JDL is a large scale distribution processing vision that can be applied to a very large class of complex problems.  </p>
<p>Reducing the vision to what fits a rules-engine is a bit like burning all the books in a library that are not about rules.</p>
<p>Maybe one issue is that that rule-processing, like RETE, is such a fascinating area, that folks who work deep in that area do not really have the time or energy to go deep into other areas?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Peter Lin</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34542</link>
		<dc:creator>Peter Lin</dc:creator>
		<pubDate>Sun, 07 Mar 2010 03:35:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34542</guid>
		<description>Not to confuse things, but there's a third way to chain rules, which I've been researching for many years now. I call it bi-directional chaining. It's bi-directional in the sense that if the data is available, it works in normal forward chaining mode. If the data isn't in the working memory, the engine gets it and asserts it. By "get it" I mean it attempts to deduce it by looking at the rules and working memory. If it needs to, it will query external data source and assert the data. The reason for this is it reduces the need to generate subgoals and manage them. That's the theory anyways, I still haven't had time to work it through completely.</description>
		<content:encoded><![CDATA[<p>Not to confuse things, but there&#8217;s a third way to chain rules, which I&#8217;ve been researching for many years now. I call it bi-directional chaining. It&#8217;s bi-directional in the sense that if the data is available, it works in normal forward chaining mode. If the data isn&#8217;t in the working memory, the engine gets it and asserts it. By &#8220;get it&#8221; I mean it attempts to deduce it by looking at the rules and working memory. If it needs to, it will query external data source and assert the data. The reason for this is it reduces the need to generate subgoals and manage them. That&#8217;s the theory anyways, I still haven&#8217;t had time to work it through completely.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Peter Lin</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34539</link>
		<dc:creator>Peter Lin</dc:creator>
		<pubDate>Sun, 07 Mar 2010 03:08:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34539</guid>
		<description>Here is the link to Paul Haley's paper from 20 yrs back.

http://haleyai.com/wordpress/2008/03/11/goals-and-backward-chaining-using-the-rete-algorithm/

Haley rule engine implemented this approach, so oracle has it now.</description>
		<content:encoded><![CDATA[<p>Here is the link to Paul Haley&#8217;s paper from 20 yrs back.</p>
<p><a href="http://haleyai.com/wordpress/2008/03/11/goals-and-backward-chaining-using-the-rete-algorithm/" rel="nofollow">http://haleyai.com/wordpress/2008/03/11/goals-and-backward-chaining-using-the-rete-algorithm/</a></p>
<p>Haley rule engine implemented this approach, so oracle has it now.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on RETE Engines Must Forward and Backward Chain?! by Charles Young</title>
		<link>http://www.thecepblog.com/2010/03/06/rete-engines-must-forwards-and-backwards-chain/#comment-34537</link>
		<dc:creator>Charles Young</dc:creator>
		<pubDate>Sun, 07 Mar 2010 00:09:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.thecepblog.com/?p=500#comment-34537</guid>
		<description>And to clarify further on backward chaning, a common misunderstanding (I know because I used to assume this at one time) is that forward chaining is synonymous to the match-resolve-act cycle and therefore backward chaining must somehow use some different cycle.   This is not the case, which is why, although backward chaining is not 'required' by Rete, Rete engines can be, and sometimes are, built to perform backward chaining.   Indeed, at a deeper level, backward chaining is a natural approach for production systems.   Grammar-driven parser generators are an example of a type of production system which in essence perform backward reasoning.   Paul Hayley suggested, some years ago, that an automated approach to ‘full’ backward chaining (i.e., automatically instrumenting rule sets to perform backward chaining wherever possible) will generally yield a performance benefit in most common scenarios, and I think he is probably correct, although it would take some proper research to really establish this beyond doubt.</description>
		<content:encoded><![CDATA[<p>And to clarify further on backward chaning, a common misunderstanding (I know because I used to assume this at one time) is that forward chaining is synonymous to the match-resolve-act cycle and therefore backward chaining must somehow use some different cycle.   This is not the case, which is why, although backward chaining is not &#8216;required&#8217; by Rete, Rete engines can be, and sometimes are, built to perform backward chaining.   Indeed, at a deeper level, backward chaining is a natural approach for production systems.   Grammar-driven parser generators are an example of a type of production system which in essence perform backward reasoning.   Paul Hayley suggested, some years ago, that an automated approach to ‘full’ backward chaining (i.e., automatically instrumenting rule sets to perform backward chaining wherever possible) will generally yield a performance benefit in most common scenarios, and I think he is probably correct, although it would take some proper research to really establish this beyond doubt.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
