Tag: natural language

Rule Design – How Far Do You Go?

Rule Design – How Far Do You Go?

The topic of genericization in rule design came up the other day. I should explain first what was meant, and the easiest way to do that is with an example.

Suppose an OPA Customer conceives a rule that looks a little bit like this

Rule Design OPA 12Some time later, the same customer finds that there are several similar rules, such as the next one below.

An attempt is made to streamline the rules into a more appropriate structure first of all. So a rule might be rewritten to take into account not just a boolean conclusion but something more interesting, such as return codes.

Rule Design OPA 12Shortly after that, as the realization dawns that there are thousands of rules like this, a further effort occurs to streamline the concept even further as shown in the example below.

Rule Design OPA 12Here we can see the rules are broken down in the manner of with input arguments that may be numbers, Booleans and so on. The exact components of each validation are detailed. This is further extended and generalized, broken across Excel and Word (to cope with grouping operators like either) and what have you.

And so the usage of the validations becomes something a little like this (I am exaggerating for effect). Further tables are created to schematize which rules are used in which business context. We shorten the attribute names, create legends, standardize the text used.

Rule Design OPA 12

We are so far away from anything resembling natural language that we might as well be using the Microsoft Win32 API. We have delivered our Rule Design but have we best served the customer? Of course the context is key (the audience for the rule design documents, the purpose of the rules – Web Service or Interview, to mention only a couple of criteria) but the presence of different teams and different competing teams – internal or external – seems to lead to black box designs that only serve to frustrate the customer.

Natural Language in Oracle Policy Modeler- Missing Translations

Natural Language in Oracle Policy Modeler- Missing Translations

One of the things that irritates me, and I am sure (since I ask) other people is the lack of support for natural language versions of some pretty basic functions. For example, in English you can write (this is a screenshot in version 12 of Oracle Policy Modeler, in a Microsoft Word document) the following conclusion using a natural language “long form” function on the right hand side of the equals sign:

english natural language

This is a pretty standard function (the current date time) and I can think of gazillions of places where you would neeed to use it. In French, for example, the identical conclusion in a similar Project would need to look like this, where you can immediately see the section after the equals sign is no longer in natural language “long form”. You can find the function in the French function reference on the web here:

FRENCH FUNCTION WITH ONLY SHORT

So why is this function not available to be written in “long form” in French (and in a number of other supported languages)? This is because of the lack of natural language French equivalent for the “current date time” function, in the dictionary file. Now I’m not suggesting this is a showstopper, but natural language is one of the biggest selling points of Oracle Policy Modeler in respect of working with non-technical team members. So it would be nice to see a more complete investment in providing translations for common functions.

For esoteric ones, I get it, it can be hard, But this is an easy one and a translation can readily be found. In a few days we will take a look at how to resolve this kind of issue.

OPA 12 – It’s all in the Natural Language Text

OPA 12 – It’s all in the Natural Language Text

OPA 12 – It’s all in the Natural Language Text

I suppose this article could have just as easily been about Oracle Policy Modelling 10 as well. But since I was teaching version 12 I decided to use it for the screenshots. I also was teaching a group of French students so the examples are in French and English. Ultimately the same challenges occur no matter what language you are using, provided that language uses definite articles in the same way. Natural Language is not always natural.

Consider the following :

An Entity called “the contact” or “l’interlocuteur”.

OPA 12 - Contact Entity Natural Language

As you can see, the Relationship Text has been changed to “tous les interlocuteurs” or “all the contacts” instead of the standard “all instances of the contact” or “toutes les instances de l’interlocuteur”. I see a lot of students working in this way. However there are some side effects of using this kind of wording…

Let’s imagine that every contact has a telephone number, and we want to check that the telephone number has been entered. The first part is fine, we can write the following rule to assign a Boolean value depending on whether we have a telephone number or not, and let’s build a rule that uses Entity Quantifiers to look at the different contacts.

When is Natural Language really Natural?OPA 12 - For Each of the Contacts Natural Language

In English we would have something like

OPA For Each Contact in English Natural Language

We are using the longest version of the “natural language” Function “ForAll“. And it looks a bit, well, long-winded. So we might try one of the other versions:

OPA 12 - For Each of the Contacts EN Part Two Natural Language

That’s even worse. In French too it’s almost comical …

OPA 12 - For Each of the Contacts FR Part Two Natural Language

That’s even worse. So let us try a different approach. We decide to modify the Relationship Text and remove the “all” to leave only “the contacts” or “les interlocuteurs”. So now our rules look a bit more “natural language” when we use the ForAll function in it’s long form.

OPA 12 - For Each of the Contacts EN Part Three Natural Language

OPA 12 - For Each of the Contacts FR Part Three Natural Language

Of course I can hear people saying, why don’t you just use ForAll or PourTous – that is, the terse or short version of the function? It does of course depend on your environment, but a non-technical user is going to be far more comfortable using a natural language-based solution.

