I realised that I need to demo, coming soon in flesh, why I'm doing the relations the way I do, and why I have these strange concepts.

Let's start with an example in KIF, the example is lifted from the KIF draft proposed American National Standard (dpANS).

(defrelation number (?x) := (or (real ?x) (complex ?x))) 

What does it mean? Well, is number(x) will be true if x is either a real or complex number. Number is a relation.

Generally speaking we have two ways to define a relation or function - either explictly defining all possible/known cases, or by using some procedure to produce them.

How does that map to Drupal? Drupal stores a lot of different objects in its database. Drupal has nodes, users, userprofiles, aggregator feed, aggregator items, taxonomy terms, etc... All of those can be viewed as basic relations. I wouldn't call them atomic though, since that role should rightfully to fields in Drupal speak. Each of these object is a relation or a composition of relations.

So a node with its related elements form a relation composition indeed. And I target those, which can be expressed in one SQL sentence.

For example - our drupal node is a composition of the node and revision + maybe nodeapi extensions. That's correct enough due to the caching mechanisms.

Node lists and all other lists are relations in the above knowtion - they are defined by a procedure, and they answer a particular question.

An example for a relation definition:

relation('CROSS', 
   relation('NAMED','node','left'),
   relation('NAMED','node','right'), 
   filter( eq('uid','uid'),
   NULL
)

This should generate a list of all node pairs which are authored bt the same user. Pretty useless that one. For more look at the test cases in svn.

So I've set out to capture this knowledge and explicitly define it. This is what my work on relations in Drupal is. This is why I approach the database in the way I'm doing it. I want to be able to declare realtions using a subset of SQL's expressiveness via UI or limited coding passed through the php filter, or similar.

We will be able to use Drupal as a knowledge base, with relations defining the knowledge rules.

Inference - well, we will be able to find out if an object satisfies any of the declared rules/relations. By implementing algorithms on top of the rule base we will be able to do interesting speculations. You will be able to apply most of your favourite symbolic AI techniques (if you have any that is).

The structure of the rules is such, that it can be used not only for data filtering and retrieval, but for building the content view, of the relation. This is where the forms api comes to play - we can make both the content forms and the views rendered by the forms api.

To bring this further - we are not limited by the 'type' of view - html, rss, rdf, atom, kif, owl - anything appropriate is possible. Just theme it.