Current data protection laws are not up-to-date on handling data sharing and protection in the semantic cloud. We address the associated research issues, not only for law refinement but also for technology re-engineering when the concepts embarked in the laws for regulating the cloud are updated. The ultimate objective of this study is to empower the flexible and agile use of cloud resources without fear of violating data protection and other related laws.

We propose a law-aware semantic policy infrastructure to provide LaaS for various cloud service providers (CSPs) and their potential customers. In this paper, we extend our previous work [7], where a Super-Peer Domain (SPD) for modeling a specific Trusted Legal Domain (TLD) enables data integration in the semantic policy architecture. This major revised version is explicitly different in two directions from the previous one we published in the WIMS’12 conference. (1) We introduce semantic data integration from outsourcing data in terms of the fragmentation of sensitive relationship to prevent curious but honest cloud service providers from using the data. Furthermore, we address the semantic data exchange between super-peers. A super-peer is in charge of an SPD, which is corresponding to a virtual private cloud (see Figure 1); (2) Policy exception is handled by cq-programs non-monotonic reasoning in SPD_α∩β.

Similar to a privacy appliance [8], an agent in the super-peer is a unique law-aware guardian that provides LaaS to its peers. The super-peer is also a trusted proxy of an SPD that provides a query interface between its peers and a user. Peers own real fragmented data sources that are directly mapped from relational database tables. Therefore, the super-peer provides a data integration service to its peers. Furthermore, the super-peer specifies how law-compliant semantic legal policies that are unified and enforced among SPDs to achieve data exchange. The enforcement of unified semantic legal policies not only protects integrated data from a super-peer’s own peers but also protects exchanged data from another SPD.

Regarding data protection legal issues, processing personal data in Europe is mainly regulated by the Data Protection Directive 95/46/EC, which is currently under revision. In a legally uncertain situation, to handle semantic legal policies in compliance with emerging data protection laws, we use flexible relationship mapping between TLD and TVD layers. This allows us to enable/disable security and privacy policies dynamically in the TVD layer using self-managed LaaS.

The principles of using privacy protection laws in the cloud depend on three criteria [9]:

Currently, there is no consensus on which principles should be used for enforcing privacy protection laws in the cloud, especially across jurisdictions. In this paper, we offer LaaS for CSPs before deploying their cloud resources and allow them to choose flexibly any principles of the privacy laws with which they prefer to comply. We also ensure that all of the subsequent queries in the resources and services deployment cloud are compliant with the principles of selective laws. We manually unify semantic legal policies to avoid any possible conflicts of data disclosure and exchange across jurisdictions.

Whenever the laws used for regulating cloud computing are updated and expected to agree with the laws of different jurisdictions, semantic legal policies, modeled as a combination of revised ontologies and rules, are re-mapped to the updated security and data policies in Trusted Virtual Domains (TVDs). A TVD consists of a set of distributed virtual machines (VMs), storage for the VMs, and a communication medium interconnecting the VMs in the OpenTC [3]. A semantic cloud of TLDs is established over the OpenTC TVDs (see Figure 1). Therefore, we ensure that our law-aware semantic cloud policies are always compliant with the most up-to-date laws for cloud operations.

A Peer Data Management Systems (PDMS), such as PAYGO and Piazza, were demonstrated as the best way to achieve wide-scale data integration over the Internet [12,13,14]. However, the PAYGO and Piazza systems only use a relational data model that hampers our use of a conceptual-based for information sharing. Moreover, it is difficult to enact data sharing in a pure peer data integration architecture because of the difficulty of describing the nature of relationships among many unstructured peers. It is certainly a great challenge to provide unifying semantic legal policy services for effective data integration and protection in an unstructured peer data management system.

We propose an SPD model to allow for data integration and protection in a jurisdiction and furthermore to enable data exchange across jurisdictions. Within an SPD, a super-peer specifies its semantic legal policies based on a type of law to regulate a jurisdiction. Any peer registers at a super-peer, pledging to comply with a law declared as semantic legal policy in a super-peer for data integration. We also allow a super-peer to exchange data with another super-peer. This implies that when peers are affiliated with different super-peers, the semantic legal policies declared in these super-peers are unified to enact data exchange between these peers (see Section 6).

In terms of the data integration of multiple data sources, three approaches have been proposed to model a set of source descriptions that specify the semantic mapping between the source and global schema [15]. The first approach, called global-as-view (GAV), requires that each concept in the global schema be expressed as a query over the data sources. The GAV addresses the case in which a stable data source contains details not present in the global schema, so it is not used for dynamically adding or deleting data sources.

The second approach, called local-as-view (LAV), requires the global schema to be specified independently from the sources, and the source descriptions between the stable global schema, such as the ontology and the dynamic data sources, are established by defining each concept in the data sources as a view over the global schema [4,16]. LAV descriptions handle the case in which the global schema contains details that are not present in every data source.

The third approach, called global-local-as-view (GLAV), is a source description that combines the expressive power of both GAV and LAV and allows flexible schema definitions to be independent of the particular details of the data sources [17].

In this paper, on the one hand, data integration uses LAV and GAV mappings within an SPD to reformulate a user query into a query over the source schemas. On the other hand, data exchange between super-peers uses GLAV mappings between different SPDs. More specifically, in a data exchange setting a tuple generating dependency (tgd) for a set of source-to-target dependencies or an equality-generating dependency (egd) for target dependencies is extended to Datalog shown as a GLAV mapping [18]. However, data integration and exchange are hampered by legitimate and widespread privacy concerns. We need a technique that enables data integration and exchange without losing a user’s privacy [19,20]. An acronym table for frequently used terms are shown as Table 1.

Datalog is a database query language based on the logic programming paradigm: a set of ground facts, called the Extensional Database (EDB), is physically stored in a relational database, and a Datalog program P is called the Intensional Database (IDB). A Datalog program P is a mapping from EDB-facts to IDB-facts. Stratified Datalog^¬, which reduces data complexity and offers non-monotonic reasoning, is an extension of pure Datalog with rule stratification and negation [21].

The integration of ontologies and rules can be classified as heterogeneous or homogeneous [22]. Heterogeneous integration for hybrid reasoning is further distinguished as being loosely or tightly coupled. Description Logic Program (DLP) and Semantic Web Rule Language (SWRL) are examples of homogeneous integration, but they lack non-monotonic reasoning capabilities for policy exceptions handling. Therefore, we adopt one of the loosely-coupled approaches, i.e., conjunctive query programs (cq-programs), which is an extended version of a description logic program (dl-program), to design and enforce semantic legal policies [23].

The semantic legal policies are expressed as a cq-program, e.g., a pair (T , P), where T is the DL-based ontology and P consists of a finite set of non-monotonic datalog rules. A cq-rule has the form: (1)

where a is a rule predicate and any b₁, ..., b_m may be a DL predicate or a rule predicate.

The cq-program combines datalog rules with negation under stable model (or answer set) semantics with OWL DL. The difference between stable model semantics and well-founded semantics is that between two-valued (true or false) and three-valued (true, false, or unknown) logic. In practice, the two semantics coincide in the stratified logic program. Negation-as-failure (NAF) for weak negation (∼) in the closed world assumption (CWA) and explicitly negative knowledge for strong negation (¬) are allowed in the cq-program. In fact, Reiter-style default logic and CWA can be implemented in cq-programs to support non-monotonic reasoning of description logics [11].

Let Δ = (T , P, ≺) be a prioritized default theory, where T is the DL-based ontology in the cq-program of (T , P) and D = {δ₀, ··· ,δ_n} is a finite set of defaults with strict priorities. P consists of a finite set of non-monotonic datalog rules [24,25]. The normal default δ = is sufficient to model our exceptions, where φ is prerequisite, ψ is justifications, and ψ the consequent of δ in D. We apply the novel transformation Ω of default theories into cq-programs, which is based on the select-default-and-check principle. The evaluating extensions principle in default theories is: “If the prerequisites can be derived, and the justifications can be consistently assumed, then the conclusion can be concluded [23]”.

Example 3.1. The α Inc. is an international airline company with headquarters located in Singapore. The α airline Inc. applies the closed policies of privacy protection laws, where authorizations are denied by default based on the registration and nationality principles described in Section 1.2. The first policy exception, Ab1, states that no personal data should be disclosed unless a data owner’s prior consent is obtained.

Whenever a data disclosure request comes from a data owner’s national security officer, the open policies of the corresponding national security laws are applied, where authorizations are granted by default. As long as the officer follows legal procedure in supporting plausible evidence, this request is granted without the data owners’ consent. However, any national security officer cannot request an alien’s personal data unless the data owner’s prior consent was obtained. The second policy exception, Ab2, occurs in this situation.

The α airline Inc. pledges to follow Singapore’s data protection laws but allows data disclosure when any national security officer requests his/her own citizen’s flight information. An SPD_α is created for the α airline in compliance with Singapore’s data protection laws in TLD_α, where queries request data from the domain’s distributed data centers. Another SPD_β is created for national security officers of Taiwan CDC to enforce national security laws for a pandemic investigation, based on territoriality and nationality principles. A data disclosure exception, Ab2, is used for national security law enforcement when citizens are not Taiwanese nationals. Thus, these data cannot be disclosed unless a data owner’s prior consent was obtained. During the recent H1N1 pandemic period, a national security officer in Taiwan tried to trace the original H1N1 carriers who possibly took inbound flights from foreign territories, including Singapore, to Taiwan within the preceding fourteen days.

How do we unify the legal polices enforced in two different jurisdictions and avoid possible legal policy conflicts through exceptions handling? Furthermore, what level and range of data are permitted to be disclosed when either subject-or pattern-based queries (“Subject-based queries allow data users to query a specific person’s complete profile, while pattern-based queries allow data users to adopt a predicate model to create specific features that correspond to anticipated targets and find people with these features in the information space without disclosing their complete profile [8]”.) are initiated at a different super-peer?

In an SPD π_α, actual data are stored in a set of fragmented relational data sources DS_α = {ds₁, ..., ds_m}of a database. In an outsourcing database, the sensitive relationships (or properties) of the attributes in the tables are identified and segmented into fragmented data sources to ensure the data protection criteria are satisfied [31]. Using GAV local mappings, we associate a set of local peer P_α = {peer₁, ..., peer_n} in π_α with each individual ontology schema to the views of the related relational data sources, i.e., SQL queries. Furthermore, through LAV semantic mappings, a set of peers’ local ontology schemas are also mapped and aligned into a super-peer global view.

An SPD π_α ∈ Π can be defined as (P_α, SPD_α, GS_α, LS_peeri, M_α, DS_α):

When LaaS supports cloud resource deployment and queries across TLDs, the laws declared in each TLD are unified to comply with all TLDs. An SPD π_α of TLD_α is related to another SPD π_β of TLD_β using a set of super-peer GLAV semantic mapping assertions. A super-peer semantic schema mapping assertion between TLD_α and TLD_β is expressed as follows: (2)

where CQ_πα (sp_α) is a source conjunctive query over the sp_α in an SPD π_α ∈ Π; and CQ_πβ (sp_β) is a target conjunctive query over the sp_β in an SPD π_β ∈ Π.A CQ_πα (sp_α) is defined as an authorized legal view of an SPD π_α whenever the sp_α intends to export its data by unifying its semantic legal policies with another SPD π_β. The global schema GS_α of sp_α is mapped to another sp_β’s global schema GS_β by the super-peers’ GLAV semantic mapping assertions.

When queries go through the intersection of TLDs across law-aware super-peers, we manually unify the pre-arranged semantic legal policies to discover mapping assertions from the vocabulary of sp_α’s global ontology schema to the vocabulary of sp_β’s global ontology schema. Furthermore, potential policy conflicts between these unifiable semantic legal policies should be resolved with Datalog rules by policy exceptions handling. A semantic legal policy’s exceptions are handled by non-monotonic reasoning with stratified Datalog^¬ rules, as shown in Section 7.4.

Semantic data exchange between super-peers is the problem of taking a data structure under a source schema of a TLD_α and creating an instance of a target schema of a TLD_β that reflects the source data as accurately as possible. A semantic data exchange setting (S_α, T_β, Σ_st, Σ_t) consists of a source schema S_α, a target schema T_β, a set of source-to-target dependencies Σ_st, and a set of target dependencies is Σ_t Σ_st a tuple-generating dependency (tgd). This is a super-peer semantic schema mapping assertion between TLD_αand TLD_β, described as Formula (2) in Section 4.2. Moreover, each target dependency in Σ_t is either a tuple-generating dependency (tgd) or an equality-generating dependency (egd) [18]. Let Σ be a set of tgds over a fixed schema. A set of tgds is weakly acyclic if the dependency graph has no cycle going through dot-line special edges (see Figure 3 and Figure 4). This guarantees that the chase (or query) from target and source schemas will be terminated in polynomial time.

One of the source-to-target dependencies Σ_st from the source schema of personal flight information to the target schema of personal medical information is described as follows (see Figure 3):

A source-to-target dependency: (3)

A target dependency: (4)

A set of weakly acyclic target dependencies Σ_t from the target schema of InformedRecord to the target schema of PersonalMedicalInfo is shown as (see Figure 4):

In Section 3.1, we have proposed a pandemic investigation scenario, in which Taiwan CDC officers enforced national security laws to trace the original source of H1N1 carriers, who possibly took inbound flights from a recent pandemic area. We first query the target schema of a personal medical information ontology using Formula (4). It is weakly acyclic; thus, the chase procedure for personal medical information with H1N1 disease will be terminated in polynomial time. Then, we query the instances of personal flight information at the source schema through the source-to-target dependency _stdescribed by Formula (3). Semantic data exchange services ensure that both semantic data interoperability and law-compliant criteria are satisfied at the virtual legal domain created for the super-peer sp_α∩β, where a law-aware guardian agent_α∩β at the sp_α∩β is empowered by unifying the semantic legal policies offered by agent_β and agent_α from their respective sp_β and sp_α nodes. For more details see Section 6.

A formal (semantic) legal policy is a declarative expression executed in a computer system for a human legal norm without causing semantic ambiguity. A legal policy is created from a policy language, and a legal policy language is expressed as a combination of ontology and rule languages. A legal policy is composed of ontologies and rules, where ontologies are created from an ontology language to express the domain concepts of a policy and rules are created from a rule language to express the enforcement of a policy.

Furthermore, a legal protection policy is a legal policy that aims at representing and enforcing the privacy protection principles of resources in the semantic cloud, where the structure of resources is modeled as ontologies and the protection of resources is expressed as rules. The privacy policy model used for access control in enterprises has been extensively investigated [33], where only Logic Program (LP)-based Datalog was used to design the privacy policy. A global policy schema allows for data integration by unifying regular policies from a variety of structured data sources, where the global policy schema includes integrated ontologies and rules.

When rules specified as stratified Datalog with negation are used for non-monotonic reasoning rules, the research challenge is determining how to integrate two families of logic i.e., DL and LP, for semantic legal policy enforcement under a non-monotonic semantics. Expressiveness is not the only issue because hybrid integration usually involves high computational complexity. It is also important to ensure the appropriate hybrid integration of ontologies and rules to design policy languages for privacy protection policies. Unfortunately, this issue has not yet been completely studied [5].

Legal policy compliance addresses the issues of data access and service execution in the semantic data cloud. Semantic legal policy enforcement should satisfy up-to-date laws within a jurisdiction. However, resources, data, and services in the cloud are usually dispersed throughout the Internet. Anyone, if authorized, should be allowed to request anything from anywhere at any time. In this case, we might have to regulate a data request by unifying laws across jurisdictions. This raises the regulation compliance issue regarding how to ensure that semantic legal policies, which satisfy the data usage context, are correctly enforced.

A data usage context is created for each user. It is a precondition when applying laws for a query in a TLD. In the policy ontology described in Figure 2 in Section 4, whenever the concept of a data usage context is subsumed by a domain policy’s context, this data request enters a specific TLD. We comply with the laws of a domain policy because the subsumption criteria of a data usage context are satisfied. After a domain policy is chosen, an applicable data policy belonging to this TLD is initiated to enable real data access. However, this data usage is only used for a single TLD.

When data are used across jurisdictions, such as at the intersection of data protection and national security TLDs, we need an iterative legal policy enforcement process to achieve the selective revelation of anonymous personal identifiable information (PII). This is a pattern-based query, which is only allowed at the intersection of two SPDs. It has been unusually challenging to build a legal framework for protecting individual privacy in the struggle against terrorists since the 9-11 terrorist attack on the U.S. [8,34]. The wide distribution of cloud computing services will certainly exacerbate this challenge. We attempt to address this research issue and provide one possible solution based on semantic legal policy enforcement.

A peer p_i should register at the sp_α before this peer can offer its data for integration in an SPD_α, This registration action implies that p_i pledges to obey the privacy protection law by applying specifications of the data usage context declared in the sp_α.

Based on this data usage context specification, p_i uses the LAV source description to export its data to sp_α for data integration. Peer p_i also registers at another SPD_β, shown as TLD_β and exports its data for national security policy enforcement purposes. This indicates that the laws from sp_α and sp_β, which are privacy projection and national security legal policies, respectively, are unified and enforced after collecting data from p_i.

An open cloud is sometimes constructed as a virtualization-layered architecture for multi-tenant services. A peer is a virtual node within an SPD, and corresponds to a database installed in virtual machines (VMs). We might face a situation, where a database is compliant with a data protection law α from one jurisdiction but a data center providing VMs to host the database is compliant with a national security law β from another jurisdiction. This multi-tenant cloud service layout is different from that of Gmail and Facebook, where the cloud management services of data centers and databases belong to a single legal authority.

One possible solution to this legal discrepancy is to enact a service level agreement (SLA) between owners of a database and a data center before the database is installed in the data center’s VMs. The SLA provides the necessary information for a database owner to ensure that he/she is aware of this legal domain discrepancy. Another possible solution for preserving privacy in data outsourcing is to enforce privacy over data collections by combining data fragmentation with encryption to avoid illegal data usage requests from curious but honest cloud providers [31]. For more details, see Section 7.1. Unless national security law enforcement officers comply with the SLA and national security laws, any data disclosure request made without a data owner’s prior consent will be rejected.

Based on the above proposition, we propose a solution by unifying legal policies submitted by different judicial authorities. On the one hand, when an end-user requests for data exchange from the TLD_α∩β, two types of legal policies, e.g., privacy protection and national security, from different judicial domains are unified to legally restrict data exchange access at p_i. On the other hand, when an end-user requests data from sp_α or sp_β separately, we do not unify legal policies in this situation; therefore, one type of law is applicable for a data request.

In Figure 5, an agent_α in TLD_α enforces privacy protection law, and an agent_β in TLD_β enforces national security law. When a data usage context satisfies the conditions of national security law enforcement, such as a data user’s role as a national security officer, a data owner’s consent is absent, and the purpose of data disclosure falls on national security; then, we enter the TLD_α∩β legal domain for data exchange. We model the enforcement of national security law as the privacy policy’s exceptions. Whenever a national security officer queries data at the sp_α∩β, the nationality principle shown in Section 1.2 allows another jurisdiction’s privacy protection law to bend. However, only the anonymous PII are disclosed because we still have to somehow ensure that the privacy protection law α is not violated. This approach balances personal privacy rights and national security needs in the cloud.

We manually unify two types of legal policies, which are translated from privacy protection law and national security law to demonstrate how data are collected from peers who have been registered at the sp_α∩β. Two types of queries are available subject-and pattern-based queries, where a subject-based query allows us to access a specific data owner’s complete profile. Conversely, a pattern-based query does not have specific access targets, so only data that satisfy pre-defined filtering conditions are disclosed.

At the sp_α∩β, we only provide pattern-based queries. This is in contrast with the queries provided at the sp_α and sp_β, where we provide both. Similar to the privacy appliance [8], a trusted agent_α∩β at the sp_α∩β is a guardian, who follows the laws and provides privacy protection and national security legal services while disclosing data from its registered peers within TLD_α∩β.

In summary, we manually unify privacy protection legal policies with national security legal policies at the intersection of TLDs while enforcing data exchange. This is not only to ensure privacy but also to encourage sharing data for national security purposes without the fear of privacy rights being violated.

In this section, we demonstrate direct mapping from fragmented relational database tables to modular sub-ontologies in an outsourcing semantic data cloud. This prevents an illegal data request from curious but honest cloud providers. Whenever a data request is permitted by the LaaS, we ensure that this request is satisfied with the data protection criteria declared by data owners.

The relational database tables are first normalized using ordinary database techniques, e.g., first normal form (1NF), second normal form (2NF) [36]. The normalization technique reduces the number of duplicated tuples in the table. Then, the relational database tables are fragmented and mapped into a putative ontology (see Figure 6). In Figure 7, tables in a SQL schema are directly mapped to the Semantic Web’s putative ontology. The fragmented putative ontology of medical information is shown as a combination of modular sub-ontologies that are created from the relational database fragmented tables (see Figure 8).

At the sp_α of an SPD_α, we provide a data request service through the semantic data integration of modular sub-ontologies [30]. Once the LaaS verifies this request and grants a permission, a link ontology is used to integrate the modular sub-ontologies. Semantic reasoning is performed from a link ontology to rediscover the sensitive relationships from previous modularized but fragmented sub-ontologies. Finally, a semantic data exchange service is provided by the guardian agent_α∩β to achieve data exchange and protection across SPDs (see Section 6.2).

A legal policy (T , P) is composed of ontologies T and rules P, where ontology predicates are exported to the rules with the namespace indicator t to declare the original ontological predicate source. However, each rule still has its own predicates with the namespace indicator p. Based on the policy ontology described in Section 4, when a data request ?r with data usage context ?c satisfies a DomainPolicy(?dmp)’s data usage context ?dmc, this data request from a data user is allowed to enter the TLD(?tld) and enforce a data policy with operations on the PII dataset (see Rules 5 and 6).

In the pandemic investigation scenario presented in Section 3.1, under normal conditions, we enter sp_α in the SPD_α for subject queries as follows:

• A partial ontology for a domain policy:

The above two expressions indicate that property hasTLD has the domain of a class DomainPolicy and the range of a class TLD. Similarly, the hasCondition, hasPartOf, and other properties are as follows:

This part of the ontology indicates that each SPD has only one super-peer and at least one peer. In addition, all peers must register at a super-peer.

• Rules for a domain policy enforcement:

Rule (5) provides a concept link between an abstract TLD and a concrete SPD. In Rule (6), we determine whether a SPD should handle a data request based on this data request usage context, which is subsumed by a domain policy’s context.

(5)

(6)

In a predicate p : isSubsumedByDefault(?c, ?dmc) of Rule (6), the concept subsumption criteria is verified to determine whether a data request, with its structure condition attributes ?c is subsumed by the criteria of a domain policy context. In fact, each attribute is defined as a conceptual graph; therefore, the subsumption verification of each concept criterion is transformed into a conceptual graph-covering problem. This data request is granted only if the domain policy’s conceptual graphs include the graphs of all of the request’s attributes. Otherwise, it is rejected.

We do not address this issue further because the complex data structure of condition attributes must be modeled as function symbols for manipulation. However, the function symbols used in the datalog fragment usually introduces undecidable computation [11].

Instead, the default concept for condition ?c with any abnormal attribute subsumption will be verified through default logic to determine whether a data request with any abnormal condition Ab in ?c is subsumed (or defeasibly inherited) by the defaults in ?dmc within a domain policy. For more details about default reasoning, see Section 7.4. We allow a data request ?r using the PII ?pii of personal information as follows (see Rules (7–10)).

• A partial ontology for a data policy, which describes the concept of personal flight information available for user querying from the super-peer in an SPD:

• Rules for a data policy enforcement: (7) (8) (9) (10)

In formalizing access control policies, we may confront a situation in which a given request is neither explicitly allowed nor explicitly denied. A default decision must be made, as in the default open and closed policies, where authorization is respectively granted or denied by default.

The layers induced by Datalog stratification may be regarded as the steps of a methodology for constructing open policies in a principled way, starting with explicit authorizations, unless exception occurs, and adding derived authorizations through inheritance along hierarchies of subjects, objects, purposes, and rules. This approach can clearly implement defeasible inheritance, as shown in Section 7.4.

In general, the computational complexity of DL non-monotonic reasoning is very high, and the major DL reasoning engines do not support non-monotonic reasoning [5]; therefore, we apply stratified Datalog^¬ to address defeasible inheritance when semantic legal policies are unified in the sp_α∩β of SPD_α∩β.

Once a Taiwan national security officer enters an SPD_α∩β, he/she must simultaneously comply with Singapore data protection laws α and Taiwan national security laws β. Here, we apply stratified Datalog^¬ in Rule 6 of Section 7.2 for policy exceptions handling to comply with both of the above-mentioned two laws. In closed-world-assumption (CWA) semantics, the absence of consent is a weak negation (∼), indicated as false, e.g., ⊥.

We demonstrate how two exceptions (strata) are applied for possible dataset disclosure. In stratum one, according to the closed data protection policy, we do not disclose the personal dataset A to a data user u unless a data owner’s explicit prior consent for a particular purpose p was obtained. In fact, this is the original principle of the data protection policy.

In Rule (6) of Section 7.2, an abnormal data request’s condition ?c = Ab1 in t : hasCondition(?r, ?c) and t : Condition(?c) can be indicated as follows:

In stratum two, we apply the default open national security policy to disclose the dataset C to Taiwan national security officers, even if we lack a data owner’s explicit prior consent, i.e., weak negation (∼) indicated as ⊥. However, we deny the Taiwan national security officer’s request to disclose the dataset D for alien citizens, e.g., strong negation indicated as _¬TW − citizenship. Therefore, under Taiwanese national security laws, data will be legally disclosed unless a data request has its condition attributes satisfied by Ab2. Similarly, an abnormal data request’s condition ?c = Ab2 can be indicated as follows:

In Section 2.4, we show that Reiter-style default logic can be implemented in cq-programs to support non-monotonic reasoning of description logics. Furthermore, a prioritized default theory Δ = (T , D, ≺) resolves possible default reasoning conflicts from a finite set of prioritized defaults in D. T is the DL-based ontology in the cq-program of (T , P) and P consists of a finite set of non-monotonic datalog rules (see Section 2.5).

In (11), DL-based T_α ontology describes what is the concept of a disclosed PII_B set that satisfies a data protection policy (see Figure 9). PII_disclosure and PII_¬disclosure are mutually exclusive.

(11)

(12)

On the one hand, an individual’s PII, unless specified as an exception, is normally in a _¬disclosure PII_A set by a closed data protection policy’s assumption in TLD_α [see default δ₀ in (12)]. P_Ωα consists the following single rule for δ₀:

(13)

