The Future of the Digital Ecosystem – Part 3: How?

Each digital twin has a reality theater with a stage on which to perform in collaboration with other digital twins (persons, organizations, things, …). A theater is an instance of the OtterServer that applies OWL DL for consistency in shared knowledge and a common language dialogue for interoperability across the internet.

The semantic web provides OWL DL as a common language for knowledge definition. Knowledge definitions in OWL DL are verified by reasoners for logical consistency. Reasoners are computer code designed to efficiently uncover any inconsistency. For example, it would be inconsistent to classify a shape as both square and a circle since a square and a circle are mutually exclusive.

The diagram above shows the four theater operations of the OtterServer: lights, camera, action and perform. The arrows in read indicate how the OWL class expression is applied by the OtterServer where it defines a graph.  

The class expression is the formal language for querying and updating the OtterServer graph database. It is also the formal language for defining Service Component Architecture (SCA) dialogue and the parts played by the actors (digital twins).

Lights – A logical composition of a subset of knowledge. The composition is selected from the Digital Tree of Knowledge by a person. In DL (Description Logic) lights are the terminological knowledge; abbreviated in ontology as the TBox.

Camera – Captures points in time of the named objects and stores them in a graph database. The data stored is referred to in DL as assertions with the name ABox.  The storage model is derived from the TBox and queries and updates are defined by class expressions. In IT terms, the logical model is defined by the Abox and the physical structure of the database is determined by the actual content in the ABox.

Action – The structured communications between actors; the scripts they follow. Scripts are the procedural statements that define the actions of components that may contain one or more scripts. These actions include providing services and requesting services. Component scripts include functions, conditionals, parallelism, and query / update of information maintained in the ABox.

Perform – The real-time performance in the ecosystem. Service requests and database requests are received and processed in a multi-thread environment.

The “How” is 100% OWL DL. It does not use a separate language for database query and update, nor does it use a separate language to define Service Component Architecture. This makes it easier for individuals and organizations to contribute to the Digital Tree of Knowledge. They need only to learn one language for data definition, database, and interoperability.  One language where its content can be verified for consistency with existing library content.

Part 3 of this article introduces the concepts of the functionality implemented in the OtterServer prototype. This introduction is very high level and does not attempt to cover the foundation of technical standards on which it is based and how these standards are applied. This information can be found in other articles found at

The future offers great opportunity for every person to use their talents, time, and resources to serve others. It will come in the form of a person digital twin for all those who would like to have a personal advisor to help them find their true north.

The digital ecosystem will change. This article covered the “What”, “Why”, and “How”. So, the next question is “When?”. The answer is simple; like all other recent technology changes, this one will take place very rapidly.

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.