Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
ttrapp
Active Contributor

In my last weblog I blogged about modeling rulesets using ontologies. In a comment jann.mueller asked me whether it is possible to generate BRFplus rulesets from ontologies. I mentioned some problems and in fact I don’t think that interoperability standards between rule systems are quite useful for practical purposes. But this doesn’t mean that the approach of using ontologies is not useful – you have only to adjust the scope and this is what I’m doing right now: I show equivalence of classification using an ontology to a decision table and then I discuss the strengths and drawbacks of this approach.

Decision tables are probably the most useful expression type of BRFplus and they are available in HANA, too, which is a promising way to push business logic down to HANA.

Decision table are well understood and commonly used in software engineering. Bythe way: I developed my first one long time ago using Vorelle in Cobol. Decision tables are easy to use but if they grow in terms of columns development and maintenance can be difficult especially if the number of rows increases, too. As Carsten Ziegler pointed out BRfplus is ready even for huge decision tables but this doesn’t solve the problem of creating them and this is where ontologies can help.

Recenty new semantic approaches in the area of decision tables have been published, but in this blog entry I’ll try out a basic and straight-forward approach:

  • An OWL classification of a single can be translated to set of rows of a decision table. The datatype properties can be translated to rows of a decision table directly.
  • If the classification of the ontology consists of disjoint classes then all rows of a decision table can be merged into a big one.
  • You can check that OWL classes are disjoint using a reasoner, which is equivalent to ensure that the conditions do not overlap in the corresponding decision table.

This may sound complicated and so I provide a very simple example in the aear of insurance claims.

A Simple Example

Consider the case of a decision service that classifies a claim because of its value that is calculated using an expression or attribute of the content of a BRFplus function. This can be done in BRFplus using a small decision table having one input row (claim holder value) and the result is a classification with high or low value (in general a discrete set of values).

Now we do the same using an ontology. Using an ontology editor like Protégé we define a class (Claim) that represents BRFplus input and an attribute ClaimValue (part of the BRFplus context or calculated using a database view) that is represented in the ontology as datatype property that assigns a decimal value to a claim:

Then we define some subclasses of Claims: the class ClaimHighValue consist of claims having a value between 100 and 999:

Then I define another sublass: the class ClaimLowValue consists of claims with value less than 100:

It is obvious that these conditions can be translated as two rows of a decision table in BRFplus.

For testing purposes I define in the ontology an element test500 as element of Claim class with value 500 and using the a reasoner we can check that both conditions are disjoint (i.e. the class ClaimHighValue is disjoint with ClaimLowValue) and that the test500 element is classified correctly by reasoner als member of class ClaimHighValue:

We can see the same for the second class - again the inferred values are yellow highlighted:

So using data type reasoning we can check that both conditions do not overlap: the classes ClaimLowValue and ClaimHighValue are disjoint. There is only one drawback: the ontology can’t check whether the classification is complete: in fact a class ClaimVeryHighValue for Claims with value >= 1000 is missing. Of course we could define an element with that property and this would be a perfect test case for a missing classification but the reasoner can’t calculate this out of the box.

The reason is very simple: OWL (and, by the way SWRL, too) depends on the Open World Assumption and so there is no negation as failure: unless there is no element that proves that two classes don’t partition the whole set of elements then the reasoner won’t be able to make a statement about this partition. This is no defect and in fact a property of the decision logic used in OWL: OWL relies on the condition that a missing information does not prove the contrary. In other words: in an “open world” the existence of a black swan is possible although we have only seen white swans so far.

Towards Generation of Decision Tables

This was a very simple example but ontologies can consist of more complex conditions. In fact because of the Open World Assumption it is possible that you have to define even more properties (perhaps using features from SWRL) to get a more suitable (but in fact more complex) model. But you will never overcome the "restrictions" of the Open world assumption and in the end you will have to check the completeness of your model using a different algorithm. This could be done using a more sophisticated datatype reasoner or using BRFplus: just generate a decions table from the ontology and use completeness check in BRFplus.

Generating BRFplus artificats from ontologies is not difficult since we can add additional metadata to the ontology that are needed to generate a BRFplus function using the BRFplus API.

Summary

Ontologies provide a framework for classifications that can be used to model decision services especially decision tables. I think this is a nice to know for theoretical purposes but is this useful for practical purposes? Here I’m not sure: in my BRFplus projects I have been able to translate the complete set of rules into a huge decision table so far but in the end I favored a modularization using BRFplus functions or rule sets since often this is easier to understand. But there might be the case that rulesets can be quite large - and they will grow in the HANA context in my opinion – that a more structured approach can be useful for creation and maintenance. And here ontologies can help in my opinion. If have more experience with this approach and have some kind of best practices I will blog about them.

Again I attach the above used ontoloy as XML file to this blog entry - feel free to experiment with it. In fact I have many ideas for research topics (think of a diploma thesis for example): Can we define a description logic that represents decision tables in a better way? Could we generate decision tables (HANA and/or BRFplus) from ontologies, How do we bridge the type gap?

Labels in this area