A KnowledgeDatabase 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 InformationPath segments each of which has an Endeme and EndemeSet. 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 InformationPath segments each of which has an Endeme and EndemeSet. The information itself is also contained in an EnDeme and an EndemeSet. A knowledge database is architected with 7 or more tables, the main ones containing Endemes and EndemeSets. These are the tables: * EndemeItem - the EndemeItem table contains an EnDeme, a FK for its EndemeSet, field name, description, data particles holding fields, links to other table rows/cols, internal indexes, and a match weighting field, it also contains information about its parent EndemeSegment. It is the core table of the architecture. * EndemeSet - the EndemeSet table contains its name, version, owner and editing status. * EndemeCharacteristic - Each EndemeSet is made up of up to 24 EndemeCharacteristics (nominally 22), each one has a letter, label, and description. * EndemeCharacteristicValue - Sometimes particular values of EndemeCharactersitics inside an Endeme have special meanings, this table holds them. * EndemKey - the endemeKey table holds a few endemes for use in matching against all other Endemes in order to build an index of UnorderableInformation, since endemes are unorderable. * EndemeIndex - each endeme in the EndemeItem table is matched against all of the EndemeKeys. This allows for indexing of UnorderableInformation. * EndemeValue - contains raw data for conversion into endemes (optional) * EndemeListItem - a bridge table to allow EndemeItems to be added to lists, each of which is defined by an EndemeItem 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 TightFieldCoupling. '''Likely Weaknesses''' * It does not meet the AcId test. ''Whether it's AcId or not is orthogonal to the above, isn't it? It could be equivalently implemented in an AcId-compliant DBMS or in innumerable non-AcId ways.'' My intuition is that even when a KnowledgeDatabase is implemented in an AcId-compliant DBMS it still doesn't need to be ACID, and that part of InformationProgramming 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 InformationProgramming 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. --JonGrover ''How does your system differ from existing mechanisms for representing knowledge, such as that used by OpenCyc?'' OpenCyc 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 DirectedGraph, and Endemes as focusing on the vertices. ''I see. By "creating information descriptions of data", do you mean what is often called meta-data?'' MetaData 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 InformationProgramming techniques and an approach based on RealInformation, rather than other kinds of meta-data which is founded on RealData and DataOrientedProgramming techniques. I guess you might call Endemes InformationOrientedMetadata. I'll have to think about that. Since there must be other ways of representing RealInformation than Endemes, then perhaps for each kind of InformationDataStructure, there would also be a related meta data implementation. You coud call EndemeContexts a form of MetaInformation rather than MetaData, although there seems to be a similarity. Here is a general description of our field right now: +----------------------------------------------------+ | AI, AC | +----------------------------------------------------+ | OWL, Semantic web, opencyc, Ontologies | +----------------------------------------------------+ missing connection +----------------------------------------------------+ | field and screen conventional business programming | +----------------------------------------------------+ Here is what I propose: +----------------------------------------------------+ | AI, AC | +----------------------------------------------------+ | OWL, Semantic web, opencyc, Ontologies | +----------------------------------------------------+ | Endemes and other forms of InformationProgramming | +----------------------------------------------------+ | field and screen conventional business programming | +----------------------------------------------------+ --JonGrover ''I don't see how "endemes and other forms of InformationProgramming" 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 SemanticWeb'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 InformationProgramming can. It seems to me that perhaps they can because users think in ways more similar to EndemeContexts and RealInformation than ConventionalData, and KnowledgeRepresentation 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 ComptuerOntologies 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: +----------------------------------------------------+ | AI, AC | +----------------------------------------------------+ | OWL, Semantic web, opencyc, Ontologies | +----------------------------------------------------+ still a missing connection +----------------------------------------------------+ | Endemes and other forms of InformationProgramming | +----------------------------------------------------+ | field and screen conventional business programming | +----------------------------------------------------+ ''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 ArtificialCreativity, also called ComputationalCreativity. I am an expert at artificial creativity and also a natural InformationProgrammer. 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: +------------------------------------------------------+ | Artificial Intelligence, Artificial Creativity | +------------------------------------------------------+ | OWL, Semantic web, opencyc, Ontologies | +----------------------------------------------------+-+ mostly missing connection | | <- extreme bottleneck +----------------------------------------------------+-+ | conventional business programming and databases etc. | +------------------------------------------------------+ I am interested to hear more about your project. I am always looking for a new InformationDataStructure. 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.'' ---- AprilThirteen ---- CategoryInformationOrientation