Policy-Based Dissemination of Partial Web-Ontologies - CiteSeerX

Policy-Based Dissemination of Partial Web-Ontologies

∗

Saket Kaushik [email protected]

Duminda Wijesekera [email protected]

Paul Ammann [email protected]

Center for Secure Information Systems Department of Information and Software Engineering George Mason University Fairfax, VA 22030

ABSTRACT Traditional discretionary access control, without data alteration operators, applied directly on ontologies can result in revealing unintended information because ontologies contain meta-information about objects. As an alternative we provide a constraint logic programming based policy language that can extract, remove or desensitize sensitive concepts in ontologies prior to requested disclosures. Our policies are stratified Horn clauses with constructive negation, and our constraint system uses a finitary system of ZF sets developed by Dovier et al. - and consequently, admits a threevalued Kripke-Kleene semantics. Consequently, it is suitable for safeguarding meta-information stored on the Semantic web using OWL. We show how our three-valued semantics faithfully represents traditional OWL semantics. Categories and Subject Descriptors: C.2.0 [Computer and Communication networks]: General–Security and Protection;

rized. For defense co-operation on a specific weapon, say ‘Rocket Launcher’, this ontology may be shared with collaborators. However, sharing the complete ontology can cause a security breach, as highly sensitive information regarding the organization of nuclear warheads is revealed. If access to each object (here a weapon) is regulated, then the relationships between objects are lost. In addition, an access control policy may specify that a subset of concepts of the ontology has to be hidden, but overall structure of the ontology may be disclosed. For instance, in the weapons ontology, the concept ‘Nuclear Warhead’ could be sensitive to disclosure to some requesters, however, all other concepts and relationships can be disclosed to them. Currently, to the best of our knowledge, there are no formal frameworks to provide disclosure control over parts of an ontology based on the requestors attributes and grantors policies. This paper provides such a framework where policies are stratified Horn clauses using a finitary set constraint domain.

General Terms: Security

Weapons

Keywords: Access control, Inference control, OWL, Ontology, Policy, RDF, constraint logic programming.

1

The semantic web shares meta-information about objects available for machine processing using languages like the Web Ontology Language (OWL) [19]. OWL describes meta-objects, their attributes and relationships among objects that are typically exchanged between producers and consumers of objects - a.k.a. resources available on the web. Such meta-information is mostly expressed as a graph, whose nodes are concepts and arcs are properties, using the resource description framework or RDF(S) [17, 4]. Discretionary access control models applied to ontologies that contains several grades of sensitive information, either leak sensitive information, or fail to capture important relationships between objects. For example, consider a weapons ontology (see figure 1 and [22]) containing detailed descriptions of weapon systems and how they are catego∗ This project funded in part by the National Science Foundation under grant CCR-0208848

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SWS’05, November 11, 2005, Fairfax, Virginia, USA. Copyright 2005 ACM 1-59593-234-8/05/0011 ...$5.00.

Special Weapon

Conventional Weapon

Introduction Rocket Launcher

Size

Machine Gun

Rounds

Delivery System

Nuclear Warhead

Trigger Mechanism

Figure 1: A simple weapons ontology graph

Ontological design is guided by principals like clarity, coherence, extensibility, minimum commitment etc. (See [15]). A naive solution to the disclosure control problem is to design ontological fragments that satisfy every permissible access - and thereby incorporate disclosure control requirements in the design of the ontology itself. However, this is counter productive, as it interferes with extendibility and produces multiple versions of the original ontology, thereby giving rise to known difficulties of version control and meta-data replication. Secondly, change propagation overhead in the event of ontological updates for every maintained version of the ontology can be excessive. Finally, a change to the disclosure scheme may require creation of a new version of the original ontology. Clearly, ontology disclosure scheme must be separate from the ontology itself, so that any change in the disclosure scheme does not affect the original ontology.

1.1

Our contribution

