New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Temporal Aspects II #14
Comments
Do we care? I think these three use cases tell us that we do: Support audits Ensure compliance as policies update Enable forecasting |
So what kind of things change? Certainly pricing. Sometimes it's a price increase; sometimes data that was not fee-liable becomes so. But other things can change too. Where once you reported by Let's work with five test cases:
|
Let's start with a payment duty:
It already has several temporal aspects: pay $1,150 once ( We could simply update the But we would fail to satisfy the first and third: we have no view of the past or the future. All that is handled "off-stage". |
Instead we can add an
Before June, our Duty will look so:
After June, we will have two duties, one effective upto then end of 2020, and one effective in 2021:
Now we can satisfy all three use cases: we can look into the past and see what we were paying and we can look into the future and see what we will be paying. But things have become a little more complex: we had to edit And we still have some off-stage instructions: create a new duty and update the permission accordingly. We'll return to this issue later. But first, let's work through some more examples. |
The update to the reporting duty, where we change the unit of count, works in exactly the same way. We simply manage the change through effective dates and a new duty. |
The same considerations apply to updating
So before June, our
After June, we have two assets, one effective upto then end of 2020, and one effective in 2021:
|
Again, this approach satisfies our three use cases. Again, the update will "leak up" to the permission which will need to point to both But I'm less comfortable with the result. The identifier for the relevant asset changes over time. Yet that identifier may be held in a number of external systems, e.g. for reporting, cataloguing, and access control. The change in identifier may not come cheap. There is an alternative approach that maintains the integrity of the identifier. Rather than modeling an asset as an object with temporal properties, treat it as a temporal object: something that both continues and changes over time under the same identifier through versioning. |
What might this temporal object look like? Lets call it Prior to June:
After June:
The temporal asset is thin. Three things:
What have we lost?
|
I'm less concerned about the identifiers for |
Permission identifiers are more sensitive. Like asset identifiers, I suspect that will likely be shared with external systems for reporting, cataloguing, and access control purposes. Changing them may be non-trivial. But let's walk through the steps again:
So before June our permission looks so:
To take account of the notification, we can put effective dates on There: we've got the identifier change again, |
We can avoid the identity change if we term permissions into temporal objects like we did with assets. Let's call out temporal permission Prior to June:
After June:
Before and after June, our external systems point to |
Exactly the same story holds when adding a new asset to a permission. |
In our work at Refinitiv we do have requirements for management for all three of the temporal aspects discussed here. My vote would be to include these in the standard in some form for at least the following: • Effective dates for permissions, prohibitions and duties |
I see here two lines of work to be tackled:
|
Policies change. Updates are published. How do we ensure that parties in the data supply chain share the same view of the past, the present, and the future?
The text was updated successfully, but these errors were encountered: