Open Beta and What is JLS anyway?

The Jnana Logic Server (JLS) is available for anyone to build their own smart web applications. JLS is used entirely from your browser - no applications are installed on your own computer.

You can build a decision tree application using the QART (Question-Answer-Result-Tree) editor. Or you can build a case base reasoning (CBR) application using the CBR editor. Both kinds of applications may be extended by what we are calling special cases. These are situations where someone thinks a different result should be provided at the end of the reasoning - perhaps with some additional questions. In this way your application can be dynamically extended while you as the author have the ability to manage these special cases and update your application.

These JLS applications can then be used as iGoogle gadgets, or on Facebook, or linked to in any way you please from your own web pages. JLS is great for building applications for advice, how-to, or product selection. How many times does one go to an online store and find too many options or products available. Wouldn't it be nice if there was an automated advisor available to ask you some questions and help you choose 2 or 3 options that are relevant to you? Much as a salesperson in a brick and mortar store might help.

The possibilities are open to the imagination.



A more technical view of JLS

This version of JLS is hosted on the Google App Engine (GAE) hosting environment. GAE is still in a preview status. Currently all usage of it is free but includes various resource usage quotas. It's been mentioned that a paid version will be available before the end of the year. Until then it is entirely possible that JLS max out some resource usage quotas at various times; we will be doing everything we can to avoid that and if anyone notices any problems please let us know.

This version of the Jnana Logic Server on GAE currently supports decision trees and case base reasoning. The implementation is more general. Currently rules and the left hand sides of rules (situations) are used to support the operation of decision trees and the operation of a JLS application. There are JLS engines we call alerts and orientations that are used for some simple output.

JLS on GAE is a small subset of our general artificial intelligence JLS version that has been developed over the last 12 years. We have taken a general approach to declarative programming that doesn't require a JLS application author to understand imperative programming (control structures). In all cases we take a completely graphical approach to author editing - no actual programming syntax is encountered.

We take the point of view that one may use the type of logic one needs for their JLS application. This can be basic mapping rules, decision trees, CBR, constraint reasoning, distributed applications, natural language processing, factor lists and even spreadsheets. Logic can be simply thought of as take some data as input and write your outputs to some data. Writing a rule doesn't have to know anything about writing a constraint, for example. All logic can be worked on independently and in fact one could have different bits of logic that produce outputs for the same data. How the system decides what to do is managed by JLS's prioritization algorithms that operate similarly to how a human might ask questions of a user in order to get to a goal result. A human would try to ask the smallest number of questions but as some questions are answered different options or bit of logic may become relevant and different questions then asked. It's all very complex :-)

Our full JLS platform also includes more outputs and inputs. As usual, these are modelled as logics inside the system, but the application author doesn't need to understand that in most cases. These include Rest and Web Service logics, database integration logic, Chart and Table logic utilities, html report outputs, PDF logic (filling PDF forms automatically), email logic (in and out), and much more. Many of these logics can become quite specific. Part of the point is that all these logics are essentially independent of each other and new logics can therefore be added as necessary (whether for some specific need or recognized as a generally useful addition to JLS). Due to the general nature of how logic interacts with data this model is effective as a general purpose declarative programming environment while also providing artificial intelligence tools to the everyday JLS application author.
Who could ask for more :-?

JLS on GAE is a subset of our full JLS system for two reasons. First we are interested in simplifying JLS to the point that it becomes more attractive and easier to use for anyone. It's possible we have simplified too much and will need to add some of our features back into it.

The other reason is that this is a re-implementation in the Python language with the restrictions that GAE imposes. This subset re-implementation includes the core of our JLS system with only a couple features not implemented. The interesting aspect of this is that we must have a response time in the neighborhood of 1/3 of a second. If and when we add more logic engines or core features to JLS on GAE we will be closely watching how that affects our CPU performance.

Some may find it interesting that we did this in Python. Our full JLS is 100% Java. However, we have noticed that Python lends itself to symbolic programming readily. We (ok, I) have been pleasantly surprised at the simplicity and effectiveness of using Python for symbolic programming and find that many of Python's language features are readily mapped to the types of programming that we need in JLS. We've found that the need to build support utilities for JLS in Python has been significantly less than in Java - less code generally means better maintainability as well as faster execution. And I dare say that some aspects of programming in Python are very much like the days of programming in Common LISP.