After reading The Need for RDF Linking - Module Proposal, RDF Metadata and this comment I felt the urge to engage in writing this spewage.

The aim of the relations "system" I'm working is to capture the structure of a relation domain. Nothing more. Not to try to interpret the meaning of a relation, not to try and build ontologies, semantic networks, not to store different metadata, etc... Not at all.

You might ask why. Well the main reason is that I think that is not a consern for this particular module. I want it to be able to interpret structures well enough, that there is a way to express out of the box more complex things, that we can do now in drupal. As a side effect, we will end up having a library or API with wich we can express things like this thing is a tree. This thing is a graph. This thing is a set of things. this is an ordered set, and the distance between A and B is x. Things like that.

There is merit in looking into RDF, OWL, and other ways to capture and express the meaning of life. I just happen to think it should be done on another level. Probably on top of the structures I call relations in this series.

Call me a stubborn old git, but I still find beauty in simplicity. And the relations API I'm coming with is complex enough to cause problems.

Some definitions

Let's go on to where I am now. I was hoping to be a bit further down the line, maybe an alpha, but I'm not there yet. My brains have conjured these concepts:

a relation type, relation template

expresses the structure of the relation. No overloaded meaning.

defines the SQL templates to perform the relevant queries

is a node, displaying information about the relation. The nid is the relation type id.

for example: node-node, node-user, node-term relations

a relation type instance, or relation instance

Some or all of the parameters of the type are filled

defines runnable SQL queries

is a node extension(nodeapi),adding to the host nodes information from the SQL queries.

for example: authors(node,_)

Now, there are problems with the relation instances. Do I need an inctance id or not. In some cases it is irrelevant. In some cases it is very relevant. I think we need a set of concepts to test this against, in order to finalise the exact implementation.

peeking into the implemementation up until now

In practise I'm building an SQL query builder. The different relation types will implement series of required interfaces. The core idea is for them to describe their signature- what are they (fields they provide) and what do they work on, implementation details. This information is passed via multidimentional arrays, which are converted then to the appropriate SQL statement. The arrays are a reflection of the SQL AST, or more likely a subset of that. At the moment this is very unoptimised. No JOINS (as in left, right, inner, outer,...), no subqueries, etc...

As an example of what am I talking of here is a part of the node-user relationship definition:

$signature['fields']['nu'][]='uid';
$signature['fields']['nu'][]='nid';
$signature['aliases']['nu']='node_user';
switch($op) {
  case 'both':
    $signature['cond']['op']='AND';
    $signature['cond']['expr']=array(
        array(['op']=>'=','expr'=>array('nu.uid','uid')),
        array(['op']=>'=','expr'=>array('nu.nid','nid')) );
    $signature['param']['uid']='integer';
    $signature['param']['nid']='integer';
......
}

So what does this give us? This code snippet is an example for defining the node_user(nid,uid) function/relation, where the question is node with nid related to user with uid. you need to define as well node_user(nid,_), node_user(nid,_), node_user(_,uid), node_user(_,_), where _ stands for any.

You can see that this way we are covering the all bases for a simple relation with an unknown structure. The metadata will come from the relation instances. They carry the meaning what is represented by that structure. If you want to be able to use RDF, OWL, or any other specialised language, you can always conver.

My point is that we need astract enogh way to represent any relation, while preserving the freedom to hardcode our own optimised code, if we want to.

You might have noticed that the above in drupal SQL is actually:

SELECT nu.nid, nu.uid FROM {node_user} nu WHERE nu.nid=%d AND nu.uid=%d;

The rules?

Nothing stops us expressing things like node_user(node_user(_,uid),_), which translated into common lingo would be All users who a 'related' to the nodes related to a user with the uid. Ok, I've missed the relation instances and a few other details, but that is intentional, since I don't want to overload the idea at this point. Are these rules powerful enough? Probably. Are they flexible enough? We will see.

You can see that I want to be able to provide a declarative language like mechanism, without bothering with the language itself, but working with the AST directly. The language? It will be the UI.

Guys, let's not mix things up. I'll probably need a lot of help on the UI.

in brief

The suggested relations API will provide:

• structure - directed labelled and not-labelled graphs
• queries on top of the structures
• different vocabularies - the relation types, relation instances, ....

Inference can and should happen on top of these. Ontologies? Yes they are possible, based on these structures. Just add the rules.

update: difference with the RDF model

Essentially RDF works with triples, the relation model with tuples. the RDF triples have the form of subject,predicate,object. The tuples are (predicate,....), so that the number of arguments in the tuples is arbitrary. There exists a mapping between the two.