Temporal Aspects II

[benedictws]

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?

[benedictws]

Do we care? I think these three use cases tell us that we do:

Support audits The model must support an account of history that both the data Provider and the data Consumer can agree upon through the audit process.

Ensure compliance as policies update The model must continue to support provably-correct compliance decisions in the present as policies change and update over time.

Enable forecasting The model must support an account of the future so actors in the supply chain can predict their capabilities and costs as and when updates are published.

[benedictws]

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 User ID, now you must report by Device ID. The book depth provided is increased. And you can now share your internal derivations with your customers.

Let's work with five test cases:

1. A change in a pricing Duty - price goes up
2. A change in a reporting Duty - from User ID to Device ID
3. A change in the composition of an Asset - greater book depth
4. A change in the definition of an Action - broadening the action scope to allow derivations for pricing options as well as warrants
5. A change in the definition of a Permission - removing the condition that the consumer's access control system be deployed by a vendor
6. A change in the definition of a Permission - adding a new asset

[benedictws]

Let's start with a payment duty:

:D1                 a                   odrl:Duty ;
                    nl:creditor         <https://permid.org/1-4295899615> ; # CME
                    nl:hasDeadlineDelta [   a                   time:ProperInterval ;
                                            md:timeReference    time:Instant , md:TimeOfInvoicing ;
                                            time:hasXSDDuration "P30D"^^xsd:duration
                                        ] ;
                    odrl:timeInterval   [   a                   time:ProperInterval ;
                                            time:hasXSDDuration "P1M"^^xsd:duration 
                                        ] ;
                    odrl:action         [   a                   odrl:Compensate ;
                                            odrl:unitOfCount    md:Application ;
                                            odrl:payAmount      "1150.00"^^xsd:float ;
                                            odrl:unit           <https://www.wikidata.org/wiki/Q4917> ; # US dollar
                                            odrl:count          "1"^^xsd:int
                                        ] .

It already has several temporal aspects: pay $1,150 once (odrl:count), monthly (odrl:timeInterval), on 30 day's notice (nl:hasDeadlineDelta). But what if the price went up to $1,250?

We could simply update the odrl:payAmount at the right time to the new price and have done with it. We'd pay the right amount on time, and so would satisfy our second use case - ensuring compliance as policies update.

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".

[benedictws]

Instead we can add an Effective Date - i.e. the time interval in which this duty is effective. Let's take this in a set of steps:

1. The price of $1,150 is effective from the beginning of this year
2. We receive a price-change notification in June that price will go up to $1,250 from the beginning of next year

Before June, our Duty will look so:

:D1                 a                   odrl:Duty ;
                    nl:creditor         ...
                    md:effectiveDate    [   a             time:ProperInterval ;
                                            time:after    "2020-01-01T00:00:00Z"^^xsd:dateTime 
                                        ] ;
                    nl:hasDeadlineDelta ...
                    odrl:timeInterval   ...
                    odrl:action         ...

After June, we will have two duties, one effective upto then end of 2020, and one effective in 2021:

:D1                 a                   odrl:Duty ;
                    nl:creditor         ...
                    md:effectiveDate    [   a             time:ProperInterval ;
                                            time:after    "2020-01-01T00:00:00Z"^^xsd:dateTime ;
                                            time:before   "2021-01-01T00:00:00Z"^^xsd:dateTime
                                        ] ;
                    nl:hasDeadlineDelta ...
                    odrl:timeInterval   ...
                    odrl:action         ...

:D2                 a                   odrl:Duty ;
                    nl:creditor         ...
                    md:effectiveDate    [   a             time:ProperInterval ;
                                            time:after    "2021-01-01T00:00:00Z"^^xsd:dateTime 
                                        ] ;
                    nl:hasDeadlineDelta ...
                    odrl:timeInterval   ...
                    odrl:action         ...

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 :D1 when we got the notification to specify when it ceased to be effective and we added a new duty :D2. That means we need to update the permission too. Our update is "leaking up". We have more actors "on stage" than perhaps we'd imagined.

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.

[benedictws]

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.

[benedictws]

The same considerations apply to updating Assets. Let's check the stages:

1. The asset presently offers a book depth of 10
2. We receive a notification in June that the book depth will increase to 12 from the beginning of 2021

