Category: Other Languages

Back to Basics 6 – Always Check your Parse

Back to Basics 6 – Always Check your Parse

Back to Basics 6 – Always Check your Parse

This is of course connected to the previous remarks about constructing phrases with booleans or non-booleans. But I would like to take a moment to go a little further and remind those of you starting out of the importance of the parsing process. In some ways, the old Version 10 user experience, where the parsing engine results were popped up in Word directly, when you validated / compiled your work, was easier to explain. It oriented users towards the idea of checking the parse straight away:


In the above example, everything is fine. But the process was useful when the writer had failed to be clear in their ideas, because at least then the Select Parse window showed there might be a bit of a problem right after we clicked the button:


So in the case above, we can see that there are two verbs in our made-up phrase, and the parser has flagged that to us. In Version 12, the validation process no longer shows the dialog above – te process is largely silent and transparent. I can see this as a benefit in terms of experience but it takes away the immediate sense of checking the text and parse. To get the same sort of information you have to go into the Attribute list in the Data tab, double-click the Attribute and then click the Change button shown below:


I just think that it could be a little easier for users to find. But I’m just a slow learner. I would however say that this deserves to be in our top ten of back to basics items, since checking the parse and verifying the coherence of the generated text is something to get used to very early on. And it is valid for any language that is supported by Oracle Policy Modeler.

A quick thank you

While I am writing this, I want to thank all our readers and happily report that we have just gone past the 100 post mark. Here’s to the next 100!

Until the next time, take care!

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:


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.

Expense Report – Les notes de frais (formation OPA)

Formation OPA – Les notes de frais

Suite a la formation : OPAEn formation, il m’arrive souvent d’utiliser un modèle de donnes simple et très connu dans les différents exercices. Il n’est pas toujours utile, pédagogiquement parlant de construire un modèle d’entités très complexe d’entrée de jeu, lors qu’on découvre Oracle Policy Automation. C’est déjà assez compliqué- on aborde des idées neuves, une manière nouvelle d’écrire des règles, une nouvelle façon de construire des entretiens dématérialisés.

C’est à ce titre que je vous propose de télécharger le zip du célèbre projet “Notes de Frais”. Une fois le projet téléchargé, si vous recevez un message concernant la disponibilité du Hub OPA au moment de l’ouvrir, il suffit d’annuler pour continuer. Les thèmes abordés sont évoqués plus en détail dans le livre Getting Started with Oracle Policy Automation.

Comment Télécharger ce projet “formation”?

Pour télécharger il suffit de vous connecter avec vos identifiants (c’est gratuit, sans spam et sans risque) et ensuite de revenir ici – le lien s’affichera automatiquement en fin d’article. D’autres projets viendront compléter la série cet été.


OPA 10 – Missing “It is currently known”

OPA 10 – Missing “It is currently known” in a non-English language

This is an old one but it comes up now and again. Discussing with an Oracle Policy Modeler user (that was running Policy Automation in version 10.3) the other day, she remarked upon the lack of support for “it is currently known” or “it is currently unknown” in the rule language of choice of the user and how something that worked fine in another project (using a later version) did not compile at all in 10.3.  The solutions was to modify the relevant template file to provide the French mapping for the relevant English phrase.

In the installation folders of the relevant Oracle Policy Modeler, the templates.xml file can be located : choose the file relevant to the language needed (in this case for example the folder was “C:\….Policy Modeling\language\French\templates.xml”).

In this file we can see the different template of english phrases (for example, “currently known” or “currently unknown”) mappings to their non-English translations. If necessary, add the relevant Statement Operators and Variable Operators to the file, and restart Oracle Policy Modeler.

Check the existence of, or add t the following in the “statement operator” section of the file:

OPA 10 - Statement Operators

And the following  to the “variable operators” section of the same file:

OPA 10 -Variable Operators

These modifications allowed the documents in French to compile and be used. There are quite a few similar posts hanging around on the Internet, for example here is one involving Swedish.

Of course one should pay close attention to the XML file structure, and where possible use an existing language XML to help model the correct elements in your chosen language to create a valid XML structure for your templates.xml. In this case the easiest approach was to search for “currently known” in an existing file and work from there.

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


OPA – Entities Adventures #7 Scope in OPA …


Back to the Workshop!

In this episode, we will look at the subject of cross-entity reasoning again to investigate some functions which we do not cover in the Policy Automation training. Firstly though, we need to talk about Scope.


Many users of Policy Automation will be familiar (and not in a good way) with “X is not in scope. You may need to use an alias when referring to the X”. It’s one of those errors that most people will get in the construction of rules. To make matters worse, sometimes juggling the rules and changing the order, or moving them into different files, and the error goes away. So what is going on?

Firstly, we need to understand how the Word Compiler works. For it is the Word Compiler we need to think about. The Word Compiler works from top to bottom down the page. And as it works down the page, it uses the entity instances defined in the previous line, as the scope of the current line. Let’s extend our rulebase and focus on customer satisfaction to demonstrate.