In a nutshell, a cq-program provides two way information flow between ontologies and rules in the integrated knowledge base. A default δ₀ can be enforced as Rule (13), where DL[λ; PII_A](?pii) is a cq-atom with input list of update predicate λ and PII_A is a cq-query. Auxiliary predicate in_{PII¬disclosure} (?pii) is used in λ. λ = PII_¬disclosure ⊎ in_{PII¬disclosure} ∧ PII_¬disclosure in_{PIIdisclosure} is the update list of form PII_¬disclosure in T_α, where ⊎ (resp., ) increases PII_¬disclosure (resp., PII_disclosure). The answer set is I_ωα = {in_{PII¬disclosure(Alice)}}

Whenever we successfully enforce a closed data protection policy, an individual’s PII is included in a ¬disclosure set, PII_B. Otherwise, it is still in a _¬disclosure set, PII_A. We add the following Rule (14) in P_Ωα to achieve this objective: (14)

where Action_{ConditionCheck(Ab1,?pii)}(T) is to verify whether a request with its carrying context satisfies the Ab1 by checking against some facts present at the beginning of the reasoning process in the knowledge base, which are fed by external mechanism. The default extension answer set is I_ωα = {in_{PII¬disclosure(Alice)} , in_{PIIdisclosure(Bob)}}.

In (15), DL-based T_β ontology describes what is the concept of a not disclosed PII_D set that satisfies a national security policy.

(15)

(16)

On the other hand, an individual’s PII, unless specified as an exception, is normally in a disclosure PII_C set by an open national security policy’s assumption in TLD_β (see default δ₁ in 16). P_Ωβ consists the rule for δ₁: (17)

A default δ₁ can be enforced as Rule (17), where DL[λ; PII_C](?pii) is a cq-atom with input list of update predicate λ and PII_C is a cq-query. Auxiliary predicate in_{PIIdisclosure} (?pii) is used in the input list of auxiliary predicate λ. λ = PII_disclosure ⊎ in_PIIdisclosure ∧ PII_disclosure in_PII¬disclosure is the update lists of form PII_disclosure in T_β, where ⊎ (resp., ) increases PII_disclosure (resp., PII_¬disclosure). The answer set I_ωβ = {in_{PII¬disclosure(Alice)}}

Whenever we enforce an open national security policy with the satisfaction of Ab2, an individual’s PII is included in a _¬disclosure set, PII_D. Otherwise, it is still in a disclosure set, PII_C. We add the following Rule (18) in P_Ωβ to achieve this objective: (18)

where Action_{ConditionCheck(Ab2,?pii)}(T) is to verify whether a request with its carrying context satisfies the Ab2 by checking against some facts present at the beginning of the reasoning process in the knowledge base, which are fed by external mechanism. The default extension answer set is I_ωβ = {in_{PIIdisclosure(Alice)} , in_{PII¬disclosure(David)} }. We have default extension conflict in I_ωα = {in_{PII¬disclosure(Alice)} , ···}and I_ωβ = {in_{PIIdisclosure(Alice)} , ···}. Strict priority ordering defaults resolve this PII disclosure conflict while enforcing different default extension logic reasoning. In this study, the priority order is compliant with the national security policy, which is prioritized over the data protection policy; thus, we have δ₁≺δ₀. Therefore, PII_{¬disclosure(Alice)}∈ I_ωα is false. It is impossible to have an individual’s PII in a disclosure set and a ¬disclosure set after default extensions are complete.

LaaS has been successfully implemented in semantic policy infrastructure to verify this concept (see Figure 10). Semantic legal policy enforcement is the mapping from a data usage context to access control decisions, including permit, deny, and error. A data usage context comprises a user’s role along with his/her personal properties, resources metadata, access time, access location, purpose, and action. A data usage context is created when a user asks for information at the super-peer. A user’s inputs for information queries constitute data usage context, i.e., sets of ground facts (or instances) fed into the policies for outputs. The possible outputs from the semantic legal policy reasoning are sometimes more than simple answers like yes, no or unknown. They might provide explanations for query results.