w3c
Expressing preferred policies or templates
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 https://github.com/solid/specification/issues/355#issuecomment-1140508784 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.
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.
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!
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.
I think the approach by @coolharsh55 to define a new Policy Type is the best option
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.
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
Is the proposed "Preference" policy class the same as "Request": https://www.w3.org/TR/odrl-vocab/#term-Request
@riannella If necessary, I think it would be better modelled as the Offer component as in I'm offering my preferences rather than requesting them?
I don't know (I wouldn't be against it though). The original ask from Sarven is about which policy is preferred over others, rather than a preference itself.
To clarify, my original concern was not about precedence between policies but about expressing and discovering contextual policies. The goal is for applications to discover and compare a user's "preferred" (for lack of a better term) or ideal policy against encountered ones.
In dokieli, this was implemented by letting the application discover the user's independently published/issued policy via a property (re screencast). The rest of the implementation works with the ODRL policy as is.
If possible, relaxing odrl:hasPolicy's domain to include odrl:Party might suffice. Alternatively, a new property like odrl:issuePolicy (where a Party issues a Policy) could work too.
By preference, I did not mean precedence or that only one policy should be used. After all, it would be useful to indicate the purpose or context of a policy (possibly beyond what ODRL can help to express, and left as a separate exercise) so that it can be applied appropriately.
I would like client-side applications (or user agents) to inspect and negotiate policies on my behalf, ensuring it fulfills its duties to me (related: duties of a user agent) . As a user, I might apply one policy for storing my annotations at third-party storage and another for limiting disclosure of personally identifiable information in public discussions.
Thanks Sarven. To clarify, by "preference" I meant what you explained - that a specific policy is preferred for a given context. In ODRL, I think currently policies can only be attached to "Assets" because policies are only defined as governance over resources. If you express your data as an asset and have multiple policies associated with it, the question then becomes how to select the correct one based on "context". The same argument also works if you express your storage as an asset. I don't think ODRL provides a way to answer this question other than having all policies apply simultaneously so that the overall permission/prohibition is derived from a combined assessment.
Perhaps one way is to create an asset as a representation of the use-case and then associate a policy with it. E.g. using DPV:
ex:SarvenTPStorage a dpv:Process ;
dpv:hasPersonalData ex:Annotation ;
dpv:hasStorageCondition [
a dpv:StorageCondition ;
dpv:isImplementedByEntity dpv:ThirdParty ;
] ;
odrl:hasPolicy ex:PolicyWithRules .
Using this, you check whether the Process is relevant, and then use the associated policy. Having the domain of odrl:hasPolicy include odrl:Party doesn't fully solve the problem, because the same issue could also arise when you want to associate policies with a specific service (or process as above), or condition (like day of the week).
The other "ODRL way" is to use constraints to restrict the policy use to specific contexts, e.g. in below (I think) the policy is only applicable when the constraints are satisfied.
ex:SomeRule odrl:constraint [
odrl:leftOperand dpv:hasPersonalData ;
odrl:operator odrl:isA ;
odrl:rightOperand ex:Annotation ;
], [
odrl:leftOperand dpv:hasStorageCondition ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:StorageCondition ;
odrl:constraint [
odrl:leftOperand dpv:isImplementedByEntity ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ThirdParty ;
] ;
] .
@csarven Ok...so the current "issuedPolicy": https://w3c.github.io/odrl/community-vocab/#issued-policy Should really be "preferredPolicy" ?
@riannella Oh cool! I didn't realise issuedPolicy was introduced to community-vocab. I believe that would somewhat resolve this issue but I was hoping that it would be part of core ODRL ns since Party-issuedPolicy-Policy is useful to anyone as core ODRL (and not even domain specific). Is there a process already in place that transitions/graduates some of community-vocabs to ODRL ns or are they intended to live in community-vocabs indefinitely? (Needless to say, I'd prefer to not introduce a yet another ns just to refer to one property.)
Our plan to use the same odrl namespace URI for the community terms as well.