The main contribution of this paper is a policy-based disclosure control framework for safe sharing of sensitive ontologies. Our approach can prevent disclosing sensitive portions of an ontology, selectively hide names of concepts and/or relationships while disclosing the overall structure of the ontology, and replace them with desensitized names - thereby allowing the access controller to spread deceptive information or cover stories to requestors with known attributes. Our framework is based on constraint logic programming (CLP) based scheme with set constraints of a computable set theory, referred to as Set in [11]. Our system-defined predicates contain all the requisite logic and as a result, user defined policy rules are reduced to simple, non-recursive predicate definitions. However, our policy language can be easily extended to give greater control to an advanced user. The rest of the paper is organized as follows. In § 2 we start with the preliminaries on OWL and RDF and give a brief overview of our approach. Next we encode an RDF Graph as a Set to be used in our model. § 3 details the formal model and syntax. This is followed by § 4 which provides the semantics that we use to interpret our programs.

2

Overview

Our framework provides secure policy-based dissemination of ontologies for the following use-cases. • An actor may obtain access to parts of an ontology based on his or her attributes. • An actor may obtain the ontological structure, but not the names of the concepts and properties, based on his or her attributes. Attribute based access control (see [25]) has been widely studied for the purpose of dissemination of information over the web. Here, we design a simple scheme that uses the same paradigm for controlling disclosure of ontological information. In our scheme, requester’s attributes are modeled as a set. We provide a basic algebra over the ontologies to control accesses for parts of ontologies. Our results prove our claims regarding the protection achieved. As a theoretical framework to address these problems, we provide a constraint logic programming (CLP) based framework, in which policies are CLP programs that control the dissemination of portions of web ontologies. Our syntax is based on locally stratified Horn clauses with constructive negation [7]. We use the CLP(SET ) set theory developed by Dovier et al. [11]. OWL’s syntactic and semantic entities form the syntactic entities in our model. We give a suitably tailored three-valued [13] semantics to our programs and show that it faithfully models OWL semantics. 2.1

Preliminaries

Meta-information represents knowledge based on a conceptualization of the area of interest. A conceptualization is an abstract view of the objects, concepts, and other entities in the restricted universe of interest and the relationships between then. An ontology is an explicit specification of a conceptualization [15]. In the semantic web, a layered architecture [6], also known as ‘the cake’, is used to express meta-information. This architecture consists of a stack of web languages. The lowest layer of this stack is Unicode/URI layer on which the XML and xmlschema are built. The next layer has RDF(S), which defines both the syntax and semantics of subsequent layers. All the upper layer languages (like OWL etc.) are built on top of RDF(S).

2.1.1 RDF(S) RDF(S) or RDF Schema is RDF’s vocabulary description language. It provides mechanisms for describing groups, called concepts through the rdfs:Class tag, and the relationships between these resources, called properties through rdf:property. RDF(S) vocabulary descriptions are written in RDF using a set of language primitives presented in [5]. In summary, these include classesrdfs:Datatype, rdfs:Literal, etc., properties and their instances – rdfs:subClassOf, rdfs:domain, rdf:type, rdfs:range etc. RDF(S)’s only syntactic construct is an RDF triple discussed next. The domain of syntactic elements is represented by IR. Each RDF(S) resource (i.e., individual, class, property, or language primitive) is a member of V, the vocabulary. The syntax consists of subjects, objects and properties, which are required to be arranged in triples. Subjects and objects are ontological concepts, instances of concepts, language primitives or properties. A property is a binary relation between any two elements in IR. The semantics of resources are given by their extensions, the set of the instances of the resource that includes the resource as well. Next we repeat the definitions of relevant RDF(S) elements and their semantics as presented in the literature (for further reading see, for example, [14]). Definition 1 (RDF(S) Preliminaries). Key RDF(S) concepts are as follows: RDF Domain The RDF Vocabulary V is a set of names (URIrefs). The RDF domain is a non-empty set of constants, referred to as IR. V ∩ IR = ∅. A mapping IS: V 7→ IR maps each element of V to IR RDF Triple and RDF Document The RDF syntax is composed of triples hS, P, Oi, where S is a subject, P a property, and O an object. An RDF document is an unordered set of RDF triples. The set of objects in IR that occur in the second position in an RDF triple in a document is referred to as IP, the set of properties. RDF Graph [17] An RDF graph (a.k.a. graph) is a set of triples. RDF extensions A mapping, IEXT, relates each resource to its extension: IEXT: IR 7→ IR × IR. RDFS semantics (R) [20, 14] RDFS interpretation is a triple hIR, IEXT, ISi. Every r ∈ IR has an interpretation, given by its extension IEXT(r). 2.1.2 Our Approach RDFS syntactic and sematic entities are mapped to syntactic entities in our model. We disallow self-references and cyclic references for a standard first order logic semantics. Sub-languages of RDF(S) like RDFS-(FA) [20] or RDFS(DL) [14] are possible candidates, however, we do not go into their specifics here. The formal model is presented later in § 3. We use sets to model RDF triples and RDF Graphs, and call them RDF Trees. This is because of the following reason. Even though the expressive power and computational complexity of LIST [11] is the same as SET [11], the List theory [11] lacks the permutativity axiom. This is significant because the order of elements is respected for equality of lists, whereas order among objects related to the same subject in an RDF graph is irrelevant. A mapping of the ontological and RDF elements to elements in our model in presented in table 1. Encoding an RDF graph as a set We use von Neumann’s standard set encoding [16] to encode RDF triples as sets. A pair hA, Bi is encoded as {A,{A,B}}. A triple hA, B, Ci is encoded as {A,{A, hB, Ci}}, i.e., {A,{A,{B,{B,C}}}}. Consider an RDF triple hS,P ,

