Texai

In the post Texai’s Dialog Framework, I said:

… Firstly, by using incremental fluid construction grammar, I believe that I can parse and disambiguate, via cognitively plausible spreading activation, the sorts of English utterances required for the bootstrap task of acquiring RDF semantics for the most frequently used word senses in the Texai lexicon.  Secondly, the dialog framework neatly avoids the problem Mike described, by factoring the required model into either the framework or the associated framework interpreter.  The dialog context contains the model, initially populated by RDF statements with variables, and later populated, and the variables bound, by the ensuing conversation with the user.  The Texai dialog framework implements a controlled English language, in which only certain forms of questions and responses are permitted.  Within these constraints, I expect that Texai will fully understand what it generates and what it parses.

In this post, I’ll delve into the Java objects and behavior that constitute the Knowledge Acquisition Framework, which implement dialog scripts that themselves can be taught to Texai.

Continue Reading »

Having spent a reasonable amount of time on the distributed Texai framework, I am suspending those associated tasks, and returning to integrating the existing bootstrap English dialog system into the new skills, roles and nodes architecture.  My immediate goal is to adapt the existing dialog libraries as Texai skills, which are thread-safe plain old java objects (POJOs) that distinguish state according to a given conversation identifier.  The previous dialog source code components are already structured as nodes, so I expect that most of the work will be integrating the new dialog scripting framework, of which I will have more to say as it progresses.

Self-imposed time bounds on the distributed Texai framework compel me to leave it undone for the time being.  This means that Texai will be only usable as a web service hosted by my lab server over the internet, when I get the bootstrap English dialog system reworked to the new skills, roles and nodes architecture.

Continue Reading »

The Internet uses well-known service ports to more easily achieve interoperability.   The Internet Assigned Numbers Authority, IANA is the entity that oversees global IP address allocation.  In addition to legacy ports in the range 1 … 1023, IANA allocates ports in the range 1024 … 49151 for network services.  Today I received notification that my request has been successfully processed and Texai has been allocated TCP service port 5048.  The complete list of IANA assignments is here.

Continue Reading »

On the Singularity list, Matt Mahoney said:

For uploads [future human mind uploads to a computer], it is a legal problem. Consider what uploading is. You sign a contract with a hosting company that they will run a program that simulates you after you die. Upon your death, you transfer control of your wealth to the hosting company with the stipulation that the property be controlled as directed by this program. However, if the hosting company breaches the contract, you have no legal recourse because you are dead. Even if we pass laws that give protections to these programs, they would be very difficult to enforce. For example, the hosting company might secretly modify your mind model so that it wants to give your possessions to them. How would such tampering be detected?

Another legal question is to define the circumstances under which tampering is permitted. Suppose the upload commits a crime. Legally, the hosting company is responsible, just like it is the virus writer and not the virus that is responsible for infecting your computer. So the upload hosting company has a legal obligation to modify your mind model to prevent it from doing anything illegal. It does not seem to make any sense to me to transfer that responsibility to the program. How would you sentence an upload to jail?

Over the years, I’ve thought about obtaining a Limited Liability Corporation for Texai. I have one already for my family’s landlording business and they are easy and inexpensive to get.  As long as I am alive, I could be the owner of my Texai instance LLC, then upon the death of my body, ownership of my Texai instance LLC, and its associated lifelog, mind upload, etc. would pass into a corporation, as a subsidiary AGI LLC, that human owners of Texai instances trust.

Having AGI instances be legal business entities permits them to be paid for services rendered, to inherit wealth, to own and to control real estate and capital, to be governed by the nested legal jurisdictions in which they operate, to enter into binding contracts with human individuals and with other business entities, and to pay taxes.  If such a business entity AGI misbehaves by breaking some law, then the courts and the law are applicable as currently for any other business entity.   There may not be a human owner of the subsidiary AGI LLC still alive to put in jail, but the courts could punish an AGI LLC by fining it, by making it pay damages to the injured parties, by compelling changes to its organization,  by removing conflicts of interest, or as the most severe punishment – removing its resources.

