The key concepts that allowed me to fuse these concerns and make progress in either of them only through making progress in each, was that of the contradiction.

The Java language and all programming languages which I have had dealings with thus far do not encapsulate the concept of a logical contradiction as an element of the language. For most practical concerns that we are taught in programming classes, the languages needn't do so. However, in logic the concept of a contradiction is one of absolute importance, because of its innate relationship to truth and falsehood.

Just about any program you can write ultimately needs to make binary choices of how it proceeds, depending on the circumstances of its environment. The behavioral complexity of most programs are usually constrained by the variations in data, and the relationships between your conditional expressions is "taken for granted" by the program. In other words, the programming language and compiler usually trust that you know what you are doing.

This is reasonable, because when you write software code you do so in the context of your program's internals. The relationships are evident to the programmer, because they're kept in that programmer's short term memory (attention). OOP constructs and other techniques are used to create abstraction barriers that shield the programmer from the complexity of having to know how everything works, and the logic is free to become more complex as a result of these encapsulation barriers.

However, encapsulation barriers necessarily permit and in some cases even encourage reproduction of software code, and ultimately of decision making logic. The result of this relationship between encapsulation and executive logic duplication is that the executive logic becomes fixed and very difficult to change. Arguably, better software architecture and finer-grained class libraries could mitigate this problem. However, in languages like Java, the entire environment within which a conditional expression might draw its path of action must be passed around because of the inability to pass the expression itself using a lambda-like semantic common to Scheme and JavaScript. The architectural acrobatics necessary to place a conditional expression within a meaningful environmental context to secure a dependable and sufficiently complex result does not lend itself well to most modern programming languages.

And so, conditional expressions are littered throughout a program's structure, duplicated in different classes, and difficult or impossible to locate or update in a timely manner. Worse, these factors combine to obscure any meaningful relationship that might exist between the conditional expressions, and the very notion of this level of relational analysis is usually left to runtime debugging and long-term software maintenance.

The Arete rule engine addresses all of the issues enumerated above in a variety of ways. First, it provides a robust way to decouple the structure of conditional expressions and logical behavior of a program from the environment within which these expressions must operate. It does this by inverting the relationship between data and logic. In elementary programs, logical code runs in the context of a data-rich environment. In the Arete rule engine, the logical code is broken down into a type of data itself, and is recombined in response to the needs of the environment, as indicated by the original environmental facts, and the rule developers analysis of the relationship between these facts and the logical responses to them. Because complex conditional expressions can be reconstructed from more primitive elements in this simulated way, Arete encourages an even greater degree of code reuse than can be easily gotten inside of a simple Object-Oriented mechanism.

A secondary benefit of this large level of code reuse is the ability to analyze the relationships between our pieces of logic. We can now construct complex implication trees with much less code, and even begin to help the developer pinpoint logical contradictions in the subtle relationships that exist between our conditional expressions. This in turn leads to metarelational analysis which can identify maximally consistent subsets of rule assertions, and even automated aporetic resolution strategies.

But all of this aporetic functionality requires the simple concept of a "contradiction" taking primacy to concepts of "truth" and "falsehood" within the context of the engine environment.

It is not difficult to write a simple rule engine that does nothing more than help you decompose and recombine conditional expressions, but the many benefits of this granularity cannot be realized without the ability to draw relations and implications from your rule declarations.

So, this is the present course of R&D on the Arete project. I am implementing a fully aporetics-capable modal logic platform, based on previous experiences with rule engineering and my early success with Arete's Alpha Core. The second engine core will not replace, but instead complement and refine the workings of the first engine core. Arete's architecture permits me to create multiple operation centers that each do specialized variants of the heavy lifting, depending on what the developer needs. The software in the alpha-06 release is really just a very limited proof-of-concept for a rapidly evolving platform.

I'm trying at each turn to make sure that my architecture is theoretically grounded and that I'm not writing myself into a corner. I'd like to be able to support intensional semantics and possible worlds syntax, which are really necessary for any useful Alethic or Tense logic implementation.

