The OtterServer is a platform for Digital Twins. It is where digital twins direct the performance of services in real life events. This means that digital twins do not repeat the same performance over and over again. They must be prepared to handle whatever reality comes their way.
Digital twins that direct the performance in a theater are symbolized by the following logo where P is for Possibility, A is for Actuality, N is for necessity, and AI is for Artificial Intelligence:
Otter Server Digital Twin
This logo indicates the components found in an OtterServer digital twin. This is the case for all twins of real-life entities such as an organization, person, place, and thing twins.
Organization and person twins may each have their own personal Otter Server. This singularity enhances security for an organization and for a person. Other digital twins such as the ones for places and things may for convenience share one or more Otter Servers.
When digital twins direct a performance in an OtterServer, they are directing under the digital twin’s possibility, actuality, and necessity categories. All are derived from description logic as implemented in the OWL2 ontology language.
Possibility: A digital twin’s possibility exposes the logical structure of domain information. Possibility is the Tbox (terminological component) of an ontology and its imports.
Actuality: The actuality is the database providing update and query functionality of named objects. It is the Abox (assertion components) of an ontology and its imports. The Abox DB of the OtterServer supports all of the OWL built-in data types and does not allow duplicate object names within a domain.
Necessity: The necessity describes the components, connections, and the software for processing information. All are defined using a Service Component Architecture ontology. Currently, component service software may be written in Java or Business Process Execution Language (BPEL).
AI: Directed by a digital twin, real-time data from the ecosystem or projection data from simulations are processed. As an outcome, analysis and explanation of all actions and captured data is available from each performance.
Digital Twins Communicate
Plug to Socket Communications
Cooperation of digital twins in different OtterServers occurs over asynchronous communications by connecting a plug of one twin to the socket of another twin. The link is established by a secured access request of a plug to a socket. The communications content is defined by class expressions, each expression being a subsumption of the possibility shared between the two digital twins.
The shared possibility provides the explanation of the communications and each communication is in a standard form. The communication’s content is a Service Data Object (SDO) serialized in JSON. An SDO is a logical graph of named objects.
Digital twins are ready to direct performances when their OtterServer is up and pauses when the not up. The OtterServer operates over the Internet using the Jetty HTTP server. As soon as a server is open, the digital twin may begin receiving communications and sending communications.
Internet browsers may access the sockets of a digital twin and provide services. For access, the browser uses a Javascript library provided by the OtterServer. The library contains scripts that support local access to a theater as a plug.