Add two new entities, the customer, and the wheelcover. Make sure the wheelcover is a child of the Car entity.[/vc_column_text][vc_single_image image=”9033″ img_size=”full” alignment=”center” img_link_large=”yes”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]Add the relevant Reference Relationships and make sure the Relationship Text is suitably friendly[/vc_column_text][vc_gallery type=”flexslider_slide” interval=”3″ images=”9036,9037″ img_size=”735×666″ title=”The New Relationships”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]

Scope in our Word Document Example

Now Consider the following piece of rule text from Microsoft Word. Notice the “cascading logic”.

In the Conclusion, we set up the initial scope as the Customer. In the first line we proceed to “narrow” the Scope to the Customer’s Car. This is acceptable as there is a Relationship defined with the Customer as the Source and the Car as the Target, and it is One to One.

In the next line, we scope down to the Car’s Wheelcovers. Again, as the Customer’s Car was in scope in the previous line, this is acceptable as the Car has a Child Entity called the Wheelcover and there is a Reference Relationship in place. Finally in the last line we have a condition that references the Wheelcover, since it is in Scope.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=”9045″ img_size=”full” alignment=”center” img_link_large=”yes”][vc_single_image image=”9046″ img_size=”full” alignment=”center” img_link_large=”yes”][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]For completion we show both the terse and the long form. Since the Word document may continue to have further rules in it, you always need to be vigilant about setting scope clearly in each of your rules.

In addition, we need to choose the correct function depending on the nature of the Relationship. In this respect the Function Reference is useful.

In the next episode we will continue our Workshop and build out the various logic we promised a few chapters ago, as well as continuing our Function discovery.

Until next time![/vc_column_text][/vc_column][/vc_row]

OPA – Entities Adventures #6 Cross Entity Reasoning

Cross-Entity Reasoning

Once again we return to the Cars and Mechanics in the mythical Workshop. The first part of this post will review the French version of the work done in the previous episode, and then we will undertake some cross-entity reasoning using the various functions at our disposal. Catch up with the rest of the series (12345)

The French version looks like this in the Web Determination window. First off, the basic structure is exactly the same and there are no challenges to report.

OPA - French Workshop

Eagle-eyed viewers will notice there is a problem (that we raised earlier in the context of Gender but now is as good a time as any) concerning the title of the page. In fact, despite the Project being French Language and French Region, all the labels are in English (“Data Review”, “Assessment Summary” etc.). You could be forgiven for thinking these came from the “Appearances Property File” in your Release folder:

OPA - Messages FR Properties

But no. The titles that I just mentioned are generated when you add a Screens File to your Project. So even though we have a French Project with French as the Rule Language, we get English titles!

OPA - Titles in English

Common Trap Number #10 – Screen Titles in the wrong language

Irritatingly enough the way to fix this (if it can really be called fixing) is to switch the Language of Policy Modelling to French before you start, in which case when you add a Screens File you will see valid Titles:

OPA - French Screens Titles

Then you can switch the editing language back to English and at least you have the right titles in your Screens File. (Tools > Options > UI Language). I know it sounds silly but there are many occasions when you want to create a Project in another language but you don’t want Policy Modelling User Interface to be in that Language.

Switching back to the English version of our Project, we can now get into some more Functions, specifically cross-Entity functions. These functions are designed to cope with the need to cross from Car to Mechanic in a rule. For example

Consider the fact that Mechanics exist in several types – Expert, Confirmed and Novice. We want to write rules that say

The Car will be ready on time if the Car’s Mechanic is an Expert.

The Workshop is running efficiently if at least 2 cars are being repaired by Experts

The Car, the Mechanic – these are our Entities. The Workshop, our “singleton parent Entity” is the standard Global parent Entiity proviided by Policy Automation.