So, the result is that I have made more advancements in the Arete and CORM projects than I have shared with the public.

The first, and most significant advancement has been the purchase of $750 worth of server and network hardware, and the installation and hardening of the Solaris 10 OS on these machines. I had to teach myself Solaris administration, which was not trivial. Establishing the machines on the network in a secure manner was also not trivial. I registered a domain and set up port forwarding so that I could access these machines remotely, not without help and encouragement from Catharine.

Then, two weeks ago, I made the most important upgrade to the system to date. This was the purpose of the entire hardware and system setup.

I installed Subversion on my Solaris server.

Now Catharine and I can work on our three projects in truly collaborative terms.

As an aside, I have fought for a long time to get SVN at the University of Minnesota, but there is no funding at the University of Minnesota for Open Source research and development. They like to use the software, but don't have the organizational vision to foster a developer community here. At least not in the Office of Information Technology.

I hold out hope that the Institute of Technology could pick up the torch on this and move it forward. I know the students are interested, but I don't know whether the departments have any idea how to integrate the Open Source methods with their classroom instructional methods. I'm taking two computer science classes this autumn (nothing glorious, but rather reclaiming a bit of dignity on my transcript from early years when I was working to support myself as an undergrad and underperforming in college), and I can see how using standardized unit testing frameworks would really ease the lives of the TAs in the computer science departments. If there were a central directory for people to upload their packaged code, the TAs could effectively grade by running standard tests against student's homework assignment code, which would precisely mirror the method we use in Open Source: implement the test code. You're done when my tests run.

/end rant

The result of all this effort is a new sense of acceleration in R&D. In particular, CORM is getting a lot of my attention in the last three weeks. I've been absolutely amazed by the discovery of the JScience.org project, and immediately moved to integrate it into the CORM project, as it implements the entire quantity pattern much better than Arlow recommended, and does a decent first shot at the Money archetype pattern.

The most drastic changes I've made to my plans for the CORM project have been completely scrapping the Rules archetype pattern and moving to implement the rules in Arete. I think that Arlow's model fails to respect certain inversion of control principles that help us test and write good code. As such, we've inverted the paradigm and decided that CORM will remain a purely passive data storage model. All business logic will be implemented in a rule container, and the CORM objects will reside within that container and under its management.

But none of this is why I'm writing today. Today I'm writing to introduce the second official engine core of the Arete project. The first engine core was appropriately called "Alpha", and I'm calling the second logic core "Bravo". The Bravo Core implements the foundation for both a modal logic platform and for a real Aporetic analysis platform. The purpose of an aporetics platform is to analyze relationships between rules and find the subtle contradictions that arise in our short-sighted implementations, then to employ resolution strategies to isolate and resolve these apories.

The basis of such a system is a simple implementation of "K", Kripke's logic. In "K" I made the concept of Contradiction primary to that of boolean truth within the context of the Bravo Core, and by doing so managed to disconnect the imperative structure of Java from that of my rule assertions. In other words, truth and falsehood are no longer merely boolean values in the system, but are conditions for contradiction. The system will allow you to declare something to be true, and a second later to declare it to be false, but will throw a Contradiction to alert you to the discontinuity in your logic. This replaces the standard behavior of assignment operators in modern programming languages.

Anyway, I tagged a release today. Finally. It's at the Arete Download page.

Example code is limited to test classes right now, but the Bravo Core is fully tested and operational.

α: A --> B
β: B --> C

Both of these conditional statements are related in an easily determined way: the apodosis of α is the protasis of β. If both of these are declared in the core, the core can automatically determine the implication that:

γ: A --> C

This is clearly a reasonable implication. The goal is that our user should be able to declare:

δ: ~(A --> C)

And cause a contradiction to occur in the core. But suppose they did not declare δ Suppose instead they retracted γ explicitly. By implication, either α or β would also need to be retracted by the engine core. How does the engine decide which one to retract?

