Service Oriented Architecture Ontology (SOA-O) – Introduction

Sources

Service Oriented Architecture Ontology version 1.0 – 2010
Service Oriented Architecture Ontology version 2.0 – 2014

Overview

The purpose of the SOA Ontology (SOA-O) is to develop and foster common understanding of the SOA in order to improve alignment between the business and information technology communities, and facilitate SOA adoption:

  1. The SOA-O defines the concepts, terminology, and semantics of SOA in both business and technical terms, in order to:
    1. Create a foundation for further work in domain-specific areas.
    2. Enable communications between business and technical people.
    3. Enhance the understanding of SOA concepts in the business and technical communities.
    4. Provide a means to state problems and opportunities clearly and unambiguously to promote mutual understanding.
    5. The SOA-O potentially contributes to model-driven SOA implementation.

    The OWL ontology is available online.

    The SOA-O is designed for use by:

    • Business people, to give them a deeper understanding of SOA concepts and how they are used in the enterprise and its environment.
    • Architects, as metadata for architectural artifacts.
    • Architecture methodologists, as a component of SOA meta-models.
    • System and software designers for guidance in terminology and structure.

    This standard defines a formal ontology for SOA. The ontology is represented in the Web Ontology Language (OWL) – using OWL-DL, one of three sub-languages that provides the greatest expressiveness possible while retaining computational completeness and decidability.

    The ontology contains classes and properties corresponding to the core concepts of SOA. The formal OWL definitions are supplemented by natural language descriptions of the concepts, with graphic illustrations of the relations between them, and with examples of their use. For purposes of exposition, the ontology also includes UML diagrams that graphically illustrate its classes and properties of the ontology. The natural language and OWL definitions contained in this specification constitute the authoritative definition of the ontology; the diagrams are for explanatory purposes only.

    SOA Ontology - UML Class Diagram

    Figure 1. SOA-O – Graphical Overview.

    The class hierarchy is as follows:

    SOA Ontology Class Hierarchy

    Figure 2. The SOA-O Class Hierarchy.

  2. Applications

    The SOA-O was developed in order

    1. to aid understanding, and
    2. potentially to be a basis for model-driven implementation.

    To aid understanding, this specification can simply be read. To be a basis for model-driven implementation, it should be applied to particular usage domains and application to example usage domains will aid understanding.

    The SOA-O can be used as a core for domain-specific ontologies that apply to the use of the SOA in particular sectors of commerce and industry. The ontology is applied to a particular usage domain by adding SOA OWL class instances of things in that domain. This is sometimes referred to as "populating the ontology". In additional, an application can add definitions of new classes and properties, can import other ontologies into the SOA-O, and can import the SOA-O into other ontologies.

    The ontology defines the relations between terms, but does not prescribe exactly how they should be applied.

    Previous: SOA-RM Service Oriented Architure Reference Model – Introduction
    Next: SOA-O – Element and System Classes

SOA-O – Element and System Classes

Element and system are two of the core concepts of the SOA Ontology (SOA-O).

Here we will describe two classes:

  1. Element
  2. System

and the following properties:

  1. uses and usedBy
  2. represents and representedBy

Element Class

An element is an opaque entity that is indivisible at a given level of abstraction. The element has a clearly defined boundary. The concept of element is captured by the Element OWL class.

SOA Ontology - Class Element

Figure 1. The SOA-O Element Class.

In the SOA-O, we consider in detail only functional elements that belong to the SOA domain.

There are other kinds of elements than members of the four named subclasses (System, HumanActor, Task, and Service). Examples of other kinds of elements are things like software components or technology components.

uses and usedBy Properties

Elements may use other elements in various ways. An element uses another element if it interacts with it in some fashion. Interacts here is interpreted very broadly:

  • An element simply being a member of (or used by) some system
  • An element interacting with (using) another element (such as a service) in an ad hoc fashion
  • Strongly coupled dependency in a composition

The uses, and its inverse usedBy, capture the abstract notion of an element using another. These properties capture not just transient relations. Instantiation of the property can include “uses at this instant”, “has used”, and “may in future use”.

We have chosen not to attempt to enumerate and formally define the multitude of different possible semantics of a uses relationship. We leave the semantic interpretations to a particular sub-domain, application, or even design approach.

Example

Using an organizational example, typical instances of Element are organizational units and people. Whether to perceive a given part of an organizational unit or as the set of people within that organizational unit is an important choice of abstraction level:

  • Inside the boundary of the organizational unit, we want to express the fact that an organizational unit uses the people that are members of it. Note that the same person can be a member of (be used by) multiple organizational units.
  • Outside the boundary, the internal structure of an organizational unit must remain opaque to an external observer, as the enterprise wants to be able to change the people within the organizational unit without having to change the definition of the organizational unit itself.

This simple example expresses that some elements have an internal structure. In fact, from an internal perspective, they are an organized collection of other simpler things (captured by Class System).

System Class 

A system is an organized collection of other things. Things in a system collection are instances of Element, each such instance being used by the system. The concept of system is captured by the System OWL Class:

SOA Ontology - Class System

Figure 2. The SOA-O System Class.

The SOA-O considers in detail only functional systems that belong to the SOA domain. Note that a fully described instance of System should have by its nature (as a collection) a uses relationship to at least one instance of Element.

Since System is a subclass of Element, all systems have a boundary and are opaque to an external observer (black box view). This excludes from the System class any structure that has no defined boundary.

Having System as a subclass of Element allows us to express the notion of “systems of systems” – the lower-level levels are elements used by the higher-level system.

At the same time as supporting an external viewpoint (black box view), all systems must also support an internal viewpoint (white box view) expressing how they are an organized collection. E.g. for the notion of a service, this would typically correspond to a service specification view versus a service realization view (similar to the way that SoaML defines services as having both a black box/specification part and a white box/realization part).

It is important to realize that even though systems using elements express an important aspect of the uses property, it is not necessary to “invent” a system just to express that some element uses another. In fact, even for systems, we may need to be able to express that they can use elements outside their own boundary – though this in many cases will preferably be expressed not at the system level, but rather by an element of the system using that external Element instance.

System is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be collections of other things. System is specifically not defined as disjoint with the HumanActor class since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.

Example

Continuing the organizational example from above, we can now express that an organizational unit as an instance of System has the people in it as members (and instances of Element).

Service Composition

Using a service composition example, services A and B are instances of Element and the composition of A and B is an instance of System (that uses A and B). It is important to realize that the act of composing is different than composition as a thing – it is in the latter sense that we are using the term composition here. See below for a formal definition of the concepts of service and service composition.

represents and representedBy Properties

The environment described by an SOA is intrinsically hierarchically composite – the elements of SOA systems can be repeatedly composed to ever higher levels of abstraction.

One aspect of this has already been addressed by the uses and usedBy properties – we can use these properties to express the notion of systems of systems. This is still a very concrete relationship though, and does not express the concept of architectural abstraction. We find the need for architectural abstraction in various places, such as a role representing the people playing that role, an organizational unit representing the people within it (subtly different from that same organizational unit using the people within it, as the represents relationship indicates the organizational unit using the people within it, as the represents relationship indicates the organizational unit as a substitute interaction point, an architectural building block representing an underlying construct (e.g. important to enterprise architects wanting to explicitly distinguish between constructs and building blocks), and an Enterprise Service Bus (ESB) representing the services that are accessible through it (for instance, relevant when explicitly modeling operational interaction and dependencies). The concept of such an explicitly changing viewpoint, or level of abstraction, is captured by the represents and representedBy properties:

SOA Ontology - Properties represents and representedBy

Figure 3. The SOA-O represents and representedBy Properties.

It is important to understand the distinction between using an element (E1) and using another element (E2) that represents E1. If E1 changes, then anyone using E1 directly would experience a change, but someone using E2 would not experience any change.

When applying the architectural abstraction via the represents property there are three different architectural choices that can be made:

  1. An element represents another element in a very literal way, simply by hiding the existence of that element and any changes to it. There will be a one-to-one relationship between the instance of Element and the (different) instance of Element that it represents. E.g. a broker acting as an intermediary between a seller (who does not wish to be known) and a buyer.
  2. An element represents a particular aspect of another element. There will be a many-to-one relationship between many instances of Element (each of which represents a different aspect), and one (different) instance of Element. A simple real-world example is the notion that the same person can play (be represented by) many different roles.
  3. An element is an abstraction that can represent many other elements. There will be a one-to-many relationship between one instance of Element (as an abstraction) and many other instances of Element. A simple real-world example is the notion of an architectural blueprint representing an abstraction of many different buildings being built according to that blueprint.

Note that in most cases an instance of Element will represent only one kind of thing. Specifically, an instance of Element will typically represent instances of at most one of the classes System, Service, HumanActor, and Task (with the exception of the case where the same thing is both an instance of System and an instance of Actor).

Example

Assume a company wants to form a new organizational unit (O1). There are two ways of doing this:

  1.  Define the new organization directly as a collection of people P1, P2, P3, and P4. This means that the new organization is perceived to be a leaf in the organizational hierarchy, and that any exchange of personnel means that its definition needs to change.
  2. Define the new organization as a higher-level organizational construct, joining together two existing organizations O3 and O4. Coincidentally, O3 and O4 between them may have the same four people P1, P2, P3, P4, but the new organization really doesn’t know, and any member of O3 and O4 can be changed without needing to change the definition of the new organization. Furthermore, any member of O3 is intrinsically not working in the same organization as the members of O4 (in fact, need not even be aware of them) – contrary to the first option where P1, P2, P3, P4 are all colleagues in the same new organization. In this way the abstraction aspect of the represent property induces an important difference in the semantics of the collection defining the new organization. Any instantiation of the ontology can and should use the represents and representedBy properties to define the implied semantics and lines of visibility/change crisply.

Previous: Service Oriented Architecture Ontology – SOA-O – Introduction
Next: SOA-O – HumanActor and Task Classes

SOA-O – HumanActor and Task Classes

People, organizations, and the things they do are important aspects of SOA systems. HumanActor and Task capture this as another set of core concepts of the ontology. Both are concepts that are generic and have relevance outside the domain of SOA. For the purposes of the SOA-O we have chosen to give them specific scope in that tasks are intrinsically atomic (corresponding to, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of task) and human actors are restricted to people and organizations.

This chapter describes the following classes of the SOA-O:

  • HumanActor
  • Task

In addition, it defines the following properties:

  • does and doneBy

HumanActor Class

 

A human actor is a person or an organization. The concept of human actor is captured by the HumanActor OWL class, which is illustrated below:

SOA-O - HumanActor Class

Figure 1. SOA-O HumanActor Class.

HumanActor is defined as disjoint with the Service and Task classes. Instances of these classes are considered not to be people or organizations. HumanActor is specifically not defined as disjoint with System since an organization in many cases is in fact just a particular kind of system. We choose not to define a special intersection class to represent this fact.

The uses and usedBy Properties Applied to HumanActor

In one direction, a human actor can itself use things such as services, systems, and other human actors. In the other direction, a human actor can, for instance, be used by another actor or by a system (as an element within that system such as a human actor in a process).

The represents and representedBy Properties Applied to HumanActor

Human actors are intrinsically part of systems that instantiate SOAs. Yet in many cases as an element of an SOA system we talk about not the specific person or organization, rather an abstract representation of them that participates in processes, provides services, etc. In other words, we talk about elements representing human actors.

As examples, a broker (instance of HumanActor) may represent a seller (instance of HumanActor) who wishes to remain anonymous, a role (instance of Element) may represent (the role aspect of) multiple instances of HumanActor, and an organizational unit (instance of HumanActor) may represent the many people (all instances of HumanActor) that are part of it.

Note that we have chosen not to define a “role class”, as we believe that using Element with the represents property is a more general approach which does not limit the ability to also define role-based systems. For all practical purposes there is simply a “role subclass” of Element, a subclass that we have chosen not to define explicitly.

Organizational Example

Continuing the organizational example, we can now express that P1 (John), P2 (Jack), P3 (Joe), and P4 (Mary) as instances of Element are in fact (people) instances of HumanActor. We can also express (if we so choose) that all of O1 (CarWashBusiness), O3 (CarWash), and O4 (Administration) are (organization) human actors from an action perspective at the same time that they are systems from a collection/composition perspective.

Task Class

A task is an atomic action which accomplishes a defined result. Tasks are done by people or organizations, specifically by instances of HumanActor.

The Business Process Modeling Notation (BPMN) 2.0 defines task as follows: “A task is an atomic Activity within a Process flow. A task is used when the work in the process cannot be broken down to a finer level of detail. Generally, an end-user and/or applications are used to perform the task when it is executed.” For the purposes of the ontology we have added precision by formally separating the notion of doing from the notion of performing. Tasks are (optionally) done by human actors, furthermore (as instances of Element) tasks can use services that are performed by technology components.

The concept of task is captured by the Task OWL class, which is illustrated below:

SOA-O - Task Class

Figure 2. SOA-O Task Class.

Task is defined as disjoint with the System, Service, and HumanActor classes. Instances of these classes are considered not to be atomic actions.

does and doneBy Properties

Tasks are naturally thought of as being done by people or organizations. If we think of tasks as being the actual things done, then the natural cardinality is that each instance of Task is done by at most one instance of HumanActor. Due to the atomic nature of instances of Task we rule out the case where such an instance is done jointly by multiple instances of HumanActor. The cardinality can be zero if someone chooses not to instantiate all possible human actors. On the other hand, the same instance of HumanActor can (over time) easily do more than one instance of Task. The does property, and its inverse doneBy, capture the relation between a human actor and the tasks it performs.

uses and usedBy Applied to Task

In one direction, the most common case of a task using another element is where an automated task uses a service as its realization. In the other direction, a task can, for instance, be used by a system (as an element within that system, such as a task in a process).

represents and representedBy Applied to Task

As mentioned in the introduction to this section, tasks are intrinsically part of SOA systems. Yet in many cases as an element of an SOA system we talk about not the actual thing being done, rather an abstract representation of it that is used as an element in systems, processes, etc. In other words, we talk about elements representing tasks.

As a simple example, an abstract activity in a process model (associated with a role) may represent a concrete task (done by a person fulfilling that role). Note that due to the atomic nature of a task it does not make sense to talk about many elements representing different aspects of it.

Organizational Example

Continuing the organizational example from above, we can now express which tasks that are done by human actors (people) P1, P2, P3, and P4, and how those tasks can be elements in bigger systems that describe things such as organizational processes.

Previous: SOA-O – Element and System Classes
Next: SOA-O – ServiceClass

SOA-O – Service Class

Service is another core concept of this ontology. It is a concept that is fundamental to SOA and always used in practice when describing or engineering SOA systems, yet it is not easy to define formally. The SOA-O is based on the following definition of service:

“A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers.”

This corresponds to the existing official Open Group definition of the term.

The word “activity” in the definition above is here used in the general English language sense of the word, not in the process-specific sense of that same word (i.e., activities are not necessarily process activities). The SOA-O purposefully omits “business” as an intrinsic part of the definition of service. The reason for this is that the notion of business is relative to a person’s viewpoint – as an example, one person’s notion of IT is another person’s notion of business (the business of IT). Service as defined by the ontology is agnostic to whether the concept is applied to the classical notion of a business domain or the classical notion of an IT domain.

Other current SOA-specific definitions of the term service include:

  • “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.” (Source: OASIS SOA Reference Model)
  • “A capability offered by one entity or entities to others using well-defined ‘terms and conditions’ and interfaces.” (Source: OMG SoaML Specification)

Within the normal degree of precision of the English language, these definitions are not contradictory; they are stressing different aspects of the same concept. All three definitions are SOA-specific though, and represent a particular interpretation of the generic English language term service.

A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers. The concept of service is captured by the Service OWL class:

SOA-O - Service Class

Figure 1. SOA-O Service Class.

In the context of the SOA-O we consider only SOA-based services. Other domains, such as Integrated Service Management, can have services that are not SOA-based and hence are outside the intended scope of the SOA ontology.

Service is defined as disjoint with the System, Task, and HumanActor classes. Instances of these classes are considered not to be services themselves, even though they may provide capabilities that can be offered as services.

performs and performedBy Properties

As a service itself is only a logical representation, any service is performed by something. The something that performs a service must be opaque to anyone interacting with it, an opaqueness which is the exact nature of the Element class. This concept is captured by the performs and performedBy properties as illustrated in The Service Class (Figure 1). This also captures the fact that services can be performed by elements of other types than systems. This includes elements such as software components, human actors, and tasks.

Note that the same instance of Service can be performed by many different instances of Element. As long as the service performed is the same, an external observer cannot tell the difference (for contractual obligations, SLAs, etc. Conversely, any instance of Element may perform more than one service or none at all.

While a service can be performed by other elements, the service itself (as a purely logical representation) does not perform other services.

Service Consumers and Service Providers

Terminology used in an SOA environment often includes the notion of service providers and service consumers. There are two challenges with this terminology:

  • It does not distinguish between the contractual obligation aspect of consume/provide and the interaction aspect of consume/provide. A contractual obligation does not necessarily translate to an interaction dependency, if for no other reason than because the realization of the contractual obligation may have been sourced to a third party.
  • The above are the reasons why the ontology has chosen not to adopt consume and provide as core concepts, rather instead allows consume or provide terms used with contractual obligations and/or interaction rules described by service contracts. In its simplest form, outside the context of a formal service contract, the interaction aspect of consuming and providing services may even be expressed simply by saying that some element uses (consumes) a service or that some element performs (provides) a service.
  • Consuming or providing a service is a statement that only makes sense in context – either a contractual context or an interaction context. These terms are consequently not well suited for making statements about elements and services in isolation.

uses and usedBy Properties Applied to Service

In one direction, it does not really make sense to talk about a service that uses another element. While the thing that performs the service might very well include the use of other elements (and certainly will in the case of service composition), the service itself (as a purely logical representation) does not use other elements.

In the other direction, we find the most common of all interactions in an SOA environment: the notion that some element uses a service by interacting with it. Note that from an operational perspective this interaction actually reaches somewhat beyond the service itself by involving the following typical steps:

  • Picking the service to interact with (this statement is agnostic as to whether this is done dynamically at runtime or statically at design and/or construct time)
  • Picking an element that performs that service (in a typical SOA environment, this is most often done “inside” an Enterprise Service Bus (ESB))
  • Interacting with the chosen element (that performs the chosen) service (often also facilitated by an ESB)

represents and representedBy Properties Applied to Service

Concepts such as service mediations, service proxies, ESBs, etc. are natural to those practitioners that describe and implement the operational aspects of SOA systems. From an ontology perspective all of these can be captured by some other element representing the service – a level of indirection that is critical when we do not want to bind operationally to a particular service endpoint, rather we want to preserve loose-coupling and the ability to switch embodiments as needed. Note that by leveraging the represents and representedBy properties in this fashion we additionally encapsulate the relatively complex operational interaction pattern that was described in the section above (picking the service, picking an element that performs the service, and interacting with that chosen element).

While a service being represented by something else is quite natural, it is harder to imagine what the service itself might represent. To some degree we have already captured the fact that a service represents any embodiment of it, only we have chosen to use the performs and performedBy properties to describe this rather than the generic represents and representedBy properties. As a consequence, we do not expect practical applications of the ontology to have services represent anything.

Exemplifying the Difference between Doing a Task and Performing a Service

The distinction between a human actor doing a task and an element (technology, human actor, or other) performing a service is important. The human actor doing the task has the responsibility that it gets done, yet may in fact in many cases leverage some service to achieve that outcome:

  • John is an instance of HumanActor.
  • WashWindows is an instance of Task and is done by John.
  • SoapWater is an instance of Service.
  • WaterTap is an instance of Element.
  • WaterTap performs SoapWater.
  • John uses SoapWater (to do WashWindows).

Note how clearly SoapWater does not do WashWindows, nor does WaterTap do WashWindows.

Previous: SOA-O – HumanActor and Task Classes
Next: SOA-O – ServiceContract and Effect Classes

SOA-O ServiceContract and Effect Classes

ServiceContract Class

In many cases, specific agreements are needed in order to define how to use a service. This can either be because of a desire to regulate such use or can simply be because the service will not function properly unless interaction with it is done in a certain sequence. A service contract defines the terms, conditions, and interaction rules that interacting participants must agree to (directly or indirectly). A service contract is binding on all participants in the interaction, including the service itself and the element that provides it for the particular interaction in question. The concept of service contract is captured by the ServiceContract OWL class:

SOA-O - ServiceContract Class

Figure 1. SOA-O ServiceContract Class.

interactionAspect and legalAspect Datatype Properties

Service contracts explicitly regulate both the interaction aspects (see the hasContract and isContractFor properties) and the legal agreement aspects (see the involvedParty and isPartyTo properties) of using a service. The two types of aspects are formally captured by defining the interactionAspect and legalAspect datatype properties on the ServiceContract class. Note that the second of these attributes, the legal agreement aspects, includes concepts such as Service-Level Agreements (SLAs).

If desired, it is possible as an architectural convention to split the interaction and legal aspects into two different service contracts. Such choices will be up to any application using this ontology.

hasContract and isContractFor Properties

The hasContract property, and its inverse isContractFor, capture the abstract notion of a service having a service contract. Anyone wanting to use a service must obey the interaction aspects (as defined in the interactionAspect datatype property) of any service contract applying to that interaction. In that fashion, the interaction aspects of a service contract are contextindependent; they capture the defined or intrinsic ways in which a service may be used.

By definition, any service contract must be a contract for at least one service. It is possible that the same service contract can be a contract for more than one service; for instance, in cases where a group of services share the same interaction pattern or where a service contract (legally – see the involvesParty and isPartyTo properties below) regulates the providing and consuming of multiple services.

involvesParty and isPartyTo Properties

In addition to the rules and regulations that intrinsically apply to any interaction with a service (the interaction aspect of service contracts captured in the interactionAspect datatype property) there may be additional legal agreements that apply to certain human actors and their use of services. The involvesParty property, and its inverse isPartyTo, capture the abstract notion of a service contract specifying legal obligations between human actors in the context of using the one or more services for which the service contract is a contract.

While the involvesParty and isPartyTo properties define the relationships to human actors involved in the service contract, the actual legal obligations on each of these human actors is defined in the legalAspect datatype property on the service contract. This includes the ability to define who is the provider and who is the consumer from a legal obligation perspective.

There is a many-to-many relationship between service contracts and human actors. A given human actor may be party to none, one, or many service contracts. Similarly, a given service contract may involve none, one, or multiple human actors (none in the case where that particular service contract only specifies the interactionAspect datatype property). Note that it is important we allow for sourcing contracts where there is a legal agreement between human actor A and human actor B (both of which are party to a service contract), yet human actor B has sourced the performing of the service to human actor C (aka human actor C performs the service in question, not human actor B).

The involvesParty property together with the legalAspect datatype property on ServiceContract capture not just transient obligations. They include the ability to express “is obliged to at this instant”, “was obliged to”, and “may in future be obliged to”.

Effect Class

Interacting with something performing a service has effects. These comprise the outcome of that interaction, and are how a service (through the element that performs it) delivers value to its consumers. The concept of effect is captured by the Effect OWL class:

SOA-O Effect Class

Figure 2. SOA-O Effect Class.

Note that the Effect class purely represents how results or value is delivered to someone interacting with a service. Any possible internal side-effects are explicitly not covered by the Effect class.

Effect is defined as disjoint with the ServiceInterface class. (The ServiceInterface class is defined later in this document.) Interacting with a service through its service interface can have an outcome or provide a value (an instance of Effect), but the service interface itself does not constitute that outcome or value.

specifies and isSpecifiedBy Properties

While a service intrinsically has an effect every time someone interacts with it, in order to trust the effect to be something in particular, the effect needs to be specified as part of a service contract. The specifies property, and its inverse isSpecifiedBy, capture the abstract notion of a service contract specifying a particular effect as part of the agreement for using a service. Note that the specified effect can apply to both the interactionAspect datatype property (simply specifying what will happen when interacting with the service according to the service contract) and the legalAspect datatype property (specifying a contractually promised effect).

Anyone wanting a guaranteed effect of the interaction with a given service must ensure that the desired effect is specified in a service contract applying to that interaction. By definition, any service contract must specify at least one effect. In the other direction, an effect must be an effect of at least one service contract; this represents that fact that we have chosen only to formalize those effects that are specified by service contracts (and not all intrinsic effects of all services).

ServiceContract Examples

Service-Level Agreements

A Service-Level Agreement (SLA) on a service has been agreed by organizations A and B. It is important to realize that an SLA always has a context of the parties that have agreed to it, involving at a minimum one legal “consumer” and one legal “provider”. This can be represented in the ontology as follows:

  • A and B are instances of HumanActor.
  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the SLA.

Service Sourcing

Organizations A and B have agreed on B providing certain services for A, yet B wants to source the actual delivery of those services to third-party C. This can be represented in the ontology as follows:

  • A, B, and C are instances of HumanActor.
  • Service is an instance of Service.
  • C provides Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the legal obligation of B to provide Service for A.

Previous: SOA-O – Service Class
Next: SOA-O- ServiceInterface and InformationType Classes

SOA-O ServiceInterface and Informationtype Classes

ServiceInterface Class

An important characteristic of services is that they have simple, well-defined interfaces. This makes it easy to interact with them, and enables other elements to use them in a structured manner. A service interface defines the way in which other elements can interact and exchange information with a service. This concept is captured by the ServiceInterface OWL class:

SOA-O ServiceInterface Class
Figure 1. SOA-O ServiceInterface Class.

The concept of an interface is in general well understood by practitioners, including the notion that interfaces define the parameters for information passing in and out of them when invoked. What differs from domain to domain is the specific nature of how an interface is invoked and how information is passed back and forth. Service interfaces are typically, but not necessarily, message-based (to support loose-coupling). Furthermore, service interfaces are always defined independently from any service implementing them (to support loose-coupling and service mediation).

From a design perspective interfaces may have more granular operations or may be composed of other interfaces. We have chosen to stay at the concept level and not include such design aspects in the ontology.

ServiceInterface is defined as disjoint with the Service, ServiceContract, and Effect classes. Instances of these classes are considered not to define (by themselves) the way in which other elements can interact and exchange information with a service. Note that there is a natural synergy between ServiceInterface and the interactionAspect datatype property on ServiceContract, as the latter defines any multi-interaction and/or sequencing constraints on how to use a service through interaction with its service interfaces.

Constraints Datatype Property

The Constraints datatype property on ServiceInterface captures the notion that there can be constraints on the allowed interaction such as only certain value ranges allowed on given parameters. Depending on the nature of the service and the service interface in question, these constraints may be defined either formally or informally (the informal case being relevant at a minimum for certain types of real-world services).

hasInterface and isInterfaceOf Properties

The hasInterface property, and its inverse isInterfaceOf, capture the abstract notion of a service having a particular service interface.

In one direction, any service must have at least one service interface; anything else would be contrary to the definition of a service as a representation of a repeatable activity that has a specified outcome and is a ‘black box’ to its consumers. In the other direction, there can be service interfaces that are not yet interfaces of any defined services. Also, the same service interface can be an interface of multiple services. The latter does not mean that these services are the same, nor even that they have the same effect; it only means that it is possible to interact with all these services in the manner defined by the service interface in question.

InformationType Class

A service interface can enable another element to give information to or receive information from a service (when it uses that service); specifically the types of information given or received. The concept of information type is captured by the InformationType OWL class:

SOA-O InformationType Class

Figure 2. SOA-O InformationType Class

In any concrete interaction through a service interface the information types on that interface are instantiated by information items, yet for the service interface itself it is the types that are important. Note that the constraints datatype property on ServiceInterface, if necessary, can be used to express constraints on allowed values for certain information types.

hasInput and isInputAt Properties

The hasInput property, and its inverse isInputAt, capture the abstract notion of a particular type of information being given when interacting with a service through a service interface.

Note that there is a many-to-many relationship between service interfaces and input information types. A given information type may be input at many service interfaces or none at all. Similarly, a given service interface may have many information types as input or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).

hasOutput and isOutputAt Properties

The hasOutput property, and its inverse isOutputAt, capture the abstract notion of a particular type of information being received when interacting with a service through a service interface.

Note that there is a many-to-many relationship between service interfaces and output information types. A given information type may be output at many service interfaces or none at all. Similarly, a given service interface may have many information types as output or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).

Examples

Interaction Sequencing

A service contract on a service expresses that the services interfaces on that service must be used in a certain order:

  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • X is an instance of ServiceInterface.
  • X isInterfaceOf Service.
  • Y is an instance of ServiceInterface.
  • Y isInterfaceOf Service.

The interactionAspect datatype property on ServiceContract describes that X must be used before Y may be used.

Previous: SOA-O – ServiceContract and Effect Classes
Next: SOA-O – Composition Class

SOA-O Composition Class

The notion of composition is a core concept of SOA. Services can be composed of other services. Processes are composed of human actors, tasks, and possibly services. Experienced SOA practitioners intuitively apply composition as an integral part of architecting, designing, and realizing SOA systems; in fact, any well structured SOA environment is intrinsically composite in the way services and processes support business capabilities. What differs from practitioner to practitioner is the exact nature of the composition – the composition pattern being applied.

A composition is the result of assembling a collection of things for a particular purpose. Note in particular that we have purposefully distinguished between the act of composing and the resulting composition as a thing, and that it is in the latter sense we are using the concept of composition here. The concept of composition is captured by the Composition OWL class:

SOA-O Composition Class

Figure 1. SOA-O Composition Class.

Being intrinsically (also) an organized collection of other, simpler things, the Composition class is a subclass of the System class. While a composition is always also a system, a system is not necessarily a composition in that it is not necessarily a result of anything – note here the difference between a system producing a result and the system itself being a result. A perhaps more tangible difference between a system and a composition is that the latter must have associated with it a specific composition pattern that renders the composition (as a whole) as the result when that composition pattern is applied to the elements used in the composition. One implication of this is that there is not a single member of a composition that represents (as an element) that composition as a whole; in other words, the composition itself is not one of the things being assembled. On the other hand, composition is in fact a recursive concept (as are all subclasses of System) – being a system, a composition is also an element which means that it can be used by a higher-level composition.

In the context of the SOA-O we consider in detail only functional compositions that belong to the SOA domain. Note that a fully described instance of Composition must have by its nature a uses relationship to at least one instance of Element. (It need not necessarily have more than one as the composition pattern applied may be, for instance, simply a transformation.) Again (as for System) it is important to realize that a composition can use elements outside its own boundary.

Since Composition is a subclass of Element, all compositions have a boundary and are opaque to an external observer (black box view). The composition pattern in turn is the internal viewpoint (white box view) of a composition. As an example, for the notion of a service composition this would correspond to the difference between seeing the service composition as an element providing a (higher-level) service or seeing the service composition as a composite structure of (lower-level) services.

compositionPattern Datatype Property

As discussed above, any composition must have associated with it a specific composition pattern, that pattern describing the way in which a collection of elements is assembled to a result. The concept of a composition pattern is captured by the compositionPattern datatype property. Note that even though certain kinds of composition patterns are of special interest within SOA, the compositionPattern datatype property may take any value as long as that value describes how to assemble the elements used by the composition with which it is associated.

The Orchestration Composition Pattern

One kind of composition pattern that has special interest within SOA is an orchestration. In an orchestration (a composition whose composition pattern is an orchestration), there is one particular element used by the composition that oversees and directs the other elements. Note that the element that directs an orchestration by definition is different than the orchestration (Composition instance) itself.

Think of an orchestrated executable workflow as an example of an orchestration. The workflow construct itself is one of the elements being used in the composition, yet it is different from the composition itself – the composition itself is the result of applying (executing) the workflow on the processes, human actors, services, etc. that are orchestrated by the workflow construct.

A non-IT example is the foreman of a road repair crew. If the foreman chooses to exert direct control over the tasks done by his crew, than the resulting composition becomes an orchestration (with the foreman as the director and provider of the composition pattern). Note that under other circumstances, with a different team composition model, a road repair crew can also act as a collaboration or a choreography. (See below for definitions of collaboration and choreography.) As the last example clearly shows, using an orchestration composition pattern is not a guarantee that “nothing can go wrong”. That would, in fact, depend on the orchestration director’s ability to handle exceptions.

The Choreography Composition Pattern

Another kind of composition pattern that has special interest within SOA is a choreography. In a choreography (a composition whose composition pattern is a choreography) the elements used by the composition interact in a non-directed fashion, yet with each autonomous member knowing and following a predefined pattern of behavior for the entire composition.

Think of a process model as an example of a choreography. The process model does not direct the elements within it, yet does provide a predefined pattern of behavior that each such element is expected to conform to when “executing”.

The Collaboration Composition Pattern

A third kind of composition pattern that has special interest within SOA is a collaboration. In a collaboration (a composition whose composition pattern is a collaboration) the elements used by the composition interact in a non-directed fashion, each according to their own plans and purposes without a predefined pattern of behavior. Each element simply knows what it has to do and does it independently, initiating interaction with the other members of the composition as applicable on its own initiative. This means that there is no overall predefined “flow” of the collaboration, though there may be a run-time “observed flow of interactions”.

A good example of a collaboration is a work meeting. There is no script for how the meeting will unfold and only after the meeting has concluded can we describe the sequence of interactions that actually occurred.

orchestrates and orchestratedBy Properties

As defined above, an orchestration has one particular element that oversees and directs the other elements used by the composition. This type of relationship is important enough that we have chosen to capture the abstract notion in the orchestrates property and its inverse orchestratedBy.

In one direction, a composition has at most one element that orchestrates it, and the cardinality can only be one (1) if in fact the composition pattern of that composition is an orchestration. In the other direction, an element can orchestrate at most one composition which then must have an orchestration as its composition pattern.

Note that in practical applications of the ontology, even though Service is a subclass of Element, a service (as a purely logical representation) is not expected to orchestrate a composition.

Previous: SOA-O ServiceInterface and InformationType Classes
Next: SOA-O ServiceComposition and Process Classes

SOA-O ServiceComposition and Process Classes

ServiceComposition Class

A key SOA concept is the notion of service composition, the result of assembling a collection of services in order to perform a new higher-level service. The concept of service composition is captured by the ServiceComposition OWL class:

SOA-O ServiceComposition Class

Figure 1. SOA-O ServiceComposition Class.

As a service composition is the result of assembling a collection of services, ServiceComposition is naturally a subclass of Composition.

A service composition may, and typically will, add logic (or even “code”) via the composition pattern. Note that a service composition is not the new higher-level service itself (due to the System and Service classes being disjoint); rather it performs (as an element) that higher-level service.

Process Class

Another key SOA concept is the notion of process. A process is a composition whose elements are composed into a sequence or flow of activities and interactions with the objective of carrying out certain work. This definition is consistent with, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of a process. The concept of process is captured by the Process OWL class:

SOA-O Process Class

Figure 2. SOA-O Process Class.

Elements in process compositions can be things like human actors, tasks, services, other processes, etc. A process always adds logic via the composition pattern; the result is more than the parts. According to their collaboration pattern, processes can be:

  • Orchestrated: When a process is orchestrated in a business process management system, then the resulting IT artifact is in fact an orchestration; i.e., it has an orchestration collaboration pattern. This type of process is often called a process orchestration.
  • Choreographed: For example, a process model representing a defined pattern of behavior. This type of process is often called a process choreography.
  • Collaborative: No (pre)defined pattern of behavior (model); the process represents observed (executed) behavior.

Examples

Simple Service Composition Example

Using a service composition example, services A and B are instances of Service and the composition of A and B is an instance of ServiceComposition (that uses A and B):

  • A and B are instances of Service.
  • X is an instance of ServiceComposition.
  • X uses both A and B (composes them according to its service composition pattern).

Note that there are various ways in which the service composition pattern can compose A and B, all of which are relevant in one situation or another. For example, interfaces of X may or may not include some subset of the interfaces of A and B. Furthermore, the interfaces of A and B may or may not also be (directly) invocable without going through X – that is a matter of the service contracts and/or access policies that apply to A and B. Finally, X may also use other elements that are not services at all (examples are composition code, adaptors, etc.).

Process Example

Using a process example, tasks T1 and T2 are instances of Task, roles R1 and R2 are instances of Element, and the composition of T1, T2, R1, and R2 is an instance of Process (that uses T1, T2, R1, and R2):

  • T1 and T2 are instances of Task.
  • R1 and R2 are instances of Element.
  • Y is an instance of Process.
  • Y uses all of T1, T2, R1, and R2 (composes them according to its process composition pattern).

Process and Service Composition Example

Elaborating on the process example above, if T1 is done using service S then:

  • S is an instance of Service.
  • T1 uses S.

Note that depending on the particular design approach chosen (and the resulting composition pattern), Y may or may not use S directly. This depends on whether Y carries the binding between T1 and S or whether that binding is encapsulated in T1.

Previous: SOA-O Composition Class
Next: SOA-O Policy Class

SOA-O Policy Class

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.

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:

SOA-O Policy Class

Figure 1. SOA-O 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.

appliesTo and isSubjectTo Properties

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.

setsPolicy and isSetBy Properties

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.

Previous: SOA-O ServiceComposition and Process Classes
Next: SOA-O Event Class

SOA-O Event Class

An event is something that happens, to which an element may choose to respond. Events can be responded to by any element. Similarly, events may be generated (emitted) by any element. Knowing the events generated or responded to by an element makes it easier and more transparent to interact with that element. Note that some events may occur whether generated or responded to by an element or not. The concept of event is captured by the Event OWL class:

SOA-O Event Class

Figure 1. SOA-O Event Class.

Event as a concept is generic and has relevance to the domain of SOA as well as many other domains. For the purposes of this ontology, event is used in its generic sense.

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

generates and generatedBy Properties

Events can, but need not necessarily, be generated by elements. The generates property, and its inverse generatedBy, capture the abstract notion that an element generates an event.

Note that the same event may be generated by many different elements. Similarly, the same element may generate many different events.

respondsTo and respondedToBy Properties

Events can, but need not necessarily, be responded to by elements. The respondsTo property, and its inverse respondedToBy, capture the abstract notion that an element responds to an event.

Note that the same event may be responded to by many different elements. Similarly, the same element may respond to many different events.

Previous: SOA-O Policy Class
Next: Service Oriented Architecture Modeling Language (SoaML) – Introduction

A Vocabulary of Government Service – Part II

A Second Cycle of Developing a Vocabulary of Government Service

At the end of our first cycle of developing a vocabulary of government service, we had arrived at the following Graph:

Source Node Target Node Relation
Schema Thing hasSubclass
Thing Intangible hasSubclass
Intangible Service hasSubclass
Service GovernmentService hasSubclass
Thing additionalType hasProperty
Thing alternateName hasProperty
Thing description hasProperty
Thing image hasProperty
Thing name hasProperty
Thing potentialAction hasProperty
Thing sameAs hasProperty
Thing url hasProperty
Service availableChannel hasProperty
Service produces hasProperty
Service provider hasProperty
Service serviceArea hasProperty
Service serviceAudience hasProperty
Service serviceType hasProperty
GovernmentService serviceOperator hasProperty
additionalType URL hasRange
alternateName Text hasRange
availableChannel ServiceChannel hasRange
description Text hasRange
image URL hasRange
name Text hasRange
potentialAction Action hasRange
produces Thing hasRange
provider Organization hasRange
sameAs URL hasRange
serviceArea AdministrativeArea hasRange
serviceAudience Audience hasRange
serviceOperator Organization hasRange
serviceType Text hasRange
url URL hasRange

Table 1. Graph of a vocabulary of government service (Cycle 1).

Our second cycle through Schema.org to enrich  our vocabulary further looks to incorporate fully any Class that had defined the Range of some Property at the end of Cycle 1.  There are fifteen rows  in Table 1 where Relation = hasRange – though there are only eight unique Classes (URL, Text, ServiceChannel, Action, Thing, OrganizationAdministrativeArea, and Audience) occupying the Target Node.

Figure 1 illustrates our initial pathway from Schema -> Thing -> Intangible -> Service -> GovernmentService within Schema.org  – as well as the positions of these eight additional Classes within the Inheritance Hierarchy:

GovernmentService Classes at end of Cycle 1

Figure 1. Initial pathway from Schema -> Thing -> Intangible – > Service -> Government Service plus the position of Classes that defined the Range of Properties of Classes along this initial pathway.

These eight additional Classes fall into three categories:

  1. Classes that are included already in the vocabulary (e.g. Thing).
  2. Classes that are datatypes (e.g.  URL, Text) and whose inclusion would add no new Properties to the vocabulary.
  3. Classes that represent new entities (e.g. ServiceChannel, Action, OrganizationAdministrativeArea, and Audience) and whose inclusion would add new Properties to the vocabulary.

Only the third sort of Class offers an avenue for enriching our vocabulary.

Let’s take Class ServiceChannel as an example of how we want to proceed:

The first step is to take account of ServiceChannel’s position in Schema.org’s hierarchy of Classes. On its website, Schema.org asserts the equivalent of:

  • Thing, Intangible, hasSubclass
  • Intangible, ServiceChannel, hasSubclass

Here we note that the first assertion is already part of the vocabulary (Table 4 – Row 1); however, the second assertion is not and its addition to our Graph would enhance our vocabulary.

The second step is to take account of the Properties of Class ServiceChannel:

Properties from Class ServiceChannel
Property Range Description
availableLanguage Language A language someone may use with the item.
processingTime Duration Estimated processing time for the service using this channel.
providesService Service The service provided by this channel.
serviceLocation Place The location (e.g. civic structure, local business, etc.) where a person can go to access the service.
servicePhone ContactPoint The phone number to use to access the service.
servicePostalAddress PostalAddress The address for accessing the service by mail.
serviceSmsNumber ContactPoint The number to access the service by text message.
serviceUrl URL The website to access the service.

Table 2. Properties of Class ServiceChannel.

These eight Properties (availableLanguage, processingTime, providesService, serviceLocation, servicePhone, servicePostalAddress, serviceSmsNumber, serviceUrl) of Class ServiceChannel are new and so will be added to our vocabulary. Note that Class ServiceChannel also inherits all of the Properties of its superordinate Class Thing – but that these Properties are already included in our vocabulary and do not represent an opportunity for enhancement.

The third and final step is to take account of the Ranges of Class ServiceChannel‘s Properties – thereby adding five Classes (Language, Duration, Place, ContactPoint, and PostalAddress) to our vocabulary – (note that Class Service and Class URL are already included).

Quantitative Impact on Vocabulary

We may quantify the impact of adding any Class (ServiceChannel, Action, OrganizationAdministrativeArea, and Audience) to our vocabulary in Cycle 2 by using our vocabulary at the end Cycle 1 as a baseline:

  1. How many unique assertions of the form “Node_iNode_j, hasSubclass” are associated with the Class and how many of them are new?
  2. How many unique assertions of the form “Node_iNode_j, hasProperty” are associated with the Class and how many of them are new?
  3. How many unique assertions of the form “Node_iNode_j, hasRange” are associated with the Class and how many of them are new?
  4. How many unique Classes are referenced in #1 – #3 above and how many of them are new?
  5. How many unique Properties are referenced in #1 – #3 above are how many of them are new?

In the case of Class ServiceChannel, we observe:

  • There are two assertions of the form “Node_iNode_j, hasSubclass” – one assertion is already included in the vocabulary at the end of Cycle 1; one assertion is new and would be an enhancement to the vocabulary.
  • There are fifteen unique assertions of the form “Node_iNode_j, hasProperty” – eight unique assertions that derive from Class Thing are already included in the vocabulary; eight assertions that derive from Class ServiceChannel itself are new and would be enhancements to the vocabulary.
  • There are twenty-one unique assertions of the form “Node_iNode_j, hasRange”; thirteen unique assertions are already included in the vocabulary; eight unique assertions are new and would be enhancements to the vocabulary.
  • There are nineteen unique Classes standing in form Node_i or Node_j in assertions of the form “Node_i,Node_j, hasSubclass”, or Node_i in assertions of the form “Node_i,Node_j, hasProperty”; five of these unique Classes (Language, Duration, Place, ContactPoint, PostalAddress) are new.
  • There are twenty-four unique Properties of the form Node_j in assertions of the form “Node_i,Node_j, hasProperty” – eight of these unique Properties are new.

Note that this method of enriching our vocabulary of government service depends entirely on the structure of Schema.org – there is no model of government service that comes into the exercise.

Applying steps #1 – #5 above to the other Classes that had defined the Range of some Property in Cycle 1, we observe the following impacts of adding these Classes individually or altogether to our vocabulary:

New Assertions New Nodes
 Added Range hasSubclass hasProperty hasRange Classes Properties
ServiceChannel 1 8 8 5 8
Action 1 11 13 6 11
Organization 1 33 39 15 33
AdministrativeArea 2 15 19 11 15
Audience 1 2 2 0 2
Altogether 6 69 69 25 58

Table 3. Introduction of new components into vocabulary for GovernmentService in Cycle 2.

The Graph of our vocabulary at the end of Cycle 2 includes 25 + 58 = 83 additional Nodes and 6 + 69 + 69 = 144 additional assertions about the relations between these Nodes and/or between these Nodes and the Nodes of our vocabulary at the end of Cycle 1:

Assertions included in Cycle 1
Source Node Target Node Relation
Thing Intangible hasSubClass
Intangible Service hasSubClass
Service GovernmentService hasSubClass
Thing additionalType hasProperty
Thing alternateName hasProperty
Thing description hasProperty
Thing image hasProperty
Thing name hasProperty
Thing potentialAction hasProperty
Thing sameAs hasProperty
Thing url hasProperty
Service availableChannel hasProperty
Service produces hasProperty
Service provider hasProperty
Service serviceArea hasProperty
Service serviceAudience hasProperty
Service serviceType hasProperty
GovernmentService serviceOperator hasProperty
additionalType URL hasRange
alternateName Text hasRange
availableChannel ServiceChannel hasRange
description Text hasRange
image URL hasRange
name Text hasRange
potentialAction Action hasRange
produces Thing hasRange
provider Organization hasRange
sameAs URL hasRange
serviceArea AdministrativeArea hasRange
serviceAudience Audience hasRange
serviceOperator Organization hasRange
serviceType Text hasRange
url URL hasRange
Assertions added in Cycle 2
Thing Action hasSubClass
Thing Organization hasSubClass
Thing Place hasSubClass
Intangible Audience hasSubClass
Intangible ServiceChannel hasSubClass
Place AdministrativeArea hasSubClass
Action actionStatus hasProperty
Action agent hasProperty
Action endTime hasProperty
Action error hasProperty
Action instrument hasProperty
Action location hasProperty
Action object hasProperty
Action participant hasProperty
Action result hasProperty
Action startTime hasProperty
Action target hasProperty
Audience audienceType hasProperty
Audience geographicArea hasProperty
Organization address hasProperty
Organization aggregateRating hasProperty
Organization brand hasProperty
Organization contactPoint hasProperty
Organization department hasProperty
Organization dissolutionDate hasProperty
Organization duns hasProperty
Organization email hasProperty
Organization employee hasProperty
Organization event hasProperty
Organization faxNumber hasProperty
Organization founder hasProperty
Organization foundingDate hasProperty
Organization foundingLocation hasProperty
Organization globalLocationNumber hasProperty
Organization hasPOS hasProperty
Organization interactionCount hasProperty
Organization isicV4 hasProperty
Organization legalName hasProperty
Organization location hasProperty
Organization logo hasProperty
Organization makesOffer hasProperty
Organization member hasProperty
Organization memberOf hasProperty
Organization naics hasProperty
Organization owns hasProperty
Organization producer hasProperty
Organization review hasProperty
Organization seeks hasProperty
Organization subOrganization hasProperty
Organization taxID hasProperty
Organization telephone hasProperty
Organization vatID hasProperty
Place address hasProperty
Place aggregateRating hasProperty
Place containedIn hasProperty
Place event hasProperty
Place faxNumber hasProperty
Place geo hasProperty
Place globalLocationNumber hasProperty
Place hasMap hasProperty
Place interactionCount hasProperty
Place isicV4 hasProperty
Place logo hasProperty
Place openingHoursSpecification hasProperty
Place photo hasProperty
Place review hasProperty
Place telephone hasProperty
ServiceChannel availableLanguage hasProperty
ServiceChannel processingTime hasProperty
ServiceChannel providesService hasProperty
ServiceChannel serviceLocation hasProperty
ServiceChannel servicePhone hasProperty
ServiceChannel servicePostalAddress hasProperty
ServiceChannel serviceSmsNumber hasProperty
ServiceChannel serviceUrl hasProperty
actionStatus ActionStatusType hasRange
address PostalAddress hasRange
agent Organization hasRange
agent Person hasRange
aggregateRating AggregateRating hasRange
audienceType Text hasRange
availableLanguage Language hasRange
brand Organization hasRange
brand Brand hasRange
contactPoint ContactPoint hasRange
containedIn Place hasRange
department Organization hasRange
dissolutionDate Date hasRange
duns Text hasRange
email Text hasRange
employee Person hasRange
endTime DateTime hasRange
error Thing hasRange
event Event hasRange
faxNumber Text hasRange
founder Person hasRange
foundingDate Date hasRange
foundingLocation Place hasRange
geo GeoCoordinates hasRange
geo GeoShape hasRange
geograhicArea AdministrativeArea hasRange
globalLocationNumber Text hasRange
hasMap Map hasRange
hasMap URL hasRange
hasPOS Place hasRange
instrument Thing hasRange
interactionCount Text hasRange
isicV4 Text hasRange
legalName Text hasRange
location PostalAddress hasRange
location Place hasRange
logo URL hasRange
logo ImageObject hasRange
makesOffer Offer hasRange
member Organization hasRange
member Person hasRange
memberOf Organization hasRange
memberOf ProgramMembership hasRange
naics Text hasRange
object Thing hasRange
openingHoursSpecification OpeningHoursSpecification hasRange
owns OwnershipInfo hasRange
owns Product hasRange
participant Organization hasRange
participant Person hasRange
photo Photograph hasRange
photo ImageObject hasRange
processingTime Duration hasRange
producer Person hasRange
providesService Service hasRange
result Thing hasRange
review Review hasRange
seeks Demand hasRange
serviceLocation Place hasRange
servicePhone ContactPoint hasRange
servicePostalAddress PostalAddress hasRange
serviceSmsNumber ContactPoint hasRange
serviceUrl URL hasRange
startTime DateTime hasRange
subOrganization Organization hasRange
target EntryPoint hasRange
taxID Text hasRange
telephone Text hasRange
vatID Text hasRange

Table 4. Graph of vocabulary for describing service that is provided by a government organization (Cycle 2).

Our vocabulary for describing a service provided by a government organization now looks something like this (interactive version here):

Schema.org GovernmentService Cycle 2

Figure 5. Visualization of Graph of GovernmentService (Cycle 2), where o = Property, D = Domain, and R = Range (end of Cycle 1) and o = Property and R = Range (end of Cycle 2), terminating Property nodes with Range = Datatype.

After only two cycles through Schema.org, we see that our vocabulary of government service is already threatening to become unwieldy – the number of assertions in our Graph has increased dramatically, and many of the assertions added in Cycle 2 are less clearly relevant to describing government service. Proceeding with ingesting additional Classes and Properties into our vocabulary, using this methodology in a third, fourth, fifth Cycle of development, is an interesting exercise, but increasingly unproductive for our purposes.

Moving forward, then, we will adopt a model of service to guide our development of a vocabulary of government service using Schema.org.

Coming Up:

Part III: The Architecture of Service: the Service Organization and Service Channel

Part IV: The Service Audience and Administrative Area

Part V: The Service Action