Let’s look at the Function Reference for the For function that will be useful in our case. We are able to reason cross-Entity, as long as the Relationship type is correct (and between Car and Mechanic it is Many-to-One), and there is only one Condition (the Mechanic is an Expert.

Assuming you take a moment to create an Attribute “The Mechanic’s level” of type Text, then you could examine the following from the Function Reference and get writing.

OPA - For Function Reference

As is often the case, there are long and short versions. There is nothing stopping you using one, or other of these versions as you prefer, interchangeably. But look closely and you will see the definition of the Function has some differences. The short or “terse” version “For (relationship, expression)” looks like this when we write it out: The following should compile.

OPA - For Terse Version


Common Trap #11 Assuming All Versions of Functions have the same syntax

But suppose you decided to write using the Long form, “in the case of“. The Function Reference gives a slightly different explanation for that version, if you look closely. It says “in the case of relationship, attribute”. Which is not the same thing as the previous example, And indeed, the example below does not compile.

OPA - For Long Version Error


The following example does however, Notice how in this example we have changed the “level” to be a Boolean attribute rather than a Text attribute. It would appear from the Function Reference that the long version is only possible with a Boolean. And that may mean you end up creating an intermediate rule like this:

OPA - For Function Intermediate RuleAnd that may be something you do not need or wish to do, so you decide to use the terse version. But before you give up on the long version, you see there is a third option in the Function Reference “<val>, in the case of <relationship>”. Interestingy, the “<val>” acronym appears only once on the entire list of Functions. And it is far from clear what it actually means. So best to avoid that.

Next time, we will continue and use some other Functions!


OPA – Entities Adventures #2 Question Screens…

Back to the Workshop

So we return to our Rulebase with Mechanics and Cars. Eagle-eyed readers will see this is an adapted version of an exercise in the Policy Automation training course. The version we are using here has different relationships and attributes than the one in the course. I am not intending to copy the material used in the course.

Next Steps

In the previous post we set up our Entities and experimented wth some Containment Relationship text. Now we can begin to study our Entiities in more detail and create / edit Attributes to extend the model.

Fire up the Debugger using Build and Debug without Screens. Let’s look at the output in the Debugger. Go ahead and right-click the “all the cars” icon and choose Add Instance.

OPA - Entities Create Instance

Since the car currently has only one Attribute, you don’t have much choice as to what to enter – just double-click the green bar and type something like “Ford Fiesta”.

OPA - Create Car Instance


Which brings us to the question – just what is this information we are entering? Where did it come from, and what issues may we have?

The Attriibute you are entering was created automatically when you created the Entity definition. It is the “identifying attribute”. If this was the Mechanic, maybe it would be his or her name, or employee Id. Since it is the car, what would it be? I’ll hasard a guess and say why not the car registration plate, since it is unique and a useful way to distinguish between all those cars in the workshop. Of course our Car Entity will have a Make and Model as well, no doubt. So let us correct all of this and spot a couple of other traps along the way.

Back out of the creation and Click Build > Stop Debugging. Now double-click the Attriibute and let us review. We want this to represent the Car Registration. So go ahead and change the text. And observe :

OPA - Car Registration Identifying Attribute

Common trap #4. The Car is not a he or a she (despite what some drivers thiink!). It is impersonal – an “It” if you will. Failure to update the Default Gender will of course make for strange output in the Decision Report and Debugger.

OPA - Car Gender Error


Take the opportunity to give the Attribute a public name as well. Now we have spoken about the Car Entity, what about the Mechanic – for the Mechanic there is another one to think about.

Common trap #5 The Mechanic needs to be defined as male or female (depending on your business scenario, this may not be useful for our Rulebase, but there are many situations where it is!). To set up the “Gender Attribute” is quite simple. We have covered it before so just visit this post and resume when the Mechanic has a Gender Attriibute defined. Your Mechanic Entity should now have 2 Attributes and should look like this.

OPA - Mechanic Gender

Note that we have also edited the Attribute Text for the Identifying Attriibute since the Mechanic’s name, in our case, will be enough to differentiate between them.

The Gender Attribute will come in very handy later on in the Web Determination and Decision Report for our Rulebase, Let’s now extend our Rulebase by adding a second rule to our Word Document. Make sure you create the Attribute as a Number and that you create it in the Properties Files (that could even be common trap #5b). The creation of the Attribute will look like this:

OPA - Attribute Creation in Word Document

And the Rules should look like this now.

OPA - All the Mechanics

Now that job is done, we can begin to investigate the Gender Attribute. Firstly, we need to create a Screen File in our Project, and Create a Question Screen inside it.

OPA - Mechanic Basic Question Screen

Check your own project against the screenshot. If you are seeing “Who is the mechanic’s name?” then you need to edit the Attribute to “impersonal”, or if you chose to keep the original Attribute Text “the mechanic” then you will see that instead. Notice the new icon to show the Gender Attribute.

Build and run your Web Determination, and click the link referring to Mechanics. Add a Mechanic using the Add New Instance button.

Ignore any warnings you might get at this stage since our Interview is not really ready yet, so it has no real goals.

OPA - Create Mechanic Screen Basic

Excellent – Policy Automation has given us the two radio buttons and has shown it understands this is a Gender Attribute.

Common trap #6 Asssuming that this is going to work in different languages.

As you may know, in this demonstration sequence we have also been maintaining a parallel version in French.

OPA - French Version of Project

Having entered the different Entities, Attributes, Rules in Word and having now created the Question Screen in the Screens File, this is what we get when we run the French Web Determination.

OPA - French Mechanic Screen Basic

I’m sure you can spot the issue. To correct this we could go to the Question Screen, and the Gender Attribute Question, and change the Display Values for the List of Values.

OPA - French Gender List of Values


And so finally we get good output when we Build and Run our Web Determination.

OPA - French Mechanic Screen Basic Improved

This editing of the Display Values may come in handy of course even if you are not working in a different language. The solution to the “male/ female” issue can be found in Part Six if you can wait that long.

In the next post in this series we will get our Reference Relationships up and running. Until next time!

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]

Logo by Southpaw Projects LLC