w3c
metadata master reference policies
At scale (e.g. verifiable credentials over the European market for GDPR compliance), it is impractical to generate individual policies for millions of people as associated odrl:Set or odrl:Offer
Ideally (continuing the example) a VC asset class shape (not an instance!) would have a reference to a policy, this policy would dictate the types of shapes allowed (in the image - always an assignee is a Party / assigner a PartyCollection).
In the use case "Bob wants an insurance Policy", the agreement for GDPR will materialise (as Bob's VC will be of the "VC asset class shape") and the right relationships can be assigned at that point.
The elements in blue represent this new "reference", the rules don't hold assigners/assignees (or any other function) nor actual assets are related to a policy (it is classes-to-classes until the instantiation).
@joshcornejo: please add specific proposal for changes in the current "formal semantics spec" or specific examples for the "best practices" (in the form: "at the end of section X, add this paragraph, this figure and this Turtle spec"). If this is a long term suggestion, then I can label it as such... right?
This is most likely something for version 3.0:
The use case:
"The EU wants to attach policies to persons' verifiable credentials. For example, to make sure companies keep citizen's information within GDPR compliance requirements. Generating millions of offers in advance is impractical, and there is no way to materialise offers and trace them to a single origin offer for multiple different assigners."
As such, the policy is not created nor managed by the assigner; they are managed by an entity (the EU), and Agreements are only generated at the point in time when the three elements coincide in a governed situation "The insurer requesting a person's verifiable credential for a quote" (the assignee party: person, the asset: verifiable credential, the assigner: an insurer).
As per the diagram above, the proposed expansion (odrlex?) could look like this:
ex:TemplatedAsset a odrlex:MasterAsset ;
odrlex:hasMasterPolicy ex:TemplatedOffer.
ex:TemplatedOffer a odrlex:MasterOffer ;
odrlex:assigneeShape odrl:Party ;
odrlex:assignerShape odrl:PartyCollection ;
odrlex:permissions ex:Permission1 ;
odrlex:prohibitions ex:Prohibition1 ;
odrlex:obligations ex:Duty1.
// ex:Rules not included, but contain neither assigner nor assignee
Once someone needs an agreement, these templates materialise into an odrl:Offer:
ex:SomeAsset a odrl:Asset ;
odrlex:template ex:TemplatedAsset.
ex:Offer a odrl:Offer ;
odrlex:template ex:TemplatedOffer ;
odrl:permission ex:Permission1.
ex:Permission1 a odrl:Permission ;
odrl:target ex:SomeAsset ;
odrl:assigner ex:SomePartyCollection ;
odrl:assignee ex:SomeParty.
Reading this discussion, I must admit that I had interpreted the "inheritsFrom" https://www.w3.org/TR/odrl-model/#inheritance property to effectively cover this usecase. Can you clarify where it falls short? (or where I'm misunderstanding the meaning of the inheritsFrom objectproperty?)
Like in object-oriented programming, all rules inside a policy are passed to descendants, you have no way to select which rules from an ancestor you want to use (especially if the ancestor policy has many assets, and now you are fine-tuning to some subsets for your specific requirements, you are not interested in the assignee's down the supply chain to have access to those previous rules - or even assets -).