© korkey, Pixelio.de

Plattform für Kollaboration und Wissensmanagement – das klingt anspruchsvoll. Kann man mit solcher Software auch praktische Probleme lösen? Das fragte sich die Redaktion der “Linux Technical Review” und wagte einen spannenden Selbstversuch.

Die Pioniere des Rock\’n\’Roll waren Vorbilder: Chuck Berry etwa, eine Leitfigur der 60er Jahre, ohne den die Beatles nach eigenem Bekunden niemals angefangen hätten und dessen Songs die frühen Stones nachspielten. Oder Buddy Holly, von dem sich die Beatles direkt ihre spätere Besetzung abschauten – Lead- und Rhythmusgitarre, Bass und Drums.

Die Beatles und die Stones polarisierten ganze Fan-Generationen: Hier die Anhänger der ungeschliffenen, vermeintlich authentischeren Stones mit ihrem Bad-Boys-Image, der vielleicht besseren Live-Performance, den hörbaren Wurzeln in Blues und Hillbilly. Dort die adrett gekleideten Pilzköpfe, die bessere Studioband, die in der Anfangszeit mehr Selbstkomponiertes vorzuweisen hatte und dabei einen weicheren Pop-Ton traf, auf den sie zunächst Schlagertexte sang.

Die beiden Antipoden in den Jugendjahren des Rock vergrößerten beständig ihre Einflussreiche (“Beatlemania”), wirkten auf Dutzende nachfolgende Bands, die sich untereinander wiederum ähnelten oder kontrastierten, die kooperierten und konkurrierten, die selbst Nachfolger hervorbrachten und ihrerseits als Vorbilder späterer Generationen fungierten.

Vernetzt

Wer ein wenig vor sich hin skribbelt, um sich dieses Geflecht der gegenseitigen musikalischen Einflüsse zu verdeutlichen, der zeichnet unwillkürlich ein Netz. Dessen Knoten bilden die Namen der Bands und dessen Kanten symbolisieren verschiedene Beziehungen wie etwa “war Vorbild für”, “war Konkurrent von” oder “war Gegenspieler von”. Auf dieser Ebene, auf der allein die Bandnamen Protagonisten sind, gerät die Darstellung noch recht abstrakt, doch lässt sie sich leicht konkretisieren, indem man den Knoten Belege anhängt: etwa MP3-Musikbeispiele, biografische Texte, Tourneetermine oder auch Musikvideos (Abbildung 1). Der Fachjargon nennt diese greifbaren Details, die sich dem abstrakteren Geflecht der Grundideen zugesellen, auch adressierbare Informationen. Das Meer solcher Fakten erhält plötzlich eine Struktur, die Verknüpfung verwandelt Information in Wissen.

Abbildung 1: Ein Einblick in die Musikszene der 60er Jahre: Wer wirkte stilbildend, wer beeinflusste wen? Unwillkürlich entsteht ein Netz.

Topic Maps

Ein solches Skribble, wie es hier mit Blick in die Geschichte der Rockmusik zustande kam, taugt zu weit mehr als nur zu einer beliebigen Ideenskizze. Wenn man es ein wenig formalisiert, führt es tatsächlich zu ausgewachsenen Methoden der Wissensrepräsentation, genauer zu Spielarten semantischer Netze. Gemeinsam ist ihnen, dass ihre Knoten aus Begriffen und die Maschen aus Beziehungen bestehen, verschieden sind der Grad der Formalisierung und die exakte Art des Materials, das sie verweben.

Eine Unterart solcher Netze nennt sich Topic Maps. Die Topics sind dabei ganz allgemein die Gegenstände (Subjects) oder Themen eines Wissensgebiets im weitesten Sinn, die als Netzknoten dienen. Die Kanten bilden Beziehungen (Associations) zwischen diesen Topics. Die angehängten Dokumente, die dem oft abstrakten Topic konkrete Information hinzufügen, heißen Occurrences (Vorkommen), sie finden sich auf einer zweiten Ebene unterhalb der Topics.

