This is a public Idea Center  publicRSS

Idea

    [Not Planned] OPA Oracle Policy Automation Temporal Temporal...
    Idea posted June 11, 2017 by Paul FowlerJourneyer, last edited July 6, 2017 by Davin FifieldApprentice, tagged Policy Automation 
    50 Views, 5 Comments
    Title:
    [Not Planned] OPA Oracle Policy Automation Temporal Temporal values for OPA
    User Story / Description:

    As a government entity, I need an easier way to write policy logic to recoup payment mistakes over time with Oracle Policy Automation.

    Those who write OPA rules are familiar with the conclusion of "today = the current date".  "today" is then used throughout the policy logic instead of the current date.

    For various reasons, "today" may be overridden and made temporal...  Usually that is to support recoupment or other time comparison logic.

    Currently, we must do that with a combination of Entities and Temporal values.

    If we could have temporal values of temporal values of temporal values, etc... we could clean up our logic somewhat.  It is equivalent to arrays of arrays.

    In a more concrete example, take this rule that flattens out an entity:

    the income = TemporalFromStartDate(the monthly incomes, the monthly income start date, the monthly income)

    If the monthly income is temporal, the net effect of OPA appears to be to flatten everything out.  That has unintended side effects, not the least of which is that the original entity values cannot be reproduced with rules.  If the entity can't be reproduced for applying logic against it, it follows that the temporal value can't have equivalent logic written against it!  Ouch.

    While it is true that many functions that extract values have no inverse, in this case there should be no reason an inverse function to create entities couldn't be implemented by OPA (another suggestion!  create the inverse functions for each of these temporal functions to fill values into entities after changing temporal values to be able to contain temporal values...)

    Net result?

    By making "today" temporal, I could write rules against determinations made at two different points in time, without the need for additional entities.

    Heads up, I also suggest putting natural language around all the temporal functions.  You describe the temporal functions with natural language, therefore the functions themselves should have a natural language equivalent.  The words "time inclusive" and "time exclusive" come to mind, but I wouldn't be picky.  The reason for natural language is to get as close to the source material for policy analysts review as I can get.

    Finally, the use of temporal values in this fashion is probably immature enough by customers that making this change would have minimal impact at this point in time.  If Oracle is to make this change, do it soon, before people rely on the current implementation of these existing functions.

     

     

     

     

    Comment

     

    • Davin Fifield

      Hi Paul,

      I'm not sure what you are suggesting "the income" should actually be in the case that "the monthly income" is temporal? The time dimension is represented linearly within the changepoints of the temporal value. Are you thinking that somehow the changepoints of the monthly income should be held separate from them. Or the result should populate "the income" attribute on a set of entity instances?

      Davin.

    • Paul Fowler

      Let me give examples!  Current and how I would propose it to be...

       

      the income = TemporalFromStartDate(the monthly incomesmonthly assessment datemonthly income)

      Example 1: (how it currently works)

      monthly assessment date = 2016-03-01; monthly income = {1000, 2000 from 2016-12-01, 3000 from 2017-01-01}

      monthly assessment date = 2016-04-01; monthly income = {4000, 5000 from 2016-12-01, 6000 from 2017-01-01}

      the income = {<Uncertain>, 1000 from 2016-03-01, 4000 from 2016-04-01, 5000 from 2016-12-01, 6000 from 2017-01-01}

      Notice a logical challenge with "the income" ?  I can't recreate the original monthly income value. (for instance, the 2000 is missing)

      Example 2: (also how it currently works)

      monthly assessment date = 2017-03-01; monthly income = {1000, 2000 from 2016-12-01, 3000 from 2017-01-01}

      monthly assessment date = 2017-04-01; monthly income = {4000, 5000 from 2016-12-01, 6000 from 2017-01-01}

      the income = {<Uncertain>, <Uncertain> from 2016-12-01, <Uncertain> from 2017-01-01, 3000 from 2017-03-01, 6000 from 2017-04-01}

      Heck, that doesn't even make any sense!  ...but that is currently (in May release) how it works.

      Proposal 1: (this is how I would like it to work)

      monthly assessment date = 2017-03-01; monthly income = {1000, 2000 from 2016-12-01, 3000 from 2017-01-01}

      monthly assessment date = 2017-04-01; monthly income = {4000, 5000 from 2016-12-01, 6000 from 2017-01-01}

      the income = {<Uncertain>, {1000, 2000 from 2016-12-01, 3000 from 2017-01-01} from 2017-03-01, {4000, 5000 from 2016-12-01, 6000 from 2017-01-01} from 2017-04-01}

      THAT makes sense.

      The income would be a temporal value of temporal values if "the monthly income" is temporal.  Under normal circumstances, that situation doesn't occur in my logic, but when policy mistakes (usually in rate tables) are made, I can run into that situation.  It would be easier to correct if I can make the whole policy model with evidence temporal.  However, making the whole policy model temporal doesn't work because the policy model already has temporal values in it.  Everything becomes flat and I can't distinguish past and present values...

      I can then run logic to see how the timeline varied over time which helps me identify past errors.  I am hoping to post an example soon.  Currently, I must use context entities to accomplish this same thing.

      I think Oracle is making a logic mistake by totally flattening out values instead of doing it one level at a time.  You can't recreate the original values.  I can't recreate the monthly income from the temporal income.

      Also, I should have separated it, but I would love natural language for temporal functions would be great.

       

       

       

    • Davin Fifield

      I think I see where you are going Paul, and I can safely say we don't have plans to make changes like this any time soon! Working with temporal reasoning already requires thinking in terms of an additional dimension flowing through data elements, and if those dimensions could be nested --- well, I can't imagine how we'd support debugging for example, in any simple way.

      Getting three different entries for Uncertain certainly seems odd, though. Will see if someone can help chase down what is happening there, since that definitely isn't the behavior I'd expect.

    • Davin Fifield

      Paul, thinking about this a bit more I'm still not sure what you want to do with the income attribute once you've got this temporal temporal value in it??

    • Paul Fowler

      In short, I make the WHOLE ruleset temporal based on today = the current day

         I makde "today" temporal.  Then I have special rules where the ruleset realizes it is temporal and performs logic. 

      What happens, in short, is that there are times when the temporal circumstance changes over time due to retroactive rule or data activity. 

      In English: Every time a view of a timeline of events changes, I need to compare the timelines together.  I then make decisions based on how timelines changed over time.

      For instance, pretend there is a question about whether a determination change is rule or data induced. I can more elegantly determine whether rule or data or both impacted determination with this feature. I currently suffice with a combination of entities and temporal attributes.  Again, it would only be easier and more elegant with just temporal logic.  

      Also, I can’t reproduce all the original data in an entity that I made temporal if that original data was temporal.  That restriction limits me to only using temporal variables where I am sure that I don’t need to compare changed timelines.  

      If this capability were to be included, I would suggest infinite temporal recursion for logical consistency.  A temporal, temporal, temporal, temporal currency attribute…

       

      But, if I had a choice between the consistency of being able to make everything temporal, and having natural language for temporal attributes, I pick the natural language capability.  I think I will add that as a different idea.

      Thank you.