Roadmap brainstorm
Rectify refinement class/property to AssetCollections and PartyCollections - 64
Note: Not sure if Action needs to be rectified or if it is OK since defined within ODRL?
The original intent of the refinements over the ODRL collections was to provide a mechanism for funnelling/filtering elements from the collection for the rule application. In practice, as a builder of policies, there are situations where a refinement should be applied to an item in a collection (i.e. a simple example is "refinement of a party when in a specific location"), this also makes sense if later "Attribute-based Constraints" (requirement below) is adopted.
Supply-chain rule reference 55
Use case: As a policy builder, I want to be able to "collate" an agreement into my policy and explicitly call out the rules I find relevant to the offer I am building.
The odrl:inheritFrom concept is useful when a party builds internal offers. When it is expanded to a supply chain of external parties, the originator (that is a supplier to a party) of a single Agreement, the Agreement could have a large bundle of permissions, prohibitions and duties with a surface of many assets. In the cases where there is allowance to convert and offer further down the supply chain those assets, there is no simple way to filter the rules whilst keeping track or reference to them. Further, no simple construct provides formal "policy linkage" across the supply chain other than the asset referencing via odrl:hasPolicy.
Policy templates - 65
Use case: As a policy builder, I want to create policy templates that allow for the creation of one offer that can be reused millions of times (as in the plan by the EU for verifiable credentials) and is fully resolved when the agreement is generated.
As explained in the issue, at scale (e.g., verifiable credentials over the European market for GDPR compliance), generating individual policies for millions of people is impractical as associated odrl:Set or odrl:Offer.
Use case: As a policy builder, I want to restrict the types of parties that can be recipients of my Offers.
Although this is currently easily achieved with a profile, there should be a single and formal way (based on a centralised taxonomy) that create sets of markets or verticals where an Offer is valid or not. For example:
"Prohibits the use by any company in Artificial Intelligence training, but allows be used for any Insurer"
Where "Artificial Intelligence" and "Insurer" are instances part of this taxonomy, and should be formally managed by the W3C ODRL group.
Use case: As a policy builder, when I have many possible Assigner instances as outputs associated with a policy, there is no standard way to have a reference to 'self' that is resolved when an agreement is generated.
In a conglomerate that maps to a PartyCollection, there is no simple way to address generally any of the party's part of the conglomerate to be capable of "reusing" Offers that have refinements for the Assigner, which would become instantiated (e.g. PartyX) at the moment of the creation of an Agreement.
Use case: As a builder of policies, I want to be able to reference properties within an asset or party to use them as odrl:LeftOperand
The approach for asset (or collection) is quite straightforward with having a keyword such as target and using a syntax similar to that of an object-oriented language for referencing properties within a class:
target.property
It is left to a validator and evaluator to assess if the property is part of the asset at the appropriate time.
For the party (or collection), it is slightly more complicated as it will depend on the desired function's property to target, e.g.:
assigner.property
assignee.property
trackingParty.property
Use case: As a policy builder, I want to create more sophisticated refinements with composite logical operands.
Logical constraints at the moment can only use one logical operand. Constructs such as:
"Allow at the office when in France or the UK, anywhere in Germany"
OR spatial eq DEU
(AND
(OR spatial eq GBR
spatial eq FRA)
ex:location eq Office) # <-- an extended odrl:LeftOperand
Currently, this would require several rules to represent appropriately. As an added outcome, it would enable easy construction of extensions for Attributed-Based Encryption.