Die Topics gehören ebenso wie die Verbindungen bestimmten Typklassen an und die Occurrences können vordefinierte Rollen ausfüllen (Abbildung 2). Mit einem Blick auf die Anfangsbuchstaben der Begriffe Topics, Associations und Occurrences und mit dem konfuzianischen Begriff für den rechten Weg im Hinterkopf entstand das Wortspiel “Tao der Topic Maps” [1].

Abbildung 2: Die Trennung in zwei Layer: Topics und adressierbare Informationsressourcen bilden einen der Knackpunkte des Topic-Map-Modells.

Informationswissenschaftlich betrachtet gehören die Topic Maps in dieselbe Großfamilie wie Indexe und Thesauri. Auch in einem Index findet sich das Grundmuster wieder: Die Stelle der Topics nehmen dort Terme ein, die allerdings alle vom selben Stichwort-Typ sind, die Occurrences heißen hier Fundstellen und es gibt auch hier die – allerdings einzige und starre – Relation “Stichwort verweist auf Fundstelle”. Indexe gibt es seit Urzeiten, bekannt ist, dass bereits die Bibliothek des Assyrerkönigs Assurbanipal (685 bis 627 vor unserer Zeitrechnung) über einen Katalog – sprich Index – verfügte.

Ahnengalerie

Der Thesaurus geht als Nachfahre des einfachen Index einen Schritt weiter. Er verwendet ein festgelegtes Vokabular und erlaubt statt nur einer festen mehrere hierarchische Assoziationen in seiner Begriffsordnung: etwa “ist Oberbegriff von” (Broader Term), “ist Unterbegriff von” (Narrower Term), zuweilen auch “steht in Beziehung zu” (Related Term) oder “wird benutzt für” (Used for). Der Begriff Thesaurus wurde seit dem 18. Jahrhundert allgemein für Wissensspeicher oder im linguistischen Sinn für eine Wortschatzsammlung verwendet. Die weitere Bedeutung im Bereich des Information Retrieval geht auf eine Arbeit von Hans Peter Luhn von 1957 zurück.

Die nächste Entwicklungsstufe repräsentieren die Ontologien, die ebenfalls auf Termen und deren Beziehungen fußen, aber nicht auf wenige hierarchische Relationen beschränkt sind, sondern frei gestaltbare Begriffsbeziehungen kennen. Außerdem ermöglichen Ontologien, die man immer in einer eigenen Beschreibungssprache wie OWL [2] notiert, maschinelles Schlussfolgern. So lassen sich aus den beschriebenen Fakten und Relationen neue Aussagen gewinnen.

Dafür leitet Software auf der Grundlage der formalen Logik automatisch Implikationen ab wie: Wenn alle Laubbäume sommergrün sind und wenn Pappeln Laubbäume sind, dann müssen Pappeln im Sommer grün sein. Das einfache Beispiel mag banal klingen, tatsächlich aber ist das maschinelle Schlussfolgern ein Grundbaustein der Künstlichen Intelligenz und des Semantic Web. Der Begriff der Ontologie ist der Philosophie entlehnt, die Informationswissenschaft gebraucht ihn seit den 1980er Jahren.

Topic Maps sind in diesem Umfeld ein verwandtes Werkzeug für den Umgang mit solchen Wissensordnungen. Sie helfen derartige Strukturen flexibel zu modellieren (so können sie auch Ontologien oder auch Thesauri darstellen). Sie gestatten die Suche nach darin enthaltenen Informationen, teils mit Hilfe von Abfragesprachen, ähnlich wie in einer Datenbank. Auch erlauben Topic Maps automatisches Schließen und eröffnen die Möglichkeit, verschiedene Darstellungen (Maps) zu verschmelzen.

Sprachstandards