Ontology Element Ontological concept Individuals Relation and Function

RDF/OWL Element owl:Class rdf:type rdf:Property owl:ObjectProperty owl:DataTypeProperty .. . rdfs:domain rdfs:range RDF property Name = N

CLP Predicate Concept(A) Inst(A,B) Prop(A,B,P)

Prop(A,B,P) Prop(A,B,P) Prop(A,B,N)

Table 1: CLP modeling of web-ontology elements

Oi. We represent this triple by the set {S,{S,{P,{P,O}}}}. Consider another triple hS, P 1 , O1 i, i.e., S occurs as a subject in another RDF triple. The set encodings of the two RDF triples can be merged as {S,{S,{P,{P,O}}}, {S,{P1 ,{P1 ,O1 }}}}. Now consider a triple hO, P 2 , O2 i where O occurs as the subject. This set encoding of this triple can also be merged in the earlier encoding, i.e., the new encoded set is {S,{S,{P,{P,{O,{O,{P2 , {P2 ,O2 }}}}}}}, {S,{P1 ,{P1 ,O1 }}}}. By recursively analyzing each triple in a document, a set representation is built for RDF triples. Thus, an RDF graph is directly mapped to a set, i.e., an RDF Tree. The element of the tree occuring only as a subject in any of the triples represented by that tree is called the root of the tree. A subtree S of an RDF tree T is an RDF tree such that there exists a property P that relates the root of S to one of the concepts in T, and all triples represented by S are also represented by T. A more formal definition of subtree is presented later. We define two functions and a relation on an RDF tree, namely, Root, Property and Element, respectively. For any tree, T, Root(T) maps T to the root of the tree. If T is a subtree of a tree, say N, then Property(T) maps T to the property, say P, that relates it to N. Element(T) relates T to a non-root element of T. Definition 2 (RDF Tree). An RDF Tree is a set T such that for a set of triples, Tr ∈ D, ∀ hS, P, Oi ∈ Tr ∃ t ∈ T such that the objects Root(t), Property(Element(t)) and Root(Element(t)) = hS, P, Oi. Notation 1 (Membership notation). To denote membership of an RDF Triple in a tree, we use the notation t  T, where t is an RDF Triple encoded in an RDF Tree T. t 6 T is used to indicate that t is not encoded by T.

Definition 3 (Subtree). A subtree of a tree T is a tree Ts such that Root(Ts ) = Root(Element(T)) and ∀ t  Ts , t  T also holds, for some Element(T) or Ts is a subtree of some Element(T). Notation 2 (Subtree notation). To denote subtree of an RDF Tree, we use the notation Ts º T where Ts is a subtree of an RDF Tree T.

{Weapons,{Weapons,{sc,{sc,{Conventional Weapon}}}}, {Weapons,{sc,{sc,{Special Weapon}}}}} Conventional Weapon above can be replaced by: {Conventional Weapon, {Conventional Weapon, {sc, {sc, {Rocket Launcher}}}}, {Conventional Weapon, {sc, {sc,{Machine Gun}}}}} Rocket Launcher above can be replaced by: {Rocket Launcher,{Rocket Launcher,{sc,{sc,{Size}}}}, {Rocket Launcher,{sc,{sc,{Rounds}}}}} Special Weapon above can be replaced by: {Special Weapon, {Special Weapon, {sc, {sc,{Nuclear Warhead}}}}} Nuclear Warhead above can be replaced by: {Nuclear Warhead,{Nuclear Warhead,{sc, {sc,{Delivery System}}}}, {Nuclear Warhead,{sc, {sc,{Trigger Mechanism}}}}}

