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.

I've been experimenting, again with these. Apart from some bugs, the things are moving. I'll try to summarise my findings and thoughts on this beast called relations.

throw everything into the water

Let's start with a little bit of maths. It gives me that comfort feeling of being serious if I put down some formulas. I might be shooting myself in the head, which is not that comforting.

So, in our case, a relation is a n-tuple - R(X(1),..,X(n)), where Xi are some sets, possibly ordered, or partially ordered sets. The simplest useful relation would be the R(x) - a single value. The equivalent of an SQL databse table is R(Y(1),...,Y(n)), where Y(i) is a column in that table. The equivalent of a SELECT ... WHERE query in this little math markup journey is F(R(Y(1),...,Y(n))), where F() is a filter function implementing the conditions in the where clause. Similarly a row in the db is R(y1,...,yn), where yi is the value for Y(i) in that row.

In this scribble I'll discuss an implementation of different topological structures, which can be used for indexing different "relation systems", for example trees for menus, book structures, etc... graphs for caching links between pages.

We can split the problem into two main subproblems. First, navigation and queries withing a single relation domain. For example local table of contents for a section in a book. Second is higher order or inter-domain queries. For example: given a node, determine the all related nodes, ordering them by their distance from the node, based on taxonomy, their position in a book(s), and their position in the site's "link web". We should be able to implement second and hier order based queries, based on the results of these two basic problems.