August 5th, 2020: Topics for Discussion
Agenda:
- Finalize definitions of Notify and Report
- Begin discussion of Temporal Aspects of Policy Lifecycle
Duties: Notify and Report
Notify: The debtor makes the creditor aware of a relevant change in the state of the world (defined by the action scope) usually on a one-off basis.
Report: The debtor provides a report to the creditor on a relevant state of the world (defined by the action scope) usually on a regular basis.
See the full definitions: New Terms to Vote On
“Usually on a one-off basis:” Is frequency the right differentiator between these Notify and Report?
Possibilitites:
- Scheduled (Report) vs. Unscheduled (Notify)
- Structured (Report) vs. Unstructured (Notify)
- Has Unit of Count (Report) vs. No Unit of Count (Notify)
- “Multi-line” (Report) vs. “Single-Line” (Notify)
- Others?
- Some combination of the above?
Time to Vote?
Did we agree on how to define Notify and Report? If so, let’s make it official: New Terms to Vote On
Temporal Aspects of Policy Lifecycle
In the real world, the terms that govern a particular asset may change over time, sometimes as specified by a new contract, other times as specified in policy documents referred to by a contract.
Read more: Temporal aspects issue thread
Is it important to support temporal aspects in our standard? If so, why?
-
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.
Questions for discussion:
- Any other reasons to support time-based changes?
- Can we imagine a digital rights specification that doesn’t support time-based changes? Would it still be at all useful?
What kinds of things can change over time? Some examples:
- A change in a pricing Duty - price goes up
- A change in a reporting Duty - from User ID to Device ID
- A change in the composition of an Asset - greater book depth
- A change in the definition of an Action - broadening the action scope to allow derivations for pricing options as well as warrants
- A change in the definition of a Permission - removing the condition that the consumer’s access control system be deployed by a vendor
- A change in the definition of a Permission - adding a new asset
How do contracts govern changes over time?
- The original contract specifies a time period for a particular set of terms.
- The original contract is replaced by a new contract (versioning).
- The original contract refers to an outside document that is itself versioned.
How are these represented in our digital contracts? One possibility: Effective Dates
This example requires a “price change notification.” What form might this notification take?
Are there other ways to represent changes?
Other things to consider
- Historical data products themselves often have their own temporal aspect. How does this relate to the temporal aspect as definited in a contract?
- How do historical products then differ from streaming products in this regard?