... Figure 2: A simple weapons ontology document

2.2 Protection cases We demonstrate the protection cases using the example ontology pictured in figures 1 and 2. Our method enables two use-cases for secure access. Each of the use-cases involves introduction of tree operations on ontology trees. We discuss the use-cases and the operations next.

Definition 4 (Ontology Tree). An ontology tree is an RDF Tree such that it is not the subtree of any tree in D, the RDF Document. +

Definition 5 (RDFS extended semantics (R )). An extended RDFS interpretation is a triple hIR, ITREE, ISi where ITREE is a mapping: 2IR 7→ 2IR .

Lemma 1. R ⊆ R

+

¤

As an example of the set mapping, consider the modified ontology from [22] pictured in figure 1 and the associated RDF file in figure 2. For simplicity we assume that the concepts are only related through the rdfs:subClassOf property, ‘sc’ in short, and therefore each edge label is ‘sc’ (omitted in the figure). The corresponding ontology tree is given below. Due to space constraints it has been split into subtrees or triples.

Use Case I: Disclosure control over portions of an ontology tree. We define three excision operations on a tree to achieve disclosure control as follows. 1. Subtree removal 2. Branch removal 3. Subtree extraction Use Case II: Content obfuscation in an ontology tree. We define two renaming operations on a tree to achieve content obfuscation as follows. 1. Node hiding operation 2. Node modification operation

2.2.1 Disclosure control over portions of an ontology As a first case, consider a requirement where an ontology is used to encode and share taxonomic information. It is possible that classes or concepts close to the root of the tree are general in nature and are not considered sensitive. However, nodes below the root and other higher-level nodes may be considered sensitive and need protection. For example, in figure 1, information regarding nuclear warheads can be sensitive and must be protected from public disclosure. Therefore, when providing information about weapons ontology, the portion of the taxonomy concerning nuclear warheads must be removed. We call this the subtree removal operation, pictured in figure 3, where the disclosed portion of the ontology tree is shown. Since the subtree to be removed may be related to the rest of the tree by more than one property, this operation is designed to remove all occurrences of the subtree in the set encoding of the original tree. The subtree removal is modeled by remSubtree predicate, which is defined in § 3. Weapons

Remove subtree

Conventional Weapon

Rocket Launcher

Size

The third operation is the subtree extraction operation. This operation is useful in scenarios where only parts of an ontology must be disclosed to a requester. Consider, for example, the scenario where compartmentalization among various departments of an organization is required. Following the weapons ontology example, compartmentalization between conventional weapons department and special weapons department can be easily achieved by subtree extraction. As shown in figure 4, each request originating from the conventional weapons department is only allowed information from the conventional weapons subtree in the original tree. Subtree extraction operation is modeled by the subtree predicate defined in the next section. 2.2.2 Content obfuscation in an ontology tree The first operation introduced is the node hiding operation. In this operation, we rename the label of a node in a tree with the RDF-reserved no name element to hide the name of a concept, as shown in figure 5. A special individual, called no-name-inst, is the instance of no name concept. By changing the label of a sensitive concept and its instances, the sensitive information can be effectively controlled. For instance, by using no-name in place of ‘nuclear warhead’ in figure 5, we avoid disclosure of the type of special weapon being discussed. However, we are still able to disclose that the hidden weapon has a delivery system and a trigger mechanism. This operation is modeled by hideConcept predicate in our model.

Machine Gun Weapons

Special Weapon

Conventional Weapon

Rounds

Figure 3: Subtree Removal

The branch removal procedure is a minor modification of the subtree removal procedure. In this operation, only one subtree (or a branch) of the original ontology is removed. For instance, a security requirement can state a relation between ‘Nuclear warhead’ and ‘Trigger mechanism’ has to be protected from a class of requesters, however, relationships of ‘Trigger Mechanism’ with other concepts is allowed. As a triple is encoded only once in an RDF tree, the branch removal procedure looks for a single occurrence of the specified triple and removes it. In addition, if an ontology consists of only one subtree that needs to be removed, branch removal can accomplish the task more efficiently than the subtree removal procedure. Branch removal operation is modeled by remBranch predicate defined later in § 3. Extract subtree