Die Theorie der Topic Maps entwickelte sich in den 90er Jahren des letzten Jahrhunderts als Wissenschaftler das Problem untersuchten, wie sich elektronische Indexe verschmelzen lassen. Einen Meilenstein setzte dann der ISO-Standard für Topic Maps ISO/IEC 13250 [3] zur Jahrtausendwende. Heute existieren verschiedene standardisierte Beschreibungsmöglichkeiten, allen voran der XML-Dialekt XTM [4]. Noch im Entstehen begriffen sind dagegen die Topic Map Constraint Language (TMCL, [5]) und die Abfrage-sprache TMQL (Topic Map Query Language, [6]), apostrophiert als “SQL für Topic Maps”.

Reines XML ist für menschliche Editoren allerdings nicht sonderlich intuitiv. Besser geeignet sind tabellarische oder grafische Editoren. Die gibt es auch unter Linux, beispielsweise Wandora [7] oder TMNav aus dem TM4J-Projekt [8]. Ein verwandtes Tool aber fällt aus dem Rahmen, denn es hat viel hochfliegendere Pläne: Deepamehta [9].

Kühne Vision

Es gibt keine Dateien mehr und damit auch keine Verzeichnisse und Unterverzeichnisse. Es existiert nur noch ein einziges Fenster – und das hat keine Menüs. An die Stelle der Elemente der vertrauten Benutzerschnittstelle treten Topics und ihre Verbindungen. Nicht das Speicherformat Datei steht im Zentrum der Darstellung, sondern stattdessen der Sinnzusammenhang.

Was logisch zusammengehört, muss der Anwender nicht mehr an vielen Stellen zusammenklauben, sondern bekommt es bereits verbunden präsentiert. Das ist das visionäre Ziel des Open-Source-Projekts Deepamehta. Genaueres dazu verrät der Kasten “Visionäre Wissensverwaltung”, in dem der Deepamehta-Mitbegründer und Lead Architect Jörg Richter das Konzept vorstellt. Man muss sich aber gar nicht sofort an die größten Ziele wagen, es geht auch eine Nummer kleiner. Deepamehta, das sich im Untertitel selbst als “Semantic Desktop” oder “Plattform für Kollaboration und Wissensmanagement” bezeichnet, taugt nämlich durchaus auch als grafischer Topic-Map-Editor für fast beliebige Zwecke.

Visionäre Wissensverwaltung

