Expressing preferred policies or templates

[csarven]

Use case:

User wants to check whether the storage's policies are compatible with their own preferred policies. If there are any discrepancies, the user should be warned and given a chance to make a decision about available options.

Does ODRL provide a solution that meets the requirements of this use case?

An implementation:

The brief screencast in solid/specification#355 (comment) demonstrates an application that is aware of the storage's offer with a possible permission of action to sell assets stored in that location and selling happens to be a prohibited action by the user. The application brings the discrepancy to user's attention.

Below example policies are used by the storage (offer/permission) and the user's profile document (agreement/prohibition). I understand that the modeling of the preferred policy may be wrong or not even possible. Hence, I'd like to know if this can be accomplished with the current state of ODRL Information Model and/or possible minor extensions to express "preference" (or a template of sorts). If the expression of preference should be claimed in an external namespace, that's completely fine. Just looking for guidance.

Example (snippet) storage's policy:

</>
  odrl:hasPolicy <#policy> .

<#policy>
  a odrl:Policy, odrl:Offer ;
  odrl:permission :permission ;
  odrl:target <https://example.org/> .

:permission
  a odrl:Permission ;
  odrl:action odrl:sell ;
  odrl:assigner <https://example.org/profile#storage-org> .

Example (snippet) user's policy:

<https://csarven.ca/#i>
  solid:preferredPolicy :preferred-policy .

:preferred-policy
  a odrl:Policy, odrl:Agreement ;
  odrl:prohibition :preferred-policy-prohibition .

:preferred-policy-prohibition
  a odrl:Prohibition ;
  odrl:action odrl:sell ;
  odrl:assigner <https://csarven.ca/#i> .
  odrl:assignee foaf:Agent ;

For the time being, there is not much to the semantics of solid:preferredPolicy beyond simply referring to a "preferred policy" (i.e., an odrl:Policy) - again, it was only to exemplify the need. Perhaps odrl:hasPolicy could've been re-used, I don't know.

[coolharsh55]

Hi. I'm not sure which is the most appropriate issue to discuss preference of policies, but I think it will appeal to ODRL's scope the most (so this is after my comment in w3c/dpv#36).

In general, preference of a policy could mean that the policy should be applied either (1) first or before others; or (2) exclusively instead of others. If I'm correct (which has no guarantee in general), then the notion of policies in ODRL requires all applicable policies to be satisfied, or if this is not the case - then to explicitly denote (within a policy) which policy must take precedence or preference over another and in what manner - basically playing with if-then-else with policies and consequences and duties.

To given an example, consider P(a) and P(b) to be two preferred policies. In this case, it is unclear how the preference should be resolved: does this mean both a and b should be applied - and if so in what order? IF instead, preference only means that a policy should be applicable or active - then these are much better adjectives to use than 'preference'.

Separate from the above is the notion of degree or rank of preferences. This follows from (as an example) how CSS rules are determined to be applicable and applied. Within CSS, the resolution of rules has different scopes - global, element ID and class, inline, etc. - with fixed determination of how they will behave. So even if two elements have conflicting CSS rules (e.g. one sets color to red and the other to blue) - the CSS spec makes it clear how they will be applied. I call this degree or ranking of rules in a context. In Solid, such ranking is possible, as we (with Victor, and led by Beatriz) discussed in the paper ODRL Profile for Expressing Consent through Granular Access Control Policies in Solid, whereby local/narrower policies take preference over global/broader ones. So preference in this case also has another meaning - that of contextual ranking between policies.

[benedictws]

Hi Sarven,

I think we are dealing with an analogous use case in market data.

A trading desk in a bank may want to create an index (think the Nasdaq-100 Index) from some underlying pricing data and share it with their customers. Are they allowed to do this?

We capture the trading desk's desire as a Request Policy. We then check against all the banks Agreement Policies to see if they support the Request. More formally, we check for compliance using a subsumption check - are the Permissions in the Request Policy subsumed by Permissions in the Agreement Policies.

If so, we can tell the trading desk which permissions to use to create and share their index.

If not, then data suppliers can provide Offer Policies that are compliant with the Request. It's then up to the bank to decide whether to convert an Offer into an Agreement Policy and thus satisfy their trading desk's Request.

Your use case seems similar. A user publishes a Request Policy to the storage. If the Agreement Policy published by the store is compliant with the Request, then we're on the golden path. If not, the storage can publish an Offer Policy which the user can decide to accept (and create an Agreement policy) or not.

The storage can only store and/or process the user's data on the basis of an Agreement.

Like Harshvardhan, I'm skeptical about introducing the notion of preference into ODRL. I'm not sure we need it. But I do think that ODRL should formally define a compliance relationship between policies!

[coolharsh55]

To add to Benedict's nicely elaborated use of different ODRL policies, the odrl:Offer may be contextual i.e. only limited to that particular entity or odrl:Request. To express something akin to a general policy (which may be the basis for what offer is generated), there is odrl:Privacy but it requires both assigner (user) and assignee, and some additional details. So if you only want to capture user preferences, you can create another subclass of odrl:Policy called PreferredPolicy or PrivacyPreference or whatever is appropriate in that context which is used by users to create policies without a specific request in mind, i.e. just declare preferences. Maybe this is closer to your question and I misunderstood it in my earlier response.

[riannella]

I think the approach by @coolharsh55 to define a new Policy Type is the best option

[besteves4]

In addition to a new policy type for preferences, it would also be nice to have a property that associates users with policies (similar to the example that @csarven mentioned above: <https://csarven.ca/#i> solid:preferredPolicy :preferred-policy .).
Or relax odrl:hasPolicy domain to also include odrl:Party.
Beyond preferences, this property could also be used to associate users with data requests, i.e, odrl:Request, a feature that would be nice to have at least in data spaces and decentralised systems like Solid for users to directly request data without using any intermediary app or service.
Maybe this can be added in a future ODRL 3.0.

[coolharsh55]

DPV contains hasPolicy with an open domain - so it can be used to point to any policies. For backwards compatibility ODRL 3.0 can declare a new relation e.g. issuePolicy to indicate that a Party issues a Policy. This phrasing is consistent with existing statements, e.g. see Example 30 https://www.w3.org/TR/odrl-model/#metadata