Service-Oriented Architecture Ontology Version 2.0 – Policy



Policies, the human actors defining them, and the things that they apply to are important aspects of any system, certainly also SOA systems with their many different interacting elements. Policies can apply to any element in a system. The concept of policy is captured by the Policy class and its relationships to the HumanActor and Thing classes.

This chapter describes the following classes of the ontology:

  • Policy

In addition, it defines the following properties:

  • appliesTo and isSubjectTo
  • setsPolicy and isSetBy

The Policy Class

<owl:Class rdf:about="#Policy">   <owl:disjointWith>     <owl:Class rdf:about="#InformationType"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceInterface"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Element"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Effect"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Event"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceContract"/>   </owl:disjointWith> </owl:Class>

A policy is a statement of direction that a human actor may intend to follow or may intend that another human actor should follow. Knowing the policies that apply to something makes it easier and more transparent to interact with that something. The concept of policy is captured by the Policy OWL class, which is illustrated below.

The Policy Class

Policy as a concept is generic and has relevance outside the domain of SOA. For the purposes of this SOA ontology it has not been necessary or relevant to restrict the generic nature of the Policy class itself. The relationships between Policy and HumanActor are of course bound by the SOA-specific restrictions that have been applied on the definition of HumanActor.

From a design perspective policies may have more granular parts or may be expressed and made operational through specific rules. We have chosen to stay at the concept level and not include such design aspects in the ontology.

Policy is distinct from all other concepts in this ontology, hence the Policy class is defined as disjoint with all other defined classes. In particular, Policy is disjoint with ServiceContract. While policies may apply to service contracts – such as security policies on who may change a given service contract – or conversely be referred to by service contracts as part of the terms, conditions, and interaction rules that interacting participants must agree to, service contracts are themselves not policies as they do not describe an intended course of action.

The appliesTo and isSubjectTo Properties

<owl:ObjectProperty rdf:about="#appliesTo">   <rdfs:domain rdf:resource="#Policy"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#isSubjectTo">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#appliesTo"/>   </owl:inverseOf> </owl:ObjectProperty>

Policies can apply to things other than elements; in fact, policies can apply to anything at all, including other policies. For instance, a security policy might specify which actors have the authority to change some other policy. The appliesTo property, and its inverse isSubjectTo, capture the abstract notion that a policy can apply to any instance of Thing. Note specifically that Element is a subclass of Thing, hence policies by inference can apply to any instance of Element.

In one direction, a policy can apply to zero (in the case where a policy has been formulated but not yet explicitly applied to anything), one, or more instances of Thing. Note that having a policy apply to multiple things does not mean that these things are the same, only that they are (partly) regulated by the same intent. In the other direction, an instance of Thing may be subject to zero, one, or more policies. Note that where multiple policies apply to the same instance of Thing this is often because the multiple policies are from multiple different policy domains (such as security and governance).

The SOA ontology does not attempt to enumerate different policy domains; such policy-focused details are deemed more appropriate for a policy ontology. It is worth pointing out that a particular policy ontology may also restrict (if desired) the kinds of things that policies can apply to.

The setsPolicy and isSetBy Properties

<owl:ObjectProperty rdf:about="#setsPolicy">   <rdfs:domain rdf:resource="#HumanActor"/>   <rdfs:range rdf:resource="#Policy"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#isSetBy">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#setsPolicy"/>   </owl:inverseOf> </owl:ObjectProperty>

The setsPolicy property, and its inverse isSetBy, capture the abstract notion that a policy can be set by one or more human actors.

In one direction, a policy can be set by zero (in the case where actors setting the policy by choice are not defined or captured), one, or more human actors. Note specifically that some policies are set by multiple human actors in conjunction, meaning that all these human actors need to discuss and agree on the policy before it can take effect. A real-world example would be two parents in conjunction setting policies for acceptable child behavior. In the other direction, a human actor may potentially set (or be part of setting) multiple policies.

The SOA ontology purposefully separates the setting of the policy itself and the application of the policy to one or more instances of Thing. In some cases these two acts may be inseparably bound together, yet in other cases they are definitely not. One such example is an overall compliance policy that is formulated at the corporate level yet applied by the compliance officer in each line of business.

Also, while a particular case of interest for this ontology is that where the provider of a service has a policy for the service, a policy for a service is not necessarily owned by the provider. For example, government food and hygiene regulations (a policy that is law) cover restaurant services independently of anything desired or defined by the restaurant owner.


Car Wash Example

See The Washing Policies for the Policy aspect of the car wash example.