So before June, our asset looks so:

:A1     rdf:type                    odrl:Asset ;
        md:resource                 :S1 ;
        md:timelinessOfDelivery     ...
        md:depthOfMarket            [  a                    md:Level2 ;
                                       md:positionFrom      1 ;
                                       md:positionTo        10 ;
                                    ] ;
        md:contentNature            ...

After June, we have two assets, one effective upto then end of 2020, and one effective in 2021:

:A1     rdf:type                    odrl:Asset ;
        md:effectiveDate            [   a             time:ProperInterval ;
                                        time:before   "2021-01-01T00:00:00Z"^^xsd:dateTime
                                    ] ;
        md:resource                 :S1 ;
        md:timelinessOfDelivery     ...
        md:depthOfMarket            [  a                    md:Level2 ;
                                       md:positionFrom      1 ;
                                       md:positionTo        10 ;
                                    ] ;
        md:contentNature            ...

:A2     rdf:type                    odrl:Asset ;
        md:effectiveDate            [   a             time:ProperInterval ;
                                        time:after    "2021-01-01T00:00:00Z"^^xsd:dateTime 
                                    ] ;
        md:resource                 :S1 ;
        md:timelinessOfDelivery     ...
        md:depthOfMarket            [  a                    md:Level2 ;
                                       md:positionFrom      1 ;
                                       md:positionTo        12 ;
                                    ] ;
        md:contentNature            ...

[benedictws]

Again, this approach satisfies our three use cases. Again, the update will "leak up" to the permission which will need to point to both :A1 and :A2.

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.

[benedictws]

What might this temporal object look like? Lets call it :At1.

Prior to June:

:At1    rdf:type                    md:TemporalAsset ;
        md:version                  :A1 .

After June:

:At1    rdf:type                    md:TemporalAsset ;
        md:version                  :A1 , :A2 .

The temporal asset is thin. :At1 simply points to the assets :A1, and, after June, :A2. So what have we gained?

Three things:

1. The identifier for the (temporal) asset :At1 does not change as it gets versioned through time.
2. We don't need to update the permissions as the asset updates. It always points to :At1. The change does not "leak up".
3. Managing change over time is now explicitly handled by the model.

What have we lost?

1. Perhaps some simplicity? We've had to add a new concept to the model: temporal objects.
2. We've taken a step away from standard ODRL, which is a non-temporal model.

[benedictws]

I'm less concerned about the identifiers for actions - it's the content of the action that counts, and we can manage that across time using effective dates. (Of course, we'd have to update the permission.)

[benedictws]

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:

1. The permission presently requires the access control system to be deployed by the vendor (and to operate on the basis of a closed user-group).
2. We receive a notification in June that the requirement for deployed access control will be removed in the new year.

So before June our permission looks so:

:P1     a                   odrl:Permission ;
        dc:desciption       "Automated trading as principle in a managed environment"^^xsd:string ;
        odrl:target         :A1 ;
        odrl:action         [    a                 md:TradeAutomatically ;
                                 md:actionScope    md:Principle 
                            ] ;
        md:controls         md:Closed , md:Deployed .

To take account of the notification, we can put effective dates on :P1(ending at the end of 2020) and create a new permission :P2 in which we remove the md:Deployed constraint, and set an effective date starting from the beginning of 2021. Oh, and update any relevant policies.

There: we've got the identifier change again, :P2. That might leave us with a lot of external systems to update.

[benedictws]

We can avoid the identity change if we term permissions into temporal objects like we did with assets. Let's call out temporal permission :Pt1. So:

Prior to June:

:Pt1    rdf:type                    md:TemporalPermission ;
        md:version                  :P1 .

After June:

:Pt1    rdf:type                    md:TemporalPermission ;
        md:version                  :P1 , :P2 .

Before and after June, our external systems point to :Pt1, so do our policies. Nothing to update here!

[benedictws]

Exactly the same story holds when adding a new asset to a permission.

[primell]

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 • Stable identifiers for permissions and prohibitions • Versioning of permissions and prohibitions

[vroddon]

I see here two lines of work to be tackled:

• Definition of the vocabulary elements to be defined
• Definition of the compliance rules to be applied They are intimately related and the second must drive the first. Some Hope to contribute to this with small demos, even if after some weeks....