Was machen die Benutzerinterfaces heutiger Computer falsch? Schließlich präsentieren sie doch die vielfältigsten Informationen in ihren Ordnern und Fenstern. Ihr Handicap ist, dass sie um Netzwerkprotokolle und Dateiformate herum konstruiert sind: Für E-Mail gibt es einen POP/IMAP/SMTP-Client, fürs Web einen HTTP-Client, zum Schreiben einen Texteditor und so weiter. Viele Anwendungen beanspruchen zudem einen exklusiven Bildschirmbereich, benutzen ein individuelles Kategoriensystem und bieten wenig Möglichkeiten, ihre Inhalte mit denen anderer Anwendungen zu verknüpfen. Auf der Strecke bleibt der innere Zusammenhang der Informationen, verloren geht der Kontext, der sie verbindet. Fokus auf den Kontext Das Gegenteil davon nimmt sich Deepamehta vor, nämlich die anwendungszentrierte Denkweise durch ein Paradigma abzulösen, das den Kontext in den Mittelpunkt rückt. Alles spielt sich in einem Fenster ab, das alle Informationen enthält, die für die Lösung eines bestimmten Problems gerade nötig sind. Die Anwendungen müssen ihre Funktionen und Daten dafür von der Visualisierung entkoppeln (ganz ähnlich wie bei SOA-Anwendungen). Das heißt aber nicht, dass alle vorhandenen Anwendungen neu zu programmieren sind, denn ihre oft genutzten Funktionen sind bereits heute in der Regel über APIs erreichbar. Man denke etwa an das Java-Mail-API, die Open-Source-HTML-Engines Webkit und Gecko oder Tiny MCE als Web-basierten Wysiwyg-Editor. Deepamehtas Zielgruppe sind in erster Linie so genannte Wissensarbeiter, und in deren Tätigkeit lassen sich leicht bestimmte Grundmuster ausmachen, die der neue Desktop bedienen muss. Die Adressaten haben es immer mit Informationen zu tun – Text, Bild, Audio oder Video -, die sie erzeugen, einholen oder neu kombinieren, versionieren, kategorisieren und archivieren. Diese Grundfunktionen sind bereits in der Deepamehta-Plattform integriert und stehen den Nutzern und allen darauf aufbauenden Anwendungen konsistent zur Verfügung. In der Praxis Der Deepamehta-Bildschirm besteht in der Praxis aus einem einzigen Fenster (Abbildung 6). Es ist nie von anderen Fenstern überlagert. Der Arbeitskontext ist stets als Ganzes in Form einer Topic Map auf dem Bildschirm dargestellt. Ein Topic ist beispielsweise eine E-Mail, eine Webseite oder ein Kontakt. Assoziationen repräsentieren den Bedeutungszusammenhang. Gleichzeitig zeigt dasselbe Fenster Detailinformationen zu den Topics an, etwa den Text einer E-Mail. Die lässt sich wie alle anderen Inhalte auch an Ort und Stelle editieren und verschicken. Abbildung 6: Das gegenwärtige User-Interface zeigt Aufgaben durch Anwendungen (links), mit Deepamehta steht der Anwendungskontext im Mittelpunkt (rechts). Die verknüpften Topics repräsentieren jede Art Information. Ein paar standardisierte Typen bringt der neue Desktop dafür bereits mit, darunter »Person«, »E-Mail« oder »Kalender«. Spezielle Typen definiert der Anwender selbst. Der Nutzer ordnet sich seine Topics räumlich an und schafft dabei eine Struktur ähnlich einer Mindmap, die nach und nach wächst. Wird der Bildschirm zu unübersichtlich, blendet der Nutzer Dinge aus, die er im Moment nicht braucht. Später kann er sie wieder hervorholen, auch in einem anderen Kontext. Der Nutzer muss nie speichern, es bleibt einfach alles da. Um viele Topic Maps zu organisieren, richtet sich der Nutzer Workspaces ein. Shared Workspaces erlauben es vielen Anwendern, gemeinsam an Inhalten zu arbeiten. Java-Entwicklern steht ein Framework zur Verfügung. Damit können sie den Topics weitere Kommandos hinzufügen. Dafür hinterlegen sie zu einem Topic-Typ eine Java-Klasse, in der sie Hooks definieren, um auf bestimmte Anwender- oder Systemereignisse zu reagieren. So kann etwa ein Appointment-Topic (Teil der Kalender-Awendung) auf die Verschiebung eines Termins damit reagieren, dass er allen Teilnehmern eine Benachrichtung schickt. (Jörg Richter)

Dabei implementiert Deepamehta einerseits nicht alle Features des geltenden ISO-Standards (zum Beispiel lassen sich mit ihm keine Scopes und keine Rollen definieren, weder für Topics noch für Occurrences), es geht aber andererseits über die ISO-Norm hinaus. Denn normalerweise verweisen Topics ja nur auf Dinge oder Ideen und kennen außer einem oder mehreren Namen nur einen unverwechselbaren Subject Identifier – in der Regel einen URI, der es erlaubt, auch unterschiedlich benannte Topics zusammenzuführen, wenn sie auf denselben Gegenstand verweisen.

In Deepamehta geraten Topics dagegen zu einer Art Mini-Objekt, das der Anwender mit zusätzlichen Eigenschaften versehen darf. Im ersten Beispiel könnte ein Deepamehta-Topic vom Type »Band« etwa das Gründungsjahr und die Namen der Musiker zusätzlich als Properties besitzen. Es würde damit nicht nur auf die anhängenden Daten (Occurrences) verweisen, sondern gleich ein eigenes Informationshäppchen transportieren.