By my way of thinking, every AGI LLC itself would evaluate, shop around, and pay for compute resources, storage, bandwidth, and robotic peripherals, that it needed, and not be solely dependent upon a possibly untrustworthy hosting company.

The Google Android platform for smartphones has been in the news recently. While revisiting how Texai might best be hosted on, or at a minimum interact with, an Android device, some design issues came up. As resolutions, I’ve made these decisions:

• to postpone a full port of the Texai code base and third party libraries to the android version of Java
• to refocus on XMPP, e. g. Google Chat as the preferred method for android app interaction, and to ensure that the existing Texai web chat HTML forms work on the android UI
• because work on the Texai application installer revealed unnecessarily complexity, the message router component will be coelesced into the node runtime

Continue Reading »

The OSGi framework is a module system and service platform for Java that implements a complete and dynamic component framework. By implementing Texai skill and sub-skill components as OSGi bundles, those skills can be installed, started, updated and uninstalled without requiring a restart of Texai. Furthermore, the texai NodeRuntime, Node and Role classes will also be implemented as OSGi bundles, taking advantage of the framework. OSGi has no built-in provision for stateful services, and each component class will have a single service-providing instance. Therefore, in the case of nodes, the Node instance will keep separate internal state for each Albus Node that it is modeling, and likewise in the case of roles, the Role instance will keep separate internal state for each role that it is modeling. For roles having a sensation or action granularity level beyond 1,000 seconds, it is expected that the internal state will be persisted to recoverable storage, e.g. the knowledge base.

Continue Reading »

I envision Texai to be eventually vastly distributed and potentially operating on a very large number of hosts, including in a limited capacity – smartphones and mobile internet devices.  I previously described how I’ve elaborated the Albus Hierarchical Control System for Texai scalability.  James Albus specified asynchronous message passing as the communication mechanism between the nodes making up his intelligent system design.  Here I will discuss how Texai routes messages.

Continue Reading »

Paul Gowan recently asked several interesting questions in his comment to the Design page.

What do you regard as the smallest dataset/ontology required for an A.I. capable of learning?

I believe that the Texai ontology, having concepts  derived from OpenCyc and greatly augmented by WordNet and Wiktionary, is sufficient for class and instance concept learning.  By learning, I mean the sense in which an AGI can be taught by a mentor, rather than hand-coded by a programmer, or learning on its own.   My initial goal with Texai however goes beyond concept learning and includes skill acquisition.  To keep the size of the bootstrap ontology as small as possible, I want to focus on learning the skill of skill acquisition – in a bootstrap fashion.  Likewise, I want Texai to acquire new lexicon by being taught the skill of lexicon acquisition.

Continue Reading »

The Albus Hierachical Control System (HCS) has been usually depicted by James Albus as a tree in which each node has one superior node.  In his book Intelligent Systems, Albus allows for multiple hierarchies to exist over the set of constituent nodes.  The Texai design makes use of this generalization with one constraint: there is a single root for every control hierarchy.
Continue Reading »

My normal work routine was dramatically changed last August when I learned that my Mom had been diagnosed with terminal colon cancer. Because I alone among my four brothers am retired, and because I am supported by my wife BethLynn, I moved from Austin, Texas to Woodville, New York to care for my Mom during her remaining months. Not knowing how long my Mom had to live, I cancelled my plans to attend the AGI-10 conference in Lugano, but I continued with my research and programming.  From my home computer lab in Austin, I took only a wide-screen monitor and a Eee PC netbook.  My Mom had broadband internet, and there I added a wireless router so that I could conveniently network myself and our visiting family.  Although the netbook is about 10 times slower than the development computer in the lab, I was determined to completely recreate my familiar programming environment – adding a full sized keyboard, mouse, and printer. Because my declining Mom was active only a few hours a day, I had plenty of other time to work on Texai.

Continue Reading »