This document specifies version 2.0 of the Rei ontology. Rei is a policy
specification language in OWL-Lite that allows users to develop declarative policies
over domain specific ontologies in RDF, DAML+OIL and OWL.
Rei is used to describe positive and negative permissions and obligations of entities in
the policy domain. A distinguishing feature of Rei is that it includes specifications for
speech acts, policy analysis and conflict resolution. The speech included are delegation,
revocation, request and cancel and are used for remote policy management.
The two kinds of specifications included for policy analysis are use-case management and
what-if analysis. As Rei is geared towards distributed environments, it also includes
conflict resolution specifications like modality preferences or priority assignments
between policies or between individual rules of a policy.
Abstract
Terminology
1
Ontologies
2
Policy
3
Granting
4
DeonticObject
4.1
Permission
4.2
Prohibition
4.3
Obligation
4.4
Dispensation
5
Action
5.1
DomainAction
5.2
SpeechAct
5.2.1
Delegation
5.2.2
Revocation
5.2.3
Request
5.2.4
Cancel
5.2.5
Command
5.2.6
Promise
6
Constraint
6.1
SimpleConstraint
6.2
BooleanConstraint
7
Entity
8
MetaPolicy
8.1
Behavior
8.2
MetaMetaPolicy
8.3
ModalityPrecedence
8.4
Priority
8.4.1
RulePriority
8.4.2
PolicyPriority
9
Analysis
9.1
UseCase
9.1.1
DeonticUseCase
9.1.2
StatementUseCase
9.2
WhatIf
9.2.1
WhatIfProperty
9.2.2
WhatIfPolicyRule
10
References
Appendix A: Example Rei Policy
- policy
- the set of rules that describe the optimal behaviour of entities in the policy domain
- policy domain
- the set of entities and resources that are affected by the policy
- deontic object
- permission, prohibition, obligation and dispensation are deontic objects
- speech act
- the use of language to perform some act (WordNet 2.0)
- meta policy
- a policy that governs how a policy is enforced. Used primarily in Rei to represent
mechanisms for conflict resolution.
- constraint
- a condition on a certain policy, rule or deontic object
Rei is composed of several ontologies: ReiPolicy, ReiMetaPolicy, ReiEntity,
ReiDeontic, ReiConstraint, ReiAnalysis, and ReiAction, each with their unique XML namespace.
Each ontology describes the classes and properties associated with that domain. For the
remainder of this document, we use prefixes to refer to these namespaces. These prefixes
are created by dropping "Rei" from the name of the ontology. For example, the
prefix "policy" is used for ReiPolicy and so to describe an instance of a Policy class in
the ReiPolicy ontology we use
<policy:Policy rdf:ID="New Policy">
.......
</policy:Policy>
prefix |
Ontology |
Class list |
policy |
ReiPolicy |
Class : ReiRoot, Policy, Granting |
metapolicy |
ReiMetaPolicy |
Class : MetaPolicy, ModalityPrecedence, Behaviour, MetaMetaPolicy, Priority
Subclass of Priority : RulePriority, PolicyPriority
|
entity |
ReiEntity |
Class : Entity
Subclass of Entity : Agent, Object, Variable
|
deontic |
ReiDeontic |
Class : DeonticObject
Subclass of DeonticObject : Permission, Obligation, Prohibition, Dispensation
|
action |
ReiAction |
Class : Action
Subclass of Action : DomainAction, SpeechAct
Subclass of SpeechAct : Delegation, Revocation, Obligation, Dispensation
|
constraint |
ReiConstraint |
Class : Constraint
Subclass of Constraint : SimpleConstraint, BooleanConstraint
Subclass of BooleanConstraint : And, Or, Not
|
analysis |
ReiAnalysis |
Class : Analysis
Subclass of Analysis : WhatIf, UseCase
Subclass of WhatIf : WhatIfProperty, WhatIfPolicyRule
Subclass of UseCase : StatementUseCase, DeonticUseCase
|
Policies are used to guide the behavior of entities in the policy domain. A policy
primarily includes a list of rules and a context used to define the policy domain. It could
also include a list of defaults used to interpret the policy, and a set of conflict
resolution specifications.
<policy:Policy rdf:ID="DeptPolicy">
<policy:context rdf:resource="#IsMemberOfCS"/>
<policy:grants rdf:resource="#Perm_StudentPrinting"/>
<policy:grants rdf:resource="#Granting_StudentLaserPrinting"/>
<policy:defaultBehavior rdf:resource="&metapolicy;ExplicitPermExplicitProh"/>
<policy:defaultModality rdf:resource="&metapolicy;PositiveModalityPrecedence"/>
<policy:metaDefault rdf:resource="&metapolicy;CheckModalityFirst"/>
<policy:rulePriority rdf:resource="#PriorityBA"/>
<policy:imports rdf:resource="#SchoolPolicyWithGreaterPriority"/>
</policy:Policy>
Properties
- policy:context
- a set of constraints that define the policy domain. These constraints are conditions
over attributes of entities in the policy domain.
<policy:context rdf:resource="#IsMemberOfCS"/>
where 'IsMemberOfCS' is a constraint:Constraint.
- policy:grants
- is used to associate a deontic object with a policy either
directly of using a policy:Granting. Consider a policy, DeptPolicy,
that grants the permission to all students to print
<policy:grants rdf:resource="#Perm_StudentPrinting"/>
The policy also grants a policy:Granting that adds additional
constraints to an existing deontic object.
<policy:grants rdf:resource="#Granting_StudentLaserPrinting"/>
<policy:Granting rdf:ID="Granting_StudentLaserPrinting">
<policy:to rdf:resource="#PersonVar"/>
<policy:deontic rdf:resource="#Perm_StudentPrinting"/>
<policy:requirement rdf:resource="#IsLaserPrinterAndPhStudent"/>
</policy:Granting>
- policy:defaultBehavior
- this defines whether everything allowed/prohibited is specified or assumed. It can
only be one of the instances of metapolicy:Behavior described in the
ReiMetaPolicy ontology. The following states that everything that is permitted/prohibitted must
explicitly defined in the policy
<policy:defaultBehavior rdf:resource="&metapolicy;ExplicitPermExplicitProh"/>
- policy:defaultModality
- specifies the modality (positive or negative) that holds precedence in case of conflict. It is
one of the instances of metapolicy:ModalityPrecedence. For example,
<policy:defaultModality rdf:resource="&metapolicy;PositiveModalityPrecedence"/>
- policy:metaDefault
- states whether the defaultModality holds precedence over defaultBehavior or vice versa. It is
set with instances of metapolicy:MetaMetaPolicy. For example,
<policy:metaDefault rdf:resource="&metapolicy;CheckModalityFirst"/>
- policy:rulePriority
- is used to set priorities between potentially conflicting rules that can be either
policy:Granting or deontic objects. For example,
if a policy grants two rules; RuleA (a permission to print) and RuleB (a prohibition from
printing), then rulePriority can be used to state that the prohibition holds priority
over the permission. The metapolicy:RulePriority class is used
to create a priority statement.
<policy:rulePriority rdf:resource="#PriorityBA"/>
<metapolicy:RulePriority rdf:ID="PriorityBA">
<metapolicy:ruleOfGreaterPriority rdf:resource="#RuleB"/>
<metapolicy:ruleOfLesserPriority rdf:resource="#RuleA"/>
<metapolicy:RulePriority>
The ReiOntology also defines constructs for Policy that are used to describe administrative attributes
like 'createdBy', 'creationTime' and 'modifiedBy'.
A granting associates a set of constraints with a deontic object to form a policy rule. This allows
reuse of deontic objects in different policies with different constraints and actors.
For example, the following
policy:Granting uses an existing
deontic:Permission and defines additional constraints on the actor and
actor. The granting gives all PhD students the permission to use laser printers.
<policy:Granting rdf:ID="Granting_StudentLaserPrinting">
<policy:to rdf:resource="#PersonVar"/>
<policy:deontic rdf:resource="#Perm_StudentPrinting"/>
<policy:requirement rdf:resource="#IsLaserPrinterAndPhStudent"/>
</policy:Granting>
Properties
- policy:to
- this denotes whom the granting is made to. Can be either an instance of or an
entity:Variable over which constraints are described. These constraints
cause the Granting to be applicable to a set of entities.
- policy:deontic
- the granting is over this deontic object. This can also be either an instance or an
entity:Variable that is instantiated by fulfilling the
associated constraints.
- policy:requirement
- the list of constraint:Constraints over policy:to,
policy:deontic and/or any environmental state like the time of day.
This class is used to create permissions, prohibitions, obligations and
dispensations over entities in the policy domain. It includes
constructs for describing what action (or set of actions) the deontic
is described over, who the potential actor (or set of actors) of the
action is and under what conditions is the deontic object applicable.
Consider as an example, a deontic object that permits students to print on
certain printers
<deontic:Permission rdf:ID="Perm_StudentPrinting">
<deontic:actor rdf:resource="#PersonVar"/>
<deontic:action rdf:resource="#ObjVar"/>
<deontic:constraint rdf:resource="#IsStudentAndBWPrinter"/>
</deontic:Permission>
As the
deontic:actor and
deontic:action are both
entity:Variables, the permission is applicable to all entities and actions
that satisfy
deontic:constraint.
Properties
- deontic:action
- this property is used to specify which action the deontic object is
described over. It can either be a specific instance of
action:Action or an entity:Variable. If it is a
Variable, then constraints are described in deontic:constraint
specify a set of actions.
- deontic:actor
- this properties specifies whom the deontic object is directed to.
Again, this can either be an instance or an entity:Variable.
If it is a Variable, then constraints are described in
deontic:constraint specify a set of actions.
- deontic:constraint
- the constraint property is used to describe constraints over the
deontic:actor, deontic:actor and the
environment, in general.
- deontic:startingConstraint
- the startingConstraint property is a subproperty of constraint and defines
the state under which the deontic is true.
- deontic:endingConstraint
- the endingConstraint property is a subproperty of constraint and defines
the state under which the deontic is false.
startingConstraint and endingConstraint together define the window within which
the deontic object is valid or must be completed in case of an obligation.
DeonticObject has 4 subclasses : Permission, Prohibition, Obligation and
Dispensation.
A
deontic:Permission is used to specify the an action (set of
actions) allowed for an entity (group of entities). However, even though
this deontic object specifies a permission for an entity, the
permission does not become a rule unless it is granted by a
policy:Policy of the entity's domain.
Properties
- deontic:provision
- Permission contains only one additional property,
deontic:provision. This property is an obligation
and is used to grant conditional permissions. The obligation
only becomes active after the permission is exercised.
A
deontic:Prohibition describes an action (or set of actions) that
the actor (or group of actors) is prohibited from performing.
Properties
- deontic:sanction
- This property describes the penalties that will be
imposed on the actor if the prohibition is violated.
It is either additional obligations and/or prohibitions,
and/or actions that will be performed against the actor.
The following example is of a prohibition,
CannotUseIR,
prohibiting an entity denoted by
JohnDoe from performing
an action denoted by
InfraredPortUsage. As neither
deontic:actor nor
deontic:action are variables, the
prohibition applies only to the specified actor and action.
<deontic:Prohibition rdf:ID="CannotUseIR>
<deontic:actor rdf:resource="#JohnDoe"/>
<deontic:action rdf:resource="#InfraredPortUsage"/>
<deontic:constraint rdf:resource="#IsAfterOfficeHours"/>
</deontic:Prohibition>
A
deontic:Obligation is used to specify an action that the actor
is obliged to carry out. Again, an obligation can be about a set of actions and
can be defined for a group of actors.
Properties
- deontic:obligedTo
- This property describes whom the entity is obliged to.
- deontic:sanction
- This property describes the penalties that will be imposed if the obligation
is not fulfilled. It is either an action that will be performed or
a new obligation or prohibition that is put into effect.
A
deontic:Dispensation is a waiver for an obligation. Under the
right meta policies, a dispensation is used to negate or free the actor from a
deontic:Obligation.
This ontology is one of the most important in the Rei specifications
as policies are described over possible actions in the domain. This
class includes properties that are required for all actions.
Though the execution of actions is outside the policy engine, Rei
includes a representation of actions that allows more contextual
information to be captured and allows for greater understanding of the
action and its parameters. It also permits domain dependent
information about actions to be added.
Properties
- action:actor
- This property describes who the actor of the action is
- action:location
- This property states where the action is performed.
- action:time
- This property states when the action is performed.
Action has 2 subclasses :
DomainAction
and
SpeechAct.
This subclass of
action:Action includes
additional properties for describing application or domain specific
actions. For example, in a university domain-specific actions include
taking courses, printing, emailing, writing/reviewing papers and
passing exams. This class provides some required properties. Other
properties can be added and will be automatically reasoned over if
used to develop policies.
Properties
- action:target
- This property describes the object on which the action is performed.
- action:precondition
- This property states the conditions under which the action can
be performed. For example, in order to print, there must be paper in
the printer.
- action:effect
- This property states the conditions that occur after the action
is performed. For example, after printing 2 pages, there will be two
less pages in the printer.
If properties like target, location, and actor of an action are
instantiated to a specific instance then an action instance is
described. Otherwise, if any one of the properties is an
entity:Variable, it describes a set of actions.
An example of a description for a set of actions is
<action:Action rdf:ID="InfraredPortUsage">
<action:actor rdf:resource="#PersonVar"/>
<action:target rdf:resource="#ObjVar"/>
<action:location rdf:resource="&inst;EbiquityLab"/>
<action:precondition rdf:resource="#DeviceBelongsToEbiqLab"/>
<action:Action>
The following class describes an action that can be performed by
anyone as long as the target is a device that belongs to the
'EbiquityLab'.
OWL constructs can also be used to create classes of actions. For
example, to describe a class of printing actions located in the
'CSDept'
<owl:Class rdf:ID="CSPrinting">
<rdfs:subClassOf rdf:resource="#Printing"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="&action;location"/>
<owl:allValuesFrom rdf:resource="#CSDept" />
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
An example of a description for a specific action is
<action:Action rdf:ID="PrintingOnHP123">
<action:target rdf:resource="&inst;HP123"/>
<action:location rdf:resource="&inst;Lab"/>
</inst:StudentCSPrinting>
The speech acts that Rei defines include are primarily used for
dynamic and remote policy management.
Properties
- action:sender
- This property is a subproperty of the action:actor
and specifies who the speech act is being sent by. This cannot be
a entity:Variable.
- action:receiver
- This property states who the recipient of the speech act
is. The receiver can either be a specific entity or a entity:Variable.
- action:condition
- This property states the constraints that the sender is adding
to the speech act implying that the speech act is only valid when
these constraints are true.
- action:context
- This property is the actual message being sent and can either
be an action:Action or a deontic:DeonticObject.
There are six subclasses of SpeechAct : Delegate, Revoke, Request,
Cancel, Command, and Promise. A valid delegation leads to a new
permission. Similarly, a revocation speech act nullifies an existing
permission (whether policy based or delegation based) by causing a
prohibition. An entity can request another entity for a permission,
which if accepted causes a delegation, or to perform an action on its
behalf, which if accepted causes an obligation. An entity can also
cancel any previously made request, which leads to a revocation and/or
a dispensation. A command causes an obligation on the recipient and
the promise causes an obligation on the sender.
Consider a general delegation from 'Tim' to all members of the
'CSDept' giving them the permission to perform a class of action
denoted by 'FacultyPrinting'
<action:Delegation rdf:ID="TimToCSMembers">
<action:sender rdf:resource="&inst;TimFinin"/>
<action:receiver rdf:resource="#PersonVar"/>
<action:content>
<deontic:Permission>
<deontic:actor rdf:resource="#PersonVar"/>
<deontic:action rdf:resource="#ObjectVar"/>
</deontic:Permission>
</action:content>
<action:condition>
<constraint:And>
<constraint:first rdf:resource="#IsMemberOfCS"/>
<constraint:second rdf:resource="#IsFacultyPrinting"/>
</constraint:And>
</action:condition>
</action:Delegation>
'Tim' revokes the permission to use a specific action
'AFacultyPrintingAction' from 'George'
<action:Revocation rdf:ID="TimFromGeorge">
<action:sender rdf:resource="&inst;TimFinin"/>
<action:receiver rdf:resource="&inst;George"/>
<action:content>
<deontic:Permission>
<deontic:action rdf:resource="&inst;AFacultyPrintingAction"/>
</deontic:Permission>
</action:content>
</action:Revocation>
A constraint is used to define a set of objects like a set of graduate
students, a set of actions whose targets are laser printers, a set of
users that belong to the same lab as 'JohnDoe', and the set of
students whose advisors are assigned to the lab in which the target of
the printer is located.
There are two subclasses of constraints: SimpleConstraint and BooleanConstraint.
As any expression in RDF is a collection of triples, a
SimpleConstraint is modeled as a triple consisting of subject,
predicate and object.
For example, a set of objects of that have 'affiliation' property set
to 'CSDept' is defined as
<constraint:SimpleConstraint rdf:ID="IsMemberOfCS">
<constraint:subject rdf:resource="#PersonVar"/>
<constraint:predicate rdf:resource="&univ;affiliation"/>
<constraint:object rdf:resource="&univ;CSDept"/>
</constraint:SimpleConstraint>
Another example is of a set of actions of type 'FacultyPrinting'
<constraint:SimpleConstraint rdf:ID="IsFacultyPrinting">
<constraint:subject rdf:resource="#ObjectVar"/>
<constraint:predicate rdf:resource="&rdf;type"/>
<constraint:object rdf:resource="#FacultyPrinting"/>
</constraint:SimpleConstraint>
Constraints (both Simple and Boolean) can
be combined in pairs using boolean operators of
And, Or and
Not. Each boolean operator is a subclass of BooleanConstraint.
For example, an 'And' operation over two constraints can be defined as
<constraint:And rdf:ID="IsLaserPrinterAndPhStudent">
<constraint:first rdf:resource="#IsPhDStudent"/>
<constraint:second rdf:resource="#IsLaserPrinter"/>
</constraint:And>
Properties
- constraint:first
- This property specifies the first constraint:Constraint in
the boolean operator and can be either a
constraint:SimpleConstraint or a
constraint:BooleanConstraint.
- constraint:second
- This property specifies the second constraint:Constraint in
the boolean operator and can be either a
constraint:SimpleConstraint or a
constraint:BooleanConstraint.
However, this property is only associated with And and
Or, as the Not is over a single
constraint:SimpleConstraint.
Any human user, software agent or hardware resource is described as an
entity:Entity. Currently, the Entity class has only one
property,
entity:affiliation, which is used to specify
what organization an entity belongs to.
Entity is further subclassed into
entity:Agent,
entity:Object and
entity:Variable to indicate
whether the entity is an agent (human or software), a hardware
resource or a variable that is used to describe constraints.
A
entity:Variable is used to as a placeholder for every entity in
a set defined by the constraints the variable is used in.
An example of a
entity:Variable is
<entity:Variable rdf:ID="PersonVar" />
Rei specifications include metapolicy constructs for how policies are
interpreted and how conflicts can be resolved. Rei models 2 main
types of meta policies (1) for defaults and (2) for conflict
resolution to handle different requirements of policies. Meta policies for
defaults include behavior and meta-meta policies and meta
policies for conflict resolution include priorities and modality precedence.
This class
is made up of three instances that describe what the default behavior
of the policy is, example whether everything that is not explicitly
permitted is prohibitted or everything that is not explicitly
prohibitted is permitted.
Instances
- ExplicitPermImplicitProh
- Permissions must be explicitly stated. Every action that is not
permitted explicitly is prohibitted.
- ImplicitPermExplicitProh
- Prohibitions must be explicitly described. Every action that is
not explicitly prohibitted is permitted.
- ExplicitPermExplicitProh
- Both permissions and prohibitions must be explicitly stated. No
assumptions are made.
These
policies are used to set precedences within meta policies or in other
words to decide which meta policy to invoke first.
Instances
- CheckModalityFirst
- This implies that if modality precedence is set, then it should be used first.
- CheckPriorityFirst
- This implies that if priorities are set, then they should be
used first.
Rei also allows the default modality precedence to be set, allowing
all rules of a certain modality to be given preference over other
rules in case of conflict.
Instances
- Positive
- This implies that all rules of positive modality (permission and
obligation) override other rules in case of conflict.
- Negative
- This implies that all rules of negative modality (prohibition
and dispensation) override other rules in case of conflict.
This meta policy specification allows priorities to be set between
policies and rules. For example, it is possible to say that in case of
conflict the Federal policy always overrides the State policy.
Priority is subclassed into two: RulePriority and PolicyPriority
depending on whether priorities are being set between rules in a
policy or between policies themselves.
In order to state that one rule overrides another within the same
policy, Rule Priority is used. For example, if RuleA and RuleB are
part of a policy and RuleA gives John the permission to print whereas
RuleB prohibits John from printing, then there exists a potential for
conflict. A RulePriority can be defined between the two in order to
give one rule priority over the other. If the prohibition should have
higher priority then
<metapolicy:RulePriority rdf:ID="PriorityBA">
<metapolicy:ruleOfGreaterPriority rdf:resource="#RuleB"/>
<metapolicy:ruleOfLesserPriority rdf:resource="#RuleA"/>
<metapolicy:RulePriority>
This PriorityBA is then associated with the policy through the
policy:rulePriority property.
RulePriority can be used to resolve conflicts between rules within the
same policies. However, for conflicting rules from different policies,
the priority between the policies must be specified.
To specify that the Federal policy has higher priority that the State
policy
<metapolicy:PolicyPriority rdf:ID="PriorityFederalState">
<metapolicy:policyOfGreaterPriority rdf:resource="&gov;Federal"/>
<metapolicy:policyOfLesserPriority rdf:resource="&gov;State"/>
<metapolicy:PolicyPriority>
Meta policy
defaults are used to set precedences within meta policies or in other
words to decide which meta policy to invoke first.
Instances
- CheckModalityFirst
- This implies that if modality precedence is set, then it should be used first.
- CheckPriorityFirst
- This implies that if priorities are set, then they should be
used first.
To enable the development of consistent and valid policies, Rei
provides two specifications: use-case management and what-if
analysis.
In use-case management, a set of use cases can be described that are
can be constantly verified against a set of policies. For example, the
Dean of the CS department should always have the permission to print
to the HPColorPrinter. This is defined as a use case and can be tested
against the CS policy, the Lait lab policy and the school policy. If
the policies are consistent, the use case will be true. If the use
case is false there is an error in specifications of the policies.
There are two kinds of use cases that can be described:
StatementUseCase and DeonticUseCase. StatementUseCase is used to
specifies properties of entities and action and is further subclassed
into TrueStatementUseCase and FalseStatementUseCase. The former is
used to state that an entity must have a certain value for a certain
property whereas the latter states that the entity must not have a
certain value for a certain property.
A StatementUseCase stating that 'BobJones' should always be affiliated
to the CSDept is described as
<analysis:TrueStatementUseCase rdf:ID="BobJonesIsInCS">
<analysis:subject rdf:resource="&inst;BobJones"/>
<analysis:predicate rdf:resource="&univ;affiliation"/>
<analysis:object rdf:resource="&inst;CSDept"/>
</analysis:TrueStatementUseCase>
DeonticUseCase is used to verify the permissions, prohibitions,
obligations and dispensations of entities. It is subclassed into
PermissionUseCase, ProhibitionUseCase, ObligationUseCase and
DispensationUseCase.
A DeonticUseCase that specifies that 'Marty' must not be able to
access 'LabPrinter' is described as
<analysis:ProhibitionUseCase rdf:ID="MartyCannotUseLabPrinter">
<analysis:actor rdf:resource="&inst;Marty"/>
<analysis:target rdf:resource="&inst;LabPrinter"/>
</analysis:ProhibitionUseCase>
Whatif analysis is used to specify temporary changes to the policy or
to entities in order to test their effects before committing them.
There are two subclasses of whatif analysis: WhatIfProperty for
checking changes to entities and WhatIfPolicyRule for changes to
policies. WhatIfProperty has two subclasses WhatIfIAddProperty, which
is used to temporarily add a property of a certain value to an entity,
and WhatIfIRemoveProperty, which is used to temporarily remove a
property value from an entity. Similarly, WhatIfPolicyRule
is subclassed into WhatIfIAddPolicyRule for adding policy rules and
WhatIfIRemovePolicyRule for testing the effects of removing a policy
rule from a policy.
To test the effects of removing the 'CSDept' value of the 'affiliation'
property from 'Marty'
<analysis:WhatIfIRemoveProperty rdf:ID="RemoveMartyBelongsToCS">
<analysis:instance rdf:resource="&inst;Marty"/>
<analysis:property rdf:resource="&univ;affiliation"/>
<analysis:value rdf:resource="&inst;CSDept"/>
</analysis:WhatIfIRemoveProperty/>
In order to test the effects of adding a policy rule, 'Perm_Joe',
to a policy, 'CSPolicy'
<analysis:WhatIfIAddPolicyRule rdf:ID="AddPermToCSPolicy">
<analysis:policy rdf:resource="&dept;CSPolicy"/>
<analysis:granting rdf:resource="&dept;Perm_Joe"/>
</analysis:WhatIfIAddPolicyRule>
A complete example is available at
http://www.cs.umbc.edu/~lkagal1/rei/examples/univ/deptpolicy.owl
For use case analysis and whatif analysis
http://www.cs.umbc.edu/~lkagal1/rei/examples/univ/analysis.owl