Modeling a GDPR Compliant Data Wallet Application in Prova and AspectOWL Ralph Schäfermeier1 , Theodoros Mitsikas2,3 and Adrian Paschke1,3 1 Fraunhofer FOKUS, Berlin, Germany 2 National Technical University of Athens, Zografou, Greece 3 Institut für Angewandte Informatik, Leipzig, Germany Abstract We present a GDPR-compliant data privacy and access use case of a distributed data wallet and we explore its modeling using two options, AspectOWL and Prova. This use case requires a representation capable of expressing the dynamicity and interaction between parties. While both approaches provide the expressiveness of non-monotonic states and fluent state transitions, their scope and semantics are vastly different. AspectOWL is a monotonic context ontology language, able to represent dynamic state transitions and knowledge retention by wrapping parts of the ontology in isolated contexts, while Prova can handle state transitions at runtime using non-monotonic state transition semantics. We present the two implementations and we discuss the similarities, advantages, and differences of the two approaches. Keywords GDPR, Knowledge Representation, Prova, AspectOWL 1. Introduction In the wake of the introduction of the European GDPR (General Data Protection Regulation) in 2016 and its effective enforcement since 2018 businesses worldwide were obliged to review and adapt their data privacy policies if they desired to continue offering their online services to EU citizens. The complexity of regulatory works such as the GDPR and the large amount of parties affected by them has led to an increased interest in research on the problem of automatic legal and ethical compliance checking. The foundation of such systems is an adequate formalization of the body of rules under consideration. A key concept in GDPR is the concept of consent, meaning that the user (data subject) must agree to any processing of personal data. Moreover, the user has the right to receive the collected personal data in a machine-readable format, as well as the right to transmit those data to another controller (right to data portability) [1]. Adhering to the above principles, efforts and projects such as Solid aim to give users more control over their personal data. Solid uses Semantic Web technologies to decouple user data RuleML+RR’22: 16th International Rule Challenge and 6th Doctoral Consortium, September 26–28, 2022, Virtual $ ralph.schafermeier@gmail.com (R. Schäfermeier); mitsikas@central.ntua.gr (T. Mitsikas); adrian.paschke@fokus.fraunhofer.de (A. Paschke) € https://www.data-analytics-center.org/team-0886abf92d9d2018 (R. Schäfermeier); https://www.mi.fu-berlin.de/inf/groups/ag-csw/Members/members/paschke.html (A. Paschke)  0000-0002-4349-6726 (R. Schäfermeier); 0000-0002-7570-3603 (T. Mitsikas); 0000-0003-3156-9040 (A. Paschke) © 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) from the applications that use this data, which makes it easy for users to switch between applications that use the same data and to switch between storage providers that host the data, while having access control to their data [2]. A typical architecture of such an ecosystem has different components, each having a specific role: an Identity Provider (IDP) manages the user identity information and also provides authentication services, a Data Wallet Provider (DWP) stores user data, and Relaying Parties are applications that can access and process the data. Decoupling user data from the applications requires data to be stored in a structured way, compatible across the DWPs, and provides the user with control over their data, as users must demonstrate consent to allow applications to access and process the data [2]. To this end, we present a use case addressing a generic distributed data wallet scenario, with consent being a central concept both for access control (sharing a picture to other users) and for personal data processing (using personal data for a personalized Web search). We provide two implementations using two formalisms that are both sufficiently expressive: AspectOWL, a version of OWL extended by means for expressing context-sensitive knowledge, which allows the representation of dynamic and deontic aspects of the domain, and the rule engine Prova. The remainder of this paper is organized as follows. Section 2 presents the languages Prova and AspectOWL. Section 3 describes the use case, while Section 4 discusses the implementation in AspectOWL and Prova. Section 5 compares and evaluates the two approaches and finally, Section 6 concludes the paper and proposes future work. 2. Background 2.1. AspectOWL AspectOWL [3] is an extension of the W3C OWL 2 ontology language1 that permits the representation of contextualized knowledge by adding formal context descriptions (here called aspects) to TBox, RBox, and ABox axioms of an OWL ontology. AspectOWL is an instance of a general Knowledge Representation (KR) approach to the formalization of context, named Aspect-Oriented Ontology Development (AOOD) [4]. AOOD, in turn, is inspired by the Aspect-Oriented Programming (AOP) paradigm [5], from which it lends most of its basic concepts and accompanying terminology. 2.1.1. Aspect-Oriented Programming Aspect-Oriented Programming (AOP) aims at improving software modularity. The principle idea is the separation of pieces of (normally entangled) software code by the concerns they address. This is accomplished by diverting from the strictly execution-flow-centered semantics of classical imperative programming languages and moving code that addresses different concerns into different, isolated modules (called aspects). The information on when each aspect is executed resides in the aspect itself and is provided in a reifying manner, usually employing either an annotation system or queries in the form of formulae quantifying over the set of method signatures. Such a reference is called a join point 1 https://www.w3.org/TR/owl2-overview/ and a set of join points defined by a reifying query is referred to as a pointcut. The code in the aspect along with its pointcut description is called advice. The modules affected by the code of the aspect remain oblivious about it; it is the responsi- bility of the runtime environment to intercept existing join points and divert the control flow accordingly. Due to this property and the quantification used for the definition of pointcuts, an often quoted statement about AOP is that its two fundamental principles are quantification and obliviousness [6]. Aspects are a special kind of class (in terms of object orientation) with executable methods. As a consequence, they carry potential join points themselves and may therefore be arbitrarily nested. As an example, a login procedure might require authentication of the user, possibly logging for later auditing and then creating a user session, addressing the concerns “security”, “auditing”, and the actual “business logic”, leading to a situation where all of these cross-cutting concerns are executed in the same method body (see Figure 1a). In AOP the code addressing the first two concerns would reside in their own aspects, respectively and only the code handling the actual business logic would remain in the original method (see Figure 1b). class UserAccount { private SessionManager sessionManager; public Session login(User user, String password) { return sessionManager.createSession(user); } } class UserAccount { aspect Authentication { private AuthenticationService authenticationService; private AuthenticationService authenticationService; @Pointcut(UserAccount.login*(User user, String password, ...) private Logger logger; advice(user, password) { try { private SessionManager sessionManager; authenticationService.authenticate(user, password); } catch (AuthenticationError e) { public Session login(User user, String password) { throw new AuthenticationFailedException(user); } try { } authenticationService.authenticate(user, password); } } catch (AuthenticationError e) { throw new AuthenticationFailedException(user); aspect Logging { } private Logger logger; logger.log("Successfully authenticated user " + user.getName()); @Pointcut(UserAccount.login*(User user, ...) advice(user) { return sessionManager.createSession(user); logger.log("Successfully authenticated user " + user.getName()); } } } } (a) The three cross-cutting concerns “security” (b) Separation of concerns using aspects. The main (green), “auditing” (red), and “business logic” concern (business logic) remains in the method (blue) are handled in the same method body, lead- body, the two other concerns become encap- ing to entangled code. sulated in their respective aspects. Pointcut queries define the locations at which the aspects intercept the main code (illustrated by the ar- rows). 2.1.2. Aspect-Oriented Ontologies: Modularization by Context-Level AOOD lends its fundamental principles from AOP and applies them to knowledge representation formalisms, such as OWL ontologies. It uses a similar quantification/reification mechanism in order to connect aspects to primitives of the underlying formalism (in the case of OWL it connects them to OWL axioms), by also using primitives from the formalism in order to describe the aspects themselves (in case of OWL, for example, aspects are OWL class expressions). Applied to KR formalisms, aspects can be used to convey context to axioms (for example temporal information) that restricts the validity of the target primitive. AspectOWL uses Modal Logics as a context language and makes use of the fact that Modal Logics are syntactic variants of Description Logics [7], i. e., (almost) every Modal Logic can be translated to a particular Description Logic (and thereby to OWL) so that modal contexts (such as temporal, spatial, or deontic) can be expressed using OWL. For this purpose, Aspect OWL introduces a new axiom type called aspect assertion axiom. An aspect assertion is a binary relation between an OWL axiom and an advice class expression (the context of the axiom). Syntactically, aspect assertion axioms resemble annotation assertion axioms. They differ from the latter in that they have a defined model theoretic semantics, which makes use of combined interpretations, which we call a 𝒮ℛ𝒪ℐ𝒬𝐾𝑟𝑖𝑝𝑘𝑒 interpretation. Definition 1. A 𝒮ℛ𝒪ℐ𝒬𝐾𝑟𝑖𝑝𝑘𝑒 interpretation is a tuple 𝒥 := (𝑊, 𝑅, 𝐿, ·𝒥 , ∆, (·ℐ𝑤 )𝑤∈𝑊 ) with 𝑊 being a nonempty set, called possible worlds, and 𝐿 a Kripke interpretation, assigning truth values to propositional symbols in each world 𝑤 ∈ 𝑊 as described in the subsection about Modal Logics. For every 𝐴 ⊆ 𝑊 , ℐ𝐴 is a DL interpretation. The semantics of an aspect of an axiom is then defined as follows: Definition 2. Let 𝒥 := (𝑊, 𝑅, 𝐿, ·𝒥 , ∆, (·ℐ𝑤 )𝑤∈𝑊 ) be a possible-world DL interpretation. We interpret an aspect under which an axiom 𝛼 holds as follows: (hasAspect(𝛼, 𝐴))𝒥 → 𝐴𝒥 ⊆ 𝐶 𝒥 := {𝑤 ∈ 𝑊 | ℐ𝑤 |= 𝛼}. Because of the correspondence as described in the subsection about Modal Logics we can set 𝑊 = 𝐶 𝒥 , such that on the semantic level each individual corresponds to a possible world. Furthermore, we set 𝐿 such that 𝐿(𝛼)𝒥 := 𝐴𝒥 . AspectOWL currently implements three ways of axiom reification for pointcut selection: By DL-based modules, using SPARQL queries, and by a set of specialized SWRL built-ins2 . For a full description of the features and semantics of AspectOWL 2, see [3]3 . 2.2. Prova Prova is both a (Semantic) Web rule language and a distributed (Semantic) Web rule engine. It supports reaction rule based workflows, event processing, and reactive agent programming. It integrates Java scripting with derivation and reaction rules, supporting message exchange with various communication frameworks [8, 9, 10]. Syntactically, Prova builds upon the ISO Prolog syntax and extends it, notably with the integration of Java objects, typed variables, F-Logic-style slots, and SPARQL and SQL queries. Prolog-like compound terms can be represented as generic Prova lists (e.g., a standard Prolog- like compound term f(t1 , ..., tN ) is a syntactic equivalent of the Prova list [f, t1 , ..., tN ]). Slotted terms in Prova are implemented using the arrow expression syntax ‘->’as in RIF and RuleML, and can be used as sole arguments of predicates. They correspond to a Java HashMap, with the keys limited to Stings [11]. Semantically, Prova provides the expressiveness of serial Horn logic with a linear resolution for extended logic programs (SLE resolution) [12], extending the linear SLDNF resolution with goal memoization and loop prevention. Negation as failure support in the rule body can be added to a Knowledge Base (KB) by implementing it using the cut-fail test as follows: 2 https://github.com/RalphBln/aspect-swrl-builtins 3 For an overview over the complete abstract syntax of Aspect OWL 2, see http://www.aspectowl.xyz/syntax/. not ( A ) : − d e r i v e (A) , !, fail ( ) . not ( _ ) . Notice the Prova syntax for fail that requires parentheses, as well as the built-in meta- predicate derive that allows to define (sub) goals dynamically with the predicate symbol unknown until run-time [10]. Prova’s reactive agents are instances of a running rulebases that include message passing primitives. These built-in primitives are the predicates sendMsg/5, rcvMsg/5, as well as their variants sendMsgSync/5, rcvMult/5. The position-based arguments for the above predicates are [11]: 1. XID - conversation id of the message 2. Protocol - name of the message passing protocol 3. Destination (on sending) or Sender (on receiving) - the agent name of the receiver/sender 4. Performative - the message type broadly characterizing the meaning of the message 5. Payload - a Prova list containing the actual content of the message Prova defines the Java interface ProvaService and its default implementation ProvaServiceImpl that allows for a runner Java class – depending on the modularization (mapping each agent to a separate bundle vs. multiple agents in a bundle) – to embed one or more agents communicating with each other via messaging. The fundamental method is the method send that takes the following arguments: send ( S t r i n g xid , S t r i n g d e s t i n a t i o n , S t r i n g sender , S t r i n g performative , Object payload , EPService c a l l b a c k ) The arguments have a direct correspondence with the message passing primitives, while EPService is a superclass of the ProvaService interface. Also, the message passing protocol is selected automatically (in our use case, the osgi protocol is selected). 3. Use Cases In this section, we describe two data wallet use cases in terms of interaction sequences and data exchange between the different parties involved. The use case revolves around fictional data wallet owners that share personal data using relaying parties that provide specialized applications (a search applications and a picture sharing application). Use Case 1: Personalized Search (Figure 2) • Alice opens an account with an Identity Provider IdPAlice . • She demonstrates consent for the IdP to store her OpenID and her login credentials for the purpose of confirming her identity towards third parties. • Now Alice opens an account with a Data Wallet Provider DWP_Alice. • She demonstrates consent for the DWP to store data she uploads to the DWP along with her WebID document, which represents her online identity and contains a link to her OpenID (managed by her IdP). • Alice seeks some information at the third-party app SearchApp (relying party, RP) • She launches SearchApp and enters a search query. • The app requests personal data about her previous search history from Alice’s personal data wallet for personalization of the current search. • The app also asks if Alice’s data might be used for data analytics by SearchApp. • Alice expresses her consent for both purposes by giving read permission for the requested data to SearchApp (identified by its WebID) • SearchApp reads and stores the data Alice gave them permission for and derives an anonymized dataset for data analytics purposes. • Later Alices demonstrates the revocation of her consent to use the data for data analytics and personalisation purposes by SearchApp by revoking the read permission. • SearchApp may continue to use the derived (anonymized) data. • SearchApp must delete the personal data it has obtained from Alice’s data wallet. • SearchApp is now denied to get updates from Alice’s search history data from her data wallet. Use Case 2: Sharing Pictured via a Wallet-Enabled Sharing App (Figure 3) • Alice decides to share a personal picture with her friends Bob and Cesar using PictureApp (relying party 2, RP2). • She demonstrates consent for PictureApp to retrieve the picture from her data wallet. • She demonstrates consent for PictureApp (identified by its WebID) to make the picture available to her friends Bob and Cesar, both identified by their WebIDs. • Later, Alice demonstrates the revocation of her consent to share the picture with Cesar by revoking read permission for Cesar. • PictureApp is still permitted to store a copy of Alice’s image. • PictureApp has the obligation to deny Cesar access to the image. 4. Implementation 4.1. AspectOWL As OWL is a monotonic, declarative knowledge representation formalism it is suited for repre- senting the static aspects of the domain under consideration. With AspectOWL, however, it is also possible to represent dynamic behavior: Different states of the universe may be represented by different contexts (in the form of OWL aspects) in which certain axioms hold respectively. The transition between states may be represented in terms of events that happen at a certain point in time with the contexts representing two subsequent states having a temporal extension either before or after the point in time. SearchApp DWPAlice IdPAlice IdPDWP Alice /createAccount?user=alice&pw=secret; consent(credentials, store, service provision); consent(OpenID, store, service provision) OpenID /createAccount?id=OpenID /checkIdentity?id=OpenID request credentials /login?user=alice&pw=secret auth_token /confirmIdentity?id=OpenID&auth=auth_token WebIDAlice consent(WebIDAlice & personal, storage & transmission, service provision) /store?data= /search?query=text request_consent(personal, collect & store, personalization) consent(personal, collect & store, personalization) request_consent(personal, derive, analytics) consent(personal, derive, analytics) /get/alice/data?requester=WebIDDWP HTTP redirect to IdPDWP request_authentication(DWP) auth_token /get/alice/data?auth=auth_token personal derive analysis_result revoke_consent(personal, storage, analytics & personalization) delete(personal) Alice SearchApp DWPAlice IdPAlice IdPDWP Figure 2: First part of the use case: Alice creates an account with a DWP, demonstrates consent for sharing personal data for the purposes of sharing and analysis, later revokes her consent for the purpose of analysis. Furthermore, AspectOWL permits the application of deontic modalities to OWL axioms. Since nesting of aspects is also allowed, it is possible to combine the two and represent dynamic change of deontic modalities. Our development process was guided by the following principles: We aimed to reuse existing ontologies if available. A significant amount of concepts could be imported from the current publicly available version of the PrOnto ontology [13]. Furthermore, we use existing ontology design patterns (ODPs) whenever applicable. Links to ODPs used in this work are provided in DWPAlice IdPCesar PictureApp Alice Cesar store?data=picture; consent(picture & WebIDAlice, storage & transmission, service provision) consent(picture & WebIDAlice, read(Bob, Cesar), service provision) /get/alice/picture HTTP redirect to IdP_Cesar request_authentication?webId=cesar&rp=PictureApp) auth_token /get/alice/picture?auth=auth_token picture picture revoke_consent(picture, read(Cesar), service provision) /get/alice/picture?auth=auth_token /get/alice/picture?auth=auth_token access denied access denied Alice Cesar DWPAlice IdPCesar PictureApp Figure 3: Second part of the use case: Alice shares a picture from her data wallet with Bob and Cesar. Cesar accesses her picture using a wallet-enabled sharing app. Later, Alice decides to revoke permission from Cesar to access her picture. He and the sharing app can no longer access the picture. the footnotes. 4.1.1. Static Part Data Data is the central concept of the GDPR domain around which everything else revolves. We reuse the data concept hierarchy from the PrOnto ontology [13], which makes Data a subclass of InformationObject, which in turn is a subclass of the class FRBRWork from the Functional Requirements for Bibliographic Records (FRBR) vocabulary. 1. Data ⊑ InformationObject 2. InformationObject ⊑ akn:FRBRWork4 3. akn:FRBRWork ⊑ owl:Thing Ownership of Data The GDPR is concerned about usage of data by different agents. Agents may either be human persons or non-human organizations. 4 akn: Akoma Ntoso XML for parliamentary, legislative & judiciary documents (OASIS). FRBR: Functional Requirements for Bibliographic Records (IFLA) 4. Person(Bob) 5. ownedBy(dataHabit, Bob) Agent Roles Agents, i. e., both persons and organizations, may assume roles as defined by the GDPR, namely the role of the data subject, the data controller, and the data processor. The same agent may assume several of these roles at the same time, e. g., a company may be both data controller and data processor. 6. ∃hasRole.DataSubject(Bob) 7. ∃hasRole.Controller(CompanyA) 8. ∃hasRole.Processor(CompanyB) Demonstration of Consent Demonstration of consent is modeled in terms of a contract. 6. ConsentAction ⊑ te:Action5 7. ConsentAction(ca) 8. pwo:happened(ca, t1)6 9. pwo:produces(ca, co), Consent(co), Consent ⊑ Contract 10. allowsAction(co, ac) 11. bpe:actionHasParticipant(ac, org)7 12. hasSubject(ac, data) Data Processing Purpose As mandated by the GDPR, user consent for the processing of personal data must be explicitly given for a specific purpose and is only valid for that particular purpose. 13. Purpose ⊑ owl:Thing 14. Advertising ⊑ Purpose 15. Marketing ⊑ Purpose 16. Optimisation ⊑ Purpose 17. allowedPurpose ⊑ owl:topObjectProperty 18. allowedPurpose(dataHabit, advertising) Data Processing Action For the conceptualization of data processing actions we re-use the existing concept Action from the PrOnto ontology along with a number of ontology design patterns. PrOnto defines actions as parts of workflows and relies on the Basic Plan Execution design pattern for doing so. The 5 http://www.ontologydesignpatterns.org/cp/owl/taskexecution.owl 6 http://purl.org/spar/pwo/ 7 http://www.ontologydesignpatterns.org/cp/owl/basicplanexecution.owl latter distinguishes between abstract workflow descriptions (which are abstract plans) and their concrete executions. Consequently, a workflow description may have arbitrarily many workflow execution instan- tiations, which in turn may involve arbitrarily many actions. 19. Analysis ⊑ DataProcessing 20. DataProcessing ⊑ Workflow 21. Workflow ⊑ Plan 22. Plan ⊑ Description 23. Workflow ⊑ ∀isSatisfiedBy.bpe:PlanExecution8 A concrete execution of an abstract workflow is represented as follows: 24. pwo:WorkflowExecution ⊑ bpe:PlanExecution 25. pwo:WorkflowExecution ⊑ tis:TimeIndexedSituation9 26. bpe:PlanExecution ⊑ sit:Situation 27. tis:TimeIndexedSituation ⊑ sit:Situation And finally, an action is part of a workflow execution: 28. pwo:WorkflowExecution ⊑ ∃pwo:involvesAction.(pwo:Action ⊓ ∃te:executesTask.pwo:Step) 4.1.2. Dynamic Part In this section, we demonstrate how dynamic processes (in terms of transitions between different states of the universe over time, usually in succession of an event) can be represented using AspectOWL. Demonstrating consent for the processing of data by a third party leads to a transition between two states; from one in which the processing is not permitted to one where it is. It is possible to represent the two different states using two OWL aspects, each representing one state. As the transition is triggered by an event that happened at a certain point in time T_DC_1 the states may also be represented as temporal contexts, the boundaries of both of which coincide at T_DC_1. 29. StateAspect1 ⊑ aot:TemporalAspect ⊓ time:before.{T_DC_1}9 30. StateAspect2 ⊑ aot:TemporalAspect ⊓ ({T_DC_1} ⊔ time:after.{T_DC_1}) As it is not possible for the same thing to be permitted and prohibited at the same time it must be made sure that the two aspects representing the states are disjoint. 31. StateAspect1 ⊓ StateAspect2 ⊑ owl:Nothing 7 http://www.ontologydesignpatterns.org/cp/owl/timeindexedsituation.owl 8 http://www.ontologydesignpatterns.org/cp/owl/situation.owl 9 https://ontology.aspectowl.xyz/temporal# The action that is allowed in the state after the demonstration of consent is represented by a simple object property assertion: 32. processesData(o1, data), where 33. Organisation(o1) ⊓ Data(data) However, the aspect cannot be directly applied to the above assertion axiom since this would mean that starting from time point T_DC_1 the organization o1 processes data, while what we want to represent is the fact that o1 is permitted to process data starting at T_DC_1. Representing the permission involves the creation of a further aspect of the type deontic aspect. 34. PermissionAspect ⊑ aod:DeonticAspect ⊓ ∃aod:legallyAccepts.aod:Reality10 Application of the deontic aspect to the assertion and the nesting of the resulting aspect assertion into the temporal aspect StateAspect2 yield the representation of the statement that o1 is allowed to proccess data starting at T_DC_1. 35. Aspect(StateAspect2, Aspect(PermissionAspect, processesData(o1, data))) In order to derive statements of this kind automatically when an assertion of demonstration of consent is encountered in the knowledge base, the following SWRL rule can be employed. -: DemonstrateConsent(?ca), pwo:happened(?ca, ?t1), actedBy(?ca, ?ds), pwo:produces(?ca, ?co), Consent(?co), allowsAction(?co, ?ac), bpe:actionHasParticipant(?ac, ?org), hasSubject(?ac, ?data), aspectswrl:createOPA(collectsDataFrom, ?org, ?ds, ?a), aspectswrl:temporal(?a, time:after, ?t1, true), aspectswrl:deontic(?perm, legallyAccepts, aod:Reality), aspectswrl:nest(?perm, ?a) The rule makes use of multiple AspectSWRL built-ins. aspectswrl:createOPA, which creates the OWL object property assertion and wraps it in an aspect bound to variable ?a. aspectswrl:temporal creates the temporal aspect a. The first parameter binds the resulting aspect to ?a. The second parameter determines the accessibility relation used, in this case time:after. The third parameter determines the time individual used in conjunction with the accessibility relation, which we set to the value of the variable ?t1 and which corresponds to the object in the pso:happened predicate. The fourth parameter is a boolean determining whether the individual should be included in the interval defining the aspect or not. In this case, we want ?t1 to be included in the interval. aspectswrl:deontic works similarly with the parameters being the variable to which the resulting aspect should be bound, the accessibility relation, and 10 https://ontology.aspectowl.xyz/deontic# the individual representing reality. aspectswrl:nest nests takes to aspects as parameters and results in a nesting of the first into the second. When the user retracts their consent, an instance of the class RevokeConsent is created, which has the same properties as the DemonstrateConsent. A second SWRL rule, similar to the one above, with the exception that it contains RevokeConsent instead of DemonstrateConsent in the antecedent and legallyProhibits instead of legallyRejects then creates the new temporal context in which the former modality of permission of the data processing is replaced by a prohibition modality. Figure 4 provides an overview of the ontology and the aspects created by the rules11 . taskexecution:Action action: http://www.estrellaproject.org/lkif-core/action.owl# ao: https://ontology.aspectowl.xyz# aod: https://ontology.aspectowl.xyz/deontic# subClassOf subClassOf aot: https://ontology.aspectowl.xyz/temporal# T_DC_1 basicplanexecution: http://www.estrellaproject.org/lkif-core/action.owl# DemonstrateConsent Collect pronto: https://w3id.org/ontology/pronto# instanceOf pwo: http://purl.org/spar/pwo/ =1 pwo:happened allowsAction =1 pwo:produces taskexection: http://www.ontologydesignpatterns.org/cp/owl/taskexecution.owl# time:Instant time: http://www.w3.org/2006/time# Consent =1 actedBy subClassOf ∃ hasSubject ServiceProvision subClassOf pronto:Purpose pronto:Contract ∃ allowedPurpose basicplanexecution:actionHasParticipant action:Agent pronto:Data subClassOf subClassOf action:Person action:Organisation ∃ ownedBy instanceOf instanceOf Organisation_1 collectsData PersonalData_1 aot:TemporalAspect subClassOf hasAspect StateAspect aod:DeonticAspect hasAspect ≡ ({T_DC_1} or (time:after value T_DC_1)) subClassOf PermissionAspect ≡ aod:legallyAccepts some aod:Reality Figure 4: An excerpt from the RECOMP AspectOWL ontology showing the part used for representing the act of demonstration of consent and its consequences. Aspects are represented by areas of different shades of gray. The light-gray area depicts a an OWL object property assertion axiom, which is target of a deontic aspect, representing the fact that the validity of the target axiom is permitted. It is nested in a temporal aspect, which temporally restricts the validity of the permission. The assertion and the nested aspects are the result of the execution of a SWRL rule, which uses the AspectOWL SWRL built-ins. 11 The ontology files are available at https://github.com/RalphBln/recomp-use-cases 4.2. Prova The Prova implementation12 uses the message passing primitives mentioned in Section 2. All parties are represented as agents that communicate via message passing. All actions of the workflow are initiated by messages sent by the Java runner class to the appropriate agent. To demonstrate the Prova implementation, we focus on the first part of the use case presented in Section 3, where Alice (represented by the agent alice) performs a web search. The SearchApp (represented by the agent searchApp) requests consent for personal data access and delivers a personalized search result if the consent was demonstrated, or a non-personalized result otherwise. The actions of alice are controlled from Java, essentially creating a script with the messages that alice receives, which in turn are forwarded to other agents. Therefore, initially we pass the following message to alice from Java: payload . put ( " agent " , " searchApp " ) ; payload . put ( " o p e r a t i o n " , " search " ) ; p a y l o a d . p u t ( " webID " , " a l i c e . example . com " ) ; payload . put ( " query " , " t r a v e l s u g g e s t i o n s " ) ; p a y l o a d . p u t ( " dwp " , " dwp " ) ; s e r v i c e . send ( " xid " , " a l i c e " , " javaRunner " , " r e q u e s t " , payload , t h i s ) ; where payload is a Java HashMap, with its elements corresponding to the slot names and fillers. These are the agent that performs the search, the operation, alice’s WebID, the search query, and the agent that serves as a data wallet provider. The above message is captured by the following inline reaction rule [11]: alice () :− r c v M u l t ( XID , P , From , r e q u e s t , { a g e n t −>A , o p e r a t i o n −>Op , webID −>WebID , query −>Q , dwp−>DWP } ) , sendMsg ( XID , P , A , r e q u e s t , { o p e r a t i o n −>Op , webID −>WebID , query −>Q } ) . This rule instructs that upon receiving a message of this pattern, alice will send a message to the appropriate agent (e.g., to the agent searchApp) requesting a specific operation (e.g., search). On the searchApp side, the inline reaction rule for the search operation is the following: searchApp ( ) : − r c v M u l t ( XID , P , From , r e q u e s t , { o p e r a t i o n −> s e a r c h , webID −>WebID , query −>Q , dwp−>DWP } ) , s e a r c h ( WebID , Q , From , R e s u l t , P ,DWP) , sendMsg ( XID , P , From , i n f o r m , { msg−> R e s u l t } ) . This rule evaluates when searchApp receives a message with the above pattern, evaluates search(WebID,Q,From,Result,P,DWP) and sends the message containing the search result back to the agent, in this case alice. 12 The Prova implementation is available at https://github.com/tmitsi/recomp-usecases The search/6 predicate is used to perform the search and always evaluates to true (as some search result is always returned regardless of the user consent), binding the search result in the variable Result. It has alternatives, covering the cases where the user is not yet identified through the idp, where the user was already asked for consent in the past, as well as the following alternative covering the case where the user is already logged in and performs the first search: s e a r c h ( WebID , Q , From , R e s u l t , P ,DWP) : − l o g g e d I n ( From , WebID , _ ) , n o t ( a l r e a d y A s k e d ( WebID , p e r s o n a l , p e r s o n a l i z a t i o n ) ) , Msg = " The s e a r c h A p p wants . . . . . . p e r s o n a l i z e d r e s u l t s " sendMsg ( XID , P , From , i n p u t _ r e q u e s t , { o p e r a t i o n −> c o n s e n t , d a t a −> p e r s o n a l , p u r p o s e −> p e r s o n a l i z a t i o n , msg−>Msg } ) , rcvMsg ( XID , P r o t o c o l , From , r e s p o n s e , { answer −> I n } ) , a s s e r t ( a l r e a d y A s k e d ( WebID , p e r s o n a l , p e r s o n a l i z a t i o n ) ) , !, s e a r c h H e l p e r ( WebID , Q , From , R e s u l t , DWP, I n ) . This alternative defines the actions when the user is already logged in and hasn’t been previ- ously asked about her consent for personal data process, i.e. the predicates loggedIn/3 and not(alreadyAsked(WebID,personal,personalization)) succeed. First, a message is sent back to the user, expecting to receive a yes/no answer (the relevant Prova code for alice agent is omitted). Afterwards, the fact stating that the user is already asked is asserted in to the KB, followed by the cut operator to prevent the evaluation of other search/6 alternatives. Finally, the helper predicate searchHelper(WebID,Q,From,Result,DWP,In) is eval- uated, binding the results in the variable Result, while taking in to account the consent demonstration (or, the lack of it) of the user: s e a r c h H e l p e r ( WebID , Q , From , R e s u l t , _ , no ) : − nonPersonalizedSearch (Q, R esult ) . s e a r c h H e l p e r ( WebID , Q , From , R e s u l t , DWP, y e s ) : − c o n s e n t ( WebID , p e r s o n a l , p e r s o n a l i z a t i o n ) , p e r s o n a l i z e d S e a r c h ( WebID , Q , From , R e s u l t ) . s e a r c h H e l p e r ( WebID , Q , From , R e s u l t , DWP, y e s ) : − n o t ( c o n s e n t ( WebID , p e r s o n a l , p e r s o n a l i z a t i o n ) ) , a s s e r t ( c o n s e n t ( WebID , p e r s o n a l , p e r s o n a l i z a t i o n ) ) , !, p e r s o n a l i z e d S e a r c h ( WebID , Q , From , DWP, R e s u l t ) . As seen above, the searchHelper/6 has three alternatives, covering all possible cases: 1. the user refuses to provide consent, where the nonPersonalizedSearch/2 is called and binds the non-personalized search results in to the second argument, 2. the user has already provided consent and the personalizedSearch/5 is called, and 3. the user just provided consent and this fact should be asserted to the KB, followed by the cut operator that stops the evaluation of the second alternative, and then calling personalizedSearch/5. The rest of the Prova code for personalizedSearch/5 is omitted here. 5. Comparison of Approaches In general, the two approaches used in this paper differ in their intended application scopes and hence their syntax, semantics, and expressiveness. However, interestingly, both could be used to represent a significant part of the domain under consideration. The agent-based Prova implementation with the message passing primitives was able to model the entire workflow. The reactive rules, combined with assertions and retractions were adequate to model all possible states. Moreover, it was possible to simulate real-world practices such as storing hashed passwords instead of plain-text, and session cookies to facilitate logins. This is clearly out of the scope of static knowledge-representation formalisms such as OWL, as the latter lacks the necessary interaction primitives with the outside world, such as reaction rules or data stream processing facilities. It is, however, conceivable to employ some sort of dynamically updating ABox and let our AspectSWRL rules run on new ABox axioms as they are added to the knowledge base. An obvious difference between Prova and OWL is that the latter operates in a strictly mono- tonic fashion without any notion of knowledge retraction. AspectOWL is able to circumvent this to a certain extent since its ability to create contexts which restrict the validity of exiting axioms introduces a way of mimicking non-monotonicity. However, AspectOWL is still a monotonic formalism, and while knowledge may be retracted from the global scope by restricting it to a local context, the context itself (containing the knowledge) can never be retracted. In other words, the history of emerging and disappearing knowledge can never be erased in AspectOWL. This can be regarded either as an advantage or as a disadvantage, depending on the requirements of the application. Prova, OWL, and AspectOWL permit the choice of the level of expressiveness and the selection of semantics. OWL 2, for example, introduced different profiles, such as OWL 2 DL, OWL 2 EL, OWL 2 RL, and OWL 2 QL. OWL 2 semantics correspond to the semantics of description logics and the set of language primitives used determines the particular description logic in which an OWL ontology can be expressed. Prova and AspectOWL permit the selection of semantic profiles, which, in the case of AspectOWL, determines the model-theoretic semantics under which a theory is interpreted. These choices lead to different computational properties of each of the formalisms. AspectOWL, being a static KR formalism, requires recomputation of all inferences as facts are added to the knowledge base. Incremental reasoning has not been implemented but might be in the future. In the case of the use case presented in this paper, the resulting AspectOWL ontology has an expressiveness that corresponds to the description logic 𝒜ℒ𝒞ℛ𝒪ℐ𝒬, which means that the problems of concept satisfiability and consistency checking are NExpTime-hard. Description logics are by design decidable, but AspectOWL, the semantics of which divert from pure DLs, are not guaranteed to be decidable. The non-decidability comes from the multi-dimensional interpretation. Since, however, in the underlying use case there is no interaction between the different context levels (the object and the temporal level have both access to the time individual T_DC_1, but this individual is rigid, i. e. its interpretation is context-independent), the ontology is decidable even under the AspectOWL full semantics. Prova is a combination of rule and scripting language. The semantics of the rule language correspond to Prolog, which makes Prova generally undecidable. Prova extends the declarative rule language by procedural attachments, a mechanism for making calls to procedures written in an imperative language, such as Java, which makes it impossible to make a generalized statement about the computational properties of the Prova system as a whole. Prova’s messaging system, of which we primarily make use in the context of this research, is pattern-based with selectable inference regimes, such as DL reasoning. A clear advantage of AspectOWL is its full backwards-compatibility with OWL 2 and the resulting ability to import and reuse existing knowledge from the many OWL ontologies that are publicly available as we did with PrOnto and the ontology design patterns while the Prova implementation was basically built from scratch. In in the context of the data wallet scenario existing standards such as Solid use RDF as their data model and are thereby directly compatible with AspectOWL. 6. Conclusions and Future Work We described a GDPR-related use case for a distributed data wallet. The use case defines all typical stakeholders, namely an Identity Provider, a Data Wallet Provider, Relaying Parties as applications (a PictureApp and a SearchApp), and users. The main concepts of the use case are data access (from Relaying Parties or from users), and demonstration of consent that enables this data sharing. Depending on consent demonstrating or consent revoking actions, different possible states can emerge, rendering the use case non-monotonic. We provided two implementations, one in AspectOWL, one in Prova. Both approaches were able to result in a representation of the problem domain which is sufficiently adequate for GDPR-related inference tasks, especially deontic state transitions resulting from actions such as demonstration of user consent. Prova with its reaction rule style messaging system and procedural attachments is capable of implementing the entire workflow of our given use cases. Specifically, the Prova implementation is able to fully model the interaction of all parties (represented as agents) in real-time. The reactive messaging capabilities, the Java object support and the non-monotonic state transition semantics can model all possible states of the use case. The AspectOWL implementation provides both the ontology with types and description of the domain concepts, and the state transition modeling required by the use case. However, since AspectOWL is a monotonic formalism the representation of non-monotonic states using contexts may lead to an indefinite growth of the knowledge base. While AspectOWL proved to be a suitable approach for the specification of the domain model Prova is the more practical approach for a real-world application. Therefore, the two implementations are complementing each other. Future work may consist in combining the two approaches, by integrating and reusing the existing AspectOWL ontology in the Prova runtime system, combining the strengths of the two systems. This combined system may serve as a real-world back-end of an ecosystem of a distributed data wallet and applications. Investigating and implementing methods of incremental reasoning for the AspectOWL reasoner is also planned. Acknowledgments This work has been partially funded by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) project RECOMP (DFG – GZ: PA 1820/5-1). References [1] European Commission, Regulation (EU) 2016/679 of the European Parliament and of the Council, 2016. URL: http://data.europa.eu/eli/reg/2016/679/oj. [2] E. Mansour, A. V. Sambra, S. Hawke, M. Zereba, S. Capadisli, A. Ghanem, A. Aboulnaga, T. Berners-Lee, A demonstration of the solid platform for social web applications, in: Pro- ceedings of the 25th International Conference Companion on World Wide Web, WWW ’16 Companion, International World Wide Web Conferences Steering Committee, Republic and Canton of Geneva, CHE, 2016, p. 223–226. URL: https://doi.org/10.1145/2872518.2890529. doi:10.1145/2872518.2890529. [3] R. Schäfermeier, A. Paschke, Aspect-oriented ontology development, in: G. J. Nalepa, J. Baumeister (Eds.), Synergies Between Knowledge Engineering and Software Engineering, volume 626 of Advances in Intelligent Systems and Computing, Springer, 2018, pp. 3–30. URL: https://doi.org/10.1007/978-3-319-64161-4_1. doi:10.1007/978-3-319-64161-4_1. [4] R. Schäfermeier, A. Paschke, Aspect-Oriented Ontologies: Dynamic Modularization Using Ontological Metamodeling, in: P. Garbacz, O. Kutz (Eds.), Proceedings of the 8th International Conference on Formal Ontology in Information Systems (FOIS 2014), volume 267 of Frontiers in Artificial Intelligence and Applications, IOS Press, 2014, pp. 199 – 212. [5] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, J. Irwin, Aspect-Oriented Programming, in: M. Aksit, S. Matsuoka (Eds.), ECOOP’97 — Object- Oriented Programming, volume 1241 of Lecture Notes in Computer Science, Springer Berlin / Heidelberg, 1997, pp. 220–242. [6] R. Filman, D. Friedman, Aspect-Oriented Programming Is Quantification and Obliviousness, Workshop on Advanced Separation of Concerns, OOPSLA (2000). [7] K. Schild, A Correspondence Theory for Terminological Logics: Preliminary Report, in: J. Mylopoulos, R. Reiter (Eds.), Proceedings of the 12th International Joint Conference on Artificial Intelligence. Sydney, Australia, August 24-30, 1991, Morgan Kaufmann, 1991, pp. 466–471. [8] A. Kozlenkov, R. Penaloza, V. Nigam, L. Royer, G. Dawelbait, M. Schroeder, Prova: Rule- Based Java Scripting for Distributed Web Applications: A Case Study in Bioinformatics, in: T. Grust, H. Höpfner, A. Illarramendi, S. Jablonski, M. Mesiti, S. Müller, P.-L. Patranjan, K.-U. Sattler, M. Spiliopoulou, J. Wijsen (Eds.), Current Trends in Database Technology – EDBT 2006, Springer Berlin Heidelberg, Berlin, Heidelberg, 2006, pp. 899–908. [9] G. Kober, L. Robaldo, A. Paschke, Modeling medical guidelines by prova and shacl accessing fhir/rdf. use case: The medical abcde approach, in: dHealth 2022, IOS Press, 2022, pp. 59–66. [10] A. Paschke, Rules and Logic Programming for the Web, Springer Berlin Heidelberg, Berlin, Heidelberg, 2011, pp. 326–381. doi:10.1007/978-3-642-23032-5_6. [11] A. Kozlenkov, Prova Rule Language version 3.0 User’s Guide (2010). URL: https://github. com/prova/prova/tree/master/doc. [12] A. Paschke, M. Bichler, Knowledge representation concepts for automated SLA manage- ment, Decision Support Systems 46 (2008) 187–205. URL: https://www.sciencedirect.com/ science/article/pii/S0167923608001206. doi:https://doi.org/10.1016/j.dss.2008. 06.008. [13] M. Palmirani, M. Martoni, A. Rossi, C. Bartolini, L. Robaldo, PrOnto: Privacy Ontology for Legal Reasoning, in: A. Kő, E. Francesconi (Eds.), Electronic Government and the Information Systems Perspective, Springer International Publishing, Cham, 2018, pp. 139– 152.