Zaino, Jennifer – Ontology Plays a Part in United Nations Sustainable Development Goals Project – 20160303

Zaino, Jennifer – Ontology Plays a Part in United Nations Sustainable Development Goals Project – 20160303

How do you define “basic services”? What’s the difference between them and “essential services”? What is meant by terms like “natural capital”, “raw material” or “essential medicines”? How do these all fit into an ontology?

The truth is that there often aren’t universally accepted or precise definitions for terms like these – or even more simple ones, like “forest” – as they relate to their use in the United Nations Environment Program’s (UNEP) Sustainable Development Goals Project. The Sustainable Development Goals (SDG) – successors to the UN’s Millennial Development Goals, which expired last year – are a set of 17 goals and 169 targets to be achieved by 2030 to promote human prosperity worldwide while protecting the environment and addressing climate change.

For example, within the goal of ending poverty in all its forms everywhere, targets include reducing at least by half the proportion of men, women, and children who live in poverty in all its dimensions (according to national definitions); to implement nationally appropriate social protection systems and measures for all; and, to reduce poor people’s exposure and vulnerability to climate-related extreme events and other economic, social, and environmental shocks and disasters. Each goal’s targets will have one or more indicators, which are linked to specific data points that UN statisticians and the general public can monitor to assess progress on that issue.

For the project to come together in a way that ensures data quality and transparency and sets the stage to enable more accurate analysis and measurement of progress, the Sustainable Development Goals Interface Ontology (SDGIO) is being developed to represent the various facets of the SDGs.

An ontology is a structured set of terms and logical relations that represents not only the data, but what the data is about, says Mark Jensen, who is working on the UNEP ontology effort as a consultant. Jensen is pursuing his Ph.D. in the Department of Biomedical Informatics in the Jacobs School of Medicine and Biomedical Sciences at the University at Buffalo.

“An important distinction that well-made ontologies maintain is one between the information stored in databases and the entities out in the world that are described, measured or designated by that information,” he says.

The SDGIO project employs an approach in creating ontologies based in ontological realism, developed in large part by Barry Smith. Smith, who brought the UN effort to Jensen’s attention, is SUNY Distinguished Professor in the Department of Philosophy and Director of the National Center for Ontological Research at the university.

One use of ontologies in the UN project is to make it possible to intelligently tag incoming data to ensure that users are able to discover and better understand the information they are seeking, even when target and indicator data points intersect across domains and when there are inconsistencies in how member states define data points like “basic services” or “safe access” or, yes, even “forest.” For example, some definitions of “forest” will include palm tree plantations, while others do not, which can potentially impact data that relates to forest acreage, and subsequently, any analysis that occurs when data is aggregated across countries and regions with varying conceptions of what qualifies as a forest.

“As ontologists, we create semantic models that represent knowledge in particular domains of inquiry,” says Jensen. A UNEP ontology will provide a model to represent knowledge that’s relevant to the SDGs with more precision and better consistency, and that will provide a better way of integrating information used in monitoring the status of how various targets and goals are being addressed around the world, he explains.

Steps to the Ontology

Jensen is working closely on the SDGIO project with Pier Luigi Buttigieg, a post-doctoral researcher at the Alfred Wegener Institute for Polar and Marine Research. The lead of the Environment Ontology project (ENVO), Buttigieg was invited to participate in an UNEP-led meeting on integrated measures for global monitoring of the SDG process in 2014, Jensen relates. The value of the ontology in promoting integration and interoperability was recognized at that time by UNEP Chief Scientist Jacqueline McGlade – who is directing the SDG project with Ludgarde Coppens, UNEP head of the SDG Information and Knowledge Management Unit – and other representatives. This, Jensen says, resulted in the formation of a team of ontologists to create the SDGIO. “Pier continues to play a leading role in SDGIO’s evolution and is enhancing ENVO to help meet its aims,” says Jensen.

The aim of creating a better, more uniform approach to representing the data doesn’t mean changing the way member states conceptualize their own understandings of certain terms. But it does mean creating a way to represent the diversity of definitions and make that diversity of usage more transparent to people looking for data that is relevant to indicators. In addition to that, there needs to be a way to show how disparate data is linked together through a variety of common themes that cuts across multiple goals and targets.

An ontology enters the picture because of the advantages it affords of being a precise way to go about defining terms In hierarchical fashion and establishing relationships and formalized links between the lower-level terms in that hierarchy, he says. A top-level general definition for the term “forest,” then, can encapsulate all its different conceptualizations, with the variations between definitions represented as different lower-tier species or versions of what qualifies as a forest. There’s a great deal of unpacking of the semantics, or meaning, behind each indicator that’s required to facilitate the consistency users need to measure progress toward targets by making clear the links between various data and indicators, too. For instance, an indicator that is about the proportion of a population living in households with access to basic services has to account for all kinds of data that could relate to it, including what qualifies as a household and how that differentiates from living in a slum or informal settlement.

Jensen says the team will be finalizing the first phase of the ontology this spring, which will be implemented on the portal UNEPLive:

“An important aspect of the workflow is to elicit the feedback of relevant domain experts to guide their efforts in refining the semantics to better reflect the various domains surrounding the SDGs, such as legal entities, social policies, economic systems, equity and human rights, ecosystems and biodiversity, infrastructure, public health and education,” Jensen says.

This first phase includes the discovery and creation of all the needed terms and definitions and their formal implementation in OWL as an ontology. The team will reuse existing efforts by other groups developing ontologies, including those developed by ENVO (for the environment), CHEBI (for chemicals), OBI (for biomedical investigation), and PCO (for population and communities), and the complete semantics will grow over time as new ontologies are formed to address many of the domains that work on SDGIO has revealed a need for. For example, no ontology yet exists for human rights or financial measures, Jensen explains:

“SDGIO is truly an ‘interface.’ Not only is there a need to interface the data with the goals, targets and indicators, but also to interface the growing community of domain-specific ontologies that are and will be relevant to the SDGs.”

UN statisticians will tag the data using a few terms from the ontology (in addition to metadata such as provenance, geographic location, and so on). The ontology’s value for helping to enhance the discoverability of data should become clear in a few months as users go into the portal and type something like “access to basic services” or simply “basic services.” “We want to provide the ability for them to find data related to basic services in all contexts, not just for one particular indicator,” Jensen says.

Alternately, users might go in looking for data related to “essential services” but be served up data tagged as “basic services” because the two categories overlap very closely and often the distinction is hard to maintain. “We make the links between these terms and formalize that in the ontology so that if you search for one you can also find information tagged with the other,” he says. Researchers can drill down to determine whether information aligned with the other data tag fits their assessment requirements and use it or not, as they see fit.

Users also will be able to leverage the ontology for visualizing terms and the relationships between them. Along with those definitions they’ll find editor notes and comments about variations in usage. Says Jensen, “Hopefully they’ll utilize not just the discovery/search feature the ontology facilitates but also pay attention to the mapping and semantics it affords and the extra annotations we can add.”

Establishing and Specifying the REA model as a Domain Ontology for Business

Original specification of the REA Ontology – McCarthy, Geerts et al at University of Michigan

Transitional efforts to formalize REA Ontology using UML Diagrams – Poels, Paemeleire, Gailly et al at Ghent University

Formalization of the REA Enterprise Ontology using OWL and the UML Profile of OWL – Poels, Gailly et al at Ghent University

Background

The REA Ontology is an “event ontology” (Allen, GN and ST March, 2006) that focuses on events occurring within the realm of a company, their participating agents, affected resources, and regulating policies. REA can be used as a reference for modeling a single business cycle (e.g. sales-collection) or a chain of business cycles, connected through resource flows. Applications supported by REA-driven modeling include the design of accounting and operations management systems, auditing and internal control, and conceptual data modeling. REA has been used in a number of international standardization efforts for e-collaboration systems. For instance, REA was the basis for the business process ontology in the UMM business process and information model construction methodology, the ECIMF system interoperability enabling methodology, and the Open-EDI business transaction ontology which is part of the ISO/IEC 15944-4 standard. REA has further been proposed as a theoretical basis for the reference models that underlie ERP systems.

The Project

Frederik Gailly and Geert Poels (Ghent University) set out with two goals:

  1. To establish the REA ontology as a domain ontology – specifically a domain ontology for business, using a semiotic framework (Stamper et al, 2000; Burton-Jones et al , 2005). Within this framework, the authors sought assistance with their evaluation of the ontology’s syntactic quality specifically from Welty et al (1999) and Lassila and McGuiness (2001), and with their evaluation of the ontology’s social quality from Guarino (1998) and Uschold and Jasper (1999).
  2. To enhance the specification of the REA ontology using both a formal language representation (the Web Ontology Language or OWL) and a graphical representation (the Unified Modeling Language or UML Profile for OWL) .

We will leave it largely up to the readers to familiarize themselves with the details of how the authors achieved their goal of establishing the REA ontology as a domain ontology for business. We simply present the semiotic framework (Burton-Jones et al , 2005) in Table 1 and highlight the authors’ evaluation of the REA ontology against this framework in Table 2. Finally, we note that the authors define business as “the activity of providing goods and services involving financial, commercial and industrial aspects”.

Metric Attribute Description
Syntactic quality Lawfulness Correctness of syntax
Richness Breadth of syntax used
Semantic quality Interpretability Meaningfulness of terms
Consistency Consistency of meaning of terms
Clarity Average number of word senses
Pragmatic quality Comprehensiveness Number of classes and properties
Accuracy Accuracy of information
Relevance Relevance of information for a task
Social quality Authority Extent to which other ontologies rely on it
History Number of times ontology has been used

Table 1. Metrics  for evaluating ontologies (Burton-Jones, A et al, 2005)

Metric Attribute REA evaluation
Syntactic quality Lawfulness
  • The REA ontology has a semantically rich internal structure (say) that is not limited to the IS-A relations as found in a typical thesaurus, and that defines axioms that allow for semantic reasoning.
  • However, many details of the REA ontology internal structure and underlying logic are not explicitly specified (e.g., disjointness of concepts).
Richness
Semantic quality Interpretability
  • The authors don’t evaluate the semantic quality of the REA ontology because of their focus on the applicability of the ontology.
Consistency
Clarity
Pragmatic and
Social quality
Comprehensiveness
  • Both the pragmatic and social qualities of the REA ontology are evaluated largely in terms of the ontology’s applications and the extent to which the ontology is useful for users and their agents, irrespective of syntax and semantics.
  • The REA ontology supports a wide range of applications and users:
    • education in accounting and business
    • model-driven systems and software design
    • supply chain and e-collaboration
    • knowledge representation and retrieval
Accuracy
Relevance
Social quality Authority
History

Table 2. Evaluation of the REA ontology.

The authors’ evaluation of the syntactic quality of the REA ontology as a domain ontology for business highlighted the following deficiencies:

  • the REA ontology was a somewhat incoherent mix of textual and graphical elements that spoke to its relative immaturity
  • while some researchers (Bialecki 2001; Chou 2006; Geerts 2004) had taken steps to represent the REA ontology in a machine-readable format, none of these formalizations was widely known or generally accepted
  • like Geerts and McCarthy (1999), the authors recognized the importance of better specifying the REA ontology

Again, we will leave it largely up to the readers to familiar themselves with the details of how the authors enhance the specification of the REA ontology. The main principles of their approach included:

  • the authors apply formal procedures – the METHONTOLOGY framework (Fernandez-Lopez et al. 1997; G6mez-Perez and Rojas 1999) and the Operational Data Model (OMG, 2006) – to re-engineer the existing REA ontology
  • Three main activities are identified in this re-engineering process (Figures 2 and 3):
    • reverse engineering – the conceptualization of the REA ontology is recovered from whatever representation formats are available (e.g. text, tables, modeling diagrams)
    • re-structuring – the recovered conceptualization of the REA ontology is re-designed and expressed in a graphical representation with well-defined syntax and semantics (like the UML Profile for OWL) 1
    • forward engineering – the re-designed conceptualization is transformed into a re-engineered, formal language representation (like OWL)

 

A Business Domain Ontology Re-engineering Methodology - Process, Activities and Artifacts

Figure 2. A Business Domain Ontology Re-engineering Methodology – Process, Activities and Artifacts.

 

REA Ontology Transformation and Tools

Figure 3. The recovery, re-design, and formalization of the REA domain ontology for business.

With this overview of the methodology used by Geerts, Laurier and Poels to re-engineer the REA ontology in 2007 – 2008, we can turn to the resulting graphical representation (UML Profile of OWL) and formal language representation (OWL) of the REA domain ontology for business.

Next: Graphical representation of the REA domain ontology for business (UML Profile for OWL)

 

 

 

  1. Using UML in the re-design of the REA ontology capitalizes on the familiarity of many end-users  in the business domain with this technology.

ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Introduction – 20071101

ISO/IEC 15944 consists of the following parts under the general title “Information technology – Business Operational View”:

  • Part 1: Operational aspects of Open-edi for implementation
  • Part 2: Registration of scenarios and their components as business objects
  • Part 4: Business transaction scenarios — Accounting and economic ontology
  • Part 5: Identification and referencing of requirements of jurisdictional domains as sources of external constraints
  • Part 6: Technical introduction to e-Business modelling [Technical Report]
  • Part 7: eBusiness vocabulary
  • Part 8: Identification of privacy requirements as external constraints on business transactions
  • Part 9: Business transaction traceability framework for commitment exchange
  • Part 10: IT-enabled coded domains as semantic components in business transactions
  • Part 11: Descriptive techniques for foundational modelling in Open-edi
  • Part 20: Linking business operational view to functional service view

Introduction

Purpose and overview

This work is motivated with important ideas from the ISO Open-edi specifications as represented in ISO/IEC 15944-1. In ISO/IEC 15944-1 and in some of its earlier foundational expositions, such as ISO/IEC 14662, there were important concepts defined and interrelated such as business transaction, fundamental activities of a business transaction, commitment, Person, role, scenario, and others. A need for relating all of these concepts in a formal framework for the Open-edi work is apparent.

This is a question of ontology: a formal specification of the concepts that exist in some domain of interest and the relationships that hold them. In this case, the domains of interest are those that encompass Open-edi activities, that is, law, economics, and accounting in an extended sense, not the internal accounting of one particular firm, but the accountabilities of each of the participants in a market-based business transaction.

Ontologies are generally classified as either upper-level ontologies, dealing with generalized phenomena like time, space, and causality, or domain ontologies, dealing with phenomena in a specific field like military operations, manufacturing, medical practice, or business. The economic and accounting ontology being used in electronic business eXtended Markup Language (ebXML), in the UN/CEFACT modelling methodology, and E-Commerce Integration Meta-Framework (ECIMF) work is entitled the Resource-Event-Agent (REA) ontology 1. REA is used here as an ontological framework for specifying the concepts and relationships involved in business transactions and scenarios in the Open-edi sense of those terms. The resulting framework is titled the Open-edi business transaction ontology (OeBTO).

The REA ontology is actually an elementary set of concepts derived from basic definitions in accounting and economics. These concepts are illustrated most simply with a UML class diagram. See Figure 1, which illustrates the simple Resource-Event-Agent structure that gives REA its name. A business transaction or exchange has two REA constellations joined together, noting that the two parties to a simple market transfer expect to receive something of value in return when they trade. For example, a seller, who delivers a product to a buyer, expects a requiting cash payment in return.

Basic economic primitives of the Open-edi ontology

Figure 1 Basic economic primitives of the Open-edi ontology.

There are some specific points of synergy between the REA ontology and the ISO Open-edi specifications as represented in ISO/IEC 15944-1.

ISO/IEC 15944-1, 3.9 defines commitment as “the making or accepting of a right, obligation, liability, or responsibility by a Person…”. Commitment is a central concept in REA. Commitments are promises to execute future economic events, for example, to fulfill an order by executing a delivery event.

ISO/IEC 15944-1, 6.1.3, Rule 1 states: “Business transactions require both information exchange and commitment exchange.” REA firmly agrees with and helps give definition to this assertion. Reciprocal commitments are exchanged in REA via economic contracts that govern exchanges, while information exchange is tracked via business events that govern the state transitions of business transaction entities that represent various economic phenomena.

ISO/IEC 15944-1, 6.3.1, Rule 39 states: “Conceptually a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization, and post-actualization.” For REA, actualization is the execution of economic events that fulfill commitments. Planning and identification involve business partners with types of economic resources, events, and persons, while negotiation is finalized by an economic contract which is a bundle of commitments. The UN/CEFACT Business Process Group has also defined negotiation protocols that assist in forming commitments. The Open-edi set of activities and the REA economic concepts will help each other tie together all the activities into a cohesive business transaction, and then unite that transaction definition with its related information models.

Finally, with regard to the preliminary agreement between Open-edi and REA, the two major sets of ideas that characterize the Open-edi work, the specification of business transactions and the configuration of scenarios, correspond well at the aggregate level to what the REA ontology calls the accountability infrastructure and the policy infrastructure. A business transaction specifies, in a descriptive sense, actual business events of what has occurred or has been committed to. Conversely, a scenario is more prescriptive: it configures what could be or should be. The realm of both descriptions and prescriptions is important both to Open-edi and REA, and they can work well in developing standards for each.

Definition of Open-edi Business Transaction Ontology (OeBTO)

According to the most widely accepted definition from Tom Gruber, an ontology is a formal, explicit specification of a shared conceptualization. The individual components of this meaning are each worth examining.

  • formal = machine-readable
  • explicit specification = concepts, properties, relations, constraints, and axioms are explicitly defined
  • of a shared = consensus knowledge
  • conceptualization = abstract model of some phenomenon in the real world

At present, the REA model is certainly an explicit specification of a shared conceptualization of economic phenomena in the accounting community.

A formal, machine-readable specification is not proposed in this part of ISO/IEC 15944; however, such extensions may follow in other standards work.

This part of ISO/IEC 15944 focuses on integrating the Gruber definition of ontology with a REAbased approach. It does so from an accounting and economic ontology perspective within an Openedi Reference Model context. This is achieved through the introduction of the concept (or construct) of “Open-edi Business Transaction Ontology (OeBTO)”, which is defined as follows:

formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among those concepts.

Use of the “independent” and “trading partner” perspective in the Open-edi ontology work

In normal business use, the naming perspective for the ontological primitives would be that of the entrepreneur or of one of the two trading partners engaged in collaborative commerce. The other trading partner would ordinarily have a mirror-image view. Thus, a sale, a cash receipt, or a resource inflow for a particular entrepreneur would become a purchase, a cash disbursement, or a resource outflow for a corresponding trading partner. From this perspective, business events and their accompanying economic phenomena would be modeled twice, once in the database of each trading partner. However, for Open-edi purposes, or for that matter for any other independent modeling of business collaborations like the Business Requirement View BRV level of the UN/CEFACT modeling methodology, this redundancy is not acceptable because it allows the states of the two representations to become inconsistent. This difference in naming perspective is explained below and illustrated in Figure 2.

Different views of business collaboration

Figure 2. Different views of business collaboration.

Figure 2 illustrates three independent value chains for three different enterprises. Each company has a connected network of business processes that takes its initial input of resources (called factor inputs for their production functions) and transforms them via cumulative flows of goods, services, rights, and/or cash into an output for that firm’s downstream customers. For Open-edi collaboration modeling, these internal processes are not relevant until a resource flow crosses enterprise boundaries, as is illustrated for Enterprise #2 which accepts materials from Enterprise #1 and which delivers materials to Enterprise #3 (most probably in both cases for cash payments in return). The two dotted lines with double-headed arrows show these inter-enterprise events.

The independent or collaboration perspective of resource flows is anchored on the view of the eye outside of Enterprise #2. This view sees both exchanges as conceptually similar with flows of materials being requited by flows of funds. Such a perspective is quite different from that of the eye inside of Enterprise #2, which sees the flow between Enterprise #1 and Enterprise #2 as a “purchase” and the flow between Enterprise #2 and Enterprise #3 as a “sale”. Note that an eye inside of Enterprise #1 (not shown on diagram) would have modeled the “purchase” of Enterprise #2 as a “sale” of Enterprise #1, hence the redundancy and the inevitable inconsistency.

Business process modeling can take either of the perspectives shown by the eyes of Figure 2, but the independent perspective is clearly the choice for Open-edi. This leads to the concept of a business collaboration that is illustrated in Figure 3. Most generally, there is a value exchange between two Persons, with one assuming the role of a “buyer” (has money, desires goods, services, and/or rights) and the other assuming the role of a “seller” (has goods, services, and/or rights, desires money). It is also possible to anchor the independent view on time, with one event being the initiating flow and the requiting event being the responding flow. For internal database purposes of corporate accountability, “trading partner perspective” terms are directly derivable from “independent perspective” terms.

Concept of a business collaboration

Figure 3. Concept of a business collaboration.

The “Open-edi Business Transaction Ontology” (OeBTO)

“Definition of Open-edi Business Transaction Ontology (OeBTO)” and “Use of ‘independent’ and ‘trading partner’ perspective in the Open-edi ontology work” have suggested:

  • that the components of the REA domain ontology model are sufficiently well-defined, stable, and well-known that they can clearly serve as the basis for an ontological specification of the concepts involved in collaborative exchanges between trading partners, and
  • that the components of that model must be viewed from the outside perspective of a modeler viewing the economic phenomena independently.

Because the primitive economic terms are being adopted here for use with the operational aspects of Open-edi from ISO/IEC 15944-1, the ontology to be defined will be termed the “Open-edi Business Transaction Ontology” (OeBTO). Its definition is

formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among these concepts

From the definitional foundations of both ISO/IEC 15944-1 and the REA model, it follows that the OeBTO will follow these five principles:

  • as a business transaction ontology, a distinguishing characteristic of OeBTO is that in addition to information exchange, it incorporates commitment exchange among autonomous Persons
  • an OeBTO requires the use of clear and pre-defined rules, principles, and guidelines (see ISO/IEC 15944-1, 5.1)
  • an OeBTO is neutral in terms of technology, representation, and application
  • the scope of an OeBTO covers all areas of business transactions (public/private, industry sectors, international, regional, etc.)
  • the semantics of the concepts represented in an OeBTO are explicitly specified and constrained.

Organization and description of Part 4 of  ISO/IEC 15944

Clause 1 and Clause 2 provide scope and normative references for OeBTO. The basic OeBTO definitions are first enumerated in Clause 3, while Clause 4 provides a table of symbols and abbreviations. Clause 5 provides the declarative substance for this part of ISO/IEC 15944, which is a set of UML class diagrams and conceptual explanations that circumscribe the Open-edi Business Transaction Ontology. Clause 6 explains the mechanics of a business transaction state machine, which is the procedural component of an OeBTO, while Clause 7 explains the (internal) constraint component of OeBTO, which is its repository for business rules.

At the end of this part of ISO/IEC 15944 are some helpful Annexes that provide elaboration on the points raised in the main body. Normative Annex A is a consolidated list of all the terms and definitions used in this part of ISO/IEC 15944 in both ISO English and ISO French. The other normative annex is Annex C, which is common to ISO/IEC 15944-2, ISO/IEC 15944-4, ISO/IEC 15944-5, and ISO/IEC 15944-8. Annex B is informative text providing more detailed background information on the REA Model. This part of ISO/IEC 15944 concludes with a bibliography.

Appendix B – REA Ontology

Note: The text of this annex has been adopted from the UN?/CEFACT Simple Guide to the UMM, 2003.

Introduction

Ontology, according to the most generally accepted e-commerce definition of that word, is a “specification of a conceptualization”. The REA (Resource-Event-Agent) ontology is a specification of the declarative semantics involved in a business process. The theory behind REA came initially from the field of accounting where REA was first introduced, but its components clearly have microeconomic origins with specific ties in many instances to the use of economic definitions in the practice of building enterprise-wide information systems. In UN/CEFACT work, all of the REA ontology definitions are applied to the collaborative space between enterprises where market exchanges occur in closely synchronized fashion among two or more trading partners.

In its most simple form without a high degree of precision, REA can be portrayed as a UML class diagram with associations and generalizations relating the object classes. The intent of this annex is to display REA simply and to explain its basic rationale. To do so, the annex will use a set of three figures (Figures B.1, B.2 and B.3), plus two summary figures. The most advanced of the UML diagrams (Figure B.3) is a good overall guide to the BRV semantics, given both here and in the Unified Modeling Methodology (UMM) of UN/CEFACT.

B.2 The Basic REA Ontology

The Basic REA model was first published in the July 1982 issue of The Accounting Review, the most prominent, most reliable, and most tightly controlled outlet for theoretical-based accounting work in the world. Its basic premises have withstood all theoretical challenges in the 20 years since, and its components are used extensively in a variety of educational, practical, and theoretical contexts. The REA model work was given the first (and thus far only) Seminal Contribution to the Accounting Information Systems Literature Award in 1996 by the American Accounting Association (AAA), and in 2003, its use as a model for teaching enterprise information systems was awarded the Innovation in Accounting Education Award, also from the AAA. There are a number of textbooks in worldwide use that feature REA as a pattern-oriented teaching framework.

Figure B.1 illustrates the basic class structure of REA ontology. The left-to-right configuration of economic Resources, economic Events, and economic Agents (renamed in UMM as “Partner”) in a typical business collaboration pattern is the source of the model’s REA name.

A successful business collaboration involves first and foremost two types of Economic Events, each of which details the Economic Resources involved in an exchange between two Trading Partners. For example, a Supplier (Trading Partner) transfers ownership of an Automobile (Economic Resource) to a Customer (Trading Partner) in return for which (duality association) the Customer will provide Money (Economic Resource) to the Supplier. There are two mirror-image instantiations of the object pattern shown in Figure B.1 where one transfer represents the legal or economic consideration given for the other.

Basic REA ontology

Figure B.1. Basic REA ontology.

The declarative semantics shown here are central to all trading relationships. Economic Resources are objects that have value and are under the control of one of the two collaborative agents. Trading partners always expect requited transfers of resources when they engage in commerce. Hence, Figure B.1 is a pattern for all economic exchanges.

B.3 Adding Commitments to the Basic Exchange Ontology

In electronic commerce, the actual trading phase of an exchange is accommodated well by the object structure shown above in Figure B.1. However, trading partners in long-term relationships need more trusted and predictable structures where both parties contract for their exchange behavior in advance. The REA ontology accommodates this expansion with the addition of the classes shown as Economic Commitments, Economic Contract, and Agreement in Figure B.2.

REA ontology with Commitments

Figure B.2. REA ontology with Commitments.

A Commitment is a promise by a Trading Partner to initiate an Economic Event in the future. Performing the Economic Events fulfills that Commitment. Commitments should always be reciprocated by the other Trading Partner who commits to initiate another type of Economic Event in return. An Economic Contract is a bundle of reciprocating commitments between Trading Partners who bind themselves to one or more economic exchanges in the future. A Contract is a subtype of the more general object class called Agreement, and Agreements can regulate other Agreements.

In the case of the automobile-for-money exchanges discussed in the prior section, Commitments would involve the Customer agreeing to accept delivery of an Automobile on a certain date in return for which he or she would be contractually obligated to making a series of Cash payments to the Supplier for that purchase.

In the bottom part of Figure B.2, two additional objects of the REA ontology are illustrated: Claims and Locations.

  • Materialization of Claims is sometimes needed when Trading Partners insist on documentation of partially completed exchanges (for example, when a Customer takes possession of an Automobile before paying for it in full). If needed, Claims can be instantiated by documents like invoices or by accounting artifacts like accounts-receivable. Their inclusion here is more a matter of business custom than ontological completeness.
  • A Location is another object that is sometimes needed to fill out the specification for a full economic transfer. Locations simply identify the place where Economic Events take place.

The economic and ontological foundations of commitments are explained more completely by Geerts and McCarthy.

Adding Types to the Basic REA Exchange Ontology

The object pattern portrayed in Figure B.2 above is primarily descriptive in the sense that it illustrates what actually occurred in an economic exchange or what has been committed to. In the UMM, these descriptive components have been augmented by prescriptive components that allow the specification of control policies or collaboration patterns. These prescriptive components are enabled by the inclusion of type images of the basic descriptive objects. The class diagram of Figure B.3 shows these additions.

The addition of Types to Figure B.3 proceeds in two stages:

  • The three base descriptive classes – Economic Resource, Economic Event, and Partner (Economic Agent) – have classes added for their types. These new classes are connected to the descriptive objects by typifies associations. An example of a Resource Type could be different models of automobiles. An example of Economic Event Type could be the classes of retail transaction and wholesale transactions, each with different pricing structures. An example of Partner Type could be different classes of employees, each type with separate training requirements. Additionally, the class Location is also typified. An example of Location Type might be different types of loading docks with different sizes and stress capability levels.
  • The full design of the Economic Commitment would necessitate associations between the commitment and each of the new type-level objects. These are illustrated in the figure with specifies associations.

REA Ontology with Types

Figure B.3. REA Ontology with Types.

In addition to these two groups of additions, there are other REA associations in the UMM that are not illustrated here in an effort to minimize diagram complexity. These include:

  • Contract – responsible – Partner
  • Economic Commitment – destination – Location
  • Partner – participates – Agreement
  • Partner – participates – Economic Commitment
  • Economic Commitment – reserves – Economic Resource

And finally with regard to Figure B.3, the partial integration of the elements of the REA ontology with the components of the UMM business collaboration framework is illustrated by showing the class for Business Collaboration (with dotted lines) and some of its associations with REA classes (also illustrated with dotted lines). Outside of its use with the UMM and the attendant specifications, the REA ontology has a three-level architecture that is explained by Geerts and McCarthy. In the UMM, this three-level architecture is effected by the integration of REA components within the business collaboration framework and by the connection of the Business Requirements View (BRV) to the Business Domain View (BDV) above it and the Business Transactions View (BTV) below it.

The Suitability of the REA Ontology within the Open-edi Model

The REA ontology is well known and well used throughout the field of accounting and to a lesser extent throughout the field of enterprise computing in general. It is the best example of a business domain ontology in existence today, and its measures well against the most commonly cited “ontology quality” criteria as proposed by Gomez-Perez. Her functional criteria and the REA explanation of their applicability are portrayed in Figure B.4. REA and Open-edi also fit very well together, as do REA and the Business Requirements View of the UN/CEFACT meta-model. Figure B.5 illustrates how these three systems correspond to each other on some very important points of emphasis. Continuing harmonization work with both the business process group and the core components group of UN/CEFACT is emphasizing these principles of commonality.

Functional Criteria REA Explanation
Does it express the consensus knowledge of a community of people? The original paper and all extensions since have been published in high quality refereed journals (The Accounting Review, IEEE Intelligent Systems, etc.) where its components are open to constant review and criticism. In 1996, the original paper was given the first Seminal Contribution to the Accounting Information Systems Literature Award by the American Accounting Association.  The Work was most recently awarded the 2003 Innovations in Accounting Education Award by the AAA.
Do people use it as a reference of precisely defined terms? The three leading textbooks on accounting systems analysis and design all use REA extensively to define system primitives and to explain modeling of accounting phenomena.
Is the language used expressive enough for people to say what they want to say? The REA primitives may be used to model any of the economic dealings of an enterprise.  The actual chain of entrepreneurial logic might itself be hard to explicate in a minority of cases (why for instance do firms support public charities or why is training important for employees?), but once those links are made at some level of granularity, REA primitives are able to document them.
Is it stable? The original paper was published in the top accounting journal in the world (The Accounting Review) in 1982.  No substantive criticisms of its features have been published in the intervening 20 years.
Can it be used to solve a variety of different sorts of problems or as a starting point to construct multiple sorts of applications? REA can be used to model and design the accounting components of software systems.  It has also been used to model external business processes or business collaborations for ebXML and TMWG of UN/CEFACT.  It has also been used to model inter-firm phenomena such as supply chains and to analyze the efficacy of a variety of enterprise software systems. Moreover, this documentation can be expressed at multiple levels of granularity, ranging from high level value chains and supply chains all the way down to the level of workflow tasks   The original model covered both inter- and intraenterprise transactions, but its use can be specialized for either case.

Figure B.4. Ontology criteria and the REA Ontology.

Overall Concept ISO Open-edi REA Ontology UN/CEFACT
Emphasis on “economic value” as foundation for business process and business collaboration definitions A business transaction pertains to the exchange of something of value Involves requited economic events wherein one economic resource –which is something of value under the control of an enterprise – is exchanged for another economic resource A business collaboration is an activity where one thing of measurable value is created, either as a service performed or as a product created
Designated “actors” or agents who participate in the economic activities within or between business enterprises Person is a legal or human entity having the ability to make commitments and to fulfill resulting obligations, and to be held accountable for those obligations Economic Agents include persons and agencies who participate in the economic events of the enterprise Partner is an actor in a business collaboration
The ability to make and impart information about “commitments” as a critical component of e-commerce A key property of a business transaction is that it involves commitment exchange among persons A commitment is an agreement to execute an economic event in a well-defined future that will result in either an increase of resources or a decrease of resources A commitment is an obligation to perform an economic event (that is, transfer ownership of a specified quantity of a specified resource type) at some future point in time
Preestablished patterns for different classes of e-commerce collaboration An Open-edi Scenario is a formal specification of a class of business transactions having the same business goal A scenario is a configuration of event types, resource types, commitment types, and agent types aggregated together Declarative Collaboration Patterns are being developed based on the BRV components of the UMM metamodel

Figure B.5. Correspondence of ISO, REA, and UN/CEFACT.

Next: ISO/IEC 15944-4 – Terms and definitions – 20071101

  1. Elements of the REA ontology as they are used in other standards work are explained in Annex B

ISO/IEC 15944-4 – Terms and definitions – 20071101

Scope

This part of ISO/IEC 15944 provides a set of UML class diagrams and conceptual explanations that circumscribe the Open-edi Business Transaction Ontology. It explains the mechanics of a business transaction state machine — the procedural component of an OeBTO — and the (internal) constraint component of OeBTO — its repository for business rules.

This part of ISO/IEC 15944 addresses collaborations among independent trading partners as defined in ISO/IEC 15944-1. This part of ISO/IEC 15944 applies to both binary collaborations (buyer and seller) and mediated collaborations (buyer, seller, third-party). The ontological features described herein propose standards only for the BOV — that is, the business aspects of business transactions as they are defined in ISO/IEC 15944-1.

Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the editiNoon cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 15944-1:2002, Information technology — Business agreement semantic descriptive techniques — Part 1: Operational aspects of Open-edi for implementation

ISO/IEC 15944-5:2006, Information technology — Business Operational View — Part 5: Identification and referencing of requirements of jurisdictional domains as sources of external constraints

Terms and definitions

agent

Person acting for another Person in a clearly specified capacity in the context of a business transaction

NOTE: Excluded here are agents as “automatons” (or robots, bobots, etc.). In ISO/IEC 14662, “automatons” are recognized and provided for but as part of the Functional Services View (FSV) where they are defined as an “Information Processing Domain (IPD)”.

[ISO/IEC 15944-1:2002 (3.1)]

attribute

characteristic of an object or entity

[ISO/IEC 11179-3:2003 (3.1.3)]

bilateral transaction

subtype of a business transaction where the Persons include only the buyer and the seller, or alternatively other Persons acting as agents for the buyer and/or seller

business

series of processes, each having a clearly understood purpose, involving more than one Person, realized through the exchange of recorded information and directed towards some mutually agreed upon goal, extending over a period of time

NOTE          Adapted from ISO/IEC 14662:2004 (3.1.2).

business event

occurrence in time that partners to a business transaction wish to monitor or control

NOTE 1: Business events are the workflow tasks that business partners need to accomplish to complete a business transaction among themselves. As business events occur, they cause a business transaction to move through its various phases of planning, identification, negotiation, actualization and post-actualization.

NOTE 2: Occurrences in time can either be internal as mutually agreed to among the parties to a business transaction; and/or, reference some common publicly available and recognized date/time referencing schema (e.g. one based on using ISO 8601 and/or ISO 19135).

business location geographic site where an economic event is deemed to occur with its attendant transfer of an economic resource from one Person to another

Business Operational View – BOV

perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among Persons, which are needed for the description of a business transaction [ISO/IEC 14662:2004 (3.1.3)

business transaction predefined set of activities and/or processes of Persons which is initiated by a Person to accomplish an explicitly shared business goal and terminated upon recognition of one of the agreed conclusions by all the involved Persons although some of the recognition may be implicit

NOTE: Adapted from ISO/IEC 14662:2004 (3.1.4).

business transaction entity

computable representation of any real-world entity that participates, occurs or is materialized during a business transaction

business transaction entity type

abstract specification of a business transaction entity, detailing its recommended characteristics, its recommended methods and its recommended life-cycle states

NOTE: A business transaction entity type will usually specify the types of business events that cause a business transaction entity of this type to proceed through its different states as the business transaction itself progresses through its phases of planning, identification, negotiation, actualization and post-actualization.

buyer

Person who aims to get possession of a good, service and/or right through providing an acceptable equivalent value, usually in money, to the Person providing such a good, service and/or right [ISO/IEC 15944-1:2002 (3.8)]

collaboration space

business activity space where an economic exchange of valued resources is viewed independently and not from the perspective of any business partner

NOTE: In collaboration space, an individual partner’s view of economic phenomena is de-emphasized. Thus, the use of common business and accounting terms like purchase, sale, cash receipt, cash disbursement, raw materials and finished goods is not allowed because they view resource flows from a participant’s perspective.

commitment

making or accepting of a right, obligation, liability or responsibility by a Person that is capable of enforcement in the jurisdiction in which the commitment is made

[ISO/IEC 15944-1:2002 (3.9)]

constraint

rule, explicitly stated, that prescribes, limits, governs or specifies any aspect of a business transaction

NOTE 1: Constraints are specified as rules forming part of components of Open-edi scenarios, i.e. as scenario attributes, roles and/or information bundles.

NOTE 2: For constraints to be registered for implementation in Open-edi, they must have unique and unambiguous identifiers.

NOTE 3: A constraint may be agreed to among parties (condition of contract) and is therefore considered an “internal constraint”. Or a constraint may be imposed on parties (e.g. laws, regulations, etc.) and is therefore considered an “external constraint”.

[ISO/IEC 15944-1:2002 (3.11)]

custody

association between a Person and an economic resource where the Person has physical control only over the resource or controls access

NOTE: Having custody of a good, service and/or right does not imply and is differentiated from having economic control of the same (e.g. a Person may have economic control of a good even though it is not under its custody).

data

business transaction〉 representations of recorded information that are being prepared or have been prepared in a form suitable for use in a computer system

[ISO/IEC 15944-1:2002 (3.14)]

defined market model

trade model where the buyer and seller accept the entry terms of a specified market in advance and where that market has an accepted and recognized source for business rules and conventions

NOTE: In a defined market, the phases of a business transaction — planning, identification, negotiation, actualization and post-actualization — are governed by the rules and conventions of the particular defined market.

duality

\association between economic events where one is the legal or economic consideration for the other in an exchange

NOTE: Duality is the conceptual analog of double entry in traditional bookkeeping. For example, a shipment from a partner requires a matching flow in, like a payment, to balance accounts between the parties.

economic agreement

arrangement of reciprocated economic commitments between two partners where the abstract specification of terms of trade is incomplete and not subject to legal enforcement

economic bundle

association between economic commitments and the economic contract that bundles those promises and binds them to the two partners who negotiated them

economic claim

expectation of one Person to receive a future inflow of economic resources from another Person because of an economic exchange which is currently incomplete

economic commitment

type of commitment by one Person to transfer economic resources to another Person at some specified point in the future

economic contract

bundling of reciprocated economic commitments between two partners where the abstract specification of the proposed economic exchange is deemed to be complete

economic control

association between a Person and an economic resource where the Person either owns the economic resource or is otherwise able to derive economic benefit (utility) from it

economic event

occurrence in time wherein ownership of an economic resource is transferred from one Person to another Person

NOTE: Occurrences in time can either be internal as mutually agreed to among the parties to a business transaction; and/or reference some common publicly available and recognized date/time referencing schema (e.g. one based on using ISO 8601 and/or ISO 19135).

economic event type

abstract specification of an economic event where its grouped properties can be designated without attachment to an actual, specific occurrence in time

NOTE: Example of attributes at the type level for events might be expected-duration or standard-pricing-percentage.

economic exchange

type of a business transaction where the goal is an exchange of economic resources between two Persons where both parties derive higher utility after the completed business transaction

NOTE: An economic exchange usually involves two economic events with different types of economic resources flowing in opposite directions. For example, an exchange of cash for a good involves a shipment with a requited payment following.

economic resource

good, right or service of value, under the control of a Person

economic resource type

abstract specification of an economic resource where its grouped properties can be designated without attachment to an actual, specific economic resource

NOTE: Example attributes at the type level for an economic resource like an automobile might include its designated fuel capacity or its maximum expected range.

economic role

abstract specification of a Person for economic purposes where its grouped properties can be designated without attachment to an actual Person

NOTE: An example economic role might be qualified buyer or approved shipper, i.e. from an economic perspective only.

economic specification

association between an economic commitment and the abstract properties of an economic event, an economic resource, a partner or a business location

entity

concrete or abstract thing that exists, did exist or might exist including associations among these things

EXAMPLE: A person, object, event, idea, process, etc.

NOTE: An entity exists whether data about it are available or not.

[ISO/IEC 2382-17:1999 (17.02.05)]

external constraint

constraint which takes precedence over internal constraints in a business transaction, i.e. is external to those agreed upon by the parties to a business transaction

NOTE 1: Normally external constraints are created by law, regulation, orders, treaties, conventions or similar instruments.

NOTE 2: Other sources of external constraints are those of a sectorial nature, those which pertain to a particular jurisdiction or mutually agreed to common business conventions (e.g. INCOTERMS, exchanges, etc.).

NOTE 3: External constraints can apply to the nature of the good, service and/or right provided in a business transaction.

NOTE 4: External constraints can demand that a party to a business transaction meet specific requirements of a particular role.

EXAMPLE 1: Only a qualified medical doctor may issue a prescription for a controlled drug.

EXAMPLE 2: Only an accredited share dealer may place transactions on the New York Stock Exchange.

EXAMPLE 3: Hazardous wastes may only be conveyed by a licensed enterprise.

NOTE 5: Where the information bundles (IBs), including their Semantic Components (SCs), of a business transaction are also to form the whole of a business transaction (e.g. for legal or audit purposes), all constraints must be recorded.

EXAMPLE: There may be a legal or audit requirement to maintain the complete set of recorded information pertaining to a business transaction, i.e. as the information bundles exchanged, as a “record”.

NOTE 6: A minimum external constraint applicable to a business transaction often requires one to differentiate whether the Person, i.e. that is a party to a business transaction, is an “individual”, “organization” or “public administration”. For example, privacy rights apply only to a Person as an “individual”.

[ISO/IEC 15944-1:2002 (3.23)]

fulfillment

association between an economic commitment and an economic event where the event executes the promised resource flow from one Person to another

NOTE: For example, a delivery to a customer would fulfill that customer’s sale order.

governed

association between an economic agreement and the business transaction whose conduct and phases are subject to that economic agreement

individual

Person who is a human being, i.e. a natural person, who acts as a distinct indivisible entity or is considered as such

[ISO/IEC 15944-1:2002 (3.28)]

information bundle – IB

formal description of the semantics of the information to be exchanged by Open-edi Parties playing roles in an Open-edi scenario

[ISO/IEC 14662:2004 (4.1.2.2)]

internal constraint

constraint which forms part of the commitment(s) mutually agreed to among the parties to a business transaction

NOTE: Internal constraints are self-imposed. They provide a simplified view for modeling and re-use of scenario components of a business transaction for which there are no external constraints or restrictions on the nature of the conduct of a business transaction other than those mutually agreed to by the buyer and seller.

[ISO/IEC 15944-1:2002 (3.33)]

location type

abstract specification of an economic location where its grouped properties can be designated without attachment to an actual place

NOTE: An example location type might be an accepted shipping facility or approved hospital location.

materialized

association between an economic event and an economic claim where the occurrence of the economic event causes the economic claim to come into existence

mediated transaction

subtype of a business transaction where a third party mediates between the partners as mutually agreed to by the partners

object

anything perceivable or conceivable

NOTE: Objects may be material (e.g. an engine, a sheet of paper, a diamond), immaterial (e.g. a conversion ratio, a project plan) or imagined (e.g. a unicorn).

[ISO 1087-1:2000 (3.1.1)]

Open-edi

electronic data interchange among multiple autonomous Persons to accomplish an explicit shared business goal according to Open-edi standards

[ISO/IEC 14662:2004 (3.1.9)]

Open-edi Business Transaction Ontology – OeBTO

formal, rule-based specification and definition of the concepts pertaining to business transactions and scenarios and the relationships that hold among those concepts

Open-edi Party – OeP

Person that participates in Open-edi

NOTE 1: Adapted from ISO/IEC 14662:2004 (3.1.11).

NOTE 2: Often in ISO/IEC 15944 referred to generically as “party” or “parties” for any entity modeled as a Person as playing a role in Open-edi scenarios.

Open-edi scenario – OeS

formal specification of a class of business transactions having the same business goal [ISO/IEC 14662:2004 (3.1.12)]

organization

unique framework of authority within which a person or persons act, or are designated to act, towards some purpose

NOTE: The kinds of organizations covered by this part of ISO/IEC 15944 include the following examples:

  • an organization incorporated under law;
  • an unincorporated organization or activity providing goods and/or services including:
    • partnerships,
    • social or other non-profit organizations or similar bodies in which ownership or control is vested in a group of individuals,
    • sole proprietorships,
    • governmental bodies;
  • groupings of the above types of organizations where there is a need to identify these in information interchange. [ISO/IEC 6523-1:1998 (3.1)]
  • organization part department, service or other entity within an organization, which needs to be identified for information interchange

[ISO/IEC 6523-1:1998 (3.2)]

organization Person

organization part which has the properties of a Person and thus is able to make commitments on behalf of that organization

NOTE 1: An organization can have one or more organization Persons.

NOTE 2: An organization Person is deemed to represent and act on behalf of the organization and to do so in a specified capacity.

NOTE 3: An organization Person can be a “natural person” such as an employee or officer of the organization.

NOTE 4: An organization Person can be a legal person, i.e. another organization.

[ISO/IEC 15944-1:2002 (3.46)]

participates

association between an economic event and each of the two Persons participating in the economic event

NOTE; Usually there is a “from” association and a “to” association, depending upon the direction of the flow of the economic resource.

partner

subtype of Person that includes buyer and seller

Person

entity, i.e. a natural or legal person, recognized by law as having legal rights and duties, able to make commitment(s), assume and fulfill resulting obligation(s), and able to be held accountable for its action(s)

NOTE 1: Synonyms for “legal person” include “artificial person”, “body corporate”, etc., depending on the terminology used in competent jurisdictions.

NOTE 2: Person is capitalized to indicate that it is being utilized as formally defined in the standards and to differentiate it from its day-to-day use.

NOTE 3: Minimum and common external constraints applicable to a business transaction often require one to differentiate among three common subtypes of Person, namely “individual”, “organization” and “public administration”. [ISO/IEC 15944-1:2002 (3.47)]

process

series of actions or events taking place in a defined manner leading to the accomplishment of an expected result

[ISO/IEC 15944-1:2002 (3.53)]

public administration entity

a Person, which is an organization and has the added attribute of being authorized to act on behalf of a regulator

[ISO/IEC 15944-1:2002 (3.54)]

reciprocal

association between economic commitments where the promise by one partner to execute an economic resource transfer in the future is reciprocated by the other partner promising a requited transfer in the opposite direction

recorded information

information that is recorded on or in a medium irrespective of form, recording medium or technology utilized, and in a manner allowing for storage and retrieval

NOTE 1: This is a generic definition and is independent of any ontology (e.g. those of “facts” versus “data” versus “information” versus “intelligence” versus “knowledge”, etc.).

NOTE 2: Through the use of the term “information”, all attributes of this term are inherited in this definition.

NOTE 3: This definition covers: any form of recorded information, means of recording, and any medium on which information can be recorded; and all types of recorded information including all data types, instructions or software, databases, etc.

[ISO/IEC 15944-1:2002 (3.56)]

regulator

Person who has the authority to prescribe external constraints which serve as principles, policies or rules governing or prescribing the behavior of Persons involved in a business transaction as well as the provisioning of goods, services and/or rights interchanged

[ISO/IEC 15944-1:2002 (3.59)]

resource-flow

association between an economic event and an economic resource

NOTE: A common example would be a resource-flow between some inventory and the shipment that caused control of that inventory to flow from one Person to another.

responsibility

association between Persons where one is responsible for the other or between a Person and an organization Person where that Person is assigned

NOTE Subtypes of Persons include individuals, organizations and public administrations. An “individual” is nondivisible but organizations and public administrations are and as such will assign specific responsibilities to organization Persons (see further 6.2.7 and Figure 17 in ISO/IEC 15944-1:2002).

role

specification which models an external intended behaviour (as allowed within a scenario) of an Open-edi Party

[ISO/IEC 14662:2004 (4.1.2.1)]  

seller

Person who aims to hand over voluntarily or in response to a demand or a request, a good, service and/or right to another Person and in return receives an acceptable equivalent value, usually in money, for the good, service and/or right provided

[ISO/IEC 15944-1:2002 (3.62)]

Semantic Component – SC

unit of recorded information unambiguously defined in the context of the business goal of the business transaction

NOTE: An SC may be atomic or composed of other SCs.

[ISO/IEC 14662:2004 (4.1.2.2)]

settlement

association between a requiting economic event and an economic claim where the occurrence of the event causes the economic claim to expire

site

association between an economic event and the business location where the transfer of economic resources involved in that event is deemed to have occurred

third party

Person besides the two primarily concerned in a business transaction who is agent of neither and who fulfills a specified role or function as mutually agreed to by the two primary Persons or as a result of external constraints

NOTE: It is understood that more than two Persons can at times be primary parties in a business transaction.

[ISO/IEC 15944-1:2002 (3.65)]

typification

association between a concrete entity and the abstract specification of its grouped properties

undefined market mode

trade model where participants are not registered in advance and where that market does not have accepted and recognized sources for business rules and conventions

Abbreviated terms

BOV Business Operational View
BTE Business Transaction Entity
BTET Business Transaction Entity Type
ebXML electronic business eXtended Markup Language
ECIMF E-Commerce Integration Meta-Framework
EDI Electronic Data Interchange
IB Information Bundle
OCL Object Constraint Language
OeBTO Open-edi Business Transaction Ontology
OeP Open-edi Party
OeS Open-edi Scenario
REA Resource-Event-Agent
SC Semantic Component
UML Unified Modeling Language
UMM Uniform Modeling Methodology
UN United Nations
UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

Previous: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Introduction – 20071101
Next: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Declarative component of an OeBTO – 20071101

ISO/IEC 15944-4 – The declarative component of an OeBTO- 20071101

An ontology has a declarative component – which specifies the categories into which collaboration data exchanged among Persons in a business transaction may be slotted; a procedural component – which specifies how that data is to be used in deriving conclusions; and a constraint component – which specifies the business rules for both data and procedures.

Primitive and Derived Data Classes

Persons and Economic Resources

One of the most fundamental ideas in Open-edi is the category of Person as an entity recognized as having legal rights and duties, able to make commitments, and fulfill resulting obligations. Based on applicable external constraints, a Person can be decomposed into three separate subtypes, namely, “individual”, “organization”, and “public administration” 1. These subtypes are illustrated in the UML class diagram of Figure 1.

In this part of ISO/IEC 15944, the focus is on the OeBTO from an internal constraints perspective only 2. However, users of this part of ISO/IEC 15944 should note that where and whenever Person is utilized, it covers the three sub-types of individual, organization, and public administration.

Subtypes of Person based on External Constraints

Figure 1. Subtypes of Person based on External Constraints.

Rule 1:

Irrespective of the use of any particular information technology and related devices, Persons are the only entities which are legally recognized as able to make commitments, agree to the rights and obligations entered into, can be held accountable for their actions, etc., i.e. Persons are the only entities able to participate in a business transaction and able to make commitments for exchanges of value 3.

Persons are the entities who drive the economic exchanges forward in Open-edi collaborations. Ontologically and normatively, they are considered as homo economicus in the classical microeconomic sense; that is, they are parties interested in commercial activity as a means of maximizing utility.

Besides Person, a second very important notion in the OeBTO is the concept of an Economic Resource which is something of value under the control of a Person. These two fundamental categories appear on the left of Figure 2, connected by an economic control relationship which indicates that the Person either owns the resource or is otherwise able to derive economic value (utility) from it.

Person and Economic Resource as the Basis for Exchange

Figure 2. Person and Economic Resource as the Basis for Exchange.

Onto the right side of Figure 2 (inside the dotted lines) is now added an additional Person and economic resource association, thus setting the stage for a possible exchange where both parties might view control of the other Person’s resource as a means of deriving higher utility than present circumstances render. This “value exchange” as it is titled in the collaboration space (Figure 3 of previous post) is the basis for what Open-edi calls a business transaction between the two Persons.

Rule 2:

An Open-edi Business Transaction is an economic exchange occasioned by the presence of two

Persons as trading partners, each possessing a resource of value desirable to the other party. These Persons shall be autonomous parties with competing economic interests, able to commit to a requited exchange with the other Person.

The Open-edi Business Transaction Ontology does not construct exhaustive classification hierarchies for the primitive classes of Person and economic resource, but it does provide a limited taxonomy for both. The hierarchical decomposition of both of these ontology items beyond 2-3 levels becomes very dependent upon the context of industry structure. Particular de-compositions beyond the second or third level may be joined to the minimum classification structures illustrated here to give more detailed taxonomies for a particular industry domain.

In addition to being classified on identity, Persons may also be classified on the basis of their roles, which are the abstract specification of the functions they perform in business transactions. This functional decomposition through three levels is illustrated in the UML class diagram of Figure 3 and explained below.

  • Partner which itself further specializes to Buyer (has money, desires goods) and Seller (has goods, desires money).
  • Regulator which represents Persons who impose external constraints on Business Transactions.
  • Third Party which specializes to a number of other classes such as Escrow, Guarantor, Mediator, and
  • Agent which is a special sub-type in Open-edi that can act for any other Person in a clearly specified capacity, most commonly for a buyer or a seller.

Subtypes of Person based on Roles in a Business Transaction

Figure 3. Subtypes of Person based on Roles in a Business Transaction.

When fully-specified business transactions occur, Persons are able to play roles as indicated by the different sub-typing shown in Figure 3. Again, this taxonomy could be extended with industry-specific specializations of these role levels 4.

Figure 4 illustrates some of the possible sub-typing for the other OeBTO primitive – economic resource – illustrated in Figure 2. This taxonomy has a second level derived directly from the text of 15944-1 which categorizes resources as:

  • Goods which are tangible resources to include: o Materials including capital assets (like trucks), basic raw materials and natural resources (like steel or petroleum) plus sub-components of a larger assembled product (like seats for an automobile).
    • Real Estate like office buildings or warehouses.
    • Funds like money or marketable securities.
  • Services which are the provision of value-adding activities by a provider to a consumer to include:
    • Human Services like temporary workers or consultants. o Transportation Services like packing/picking or actual shipments.
    • Regulatory Services such as the right to import/export or the right to do business in a certain segment or area.
    • Warranty Services such as the automatic provision of replacement goods under faulty judgments.
    • Insurance Services such as guaranteed payment under exigent circumstances.
    • Rights which are intangible resources to include examples like Intellectual Products (IPR) and Rightsof-way 5.

ISO 15944-4 Figure 7 Subtypes -possible- for Economic Resource

Figure 4. Subtypes (possible) for Economic Resource.

Rule 3:

Economic Resources may be classified as goods, rights, or services. Particular industry level classifications can further specialize this first level of decomposition.

Figure 4 also shows a recursive association that is especially important in ontological terms because it reflects an important aspect of economic reality – that economic resources often have component structures. This means that their value is often derived from an assemblage of other resources.  For a product example, those components could be the physical material, its advertised cache, its delivered-to-the-door-status, and its warranty.

Rule 4:

Economic Resources in the vast majority of trading cases will have component structures that can be identified and treated differentially in economic exchanges.

As an example of the logic of Rule 4, example goods that are termed free-on-board at source (FOB source) would be missing a delivery component that free-on-board destination (FOB destination) would have included.

In Open-edi, a business transaction involves an economic exchange of resources between Persons with competing economic interests, each attempting to maximize his or her own economic utility. As portrayed in 15944-1 and shown in Figure 5, there are two additional fundamental elements of a Business Transaction Model besides PERSON (discussed amply above). The first of these is the DATA involved in the transaction, and the ontological categories for capturing that data will be the topic for the rest of this Clause 5. The other fundamental element is the PROCESS involved in a business transaction and that will be the main topic for the following Clause 6. Clause 7 illustrates the constraint component where the business rules concerning both data and processes are enumerated.

Fundamental parts of a business transaction

Figure 5. Fundamental parts of a business transaction.

Normative Data Categories for a Business Transaction involving an Economic Exchange: Resources, Events, and Persons plus their fundamental Relationships

The UML class diagram of Figure 6 illustrates the high level semantic view of the essentials of an economic exchange. In Open-edi, the full details of this exchange are realized within the scope of a single business transaction as trading partners identify each other, negotiate commitments, and engage in the actual exchange of resources with value.

As a starting point for ontological definition, this collaboration space diagram concentrates on the object answers to four fundamental questions:

  • Who is involved in the collaboration (Persons)?
  • What is being exchanged in the collaboration (Economic Resources)?
  • When (and under what trading conditions) do the components of the exchange occur (Economic Events)?
  • Why are the trading partners engaged in the collaboration (duality relationships between resource flows)?

The normative infrastructure of the Open-edi Business Transaction Ontology (OeBTO) encompasses these essential question components, as explained in Addition of Business Event to Basic Exchange Pattern below. Extension of the OeBTO into Types below illustrates the ontological components that result from typifying the OeBTO normative infrastructure, while Locations and Claims below deals with the non-normative extensions of claims and business locations. Adding Commitments to Economic Exchanges below discusses the elaborate commitment structures of the OeBTO, and Business Transactions with Contracts below accounts for the extended ontology objects of scenarios and markets.

Figure 6 illustrates the basic economic primitives of OeBTO in a UML class diagram. An actual value exchange in the collaboration space of Open-edi between a buyer and a seller would involve two instances of this object pattern. That is, there would a resource-event-person pattern instance for an initial resource transfer from one partner to the other; this would then be followed by a connected (with duality associations) resource-event-person pattern instance for a requiting resource transfer. A full example of this is shown in Figure 7 with a delivery of product followed by a payment of cash. In very general terms, a full economic exchange of value in collaboration space is defined as a Business Transaction in the Open-edi ontology. It is important to remember that Bilateral Transactions between a buyer and a seller constitute the basic collaborative unit in Open-edi. These bilateral transactions may be aggregated to Mediated Transactions involving more than two Persons.

Basic exchange primitives of the Open-edi Ontology

Figure 6. Basic exchange primitives of the Open-edi Ontology.

Exchange of value in collaboration space involves two symmetrical Resource-Event-Agent clusters

Figure 7. Exchange of value in collaboration space involves two symmetrical Resource-Event-Agent clusters.

Entity Definitions:

  1. A Person is a natural or legal person unit empowered to control the flow of economic resources (including his or her own labor) by engaging in economic events. Persons are also empowered to make commitments or promises to execute resource flows in the future. The Person class may also include persons who are responsible for subordinates’ participation in economic events. A subset of Person is Partner; partners are Persons who play the leading roles in business transactions as sellers and buyers (or alternatively, as producers and consumers of services).
  2. An Economic Resource is a scarce good, right, or service that possesses utility (economic value) and that is presently under the identifiable control of a particular Person.
  3. An Economic Event most simply is an inflow or outflow of an economic resource. Economic events reflect changes in economic resources resulting from exchanges, conversions, or transportation.

Relationship Definitions:

  1. A resource-flow relationship is an association between an economic resource and an economic event. From the independent perspective, resource-flow instances are matched in bi-directional fashion with each party both giving and taking in the same exchange.
  2. A participates relationship is an association between a Person and an economic event. Economic events normally have two participates relationships with independent parties who have competing economic interests (that is, they are said to have an arm’s length relationship with each other). One of these is specialized on the class diagram of Figure 6 as “from” and the other as “to”, indicating again the independent perspective of collaboration.
  3. A duality relationship is an association between two (or more) economic events where one is the economic or legal consideration for the other in an economic exchange. Dualities are needed for every binary component of mediated transactions.
  4. A custody relationship is an association between a Person and an economic resource where physical control or access to physical control possession is indicated.
  5. Responsibility is a relationship between (among) two or more Persons. These responsibility associations indicate hierarchical orderings within an enterprise that are necessarily revealed to trading partners in a collaboration model.

Rule 5:

The minimum normative constellation of business transaction entities needed for a valid business transaction includes Economic Resources, Economic Events, and Persons plus their exchange relationships (resource-flow, duality, and participates).

Rule 6:

Custody and responsibility relationships are not required for a valid economic exchange, but they provide critical additional data to the basic exchange template.

Addition of Business Event to Basic Exchange Pattern:

In Figure 8, the primitive Business Event has been added to the basic OeBT ontology pattern in a UML class diagram. A business event is an occurrence in time in collaboration space that Persons wish to plan, control, monitor, or evaluate. To bring about the occurrence of an economic event, it is often necessary to perform multiple business events. Additionally, business events may also be aggregates of other, finer-grained business events, so the UML component structure for a business workflow is shown as recursive business events. In a state machine sense where many elements of the OeBTO become business transaction entities (representing business transaction entity types as explained in Clause 6) with defined object states and defined object lifecycles, a business event can be defined more precisely as an occurrence that causes a state change in one or more business transaction entities.

Rule 7:

Business Events can either occur instantaneously or have duration. For a business event that has duration, it will be possible to specify as its components, both starting and finishing events of instantaneous nature.

Addition of Business Event to Basic Business Transaction Pattern

Figure 8. Addition of Business Event to Basic Business Transaction Pattern.

Extension of the OeBTO into Types

Abstract concepts are information structures used to describe the intangible components of actual phenomena. For ontologists, this is an important distinction. In the OeBT ontology, “type images” are used to represent the abstract structure of economic phenomena. For the construction of abstract concepts, the common abstraction mechanism of typification is used.6  This abstraction method is portrayed in Figure 9.

The bottom of Figure 9 represents things that really exist or have actually happened, like a digital product or some real material or an event that has transferred ownership of such resources. In concrete economic terms, this is where accountability for past and near future activities lies. At the top of the figure is where policies are specified in terms of the abstract economic future: things that could be or should happen. Typification works by abstractly specifying the grouped properties of real things, and policies can then be derived by associating those abstract entities.

In the UML class diagram of Figure 10, three of the economic primitives defined previously (Economic Resource, Economic Event, and Person), are typified to produce their abstract specification classes shown at the top of the figure (Economic Resource Type, Economic Event Type, and Economic Role).

Abstract specification with typification

Figure 9. Abstract specification with typification.

When type images are connected with each other as illustrated in the top constellation of Figure 10, policy artifacts often emerge, such as the association between an Economic Event Type (for example, large amount sales) and an Economic Role (such as the managerial position needed to authorize such a class of transactions). This kind of abstract specification is especially important to the pre-actualization components (planning, identification, and negotiation) of an Open-edi business transaction. For example, parties often specify in advance the types of goods they desire to be shipped under different delivery categories by different types of shipping agencies. Typification is strongly linked to the concept of Open-edi Scenarios which are formal specifications of particular classes of business transactions designed for reusability. As discussed in Clause 6, connected type images also result many times in control artifacts such as the rules embodied in internal and external Open-edi constraints. Such constraints supply pre- and post-conditions on state machine transitions.

Type connections for policy and planning

Figure 10. Type connections for policy and planning.

Typification is a non-normative extension of the components of a basic economic exchange. Connecting typified entities specifies the abstract rules or business policies under which business transactions occur.

Locations and Claims

The UML class diagram of Figure 11 illustrates two non-normative additions to the basic Open-edi ontological framework.

  1. A Business Location designates the site where an economic event occurs if such information is needed. Locations also indicate the targeted delivery points for Economic Commitments. Location Types indicate grouped instances like an approved kind of delivery warehouse or an acceptable medical facility.
  2. An Economic Claim is an optional materialization of a temporal imbalance in a duality relationship where an economic event has occurred without its requited correspondence to another economic event. An initial economic event materializes the claim, while the requiting economic event settles it.

Addition of Business Location and Economic Claim

Figure 11. Addition of Business Location and Economic Claim.

Adding Commitments to Economic Exchanges

In the Open-edi ontology, a business transaction pertains to the exchange of something of value as illustrated in the delivery-payment example of Figure 10. An additional key property of an Open-edi business transaction is that it involves commitment exchange as illustrated in Figure 12. In economic terms however, commitments do not occur in isolation because partners simply do not agree to value exchanges without reciprocation. Commitments are bundled in Economic Contracts between trading partners where, for example, a commitment to deliver some product is reciprocated by a commitment to pay cash.

Contract as a Bundle of Commitments

Figure 12. Contract as a Bundle of Commitments.

Rule 9:

Economic commitments are fulfilled by economic events; these commitments are the promised analog of economic events which are connected by duality relationships. Thus, commitments also occur in reciprocal pairs where the promise of one party is requited by the promise of the other.

In Figure 13, the ex ante nature of commitments is illustrated further. At a minimum, an Open-edi economic commitment should specify the type of economic resource expected in the fulfilling economic event. For example, a catalogue order chooses from a product list for delivery. Additionally, the economic commitment often will specify:

  1. the type of event to fulfill it (such as an expedited delivery or a purchase under wholesale pricing), and
  2. the business roles needed in the eventual exchange (such as a buyer, a seller, a seller agent, and a third-party escrow).

Economic commitments may less commonly specify types of locations, like an approved class of warehouse.

 Abstract specification of Commitments

Figure 13.  Abstract specification of Commitments.

Business Transactions with Contracts

The UML class diagram of Figure 14 formally adds Economic Commitment structures to the basic notion of an economic exchange. As mentioned previously, commitment is one of the defining features of Open-edi, so these structures are extremely important ontological components.

  1. An Economic Commitment is a promise to execute an Economic Event at some point in the future. The specification of an Economic Commitment may involve relationships with four type-level classes: Economic Resource Type, Location Type, Economic Event Type, and Economic Role. Economic Commitments may also have relationships with Economic Resource (reserves), Person (participate), and Business Location (target).
  2. A fulfillment relationship is an association between an Economic Commitment and the Economic Event that executes that commitment.
  3. A reciprocal relationship is an association between Economic Commitments that each in turn individually fulfills compensating economic events.
  4. An Economic Contract is a bundle of reciprocating commitments wherein two Parties agree to a future schedule of exchanges with compensating economic events. An Agreement is similar to an economic contract, but it is not legally enforceable.
  5. An economic bundle relationship is an association between an Economic Contract and its pair of reciprocal Economic Commitments.

Business Transaction Model with Bundled Commitments

Figure 14. Business Transaction Model with Bundled Commitments.

Rule 10:

An Economic Contract is a reification of the reciprocal relationship among groups of Economic Commitments. When the paired commitments have simple structures and there are no legal needs for a formal agreement, the Economic Contract entity becomes optional.

Figure 15 illustrates the full addition of the “commitments to type specification” by combining Figures 13 and 14. Additionally, it extends the concept of a Bilateral Transaction to that of a Mediated Transaction by including the previously-defined Third Party subtype of Person as an essential ingredient of mediated collaborations. Figure 15 also indicates the essential roles of Regulators who are Persons who constrain business transactions.

Collaboration with Commitment structures

Figure 15. Collaboration with Commitment structures.

Rule 11:

A Bilateral Business Transaction includes just the two basic kinds of Partner: the Buyer and the Seller (or an Agent for one or both). Mediated Business Collaborations involve the participation of a Third Party like a Guarantor or a Notary.

Rule 12:

All Open-edi business transactions, which include the modeling of external constraints in addition to internal constraints only, are subject to the participation of a Regulator – a Person with the authority to prescribe external constraints which serve as principles or rules governing the behavior of other types of participants in a business transaction.

Typifying Agreements and Business Transactions

Figure 16 and Figure 17 illustrate typification of Economic Agreements and Business Transactions.

  1. All Business Transactions are set in both Defined Markets and Undefined Markets, both of which are overseen by various Jurisdictional Domains.
  2. Business Transactions may be classified into different kinds of Open-edi Scenarios such as the 2x2x2 (overall giving eight combinations) factoring shown in the cloud at the bottom of Figure 16. 7.

An Agreement can be decomposed into classes like Leases/Rentals, Service Agreements, Consignments, and Purchases. Agreements have Pricing Methods like reverse auctions, open and closed bids, and individual quotes. These methods can in turn be typified into classes (Pricing) like bid, auction, or matching. These are all illustrated in Figure 17.

The modeling specifications illustrated in Figure 1 through Figure 17 give specific conceptual definition to many of the Open-edi Business Transaction terms used in ISO/IEC 15944-1. In the following clause, the behavioral use of these components is explained with explicit reference to the Open-edi notion of business transaction phases. According to ISO/IEC 15944-1, a business transaction proceeds through the stages of planning, identification, negotiation, actualization, and post-actualization, and an ontologically-based state machine model of this progress is explained there.

Addition of markets and scenarios for Business Transactions

Figure 16. Addition of markets and scenarios for Business Transactions.

Agreement Types with Pricing Methods

Figure 17. Agreement Types with Pricing Methods.

Previous: ISO/IEC 15944-4 – Business transaction scenarios – Accounting and economic ontology (1st edition) – Terms and definitions – 20071101
Next: ISO/IEC 15944-4 – The procedural component of an OeBTO – 20071101

  1.   See further in ISO/IEC 15944-1:2002, 6.2 “Rules governing Person” and in particular, 6.2.7 “Person and external contraints: individual, organization and public administration.”
  2.   With respect to incorporating external constraints, see further ISO/IEC 15944-5:2006; in particular, see 5.2.2 “Collaboration space — internal constraints only” and 5.2.3 “Collaboration space — the role of ‘regulator’ representing “external contraints”, and Annex G.
  3.  Rule 1 is based on ISO/IEC 15944-1:2002, 6.2, Rule 11.
  4.  Because of this industry specificity, these hierarchical decompositions should be viewed as informative rather than normative. This is especially true of the decomposition of “third party” where industry specificity gives rise to many different types of role names.
  5.  Again as in Figure 3, these hierarchical de-compositions should be viewed as informative rather than normative. This is especially true of the third level decomposition in Figure 4 which is clearly designed as an example enumeration.
  6. For an explanation of typification, see Geerts, GL and McCarthy, WE – Using object templates from the REA Enterprise Information Systems, Journal of Information Systems, 2006
  7. A more complete explanation of this classification scheme for Open-edi Scenarios is given in ISO/IEC 15944-2

ISO/IEC 15994-4 – The procedural component of an OeBTO – 20071101

An ontology has a declarative component – which specifies the categories into which collaboration data exchanged among Persons in a business transaction may be slotted; a procedural component – which specifies how that data is to be used in deriving conclusions; and a constraint component – which specifies the business rules for both data and procedures.

In an operational use of the Open-edi Business Transaction Ontology, the various declarative components specified in Clause 5 – for example all of the classes illustrated in Figure 15 – become defined as Business Transaction Entity Types (BTET). BTETs represent the abstract specification of Business Transaction Entities (BTE), detailing their recommended attributes, their recommended methods, and their recommended life-cycle states. Additionally, a business transaction entity type will usually specify the types of business events that cause a BTE of this type to proceed through its different states as the business transaction itself progresses through its own phases of planning, identification, negotiation, actualization, and post-actualization. A BTE thus is a particular real instance of a business transaction entity type.

Rule 13:

A Business Transaction Entity (BTE) is the computable representation of any real world entity that participates, occurs, or is materialized during a particular business transaction. For procedural materialization of conclusions during the business transaction, the combined use of the BTE attributes, methods, and states may be used to determine its status as a component in an economic exchange.

Relating Ontological Components to the Open-edi Business Transaction Phases

From ISO/IEC 15944-1, the paragraphs below enumerate the five identified phases of an Open-edi Business Transaction. This phase specification is one of the major building blocks of ISO/IEC 15944-1.

  1. Planning: In the Planning Phase, both the buyer and seller are engaged in activities to decide what action to take for acquiring or selling a good, service, and/or right.
  2. Identification: The Identification Phase pertains to all those actions or events whereby data is interchanged among potential buyers and sellers in order to establish a one-to-one linkage.
  3. Negotiation: The Negotiation Phase pertains to all those actions and events involving the exchange of information following the Identification Phase where a potential buyer and seller have:
    1. identified the nature of good(s) and/or service(s) to be provided; and,
    2. identified each other at a level of certainty. The process of negotiation is directed at achieving an explicit, mutually understood, and agreed upon goal of a business collaboration and associated terms and conditions. This may include such things as the detailed specification of the good, service, and/or right, quantity, pricing, after sales servicing, delivery requirements, financing, use of agents and/or third parties, etc.
  4. Actualization: The Actualization Phase pertains to all activities or events necessary for the execution of the results of the negotiation for an actual business transaction. Normally the seller produces or assembles the goods, starts providing the services, prepares and completes the delivery of good, service, and/or right, etc., to the buyer as agreed according to the terms and conditions agreed upon at the termination of the Negotiation Phase. Likewise, the buyer begins the transfer of acceptable equivalent value, usually in money, to the seller providing the good, service, and/or right.
  5. Post-Actualization: The Post-Actualization Phase includes all of the activities or events and associated exchanges of information that occur between the buyer and the seller after the agreed upon good, service, and/or right is deemed to have been delivered. These can be activities pertaining to warranty coverage, service after sales, post-sales financing such as monthly payments or other financial arrangements, consumer complaint handling and redress or some general post-actualization relationships between buyer and seller.

Rule 14:

Conceptually, a business transaction can be considered to be constructed from a set of fundamental activities. They are planning, identification, negotiation, actualization and post-actualization.

Figure 18 adds the definition of these Business Transaction Phases to the OeBTO declarative primitives for a bilateral collaboration.

Open-edi Ontology with Business Transaction Phases and Business Events

Figure 18. Open-edi Ontology with Business Transaction Phases and Business Events.

Figure 18 also specifies that these Open-edi business process phases have Business Events as components, illustrating the behavioral progress through each phase as marked by collaborative activities. A Business Event is defined as an occurrence in time that partners to a business transaction wish to monitor or control.  Business events are the fuel that drives a business transaction state machine, as they progress that dynamic representation through its five phases by changing the states of the ontological components illustrated in Figure 18. Additionally, Business Events have component structures as illustrated by the recursive relationships in Figure 18, and this facilitates the modeling of activities in business collaboration space at whatever level of granularity is needed. Business Event components of instant duration can drive the state of a higher-level Business Event with extended duration from start to completion, and that higher level component may then effect a state change in one of the other Business Transaction Entities for a particular transaction.

Figure 19 illustrates the approximate correspondence of the Open-edi Business Transaction phases with the categories of ontological components defined in Clause 5.

ISO Open-edi Phases with Components

Figure 19. ISO Open-edi Phases with Components.

  • Planning and Identification involve business events wherein potential buyers and sellers identify each other by matching on proposed types of resources to be exchanged and their actual trading partners.
  • Negotiation involves business events wherein linked business partners cooperate on the abstract specification of their proposed exchange (its type of resources, events, and roles as stipulated in a contract).
  • Actualization and Post-Actualization involve business events that aggregate to the performance of resource transfers (the actual economic events) between the buyer and seller.

Business Events are the specific activities that mark the explicit states that trading partners expose to each other as they complete an exchange. For example, supplying a quote on a listed product during negotiation may progress an Economic Commitment from status (or state) “unspecified” to “proposed” while simultaneously marking a Resource Type and an Event Type as “specified”. If this Business Event of supplying a quote was followed by a quote acceptance and then a payment terms acceptance, an Economic Contract might move into status “in-force” and then the entire Negotiation Phase might move into state “completed”. This completed negotiation would keep the entire Business Transaction in state “in progress”, whereas an unsuccessful negotiation might have moved the overall Business Transaction into state “aborted” or state “suspended”.

Rule 15:

Business Events are the activities or messages that collaborative business partners use to communicate their progress through a Business Transaction.

Figure 20 portrays the individual phases of a Business Transaction and the targeted object states that would signal to each business partner that a particular phase was now complete.

  1. Planning is complete when both trading partners have formulated an abstract vision of an exchange. This involves moving the entities representing the potential partner and the potential type of resource into “candidate” states.
  2. Identification is complete when the corresponding partners have been identified along with their identified resource types. This establishes a 1-to-1 linkage between the partners concerning a common trading interest.
  3. Negotiation is complete when the abstract specification of economic commitments is done and when all the commitments and a contract move to an “in-force” condition. Generally, this would mean that the entities for the types of resources to be exchanged are in state “specified”. It could also mean that economic specifications are complete for the type of event, the economic roles, and the types of location.
  4. Actualization is complete when the requiting Economic Event entities are both in state “complete”, thus marking the completion of the full exchange.
  5. Post-Actualization is complete when the possible warranty (or similar post-exchange exception condition) component of an Economic Resource is invoked, and the conditions of the exchange reach their final values.

Phases of a Business Transaction and Object States for Completion

Figure 20. Phases of a Business Transaction and Object States for Completion.

Figure 21 illustrates how the declarative ontological components of Open-edi (referred to here as Business Transaction Entity Types) can be augmented to account for state machine mechanics. Each ontological component is envisioned as a possible Business Transaction Entity with a defined Business Transaction Entity Lifecycle consisting of multiple Business Transaction Entity States. The transition to these states is effected by the occurrence of a Business Event.

Business Transaction Entities, Lifecycles, States, and Events

Figure 21. Business Transaction Entities, Lifecycles, States, and Events.

Figure 22 illustrates some example states that could be identified for some of the Open-edi Ontology components defined thus far. In a full ontological specification, all of the business transaction entity types defined in this document would be given fully-enumerated lifecycles of object states (as specified in Figure 21). However, these would change from one business context to another, so the exposition here is limited to these four samples.

Rule 16:

In the OeBTO, all declarative components become candidates for Business Transaction Entities, and each of these in turn will have a defined life cycle of states that will mark its progressive use in the representation of a real economic exchange.

Sample States for Business Transaction Entities

Figure 22. Sample States for Business Transaction Entities.

Figure 23 lists an example set of Business Events involved in a typical instance of a Business Transaction. These 14 Business Events represent a full collaboration between an example buyer and seller, as it proceeds through the Open-edi phases. Again, each Business Event might cause multiple state changes. For example:

  1. The fourth activity – Buyer sends Availability and Price Request to Seller – would cause:
    1. the Economic Resource Type to move into its Specified state, and
    2. the Identification Phase to move into its In-Force state.
  2. The ninth activity – Buyer sends an Order Acceptance to Seller for parts – would cause:
    1. the Economic Resource Types, the Economic Event Types, and the Economic Roles to move into their Specified states, and
    2. the Economic Contract and the Economic Commitment entities to move into their In-Force
  3. The eleventh activity – Buyer sends Receiving Report to Seller when inspected goods are accepted – would cause:
    1. the Economic Event to move into its Completed state, and
    2. the Economic Resource to move into its Transferred

An Example Business Transaction with Business Events Grouped in Phases

Figure 23. An Example Business Transaction with Business Events Grouped in Phases.

A UML state machine diagram is the best formal specification of dynamic object behavior with state changes. Such a specification is illustrated in Figure 24 for the Business Entity Type “Economic Resource Type” as it moves through the example collaboration.

  1. The Economic Resource Type (for example a type of inventory) would become a Candidate when the Publish-Catalog event occurs, moving from its initial undefined state (black dot).
  2. The Send-Availability-And-Price-Request event would then move the inventory into state This same event would move the Identification Phase of the Business Transaction into state In-Service (not shown in Figure 24).
  3. The Return-Availability-And-Price-Result would cause the inventory to become This same event would move the Identification Phase of the Business Transaction into state Complete (not shown).
  4. The Send-Offer event would shift the example inventory into its Proposed state.
  5. The Accept-Offer would cause the Economic Resource Type to become Specified.
  6. And finally, a Send-Shipping-Notice action would cause the resource type to move to an Actualization state (end of object life cycle). 1

State Machine Diagram for Economic Resource Type

Figure 24. State Machine Diagram for Economic Resource Type.

Figure 24 illustrates the progress of a collaboration between two trading partners from the perspective of one Business Transaction Entity as it progresses through its state changes. Figures 24-27 provide a different, but much more comprehensive view of progress through the first three phases (planning, identification, and negotiation) 2 the same business transaction. 3 Each of these figures illustrates a UML activity graph with various business events (such as “Publish-Catalog” at the top right of Figure 25) being performed by either the buying partner (left column) or the selling partner (right column). The collaboration space between the buyer and seller (first illustrated in Figure 3) is where the shared business entity states reside that allow each partner to determine simultaneously what the exact status of the overall business collaboration is. For example in Figure 25, the Publish-Catalog event at the upper right causes the entity Economic Resource Type to move into state Candidate (as earlier illustrated in Figure 24) and the entity Planning Phase to move into state Waiting Start. For purposes of parsimony, Figures 25-28 do not illustrate all of the state changes that would occur in a collaboration, only an illustrative subset. For example, it would commonly be the case that the Completed state of one transaction phase (such as Identification) would cause the following phase (such as Negotiation) to move into a Waiting Start state. However, this state transition is not shown.

Activity Graph 1 for Collaboration

Figure 25. Activity Graph (1) for Collaboration.

Activity Graph 2 for Collaboration

Figure 26. Activity Graph (2) for Collaboration.

Activity Graph 3 for Collaboration

Figure 27. Activity Graph (3) for Collaboration.

Activity Graph 4 for Collaboration

Figure 28. Activity Graph (4) for Collaboration.

To summarize the state machine presentation, it is necessary to understand how the definitions of Clause 5 and Clause 6 work together.

  1. Clause 5 defined the declarative components of the Open-edi ontology. This is a specification of the primitive classes as they model the components of a business transaction. These primitive classes become candidates for Business Transaction Entity Types, and their realization during an actual business collaboration would become Business Transaction Entities.
  2. Clause 6 defined the procedural components of the Open-edi ontology. This illustrated the dynamic mechanics of tracking business collaboration through each of the five Open-edi phases using state machine mechanics. This progress was illustrated with the UML, first from the perspective of a single business transaction entity (state machine diagram) and second from the perspective of the entire workflow (activity graphs).

With partners communicating with each other through shared states of Business Transaction Entities, the actual status of an Open-edi collaboration is exactly determined for each at any point in time.

Rule 17:

In the OeBTO, the declarative components – the Business Transaction Entities – and the procedural components – the shared collaboration space state machines – work in tandem to fully track the activities and progress in an economic exchange. A realization of the OeBTO requires integrated specification of both of these features in the conduct of an Open-edi business transaction.

Previous:  ISO/IEC 15944-4 The declarative component of an OeBTO – 20071101
Next: ISO/IEC 15944-4 The constraint component of an OeBTO – 20071101

  1. In reality, this state machine example for Economic Inventory is slightly more complicated as the individual state changes would need to be tracked through a UML association class between the Economic Inventory Type and the Business Transaction.
  2. The exposition here is limited to these first three phases for parsimony sake. Including the phases of actualization and post-actualization would make the activity documentation twice as long with little gained in explanatory power.
  3. Figures 25-28 are intended to be read consecutively. For example, the start of Figure 26 (illustrated as a  filled-in circle) connects with the finish of Figure 25 (illustrated as a target circle.

ISO/IEC 15944-4 The constraint component of an OeBTO – 20071101

Business Rules and Open-edi Constraints

Business rules specifying computational procedures, approved sequences of actions, valid inferences, and effective control monitoring govern the day-to-day operations of business enterprises. A useful definition of a “business rule” from Eriksson and Penker is:

… a statement that can control or affect the execution of a business process as well as the structure of the resources in a business. The statement specifies a condition that must be upheld, or a condition that controls which activity should follow next. It can express a business goal, specify the way a process should execute, detail the conditions of a relationship, or constrain the behavior of a resource.

In the database world somewhat synonymously, “constraints” are defined as rules governing the integrity of data that prevent a database from moving from one representation state to another without proper validation, and in the most simple ontological case, their function is exactly congruous with the business rules definition given above. Database integrity constraints are also commonly referred to as assertions.

In ISO/IEC 15944-1, a constraint is defined as “a rule, explicitly stated, that prescribes, limits, governs, or specifies any aspect of a business transaction.” That same standard differentiates those constraints that are self imposed by the trading parties (internal) from those constraints created by law, regulation, orders, treaties, conventions, or similar instruments (external):

  1. internal constraint: a constraint which forms part of the commitment(s) mutually agreed to among the parties to a business transaction
  2. external constraint: a constraint which takes precedence over internal constraints in a business transaction,e., is external to those agreed upon by the parties to a business transaction.

Open-edi further divides the category of external constraints into:

  1. those that are common and horizontal in nature as introduced by the additional presence in a business transaction of a “regulator” as a third subtype of Person representing “public administration“, and
  2. those that are more sectorial in nature (involving standard rules, both across many sectors and across just one sector). Open-edi differentiates these classes of constraints in order to provide summaries of complex bundles of rules for scenario registration. For example, the simplest constraint bundle for a scenario could aggregate only internal constraints; the next most complex could add horizontal external constraints, etc.

In the OeBTO, constraints encapsulating business rules constitute the third major representation component. The first component was the declarative specification of domain classes and associations in Clause 5, while the second component was the procedural aspects associated with business transaction state machines and activity graphs as explained in Clause 6.

OeBTO Constraint Examples

Constraints may be expressed informally in natural language, such as the following accounting rule for separation of duties as applied to the class diagram of Figure 6:

“the Person who fills the participation role in an Economic Event that involves a certain Economic Resource should not be the same Person who has a custody relationship with that Economic Resource”

The need for this constraint to a business transaction could be derived for example from a sectorial application (an OeBTO external constraint) of the 2002 USA Sarbanes-Oxley internal control legislation.

Constraints may also be expressed more formally with the Object Constraint Language (OCL) of the UML. For example, a state sales tax rule for Michigan (another sectorial external constraint) on merchandise orders (a subtype of Economic Contract) could be specified as 6% of the gross amount of the order:

context Order inv michiganSalesTaxCalculation  salesTax = grossAmount × .06

Such a constraint could be placed in curly brackets on a UML class diagram next to the class definition for order (for example, a more specific form of Figure 16), and it then becomes an invariant (inv) or a condition that must be true for all objects of that class.

According to both Odell and Eriksson and Penker, constraints may be of two general behavioral kinds:

  1. Those that define how knowledge in one form may be inferred or derived from another form. Examples of this constraint category might be the Michigan sales tax calculation shown above. Another example might be a constraint that designates a scheduled shipment as “hazardous” if it exceeds a designated weight threshold of goods (economic resources) typed as “dangerous if unpackaged” shown in an inheritance taxonomy that would give domain level expansion to the three levels initially shown in Figure 4.
  2. Those that “constrain either the possible structure or the behavior of objects or processes, that is, the way objects are related to each other or the way objects or process state changes may occur.” An especially prominent illustration for the OeBTO of this class of constraints are rules that define preconditions and post-conditions for the types of state changes described in Clause 6. For example in Figure 26, the state machine diagram makes it clear that for Economic Resource Type to achieve its “proposed” state, it has a pre-condition of being in state “identified” and a post-condition of state “specified” and that these transitions are effected by the business events shown. These same types of rules can be specified as constraints in OCL and portrayed on UML class diagrams.

Both derivation business rules and constraint business rules are important to effective business operation in collaboration space, so their characterization in the Open-edi Business Transaction Ontology is an important third step in insuring interoperability and semantic integrity. To the extent that the declarative and procedural components of an ontology are specified correctly, the parties to a business transaction are given computable methods for ensuring compliance with both internal and external rules of business behavior.

7.3 Summary

There is certainly now a critical opportunity for developing coherence in worldwide standards for business level definitions of economic phenomena. Open-edi, especially in its prior work of ISO/IEC 15944-1, has standardized much of the technical and economic environment for economic exchanges, and the field of ontology provides an extended opportunity for unifying and coordinating that work. This part of ISO/IEC 15944 aims to provide that unity with an ontological analysis of the declarative, procedural, and constraint components of Open-edi. Certainly, the majority of the work in this document concentrates on the declarative components of the OeBTO – those data classes that model the fundamental categories of economic endeavors in collaboration space and the relationships that exist among those categories. This declarative emphasis is reasoned and deliberate. As noted by John Sowa, conceptual progress in a specialized domain is usually marked by an increasing percentage of the knowledge in that field being embedded in its declarative components. As ad hoc procedures and constraints become more structured and predictable, they lead naturally to better theoretical and conceptual structures.

In concert, the declarative, procedural, and constraint components of the Open-edi ontology provide a definitive specification that is formal, explicit, and conceptual. An ontological foundation is one of the key components of that coherence.

Previous: ISO/IEC 15944-4 The procedural component of an OeBTO – 20071101

Next:

ISA Core Vocabularies – Readings

Publications on the Core Vocabularies

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 I

Previously we described the inheritance hierarchy of Classes in Schema.org and visualized this hierarchy as an expandable/collapsible tree using d3.

Now we build upon that work to develop a vocabulary of Classes and their Properties for describing government service.

Seeding the Vocabulary

The starting point for seeding our vocabulary is Schema.org’s Class GovernmentService, used to describe a service that is provided by a government organization or by an organization that is funded by government.

Figure 1 illustrates the pathway to Class GovernmentService within Schema.org’s Inheritance Hierarchy.

Figure 1. Pathway to GovernmentService through Schema.org.

Class GovernmentService has one Property – serviceOperator that is expected to be of Type Organizationanother Class in Schema.org. GovernmentService is the Domain of serviceOperator and Organization is its Range.

Schema.org’s website represents the above in the form of a Table:

Properties from GovernmentService
Property Range Description
serviceOperator Organization The operating organization, if different from the provider. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor.

Table 1. Properties of Class GovernmentService.

We may also represent the information in Table 1 as a Graph, where the Nodes are Classes and Properties, and where the Links are relations connecting them:

Source Node Target Node Link
GovernmentService serviceOperator hasProperty
serviceOperator Organization hasRange

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

Extending the Vocabulary – Cycle 1

This start on a vocabulary for describing government service may be extended in a systematic fashion – first, by incorporating any SuperClass (and its Properties) that contains GovernmentService as a Subclass.

In this manner, our vocabulary extends to include Class Service, Intangible, and Thingas well as their respective Properties. (Note that these Classes are the points highlighted along the pathway in Figure 1).

Again, Schema.org’s website represents each of these SuperClasses in the form of a Table:

Properties from Service
Property Range Description
availableChannel ServiceChannel A means of accessing the service (e.g. a phone bank, a web site, a location, etc.)
produces Thing The tangible thing generated by the service, e.g. a passport, permit, etc.
provider Person  or
Organization
The service provider, service operator, or service performer; the goods producer. Another party (a seller) may offer those services or goods on behalf of the provider. A provider may also serve as the seller.
serviceArea AdministrativeArea The geographic area where the service is provided.
serviceAudience Audience The audience eligible for this service.
serviceType Text The type of service being offered, e.g. veterans’ benefits, emergency relief, etc.

Table 3.1. Properties of Class GovernmentService that are inherited from Class Service.

and

Properties from Thing
Property Range Description
additionalType URL An additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax. This is a relationship between something and a class that the thing is in. In RDFa syntax, it is better to use the native RDFa syntax – the ‘typeof’ attribute – for multiple types. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally.
alternateName Text An alias for the item.
description Text A short description of the item.
image URL  or
ImageObject
An image of the item. This can be a URL or a fully described ImageObject.
name Text The name of the item.
potentialAction Action Indicates a potential Action, which describes an idealized action in which this thing would play an ‘object’ role.
sameAs URL URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Freebase page, or official website.
url URL URL of the item.

Table 3.2. Properties of Class GovernmentService that are inherited from Class Thing.

Class Intangible has no Properties of its own – all of its Properties are inherited from Class Thing.

At the end of Cycle 1 of extending the vocabulary, our Graph is looking much more respectable (compared to Table 1):

At the end of Cycle 1 of extending the vocabulary, our Graph has become much richer (compared to Table 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 ImageObject hasRange
image URL hasRange
name Text hasRange
potentialAction Action hasRange
produces Thing hasRange
provider Organization hasRange
provider Person hasRange
sameAs URL hasRange
serviceArea AdministrativeArea hasRange
serviceAudience Audience hasRange
serviceOperator Organization hasRange
serviceType Text hasRange
url URL hasRange

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

We may serialize the Graph in Table 4 using various semantic technologies, including RDF/XML, RDFa, and Turtle.

Pruning

Note in Table 4 that Property image may be of type URL or ImageObject; here we’re going to use only “cool” URLs – both for the sake of having a persistent identifier for an image that may be modified from time to time and to avoid introducing the clutter of a complex entity like ImageObject – which is incidental to the semantics of a government service – into our vocabulary.

Also note in Table 4 that Property provider may be of type Organization or Person; here we’re going to restrict ourselves to providers of government service that are organizations and not individuals. We will bring Class Person (e.g. as an employee of an organization) into our vocabulary in a subsequent Cycle.

Visualizing

In a fairly traditional manner, our vocabulary for GovernmentService may be visualized as a basic Class Diagram using the Unified Modeling Language (UML):

Figure 2. Visualization of Vocabulary for GovernmentService (Cycle 1) using a UML Class Diagram.

In a more innovative fashion, we may also visualize our vocabulary GovernmentService as a Force-Directed Graph (with Thing, Intangible, Service and GovernmentService fixed in position in the corners of the graph:

Figure 3. Visualization of Graph of GovernmentService (Cycle 1), where o = Property, D = Domain, and R = Range.

See also this interactive version of Figure 3.

Note in Table 4 that several Properties are of type Text or URL – Schema.org treats Text, URL and a few other entities (Boolean, Date, DateTime, Number, Time) as a Datatype (as opposed to a Thing). We may streamline the visualization of our vocabulary by terminating any node corresponding to one of these Properties with a colored-symbol specific to its Datatype:

Figure 4. Legend for terminating a Property node whose Range is Datatype.

Here’s our streamlined visualization of our vocabulary for GovernmentService:

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

See also this interactive version of Figure 5.

Coming Up:

A Vocabulary of Government Service – Part II

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

Semantics of public service

Two major efforts to design and deploy a semantic data model of public service are currently underway:

Schema.org Government Services

In August 2013, Schema.org proposed a vocabulary for Civic Services that was “similar to the European Commission ISA Core Public Service vocabulary”. The hierarchy of schemas includes a vocabulary for Service and the specific subtype GovernmentService.

ISA Core Public Service Vocabulary Application Profile (CPSV-AP)

In 2013, the EC published a Core Public Service Vocabulary under ISA Action 1.1 Improving semantic interoperability in European eGovernment systems and reported on a pilot study of the CPSV  in four jurisdictions. The same year, the EC published a Federated Catalog of Public Services (FCOPS) under ISA Action 1.3 – Improving semantic interoperability in eGovernment systems.

Between November 2014 – January 2015, a Working Group is developing an ISA Core Public Service Vocabulary Application Profile (CVSP-AP) to refine the data model of business life-events and related public services. We will use the interim findings and recommendations of the Working Group to describe the data model of public services that is emerging from the EC’s ISA initiative.

CPSV-AP Graphical representation of classes and properties

Figure 1. Graphical representation of the relations among the classes and properties of the CPSV-AP.

A few definitions provided by the ISA may prove helpful before we compare the semantic data models of public service provided by Schema.org and the ISA:

Glossary
Public administration Public administrations are the competent authorities responsible for public services. They consist of national civil servants across the Member States and the European Commission. The federated catalog of public services will include all public authorities at supranational, national, regional and local levels.
Public administration portal A public administration portal is a portal owned by a public administration that provides information about what the public administration does and which public services they provide to citizens, businesses and other public administrations.
Point of single contact Point of Single Contact is a public administration portal (and a one-stop-shop) for service providers with two main goals: providing information and completing administrative procedures. It is necessary for the portal to describe the requirements, procedures and formalities which are necessary to perform or access the services within a Member State. It also needs to provide contact details of competent authorities, access to public registers, and online forms, and process the applications filed.
Service A service is a resource that represents the capability to bring a certain outcome and value to the service requester and is enabled by the service provider.
Public service A public service is a service rendered by a public administration to either business (A2B), citizens (A2C) or other public administrations (A2A).
Service model A service model is a semantic data model which describes how the public service is built. The description of the service is created by means of metadata (data about data) which identifies all the characteristics and specifications of the data structure of a service.
Services of general interest The concept Services of general (economic) interest (SG(E)I) is an official term used by the European Union for all services that are of specific interest to society. This includes all public services. The scope of the SGIs is broader than the scope of the public services in this document and can also include services which are often, but not always, in hands of private companies (e.g. water, electricity, mail).
Generic public service A generic public service is a service which is defined generically, i.e. it only contains information that applies to all the administrations that offer this service. They are typically defined by a coordinating body in a standardized way. These generic services detail the “what” but do not provide detail on “how” and “where” they are offered by a public administration. However, they can refer to the government level at which they are offered. Each service contains a number of fields to describe the content of the service (title, content and generic conditions, procedures, exceptions, documents and regulations). In addition, each service contains metadata; these fields serve to classify the service (competent authority/government level, authority/government level that delivers this service, theme, type and keyword). These services are constructed by a coordinating body as a unique list, agnostic of all public services offered by all executing public administrations. The outcome is a set of generic public services based on a standardized data model, taxonomy and ontology.
Specific public service Specific public services are the public services which are actually rendered by a specific public administration. A specific service may be linked to a generic public service (if the generic concept exists at Member State level). The specific service is the executable and actionable part of a generic public service offered by a public administration. The same generic service (e.g. issue and ID card) could be executable and offered in many local authorities in various ways (different local forms, different buildings and opening hours). In contrast to generic services, these specific services also detail the “how” and “where” they are offered by a public administration and how they can be rendered by business (A2B), citizens (A2C) or other public administrations (A2A). It will spell out in detail to which authority/building/office one needs to go, give contact details of the organisation that provides the service, forms that need to be filled in and how the service can be rendered electronically.
Catalog of public services A catalog of public services is a database or structured document that contains all the services which are provided by public administrations.
Federated architecture A federated architecture is a composition of autonomous (decentralized) organised systems. It is an approach to coordinate the exchange of information across the organised system. A mapping is created between the multiple autonomous systems which forms the federated architecture; this is achieved by defining guidelines and standardized mapping. In a federated catalog, content syndication is in place. The syndication will support the information exchange between the different systems.
Federated catalog of public services A federated catalog of public services is a collection of other catalogs of public services which are joined together in a standardized method. The database or structured document contains all the public services of the catalogs included.
Controlled vocabulary A controlled vocabulary is a code list which is used to organize or give structure to certain information. It contains predefined values for a certain subject. These vocabularies could be used for indexing schemes, subject headings, taxonomies, etc. These controlled vocabularies are used to give a structure to the federated catalog of public services and categorize the public services (generic and specific).
Taxonomy The taxonomy determines the classification of concepts, the division of ordered groups or categories. It is a science which defines a set of principles in order to classify concepts. In this case the definition of the controlled vocabularies could be seen as the taxonomy.
Ontology Ontology is the science of describing the relationship between concepts. This can be used to gain insight into a particular domain by modelling the concepts and ideas (conceptualization). The reasoning behind the federated catalog can be defined by describing the relationships between the multiple concepts (catalogs).
Semantic data model A semantic data model is a conceptual data model that represents data objects together with their properties and relationships and includes the capability to express information that enables parties to the information exchange to interpret meaning (semantics) from the instances, without the need to know the meta-model.
Interoperability Interoperability, for public service delivery, is the ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective Information and Communication Technology (ICT) systems.

 

Government Service – Schema.org

Overview

A vocabulary for describing Government Service was included in Schema.org  version 1.0d (November 2013). Also see Vocabulary for describing Civic Services – draft, Civic Services – draft 01, Civic Services – draft 02, and Civic Services – RDFS – draft.

Government Service is a more specific type of Service.

In fact, the vocabulary for Government Service adds only one property to the vocabulary for Service:

serviceOperator – typeof Organization

The serviceOperator property enables the representation of a service that is provided by an organization, but operated by another organization, like a subcontractor.

Also note that Schema.org includes GovernmentOrganization, which is a more specific type of Organization, having no additional properties.

Thing > Intangible > Service > GovernmentService

A service provided by a government organization, e.g. food stamps, veterans benefits, etc.
Property Expected Type Description
Properties from GovernmentService
serviceOperator Organization The operating organization, if different from the provider. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor.
Properties from Service
availableChannel ServiceChannel A means of accessing the service (e.g. a phone bank, a web site, a location, etc.)
produces Thing The tangible thing generated by the service, e.g. a passport, permit, etc.
provider Person
or Organization
The organization or agency that is providing the service.
serviceArea AdministrativeArea The geographic area where the service is provided.
serviceAudience Audience The audience eligible for this service.
serviceType Text The type of service being offered, e.g. veterans’ benefits, emergency relief, etc.
Properties from Thing
additionalType URL An additional type for the item, typically used for adding more specific types from external vocabularies in microdata syntax. This is a relationship between something and a class that the thing is in. In RDFa syntax, it is better to use the native RDFa syntax – the ‘typeof’ attribute – for multiple types. Schema.org tools may have only weaker understanding of extra types, in particular those defined externally.
alternateName Text An alias for the item.
description Text A short description of the item.
image URL URL of an image of the item.
name Text The name of the item.
potentialAction Action Indicates a potential Action, which describes an idealized action in which this thing would play an ‘object’ role.
sameAs URL URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Freebase page, or official website.
url URL URL of the item.

Example 1

Without markup

<div>NYC Food Service Establishment Permit, issued by Department of Health and Mental Hygiene.
(issued through NYC Food Service Establishment Permit Service; valid in New York for 1 year).</div>

Microdata

<div itemscope itemtype="http://schema.org/GovernmentPermit">
 <span itemprop="name">NYC Food Service Establishment Permit</span>
 <div itemprop="issuedBy" itemscope itemtype="http://schema.org/GovernmentOrganization">
 <span itemprop="name">Department of Health and Mental Hygiene"</span>
 </div>
 <div itemprop="issuedThrough" itemscope itemtype="http://schema.org/GovernmentService">
 <span itemprop="name">NYC Food Service Establishment Permit Service</span>
 </div>
 <div itemprop="validIn" itemscope itemtype="http://schema.org/AdministrativeArea">
 <span itemprop="name">New York</span>
 </div>
 <time itemprop="validFor" content="P1Y">1 year</time>
</div>

RDFa

<div vocab="http://schema.org/" typeof="GovernmentPermit">
 <span property="name">NYC Food Service Establishment Permit</span>
 <div property="issuedBy" typeof="GovernmentOrganization">
 <span property="name">Department of Health and Mental Hygiene"</span>
 </div>
 <div property="issuedThrough" typeof="GovernmentService">
 <span property="name">NYC Food Service Establishment Permit Service</span>
 </div>
 <div property="validIn" typeof="AdministrativeArea">
 <span property="name">New York</span>
 </div>
 <time property="validFor" content="P1Y">1 year</time>
</div>

JSON-LD

<script type="application/ld+json">
{
 "@context": "http://schema.org",
 "@type": "GovernmentPermit",
 "issuedBy": {
 "@type": "GovernmentOrganization",
 "name": "Department of Health and Mental Hygiene\""
 },
 "issuedThrough": {
 "@type": "GovernmentService",
 "name": "NYC Food Service Establishment Permit Service"
 },
 "name": "NYC Food Service Establishment Permit",
 "validFor": "",
 "validIn": {
 "@type": "AdministrativeArea",
 "name": "New York"
 }
}
</script>

Example 2

Without Markup

This example shows a JSON-LD description of services that do not necessarily have a direct
human-oriented HTML description. It describes a GovernmentService named "Veterans Affairs Emergency Mental Health" its operator, service area and service details, such as its Veterans Crisis Line (including phone contact line
hours of operation, language and other details).

JSON-LD

<script type='application/ld+json'>
{
 "@context": "schema.org",
 "@type": "GovernmentService",
 "name": "Veterans Affairs Emergency Mental Health",
 "serviceType": "Psychiatric Emergency Services",
 "operator": {
 "@type": "GovernmentOrganization",
 "name": "US Department of Veterans Affairs"
 },
 "serviceArea": {
 "@type": "AdministrativeArea",
 "name": "Massachusetts"
 },
 "serviceAudience": {
 "@type": "CivicAudience",
 "name": "Veterans"
 },
 "availableChannel": {
 "@type": "ServiceChannel",
 "name": "Urgent Care Clinic",
 "availableLanguage": {
 "@type": "Language",
 "name": "Spanish"
 },
 "serviceLocation": {
 "@type": "Hospital",
 "name": "VA Boston -- West Roxbury",
 "address": {
 "@type": "PostalAddress",
 "streetAddress": "1400 VFW Parkway",
 "addressLocality": "West Roxbury",
 "addressRegion": "MA",
 "postalCode": "02132"
 }
 }
 }
}
</script>

Related additions in Schema.org version 1.0d

ContactPoint – e. g. now provides a mechanism for describing contact points for services which support users with hearing impairments.

Organization – a small but useful improvement, adding department and subOrganization properties that relate organizations to each other. This can be used when describing common situations,  when details such as opening hours or contact information vary by department.

Interoperability Solutions for European Public Administrations (ISA)

Overview

Administrative procedures have the reputation of being lengthy, time-consuming and costly. Electronic collaboration between Public administrations can make these procedures quicker, simpler and cheaper for all parties concerned, in particular when transactions need to be done cross-border and/or cross-sector.

Actions

The Interoperability Solutions for European Public Administrations (ISA) program of the European Commission facilitates such transactions through more than 40 Actions organized into five categories:

and four clusters:

Our interest in the Semantics of Service immediately engages us with two Actions falling within the Trusted Information Exchange cluster:

Common services – Action 1.1 – Improving semantic interoperability in European eGovernment systems.

Common frameworks – Action 1.3 – Accessing Member State information resources at European level.

Ferrario & Guarino on services science