Background for our Semantic Technology 2013 presentation

In the spring of 2012, Vulcan engaged Automata for a knowledge acquisition (KA) experiment. This article provides background on the context of that experiment and what the results portend for artificial intelligence applications, especially in the areas of education. Vulcan presented some of the award-winning work referenced here at an AI conference, including a demonstration of the electronic textbook discussed below. There is a video of that presentation here. The introductory remarks are interesting but not pertinent to this article.

Background on Vulcan’s Project Halo

From 2002 to 2004, Vulcan developed a Halo Pilot that could correctly answer between 30% and 50% of the questions on advanced placement (AP) tests in chemistry. The approaches relied on sophisticated approaches to formal knowledge representation and expert knowledge engineering. Of three teams, Cycorp fared the worst and SRI fared the best in this competition. SRI’s system performed at the level of scoring a 3 on the AP, which corresponds to earning course credit at many universities. The consensus view at that time was that achieving a score of 4 on the AP was feasible with limited additional effort. However, the cost per page for this level of performance was roughly $10,000, which needed to be reduced significantly before Vulcan’s objective of a Digital Aristotle could be considered viable.

Continue reading “Background for our Semantic Technology 2013 presentation”

April 7, 2013September 27, 2018

Semantic Technology & Business Conference (SemTechBiz)

Benjamin Grosof and I will be presenting the following review of recent work at Vulcan towards Digital Aristotle as part of Project Halo at SemTechBiz in San Francisco the first week of June.

Acquiring deep knowledge from text

We show how users can rapidly specify large bodies of deep logical knowledge starting from practically unconstrained natural language text.

English sentences are semi-automatically interpreted into predicate calculus formulas, and logic programs in SILK, an expressive knowledge representation (KR) and reasoning system which tolerates practically inevitable logical inconsistencies arising in large knowledge bases acquired from and maintained by distributed users possessing varying linguistic and semantic skill sets who collaboratively disambiguate grammar, logical quantification and scope, co-references, and word senses.

The resulting logic is generated as Rulelog, a draft standard under W3C Rule Interchange Format’s Framework for Logical Dialects, and relies on SILK’s support for FOL-like formulas, polynomial-time inference, and exceptions to answer questions such as those found in advanced placement exams.

We present a case study in understanding cell biology based on a first-year college level textbook.

March 28, 2008July 14, 2018

Harvesting business rules from the IRS

Does your business have logic that is more or less complicated than filing your taxes?

Most business logic is at least as complicated. But most business rule metaphors are not up to expressing tax regulations in a simple manner. Nonetheless, the tax regulations are full of great training material for learning how to analyze and capture business rules.

For example, consider the earned income credit (EIC) for federal income tax purposes in the United States. This tutorial uses the guide for 2003, which is available here. There is also a cheat sheet that attempts to simplify the matter, available here. (Or click on the pictures.)

What you will see here is typical of what business analysts do to clarify business requirements, policies, and logic. Nothing here is specific to rule-based programming. Continue reading “Harvesting business rules from the IRS”

February 25, 2008June 20, 2019

Agile Business Rules Management Requires Methodology

Don’t miss the great post about his and Ilog’s take on rule and decision management methodologies by James Taylor today (available here).

Here’s the bottom line:

Focus on what the system does or decides.
- Focus on the actions taken during a business process and the decisions that govern them and the deductions that they rely on.
- In priority order, focus on actions, then decisions, then deductions.
Don’t expect to automate every nuance of an evolving business process on day one – iterate.
- Iteratively elaborate and refine the conditions and exceptions under which
  - actions show be taken,
  - decisions are appropriate, and
  - deductions hold true

Another way of summing this up is:

Try not to use the word “then” in your rules!

Do check out the Ilog methodology as well as the one I developed for Haley that is available here. The key thing Continue reading “Agile Business Rules Management Requires Methodology”

January 8, 2008September 27, 2018

Elicitation and Management of Rules, Requirements and Decisions

A manager of an enterprise architecture group recently asked me how to train business analysts to elicit or harvest rules effectively. We talked for a bit about the similarities in skills between rules and requirements and agreed that analysts will fail to understand rules as they fail to understand requirements.

For example, just substitute rules in the historical distribution of requirements failures:^[1]

34% Incorrect requirements
24% Inadequate requirements
22% Ambiguous requirements
9% Inconsistent requirements
4% Poor scoping of requirements
4% Transcription errors in requirements
3% New or changing requirements

Continue reading “Elicitation and Management of Rules, Requirements and Decisions”

January 3, 2008October 20, 2018

When Rules Meet Requirements

I am working on some tutorial material for business analysts tasked with eliciting and harvesting rules using some commercial business rules management systems (BRMS). The knowledgeable consumers of this material intuitively agree that capturing business rules should be performed by business analysts who also capture requirements. They understand that the clarity of rules is just as critical to successful application of BRMS as the clarity of requirements is to “whirlpool” development.^[1] But they are frustrated by the distinct training for requirements versus rules. They believe, and I agree, that unification of requirements and rules management is needed.

Consider these words from Forrester:

One might argue that Word documents, email, phone calls, and stakeholder meetings alone are adequate for managing rules. In fact, that is the methodology currently used for most projects in a large number of IT shops. However, this informal, ad hoc approach doesn’t ensure rigorous rules definition that is communicated and understood by all parties. More importantly, it doesn’t lend itself to managing the inevitable rules changes that will occur throughout the life of the project. The goal must be to embrace and manage change, not to prevent it. ^[2]

But note that Forrester used the word “requirements” everywhere I used “rules” above!

Continue reading “When Rules Meet Requirements”