Konkurrent RDF

Name und Gründungsjahr wären typische Metadaten, wie sie für digitalisierte Texte, Bilder oder Videos etwa der Standard Dublin Core [10] definiert. Auch wie derartige Daten über Daten den beschriebenen Objekten zuzuordnen sind, ist durch Standards festgelegt. Eine weit verbreitete Norm dafür ist das Resource Description Framework (RDF), das zum Ende des vergangenen Jahrhunderts parallel zu den Topic Maps im Rahmen des W3C entstand. Es formuliert in einer genau definierten Weise Aussagen über Dinge als so genannte Triples aus Subjekt, Prädikat und Objekt, ähnlich der natürlichen Sprache.

Eine Aussage, die eine Topic Map mit zwei Topics und einer Verbindung beschreibt, lässt sich ebenso als RDF-Triple formulieren. Aus Topic 1 »die Beatles«, Topic 2 »die Rolling Stones« und der Association »waren Gegenspieler von« macht RDF: Die »Beatles« (RDF-Subjekt, Gegenstand der Aussage) »waren Gegenspieler« (RDF-Prädikat oder Eigenschaft des Triple) »der Rolling Stones« (RDF-Objekt, Wert des Prädikats). RDF-Modelle lassen sich ähnlich wie Topic Maps validieren, durchsuchen oder in automatische Schlüsse einbeziehen.

Beide, RDF und das Topic-Map-Projekt, nahmen erst spät voneinander Notiz und als sie die Überschneidungen und Ähnlichkeiten entdeckten, waren die Standards bereits durch die ISO beziehungsweise das W3C verabschiedet [11], sodass neben technischen auch politische Argumente gegen eine Vereinigung sprachen. Inzwischen gibt es für RDF ebenfalls eine XML-Repräsentation namens RDF/XML [12], auch die bereits erwähnte Ontologie-Beschreibungssprache OWL basiert auf RDF.

Zwar sind die Ziele beider Projekte nicht genau deckungsgleich, aber die Ähnlichkeiten lassen sich nicht übersehen und so haben Forscher nicht nur immer wieder versucht Topic Maps in RDF abzubilden und umgekehrt, sondern auch die beiden Technologien irgendwie zu verheiraten. Genau das ist auch das Motiv der Topic-Map-Erweiterungen in Deepamehta. Das Integrationsbemühen ist dabei beileibe kein Einzelfall, im Gegenteil: Dem möglichen Synergieeffekt einer solchen Fusion spürte bereits eine ganze Reihe von Projekten nach, [13] gibt einen Überblick.

Im Selbstversuch

Wozu aber taugt das Tool nun ganz praktisch? Weil die Organisation einer Zeitschriftenproduktion auch sehr viel mit Informationsverwaltung zu tun hat, wagte die Redaktion der Magazin-Schwester “Linux Technical Review” den Selbstversuch und nutzte Deepamehta testweise für die Planung der aktuellen Ausgabe zum Thema “Migration”.

Das brachte einige interessante Erfahrungen. Schon während der ersten Schritte behinderte die Tester jedoch ein Manko, dass bei freier Software leider eher Regel als Ausnahme ist: Die häufig fehlende oder grob lückenhafte Dokumentation. Für Deepamehta gibt es einen User Guide [14], der brauchbar die elementare Bedienung erläutert, und es gibt eine Dokumentation des Java-API für Entwickler. Was man dazwischen sucht, fehlt.

Was ist mit den bereits vordefinierten Topic-Typen? Welche gibt es und welche Eigenschaften haben sie? Welche Assoziations-Typen bringt Deepamehta schon mit und wie soll der Anwender sie verwenden? Was bedeuten die Fehlermeldungen und wie begegnet man ihnen am besten? Wie wäre eine komplexere Suchanfrage zu formulieren? Auf diese und viele weitere Fragen gibt es kaum Antworten, oft bleibt wenig mehr als das Studium der mitgelieferten Beispiele, aus denen sich das eine oder andere abschauen lässt.