Conventional Weapon

Rocket Launcher

Size

Machine Gun

Rounds

Delivery System

Name hidden NO NAME

Trigger Mechanism

Figure 5: Hiding a node

The second operation, called node modification operation, is a slight mutation of the node hiding operation. Here, the label of the node is changed to a new value. For example, in figure 6, the label ‘Nuclear Warhead’ is renamed to ‘Warhead’, a less sensitive label. In this particular example, the effect of the modification operation is similar to the hiding operation. However, depending upon the renaming used, it is possible to modify an ontology as required. For example, military applications may require deceptive information be released (an additional precaution for protection of sensitive information). This can be achieved by the node modification operation, modeled by modifyConcept predicate in our model.

3

Formal Model

3.1 Syntax

Rocket Launcher

Machine Gun

Definition 6 (Terms). Terms consist of arbitrary constants, C, function symbols, F, which includes the two functions {· | ·} and nil, and a set of variables, V, ranging over the constants. Given a term t, FV(t) is the set of all variables that occur in t.

Size

Rounds

Figure 4: Subtree Extraction

We assume that the constants contain a reserved symbol no-name ˜ represents sequences of terms. abbreviated as N . Notation X

Symbol

Weapons

Rocket Launcher

Size

Concept(X) Inst(A,B) Prop(A,B,P)

Special Weapon

Conventional Weapon

Delivery System

Rounds

allI(a,B)

Trigger Mechanism

subtree(A,B,C) remSubtree(A,B,C) remBranch(A,T,C)

Figure 6: Modifying a node

Definition 7 (Constraint domain). Set constraint domain, referred to as SET in [11], over a set of arbitrary constant and function symbols in the domain. SET interprets the predicates =, 6=, ∈, 6∈.

