Real Rule of the Week: Defining a Subconcept
In our first of a series of real rule examples we consider the case where a subconcept is defined by means of a derivation rule with the help of a condition on the properties of the superconcept.
The rule states: A woman is a female whose age is greater than 21. The underlying vocabulary of this rule, depicted in the diagram to the left, includes the concepts person, female and woman, where woman is a subconcept of female, which is in turn a subconcept of person, and the person properties name and age.
The defined concept, woman, is in the conclusion of the rule, while the condition consists of two parts: a classification of something as a female and an attached requirement that the age of that female must be greater than 21. This gives us a rule with a classification conclusion for infering that x is a woman, and with a classification condition, requiring that x is a female, and an inequality condition, requiring that the age of x is greater than 21. The rule can be visualized as shown in the diagram to the right. The circle epresents the rule, its label DR stands for derivation rule. Incoming arrows attached to a rule circle represent conditions, and the outgoing arrow represents the conclusion.
If you wonder, what kind of visual representation I'm using here, it's the UML-based visual rule language URML developed in the REWERSE research project Rule Modeling and Markup.
The UML comes with a formal languge for expressing integrity rules and derivation rules, called OCL. Unfortunately, OCL supports only derivation rules for defining properties, but not for defining (sub-)classes. We'll use it in some of our next real rule of the week posts.
In the predicate logic syntax of the logic programming language Prolog, this rule would be formalized as
woman(X) :- female(X), age(X,Y), Y > 21.
It would be nice to collect further formalizations in other rule languages. Can you add your favorite one?
- Login to post comments
I have used Blaze quite a
I have used Blaze quite a bit and my experience is that template development, template management and everything related to templates as such makes the whole rule writing process extremely difficult. Well if there are ways to make rules easier to read (and write) definitely Blaze templates isn't one of them!
Blaze Advisor rule syntax
In this case we would define this as a pattern something like this:
It's a little easier to read than the Prolog :-)
Subsequent rules could have conditions like
James Taylor Check out my Enterprise Decision Management blog at edmblog.fairisaac.com
RE: Blaze Advisor rule syntax
Is the Blaze Advisor rule syntax really easer to read? Of course, your phrase above is easier to read, but that's not the formal syntax, which you would need to compare in order to be fair.
This is the formal syntax.
This is the formal syntax. This is what you write in the IDE if you want to write it directly. You can make it easier to read if you want using templates but this is as formal as it gets.
Not all rules languages make it hard to define things.
James Taylor
Check out my Enterprise Decision Management blog at edmblog.fairisaac.com