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 policies.

Specifications

The following image illustrates the AIR classes and properties and their relationships.

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, policy1, can be declared as

@prefix air: <http://dig.csail.mit.edu/TAMI/2007/amord/air#> .
@prefix ex: <http://example.org/expolicy#> .

:policy1 a air:Policy.

AIR uses N3Logic syntax to declare variables. It uses @forAll to declare universals and @forSome to declare existentials. Variables are scoped to file in which they appear in. Variables can be declared globally (outside policies and rules) or they can be declared in one of the two sides of a rule (pattern or assertion).

If a variable is declared globally then that variable can be used on both sides of any rule in that file and can be referred to in nested rules triggered from those rules in that file. If one of the rules in the file ultimately trigger a nested rule in a different file, then a previously matched global variable can be used in the latter rule as long as it is referred to with its entire URI (base URI of original file + name of variable). A variable is an anonymous node named with a certain URI. If an un-nested rule refers to a variable that is not quantified in the file using the variable's URI, it will referring to an object at that URI and not a variable in a different file. A (universal or existential) variable that is declared in the hand side (pattern) or the right hand side (assertion) of a rule is only accessible in that side. Variables declared in the right hand side (assertion) are simply anonymous nodes with the correct quantification but that functionality is not supported in this version. In order to use the same variable in both the left and right hand side of a rule, it must be declared globally. However, globally declaring existential variables is not supported in this version and existentials can only be used in patterns.

An Abstract-rule is a subclass of both Abstract-container and Abstract-action and its subclasses are Hidden-rule and Belief-rule. Most policies usually contain only Belief-rules. The deductions made by a rule declared to be a Hidden-rule will not appear in the resulting explanation. A rule is a property of all Abstract-containers and is used to attach rules to policies as shown in the example above.

A policy usually consists of one or more rules specified via the air:rule property. A rule consists of a pattern, a matched-graph variable, a justification, a label, a description, and zero or more actions. The matched-graph variable, justification, description, 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. The description is a list of strings, variables, and expressions that provides a natural language description of the rule. For example, the following belief rule declares a variable and has a label, and a pattern

@forAll :U.
:rule3 a air:Belief-rule;
   rdfs:label "AIRRule 3";
   air:description ("The event " :U " uses prox card data ");
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      }.

The action portion of a rule can either be a nested rule or an assertion. A nested rule is specified using air:rule property and an assertion via air:assert property. 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, policy3 has a rule rule4. If the pattern of rule4 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.

@forAll :U, :A.

:policy3 air:rule :rule4.

:rule4 a air:Belief-rule;
   rdfs:label "AIRRule 4";
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      };
    air:rule 
       [
         rdfs:label "NestedAIRRule";   
         air:pattern 
            {
              :U :actor :A.
              :A a :Student. 
            };
         air:assert { :U a :StudentUseEvent }
        ].

There is another useful property in an Abstract-rule namely air:alt. It is used to specify alternate rules that become active or are triggered when the pattern of the parent rule does not match. In the example below, :rule5 only becomes active when the pattern associated with :rule4 does not match

@forAll :U, :A.

:policy3 air:rule :rule4.

:rule4 a air:Belief-rule;
   rdfs:label "AIRRule 4";
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      };
    air:alt 
       [
         rdfs:label "AlternateRule";   
         air:pattern 
            {
              :U a tami:UseEvent
            };
         air:assert { :U a mit:NotProxCardEvent }
        ].

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 asserted as a goal or a belief. In the following example, a Belief assertion is associated with :rule5, so when the pattern matches, the statement is asserted as a belief

@forAll :U.

:rule5 a air:Belief-rule;
   air:pattern
      {
        :U a tami:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
       }.
   air:assert { :U :patternMatches :rule5 }.