The set {A | {B | · · · {S | T} · · · }} will be denoted by {A,{B,. . ., {S|T}· · · } or simply by {A,{B,. . . ,{S}· · · } when T is nil. The constraint domain ensures the following identity axioms [11]. Axiom K. (x 6∈ f (y1 , . . . , yn ))

Modification predicates (MP) 3 C is the tree A such that each node B in A is renamed to N modifyConcept(A,B,C,D) 4 D is the tree A such that each node B in A is renamed to C

f ∈ F , f is not {· | ·}

Axiom W. ∀yvx

Suspicious(A) Citizen(A) Secret(A) TSecret(A)

(x ∈ {y | v} ↔ x ∈ v ∨ x = y)

Axiom Ep (Permutativity). ∀xyz

{x, y | z} = {y, x | z}

{x, x | z} = {x | z}

Axiom Ek (Equality/Disequality).  {y1 | v1 } = {y2 | v2 } ↔ (y1 = y2 ∧ v1 = v2 )∨   (y1 = y2 ∧ v1 = {y2 | v2 })∨ ∀y1 y2 v1 v2   (y1 = y2 ∧ {y1 | v1 } = v2 )∨ ∃k(v1 = {y2 | k} ∧ v2 = {y1 | k})

    

Axiom F1 (Freeness (1,2)). µ ¶ f (x1 , . . . , xn ) = f (y1 , . . . , yn ) ∀x1 . . . xn y1 . . . yn → x1 = y1 ∧ . . . ∧ xn = yn for any f ∈ F , f distinct from {· | ·} Axiom F3 (Freeness (3)). ∀x

Special predicates (SP) 3 Tree C can be released to a requester with attributes B requesting access to a tree rooted at A User defined predicates (UP) (Examples) 1 True if A is suspicious 1 A is the SSN of a citizen 1 A has secret clearance 1 A has top secret clearance

Table 2: Predicate descriptions

Axiom Ea (Absorption). ∀xz

Excision Predicates (EP) 3 C is the subtree of A at node B 3 C is the subtree A with no subtree at B 3 C is the tree A, with subtree containing triple T removed

hideConcept(A,B,C)

allow(A,B,C)

∀xy1 . . . yn

Description

Tree construction predicates (TP) 2 {A | B} is an ontology tree 2 B is an instance of tree A 2 {A | B} is an RDF tree 2 B contains extensions of all triples encoded in A 2 B is the set of all instances of a

OTree(A,B) RDFInst(A,B) OBuild(A,B) IBuild(A,B)

Name modified WARHEAD

Machine Gun

Arity

Semantic Relationships (SR) 1 X is an ontological concept 2 B is an individual of type A 3 P relates A and B

(x 6= t[x])

unless: t is of the form {t1 ,. . .,tn |x} and x ∈ FV(t1 ,. . .,tn ) Definition 8 (Primitive constraint, Constraint). Primitive Constraint A primitive constraint is of the form t1 π t2 , where t1 , t2 are terms and π is one of the interpreted predicates. Constraint A constraint is a conjunction of primitive constraints or negation of primitive constraints.

Definition 9 (Predicates). Predicate symbols are partitioned into six sets: Semantic relationships (SR), tree construction predicates (TP), excision predicates (EP), modification predicates (MP), special predicates (SP) and user-defined predicates (UP). They are described in table 2.

Definition 10 (Atom and Literal). An atom is of the form q(t1 ,. . . ,tn ) where q is a predicate symbol or a primitive constraint and t1 ,. . . ,tn are terms. A literal is an atom (or a positive literal) or its negation (a negative literal). Definition 11 (Rule and Fact). A rule is of the form H ← B where H is an atom, and B is a list of literals. A fact is a rule such that B is an empty list.

Next we describe policies that can be expressed using our language. Definition 12 (Dissemination Control policies). Dissemination control policies are sets of stratified rules with following strata: 1. Stratum 0: Concept(X), Inst(X,Y), and Prop(X,Y,Z) facts. 2. Stratum 1: Definitions of system defined predicates: (a) TP (b) EP (c) MP These predicates are defined in figures 7, 8 and 9 (Appendix B). 3. Stratum 2: Definitions of SP predicate allow. These predicates are restricted in the following way: (a) The rule body cannot contain allow predicate. (b) The rules must be of the form allow(x,Y,C) ← B where B con˜ remSubtree(X), ˜ remBranch(X), ˜ hideConcetains: subtree(X), ˜ modifyConcept(X) ˜ and constraints. pt(X),

Next we give an example policy for the protection cases outlined in section 2.2 using the sample ontology presented in figure 1. Even though protection cases discussed involve only the rdfs:subClassOf property, our scheme can be used for protection of any ontological property.

Example 1 (Subtree protection policy). Consider an ontology tree rooted at ‘x’ that contains sensitive information and the requester’s attributes, available as a set Y. Disclosure control rules, where the level of detail in an ontology is to be disclosed based on the following attributes of the requester, are presented below:

allow(x, Y, C)

←

• Suspicious requesters are denied access to any ontological information, specified in rule 1,

allow(x, Y, C)

←

• Non citizens are denied access to any subtree whose root label is ‘Army’, specified by rule 2,

allow(x, Y, nil)

←

• Citizens can gain access to ontologies based on their security clearance: – ’Secret’ clearance can access any information except the details of Human agents (rule 3), and

← ←

SSN ∈ Y, Suspicious(SSN ) SSN ∈ Y, ¬Citizen(SSN ), OT ree(x, A), 0

allow(x, Y, C)

←

remSubtree(A, ‘Army , C), SSN ∈ Y, Citizen(SSN ), Secret(SSN ), OT ree(x, A), remSubtree(A,0 Agent0 , C) SSN ∈ Y, Citizen(SSN ),

hideConcept(A, ‘N 0 , C) SSN ∈ Y, Citizen(SSN ), Secret(SSN ), OT ree(x, C) SSN ∈ Y, ¬Citizen(SSN )

(10) (11) (12)

Example 5 (Node renaming with node hiding). As an update to the policy in example 4, it is decided that: • For citizens without secret clearance, Nuclear Warhead (abbr. N) should be hidden (rule 13).

– ‘Top Secret’ clearance can access the complete ontology (rule 4). allow(x, Y, nil) allow(x, Y, C)

SSN ∈ Y, Citizen(SSN ), ¬Secret(SSN ), OT ree(x, A),

• For citizens with secret clearance, N, should be desensitized to Warhead (abbr. W) (rule 14).

(1)

• Citizens with top secret clearance can access the unaltered ontology (rule 15).

(2)

• No access to non-citizens (rule 16). ←

SSN ∈ Y, Citizen(SSN ),

allow(x, Y, C)

←

where a specific branch in an ontology ‘x’ is rooted at ‘Nuclear Warhead’ (abbr. N) node related to a node ‘Deployment Site’ (abbr. D) through ‘isAt’ (abbr. I) property. Disclosure requirement is as follows:

¬Secret(SSN ), OT ree(x, A), hideConcept(A, ‘N 0 , C) (13) SSN ∈ Y, Citizen(SSN ), Secret(SSN ), OT ree(x, A), modif yConcept(A, ‘N 0 , ‘W 0 C) (14)

allow(x, Y, C)

←

• Requester with ‘Secret’ clearance can get access to the unaltered ontology (rule 5),

allow(x, Y, nil)

←

allow(x, Y, C)

←

T Secret(SSN ), OT ree(x, C)

allow(x, Y, C) (3) (4)

Example 2 (Branch protection policy). Consider another scenario

• No other requester can get access to the triple hN, I, Di and the subtree beneath it (rule 6). allow(x, Y, C)

←

allow(x, Y, C)

←

SSN ∈ Y, Secret(SSN ), OT ree(x, C) SSN ∈ Y, ¬Secret(SSN ), OT ree(x, A), remBranch(A, {N, {I, D}}, C)

(5)

• If Origin = Internal, then no alterations (rule 17). • Origin 6= Internal, rename ‘A’ to ‘P’ (rule 18). (6)

• Requests originating from CW department can only receive the subtree rooted at Co (rule 7). • Requests originating from SW department can only receive the subtree rooted at Sp (rule 8). • No access to requests outside the two departments (rule 9). ←

allow(x, Y, C)

←

allow(x, Y, nil)

←

CW ∈ Y, OT ree(x, A), subtree(A, Co, C) SW ∈ Y, OT ree(x, A), subtree(A, Sp, C) SW 6∈ Y, CW 6∈ Y

(15) (16)

Example 6 (Deliberate deception Policy). Consider a weapons ontology, rooted at ‘x’, that contains a triple hN uclear W arhead, Status, Activei. Deliberate deception is required here to change the label ‘Active’ (abbr. A) to ‘Passive’ (abbr. P) when releasing the ontology based on a specific attribute, say, Origin (abbr. O) as:

Example 3 (Subtree extraction policy). Consider the ontology in figure 1, with ‘Conventional Weapons’ abbreviated as ‘Co’ and ‘Special Weapons’ abbreviated as ‘Sp’. Requests for ontology can originate from two departments, conventional weapons department (abbr. CW) and special weapons department (abbr. SW). Disclosure control requirement states:

allow(x, Y, C)

SSN ∈ Y, Citizen(SSN ), T Secret(SSN ), OT ree(x, C) SSN ∈ Y, ¬Citizen(SSN )

(7)

(9)

Example 4 (Node hiding policy). Consider the ontology in figure 1, and a new disclosure policy:

←

allow(x, Y, C)

←

O ∈ Y, Internal(O), OT ree(x, C) O ∈ Y, ¬Internal(O), OT ree(x, X), modif yConcept(X, A, P, C)

(17)

(18)

Lemma 2. A dissemination control policy is a stratified CLP program. Proof: Stratification is obtained with the following level mapping [2, 21] `: ` assigns a level 0 to Stratum 0, level 1 to Stratum 1, level 2 to Stratum 2 and level 3 to Stratum 3 predicates. ¤

4 (8)

allow(x, Y, C)

Semantics

We use a three-valued semantics, called Kripke-Kleene (or KunenFitting) [13] semantics, for CLP programs, with constructive negation presented by Fages [12] We first repeat some standard definitions as they appear in [13] and repeated in [25].

• Citizens without secret clearance can access the organization of weapons ontology, but ‘Nuclear Warhead’ (abbr. N) node must be protected (rule 10).

Definition 13 (P∗ ). Suppose P is a CLP program, then P∗ is the set of

• Citizens with secret clearance can receive the complete ontology (rule 11).

The standard practice is to take A← as A and any ground atom A not in the head of any rule as A← false. We now define two and three valued truth lattices.

• No access to non-citizens (rule 12).

all ground instances of atoms in P.

Definition 14 (2 and 3 truth value lattices). 2 = h{T,F},