So, here's a brief idea of how a hypergraph based system could be implemented in a SQL environment. There are two core tables: Nodes and Links.
The link description format is simple : index, something, link, something
The Node table contains the following fields:
id - an index number used for reference and graph building
label - english language label (where applicable)
description - english language description (where applicable)
type - atom, link, or dual
The Node table is simply an indexed collection. Its only purpose is to provide references for the Links table.
The Links table contains the following fields:
id - an index of the link
node1 - the primary node
link - the link node
node2 - the secondary node
So let's say we have a very basic set of facts we want to enter into the database:
dog isA mammal
mammal isA animal
animal isA livingThing
livingThing isA thing
isA isA relationship
isA isA thing
relationship isA thing
We have a set of things and a single type of relationship, isA.
A simplified example of what this would look like, laid out in text:
Node:dog:1
Node:mammal:2
Node:animal:3
Node:livingThing:4
Node:thing:5
Node:relationship:6
Node:isA:7
Link:1,7,2
Link:2,7,3
Link:3,7,4
Link:4,7,5
Link:7,7,5
Link:7,7,6
Each node is identified, the relationship is identified, and it's defined recursively. The SQL to traverse the graph would be relatively trivial - simply iterate over each link, identify the nodes, find other links related to the nodes, and define meaningful relationships across nodes that occur. For example, to identify that a dog is a thing, you'd create the graph that defines the dog, then search for an unbroken chain of isA relationships between dog and thing. If it's found, you can return "yes, a dog is a thing" and if nothing comes up, you say "well, as far as I can tell, a dog isn't a thing." Or just "no", depending on how seriously the AI takes itself.
That's high level logic, though, and trivial to do. OpenCyc, ConceptNet, SUMO, etc, are light years ahead of anything we could whip up, insofar as knowledge representation is concerned. They've not only got predicate calculus hitched to their wagon, they've got decades of parses, material, research, and interns adding material by hand. This is nothing new - I'm simply building a graph representing knowledge and doing it in SQL.
So, we take this database, and we add the bookkeeping bits and pieces, the comments, the timestamps, maybe a raw log and references to when, why, and how nodes and links were added. We give it all the information necessary to recreate the circumstances leading to the addition of new material in the database. We give it probablistic references in order to take advantage of statistical data.
It's empty - we aren't going to plug in arbitrary concepts like isA, because the idea of that specific relationship doesn't have a connection to anything relevant to the AI. Just like, if I were to take apart your brain at the molecular level, I wouldn't find a nice, clean set of cells from which your entire concept of "is" and "isn't" springs forth. We're gonna delve into a much deeper, fuzzier area, and hopefully see if my rambling has any basis in reality.
With the mind in place, we have to settle on how the mind operates. Earlier in the thread, I described several levels of consciousness. The mechanism would be loading graphs from the database into memory. What I described were some arbitrary ideas - active, subconscious, emotional. These would actually be self-constructed, and I envision far more than 3 discrete levels will be active.
This AI should have a mechanism for loading and unloading graphs from its "mind" in order to create different states of awareness. This functionality can take two forms - rebuilding a particular state via a set of queries and/or functions, or the storage of a specific graph in the database. Dynamic states would change with time or purpose, and static states would be useful for things like file storage, precise memories, instruction sequences, functions, and so on.
We have the raw, formless mind, and the first function of mind - the creation and manipulation of awareness. Awareness, in our little experiment, is simply a graph ready in memory created or remembered by the AI. We haven't yet given the mind an interface, or devised an attention algorithm.
The mind should also store its code - being able to (eventually) understand how its own self operates, and being able to change that, should be part of the structure. Every function should be stored in the mind, and every function that is executed should be part of some level of awareness - created, stored, and read from the mind into a particular graph in memory. Nothing should operate outside the ability of the program to see - only the initial execution is outside its power of introspection.
Everything the agent is - its mind, its functions, its thoughts - stems from the "brain" database. I think that this is functionally equivalent to the "tragic baby" - its totally disembodied, but has the theoretical capacity to be just as intelligent as any human, should it be given relevant embodiment, and the right functions (or function approximators, as the case may be.)
Just to recap, in preparation for the next step: We have a database representing the mind. This database consists of two tables devoted to graph management - Links and Nodes. Several other tables will be needed to store graphs for later loading, functions for accessing and manipulating the code itself, functions for the creation and management of graphs, and tables used to represent levels of awareness - perhaps the storage of BLOB data for direct loading into memory.
More later, and the beginning of a code framework - I'll be using Lua.