Rei logo

Rei Ontology Specifications, Ver 2.0

This version :
Ontologies :
Lalana Kagal (


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.

Table of contents


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


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.
a condition on a certain policy, rule or deontic object

1    Ontologies

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">



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

2    Policy

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"/> 


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.
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"/>
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"/> 
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"/> 
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"/> 
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"/>
The ReiOntology also defines constructs for Policy that are used to describe administrative attributes like 'createdBy', 'creationTime' and 'modifiedBy'.

3    Granting

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"/>


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.
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.
the list of constraint:Constraints over policy:to, policy:deontic and/or any environmental state like the time of day.

4    DeonticObject

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"/>
As the deontic:actor and deontic:action are both entity:Variables, the permission is applicable to all entities and actions that satisfy deontic:constraint.


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.
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.
the constraint property is used to describe constraints over the deontic:actor, deontic:actor and the environment, in general.
the startingConstraint property is a subproperty of constraint and defines the state under which the deontic is true.
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.

4.1    Permission

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.


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.

4.2    Prohibition

A deontic:Prohibition describes an action (or set of actions) that the actor (or group of actors) is prohibited from performing.


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"/>

4.3    Obligation

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.


This property describes whom the entity is obliged to.
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.

4.4    Dispensation

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.

5    Action

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.


This property describes who the actor of the action is
This property states where the action is performed.
This property states when the action is performed.
Action has 2 subclasses : DomainAction and SpeechAct.

5.1    DomainAction

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.


This property describes the object on which the action is performed.
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.
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"/>
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"/>
      	       <owl:onProperty rdf:resource="&action;location"/>
               <owl:allValuesFrom rdf:resource="#CSDept" />
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"/>

5.2    SpeechAct

The speech acts that Rei defines include are primarily used for dynamic and remote policy management.


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.
This property states who the recipient of the speech act is. The receiver can either be a specific entity or a entity:Variable.
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.
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"/> 
			<deontic:actor rdf:resource="#PersonVar"/> 
			<deontic:action rdf:resource="#ObjectVar"/> 
			<constraint:first rdf:resource="#IsMemberOfCS"/> 
			<constraint:second rdf:resource="#IsFacultyPrinting"/> 
'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"/>
			<deontic:action rdf:resource="&inst;AFacultyPrintingAction"/>

6    Constraint

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.

6.1    SimpleConstraint

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"/>
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"/>

6.1    BooleanConstraint

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"/>


This property specifies the first constraint:Constraint in the boolean operator and can be either a constraint:SimpleConstraint or a constraint:BooleanConstraint.
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.

7    Entity

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" />

8    MetaPolicy

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.

8.1    Behavior

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.


Permissions must be explicitly stated. Every action that is not permitted explicitly is prohibitted.
Prohibitions must be explicitly described. Every action that is not explicitly prohibitted is permitted.
Both permissions and prohibitions must be explicitly stated. No assumptions are made.

8.2    MetaMetaPolicy

These policies are used to set precedences within meta policies or in other words to decide which meta policy to invoke first.


This implies that if modality precedence is set, then it should be used first.
This implies that if priorities are set, then they should be used first.

8.3    ModalityPrecedence

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.


This implies that all rules of positive modality (permission and obligation) override other rules in case of conflict.
This implies that all rules of negative modality (prohibition and dispensation) override other rules in case of conflict.

8.4    Priority

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.

8.3.1    Rule Priority

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"/>
This PriorityBA is then associated with the policy through the policy:rulePriority property.

8.3.2    Policy Priority

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"/>

8.4    Default

Meta policy defaults are used to set precedences within meta policies or in other words to decide which meta policy to invoke first.


This implies that if modality precedence is set, then it should be used first.
This implies that if priorities are set, then they should be used first.

9    Analysis

To enable the development of consistent and valid policies, Rei provides two specifications: use-case management and what-if analysis.

9.1    UseCase Management

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"/>
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"/>

9.2    WhatIf

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"/>

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"/>

10    References

Appendix A: Example of Rei Policy

A complete example is available at
For use case analysis and whatif analysis