In recent years, there have been many developments for GDPR-compliant data access and sharing based on consent. For more complex data sharing scenarios, where consent might not be sufcfiient, many parties rely on contracts. Before a contract is signed, it must undergo the process of contract negotiation within the contract lifecycle, which consists of negotiating the obligations associated with the contract. Contract compliance verification (CCV) provides a means to verify whether a contract is GDPR-compliant, i.e., adheres to legal obligations and there are no violations. The rise of knowledge graph (KG) adoption, enabling semantic interoperability using well-defined semantics, allows CCV to be applied on KGs. In the scenario of different participants negotiating obligations, there is a need for data consistency to ensure that CCV is done correctly. Recent work introduced the automated contracting tool (ACT), a KG-based and ODRL-employing tool for GDPR CCV, which was developed in the Horizon 2020 project smashHit (https://smashhit.eu). In this work, we propose a novel approach to overcome some limitations of ACT. We semi-automatically resolve CCV inconsistencies by providing repair strategies, which automatically propose (optimal) solutions to the user to re-establish data consistency and thereby support them in managing GDPR-compliant contract lifecycle data. We have implemented the approach, integrated it into ACT and tested its correctness and performance against basic CCV consistency requirements.
One of the legal bases that must be satisfied for General Data Protection Regulation (GDPR) [
Recently, approaches for digital contracting to tackle the CCV challenge are often based on knowledge
graphs (KGs) [
Shapes Constraint Language SHACL. (ii) Fixing CCV violations, i.e. semi-automatically repairing violations while at the same time ensuring the semantics of the contract.
To cope with these challenges, we first establish integrity constraints using SHACL. In the context of the
ACT tool, it may occur that CCV violations are reported based on inconsistencies present in received
data. For such cases of CCV violations, we employ SHACL validation as a declarative approach to
identify inconsistencies, and SHACL repairs [
There are several systems developed to manage contracts consistently between participants, as described
in [
Contract Lifecycle The contracting process involves drafting, negotiating terms, signing, executing obligations, and performing CCV checks during the auditing phase. Finally, the process ends with the termination or renewal of the contract.
Data Model The data for contracts and related elements is described using the Contract Ontology (CO), which incorporates the Financial Industry Business Ontology (FIBO) to semantically describe contract lifecycle elements. This work specifically focuses on the fibo:Contract class, represented by the property co:hasContractStatus, and the co:Obligation class, where contracts are linked via the co:hasObligations property and the obligation state is represented by co:hasState.
ACT [
The CCV consistency requirements were originally determined for the contract data in the smashHit KG, which was built for the use cases of the smashHit project. For achieving CCV consistency in relation to ACT, we introduce repair strategies to automatically ensure that every contract has a clearly defined and consistent status regarding the contract lifecycle.
Recent work presented SHACL repairs – an approach to repair RDF graphs to satisfy given SHACL constraints. It is based on explanations for constraint violations, which are represented as sets of additions and deletions for the RDF graph to achieve conformance. The implementation uses answer set programming (ASP) to provide repair choices as part of minimal models. In our context of fixing violations reported by CCV, we aim to automatically determine an optimal repair choice to minimize human-in-the-loop. In cases where this is not possible, the ACT UI has been extended to allow users to select one preferred choice.
Consequently, we extend SHACL repairs with repair strategies for ACT, which formalize optimizations to automatically determine optimal repair choices compliant to CCV consistency requirements. We implement a repair strategy program on top of the SHACL repair program, which parses RDF repair strategies and automatically generates additional ASP rules to determine optimal choices.
In the following, we provide an example for one of the ACT consistency requirements. The following SHACL shape represents the consistency requirement: "A Contract is violated if at least one associated Obligation has the state set to violated". :ContractViolationShape a sh:NodeShape; sh:targetClass fibo:Contract; sh:property [ sh:path :hasContractStatus; sh:maxCount 1; ]; sh:or ( [ sh:not [ sh:property [ sh:path ( co:hasObligations co:hasState ); sh:hasValue co:ViolatedState; ]; ] ] [ sh:property [ sh:path co:hasContractStatus; sh:hasValue co:statusViolated; ] ] ).
Consistency for ContractViolationShape means that there must not be any non-violated contract if there is a violated obligation. In case of a violation, the repair program either deletes hasObligations, removes the ViolatedState from the obligations or it adds the statusViolated to the contract. The repair strategy we define for CCV semantics is to only allow adding statusViolated for hasContractStatus to represent the actual real-world situation. We define two constraints for the repair strategy. :ViolatedContractStrategy a shr:RepairStrategy; shr:hasConstraint [ sh:path co:hasObligations; sh:action sh:delete; ]; shr:hasConstraint [ sh:path co:hasState; shr:action shr:delete; shr:values ( co:ViolatedState; ) ] . We assume the following data graph: :contb2b a fibo:Contract; co:hasContractStatus :statusFulfilled; co:hasObligations :ob_1 . :ob_1 a co:Obligation; co:hasState co:ViolatedState .
Without the repair strategy, the repair program would return the following two minimal repairs with deletions D1 and D2, which both violate the CCV semantics:
D1 = {hasObligations(contb2b, ob_1)}
D2 = {hasState(ob_1,ViolatedState)} In contrast, when we apply the repair strategy, the repair program will return a new minimal repair under the constraints added by the repair strategy with additions A and deletions D:
A = {hasContractStatus(contb2b, statusViolated)}
D = {hasContractStatus(contb2b, statusFul f illed)} With repair strategies, the data can now only be repaired when assigning the contract status statusViolated to the contract, thereby implementing the expected CCV semantics.
Evaluation of CCV Repairs Tests were conducted using contract data from the smashHit project to evaluate the correctness and performance, including bulk performance tests. The results in Fig. 1 show that data with up to 3000 inconsistencies was repaired within a minute. The performance curve shows an above linear development. As a conclusion from the test results, our approach shows promising performance in practice, highlighting the approach’s correctness and scalability. The implementation and test data are available on GitHub2. 2https://github.com/robert-david/shacl-repairs/tree/ccv-repair-strategies 500 1,000 1,500 2,000 2,500
Data graph inconsistencies
This work presents a new approach for semi-automatically resolving data inconsistencies in CCV using the ACT tool, simplifying the repair process and helping to manage GDPR-compliant contract data. Future work will focus on handling more complex constraints, evaluating repair quality, and expanding the approach to broader use cases, ultimately improving the applicability and reliability of semantic contract environments and supporting the adoption of formalized contracts in automated systems.
The author(s) have not employed any Generative AI tools.