Have fun improving your text, until next time

Rich@rd

Policy Automation – Jargon Busting – Natural Language

Policy Automation – Jargon Busting – Natural Language

A serious problem in the design of business rules of any kind, or the interpretation of existing legislation or jurisdiction is that most computer programs do not allow us to construct rules in a natural way.

Siebel Tools, for example, lets us use syntax like [Field Name] + [&Property Name] as well as a library of functions. This is hard to “sell” to business users when you want to give them confidence in the translation of the “paper” rules into the “system” rules.

Policy Automation increases our ability to respond to these situations by using “natural language”. This does not mean necessarily that you can copy out existing text word for word, but it does get us a lot closer. Let us see a couple of examples that will introduce key elements of the tools and the practical aspects of rule creation.

Open up your Policy Modelling application, create a new Project called “ODE – Natural”. Set the language to “English American” and the locale to “United States – English”.

Examine the text in the below”Source” document. Notice how the document is broken down into sections. This is a common feature in legal documents. Notice how the document speaks about guests, members and so on.

OPA - Natural Language Members and Guests

Using the “Design” files provided (see the previous post) let us compare. Please note, these files are just for comparison purposes and are not optimized in any way. Right-click the “Design” folder (inside the Documents folder) and select “Add Existing File”. Add both the Excel file and the Word file.

OPA Natural Language Members and Guests Rules

Some features that are important to highlight.

  • The “1” and “2” and (a)…(c)  used to mirror the structure of the source
  • The color-coded structure using strict Formatting
  • The large, clear descriptive headings in the document
  • The full text variable names at the top of the document
  • The need to still use functions (ExtractTimeOfDay for example)

Using the Build menu, select “Build and Run” and the default “Run with Web Determinations” option.

OPA - Natural Language Initial Screen

Observe that when you click on the “Why?” you are told that Section 2 has been satisfied. When correctly formatted using numbers like the example, rules will automatically generate this kind of summary. This is great for reassuring and familiarizing business people with the rules that map to their source documents.

Proceed to the session, answering that you are 18 years old, that you have spent 14 dollars and that you belong to the Paris club, and that your guest has completed the questionnaire. You should see that you are able to invite guests into the club. Click the “Why” link again.

OPA Natural Language Why

Again, the formatting has reproduced the structure of the source. Now replace the existing Word file (Right Click, “Remove File from Project”) with another version “Design2”. Observe how the structure of the Word document is slightly different (but the content is the same). In Policy Modelling, the format of the text is all important, since it tells the engine several things

  • What the conclusions and main goal are
  • What the structure of the logic is (Level 1, Level 2 formatting)
  • How to parse the content of your Word file (where the “questions” are)
  • What text to ignore (Heading, Comments, Blank Lines)

The formatting is achieved by use of the Policy Modelling toolbar. Rerun your “Build and Run” with the same data as before, notice the “Why?” this time matches the original text, because of the changed structure of the file. (Note in the example below, we set the “closing time” of the club to 6pm…)

OPA Natural Language Guest Accepted

In Policy Modelling, there are often multiple ways to write something, but we must balance writing fast (less understandable) and writing well (helping the business understand the correlation with the source text), all the time writing “understandable” sentences for Policy Automation using the correct formatting. We can come close to natural language, far closer than ever before.

Finally, change the computer clock to a “closed” time, or carefully edit the Word document to be “closed”. Rerun and observe you are not even able to begin the question and answers, because :

OPA Natural Language The Club is Closed

This is because of another jargon item, which we will discuss in the next post.

PS – the “club rules” used were inspired by documents like this one.

PPS [Note : Orginal Attached Files that belonged with this post have been removed. If you want them please contact the author]

Jargon Busting

Jargon Busting

The world we work in loves jargon. Let’s face it, many of the terms we work with (CRM, SRF, SEM) are impenetrable to the outside world in the wide sense. Worse still, the terms we love mean various things to different people. Some Siebel-related or Oracle Policy Automation-related terminology surprises:

  • Crew Resource Management (CRM) in aviation
  • Solid Recovered Fuels (SRF)  in waste and energy management
  • Standard Error of the Mean (SEM) in statistics
  • OPA – Offre Public d’achat – public share offering
  • Oracle Policy Modelling (OPM) – Office of personnel management

Any time new students and new vocabulary meet, there is bound to be an interesting jargon busting challenge in the training room. Policy Automation is a great example. Inference, Forward and Backward Chaining, Determination, Constrained Natural Language (ha!), they all get us in a bit of a spin.

So we decided to begin a “jargon buster” micro-lecture series for Policy Automation. Read them on this blog and hopefully it will accelerate your learning as you delve into Oracle Policy Automation.

Worldwide
Logo by Southpaw Projects LLC