dimelab: shrinking the gap between talk and action.
Somewhere near the heart of computer science lies the complex frontier joining representation to computatation. Every significant computational domain must cross this frontier numerous times in every application. Consider the Turing machine; at first glance, the tape would seem to provide representation, while the state transition engine offers computation. But of course a universal Turing machine can represents any particular computation using the tape. In general, it would seem that any computation can be represented, and any representation would be made useful by subjecting it to some applicable computation.
Despite the ultimate slipperiness of concepts, in practice, computation and representation tend to be pretty well separated, if only for the convenience of the humans who must program the interactions to acheive desired products. Indeed, both computation and representation get quite complex quite rapidly on leaving the spare world of Turing machines and moving towards practical applications. But the division of labor between representation and computation is still often unobvious; situations frequently arise in which complexity can be traded off between representation and computation, and there's a lovely abstract aesthetic to the partition in trying to minimize overall complexity.
Spend some time in contemplation of representation and computation and you might join us in wondering how spare a model will provide full generality. Consider something modern like XML. That's where we started. Clearly XML is biased towards representation; indeed it seems to lack any explicit notion of computation at all. Computation is left to APIs and schema products. Of course without computation there's not much in the way of useful products. So take XML along with DOM or SAX and a fairly general model integrating representation and comptutation emerges. Not exactly spare but well within the ready comprehension of a person of ordinary skill in the art. Plenty of moving parts, however; documents, hierachical elements, attributes, etc. The document-oriented origins of XML may have left a residuum of cruft, despite the uncomfortable limitation of hierachical element relationships and weakly specified attribute semantics. So can we do better?
We scrabbled around logic, linguistics, relational theory, and epistemology, and eventually what's likely a misreading Charles S. Peirce led us to a rather simple model that we have been running with for quite a while. Peirce had a quasi-mystical notion of one, two, three. We read that to mean an entity (one), a characterized entity (two), and a subject entity related to an object entity (three). By entity, we mean anything distinguishable that we care to talk about. Let a, b, and c represent entities. A characterized entity (two) is the simplest proposition; it's the combination of a subject entity with a relation. Letting P and Q represent relations, a characterized entity is a proposition like aP or bQ. We say characterized because the relation in this sort of proposition behaves like the characteristic function of a set, in effect, asserting the membership of the entity in a set characterized by the relation. So if P represented maleness and Q represented femaleness, the propostion aP is an assertion of a being a member of the set of males, and bQ is an assertion of b being a member of the set of females.
A more familiar form of proposition relates two entities via a relation. say aRb or bSa, where R and S are relations. Relation R might represent the has-mother relation, and S the has-son relation. Those who are familar with the semantic web and its numerous precursors will recognize triples and the logic of unary and binary relations. Nothing profound, but apparently it's pretty much all we need for representation. What about computation?
Lots of folks have come down the path to this point. Generally they get this far and start to think about inference and search. Both interesting applications, but, in our view, somewhat limited in generality. We like a our computational model with minimal refinements, so we turn on of our favorite notions, that of an event. For us, the expression of a proposition (a declaration, in our lingo), can be productively considered as an event. And an event, for us, immediately conjures the notions of notification and response. And that's our computational model: responders, which are units of computation, may attach themselves to relations. To process a declaration (an expressed proposition), say, aRb, all of the responders that have attached themselves to R are dispatched a notification of the declaration. The responders are free to take any relevant action. The relevant actions of course are determined by the requirements of the application.
That's the whole model. Responders attach themselves to relations. Entities and relations are combined into declarations. Declarations are processed by dispatching notifications to responders. Stuff happens.
Declarative dispatch sounds simple, because it is. But sort of profound, too, we believe. Richly suggestive as a computational paradigm, we feel. But that exposition is deferred in favor of talking a little about syntax. If you browse around this site, you'll see lots of applications of this model, however.
Because we are connoisseurs of synthetic language, we want this to look good and be easy to write. It gets tiresome to have to spell this stuff out in (doubles and) triples. Moreover, we've not addressed notions of naming and data payloads, details to be sure but crucial for real applications. Clearly it's an undue burden to require a unique name for every entity, so some notion of anonymity is required to alleviate that.
Our syntactic sugar tries to be comfortable for native English speakers and code jockeys alike. We introduce a notion of a predicate. A predicate is a relation and optional object entities. We permit expressions consisting of one or more subjects combined with one or more predicates. We also allow reference to an entity by name or by a syntactic scope in which predicates may occur. Here's some examples.