Deepamehta-Praxis

Wer sich über diese Hürde gekämpft hat, darf losgehen. Für die redaktionelle Planung bietet sich eine Themenlandkarte an, die fast von allein entwickelt, wer das Problemfeld grafisch darzustellen versucht und sich dabei von ein paar Ankerpunkten zu abgeleiteten Fragen hangelt. Beim Stichwort Migration etwa ging die Redaktion von rechtlichen, wirtschaftlichen, strategischen und ganz praktischen Fragen aus und dröselte dann die damit verbundenen Probleme weiter auf: Was für rechtliche Stolpersteine kann es geben? Wie berechnet der Anwender den wirtschaftlichen Nutzen? Ist es strategisch klug, vom Mainframe zum Linux-Cluster zu migrieren? Wie gelangt der Admin von Active Directory zu LDAP? (Abbildung 3)

Abbildung 3: Eine Themenlandkarte entsteht fast von allein, wenn der Deepamehta-Benutzer – ausgehend von ein paar Kernpunkten – die Fragestellung immer weiter verfeinert. Das Panel rechts listet die Details zu dem markierten Topic, etwa seine Properties.

Die Grundbausteine (Topics) einer solchen Karte sind Stichworte zum Thema Migration. Jedes Stichwort kann auf geplante Artikel (Occurrences) zu seinem Gegenstand verweisen, die ihrerseits einen bestimmten Status haben. Jeden Artikel beschreiben Metadaten wie Autor, Titel, Umfang oder verschiedene Termine, die mit Deepamehta gleich als Eigenschaften in den Topic implantierbar sind. Während für die thematischen Ecksteine der per Default vorhandene Universal-Topic verwendbar ist, muss für die Artikel ein spezieller Typ her.

Praktisch erledigt ein Redakteur dies, indem er die Typ-Definition selbst als Topic Map anlegt, wobei sich die Metadaten-Eigenschaften über spezielle, bereits vordefinierte Assoziationen anflanschen lassen (Abbildung 4). Im selben Schritt kann er gleich noch Untertypen ableiten, die die drei Status repräsentieren, die ein Artikel annehmen können soll: »angefragt«, »bestätigt« oder »abgesagt«, ausgezeichnet in den Ampelfarben.

So weit, so klar. Wer aber ein wenig mit diesem Redaktionssystem en miniature arbeitet, stellt schnell fest, dass es noch lange nicht alle Informationsbedürfnisse erfüllt. So möchte der Ausgabenplaner zu einem bestimmten Zeitpunkt beispielsweise wissen, wie viele Artikel mit zusammen wie vielen Seiten er bereits fest zugesagt im Kasten hat, denn natürlich gibt es dafür ein Soll. Er muss außerdem im Blick behalten, ob und welche Beiträge den vereinbarten Abgabetermin bereits überschritten haben. Genauso ist es für die Planung bedeutsam, wie viele Beiträge mit wie vielen Seiten etwa morgen oder am Freitag zu erwarten sind und manches andere Detail mehr.

Abbildung 4: Topic-Typen definieren selbst eine Topic-Map. Hier der Typ Artikel mit Metadaten-Eigenschaften.

Das bisherige Modell kann jedenfalls etliche Anfragen der skizzierten Art nicht oder nicht unmittelbar befriedigen, weil Deepamehta nicht darauf eingestellt ist, direkt nach Properties von Topics zu suchen und weil es die im Rahmen einer Suche gefundenen Werte nicht aggregiert. Für die erste Aufgabe muss sich der Anwender erst eigene Suchtypen kreieren, indem er prinzipiell bereits vorhandene Komponenten mit speziellen Assoziationen verbindet.

