Our software is translating even long and complicated sentences from regulations to textbooks into formal logic (i.e,, not necessarily first-order logic, but more general predicate calculus). As you can see below, we can translate this understanding into various logical formalisms including defeasible first-order logic, which we are applying in Vulcan’s Project Halo. This includes classical first-order logic and related standards such as RIF or SBVR, as well as building or extending an ontology or description logic (e.g., OWL-DL).
We’re excited about these capabilities in various applications, such as in advancing science and education at Vulcan and formally understanding, analyzing and automating policy and regulations in enterprises.
English translated into predicate calculus
an unambiguously, formally understood sentence
English translated into SILK and Prolog
The folks from Knowledge Partners have a post that I found thanks to Sandy Kemsley, whose blog often provides good pointers. This article talks about the decision perspective on business rules. It makes some good points, on which I would like to elaborate albeit at a more semantic or knowledge-level.
Every language has three kinds of statements: questions, statements, and commands. There are also some peripheral types, such as exclamations (Yikes!), but in business processes and decisions only declarative and imperative sentences matter.
From a process- or decision-oriented perspective, decisions are always phrased as imperative sentences. Otherwise, the statements reflected in any business process, whether you are using BPMN or a BRMS, are declarative sentences.
Decisions are imperative sentences because they state an action to be taken. For example, decline a loan or offer a discount. It’s really pretty simple. A decision is an action. Rules that don’t take actions are statements of truth. Such declarative statements of truth are perfect for formal logic, logic programming, and semantic technologies. It’s the action that requires the production rule technology that dominates the market for and applications of rules.
The authors of the aforementioned article use the following diagram to explain the benefits of the decision-oriented approach in simplifying business processes:
The impact is very simple. If you eliminate how you reach decisions from the flow that you diagram in BPMN things get simpler. It’s really as simple as realizing that you have removed all the “if” parts (i.e., the antecedents) of the rule logic from the flow chart.
So who in their right mind would use a business process tool to express any business logic? Continue reading “What could be more strategic than process or decision management?”
Today, I came upon some commentary by a business rule colleague, Carlos Serranos-Morales, of Fair Isaac concerning a presentation I made at the Business Rules Forum. During the presentation I showed some sentences that are beyond the current state of the art in the business rules industry. Generally speaking, these were logical statements that did not use the word “if”. (Note, however, that many of the them could be expressed in SBVR, OMG’s semantics of business vocabulary and rules standard). Carlos argued that such statements should be more precisely articulated within the specific context of a business process.
Here is the slide that triggered the controversy:
Continue reading “How is a process an event?”
James Taylor’s notes on his lunch with Sandy Carter of IBM and the CEO of Ilog prompted me to write this. Part of the conversation concerned the appeal of SOA and rules to business users. Speaking as a former vendor, we all want business people to appreciate our technology. We earn more if they do. They say to IT “we want SOA” or “we want rules” and our sale not only becomes easier, it becomes more valuable. So we try to convince the business that they are service-oriented, so they should use SOA. Or we tell the business that they have (and make) rules, so they should use (and manage their own) rules. And rules advocates embrace and enhance the SOA value proposition saying that combined, you get the best of both worlds. This is almost precisely the decision management appeal. Externalize your decisions as services and externalize rules from those services for increased agility in decision making. This is an accurate and appropriate perspective for point decision making. But it doesn’t cover the bigger picture that strategic business people consider, which includes governance and compliance.
Effective SOA and business rules have one requirement (or benefit) in common: externalization.
The externalization of services from applications Continue reading “Externalization of rules and SOA is important – for now”
Work on acquiring knowledge about science has estimated the cost of encoding knowledge in question answering or problem solving systems at $10,000 per page of relevant textbooks. Regrettably, such estimates are also consistent with the commercial experience of many business rules adopters. The cost of capturing and automating hundreds or thousands of business rules is typically several hundred dollars per rule. The labor costs alone for a implementing several hundred rules too often exceed $100,000.
The fact that most rule adopters face costs exceeding $200 per rule is even more discouraging when this cost does not include the cost of eliciting or harvesting functional requirements or policies but is just the cost of translating such content into the more technical expressions understood by business rules management systems (BRMS) or business rule engines (BRE).
I recommend against adopting any business rule approach that cannot limit the cost of automating elicited or harvested content to less than $100 per rule given a few hundred rules. In fact, Automata provides fixed price services consistent with the following graph using an approach similar to the one I developed at Haley Systems.
Continue reading “The $50 Business Rule”