This section describes the process followed by goodFlows to resolve conflicts between the processing intentions of a resource consumer on a third-party dataset, as reflected by a Data Processing Workflow, and the dataset provider’s policies regarding the use of the data, specified in ODRL. Figure~\ref{fig:conflict-resolution-overview} provides an overview of the process.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=0.75\linewidth]{figs/OverviewOfTheConflictResolutionProcess}
	\caption{Overview of the conflict resolution process}
	\label{fig:conflict-resolution-overview}
\end{figure}


The first step is the generation of all intentions that are expressed for the dataset in question through the DPW. To this end, all tasks that consume the dataset are identified, and an Intention object is created based on every execution profile.

An example of an Intention object is shown in Figure~\ref{fig:intention-object}, corresponding to the task of \texttt{PerformStatisticalAnalysis} contained in the workflow that is defined by the data consumer in Figure~\ref{fig:process-modeller}. According to Figure~\ref{fig:intention-object}, an entity of type \texttt{NonGovernmentalOrganisation} is intended to perform statistical analysis on a \texttt{TrainingMeasurements} dataset for the purpose of \texttt{CommercialResearch}.

\begin{figure}[!htb]
	\centering
	\includegraphics[width=0.5\linewidth]{figs/intention-object}
	\caption{Intention object (excerpt)}
	\label{fig:intention-object}
\end{figure}

The intention objects are passed to the PDP, along with the data provider’s policy, specified in ODRL; the associated usage constraints are translated into the goodFlows access and usage control language and imported into a dedicated Policy Model ontology, so as intentions to be evaluated and possibly modified against this ruleset.

For example, Figure~\ref{fig:ODRL-policy} presents an ODRL policy that is putting usage constraints on a dataset of type \texttt{TrainingMeasurements}; the policy is defined by the data holder for accompanying the dataset when provided to a consumer, and contains two rules:
\begin{itemize}
	\item A \texttt{Permission} (line 14) allowing a \texttt{NonGovernmentalOrganisation} with more than 200 employees, for the purpose of \texttt{ResearchAndDevelopment}, to partially \texttt{Analyse} \texttt{TrainingMeasurements}, by using only \texttt{BurntCalories}, \texttt{ExerciseType} and \texttt{HeartRateRange} contained therein, provided that the associated measurements will be first anonymised (\texttt{Anonymise} duty) and that the processing will take place before 31/12/2025. 
	\item A \texttt{Prohibition} (line 71) prohibiting a \texttt{NonGovernmentalOrganisation} of any size to \texttt{Analyse} \texttt{TrainingMeasurements} corresponding to training sessions performed after 1/1/2025 for the purpose of \texttt{CommercialResearch}.
\end{itemize}
In this case the permission is more general applying for the high-level \texttt{ResearchAndDevelopment} purpose, while the prohibition constitutes an exception to the permission for the more specific purpose \texttt{CommercialResearch} (\texttt{isA} \texttt{ResearchAndDevelopment}).

\begin{figure}[!htb]
	\centering
	\includegraphics[width=\linewidth]{figs/ODRL-policy}
	\caption{ODRL policy associated with \texttt{TrainingMeasurements} dataset}
	\label{fig:ODRL-policy}
\end{figure}


Thereupon, for each rule defined by the provider, the corresponding meta-rules are extracted, as described in section~\ref{sec:policy-model}.

Upon the extraction of the meta-rules, the ground for evaluating intentions against them is set. First, for each intention, the applicable rules, i.e., permissions, prohibitions and obligations affecting the intention, are identified; if no permission is found, the intention cannot be validated (Deny unless permitted).

Assuming at least one permission has been identified (as in Figure~\ref{fig:ODRL-policy}), conflicting rules are identified, for eliminating overridden rules. This is challenging in the presence of both positive and negative privileges, concept hierarchies and comparison of heterogeneous entities (entities of the action in question, as well as entities associated with pre- and post- actions of rules) with complex constraints that need to be evaluated. The resolution procedure follows several widely adopted patterns (~\cite{ferraiolo2001}\cite{bertino1999}\cite{park2004}\cite{liu2021}\cite{shu2009}):
\begin{itemize}
	\item Specific rules override general ones (lex specialis principle): Explicitly defined rules prevail over meta-rules derived by propagation of rules across hierarchies. Moreover, more strict rules (in terms of defined constraints) prevail; for instance, a rule allowing the publishing of training measurements only in EU will prevail over a generic permission for publishing of training measurements without any constraint.
	\item Deny overrides: if both permissions and prohibitions exist for the same action, prohibitions prevail.
	\item Inclusion-Exclusion principle for comparing all kind of constraints, pre-actions and contextual conditions; if an action is both permitted and prohibited under different conditions, the system determines whether those conditions overlap.
