Die Aufbau-Hierarchie bietet auf den ersten Blick keine großen Überraschungen. Die spannende Frage steckt hier in der Legende: Lohnt es sich, die Organisationseinheiten innerhalb eines Unternehmens als unterschiedliche Typen zu modellieren (wie hier geschehen mit den Typen „Business Unit“, „Bereich“ und „Abteilung“)? Oder genügt uns ein generischer Typ namens „Organisationseinheit“
Das kommt darauf an, ob es uns wichtig ist ganz einfach alle Objekte dieser Typen isolieren zu können. Wenn wir z.B. immer wieder Abfragen haben, die auf alle Abteilungen (mit bestimmten weiteren Eigenschaften) filtern, dann ist eine solche Unterteilung sinnvoll. Umgekehrt ist die Frage ob wir in unserem Knowledge Graphen nur unser eigenes Unternehmen, mit einer einheitlichen hierarchischen Einteilung abbilden wollen oder ob wir eine größere Menge von Unternehmen modellieren. In diesem Fall wird es wahrscheinlich schwierig eine einheitliche Nomenklatur zu finden – nicht jedes Unternehmen hat Business Units, viele große Unternehmen haben eigene Bezeichnungen für die verschiedenen Hierarchie-Ebenen.
Wenn wir uns für unterschiedliche Typen entscheiden, dann ist eines wichtig: wir müssen die Teil-von-Hierarchie sauber von der Typen-Hierarchie trennen. Wir dürfen nicht der Versuchung erliegen die unterschiedlichen Typen von Organisationseinheiten einander unterzuordnen (siehe links).
Dass alle konkreten Abteilungen – wie wir oben in der Netz-Darstellung oben sehen – unter Bereichen aufgehängt sind, also jede Abteilung Teil eines Bereiches ist, bedeutet nicht, dass der Typ „Abteilung“ ein Untertyp oder, anders ausgedrückt, Spezialfall des Typs „Bereich“ ist. Werfen wir die Typ-Hierarchie und die Teile-Hierarchie durcheinander, kommen wir mit unseren Abfragen ganz schnell in Teufels Küche.
Hier bietet sich eine einfache Nagelprobe an. Eine saubere Typ-Hierarchie kann immer auf folgende Weise gelesen werden: [Ein beliebiges konkretes Objekt] ist ein(e) [sein Typ], ist ein(e) [jede Obertyp]. Z.B. „Die ST-F&E-Antrieb ist eine Abteilung, ist eine Organisationseinheit“ – beide Aussagen sind korrekt. In unserer fehlerhaften Typenhierarchie würden wir lesen: „ST-F&E-Antrieb ist eine Abteilung, ist ein Bereich, ist eine Business Unit, ist eine Firma“.
Nehmen wir an, wir haben uns für das differenzierte Modell entscheiden – mit einer entsprechenden Typen-Hierarchie. Die nächste Frage ist: Wollen wir für auch entsprechend differenzierte Relationen einführen? Unser erstes Modell kennt nur eine Relation, nämlich „hat Teilorganisation“ bzw. „ist Teilorganisation von“ – diese kann zwischen beliebigen Objekten vom Typ „Organisation oder Organisationseinheit“ gezogen werden. Welchen Grund kann es geben, spezifischere Relationen wie „BU umfasst Bereich“, „Bereich ist enthalten in BU“, „Bereich umfasst Abteilung“ etc. einzuführen?
Ein möglicher Grund ist mehr Kontrolle. Wenn wir schon über das Schema unseres Graphen verbieten wollen, dass beispielsweise Zyklen entstehen (s.u.), dann ist sind unterschiedliche Relationstypen, die immer nur zwischen einer Ebene der Organisationshierarchie und der nächsten gezogen werden können, ein Mittel dagegen.
Wir handeln uns damit allerdings viele neue Relationstypen ein. Hier ist es wichtig, dass unsere Knowledge-Graph-Plattform auch Hierarchien auf Relationstypen und abstrakte Relationen unterstützt. So können wir unsere neuen, ebenen-spezifischen Relationstypen alle dem allgemeinen Typ „hat Teilorganisation“ unterordnen und bei Abfragen, die z.B. die gesamte Organisation nach unten oder oben traversieren, diese (abstrakte) Oberrelation abfragen.
Was haben wir gesehen? Wir wollen grundsätzlich immer „sparsam“ sein in unserer Modellierung und nicht mehr Objekt- und Relationstypen als unbedingt nötig einführen. Zusätzliche Typen geben uns andererseits mehr Kontrolle, schon auf der Schema-Ebene. Das ist ein Konflikt, den wir nicht auflösen können. Hier müssen wir den für unseren Knowledge Graphen besten Kompromiss finden.
Im nächsten Schritt führen wir Mitarbeiter in unseren Knowledge Graph ein, das wird eine Reihe von neuen Fragen mit sich bringen… „stay tuned“