Because this does not involve negation, we cannot opt for a simple disjunctive solution. At this point we are no longer in the realm of mere propositional logic. We have officially entered the realm of aporetics, which focuses on apory (paradox) resolution strategies. The grey ground here comes partially from our distinction between negation and retraction. A declaration of A is a positive assertion which can be altered in one of two ways. Either we can contradict the original declaration and say "~A" and cause a logical paradox in the system, or we can simply retract the original declaration. The retraction still allows for the possibility of "A", and constitutes a sort of clean slate.

Negation, by contrast, is a positive declaration in the following form:

&eta: A --> !

This reads "If A, then there exists a contradiction". The difference between a naive logical negation using boolean operators in Java and this concept of active contradiction is that the latter doesn't permit unacknowledged change in the logical tenets of the system. You cannot declare "A" and a minute later declare "not A", thus overwriting your initial assertion. This is because "not A" might be the unforseen consequence of a complicated set of rules. While this is harmless in an imperative logical environment such as Java, the proper way to deal with negation in a declarative platform is to explicitly declare something to be the condition for a contradiction in the system, and then use standard exception handling to initiate one or more aporetic strategies at runtime.

It might be that the distinction between retraction and negation is lost in text books because so many texts are trying to communicate the absolutely basic relationships between different axioms and arguments. But in the real world, the world of practice, people and machines are busy declaring truths, contradicting themselves, catching their errors and, unless they're simple ideologues, retracting their earlier declarations. The aporetic process is so second nature to us that we've rarely afforded ourselves the opportunity to give it a name. And, while examples in text do not lend themselves well to retraction--for how do you retract a written statement?--today's logical workbench gives us every opportunity to do so.

So, what strategy will we use for resolving the above paradox? One strategy involves maximally consistent subsets, and the other involves assigning plausibility values to all declarations. A combination of these is likely what I will use. These plausibility values will be explicitly determined by the operator as the lattice of logical declarations is framed. The most immediate challenges to completing the implementation of this feature revolves around determining the plausibility of implications, a topic that was not covered in books on aporetics which the author has yet read.

My instinct is to play upon a variant of the "truth corruption" principle that I currently use in logic. The truth corruption principle states that if any part of the logical statement is false, the truth of the statement is corrupted entirely. Within every lie may lie a truth / But truths may never be composed of lies. A variant of this, the "plausibility corruption" principle might state that the plausibility value of an implied declaration is never greater than that of its least plausible implicative. An implication's implicatives are those declarations whose contextual relationship directly led to its inclusion in the latticework of logical statements.

As an aside, I wasn't kidding about creating that ontology--I don't even like the word 'ontology'-- but my esteemed friend Mr. Bringman convinced me that it ranked among my major obstacles in creating this engine and the community around it. I promise that these terms will all be explained in a glossary of terms soon. I'll even add that task to the JIRA.

There must be distinct types of implicative relationship, then. Some implications are bidirectional, tautological, unidirectional, and can involve other implications. It is this implicative latticework that lies at the heart of a real analytics framework. It informs analysis but also distinguishes a truly declarative system from the imperative bias of all modern logical computing languages.

More on this implementation as it unfolds.

Before I can instantiate an alethic system, I must first determine the core architecture of an extensible propositional logic language, based on "K". I'm exploiting Java's built-in concept of exceptions to handle the behavior of contradictions in the logic core, and encapsulating contradiction as a foundational principle of the entire logical system. This idea comes directly from Garson's text on modal logic.

Right now I'm experimenting with the concept of a sentence, and trying to build propositions, contradictions, and conditionals all as sentences. One challenge is that a conditional uses two sentences and I wish to keep the API distinct for the time being from the imperative logic API that I've been using thus far. So, I might be spending some time with the Organon to find meaningful vocabulary. I'll also be returning to the logical lexicon I established earlier this month.

I intend to support these two sentence types in the same logic core:

1. An imperative type which initiates change in the system as a result of a specific anticipated state of conditions, and
2. A propositional type which analyses the structure of and relationships between both the state of conditions in the system and the imperative sentences created by the knowledge experts.

In order to do this, I'm building a Lexicon, and while I draw the line far from finding the quiddity of these terms, I do want to assemble enough nouns to allow myself to be both expressive and correct in the core APIs.

Imperative systems direct the actions which a computer program performs. They are perhaps the most common and practical systems in use today. Less common, though ultimately no less practical, are logical systems that evaluate the truth of certain logical arguments. Telling a computer how to perform certain functions is useful, but dangerous if the reasoning behind our commands is flawed.

So, I'm interested in building systems that can provide a means to analyse our logics as well as to execute them. That's what I'm trying to build with Arete. However, the effort requires visible public progress as an Open Source project before I can get some of the needed infrastructure to continue more advanced development. This requires an iterative approach to building the platform.

The problem with this iterative approach is that there is scant and often contradictory literature to help me distinguish the two types of logic listed above. Often terms are used interchangeably between the two types of logic to describe what are essentially different things. Theorems, premises, antecedents, consequents, hypotheses, sentences, clauses, instructions, protasis, sumperasma, arguments. Logical literature today is a mixed bag of ambiguity and industry buzz-words.

So, I'm trying today to come to terms, to fashion an ontology I can use moving forward in development. It is fun but demanding work, and I've not yet eaten. I think I should see to that.

These lists will be open to the public, and the arete-user list archives are searchable from the University of Minnesota LISTSERV homepage.

1. An improved project directory structure brings us much closer to a Maven2 build
2. 100% unit test coverage!
3. The addition of a new example application--a Rock-Paper-Scissors game simulation.
4. A vastly improved I/O subsystem, with much more robust error checking and reporting for XML files

But that's not the end. Really, the project is maturing at a steady pace, and with full unit test coverage we can begin to turn our attention to a boat-load of new features that are in our project JIRA, including more and better example applications and advanced engine cores. It is an exciting time in Minneapolis.

The good news is that the blog got a face lift last evening, and is looking pretty sharp. Once the mailing list goes online, I'll report with updates.

Here's the big plan. I'm going to get the following for this project:

I'm working on three more sample applications for Arete.

The first application is none other than Miss Manners. That's right, she's back in full effect. I've currently got her cranking out very VERY large seating plans, and while she's not perfect just yet, it's really just a matter of time.

The second application, which I'm pretty excited about, is a deck analysis program for Magic the Gathering. I'm experimenting with MTG because the game rules involve manifold modes of truth assertion. At the moment, my attention is focused on the data gathering and data modeling aspects of the application.

The final application is a network diagnostics tool. I'm going to write something to help my colleagues in 1-HELP troubleshoot network problems at the University. Of course the application will have limited use, because so many of the core systems at the University which we use for diagnostics do not expose public interfaces. This is fine. I'm going for the 80/20 approach.

Hopefully these three sample applications will garner some interest and attract a few interested developers. I think the best way to see why modal logic is important is to try to model a system for something that involves a lot of timing, possibility analysis, and permission / obligation rules.

With any fortune, I'll be able to show some respectable progress to the IntelliiJ license granting team in the next couple of months. Until then, my friend Nate's going to have to use Eclipse.

Coding Tonight

Documentation authoring is simple on UMWiki. I used to publish a lot of articles in various online tech journals such as Java.net and TheServerSide.org, but the ability to push out professional-quality documentation and keep it up-to-date on a minute-by-minute basis was never something that my publishers could offer. I would rather write and publish for free on the UMWiki platform than get paid to write for my old publishers, not because I have something against the publishers--they were great. But this technology really puts me where I want to be, which is in the driver's seat.

Anyway, enjoy the quickstart manual. I'll be writing a lot of these in the near future, I think. There are dozens of projects here on campus that could use documentation like this.