Knowledge Database

is a particular kind of database which contains data addressed by the information necessary to describe the context of the data rather by tables, columns and keys. It contains two kinds of information:

It contains data whose context is defined by a sequence of Information Path segments each of which has an Endeme and Endeme Set. The data itself is contained (or referenced) in things like text, number, GUID or date fields.

It contains information whose context is defined by a sequence of Information Path segments each of which has an Endeme and Endeme Set. The information itself is also contained in an En Deme and an Endeme Set.

A knowledge database is architected with 7 or more tables, the main ones containing Endemes and Endeme Sets. These are the tables:

Endeme Item - the Endeme Item table contains an En Deme, a FK for its Endeme Set, field name, description, data particles holding fields, links to other table rows/cols,

Endeme Set - the Endeme Set table contains its name, version, owner and editing status.

Endeme Characteristic - Each Endeme Set is made up of up to 24 Endeme Characteristics (nominally 22), each one has a letter, label, and description.

Endeme Characteristic Value - Sometimes particular values of Endeme Charactersitics inside an Endeme have special meanings, this table holds them.

Endem Key - the endemeKey table holds a few endemes for use in matching against all other Endemes in order to build an index of Unorderable Information, since endemes are unorderable.

Endeme Index - each endeme in the Endeme Item table is matched against all of the Endeme Keys. This allows for indexing of Unorderable Information.

Endeme Value - contains raw data for conversion into endemes (optional)

Endeme List Item - a bridge table to allow Endeme Items to be added to lists, each of which is defined by an Endeme Item

It is called a knowledge database because in theory it contains what the database 'knows' rather than just what the database 'stores'.

Likely Benefits

It is a first step in avoiding Tight Field Coupling.

Likely Weaknesses

It does not meet the Ac Id test. Whether it's Ac Id or not is orthogonal to the above, isn't it? It could be equivalently implemented in an Ac Id-compliant DBMS or in innumerable non-Ac Id ways. My intuition is that even when a Knowledge Database is implemented in an Ac Id-compliant DBMS it still doesn't need to be ACID, and that part of Information Programming is to make applications that do not need ACID compliant information storage. So it's more based on choice of approach than actual technology. In other words you might be doing something which might be considered Information Programming when you code around the inability of your information source to comply with ACID. I could have this wrong though, that's why I call this a 'likely' weakness.

--Jon Grover

How does your system differ from existing mechanisms for representing knowledge, such as that used by Open Cyc?

Open Cyc is an OWL, Computer Ontology, relationship based artificial intelligence system. It focuses on relationships between entities, and defining entities in terms of their relationships. Endemes are a system for defining information entities in terms of data and information. It focuses on information and creating information descriptions of data as it is used and implemented in conventional business programming. As a visual metaphor, think of opencyc as focusing on the edges of a Directed Graph, and Endemes as focusing on the vertices.

I see. By "creating information descriptions of data", do you mean what is often called meta-data?

Meta Data comes a little closer to what I'm working with than cyc. You might say that endemes are a particular form of metadata that is much more flexible than standard meta-data because it is based on Information Programming techniques and an approach based on Real Information, rather than other kinds of meta-data which is founded on Real Data and Data Oriented Programming techniques. I guess you might call Endemes Information Oriented Metadata. I'll have to think about that. Since there must be other ways of representing Real Information than Endemes, then perhaps for each kind of Information Data Structure, there would also be a related meta data implementation. You coud call Endeme Contexts a form of Meta Information rather than Meta Data, although there seems to be a similarity.

Here is a general description of our field right now:

Here is what I propose:

--Jon Grover

I don't see how "endemes and other forms of Information Programming" form a bridge between knowledge representation (plus AI) and CRUD screens. Could you explain?

I'm mostly just theorizing based on the current failure of knowledge representation to go mainstream that there is a missing connection between the two. Using Endemes, I can address data by its context. That's what this page is about. Second, if things are defined only by their relationships, then it is like having a cloud of definitions floating in space without any reality to define its basic words. If you could define say the 1000 basic words in English by things that were very concrete and based on experience rather than definitions to other words, then in theory the rest of the words defined based on those basic words also connect to reality. I'm guessing that something similar needs to be done to connect the Semantic Web's 'basic words' to some form of data reality. I'm also guessing that endemes can do that job. I know the connection needs to be made and I know that endemes can make the lower half of that connection. I don't have enough experience with the upper half of that connection to know how to do it, so the best I can do is make the assertion that either Endemes or some other form of Information Programming can. It seems to me that perhaps they can because users think in ways more similar to Endeme Contexts and Real Information than Conventional Data, and Knowledge Representation has been designed to try to map the way users/people define and therefore think about things. I'm guessing that since the behavior of Endemes is very similar to the design goal of Comptuer Ontologies that a connection between the two should be relatively easy to build. The actual technological connection remains to be worked out. On the other hand, perhaps the real situation is like this:

What is AC?

Are you sure something is missing? I have created applications with conventional front-ends (a form and submit button, in one case) that use a database of semantic links -- i.e., a knowledge base -- at the back-end. It was not my impression that something was missing between the front-end and the back-end, other than the straightforward code I wrote to link them.

Perhaps my description of conventional business programming is a little misleading. I am actually more focused on conventional data storage and middle tier development than CRUD. AC is Artificial Creativity, also called Computational Creativity. I am an expert at artificial creativity and also a natural Information Programmer. If there were not something missing in the programming field then there would be myriads of jobs for people like me doing artificial creativity or information programming. Since there are few if any jobs in this field, that means that the connection between business programming and these fields is missing. Information programming especially could make businesses billions or trillions of dollars. I see copious low hanging fruit, potential for thousands of companies to take advantage of it, and for millions of companies to cut costs and/or improve productivity. These things are not happening, so something is missing. I am developing what is missing, so it is easy for me to see that there is something missing. Since I can come up with hundreds of obvious unbuilt applications and unstarted businesses. It may be a case of an extreme bottleneck rather than a completely missing connection.

Maybe this diagram describes our field best:

I am interested to hear more about your project. I am always looking for a new Information Data Structure. Also, you might ask yourself why there are so few people doing your sort of work, and why so few businesses willing to benefit from it.

My project was to develop a search engine that uses semantic relationships to generate search results in addition to the usual keyword hits. So, for example, a search for "fish" might retrieve not only keyword hits for "fish", but also "ocean dwellers" and "seafood" and "look for" and so on. There are few people doing such work because it's difficult to reliably generate useful results. There are no quick wins here. Because it's difficult to reliably generate useful results, there are few businesses interested in using it. Human reasoning applies numerous filters and cognitive processes that we're only beginning to appreciate, and we're barely starting to get a handle on computerising them. But, the area growing in both in terms of both academic interest and business attention.

April Thirteen

Category Information Orientation

See original on c2.com