Category: Executable Descriptive Logic

Mapping OWL to an OWL Ontology

The OWL language is well-structured and meticulously designed for description logic. There are many sources of documentation describing its specifications with examples. There are also thousands of projects that utilize the OWL language. It is well documented for humans.

In the Otter Project, all ontologies are designed to be understood by both humans and computers. Humans can understand most anything, but computers are limited to their functionality. Since the Otter Server has a finite set of functionality, the OWLMap exists to reflect the existing Otter Server functionality.

OTTER utilizes this ontology to provide access to all OWL-defined ontologies. This ontology, developed as part of the Otter Project, has been through multiple revisions. The revisions have been required as the OTTER project has progressed.

All graph structures in the Otter Server are defined as SDO Datagraphs, and Datagraphs are created from OWL class expressions. The OWLMap ontology provides the Otter Server with the ability to use a class expression to access the content of all the loaded ontologies. The class expression is the base for queries, updates, and server messages.

The OWLMap ontology is not intended to be a complete representation of the OWL language. The structure of OWLMap follows the principle of “form follows function”. With this principle In mind, the purpose of OWLMap is to provide a form which can give full access to the functionality of the Otter Server.

There are twenty-six classes described in the OWLMap as of 3/11/18. The following diagram generated using d3.js shows the class content and the class relations:

When accessing this diagram within the Otter Server and focus is given to a single class, only its relations are shown in the diagram. Giving focus to a relation will show the relation as either a subset or as having one or more object properties (domain and range) or class relationships.

Selecting a class will bring up a diagram that shows the properties and relations of the class. The following is an example of the OWL_Entity class:

The object properties include: inDocument (The containing document), has Annotation (A list of annotations),and  isEntityOf (The class of the entity as a subclass of OWL_Document). The data properties include: hasName (The string name of the entity).

The OWL_Entity is the super class of: OWL_Document, OWL_Class, OWL_Datatype, OWL_Annotaion, OWL_Individual, and OWL_Property. Each of these classes inherits the object properties and data properties of OWL_Entity.

Another more recently added class is ExpType, which defines the content of a class expression as shown in the following diagram:

This class is the super class of the five assertion classes of a class expression. This includes: IndividualRestriction (An specific individual name), OWL_Class (An OWL class name), BooleanConstructor (Defines “and”, “or”, and “not”), DataRestriction (A data property restriction), and ObjectRestriction (An object property restriction).

The ExpType class was added to support the construction of a visual function to build a class expression. Class expressions can be very complex. The visual function builds a class expression in the tradition of “What you see is what you get.”

These diagrams are visual results of the use of the OWLMap ontology. The OWLMap is also being used to construct the class expression builder for both service messages and repository queries. It will also be used to construct the ontology builder.

 

REA Business Model

The OtterServer includes a simulation of three pizza stores, each making pizzas from supplies ordered from three different sources. The REA (Resource Event Agent) business model, proposed in 1982 by William E. McCarthy, is applied in the form of two xontos (Executable Ontologies Defined in a Descriptive Logic Language): REA Exchange and REA Convert. These xontos provide the definitions and services required to run the simulation.

Model-Driven Design Using Business Patterns, an excellent book by Pavel Hruby, was the source for constructing the models used in the simulation. This book provides patterns that can be applied to many business processes.

The “Exchange” xonto provides the means to describe the contracts for selling pizzas and acquiring the ingredients to make the pizzas. This xonto has the following structure:

The simulation has two forms of the exchange model. One form is to define the exchange between a customer and a store:

Three contracts are defined, one for each store. When a pizza is purchased by a customer, the store pizza resource is decremented and the price of the pizza is paid for by the customer. The income from each purchase goes into the appropriate revenue accounts. This is triggered by the service “Order Pizza from Menu”.

The other application of the exchange model happens between the stores and their suppliers. Since there are three stores and three suppliers, the simulation includes a total of nine store and supplier contracts as shown below:

The stores restock the ingredients they need by ordering from their suppliers. Every order includes the number of units of each ingredient required by the store. Each store’s pizza ingredients are incremented and the appropriate expense account is decremented. This event is triggered by the service “Restock Ingredients”.

The REA “Convert” xonto is used to make pizzas. The general structure of this xonto is:

When pizzas are ordered by customers, this model is applied to make each pizza:

The service “Order Pizza” performs the convert for a specific pizza according to that pizza’s recipe. For each pizza produced, the pizza resource is increased and the ingredients used to make the pizza are decreased.

The simulation operates over several days. At the beginning of each day, each store’s ingredients are checked by the “Restock Ingredients” service to see if they fall below the economic order quantity. If so, an order is prepared for the suppliers to restock to a level that does not exceed the store’s storage capacity. The simulation then randomly creates specific pizza orders for the stores.

The viewer for the simulation slows down the process using time delays, allowing the details of the revenue and expenses incurred each day to be seen.

The REA models work perfectly as xontos, and sincere thanks are given to Pavel Hruby for describing these patterns. See reatechnology.com.

Form Follows Function

Perhaps the most famous quote from Frank Lloyd Wright, the master architect, was:

“Form Follows Function.”

The value of that philosophy is obvious when it comes to building homes and business structures, and it should be just as obvious when building information systems. In the OTTER Project, the intended function is to establish:

Ontology-driven Enterprise Architecture.

The OtterServer is the form that follows. The overall function of ontology-driven Enterprise Architecture can be subdivided into smaller, more specific functions. Those functions and their form in the OtterServer Structure are outlined in the following:

Function Form Follows
Blackbox components Ontologies
o   Ontology definition OWL
o   Consistency General reasoners
Layered knowledge OWL imports
o   Layer definitions Standard education & business categories
o   Layer dependency Standard crosswalks of education & business categories
o   Infrastructure layer Ontologies for standard architecture
Business processing
 Service Component Architecture (SCA)
o   Standard connections SCA ontology sockets & plugs
o   Service access Class expression messages
o   Access security Socket access through IAM
o   Business process execution BPEL ontology
Information persistence & transformation Service Data Objects (SDO)
o   Information access OWL class expressions
o   Reference data persistence Ontology individuals
o   Master data persistence External storage
o   Transformation SDO update
Visualization Graphical presentation
o   Ontologies D3.js diagrams
o   SCA Graphviz graphs
Development / Change management Protégé editor

Some might read this list and think it’s incomplete, since it doesn’t include meeting a business need. That function would entail gathering requirements from stakeholders and the building or buying of a system appropriate to their needs. And viewed from the traditional approach to software engineering, this list is incomplete. However, this list is not about what is to be constructed, but rather, how it is to be constructed.

The ontology-driven approach is very different from the traditional when using a framework like the OtterServer. New construction doesn’t begin with a clean slate. It begins by understanding and utilizing the knowledge that has been captured by other professionals. When a common framework is used, all of the ontologies will work together.

The OtterServer supports the capture and reuse of knowledge in academic disciplines, business, and infrastructure. With that stored knowledge, anything new can be built upon proven ontologies. And having a common framework will result in a major leap in our ability to use software to handle greater and more complex systems. Once we have quality computing systems that rely upon our accumulated and proven knowledge, they will far exceed the capabilities of the localized and limited applications of today.