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.

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.

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 U is within policy2 and the scope of variable U2 is rule2

:policy2 a air:Policy;
   air:variable :U;
   air:rule :rule2.

:rule2 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, 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

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

Goal-rules are used to provide control over how forward chaining occurs and to restrict the search space. (Please refer to the AMORD paper for more information.) In the following example, a belief rule :ruleB has a nested goal rule r1 that controls the introduction of sub-class type inference. The outer rule fires whenever a sub-class relationship is believed, causing r1 to be enabled. R1 fires when there is a goal to show that some resource is a member of the class :V2, enabling the belief rule r2. R2 implements the implication "if a resource is a member of a subclass :V3, it's also a member of the containing class :V2".

:ruleB a air:Belief-rule;
	air:variable :V1, :V2, :V3, :V4;
	air:label "sub-class implication";
	air:pattern { :V3 rdfs:subClassOf :V2. };
	air:goal-rule	# sub-rule r1
	    [
	    air:pattern { :V1 a :V2. };
	    air:rule	# sub-rule r2
		    [
		    air:pattern { :V1 a :V3. };
		    air:assert { :V1 a :V2. };
		    ];
	    ].

The purpose of the goal rule r1 is to limit the deductions made by the system. If :ruleB were rewritten as a belief rule, as below, it would make all possible deductions of this kind, whether they were needed or not. The use of a goal rule instead limits the deductions to those actually asked for (specified as goals) rather than for every possible deduction.

:ruleB a air:Belief-rule;
	air:variable :V1, :V2, :V3;
	air:label "sub-class implication";
	air:pattern
	    {
	    :V3 rdfs:subClassOf :V2.
	    :V1 a :V3.
	    };
	air:assert { :V1 a :V2. }.

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

:policy3 air:rule :rule4.

:rule4 a air:Belief-rule;
   air:variable :U;
   air:label "AIRRule 4";
   air:pattern
      {
        :U a air:UseEvent;
           :refers-to [ a mit:ProxCardEvent ]
      };
    air:rule 
       [
         air:variable :A;
         air:label "NestedAIRRule";   
         air:pattern 
            {
              :U :actor :A.
              :A a :Student. 
            };
         air:assert { :U 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 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

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

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

:rule6 a air:Belief-rule;
   air:variable :U;
   air:variable :P;
   air:variable :AP;
   air:label "AIRRule 6";
   air:pattern
      {
        :U a air:UseEvent;
           :refers-to [ a mit:ProxCardEvent ];
           :purpose P;
        air:UseEvent :allowed-purposes :AP. 
        :P is-member-of :AP
      };
    air:assert { :U :validPurpose :rule6 }.

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 they have identical URIs or if they are related using owl:SameAs. Two resources are related with is-distinct-from property if there is an explicit declaration that they are related using owl:differentFrom. 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

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

References

• TAMI project: project that uses AIR
• AIR ontology
• Overview paper describing language and prototype implementation: Lalana Kagal, Chris Hanson, and Daniel Weitzner, Integrated Policy Explanations via Dependency Tracking, under review at IEEE Policy 2008
• 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
• N3 Rules - Experience with N3 rules