Back ... ... ... ... ... ... ... ... ... ... ... On Stream ... ... ... ... ... ... ... ... ... ... ... Forward

OntologyStream Inc.

Market Delineation for Structural Holonomy

Draft: May 21, 2001

Also see “Technical Paper on: Process Model for In-memory Databases”. In this technical paper, we provide the definition of a class of innovations called structural holonomy.

The essential feature of structural holonomy is that it is a compact representation of the structure of information. The practical aspect of this feature is that types of information aggregation and data ware housing can be done in real time in small memory footprints.

Introduction

OntologyStream technologists have partitioned the market for structural holonomy into six market spaces. This partitioning could be delineated in a different fashion than as is shown in Figure 1. This partition serves to descriptively enumerate market needs so that a value matrix can be revealed.

The value matrix has markets as matrix rows and two types of matrix columns. The first columns are used to indicate what the market needs. After these columns, one specifies columns to indicate what the technology contributes to the market.

Figure 1: The market place

National Defense Technology does not appear in Figure 1. A separate market delineation and related value matrix is used to encode the needs and capabilities of structural holonomy in the context of National Defense Technology.

Section 1: Knowledge Management (KM) has become the branded term for sharing knowledge within communities. Autonomy Inc. is perhaps the branded lock-in with a web-crawler type “Dynamic Reasoning Engine” (DRE) that builds collections of profiles (smart agents) that push and pull information about people, places and things into Internet (Intranet) locations. Semio and Tacit Knowledge Systems have variations on the Autonomy lock-in. Lotus Notes Raven system has some additional innovations, particularly in the direction of distance learning.

OntologyStream scientists have developed a plan that involves replacing the relational database technologies that underlie several of the knowledge management technologies. For example, Ncorp’s mission statement:

"Ijen from NCorp offers a revolutionary new technology which enables users to intuitively and intelligently interact with structured information. …. NCorp's powerful new technology provides a mathematical understanding of database content which allows it to immediately and dynamically provide the most accurate, relevant information to end-users".

from www.ncorp.com.

The application architecture for Ncorp’s ljen technology has a relational database at it’s core, with a translation layer, or wrapper, that uses Autonomy technology (composed mostly of algorithms) to act as an intermediator between e-commerce applications and the data. This plan can be modified to develop a competing technology to Autonomy.

Solutions, such as provided by Ncorp, will transform structured information systems, such as e-commerce sites, in an extremely efficient and elegant manner. However, the relational database is the weak link in this chain. Structural holonomy is a clear alternative that can be made to sit within the Ncorp architecture.

In-memory database such as TimesTen’s core “in-memory database technology” is oriented at SQL optimization and relational databases with normal forms. This in-memory technology is not of the same category as the technology, as the structural holonomy technology. We have evidence that structural holonomy will eliminate the existing generation of relational databases and SQL completely, while being interoperable with legacy data systems. TimesTen makes a step towards the structural holonomy and away from the traditional database.

An essential feature of structural holonomy comes from the class of transformations that can be applied. These transformations include the formative projection where interaction with a human is assumed and leads to a validation of the projection. The projection is a query that returns a view of the structural holonomy . This view must be considered non-validated due to the differences between human perception and algorithmic processes.

A class of architectures for knowledge portals can be found at www.kmci.org. The architectural specification for knowledge claims and knowledge validation can be reviewed by visiting this web site.

Section 2: Data fusion is an entrenched problem with large research and development projects. However, the way in which the structural holonomy addresses this problem is revolutionary. The fusion becomes a matter of loading data into a single structure and performing arithmetic like operations.

An example can be shown whereby heterogeneous data is loaded in a structural holonomy structure. Once in this structure, data from two different sources can be made to appear as from one source; e.g., arithmetic operations can be performed. Scatter- gather and existing relational information (from the tables’ key structure) can produce very fast In-Memory processes. This distills information from data invariance. Data aggregation in this numeric space will cluster tokens in such a way that individual tokens can be moved from one of these structural holonomies to another.

A neuropsychological grounding to structural holonomy architecture used with the OntologyStream Tri-Level architecture is provided in Prueitt’s published work. The published work references Karl Pribram’s holographic theory of brain function, as well as work in ecological complexity (Robert Shaw, J. J. Gibson). This scientific literature reveals the structural holonomy as phase coherence in electro-magnetic domain, as mediated by the neural connections. In this domain, data fusion is has a solution that can be interpreted as reinforcement and collision of wave fronts. More is said on this subject in the published research of our colleagues at the Einstein Institute.

Market spaces for data fusion include B-2-B and B-2-C both in government and in commercial spaces. Data fusion also is involved in some of our preliminary notions about how structural holonomy can be employed in image compression and image understanding, as well as in real time simulation of complex environments such as computer games and battlefield simulation.

Section 3: Data Migration

Data migration is a very difficult proposition in today’s market spaces. Data base technology has evolved over the last few decades, and each stage of this evolution has involved the introduction of new barriers to interoperability between database vendors and even the different versions that one vendor has sold into the market space.

This is a problem that almost everyone has.

Several technology groups are developing structural holonomy technology for the data migration / data integration / data renewal problem.

The data migration problem has developed to have very specific characteristics. One of these being that most professional don’t believe that the problem can be overcome. However, revolutions often occur exactly when there are many who feel that the situation cannot change.

Section 4: Agile Interoperable (AI) IDEF

Section 4 was developed jointly with Intersect Technologies.

Agile Interoperable IDEF is a standardized methodology used in the government to engineer business processes such as e-procurement and government payroll.

One can envision a product that is developed in three phases:

1) An application that creates, modifies and maintains IDEF0 drawings and IDEF1 diagrams

2) An application that opens a hyperlink-style information portal for each Active Object in the IDEF0 drawing

3) An application that provides Agile, Interoperability to heterogeneous data sources related by, but not normally accessible from, the IDEF0 drawing.

IDEF is directed at modeling processes using a standard framework. This framework is well understood and is presented elsewhere.

Figure 2: The standard life cycle for IDEF

The standard life cycle for IDEF (see Figure 2) produces a IDEF0 drawing depicting processes in a nested structured fashion. IDEF1 is a relational diagram that corresponds to a Entity Relationship Diagram (ERD) used sometimes to instantiate information into a relational database in Codd third normal form. The Objective World is often the communities’ consensual agreement as to what is the set of processes underlying the work effort.

One limitation of the IDEF life cycle is that the IDEF0 is not always fully modeled by the ERD due to incomplete or inconsistent information.

A second limitation is that the world of natural processes is non-stationary and introduces novelty in such a way that exposes the ERD to fundamental design changes. A third limitation is that there is often not enough time to develop the optimal IDEF0 drawing. A fourth limitation to the IDEF life cycle is that the community may have an intervening agreement about what the work process is that is not functional or that is based more on political issues as opposed to other types of functional issues.

Let us consider an abstract problem. Suppose that the X system is governed by the IDEF life cycle. Suppose also that the current X IDEF model shows business rules down to a program level and that there are 8273 such programs with average length of 725 lines. Each program, in theory, implements code that conforms to some part of the set of business rules.

In truth, the logic of business processes will deviate from the code. In the typical case, the X code took 30 years to evolve. During this period, there where often times in which design shortcuts where required by the contingencies of policy directed changes to the business rules. Part of the impacting contingency is the difficulty of updating an increasing complex relationship between older code and new code. The divergence between code and business logic now represents an intractable problem given known tools.

Suppose now that a 600-member team of specialists has been tasked to maintain the X System by developing a model. For the sake of this discussion, we will refer to this model as the “X Code Model”. The body of the X Code Model is used to attempt to prove that inputs and outputs comply with a specific IDEF drawing, and that auxiliary information and data resources are well formed and correct.

The challenge is not only in proving that the current X Code Model is well formed and correct. Continual change is introduced from Policy and Guidance authorities. In addition to reducing divergence between the code and the business logic, attempts are made to conform this business logic to what is intended by policy and guidance.

The X Code Model is produced by

1) reverse engineering application and

2) through discussions involving software engineers and specialists within the 600 member X team.

Figure 3 represents a view of the migration and update of IDEF drawings. The historical process (a, b, c) implemented code based in a three step process that starts with policy and guidance. To the degree necessary to keep the current X system operational, this historical process remains in place.

Process d was completed as an intermediate step whose final objective is to produce an IDEF0 drawing having active objects pointing to process logic, the programs that compute this process logic, and to other informational recourses. This intermediate step was accomplished primarily using a reverse engineering workbench. Some documentation of the code has been made that assist in the one to one correspondence between elements of the business logic seen in the IDEF drawing. A separate software tool accomplishes the production of IDEF drawings.

The relationship between the IDEF drawings and the collection of COBOL programs is managed by hand.

Figure 3: Current model of Process

Figure 3 represents a model of the current migration and update of IDEF drawings. Aside from unavoidable limitation of the standard IDEF practice, the model suffers from the complexity of the legacy system and the uncertainty of continuing alterations in business logic.

Figure 4: Desired next state model

Figure 4 depicts an idealized process whereby snapshots of the entire 6 million lines of COBOL code is encoded into a structural holonomy each day during a period of transition.

The archive deploys structural holonomy technology to compress the original data source (lines of COBOL code) into a data-warehouse.

To move a legacy system to this state we need the following milestones.

1) A transition process that has resulted in a provably complaint Code Generating IDEF Drawing Workbench.

2) A Code Generating IDEF Drawing Workbench that has demonstrated the prototyped ability to generate and maintain business logic and implementing code within a one-to-one correspondence.

3) A Code Generating IDEF Drawing Workbench that has demonstrated the ability to generate and maintain all business logic and implementing code in a one-to-one correspondence. (Equivalent to: prototype properly scaled and placed in an operational environment.)

4) During the transition a historical archive was created to give confidence that migration processes are reversible under the condition that the replacement system has a failure.

Given these milestones, one is ready to support the migration of centralized responsibility to the organization Q.

Figure 5: Final state of the system

The final state of the transition process leads to Q’s control of implementation at distributed and situationally distinct systems. Q’s responsibility is to implement policy and guidance and to preserve daily records of the entire state of many code generated IDEF0 drawing.

Section 5: B-2-B and B-2-C is the most visible of all application areas for new computer and Internet technologies. OntologyStream is developing an general architecture for B-2-B that involves Topic Maps as a control interface and structural holonomy technology as a virtual information machine. This architecture will be published in a presentation at Extreme Mark-up Conference in August 2001.

We are claiming that the relational database is being replaced by new technology having structural holonomy at its core. It has been mentioned that the entire market cannot partitioned into six market spaces. This partitioning overlaps. Perhaps the best example of this is the fact that B-2-B and B-2-C is an application of Content Management. Content Management is a more general technical problem. OntologyStream is pursuing a strategy that may lead to an product line for KM that integrates Topic Maps, the OntologyStream’s Tri-Level Architecture, and the structural holonomy database.

Section 6: Content Management has three aspects (1) content evaluation (2) Peer-2-Peer content streaming and (3) content publishing. The structural holonomy technology provides solutions to the content evaluation space. Topic Maps provide the solution set to the content publishing space.

Content evaluation has a great deal in common with B-2-B and B-2-C and KM since content evaluation has a context determined by an individual or organizational viewpoint.