Temporal Aspects of Policy Management

[benedictws]

Contracts are renegotiated; policies are updated. The rules governing data change over time. How do we know which rules apply over what time periods?

We want to be able to answer questions like:

• What rules are applicable today?
• Which were yesterday?
• What rules apply tomorrow?

Seems to me we have two cases to cover:

1. Changes are retrospective. The data is controlled by a contract that points to a set of policies. As the policies update so do the rules controlling the data supplied under the contract. All data (including past data) is controlled by the most recent policies.
2. Changes are not retrospective. Old data continues to be controlled by the old contract. Any alterations apply only to new data.

I see a lot of (1), but how often do we meet (2)?

Do we have any other cases to cover?

[benedictws]

During our discussions about Duties, we introduced the concept of Time Interval to control their applicability. We can extend the concept to the other rules (aka Permissions and Prohibitions) to help answer the questions above. Satisfaction of the time interval is a necessary (though not always sufficient) condition for a rule's validity.

We can define time intervals with two instants: after and before. Between these instants the time interval is satisfied. If no before instant is specified (i.e. no upper bound) the time interval is assumed to hold in perpetuity.

[benedictws]

So what would a permission look like with a time interval controlling its validity?

Here's one valid for the month of June this year:

:P1     a                   odrl:Permission ;
        odrl:timeInterval   [   a             time:ProperInterval ;
                                time:after    "2020-06-01T00:00:00Z"^^xsd:dateTime ;
                            time:before   "2020-06-30T24:00:00Z"^^xsd:dateTime
                            ] .

And here's one that has been valid since the 1st of June and continues to be so into the foreseeable future:

:P2     a                   odrl:Permission ;
        odrl:timeInterval   [   a             time:ProperInterval ;
                                time:after    "2020-06-01T00:00:00Z"^^xsd:dateTime ;
                            ] .

[benedictws]

We haven't yet met the challenge we set at the top of this issue. We can't distinguish between changes that are retrospective and those that are not. This feels like we need to track two timelines:

1. valid time - time (and history) as we see it today
2. transaction time - time (and history) as we saw it at a particular moment in the past

(I've borrowed the terms from bi-temporal modelling)

Where changes are retrospective, we can rely on valid time. What counts is today's view of history.

But where changes are not retrospective, we need to see how things looked in the past and so use transaction time.

Now, though the concepts are complex, we can easily make the distinction by "typing" the interval. If we specify the time interval as a valid-time interval then we are saying that it's satisfaction depends on today's date. If we specify the time interval as a transaction-time interval then we are saying that it's satisfaction depends on the date the data was received.

At least the specification is easy to do. For valid time:

:P3     a                   odrl:Permission ;
        odrl:timeInterval   [   a             md:ValidTimeInterval, time:ProperInterval ;
                                time:after    "2020-06-01T00:00:00Z"^^xsd:dateTime ;
                            time:before   "2020-06-30T24:00:00Z"^^xsd:dateTime
                            ] .

And for transaction time:

:P4     a                   odrl:Permission ;
        odrl:timeInterval   [   a             md:TransactionTimeInterval, time:ProperInterval ;
                                time:after    "2020-06-01T00:00:00Z"^^xsd:dateTime ;
                            time:before   "2020-06-30T24:00:00Z"^^xsd:dateTime
                            ] .

[markabird]

I'm not sure that asking if a change is retrospective or not is the right question to ask. Rather, I think it's a question of scope. Does a contract refer to something outside of itself that gives definitions to terms by which the licensee must abide, or is the contract self-defining?

The most common example is pricing, I think. For this conversation, we can think of pricing models as breaking out into three categories:

1. The Originator has a stand-alone price schedule to which all contracts refer. If a particular list price changes at a point in time, the new price is effective to the licensee immediately, because their contract does not in itself specify any pricing information but rather refers to the schedule.

2. The Originator has a price schedule, and contracts executed at a point in time are informed by the price schedule at that point in time. But, the contracts have the prices themselves specifically defined (rather than referred to) and include their own term. In this case, if the Originator's list price changes, what the licensee is paying doesn't change until the end of their term.

3. The Originator has no published stand-alone price schedule, all contracts have prices defined ad-hoc and therefore fully include pricing details without referring to anything external.

We have Originators using DataBP for all three use cases.

[markabird]

I'd add that while my example above uses payment as an example, there's no reason why it couldn't and doesn't apply to any particular term or set of terms. Sometimes a part of a contract stands alone, and other times it refers to a document outside of itself.

When a contract refers to an external document, it's not that when the external document is changed (or maybe versioned is the better word) that the past is changed. Rather, it's that from the point in time of the new version forward that new terms apply from what they were at the signing of the original contract.

[markabird]

I'm not sure that asking if a change is retrospective or not is the right question to ask.

Maybe I shouldn't have said that it wasn't the right question to ask, thinking about it more I see your point about old terms referring to old data sets, with new data sets being governed by new terms. I probably should have said "there's another interesting aspect of this to discuss." :-)

[jo-rabin-db]

A somewhat pedantic point, perhaps: In the discussion about before and after, it would be useful to know what is meant more precisely. For example, I would usually encode before as meaning any time strictly less than the time specified, and after as meaning equal to or greater than ...

[jo-rabin-db]

pls note request for clarification inline above: https://github.com/w3c/market-data-odrl-profile/issues/12#issuecomment-661020960

[benedictws]

I'm using the OWL Time Ontology, @jo-rabin-db, to manage as many references to time as possible. It implements Allen's interval algebra in a W3C standard. The definitions of before and after come from there.

[benedictws]

Time is such a headache!

All the cases you list, @markabird, are, I think, cases of valid time. We can satisfy both the second and the third with valid-time time intervals as described above. But the first takes us into deep waters I had hoped to avoid. The policy, or at least the payment duty, is changing over time.

But it's a common use case!

Let's stay with the payment example - although, as you suggest, anything in a policy might update. Three ways of handling a price change come to mind:

1. 'Edit-in-place' - simply update the duty. The model itself represents only today, and we capture all temporal aspects in some kind of audit log.
2. Update the permission - add a new duty that reflects the new price, and use time intervals to specify which duty is applicable at any given moment in time.
3. Turn all rules into temporal objects and version them through time.

[durenma]

My feedback would be:

• Commercial changes, or changes in term that would have a financial impact, would need to take effect from a specific point in time. An exchange could / should not make a change in unit of count, as an example, that would apply retrospectively. During an audit spanning previous and new contract provisions, the review would need to delineate the period and requirements and account for these separately.
• I have seen providers / originators look to level set disparate versions of terms by producing a new standard which supersedes any existing variations. This action could apply to both legal and commercial terms, however would not be retrospective.

[benedictws]

Thanks for the comments @markabird, @jo-rabin-db, @durenma

I think the way to progress this is with some clearer use cases and test cases. Let's do that here: #14