In order to modify the dependency structure and allow customized justifications, AIR provides a means to write explicit justifications. This is done by using the assertion property associated with rules. This property is composed of two components, statement, which is the set of triples being asserted, and justification, which is the explicit justification that needs to be associated with the statement. The value of the justification property has to be an instance of the Justification class. The Justification class consists of two properties rule-id and antecedent. The rule-id can be set to the name of the rule that the assertion is to be attributed to and the antecedent is a list of matched graphs that would act as the premises. It is possible to obtain the matched graphs of rules by using the matched-graph property of rules with a variable. Consider the example below. A rule, :DAP-1, has a nested rule, :DAP-2, inside it. The default justification for the assertion of :DAP-2 would be both the rules and their matched graphs.

@forAll :REQ, :REQUESTER, :RESOURCE, :MEMBER, :MEMBERLIST.
:DAP-1 a air:BeliefRule;

   air:pattern {
      :REQ a air:Request;
      foaf:openid :REQUESTER;
      air:resource :RESOURCE.
      :DIG data:owns :RESOURCE.
   };
   air:rule :DAP-2.

:DAP-2 a air:BeliefRule;
   air:pattern {
      :DIG foaf:member :MEMBERLIST.
      :MEMBER list:in :MEMBERLIST.
      :MEMBER a foaf:Person;
      foaf:openid :REQUESTER.
   };
   air:assert{ :MEMBER permitted :RESOURCE }.

In order to change this justification structure and show that a completely different rule, :SomeOtherRule is used, the matched-graph, :G1, for the new rule is obtained. This matched-graph is used as the antecedent and the rule name, :SomeOtherRule, is used as the rule-id in the assertion of :DAP-2. This overwrites the original justification tree of assertion of ":MEMBER permitted :RESOURCE".

:SomeOtherRule a air:BeliefRule;
   air:matched-graph :G1;
   air:pattern { A X C };
   air:assert { B A C}.

:DAP-2 a air:BeliefRule;
   air:pattern {
      :DIG foaf:member :MEMBERLIST.
      :MEMBER list:in :MEMBERLIST.
      :MEMBER a foaf:Person;
      foaf:openid :REQUESTER.
   };
   air:assertion [
      air:statement { :MEMBER permitted :RESOURCE };
      air:justification [
         air:rule-id :SomeOtherRule;
         air:antecedent :G1
      ]
   ].

The AIR ontology also includes properties for policy compliance namely 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

@forAll :U, :P, :AP.
:policy7 a air:Policy;
   air:rule 
      [
        air:pattern
           {
             :U a tami:UseEvent;
               :refers-to [ a mit:ProxCardEvent ];
               :purpose P;
               tami:UseEvent :allowed-purposes :AP.
               :P is-member-of :AP                            
            };
        air:assert { :U air:compliant-with :policy7 }
      ].

AIR Reasoner

The AIR reasoner is developed in python and uses cwm libraries. It can be accessed online and uses the following properties

• logFile - URI of the data
• rulesFile - URI of an AIR policy
• filterProperties - URI of predicates for which justification is desired. This is an optional property. If no filterProperties are specified, air:compliant-with and air:non-compliant-with are the only predicates for which justifications are produced.

Justification User Interface

References

• AIR ontology
• AIR examples and online demos
• Overview paper describing language and prototype implementation: Lalana Kagal, Chris Hanson, and Daniel Weitzner, Integrated Policy Explanations via Dependency Tracking, IEEE Policy 2008
• Draft of AIR Language Formalization
• Examples of how N3Logic handles variables
• AIR Tutorial at RPI
• TAMI project: project that uses AIR
• Chris Hanson, Tim Berners-Lee, Lalana Kagal, Gerald Jay Sussman, Daniel Weitzner. Data-Purpose Algebra: Modeling Data Usage Policies. Proceedings of the 2007 IEEE Workshop on Policies for Distributed Systems and Networks, Bologna, Italy, June 2007
• Turtle - Terse RDF Triple Language
• N3 - Design Issues of Notation 3