Applications of Rhizomes

The intention of this post is to shed a little light on possible applications of rhizomes. I am personally still struggling to figure out what the best use cases for rhizomes might be, but here is a list including some ideas nevertheless. The basic problem I am confronted with is my own tendency to interpret rhizomes in terms of existing data structures and algorithms instead of focusing on what is genuinely new. I have recently come to the (maybe preliminary) conclusion that rhizomes are at their best when it comes to post-structuralist applications. That is, applications where up-to-date a certain data structure is silently accepted as a best way to do things. I call rhizomes to be post-structuralist because they violate the common paradigma of storing data on the one hand and linking it on the other hand. Rhizomes, compared to graphs, do not consist of nodes and edges, but only of relations. The main characteristic then, in my eyes, of rhizomes is that they allow unrestricted connectivity. Everywhere. There is nowhere an element which cannot be connected to any other due to an underlying paradigma. Therefore, there is no separation between data and structure but only “order” in the most abstract and fundamental way.

Hierarchical file systems

My laptop’s file system is organized as a hierarchical tree. The file system contains two basic elements, directories (folders) and files. Each directory and file has a unique identity in the whole file system, defined through its path. A directory can contain any number of other directories and files, whereas a file cannot contain other directories of files. (This is not entirely true, as sometimes modern files such as packed .zip files are internally organized similar to a file system themselves.) Some file systems additionally allow the creation of symbolic links to alleviate the restrictions of the file system’s hierarchy a bit. Yet, these links can break if the link target is removed without updating or deleting the symbolic link.

One of the most severe restrictions is that a file cannot be placed inside two different directories at the same time. The only way to do this is to create a copy of the file and therefore redundancy. Imagine the following situation. A user organizes her blog around categories “food” and “animals”. For this purpose, she has created two directoreis “food” and “animals”. One day she has the idea to write about her dog’s favorite food. The only question is where to place the corresponding post file. Her computer’s file system prevents her from placing it in both directories, but that’s where it would actually belong.

In a rhizome, the file system’s hierarchy can be broken up. Files can be placed in several directories, it would even be possible to place two directories into each other or a directory into itself (perhaps with some modifications to the basic algorithm described in my last post.)

Ontologies

Ontologies are another example where an implied structure can sometimes be painful. Most ontologies demand that a thing either belongs in one or another category, but not in two different ones at the same time. I still remember a biology class in high school, where under the teacher’s guidance we tried to figure out whether a virus should rightfully be categorized as a mere molecule or a living being. Most computational ontologies demand to make an exclusive decision, whereas in most cases our perception of the world is sensitive to contexts and to interpretation according to circumstances. Whether a virus is considered to be a molecule or a living being, or whether a person must correctly be categorized as a father, lover, brother, chess player or firefighter is actually dependent on our concerns and on the questions we ask. Rhizomes have no problem in putting a thing into several categories at the same time. With certain modifications the concept might be expanded to support contexts. Inside a given context, contradictory categorizations are not allowed. But a meta-algorithm - running on the same relations! - might be allowed to return contradictory search results and let the user decide which of the possible categorizations she prefers. The crucial point is that a rhizome would not require the creation of two different ontologies, but only to contextualize the stored relations.

Furthermore, in computational ontologies it is common to have a certain meta-architecture, which is not part of the ontology itself, for example data structures such as subject-predicate-object triples. In this triple the predicate is the relation between subject and object, but the relation between the subject and the predicate or the object and the predicate has no identity. Thus, unlike in traditional ontologies, a rhizome does not prohibit a developer to address these subject-predicate or object-predicate relations, or even predicate-predicate relations of two different triples and so on.

Object-oriented programming

Similar thinking as for ontologies can be applied to object graphs in OOP languages. Whereas Java allows only single-parent inheritance, C++ allows multi-parent inheritance with all its dangers. Some languages like C++ allow pointers to be stored in variables and manipulated, whereas others like Java do not offer such functionality. Yet also in C++ a pointer is rather a “second class citizen” besides full blown objects. It cannot call a function, it cannot inherit from other objects and so on. The underlying paradigma is still that of nodes and edges. A rhizome however has no preference over its elements, relations are all there is.

Also, most modern OOP languages introduced reflection as a feature. Although in practice rarely used, in some cases reflection leads to highly elegant solutions, for example when creating a debugger application. Reflection offers a way to dynamically establish connections, for instance calling a method not through a direct pointer but by its name. Rhizomes could take this approach even further, as they would allow literally any element to be related to any other at runtime. Maybe it might be interesting to entirely switch an object’s class (or its methods or instance variables) at runtime.

An example. Assume that you wrote a class with a logException method. The objects of this class could be serialized and sent back and forth between the client and the server. On the server, the method should silently log exceptions to a log file, whereas on the client a popup should appear to the user. How would you implement this? Probably you would use an OOP strategy pattern. The purpose of this pattern is to decouple an object its method to select a certain behavior at runtime. The problem with this pattern is that something that is inherently a behavior (i.e. logging) is modeled as an object (class ClientLoggingBehavior and class ServerLoggingBehavior), and not only as one but instead as two different objects, because we need to introduce a new class per logging behavior. This is counter-intuitive. We human beings are very used to do things differently according to the context. In our reasoning we perform the “same” action (logging) in both contexts - just adapted to the needs of the current context. If the object and the method would be coupled through a rhizome, we could decide at runtime which method is currently attached to the object. Then there would be no need to write different classes and instantiate a client- or a server-behavior object before calling the log method.

Uniform Resource Identifier (URIs)

The internet is built upon the node/edge paradigm. Websites (nodes) can contain links (edges) to other websites. What is not possible to do is to link from one link to another link. Whereas an Uniform Resoruce Identifier (URI), as its name says, identifies a resource on whe world wide web, the URI itself has no identity. It cannot be identified. Being able to create links to links could be a very useful feature, as it would allow to attach information to these URIs. For example, if a trustworthy source links to a certain other website, this might be much more relevant to me than if the link is from any other website. Or two users might disagree in some way on a certain link. This would however require us to somehow add the information on trustworthiness to the URI. And this is only possible if the URI is addressable itself, in other words, if I could create an URI to an URI.
It would also be a nice feature if a link’s origin could either point to several targets or if a target could have several sources.

Rhizomes might support such architectures in one way or another. In a rhizome, not only the website’s URI is stored as a relation, but also the URI itself could be stored as a relation, therefore making the relation between website and URI addressable.

Other examples

These are just a few examples presented here. Other suggested applications (using the term “pile systems”) can be found in several places:

1. Krieg P. (2005): Die paranoide Maschine - Computer zwischen Wahn und Sinn. Telepolis/Heise Zeitschriften Verlag. Hannover.
   The book seems to me in some parts rather enthusiastic, and I am skeptical concerning some of the more elevated claims in it. Nevertheless there are some valid and interesting points, and there is a section on possible applications. (Here is another, somewhat critical comment on this book by Eberhard von Goldammer.)
2. Westphal R. (2006): A Journey Into The Pile Universe. Blog entry available at: http://www.lawsofform.de/wp-content/uploads/2006/05/RalfWestphalBlog.pdf. The author shows how a “pile system” (rhizome) could be used for text storage and retrieval.