How to Educate Your Digital Twin with Blockly

Following the successful use of Google Blockly to build OWL class expressions, the next Otter Project effort is to move forward with building all description logic with Blockly. The outcome will be a full implementation of the edit functionality needed to educate your digital twin to perform in the digital ecosystem.

Knowledge vs Learning

The first step is to formalize the definition of knowledge building for AI. For the Otter Project, this definition has been extrapolated from the Knowledge Building theory attributed to Carl Bereiter and Marlene Scardamalia, two professors from the University of Toronto. Although they address knowledge building from the perspective of how human beings build their knowledge, their model is also applicable to AI.

According to their theory, knowledge building in education is either done in belief mode or design mode. Belief mode is what we are told to believe, based upon publicly shared knowledge. Design mode incorporates actual experience that fosters improvement. Consider that in AI, the same distinction exists. Building OWL DL documents is based upon shared beliefs, while training neural networks is based upon design by incorporating actual experience.

OWL DL documents represent the capturing of knowledge by humans to share with computers. Neural networks are essentially trained by repetition. The methods applied for training continue to improve so a computer can learn from big data observations.

Cognitive Artifacts

Bereiter and Scardamalia describe knowledge building as a way to create new cognitive artifacts. They recognize the importance of the community in building public knowledge artifacts, and of individuals applying innovation to build new artifacts. In the OTTER project, this concept is formalized by layered groups of knowledge topics for OWL DL documents as listed below:

  • Innovation – Unique and private topics building upon Business, Academia, and Universal topics.
  • Business – Topics defined by the North American Industry Classification System (NAICS) and building upon Academia and Universal topics.
  • Academia – Topics defined by the Classification of Instructional Programs (CIP) and building upon Universal topics.
  • Universal – Common topics for classification, processing, and federation as provided by the Otter Server.

Each OWL DL is classified in one and only one of a given topic.

Knowledge Building Graph

The following is an initial implementation showing a knowledge building graph. The Pizza Stores DL topic from the Otter Server prototype is selected as the focus for the topic filter. The visible layer options of Innovation, Business, and Academia are set on where Universal is set off.

Setting Business and Academia off and setting Universal on shows the Universal topics applied in the Pizza Stores OWL DL document.

The Knowledge Building graph is dynamically created based upon the selection criteria and the dependency of a OWL DL document on another. Dependency is based upon the imports defined in each of the OWL DL documents.

Knowledge Building Artifacts

In the OTTER project, these artifacts exist within Lights, Camera, Action, and Perform. Each of these will implement Blockly edits to visualize, create, and update content artifacts. The list of items in each are an indication of what is to come.

Data Properties
Object Properties
Query Database
Request a Response

This is the beginning implementation of building AI knowledge by the Otter Project using Google Blockly. It is the next step towards achieving the education of your digital twin.

Blockly Experiment

Logic brings lights, objects bring the camera, and services bring the action. Together the performance is staged by the Otter Server. Blockly may be an ideal editor for Otter Server content.

The Blockly visual development process is currently being evaluated as a possible method for providing edit capability to the components of the Otter Project. A sample test is being run using a prototype development of Blockly blocks for constructing logic, services, and objects. Readers can view the test and try it for themselves at:

Motivation to Use Blockly

Blockly is an editor for visually constructing logical statements by connecting 2D blocks. Whereas most ontology editors are either forms-based or text-based, Blockly is picture-based. All blocks have a common shape, and each supplies content and connectivity. However, each individual block has its own unique content, connection restrictions, and differentiating color.

Blockly provides localization so the same blocks can be presented in multiple languages. The approach used in Blockly for localization may also be extended to ontologies.

Starting with Objects

The first test is with objects, as defined by the standard for Service Data Objects. In the Otter Project, objects are defined by OWL class expressions. The test shows how Blockly blocks can be combined to build a class expression, and that the Blockly visual can then be transformed into a text-based class expression. The Blockly blocks may also be created directly from a text-based class expression.

Objects was chosen as the first area to experiment with Blockly due to the importance of class expressions to the Otter Server. Class expressions are the language used to access and update the Abox database. Class expressions are also used to define all the messages in service dialogues.

Next Steps

  1. Finalize the blocks for objects.
  2. Complete localization for the blocks and the OWL DL ontologies.
  3. Develop the blocks for services as defined by the standard Service Component Architecture and the Business Process Execution Language.
  4. Develop blocks for logic as defined by description logic and specified by the OWL language.


Sharing and reuse of multilingual description logic, processes, and data with consistency when combined.

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.