LawsOfForm

Als ich das neue Paper “Freeing Data From the Silos” von Ralf gelesen habe, wurde mir einiges “klarer”. Besonders interessant fand ich das Beispiel mit der Pile-Relationsstruktur für ein ASCII-A und die Veranschaulichung, wie durch das Traversieren von einer Relation zu den Tops das ASCII-A aus dieser Relationsstruktur erzeugt werden kann. Ganz im Sinne “erkenne um zu handeln, handle um zu erkennen” dachte ich mir, “Okay, jetzt hast du erkannt/gesehen – jetzt muss ich handeln, um noch mehr über Pile zu lernen”. Um meine Lern-Feedbackschleife zwischen “Theorie” und “Praxis” ins “Rollen” zu bringen dachte ich mir, das Paper von Ralf ist ja so konkret, das ich hierzu doch einmal eine handvoll Javaklassen programmieren könnte mit einer rekursiven traverseUp()-Methode, um Daten aus einer Pilestruktur zu erzeugen. Gesagt – getan – abends, parallel zu einem der WM-Fußballspiele (Fußball hat nicht ganz eine so hohe Bedeutung für mich – deshalb kann ich mich nicht mehr genau daran errinnern, wer gegen wen spielte).

Top white = new Top("white");
Top black = new Top("black");
Relation wb = new Relation(white,black);
Relation ww = new Relation(white,white);
Relation wwwb = new Relation(ww,wb);
Relation wbww = new Relation(wb,ww);
Relation wbww_wwwb = new Relation(wbww,wwwb);
Relation wbww_wwwb_wb = new Relation(wbww_wwwb,wb);
PileEngine pe = new PileEngine();
pe.printTops(wbww_wwwb);

Die zweite Java-Klasse ist die Klasse PileEngine.java was etwas übertrieben ist. Derzeit enthält diese Klasse lediglich meine Methode traverseUp(), die sich rekursiv selbst aufruft.

An dieser Stelle möchte ich auf darauf hinweisen, das eine Pile-Relation intern nicht weiß, was Sie darstellt. Wenn ich das Konzept richtig verstanden habe wird durch die “äußeren Pile-Architektur-Layer” das Konzept des Beobachters realisiert. D.h. erst der Beobachter bestimmt die Bedeutung der Pile-Relation. Hierzu gibt es dann nach dem PileSpace die PileSpaceEngine, die PileEngine und den PileAgent (vgl. hierzu auch meine ersten Auseinandersetzungen mit Pile – Auf dem Weg zu Pile). Ich weise deshalb an dieser Stelle darauf hin, das es sich hier nur um eine Quick-And-Dirty-Learning-Implementation meiner Klassen handelt mit keinem Anspruch auf Vollständigkeit. D.h. ich lege hier im Moment noch keinen Wert auf die explizite Trennung und die Terminologie Relation, Top, TerminalValue – ich vermische die Begriffe codetechnisch. Ich verzichte auch bewußt auf die Darstellung der Relationen als 2D-Koordinaten, wie es der Code pilespace.cpp von Ralf umsetzt (vgl. auch JNI-Wrapper für Pile). Zum Erlernen und Verstehen, ist mir meine derzeitige Abbildung zugänglicher.

public void printTops(Relation r)
{
    traverseUp(r);
}
private void traverseUp(Relation r)
{
    Relation normative = r.getNormative();
    if(!normative.isTop())
    {
        traverseUp(normative);
    }
    else
    {
        System.out.println(((Top)normative).getSymbol());
    }
    Relation associatve = r.getAssociative();
    if(!associatve.isTop())
    {
        traverseUp(associatve);
   }
    else
    {
        System.out.println(((Top)associatve).getSymbol());
    }
}

Folgende Grafik gibt die Aufrufreihenfolge durch eine GIF-Animation wieder. Wenn Du auf die Grafik klickst, erhälst Du diese Animation als PDF-Dokument.

Nachstellung der traverseUp()-Methode für ein ASCII-A

Durch das Handeln (Programmieren) nach dem Sehen (Erkennen) drängen sich mir nun folgende Fragen auf, die ich versuchen werde künftig zu beantworten:

1. Wie kann eine PileEngine.assimilate()-Methode aussehen, welche eine Bitsequenz assimiliert, um eine PileRelation zu erzeugen?
2. Wie könnte eine PileEngine.query()-Methode aussehen, welche als Input eine Bitsequenz erhält und als Antwort eine Kontext-Information der Bitsequenz zurückgibt bzw. mit “Ja” oder “Nein” antwortet, ob die Pilerelation diese Bitsequenz überhaupt enthält erzeugen könnte.
3. Reicht für die beiden Operationen 1+2 die aktuelle Implememtierung meiner Klasse Relation.java aus? Ich vermute nicht, denn die Klasse enthält lediglich zwei Pointer: den NormativePointer (Np) und den AssociatePointer (Ap). Ich vermute einmal meine Struktur benötigt noch Top-Down / Parent-To-Child-Pointer.
4. Darüber hinaus stellt sich mir die Frage, inwiefern das “Setzen einer Relation” in einer Pile-Relationsstruktur verglichen werden kann mit dem “Treffen einer Unterscheidung im Raum” nach Spencer-Brown. Denn: das Vollziehen des Prozesses der Unterscheidung schafft eine Form. Das Setzen einer Relation innerhalb einer Pile-Relation schafft ebenfalls etwas Neues. Eine Pile-Relation hat ebenfalls “zwei Seiten”: den NormativePointer und den AssociatePointer. Evtl. sind diese mit dem “marked” und “unmarked” Space nach Spencer-Brown vergleichbar?

So, dann fehlen ja nur noch die Java-Klassen zum download. Du findest sie hier: JPile-TraverseDemo. Pile ruleZ!