AIR Policy Language


AIR (AMORD In RDF) is a policy language that is represented in Turtle + quoting and supports AMORD-like constructs. The language describes several classes and properties that can be used to define privacy policies.
The following image illustrates the AIR classes and properties and their relationships. AIR ontology
There are two super classes in AIR: Abstract-action and Abstract-container. An AIR Policy is an subclass of Abstract-container. For example, an AIR Policy can be declared as 
@prefix air: <http://dig.csail.mit.edu/TAMI/2007/amord/air#> .
@prefix ex: <http://example.org/expolicy#> .

:FirstAIRPolicy a air:Policy.
The Abstract-container class has properties for defining variables, rules, goal-rules, assertions, and goal-assertions that Policy inherits. Variables are scoped to the container they appear in. For example, in the following declaration the scope of variable U1 is within FirstAIRPolicy and the scope of variable U2 is Rule1 
:FirstAIRPolicy a air:Policy;
   air:variable :U1;
   air:rule :Rule1.

:Rule1 a air:Belief-rule;
   air:variable :U2.
An Abstract-rule is a subclass of both Abstract-container and Abstract-action and its subclasses are Goal-rule and Belief-rule. Goal-rules only match facts that are asserted as goals and do not fire otherwise. Most policies usually contain only Belief-rules. A rule is a property of all Abstract-containers and is used to attach rules to policies as shown in the example above.

A rule consists of a pattern, a matched-graph variable, a justification, a label, and zero or more actions. The matched-graph variable, justification, and label are optional.Omitting the matched-graph variable means there's no direct reference for the matched graph, which often isn't needed. Omitting the justification means a default justification is used, also the usual case. For example, the following rule declares a variable and has a label, and a pattern 
:Rule1 a air:Belief-rule;
   air:variable :U2;
   air:label "FirstAIRRule";
   air:pattern
      {
        :U2 a air:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      }.
The action portion of a rule can either be a nested rule or an assertion. If a rule has as its action another rule, then when the pattern of the initial rule matches, the nested rule becomes active. In the following example, FirstAirPolicy has a rule Rule1. If the pattern of Rule1 is matched, its action becomes active. In this case, the action is another rule so the rule becomes active. At this point of time, if the pattern of the nested rule matches, the action, which is an assertion, becomes active i.e. the statement is asserted. 
:FirstAIRPolicy air:rule :Rule1.

:Rule1 a air:Belief-rule;
   air:variable :U2;
   air:label "FirstAIRRule";
   air:pattern
      {
        :U2 a air:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      };
    air:rule 
       [
         air:variable :A;
         air:label "NestedAIRRule";   
         air:pattern 
            {
              :U2 :actor :A.
              :A a :Student. 
            };
         air:assert { :U2 a :StudentUseEvent }
        ].
The actions of rules can also be assertions. These assertions can either be beliefs in which case the asserted statement(s) can be matched against belief rules or goals in which case the asserted statement(s) can be matched against goal rules. Belief and Goal are subclasses of Abstract-assertion, which is a subclass of Abstract-action. An instance of an Abstract-assertion has one property namely statement. Depending on the type of subclass, a statement is either be asserted as a goal or a belief. In the following example, a Belief assertion is associated with Rule1, so when the pattern matches, the statement is asserted as a belief 
:Rule1 a air:Belief-rule;
   air:variable :U2;
   air:pattern
      {
        :U2 a air:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
       }.
   air:assert { :U2 :patternMatches :Rule1 }.
The AIR language provides certain classes and properties for describing collections and their operations. This is useful for calculating the allowed purpose of data as it flows within the system. For more information about the calculation of purposes, please refer to the DPA paper. The language defines a Collection class that has several properties such as for testing whether a collection is empty, whether it has any members, whether X is a member of a certain collection or not, and whether one collection is contained in another. These are used to create patterns or assertions associated with rules. For example, the following rule checks if the purpose associated with a specific event is one of the allowed purposes associated with that particular class of events 
:Rule1 a air:Belief-rule;
   air:variable :U2;
   air:variable :P2;
   air:variable :AP;
   air:label "FirstAIRRule";
   air:pattern
      {
        :U2 a air:UseEvent;
           :refers-to [ a mit:ProxCardEvent ];
           :purpose P2;
        :UseEvent :allowed-purposes :AP. 
        :P2 is-member-of :AP
      };
    air:assert { :U2 :validPurpose :P2 }.
AIR also defines properties for generating new collections from existing ones namely includes-member, includes-member-of, and restricted-to-members-of. A subject collection can have any number of each of these properties. A resource is a member of the subject collection if it is the object of at least one air:includes-member property or if it is a member of at least one object collection of air:includes-members-of, and only if it is a member of every object collection of air:restricted-to-members-of.

There are some properties for talking about equivalence and compliance. Two resources are related with is-identical-to property if and only if the subject is identical to the object. Two resources are related with is-distinct-from property if and only if the subject is distinct from the object. The properties dealing with policy compliance are compliant-with and non-compliant-with and they specify that the subject is or is not compliant with the object policy. For example, the following policy has a single rule, which when matched asserts that the event is compliant-with the policy 
:SecondAIRPolicy a air:Policy;
   air:rule 
      [
        air:variable :U2;
        air:variable :P2;
        air:variable :AP;
        air:pattern
           {
             :U2 a air:UseEvent;
               :refers-to [ a mit:ProxCardEvent ];
               :purpose P2;
               :UseEvent :allowed-purposes :AP.
               :P2 is-member-of :AP                            
            };
        air:assert { :U2 air:compliant-with :SecondAIRPolicy }
      ].

References

maintained by Lalana Kagal
 $Revision: 4139 $
$Date: 2007-09-25 23:43:09 -0400 (Tue, 25 Sep 2007) $


*This work is sponsored by National Science Foundation (Award 0524481) and by DTO (Award ).