Einfacher ist die Fahndung nach Topics. Eine Lösung ergab sich für die Tester also daraus, die Properties wenigstens teilweise in Topics zu verwandeln, die ihrerseits über bestimmte Relationen mit dem Artikel-Topic verbunden sind (Abbildung 5). Für einige der alten Properties bieten sich jetzt bereits vordefinierte Topic-Typen an, etwa der Typ »Person« für die Daten zum Autor. Danach ist es möglich, beispielsweise die ausstehenden oder bestätigten Artikel zu suchen oder auch diejenigen, die in einem bestimmten Zeitraum fällig werden.

Abbildung 5: Nachdem einige Properties in Topics verwandelt wurden, ergeben sich die gewünschten Suchmöglichkeiten.

Ein Nachteil dieses Vorgehens ist allerdings, dass die zusätzlichen Topics die Map aufblähen, was sie unübersichtlich macht. Auch die Suchergebnisse erscheinen nicht als der eigentlich benötigte einfache Zahlenwert, sondern als weniger gut zu überblickende Verknüpfungen (Abbildung 7).

Abbildung 7: Am 8. Mai werden zwei Artikel fällig, einer über die Migration zu Nagios von Julian Hein und einer über Terminalserver als Migrationshilfsmittel.

Diese Klippe umschifft vermutlich, wer anstelle des Deepamehta-Clients das zugrunde liegende Framework verwendet und selbst eine darauf aufbauende Webapplikation schreibt. Als Anregung hierfür gibt es bereits ein paar Referenzprojekte, die zeigen, dass der Topic-Map-Mechanismus in solchen Fällen für den Anwender völlig transparent werden kann, wie beispielsweise bei dem Kiez-Atlas Berlin [15].

Ausblick

Deepamehta hat noch viel vor. So ist ein Webseiten-Topic geplant, der selbstständig weitere Topics für jeden Link erzeugt, den der Benutzer von dort aus ansurft, PDFs sollen sich per Drag&Drop in eine Topic Map platzieren und Flash-Dokumente sich unmittelbar einbinden lassen, Latex-Dokumente werden direkt in der Map renderbar sein. Ein Twitter-Topic soll Follower-Netze visualisieren. Andere Anwendungen werden Inhalte aus Topic Maps via JSON-RPC-Services erreichen können. Der Import von CSV-Dateien soll automatisch Topics für jedes Element generieren und vieles mehr.

Noch wichtiger ist aber Folgendes: Die nächste Major-Release Deepamehta 3 will sich von den Topic-Objekten mit eigenen Properties wieder verabschieden und so, wie der Standard es vorsieht, nur noch Topic-Typen kennen. Die Erfahrung hat die Entwickler nämlich inzwischen gelehrt, dass der Kompromiss, zu dem die Properties zwingen, nur schwer lösbar ist: Zwar können sie viele Details auf engem Raum präsentieren, doch bilden sie keine semantischen Knoten und sind nicht wie Topics adressierbar.

So muss der Entwickler in jedem Fall in einen der sauren Äpfel beißen: Entweder verbessert er die Detaildarstellung, muss dann aber in Kauf nehmen, dass diese Details anders zu behandeln sind und nicht von den Eigenschaften spezieller Topic-Typen für denselben Zweck profitieren. Im anderen Fall hält er sich streng an ein standardkonformes Netz ohne Properties, bürdet dann aber seinem Anwender zusätzliche Aktionen im Interface auf, um die so modellierten Details sichtbar zu machen.

Fazit

Wer ein wenig Interesse dafür aufbringt, wie sich Wissen, immerhin der wichtigste Rohstoff unserer Zeit, verwalten lässt, für den ist Deepamehta sicherlich ein spannendes Projekt. Die Vision einer ganz neuen Benutzerschnittstelle fasziniert und auch für alle, die nach praktischen Lösungen auf dem Gebiet des Knowledge-Managements suchen, lohnt ein Blick auf das Tool.