In another of our design pattern series, this week we look at two important elements of Oracle Intelligent Advisor platform capability. The example concerns a common scenario for eligibility – tell me if a citizen has had two consecutive situations in their life. Let’s see the example which uses temporal attributes.
Consider a person who has a variety of personal or professional situations in their life. Sometimes employed, sometimes unemployed, sometimes on sick leave, sometimes undertaking an apprenticeship, and so on. Our eligibility rules might look something like this. “A person is eligible for this service / or benefit if they have had a period of unemployment of at least 30 days, and if the unemployment period was followed by a period of employment”. Of course you can make this more complicated but we are talking about design patterns here.
So you probably just have a bunch of data coming out of either a CRM system like Siebel or a third party such as the employers national database. And it looks like this before we convert it to temporal data.
And that’s all you have. Now, we also understand that you might not have start and end dates, but calculating them is for another article. Let’s assume that you do, or that you have calculated the start and end dates. Note that we have calculated, in this case, the end date of the last row as being the latest possible date, which we might use to indicate that the job is “ongoing”.
So we transfer all this into a temporal attribute, to build a chronology and to be able to look at a single attribute.
At which point, you can visualise the result in the Debugger using the Temporal Visualisation:
So we now have a single temporal attribute to look at. But it doesn’t really help us. We need to set up some Boolean attributes to handle our requirements. For example, we can flag unemployment for a duration of more than 30 days, or less than 30 days, or employed for each of our five records.
And we can turn that into a temporal attribute to look at:
So if we visualise our new attribute alongside the previous one, we get this.
The new temporal attribute already allows us to properly identify when the person was in work, or what kind of unemployment they were experiencing (short or long duration).
With this we can now apply the second piece of logic. We want to know if there were any periods of employment preceded by a period of long unemployment.
So if we can find a period of work “INJOB” that is preceded by a period of “LONG” unemployment, we know that is in line with our requirement.
And we can easily identify if our person is eligible. This design pattern appears often –
1 ) Creating temporal chronology to be able to visualise data as a single time-based attribute
2) Creating one or more booleans to identify the different rows
3) Using ValueAt() to inspect the chronology and looking back to see what happened earlier (note the AddDays using -1, to step into the previous status)
Have fun. Here are some related articles about Temporal Reasoning: