Section 1: Natural Relationship

A natural relationship exists between types and values and classes and objects. This relationship defines duality within the class of cross-scale operators. The natural relationship is exploited when one treats either the value or the type as a class that produces instances of objects. So a type is considered as a class that produces instances of values. Or a value can be considered a class that produces instances of a type. This duality leads to great agility and flexibility in “modeling” cases where nature itself flips the object-class relationships.

The object-class relationship is flipped, in nature, when a new phenomenon (produced by a class as an object) becomes a class that propagates a new class, producing instances as objects. In natural systems the emergence of form from structure is governed by function. This emergence is discussed in Maturana and Varela [2] through the use of the term “autopoiesis”. Maturana and Varela also use the expression “structural coupling” to specific some specific set of governing rules involved in the expression of autopoiesis.

Information Production Systems must have a similar property.

Information Production Systems creates true information about the invariance in measurement processes and about the formative processes governed by event Chemistry (eC). Thus the measurement process is regarded as the most critical of the nine aspects of the Actionable Intelligence Process Model (AIPM). The consequent of this measurement has to be the development of structural coupling between elements of linguistic variation, encoded into patterns called local linguistic neighborhoods (llns).

Seen in this way, the CCM construction allows the development of a new type of class-object based information production. Information Production Systems are radically different from Information Technology and data mining. Data mining finds what is already there.

Information Production Systems involves a rich interaction between humans in communities as new information is produced and then placed into context and reified. The C-BIP process allows the real time creation of new objects and classes without the imposition of data schema.

Section 2: Method of Disambiguation

A single hash table can be used to store Input Array branches "up side down". In the experimental system we using the following notation:

( value | type, branch )

where “value” is the value of the ending node in a branch from the Input Array. This ending node is the center of a 5-gram.

The value is used to generate a hash (value: key) pair and the key is sent to a class construction that produces an object that stores the information to the right of the “|” delimiter.

The dump of the Input Array, I, is achieved from the same data as the dump of the Output Array, O.

How this is done is addressed in a research note (under development as of September 17, 2003)

Section 3: Differential Inversions

The differential inversion (see CCM-notational paper), is only partially developed and now only involves some experimental reconciliation processes at the center of the 5-grams. We say, in CCM notation, that a convolution occurs locally at the center of the n-gram.

Reconciliation processes are differentiating the context of sub-parts of the bag of branches ... as in the example

[ bush, bush ] à { bush(1), bush(2) }

A reconciliation operator provides a disambiguation of "bush" into two contexts.

This disambiguation can occur in the Input Array by physically making a substitution of “value” by “value(i)” where the index “i’ is over some set of reconciliation categories [3].

Similarly one can effect a disambiguation of the subject having two names using a rule base that is constructed as if a thesaurus ring.

{ bush(1) , president } à { "bush the president" }

Section 4: Class-object relationship to OWL

We are addressing two long term issues

1) How to bring in OWL as a persistent storage mechanism - particularity for information derived from statistical analysis on the similarity of branches and the statically derived definition of metaconcepts.

2) How to apply the concept of differential inversion so that local convolutions are occurring at nodes other than the root node.

The class-object relationship directly impacts on the development of a seamless interoperability between RDF and OIL constructions.

The implicit understanding is that (type:value), and what has been classically the ATS discrete analysis, is related to OWL through the class-object constructions of OWL.

In general terms the (type:value) pair is "placed into a hash table" (or btrees) by using the value to form the (value, key) pair. Some additional information is required to associate the type and the branches of the Input Array to these objects. So we have introduced this notation:

( value | type, branch ) where value à key

The expression “value à key” is read “the value is used to generate a hash key”.

The key is then associated with an class that has internal data variables:

{ key, type, branch }

The class produces an object with specific key data, and a specific type. The branch is encoded into the branch variable. These objects can also have a larger structure such as a simple tree. However, as we see, the simple trees of the Output Array are immediately derived from the Input Array and so no class with simple tree variables are needed at this point.

The BerkeleyDB does a nice job of increasing the size of the hash, or btrees, and so we have an internal structure efficiently in place.

Section 5: On metaconcept persistent storage

(Section to be extended)

A number of questions are being addressed as of this date: Sep. 17, 03.

How are metaconcepts developed? Once they are produced how to store them efficiently?

What brings everything together is the relationship between a class and object, and a value and type... and the fact that the class definition can be such that internal data can exist in each object produced from that class.

In a research note, under development as of Sep. 17, 03, we document and describe exactly how the experimental system uses the hash table in BerkeleyDB. This research note is designed to be communicative to anyone who has no previous experience with NdCore

The concepts are very clearly expressed, along with the BerkeleyDB functions used. It should be clear that we ARE NOT using type at all in this version of the experimental system, since we are reserving this for the local convolutions in the differential inversion.

Amnon will soon be delivering a noun verb tagging of the fables to boot us into this work, under development as of Sep. 17, 03.

With the deployed NdCore 2.0, one is able to dump the metaconcepts to a file. We will show what this data looks like and what is related to the data construction that are dumped by setting flags before running NdCore 2.0

Of concern is how the metaconcepts are being stored persistently.

We have a new type of discrete analysis referential base that is being developed for NdCore.

[1] The CCM notational system http://www.ontologystream.com/CCM/CCMnotation.htm is to be consulted for references to constructions and processes indicated by standard CCM notation.

[3] We are working on this method of disambiguation as part of the Phase 3 deliverable.