\end{itemize}
It is noted that the engine also supports the lex posterior principle, i.e., that most recent rule prevails; however, this pattern is only applicable when an intention is evaluated against internal policies, as in goodFlows the policy author may define a new rule in order to possibly override a previous one or define an exception to a rule.

After the elimination of conflicting rules, the applicable rules are merged, essentially combined into a unified rule that satisfies the intent of all applicable policies, by: 
\begin{itemize}
	\item Merging positive and negative authorisations: a prohibition for executing an action during the night combined with a permission for executing the said action without any temporal conditions set will result to a permission only for daytime. 
	\item Merging constraints and contextual conditions under which results are valid.
	\item Merging required or forbidden action structures complementing the execution of the requested action.
\end{itemize}
An additional merge operation that takes place concerns merging the constraints of rule entities with those of intentions, thereby ensuring that constraints defined as part of the intention are taken into account in the compliant intention. This includes comparison of intention and rule constraints, leveraging the Inclusion-Exclusion principle. The lex superior principle applies in this case, i.e., access and usage rules prevail over intentions.
It should be noted that in case no valid intention is found, the same procedure is performed for each of the parts of the given resource; possible valid intentions for these parts prescribe projection of the given resource.

This way, an intention may eventually be: 
\begin{itemize}
	\item allowed as-is; however, it may prescribe or forbid the execution of other actions,
	\item rejected, or
	\item allowed, but in a modified version, possibly requiring the selection, projection or change of state of resource’s fields, along with complementary or forbidden actions.
\end{itemize}
The latter is the most interesting case, since a recommendation on how to resolve the conflict is generated by the PDP, in the form of an updated intention. For example, the compliant ODRL request for the intention of Figure~\ref{fig:intention-object}, given the policy of Figure~\ref{fig:ODRL-policy}, is presented in Figure~\ref{fig:modifiedODRL}, highlighting the necessary changes to the original request, Both rules defined in the policy of Figure~\ref{fig:ODRL-policy} have been applied to the intention of Figure~\ref{fig:intention-object}, in order to provide common ground between the data consumer and provider, e.g., in the context of a negotiation and eventual agreement. In more detail, the first highlighted modification (lines 61-73) concerns the restriction on the \texttt{NumberOfEmployees} property of the assignee, while the second one (lines 102-115) addresses the temporal constraint that the processing can take place before 31/12/2025, both prescribed by the permission of the policy. The third highlighted modification (lines 121-142) concerns refinements of the resource/target of the policy; associated constraints of the original permission and prohibition are combined so that processing is allowed only upon the specific parts (\texttt{BurntCalories}, \texttt{ExerciseType} and \texttt{HeartRateRange}) of the \texttt{TrainingMeasurements} and for less recent training sessions performed before 1/1/2025. The fourth modification (lines 9-13) reflects the semantic nature of conflict identification and resolution; although the original rules are defined for the \texttt{dpv:Analyse} action, \texttt{upcast:PeformStatisticalAnalysis} included in the request does not result in a conflict as \texttt{upcast:PeformStatisticalAnalysis} \texttt{isA} \texttt{dpv:Analyse} in the Information Model. It is noted that the odrl:implies predicate is leveraged for denoting specialisation of concepts, further fostering explainability. Finally, a duty has been added to the request prescribing anonymisation of the associated measurements before processing (lines 115-119). Figure~\ref{fig:conflict-resolution-suggestions} illustrates the suggestion of possible conflict resolution within the Process Modeller.



\begin{figure}[!htb]
	\centering
	\includegraphics[width=\linewidth]{figs/modifiedODRL}
	\caption{Modified ODRL request}
	\label{fig:modifiedODRL}
\end{figure}

\begin{figure}[!htb]
	\centering
	\includegraphics[width=\linewidth]{figs/conflict-resolution-suggestions}
	\caption{Suggestion for conflict resolution in the Process Modeller}
	\label{fig:conflict-resolution-suggestions}
\end{figure}

