WO2009049718A1

WO2009049718A1 - Computerimplementiertes system und verfahren zum strukturierten speichern von daten mindestens eines vordefinierten ablaufs

Info

Publication number: WO2009049718A1
Application number: PCT/EP2008/007286
Authority: WO
Inventors: Christof Dallermassl; Christian Erich Fessl
Original assignee: Unycom Information Technology Services Gmbh
Priority date: 2007-09-05
Filing date: 2008-09-05
Publication date: 2009-04-23
Also published as: DE102007042094A1

Abstract

Die Erfindung betrifft ein computerimplementiertes System und Verfahren zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs, um diese weiterverarbeiten zu können, bei dem der vordefinierte Ablauf mittels zweier Stati und einem Statusübergang definiert ist, von denen die Stati je als ein Informationsobjekt (58) und der Statusübergang als ein Verbindungsobjekt (56) abgebildet ist, das die beiden Informationsobjekte (58) verbindet.

Description

Computerimplementiertes System und Verfahren zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs

Beschreibung

Die Erfindung betrifft ein computerimplementiertes System und Verfahren zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs, um diese weiterverarbeiten zu können.

Allgemein betrifft die Erfindung das Gebiet der Erstellung, Verarbeitung, Strukturierung und Verteilung von Daten mindestens eines vordefinierten Ablaufs, welche in der Fachsprache auch als Workflow bezeichnet werden. Derartige vordefinierte Abläufe werden bei computerimplementierten Systemen in einer Vielzahl von Geschäftsorganisationen wie beispielsweise Versicherungsunternehmen, Finanzunternehmen oder allgemein Beratungsunternehmen genutzt, um standardisierte Abläufe innerhalb der zugehörigen Büroorganisation mit einem hohen Maß an Effizienz zu schaffen.

Ein wichtiges Anwendungsgebiet für die erfindungsgemäße Lösung ist jenes von Applikationen bzw. Anwendungen sowohl im klassischen PC-Bereich, als auch im Client-Serverbereich. Die Erfindung kommt insbesondere dort zur nutzbringend zur Anwendung, wo Daten in vordefinierten Abläufen mit aufeinanderfolgenden Schritten zu bearbeitet, auszutauschen bzw. weiter zu verarbeiten sind. Ein Beispiel für eine solche Applikation wäre ein Programm für ein Bestellwesen, bei dem die einzelne Bestellung von mehreren Sachbearbeitern aufeinanderfolgend zu bearbeiten ist. Dabei kann beispielsweise in einem ersten Schritt eine Prüfung auf Vorauszahlung, in einem zweiten Schritt eine Lagerabfrage, in einem dritten Schritt eine Warenbereitstellung, in einem vierten ein Verpacken und in einem fünften Schritt ein Prüfen und Versenden erfolgen. Bei jedem dieser Schritte sind im Austausch des bzw. der Benutzer mit dem zugehörigen computerimplementierten System insbesondere Daten abzulesen und einzugeben, welche den Gesamtablauf steuern, ihn dokumentieren und später zur Qualitätssicherung nachvollziehbar machen. Weitere Anwendungsgebiete sind Applikationen, welche rein auf Personalcomputern (PCs) betrieben werden und/oder Betriebssysteme für solche Personalcomputer und andere Rechner.

Es gibt typische Tätigkeiten, insbesondere in Programmanwendungen, die ein Benutzer eines computerimplementierten Systems üblicherweise ausführt. Zu die- sen typischen Tätigkeiten gehört es neue Informationen in Form von Texten, Bildern und Multimedia zu erstellen, Informationen zu bearbeiten, Informationen zu verteilen, Informationen zu suchen, zu sichten, zu ordnen und zu bewerten, Informationen strukturiert abzulegen und später wieder zu benutzen, Informationen untereinander zu verknüpfen, um damit Schlussfolgerungen und neues Wissen zu generieren, sowie schließlich veraltete, falsche oder nutzlos gewordene Informationen wieder zu löschen.

Zugleich stellt sich, insbesondere dann wenn ein Benutzer an einer neuen Aufgaben, einem neuen Thema oder einem neuen Projekt zu arbeiten beginnt, schon nach kurzer Zeit ein sehr bemerkenswertes Phänomen ein: Es entstehen immer mehr Dateien, die in unterschiedlichen Ordnern bzw. auch in unterschiedlichen Softwareprodukten bzw. Applikationen immer schwerer zu finden sind. Es wird für den Benutzer zugleich immer schwieriger, die einzelnen Dateien logisch miteinander zu verknüpfen, und in eine Beziehung zueinander zu bringen. Noch schwieri- ger wird es, wenn in einem Projekt eine Vielzahl von standardisierten Abläufen abzuarbeiten und datentechnisch zu verwalten ist.

Benutzer von heute bekannten computerimplementierten Systemen zum strukturierten Speichern von Informationen erhalten insbesondere keinen Überblick, was sie bereits gesehen haben und was noch nicht. Sie erhalten keinen Hinweis, welche die relevanten Informationen sind und welche für sie nicht relevant sind. Sie erhalten keinen Überblick über bereits gesehene Informationen, die aber in der Zwischenzeit wieder geändert wurden. Sie haben keine Unterscheidungsmöglichkeit zwischen Dokumenten, die aktuell sind, und jenen die schon veraltet sind, und sie haben keine Möglichkeit zu erkennen, welche Personen man fragen oder um Hilfe bitten könnte.

Um diese Probleme zumindest annähernd zu bewältigen, ist es bekannt einem Benutzer einzelne Softwareprodukte in Form von „Insellösungen" bereitzustellen, mit denen er beim Ablegen, Strukturieren und Wiederfinden seiner Daten und Do- kumente unterstützt wird. Diese Softwareprodukte berücksichtigen teilweise auch die laufende Nutzung der Daten durch die Benutzer. Die vielen, im Grunde genommen voneinander aber unabhängigen Einzelsysteme bilden dabei eine Informationstechnologie-Landschaft, in der die „Insellösungen" nur auf komplizierte, umständliche Art und Weise Daten miteinander austauschen können. So bedarf heutzutage z.B. bereits der aufeinanderfolgende Zugriff auf Daten eines ersten

Arbeitsablaufes der Kundenverwaltung und Daten eines anderen zweiten Arbeitsablaufes der Lagerverwaltung oft verschiedener Anwendungsprogramme, die sich in der Regel nicht untereinander austauschen können. Wir nennen dieses Phänomen „Informationsbruch".

Die heutigen Daten von Arbeitsabläufen sind auf vielen einzelnen Systemen verteilt und es ist nahezu unmöglich, komplexere Abfragen und Auswertungen einfach und ohne Programmieraufwand über einzelne Systeme und deren Systemgrenzen hinweg durchzuführen. Schon gar nicht ist es möglich, die Ergebnisse einheitlich in Form einer einzigen Tabellen, einer Graphik oder eines Berichtes darzustellen. So sorgt beispielsweise die Frage: „Welche Benutzer hat an wen innerhalb eines Arbeitsablaufs zusätzlich e-Mails erstellt und versendet?" in einer IT-Abteilung eines Unternehmens zunächst für Nervosität und anschließend zu hektischem Programmieren auf jedem der einzelnen Systeme. Einen informationsbruch gibt es insbesondere auch zwischen den lokalen Daten (beispielsweise Detaildaten zu einem einzelnen Schritt eines Arbeitsablaufs), die sich auf einer Festplatte eines Arbeitsplatzrechners befinden, und den zentralen Daten (beispielsweise Formulare zu einem Arbeitsablauf), die sich in einem Intra- net oder allgemein auf einem beliebigen Server befinden. Diese Daten stehen oft in Bezug zueinander (z.B. wurde eine e-Mail eigentlich innerhalb eines Arbeitsablaufs geschrieben), doch können in sehr vielen Systemen diese Beziehungen nicht modelliert und damit auch nicht genutzt werden (so stehen die e-Mails z.B. nur in einem e-Mail-Programm zur Verfügung, nicht aber in einem Lagerverwal- tungsprogramm).

Es wäre im Gegensatz zur heutigen Situation sehr zeitsparend, wenn nicht nur die Dokumentation von Arbeitsabläufen erleichtert würde, sondern auch ein Zusammenhang zwischen den in den einzelnen Schritten verarbeiteten Daten und den eigentlichen Ablaufinformationen von Arbeitsabläufen auf einfache Weise hergestellt werden könnte.

Insbesondere vernachlässigen viele der heute bekannten Softwareprodukte den Aspekt, dass sie von vielen Benutzern gleichzeitig oder für gleiche Aufgabenstel- lungen genutzt werden. Dabei wäre es oft wünschenswert, wenn einem Benutzer erkennbar wäre, ob z.B. ein anderen Mitarbeiter im Unternehmen ähnliche Aufgabenstellungen innerhalb von Arbeitsabläufen vorliegen hat.

Ferner haben viele der heute bekannten Softwareprodukte einen großen, auf den ersten Blick aber gar nicht erkennbaren Nachteil: Diese Softwareprodukte merken sich nicht, welche Tätigkeiten ihre Benutzer im Laufe der Zeit mit welchen Daten durchgeführt haben. So ist es beispielsweise nicht möglich, in einem System eine Suche in all jenen Dokumenten durchzuführen, die ein Benutzer bereits einmal gesichtet hat oder die sich nach dem Sichten inzwischen wieder verändert haben. Auch ergibt sich bei bekannten Softwareprodukten das Problem, dass man bei der Abarbeitung von Arbeitsabläufen einem derart festen Schema folgen muss, dass es nicht möglich ist, z.B. eine kleinen „Umweg" zu gehen oder ein paar informelle Zusatzinformationen anzugeben. Bereits ein kleiner Hinweis wie „wichtig!" kann in der Regel einem Datenfeld nicht hinzugefügt werden. Eine solche einfache Handlung, die in der realen Welt durch aufklebbare Notizzettel möglich wird, ist in computerimplementierten Systemen und Verfahren in der Rege! nicht oder nur rudimentär vorhanden.

In ähnlicher Weise können bei bekannten Softwareprodukten einzelne Themen oder Bereiche in Arbeitsabläufen nicht einfach miteinander zusammengehängt oder gruppiert werden. Bestehende Zusammenhänge werden dadurch nicht nutzbar oder gehen als Information wieder verloren.

Der Erfindung liegt die Aufgabe zu Grunde, ein computerimplementiertes System und Verfahren zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs bereit zu stellen, bei dem die oben genannten Probleme überwunden sind. Insbesondere sollen mit dem System und Verfahren Softwareprodukte für eine Vielzahl von Benutzern bereitgestellt werden, die sehr kurze Datenbank- zugriffszeiten aufweisen und innerhalb von Geschäftsapplikationen eine große Menge an Daten von Arbeitsabläufen handhaben können, ohne dass der oben beschriebene Informationsbruch auftritt.

Die Aufgabe ist erfindungsgemäß mit einem computerimplementiertem System nach Anspruch 1 gelöst. Ferner ist die Aufgabe mit einem computerimplementierten Verfahren nach Anspruch 9 gelöst. Vorteilhafte Weiterbildungen der Erfindungen sind in den abhängigen Ansprüchen beschrieben.

Bei dem erfindungsgemäßen computerimplementierten System bzw. Verfahren zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs, um diese weiterverarbeiten zu können, ist der vordefinierte Ablauf mittels zweier Stati und einem Statusübergang definiert, von denen die Stati je als ein Informationsobjekt und der Statusübergang als ein Verbindungsobjekt abgebildet ist, das die beiden Informationsobjekte verbindet.

Dabei geht die Erfindung von einer objektorientierten Betrachtung nicht nur von Daten innerhalb eines computerimplementierten Systems aus, sondern bezieht diese Betrachtungsweise auch auf den Ablauf bzw. den erfindungsgemäß so genannten Lifecycle, also den Lebenszyklus, eines Objektes. Der Lebenszyklus beschreibt jenen Zyklus, den jedes Objekt durchlebt. Er beginnt mit der „Geburt" des Objektes und endet mit dessen „Tod". Die „Geburt" findet in Form der Erstellung eines neuen Objekts im erfindungsgemäßen System statt. Während des „Lebens" erfährt das Objekt die unterschiedlichsten Modifikationen, die sich erfindungsgemäß insbesondere aufgrund seiner Fähigkeiten ergeben. Der Tod des Objektes tritt schließlich dadurch ein, dass dieses endgültig aus der Datenbank gelöscht wird. Einen solchen Lebenszyklus muss erfindungsgemäß jedes Objekt durchleben. Zugleich gibt es Objekte, deren Lebenszyklus muss (zumindest abschnittsweise) nach einem klar definierten Weg ablaufen. Diesen definierten Weg nennen wir schlicht "Ablauf oder „Workflow". Ein solcher "Ablauf ist gemäß der Erfindung zunächst als eine Menge von Stati beschrieben, die das zugehörige Objekt wäh- rend seines Lebens einnehmen kann, und durch eine Menge an Übergängen, die den Wechsel von einem Status zu einem anderen beschreiben. Die Übergänge sind dabei erfindungsgemäß selbst Objekte, nämlich solche, die zwei oder mehr der Stati verbinden. Es wird so gemäß der Erfindung auch der "Ablauf objektorientiert im computerimplementierten System realisiert, wodurch eine Datenbasis- struktur entsteht, die viele vorteilhafte Möglichkeiten der Weiterverarbeitung dieser Daten bietet. Diese Möglichkeiten werden nachfolgend noch genauer erläutert.

Erfindungsgemäß vorteilhaft kann bei dem computerimplementierten System und Verfahren das einzelne Informationsobjekt und/oder das einzelne Verbindungsob- jekt während des Betriebs des computerimplementierten Systems mindestens eine Fähigkeit (wir nennen dieses prinzipielle Merkmal Capability) annehmen und diese Fähigkeit auch wieder ablegen.

Insbesondere kann vorteilhaft das einzelne Informationsobjekt und/oder das ein- zelne Verbindungsobjekt die Fähigkeit annehmen und ablegen, gerichtet zu werden, abgesichert zu werden, bewertet zu werden, gewichtet zu werden, eine Information zu tragen, seine Änderung nachzuvollziehen, auf seine Änderung überwacht zu werden und/oder einem Ablauf zu unterliegen.

Ferner ist bevorzugt das einzelne Informationsobjekt und/oder das einzelne Verbindungsobjekt durch Annehmen und Ablegen von Fähigkeiten während des Betriebs des computerimplementierten Systems für seine Aufgabe angepasster gestaltet (wir nennen dieses prinzipielle Merkmal Evolution) worden, insbesondere zu einem andere Objekte enthaltenden Objekt.

Die Eigenschaft und/oder Fähigkeit stellt dabei vorzugsweise eine Anpassung einer allgemeineren Eigenschaft bzw. Fähigkeit dar.

Alternativ oder zusätzlich kann das einzelne Informationsobjekt und/oder das ein- zelne Verbindungsobjekt eine Eigenschaft und/oder eine Fähigkeit tragen, welche eine Zusammenstellung mehrerer allgemeinerer Eigenschaften bzw. Fähigkeiten darstellt.

Vorteilhaft ist ferner bei dem erfindungsgemäßen computerimplementierten Sys- tem und Verfahren das einzelne Informationsobjekt und/oder das einzelne Verbindungsobjekt dazu eingerichtet, dass es während des Betriebs des computerimplementierten Systems seine Nutzung protokolliert (wir nennen dieses prinzipielle Merkmal Usage).

Schließlich ist vorteilhaft das einzelne Informationsobjekt und/oder das einzelne Verbindungsobjekt dazu eingerichtet, dass es gemäß seinem vordefinierten Ab- lauf, der angenommenen Fähigkeit, der Art seiner Zusammenstellung aus mehreren Objekten, der Art der Zusammenstellung mehrerer allgemeiner Eigenschaften und/oder seiner protokollierten Nutzung geordnet werden kann (wir nennen dieses prinzipielle Merkmal Swarm).

Nachfolgend wird ein Ausfϋhrungsbeispiel der erfindungsgemäßen Lösung anhand der beigefügten schematischen Zeichnungen näher erläutert. Es zeigt:

Fig. 1 ein erstes Schaubild zum so genannten prinzipiellen Merkmal Capability, Fig. 2 ein zweites Schaubild zum so genannten prinzipiellen Merkmal Capability, Fig. 3 ein Schaubild zum so genannten prinzipiellen Merkmal Evolution, Fig. 4 ein erstes Schaubild zum so genannten prinzipiellen Merkmal Composition, Fig. 5 ein zweites Schaubild zum so genannten prinzipiellen Merkmal Composition, Fig. 6 ein drittes Schaubild zum so genannten prinzipiellen Merkmal Composition, Fig. 7 ein erstes Schaubild zum so genannten prinzipiellen Merkmal Connection, Fig. 8 ein zweites Schaubild zum so genannten prinzipiellen Merkmal Connection, Fig. 9 ein erstes Schaubild zum so genannten prinzipiellen Merkmal Usage, Fig. 10 ein zweites Schaubild zum so genannten prinzipiellen Merkmal Usage, Fig. 11 ein drittes Schaubild zum so genannten prinzipiellen Merkmal Usage, Fig. 12 ein viertes Schaubild zum so genannten prinzipiellen Merkmal Usage, Fig. 13 ein erstes Schaubild zum so genannten prinzipiellen Merkmal Swarm, Fig. 14 ein zweites Schaubild zum so genannten prinzipiellen Merkmal Swarm und Fig. 15 ein Schaubild zum so genannten prinzipiellen Merkmal Socializing.

Ein Ausführungsbeispiel eines erfindungsgemäßen computerimplementierten Systems und Verfahrens zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs, um diese weiter verarbeiten zu können, ist in Form eines objektorientierten Datenbank-Softwareprodukts gestaltet, das auf einem Spei- chermedium, wie beispielsweise einem Speicherchip eines Servers oder Personalcomputers oder einem tragbaren Datenträger, abgespeichert ist. Das System und Verfahren stellen in Kombination mit einem Server und/oder Personalcomputer eine lauffähige Softwareanwendung bereit.

In dem System und Verfahren sind sämtliche Informationen ausgehend von Ba- sisobjekten (welche wir als Base Objects bezeichnen) strukturiert, denen je eine eindeutige Kennung zugewiesen ist, die je computerimplementiert gespeichert werden können, die je auf eine computerimplementierte Anfrage hin antworten können und von denen während des Betriebs des computerimplementiertes Systems mindestens ein Basisobjekt mindestens eine Fähigkeit (welche wir als Ca- pability bzw. Capabilites bezeichnen) annehmen und eine Fähigkeit auch wieder ablegen kann.

Bei dieser Festlegung von Basisobjekten ist das einzelne Basisobjekt eine unteilbare Einheit, welche gewisse Fähigkeiten hat, die es erwerben und verlieren kann. Wichtig ist dabei, dass das einzelne Basisobjekt nicht etwa eine Eigenschaft oder eine Methode zugeordnet hat, sondern eine Fähigkeit. Ferner ist wichtig, dass es die Fähigkeit nicht nur annehmen, sondern auch während des Betriebs des computerimplementiertes Systems wieder ablegen kann. So ist es erfindungsgemäß möglich, eine Menge von Fähigkeiten zu definieren, die unterschiedlich genutzt, mit einander kombiniert, erworben und wieder verloren werden können. Diese

Menge von Fähigkeiten ist zunächst unabhängig von den Basisobjekten, so dass sich innerhalb der Softwarestruktur des computerimplementierten Systems eine neuartige Situation ergibt. Innerhalb der Struktur werden nämlich die Basisobjekte nicht derart programmiert, dass ihnen Fähigkeiten fest zugeordnet sind, sondern derart, dass ihnen Fähigkeiten zugeordnet werden können. Die eigentlichen Fähigkeiten sind „parallel" in einem Katalog von Fähigkeiten programmiert, so dass die modulierten Objekte erst durch eine Zuordnung einzelner Fähigkeiten an die Basisobjekte entstehen. Diese Zuordnung kann nun zum einen vom Programmierer des computerimplementierten Systems und Verfahrens vordefiniert sein oder zum anderen von dessen Benutzer vorgenommen werden. Damit ergibt sich eine erheblich größere Variabilität des erfindungsgemäßen computerimplementierten Systems und Verfahrens.

Alternativ oder zusätzlich sind bei dem Ausführungsbeispiel des computerimple- mentierten Systems und Verfahrens zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs, um diese weiter verarbeiten zu können, sämtliche Informationen ausgehend von Basisobjekten strukturiert, denen je eine eindeutige Kennung zugewiesen ist, die je computerimplementiert gespeichert werden können, die je auf eine computerimplementierte Anfrage hin antworten können und von denen mindestens ein Basisobjekt als Verbindungsobjekt genau zwei oder auch mehr andere Basisobjekte verbinden kann.

Mit den derart definierten Verbindungsobjekten (welche in ihrer Grundstruktur einem Basisobjekt entsprechen und dadurch z.B. die gleiche Programmiergrundla- ge aufweisen wie Objekte, die eine Information tragen) wird erfindungsgemäß insbesondere erreicht, dass ein einzelnes Basisobjekt ein anderes Basisobjekt kennt. Ferner bilden die derart definierten Verbindungsobjekte eine Verbindungsfunktion (welche wir als Connection bezeichnen), mittels der im Grunde genommen Alles untereinander eine Verbindung eingehen und miteinander in Verbindung stehen kann. Diese Verbindungsfunktion ist besonders bevorzugt in Anlehnung an die erstgenannte Ausführung gemäß der Erfindung realisiert, indem einem Basisobjekt die Fähigkeit zugeordnet worden ist, eine Verbindung herstellen zu können.

Alternativ oder zusätzlich ist bei dem Ausführungsbeispiel ein computerimplemen- tiertes System und Verfahren zum strukturiertem Speichern von Daten eines vordefinierten Ablaufs vorgesehen, um diese weiterverarbeiten zu können, bei dem sämtliche Informationen ausgehend von Basisobjekten strukturiert sind, denen je eine eindeutige Kennung zugewiesen ist, die je computerimplementiert gespeichert werden können, die je auf eine computerimplementierte Anfrage hin antwor- ten können und von denen mindestens ein Basisobjekt während des Betriebs des computerimplementierten Systems ein anderes Basisobjekt verändern kann. Mit dieser Funktionalität, welche ebenfalls bevorzugt durch Zuordnung der Fähigkeit „kann andere Basisobjekte verändern" auf der Grundlage von ein und denselben Basisobjekten programmiert ist, kann insbesondere erreicht werden, dass ein Objekt eine aktive Funktion innerhalb der Softwarestruktur einnimmt und dennoch mit den gleichen Grundprinzipien arbeitet wie auch alle anderen Basisobjekte. So kann beispielsweise die Funktionalität innerhalb eines Softwareproduktes realisiert werden, dass ein Basisobjekt durch seine Nutzung und sein Verhalten ein anders Basisobjekt verändert.

Mit der derartigen Struktur von Basisobjekten sind bei dem Ausführungsbeispiel einige grundlegende prinzipielle Merkmale in dessen Softwarestruktur implementiert, welche dann die Grundlage für eine langfristig kostengünstige und qualitativ hochwertige Software liefern. Diese prinzipiellen Merkmale sind wie folgt:

Es gibt eine Menge von Fähigkeiten, die unterschiedlich genutzt, miteinander kombiniert, erworben und wieder verloren werden können (dieses prinzipiellen Merkmal nennen wir, wie oben bereits erwähnt, Capabilities).

Eine Weiterentwicklung der Objekte, insbesondere ausgehend von Basisobjekten erfolgt basierend auf Variation und Selektion, um insbesondere eine bessere Anpassung an die zu lösenden Aufgaben zu erzielen (dieses prinzipiellen Merkmal nennen wir Evolution).

Sämtliche komplexen Strukturen werden durch Zusammenlegung von einfachen Objekten aufgebaut, ohne dass dabei Objekte definiert werden könnten, die nicht auf zumindest einem Basisobjekt zugeordneten Fähigkeiten beruhen (dieses prinzipiellen Merkmal nennen wir Composition).

Ferner können vorteilhaft alle Objekte untereinander eine Verbindung eingehen und miteinander in Verbindung stehen. Dabei werden auch die Verbindungen auf der Grundlage eines Basisobjektes programmiert (dieses prinzipielle Merkmal nennen wir, wie bereits erwähnt Connection).

Die Prozessstruktur des Ausführungsbeispiels wird vorteilhaft abgebildet, indem den Basisobjekten ein Lebenszyklus mit einem genau definierten Ablauf zugeordnet wird (dieses prinzipielle Merkmal nennen wir Lifecycle). Der vordefinierte Ablauf wird mittels zweier Stati und einem Statusübergang definiert, von denen die Stati und die Statusübergänge je als modifizierte Basisobjekte gestaltet sind. Dies geschieht derart, dass die Stati je als ein eine Information tragendes Objekt und die Statusübergänge als ein Verbindungsobjekt gestaltet sind, das die beiden Informationsobjekte verbindet.

Die Basisobjekte können ferner die Fähigkeit aufweisen, dass ihr Verhalten Spuren hinterlässt und wie bereits oben angedeutet, Auswirkungen auf andere Basis- Objekte hat (dieses prinzipielle Merkmal nennen wir Usage).

Ein weiteres prinzipielles Merkmal umfasst, dass eine Menge von mehreren bis sehr vielen Basisobjekten selbst eine Fähigkeit annehmen (und diese auch ablegen) kann, wodurch diese Menge sich wie ein aus der Natur bekannter Schwärm verhält (dieses prinzipielle Merkmal nennen wir Swarm).

Ferner können alle Objekte mit ähnlichen Eigenschaften, ähnlichem Verhalten oder ähnlichen Problemen sich zusammenfinden und eine Gemeinschaft bilden, um gemeinsame Probleme besser zu lösen und dadurch Vorteile zu erlangen (dieses prinzipielle Merkmal nennen wir Socializing).

Ferner kann zwischen den Basisobjekten ein Austausch von Information abgebildet werden, wodurch sich die die Fähigkeiten und Möglichkeiten ebenfalls vervielfachen (dieses prinzipielle Merkmal nennen wir Communication). Darüber hinaus können die untereinander kommunizierenden Einheiten auch in die Lage versetzt werden auf ein gemeinsames Ziel hinzuarbeiten (dieses prinzipielle Merkmal nennen wir Collaboration).

Diese prinzipiellen Merkmale sind oben noch vergleichsweise allgemein formuliert, entwickeln aber in Ihrer Anwendung auf die Softwareentwicklung des Ausführungsbeispiels einen erheblichen Nutzen, weil insbesondere folgende Aspekte innerhalb von dessen Softwarestruktur sehr einfach abgebildet werden können: Aus mehreren einfachen Objekten können sehr leicht komplexe Objekte zusam- mengesetzt werden. Ein Objekt kennt andere Objekte. Ein Objekt kann sich mit anderen Objekten verbinden. Ein Objekt kennt seinen aktuellen Zustand. Ein Objekt kann durch einen wohl definierten Ablauf geleitet werden. Ein Objekt merkt sich seine Nutzung und wer es in welcher Form benutzt hat. Ein Objekt kann von seinem Benutzer einen Mehrwert erhalten. Viele Objekte bilden gemeinsam eine Menge von zunächst gleichwertigen Objekten, auf die beliebige Mengenoperationen angewendet werden können. Jedes Objekt in der Menge kann durch seine Nutzung und sein Verhalten die Menge und die darin enthaltenen Objekte beeinflussen und verändern. Mehrere Objekte in einer Menge können zu Gruppen zu- sammengefasst werden. Die Menge kann explizite und implizite Ordnungen mit den darin enthaltenen Objekten bilden. Ähnliche oder zusammengehörende Objekte in einer Menge können sich zusammenfinden. Benutzer von ähnlichen Objekten können sich ebenfalls zusammenfinden, um gemeinsam an gleichen Problemen zu arbeiten und diese effektiver zu lösen. Durch Zufall können ferner unerwartete Vorteile entstehen und sich Synergien entwickeln.

Nachfolgend werden die oben genannten prinzipiellen Merkmale im Hinblick auf deren Realisierung im Ausführungsbeispiel näher erläutet.

Das prinzipielle Merkmal Capabilities beschreibt eine Menge von unterschiedli- chen Fähigkeiten, die jedem Basisobjekt in beliebiger Kombination zugeordnet, von diesem beliebig genutzt und schließlich auch wieder verloren werden können. Die einzelne Fähigkeit ist eine Art Basismethode, die allgemein beschrieben und von anderen Fähigkeiten unabhängig ist. Die einzelne Fähigkeit ist daher programmtechnisch eigenständig und jedes Basisobjekt kann sich diese Fähigkeit in beliebiger Variation zu Eigen machen. Diese Strukturierung eines computerimp- lementierten Systems und Verfahren ist insbesondere vorteilhaft, weil es dadurch möglich wird, einem Objekt, beispielsweise einem Datenobjekt innerhalb einer Datenbank, sowohl während der Programmierung des Softwareproduktes als auch bei dessen Verwendung einem beliebigen Datenobjekt eine weitere Fähigkeit hinzuzufügen und diese auch wieder zu nehmen. So kann es beispielsweise sinnvoll sein die Fähigkeit "kann eine Notiz tragen" hinzuzufügen und umgekehrt kann es zur Vereinfachung der Programmierungs- oder Datenstruktur sinnvoll sein diese Fähigkeit dem Datenobjekt auch wieder zu nehmen.

Um einem Basisobjekt Informationen zuordnen zu können, wird diesem bevorzugt die Fähigkeiten zugeordnet: "Kann eine Eigenschaft (wir nennen diese Property) tragen" und/oder "Kann einen Inhalt (wir nennen diesen Content) tragen". Eine zugeordnete Eigenschaft umfasst einen Namen der Eigenschaft und deren Wert oder Werte. Bevorzugte Eigenschaften sind es dass das Basisobjekt einen Namen tragen kann, es sich seinen Ersteller und sein Erstellungsdatum merken kann oder dass es einen Namen tragen kann, der mehrere Werte haben kann. Eine solche Eigenschaft ist beispielsweise vorteilhaft, um den Titel eines Objektes in mehreren Sprachen zur Verfügung zu stellen.

Weiter können auch Eigenschaften von anderen Basisobjekten während der Er- Stellung oder der Modifikation eines Softwareproduktes automatisch übernommen werden (wir nennen dies Derived Properties). Ferner können Eigenschaften von einem anderen Objekt besonders einfach gelesen werden (wir nennen diese Fo- reign Properties), da die Struktur der derartigen Eigenschaften einheitlich ist. Zusätzlich kann es beispielsweise einem Benutzer zur Laufzeit jeder beliebigen In- stanz jedes beliebigen Objektes erlaubt werden, neue (ggf. von ihm selbst defi- nierte Eigenschaften) hinzuzufügen und wieder wegzunehmen (wir nennen diese Free Defined Properties).

Jede Eigenschaft kann mit einem genau definierten Typ einer Benutzerschnittstel- Ie zum Betrachten oder Editieren des aktuellen Wertes der Eigenschaft gekoppelt werden. Dadurch steht eine vordefinierte Menge von Benutzerschnittstellen bzw. Eingabemöglichkeiten zur Verfügung_: deren Aussehen und deren Verhalten vom Typ der Eigenschaft selbst abhängig sind. So kann einer Eigenschaft vorteilhaft ein einfaches, einzeiliges Eingabefeld, ein regelbasiertes Eingabefeld das nur eine Zahl, ein Datum oder eine Uhrzeit erlaubt, ein mehrzelliges Eingabefeld, ein Eingabefeld für geschützte Eingaben (z.B. Passwörter), eine Auswahlmöglichkeit aus einer Liste (Select-box, Drop-down), eine Auswahlmöglichkeit aus einer Hierarchie (Taxonomy, Menü, Treeview) oder ein Eingabefeld für Bilder, Audio oder Videos zugewiesen werden.

Im Gegensatz zu dem mit einer Eigenschaft zugewiesenen Wert, wird mit der Fähigkeit "kann einen Inhalt (Content) tragen" ein Inhalt von beliebiger Form zugewiesen. Ein Beispiel für einen solchen Inhalt ist ein Text, ein Bild, ein Audio oder ein Video.

Eine weitere vorteilhafte Eigenschaft ist für ein Basisobjekt: "kann eine Ordnung tragen". Unter Ordnung wird dabei jede Zuordnung zu einem anderen Basisobjekt oder einer Menge von Basisobjekten verstanden, wobei, wie nachfolgend noch erläutert werden wird, diese Menge selbst als ein modifiziertes Basisobjekt defi- niert sein kann. Die erfindungsgemäß bevorzugte Ordnungsstruktur wird bei einer ersten Variante des Ausführungsbeispiels durch einfaches Verbinden eines Basisobjektes mit einem anderen Basisobjekt erzielt (wir nennen dies Connecting). Dabei ist bevorzugt die Verbindung selbst auch ein Basisobjekt, dessen herausragende Fähigkeit es ist, zwei andere Basisobjekte miteinander verknüpfen zu kön- nen. Die Möglichkeiten die sich daraus ergeben werden nachfolgend zum so genannten prinzipiellen Merkmal Connection noch genauer beschrieben. Eine weitere Variante des Ausführungsbeispiels besteht darin jedem Basisobjekt vom Benutzer private oder öffentliche Tags hinzufügen zu können. Die Tags bieten die Möglichkeit einer Beschlagwortung von allen Objekten (wir nennen dies Tagging). Die Anwendungsmöglichkeiten und die Nutzung solcher Tags auf den Basisobjekten werden nachfolgend noch genauer zum so genannten prinzipiellen Merkmal Usage beschrieben.

Alternativ oder zusätzlich können als weitere Variante, dass Objekte gemäß vor- gegebener Taxonomien oder Polyhierachien kategorisiert werden (wir nennen dies Classifying).

Eine weitere erfindungsgemäße wichtige Fähigkeit ist die Nachvollziehbarkeit. Gemäß einer ersten Variante kann vorteilhaft ein Basisobjekt die Fähigkeit haben einer Versionskontrolle unterworfen zu werden, sodass es möglich ist auf eine ältere Version zuzugreifen oder mehrere Versionen miteinander zu vergleichen (wir nennen dies Version Control). Die Versionskontrolle ergibt vorteilhaft eine Tabelle, die alle Versionen mit Bearbeiter und Datum beinhaltet und als History bezeichnet werden kann.

Als Verfeinerung wird bevorzugt ein so genannter Audit Trail erzeugt, der eine lückenlose Nachvollziehbarkeit aller durchgeführten Benutzeraktionen und Änderungen an einem Basisobjekt erlaubt. Dies ist erfindungsgemäß sehr einfach möglich, indem nach jeder Veränderung eines Basisobjektes automatisch eine neue Version gespeichert, insbesondere über ein Verbindungsobjekt mit der alten Version gekoppelt wird. Um die Datenmenge dennoch gering zu halten, wird ferner bevorzugt lediglich die Nutzung eines Basisobjektes mitgeschrieben (wir bezeichnen dies als Logging). Dieser Mitschrieb kann bevorzugt ebenfalls durch Ankoppeln der Änderungsinformation über ein Verbindungsobjekt an ein Basisobjekt erfolgen. Um Nachvollziehbarkeit zu gewährleisten wird bevorzugt auch eine Art "Frage" des Basisobjektes an seinen Benutzer möglich (wir nennen dies Confirming), beispielsweise wenn der Benutzer manuell einen Inhalt bestätigen muss. Diese Fähigkeit des Confirming ermöglicht es zu unterscheiden, ob ein Benutzer einen In- halt lediglich betrachtet oder diesen auch akzeptiert hat.

Die Basisobjekte können vorteilhaft auch einer Absicherung unterliegen. Dies ist insbesondere sehr einfach möglich, indem diese die Fähigkeiten der Sichtbarkeit und/oder Veränderbarkeit ihrer Informationen zugeordnet bekommen (wir nennen dies Access Rights und Access Control). Dabei werden vier Rollen von Benutzern unterschieden: Der Observer (er hat nur Lesezugriffe, er kann also Inhalte von Objekten nur betrachten, aber nicht ändern), der Contributor (er hat Lesezugriff und die Möglichkeit Informationen hinzuzufügen, indem er Verbindungen zu anderen Objekten erstellt, er darf aber nicht einzelne der Objekte selbst verändern), der Editor (er hat Lesezugriff und kann Informationen frei ändern, d.h. er kann die Eigenschaften und/oder den Inhalt von einzelnen Objekten verändern) sowie der Administrator (er hat Lesezugriff, kann Informationen frei ändern und die Möglichkeit Benutzer auf eine der vier Rollen zu verteilen). Dabei kann für jedes Basisobjekt jedem Benutzer genau einer Rolle zugeordnet sein. Diese Zuordnung findet bevorzugt wiederum über Verbindungsobjekte statt, wobei der einzelne Benutzer selbst dabei ebenfalls als Basisobjekt betrachtet wird. Wenn ein Benutzer für ein Basisobjekt keine Rolle zugeordnet hat, kann er dieses Basisobjekt auch nicht sehen und daher auch nicht benutzen.

Bevorzugt können ferner Informationen, die ein Basisobjekt beinhaltet signiert werden (wir nennen dies Signing), um sicherzustellen, dass sie nicht nachträglich verändert wurden. Die Signatur wird erfindungsgemäß bevorzugt über ein Verbindungsobjekt mit der Information des Basisobjektes (Property oder Content) verbunden und sichert auf diese Weise einen Veränderungsversuch ab. Auch können bevorzugt Informationen des Basisobjektes verschlüsselt gespeichert werden (wir nennen dies Encrypting). Besonders einfach ist dies möglich, indem am verschlüsselten Inhalt mittels eines Verbindungsobjektes eine Verbindung zu einem öffentlichen Schlüssel eines Schlüsselpaares eines Benutzers hergestellt ist, während ein privater Schlüssel des Schlüsselpaares mit dem Benutzer selbst gekoppelt ist.

Eine weitere vorteilhafte Fähigkeit ist jene, dass ein Objekt von all seinen Administratoren über bestimmte Zeiträume für alle anderen Benutzer auf sichtbar oder unsichtbar geschaltet werden kann. Besonders einfach ist dies zu realisieren, indem dem Objekt eine Angabe in Form eines Basisobjektes zugeordnet ist, wann das Objekt sichtbar ist und wann das Objekt unsichtbar ist. Unsichtbarkeit bedeutet dabei, dass das Objekt auch durch eine Suchefunktion nur von den Administratoren dieses Objektes gefunden werden kann. Wie in Fig. 1 veranschaulicht ist, ergeben sich insgesamt vier Möglichkeiten, wie die Sichtbarkeit eines Objektes gesteuert werden kann. Auf einem Zeitstrahl 10 ist dabei in einer ersten Möglichkeit ein Zeitpunkt 12 angegeben, zu dem das zugehörige Objekt sichtbar ist. Es folgt ein Zeitintervall 14, zu dem das Objekt sichtbar bleibt, bis zu einem Zeitpunkt 16, bei dem die Sichtbarkeit des Objektes wiederum gewechselt wird, sodass das Objekt zum nachfolgenden Zeitintervall 18 wieder unsichtbar ist. Entsprechend dieser Vorgehensweise kann in einer zweiten Möglichkeit ein Objekt für ein einzelnes Zeitintervall 14 auf unsichtbar geschaltet werden. In einer dritten Möglichkeit kann ein Objekt zu einem bestimmten Zeitpunkt 12 dauerhaft sichtbar gemacht werden, während schließlich gemäß der vierten Möglichkeit ein Objekt zu einem Zeitpunkt 16 dauerhaft unsichtbar gemacht werden kann.

Gemäß einer weiteren vorteilhaften Fähigkeit kann einem Basisobjekt eine Wertung beigefügt werden. Diese Wertung erfolgt vorteilhaft in Form einer Zahl die sich innerhalb eines systemweit einheitlichen und normierten Zahlenbereichs (bei- spielsweise 0 - 100) befindet. Vorteilhaft kann ein Benutzer ein Objekt beliebig oft bewerten. Zur Berechnung einer aktuellen Gesamtbewertung wird dann aber nur der letzte Wert jedes Benutzers herangezogen. Ältere Bewertungen können in Entsprechung der Nachvollziehbarkeit als Versionen eines Objektes hinterlegt werden, sodass erfindungsgemäß besonders vorteilhaft die Wertung selbst als ein Basisobjekt betrachtet und dargestellt wird. Auf diese Weise ist es insbesondere besonders einfach möglich, die Entwicklung der Bewertung eines Objektes über die Zeit erkennbar zu machen.

in Fig. 2 ist die Entwicklung der Bewertung eines derart modifizierten Basisobjektes veranschaulicht. Dabei ist über einer Zeitachse 20 in Richtung einer Bewer- tungsachse 22 die zeitliche Entwicklung der Bewertung des zugehörigen Objektes (nicht dargestellt) anhand einer Linie 24 veranschaulicht. Diese Art der Bewertung eines Objekts nennen wir Rating.

Als Alternative oder zusätzliche Bewertungsform, die in besonders einfacher Wei- se durch Anhängen als Basisobjekt an ein zu bewertendes (Basis-) Objekt angefügt werden kann, wird das so genannte Voting vorgeschlagen, bei dem gemäß einer Fragestellung bewertet wird, wobei die Auswahlmöglichkeiten genau vordefiniert sind und optional ein begrenztes Zeitfenster vorgegeben sein kann, in dem über das Objekt abgestimmt werden kann.

Ferner kann vorteilhaft ein Objekt mit einer Gewichtung vorgesehen sein, die manuell gesetzt oder automatisch berechnet werden kann. Beim manuellen Setzen eines Gewichtes kann auch zwischen einer eigenen privaten oder einer kumulierten, öffentlichen Gewichtung unterschieden werden. Das Gewichten (welches wir als Weighting bezeichnen) gibt nicht wie beim Rating eine Aussage über die Qualität des Inhaltes sondern informiert über die Relevanz eines Objektes.

Im Hinblick auf die Wertung eines Objektes kann ferner erfindungsgemäß vorteilhaft ein Objekt automatisch mit einer Maßzahl versehen sein, welche die Aktuali- tat bzw. den Neuheitswert eines Objektes angibt (wir nennen dies Aktualität). Um veraltete Objekte ferner leichter erkennen zu können, ist vorteilhaft eine regelmäßige automatische Prüfung der Aktualität von Objekten und eine Abfrage an die Benutzer bzw. Editoren eines Objektes sinnvoll, ob sie dieses Objekt als veraltet markieren möchten (wir nennen dies Outdating). Der aktuelle Datenbestand kann so von veralteten Daten unterschieden und ggf. durch Löschen veralteter Daten vergleichsweise klein gehalten werden.

Erfindungsgemäß vorteilhaft kann jedes Objekt auch mit einem Ablaufdatum versehen werden (wir nennen dies Expiring). Das Ablaufdatum kann bereits beim Erstellen eines Objektes vorgegeben sein und durch Modifikation des Objektes neu gesetzt werden. In Kombination mit Aktualität und Outdating kann das Ablaufdatum dafür sorgen, dass alte und selten genutzte Objekte als solche kenntlich gemacht werden.

Eine weitere wichtige Fähigkeit ist jene, dass ein Objekt bearbeitet werden kann. Diese Fähigkeit umfasst in einer ersten Variation das so genannte Locking und Unlocking, bei dem ein Objekt für andere Benutzer gesperrt bzw. entsperrt wird. Gesperrt ist dabei nicht das Betrachten selbst (siehe oben Visibility) sondern das Bearbeiten eines Objektes. Auch eine derart gesetzte erfindungsgemäße Sperre wird in Form eines Basisobjektes definiert und einem zu sperrenden (Basis-) Objekt zugeordnet. Die Sperre kann entsprechend automatisch nach einer gewissen Zeit der Inaktivität eines Benutzers aufgehoben oder aber manuell von einem Administrator freigeschaltet werden.

Eine weitere Funktion der Bearbeitung ist das so genannte Watching, bei dem ein Benutzer automatisch vom System informiert wird, wenn ein anderer Benutzer bestimmte Aktionen auf einem bestimmten Objekt ausführt.

Ferner besitzt jedes Basisobjekt des Ausführungsbeispiels die Fähigkeit, das jeder der genügend Zugriffsberechtigung besitzt, ein Basisobjekt neu erstellen und exis- tierende Basisobjekte modifizieren oder löschen darf (wir nennen diese eigentliche Art der Bearbeitung von Basisobjekten Editing).

Eine weitere erfindungsgemäße Fähigkeit, welche unter den Fähigkeiten-Komplex der Bearbeitbarkeit fällt, ist das so genannte Workflowable. Das zugehörige Basisobjekt hat dabei die Fähigkeit durch einen passenden Workflow bzw. Arbeitsablauf geleitet zu werden. Diese Fähigkeit umfasst zum einen_: dass sich das Objekt seinen aktuellen Status im Workflow merken kann und dass es den ihm zugeordneten Workflow kennt. Die Möglichkeiten und Anwendungen von Workflows auf Objekte werden nachfolgend zum prinzipiellen Merkmal Lifecycle noch genauer beschrieben.

Die oben genannten Fähigkeiten, „Informationen zu tragen", „zugeordnet zu werden", „seine Änderungen nachvollziehen zu können", „abgesichert zu werden", „bewertet zu werden" und/oder „bearbeitet zu werden", erscheinen auf den ersten Blick trivial zu sein, sind aber in den praktischen Anwendung von großem Vorteil. Da diese Menge an Fähigkeiten bei jedem Objekt jederzeit vollständig zur Verfügung gestellt werden und sofort in beliebiger Kombination genutzt werden kann, ergeben sich nicht nur bei der Programmierung sondern auch bei der eigentlichen Nutzung des computerimplementierten Systems gemäß dem Ausführungsbeispiel enorme Vorteile. Diese Vorteile ergeben sich insbesondere dann, wenn die einzelnen Aspekte einer Fähigkeit eines Objektes in Form von mit dem Objekt verbundenen Basisobjekten gestaltet werden. So kann beispielsweise die Fähigkeit eine Eigenschaft zu tragen, in Form eines Eigenschafts-Objekts an ein zu modifi- zierendes Objekt angehängt werden, sodass nachfolgend auf das Eigenschafts- Objekt selbst sämtliche der oben genannten prinzipiellen Merkmale angewendet werden können. Das Gleiche gilt beispielsweise für ein Wertungs-Objekt, welches ebenfalls auf einem Basisobjekt basiert und als solches an ein zu modifizierendes Objekt angehängt ist. Die Durchgängigkeit der derart definierten erfindungsgemäßen Struktur des computerimplementierten Systems bzw. Verfahrens ist dabei ein wesentlicher Kerngedanke.

Besonders vorteilhaft kann das mindestens eine Basisobjekt durch Annehmen oder Ablegen der mindestens einen Fähigkeit während des Betriebs des computerimplementierten Systems für eine Aufgabe angepasster gestaltet werden (wir nennen dies Evolution). Die Variation erfolgt dabei entweder manuell durch Programmierung oder automatisiert nach bestimmte Regeln, wobei die durch das prinzipielle Merkmal Capability zur Verfügung gestellten Fähigkeiten auf unterschiedlichste Art und Weise mit einem Basisobjekt kombiniert werden können. Dabei wird stufenweise von dem allgemeinen Basisobjekt ausgehend vorgegangen und es werden weitere Typen von Grundobjekten definiert, die einen bestimmten Nutzen optimal gewährleisten können. Durch anschließende Selektion dieser unterschiedlichen Grundobjekte werden sich all jene weiterentwickeln, die ihren Aufgaben am besten angepasst sind.

Nachfolgend werden Beispiele von Objekten des Ausführungsbeispiels vorgestellt, die sich durch bestimmte Kombinationen von Fähigkeiten ergeben. Sämtliche Ob- jekte basieren dabei auf der Grundstruktur eines Basisobjektes, welches nur die Möglichkeiten bietet, eine eindeutige Kennung zu tragen, computerimplementiert gespeichert zu werden und auf eine computerimplementierte Anfrage hin antworten zu können (wir nennen diese Art von Objekt „Base"). Dieser Objekttyp ist die kleinste gemeinsame Basis, die quasi ein "leeres Objekt" darstellt und noch keine weiteren Fähigkeiten besitzt. Das derartige Basisobjekt erhält erfindungsgemäß seine "Lebendigkeit" indem ihm für eine bestimmte Aufgabenstellung Fähigkeiten aus dem prinzipiellen Merkmal Capabilities zugeordnet werden.

Auf diese Weise ergeben sich neue Objekttypen, die bei entsprechend geringer Anzahl an Fähigkeiten noch grundlegender Art sind und daher hier als Grundobjekte bezeichnet werden. Einer dieser Grundobjekte ist der so genannte Container, ein Objekt das in irgendeiner Form Objekte "beinhalten" kann und diese Objekte hinzugefügt und entfernt werden können. In diesem allgemeinen Fall eines Containers kann das gleiche Objekt auch mehrfach hinzugefügt werden.

Im Gegensatz dazu entspricht ein so genannter Folder dem Ordner in einem bekannten Dateisystem und dient insbesondere der Strukturierung von Dokumenten, wobei jedes Objekt dem Folder nur einmal zugeordnet werden kann. Ferner ist im Folder definiert, welche Art von Objekt überhaupt hinzugefügt werden darf. Ein Folder kann weiter spezialisiert werden, indem die darin enthaltenen Objekte bestimmten Regeln unterliegen (wir nennen dies RuleBasedFolder).

Die Regeln, die das Einfügen, Modifizieren oder Löschen von Objekten in einen Container überprüfen, können in Form einer Fähigkeit abgebildet sein (beispielsweise in einer Skriptsprache formuliert sein), sodass es möglich ist, auch zur Laufzeit des computerimplementierten Systems individuelle und regelbasierte Folder zu erstellen.

Beispiele für derartig aufgabenbezogene Container und Folder sind eine so genannte Gallery, welche nur das Einfügen von Bildern oder Videos erlaubt, ein Glossary, in der Glossareinträge verwaltet werden können, eine Quicklist, in der kurzzeitig zu merkende Objekte abgelegt werden können, eine Tasklist mit Aufgaben, ein Kalender, in dem insbesondere die Kalendereinträge selbst als Aufgaben hinterlegt sind, oder ein Aggregator, der Informationen nach bestimmten Kriterien automatisiert sucht und in genau definierter Form (an eine Schnittstelle) nach außen zur Verfügung stellt.

Ferner werden als Grundobjekt, wie oben bereits erwähnt, Basisobjekte definiert, die Informationen in Form eines Inhaltes haben (Content). Darüber hinaus enthält vorteilhaft ein so genanntes Document unstrukturierten Inhalt wie z.B. eine Textdatei im Format eines Textverarbeitungsprogramms. Ein so genanntes Multidocument kann nur noch mehrere Objekte vom Typ Document beinhalten. Es können so zusammengesetzte Dokumente erstellt werden bzw. Dokumente können in mehrere Sektionen aufgeteilt werden. Eine weitere Verfeinerung von Multidocument ist das so genannte AlternativDocument, welches aufgrund bestimmter Regeln aus mehreren verfügbaren Dokumenten, die in unterschiedlichen Formaten vorhanden sind, nur jenes für die Anzeige wählt, das für den aktuellen Benutzer am besten geeignet ist. Beispielsweise können in einem AlternativDocument Informationen als Audio, Video oder Graphik enthalten sein, und einem Benutzer wird als Präferenz zunächst das Video gefolgt von der Graphik angezeigt. Auf diese Weise kann insbesondere auf unterschiedliche Lerntypen bei Benutzern eingegangen werden. Ein anderer Anwendungsfall wäre ein Bild, welches in unterschiedlichen Dateiformaten oder Qualitätsstufen gespeichert ist. Dabei hat ein Benutzer insbesondere die Möglichkeit zwischen Ladegeschwindigkeit und Qualität des Bildes zu wählen.

Ein so genanntes LanguageDocument ist eine ähnliche Spezialisierung wie das AlternativDocument, wobei das gleiche Dokument in gleichem Format aber in un- terschiedlichen Sprachen gespeichert ist. Das computerimplementierte System gemäß dem Ausführungsbeispiel liefert dem Benutzer dann automatisch jenes Dokument, das seiner voreingestellten Sprache entspricht.

Ferner sind erfindungsgemäß besonders einfach Objekte mit strukturiertem Inhalt zu verwalten (so genannte StructuredDocuments) deren Inhalt in einzelne Teile zerlegt ist, welche definiert gelesen und beschrieben werden können. So ist es erfindungsgemäß möglich, dass das computerimplementierte System über definierte Regeln selbst auch auf den Inhalt eines derartigen modifizierten Basisobjektes in Form eines Structured Document zugreifen kann. Besonders interessant ist diese erfindungsgemäße Ausgestaltung im Zusammenhang mit bereits heute be- kannten XML-Dokumenten. Formulare können damit ebenfalls strukturiert ausgefüllt und visualisiert werden.

Mittels BPEL (Business Process Execution Language) und der erfindungsgemä- ßen Vorgehensweise können Arbeitsabläufe bzw. Workflows selbst als ein modifiziertes Basisobjekt beschrieben werden, sodass auch auf einen derartigen Workflow alle oben beschriebenen prinzipiellen Merkmale angewendet werden können.

Ein erfindungsgemäßes, so genanntes Skript kann Programmcode zur Bearbeitung von Objekten innerhalb des computerimplementierten Systems beinhalten, sodass dieser Programmcode beispielsweise an einem Server des Ausführungsbeispiels ausgeführt werden kann.

Auch derzeit bereits in computerimplementierten Systemen verwendete Dateiformate, wie bei einer Tabelle in einer SQL-Datenbank oder einer e-Mail, können erfindungsgemäß in einem modifizierten Basisobjekt derart strukturiert abgebildet werden, dass sie mit derartigen Systemen besonders einfach ausgetauscht und dennoch innerhalb des computerimplementierten Systems besonders vorteilhaft verarbeitet werden können. Selbst Bearbeitungshilfen, wie eine Notiz, können grundsätzlich beliebig jedem Basisobjekt hinzugefügt werden und diese Hilfsmittel können weiter in Aspekte wie Frage, Antwort, Zustimmung und/oder Hinweis strukturiert werden.

Zusätzlich zu Objekten, die Inhalte haben können, sind bei dem Ausführungsbeispiel auch Objekte gebildet, die nur Eigenschaften haben können. Diesen Objekttyp nennen wir Attribute. Er kann weiter spezialisiert werden zu Objekttypen wie „Tag", „TagBundle" und „Classification". Bei einem Tag kann ein möglichst beschreibendes Wort an ein beliebiges Objekt angehängt werden, indem man die Capability Tagging dafür benutzt. Auf das einzelne Tag können dann sämtliche der oben genannten prinzipiellen Merkmale angewendet werden. Ein TagBundle ist ein Container, der mehrer Tags und auch TagBundles zusammenfasst. Eine Classification wird genau wie Tags behandelt, nur ist sie mittels gerichteter Verbindungen an das zugehörige (Grund-) Objekt gehängt und ferner selbst zu anderen Classifications verbunden, um eine Taxonomy abzubilden. Durch diese Art der Modellierung von Tags und Classifications als eigene Objekte treten diesbezügliche Unterschiede immer weiter in den Hintergrund.

Selbst der Zugriff auf einen anderen Server des computerimplementierten Systems mit unterschiedlichsten Protokollen kann mit derartigen Objekten gestaltet werden. Wir nennen einen derartigen Zugriff Remote, der allgemein nur den Namen des Servers, dessen IP-Adresse, den Port, das Protokoll und optional eine Benutzer-Authentifizierung beinhaltet.

Eine als Extemal bezeichnete Klasse von modifizierten Basisobjekten des Ausfϋh- rungsbeispiels erlaubt das Modellieren von externen Objekten, die sich aus unterschiedlichsten Gründen nicht innerhalb des erfindungsgemäßen Systems befinden können oder dürfen. Ein External beinhaltet einen Verweis auf das externe Objekt und Properties, die Informationen über das externe Objekt beinhalten. Mit einer derartigen Klasse können die oben genannten prinzipiellen Merkmale auch auf Objekte angewendet werden, die sich nicht innerhalb des erfindungsgemäßen Systems befinden. Damit ist die technische Möglichkeit geschaffen, die bisher starren Grenzen zwischen den Daten eines Servers, eines lokalen PCs und den Daten von Fremdsystemen aufzuheben. Auch das Arbeiten im Offline-Modus ohne Zugang zu einem Server ist erfindungsgemäß besonders einfach möglich, in- dem während dieser Arbeit modifizierte Basisobjekte generiert werden, die nachfolgend mit dem Server separat ausgetauscht werden können.

Selbst Applikationen, wie z.B. ein Flash, RCP oder Ajax-Anwendungen können mit ihrem Einstiegspunkt von einem erfindungsgemäßen Basisobjekt gestaltet wer- den. Daten und Applikationen können daher im Ausführungsbeispiel gleichwertig verwaltet und beliebig miteinander verknüpft werden. Auch kann damit die Appli- kation selbst unter eine Zugriffskontrolle gestellt werden. Damit kann dem einzelnen Benutzer oder einer Benutzergruppe der Zugriff (Aufruf) einer und/oder mehrere Applikationen erlaubt oder verweigert werden.

Gemäß einer weiteren vorteilhaften Ausgestaltung des Ausführungsbeispiels mit seiner im Wesentlichen nur durch Fähigkeiten definierten Objektstruktur sind ferner Objekte vorgesehen, die zwei Objekte miteinander verbinden. Bei diesen Ob- jekten, den so genannten Verbindungsobjekten, welche nach dem Prinzip Con- nection gebildet sind, werden „DirectedConnections" und „ParentChildConnecti- ons" unterschieden. Eine DirectedConnection enthält als Zusatzinformation zu einer Connection die Richtung, mit der die beiden Objekte verbunden sind. Eine ParentChildConncetion ist eine gerichtete Verbindung, die eine Hierarchie innerhalb einer Struktur ausdrückt. Die derart gebildeten Verbindungsobjekte können im Übrigen alle weiteren, oben bereits genannten Fähigkeiten annehmen und auch wieder ablegen, sodass sich entsprechend vielseitige Anwendungsmöglichkeiten ergeben.

Schließlich sind bei dem Ausführungsbeispiel Objekte vorgesehen, die Aufgaben verwalten können. Ein derart modifiziertes Basisobjekt ist beispielsweise ein Task, welcher eine Aktion, ein für die Ausführung derselben zuständiges Objekt und optional einen Zeitpunkt miteinander verknüpft. Ein UserTask ist ein modifiziertes Basisobjekt, welches eine Aktion, eine oder mehrere Personen und optional einen Zeitpunkt miteinander verknüpfen kann. Ein SystemTask dient zur Ausführung einer bestimmten Aktion zu einem definierten Zeitpunkt durch das System. Eine Spezialisierung eines derartigen SystemTask kann ein SearchAgent sein, der periodisch eine Suche nach bestimmten Kriterien durchführt und das Suchergebnis einem bestimmten Benutzer zur Verfügung stellt oder einem Aggregator für eine externe Verwendung des Suchergebnisses.

Zusammenfassend ermöglicht es das prinzipielle Merkmal Evolution aus recht einfachen Objektklassen mächtige Möglichkeiten zur Modellierung von verschie- densten Anwendungen zu schaffen. Einzelne Objektklassen können dabei vorteilhaft mit graphischen Hilfsmitteln gestaltet und implementiert werden. In Fig. 3 ist diese graphische Gestaltung von erfindungsgemäß modifizierten Basisobjekten veranschaulicht. Die Fig. 3 zeigt einen mit Bezugszeichen 26 bezeichneten Pool von Fähigkeiten für eine bestimmte Klasse an Objekten, aus dem ein Benutzer (durch Herüberziehen, so genanntes Drag-and-drop) jene Fähigkeiten auswählen kann, die das zu implementierende Objekt zur Erfüllung seiner Aufgabe ange- passter gestalten. Die einzelne Fähigkeit kann dabei dem Grundobjekt, vorliegend in Gestalt eines Folders 28, hinzugefügt werden. Dabei wird diese Fähigkeit mit- tels eines Verbindungsobjekts an das Grundobjekt angekoppelt. Die Fähigkeit selbst kann dann entsprechend weiter modifiziert werden. Die graphische Visualisierung der Objekte und deren Fähigkeiten erfolgt durch UML.

In dem derart visualisierten Klassendiagramm kann die Anzahl der jeweiligen In- stanzen aller Objekte anzeigt werden, wodurch erkennbar wird, welche Klassen oft benutzt werden und welche eher selten. Einzelne Klassen können vorteilhaft durch eine Import- oder Export-Funktion in das computerimplementierte System gebracht werden. Es kann eine Art Marktplatz für Klassen (insbesondere in einem allgemein zugänglichen Netzwerk beispielsweise dem Internet) zur Verfügung ge- stellt werden, wo neue Klassen oder ganze Gruppen von Klassenbibliotheken zum Tausch oder Handel angeboten werden.

Vorteilhaft kann das Basisobjekt auch eine Eigenschaft tragen, die selbst gemäß dem prinzipielle Merkmal Evolution eine Anpassung einer allgemeineren Eigen- schaft darstellt. Dazu wird die Eigenschaft der Objekte ebenfalls aus einem Basisobjekt innerhalb des computerimplementierten Systems definiert. Ein Klassenbaum für die Eigenschaften von Objekten (den Properties) kann wie folgt aussehen:

Property

SelectionProperty SingleSelectionProperty MultiSelectionProperty.

Property ist dabei die Basisklasse, welche die Grundfunktionen aller abgeleiteten Property-Klassen beinhaltet. SelectionProperty ist eine Spezialisierung dieser Basisklasse für die Verwaltung von Eigenschaften, die aus einer definierten Menge, beispielsweise einer Tabelle, zur Verfügung gestellt werden. SingleSelectionPro- perty und MultiSelectionProperty sind Spezialisierungen der SelectionProperty dahingehend, ob einer oder mehrere Werte gewählt werden können.

Das prinzipielle Merkmal Evolution lässt sich also bei dem Ausführungsbeispiel auch auf Fähigkeiten eines Objektes anwenden.

Ferner sind die Eigenschaften eines Objektes eng mit dessen Benutzeroberfläche bzw. User Interface gekoppelt, um zu erreichen, dass gleiche Eingaben, wie Text, Datum oder eine Auswahl immer gleich eingegeben werden. Das zugehörige Benutzer-Interface setzt sich daher aus jenen Objekteigenschaften zusammen, welche der Benutzer sehen oder editieren darf.

Mindestens ein Basisobjekt ist ferner aus mehreren Objekten zusammengestellt worden, die zusammen einen erhöhten Nutzen bereitstellen. Dieses prinzipielle Merkmal wird Composition genannt und findet insbesondere dahingehend Anwendung, dass aus mehreren verschiedenartigen Grundelementen ein erfindungsgemäßes Objekt zusammengestellt werden kann. Fig. 4 veranschaulicht einen derartigen Zusammenbau eines erfindungsgemäßen Objektes aus einzelnen Grundelementen.

Eine Tasklist 30 dient dabei zum Verwalten von Aufgaben und umfasst als Container mehrere Tasks 32, welche Anlagen (Attachment) 34, Notizen (Note) 36 o- der eine Bewertung (Review) 38 beinhalten können. Ferner kann an eine Anlage 34 ihrerseits eine Notiz 36 angehängt werden und an eine Bewertung 38 kann eine Frage (Question) 40 an einen anderen Benutzer angehängt werden.

In ähnlicher Weise kann gemäß Fig. 5 eine Diskussion (Discussion) 42 strukturiert werden, indem dieser mehrere Ordner (Folder) 44 zugeordnet werden, in denen sich Notizen 36 mit den Kommentaren der Benutzer befinden. An die Notizen 36 können dann Anlagen 34, weitere Notizen 36_: Bewertungen 38 oder Fragen 40 angehängt werden.

In entsprechender Weise kann auch ein Dokumentenraum (ein so genannter

DocSpace) einerseits sehr allgemein und andererseits für den einzelnen Benutzer speziell angepasst werden. Ein Dokumentenraum ist dabei ein Folder, in dem Benutzer ihre Ordner und Dateien innerhalb eines Projekts ablegen können. Dadurch werden Möglichkeiten des geordneten Zugriffs auf diese Daten und Möglichkeiten des Anbindens von Zusatzinformationen an diese Daten in nahezu beliebiger Form angeboten. Derartiges ist mit keinem der heutigen Dateisysteme möglich. Die Zusatzinformationen können vielfältig auch vom Benutzer selbst ausgewertet werden. Grundelemente wie Tasklist, Discussion und DocSpace können weiter in einen WorkSpace, also einem Arbeitsraum für bestimmte Benutzer, zusammen- gestellt werden, der schließlich in Ergänzung mit einem Kalender und einem Or- ganigramm zu einem Projektraum (einem so genannten ProjectSpace) erweitert werden kann. Projekte von mehreren Organisationen oder Bereichen können in einer Projektwelt (ProjectWorld) kombiniert und entsprechend auch von einzelnen Benutzern verwaltet werden.

Zusammenfassend können mit dem prinzipiellen Merkmal Compostion selbst komplexe Themen in kurzer Zeit und einfacher Weise strukturiert und dem computerimplementierten System und Verfahren zugänglich gemacht werden. Doch nur wenig definierte Bereiche eines Themas können in ihrer allgemeinen Form abgebildet und ggf. zu einem späteren Zeitpunkt detaillierter strukturiert werden. Dieses prinzipielle Merkmal der Composition eines Objektes aus mehreren Basisobjekten lässt sich erfindungsgemäß vorteilhaft auch auf die Eigenschaften eines Basisobjektes anwenden, indem diese computerimplementiert als einen Zusammenstellung mehrerer allgemeiner Eigenschaften dargestellt werden. So kann gemäß Fig. 6 in einfacher Weise aus einer Datumseigenschaft, einem DatePro- perty 46, und einer Zeiteigenschaft, einem TimeProperty 48, eine zusammengesetzte Eigenschaft in Gestalt einer DateTimePropery 50 gebildet werden. Diesem kann eine geographische Koordinate in Gestalt eines LocationProperty 52 nebengeordnet werden, welche dann zu einem so genannten DateTimeLocationProper- ty 54 kombiniert wird. Diese Eigenschaft kann beim Ausführungsbeispiel in einem einzigen Wert angeben, zu welchem Datum, zu welcher Zeit an welchem Ort ein Objekt erstellt worden ist.

Wie bereits oben erwähnt, ist mindestens eines der Basisobjekte als Verbin- dungsobjekt gestaltet, welches zwei oder mehr andere Basisobjekte verbinden kann. Dieses erfindungsgemäße prinzipielle Merkmal bezeichnen wir als Connec- ting, wobei beim Ausführungsbeispiel diese genannte Verbindungsfunktion eines Basisobjektes diesem als eine Fähigkeit zugeordnet ist. Mit Hilfe der derartigen Verbindungen können Objekte miteinander verknüpft, als Graphen strukturiert, geordnet und zueinander in Beziehung gebracht werden. Bei Verwendung der erfindungsgemäß bevorzugten Einschränkung, dass jedes Verbindungsobjekt immer genau zwei Objekte miteinander verknüpft, sind Hypergraphen nicht erlaubt. Jedoch ist es dennoch möglich zwei gleiche Objekte durch mehrere Verbindungsobjekte miteinander in eine stärkere Beziehung zu setzen. Hierzu ist in Fig. 7 der allgemeinste Fall einer Verbindung dargestellt, die mit einem (ausgehend von einem Basisobjekt gebildeten) Verbindungsobjekt 56 zwischen zwei (ausgehend von Basisobjekten gebildeten) Objekten 58 gestaltet ist. Das Verbindungsobjekt 56 wird dabei erfindungsgemäß auch als Connection bezeichnet.

Es entstehen auf diese Weise zwei unterschiedliche Typen von erfindungsgemäß modifizierten Basisobjekten, von denen der eine Typ als so genanntes Informati- onsobjekt im weitestgehenden Sinn eine beliebige Form von Information, wie beispielsweise ein Dokument, ein Bild oder eine Notiz enthält. Der Typ der Verbindungsobjekte ist im Gegensatz dazu darauf spezialisiert zwei andere Objekte (In- formations- oder Verbindungsobjekte) miteinander zu verbinden. Wie in Fig. 8 wei- ter veranschaulicht ist, können Informationsobjekte 58 selbst keine direkte Verbindung zu anderen Informationsobjekten 58 eingehen. Allerdings haben sie "Steckdosen" 60, an denen sich Verbindungsobjekte 56 "anstecken" können. Die Verbindungsobjekte 56 selbst haben zwei oder mehrere "Stecker" 62, die sich einzeln an einer "Steckdose" 60 eines beliebigen Objektes "anstecken" können, um eine Verbindung zwischen diesen beiden Objekten herzustellen. Ferner haben auch die Verbindungsobjekte 56 selbst "Steckdosen" 60, damit an ihnen andere Verbindungsobjekte 56 "anstecken" können.

Basierend auf den oben genannten prinzipiellen Merkmalen Capabilties, Evolution und Composition können die derart gebildeten Verbindungsobjekte sehr einfach selbst für unterschiedlichste Arten von Aufgaben angepasst werden. Insbesondere können die Verbindungsobjekte dabei die Fähigkeit annehmen und ablegen, gerichtet zu werden, abgesichert zu werden, bewertet zu werden, gewichtet zu werden, eine Information zu tragen, ihre Änderung nachzuvollziehen, auf ihre Än- derung überwacht zu werden und/oder einem Ablauf zu unterliegen.

Im Hinblick auf die Fähigkeiten abgesichert zu werden, bewertet zu werden, gewichtet zu werden, einen Information zu tragen, seine Änderung nachzuvollziehen, auf eine Änderung überwacht zu werden und/oder einem Ablauf zu unterliegen wird dabei auf die obige Erläuterung dieser Fähigkeit im Hinblick auf die allgemeinste Form eines erfindungsgemäßen Basisobjektes verwiesen.

Die Fähigkeit, dass ein Verbindungsobjekt eine Richtung erhalten kann ist so zu verstehen, dass mit der Richtungsangabe eines der verbundenen Objekte zum Ausgangspunkt und das andere Objekt zum Endpunkt dieser gerichteten Verbindung wird. Es können so erfindungsgemäß Baumstrukturen aufgebaut werden, in denen Kreisstrukturen nicht zugelassen sind, die aber eine Modellierung von Hierarchien erlauben. Dies ist insbesondere im Hinblick auf die Verwaltung von Dateisystemen oder Benutzergruppen interessant. Die derart gerichteten Verbindungen werden erfindungsgemäß auch ParentChildConnection genannt. Mit einer derartigen Art von Verbindung kann beispielsweise auch ein Hyperlink, wie man ihn aus dem Internet bzw. dem World-Wide-Web gewohnt ist, für das System und Verfahren des Ausführungsbeispiels gestaltet werden.

Durch so genannte SimilarityConnections können beim Ausführungsbeispiel fer- ner Objekte miteinander verbunden werden, die sich ähnlich in Bedeutung oder Inhalt sind. Ähnliches ist mit so genannten SeeAlsoConnections möglich, welche als gerichtete Verbindung einen Hinweis modellieren können. Mittels so genannter CitationConnections können Zitate eines Dokuments in einem anderen Dokument abgebildet werden und mit so genannten AntiConnections ist eine Verbindung möglich, welche mit Hilfe einer negativen Gewichtung angibt, wie stark sich zwei Objekte "abstoßen". Mittels so genannter SemanticConnections lassen sich semantische Netze zwischen Objekten modellieren. So genannte SpringConnecti- ons können eine sich ändernde Beziehung zwischen Objekten ähnlich dem Verhalten einer mechanischen Feder modellieren. Der Abstand zwischen den Objek- ten wird dazu als ein Gewichtungswert der Verbindung ausgedrückt. So genannte CompositionConnections dienen dazu Objekte so zusammen zu führen, wie es oben zum prinzipiellen Merkmal Composition erläutert worden ist. Es können auf diese Weise auch beliebige Objektklassen miteinander kombiniert werden, um neue Kombinationsobjekte, so genannte Composites, zu erstellen. Zusätzlich ist diese Art von Verbindung des Ausführungsbeispiels in der Lage den Typ und die jeweilige Anzahl der möglichen Objekte, mit denen das Composite erstellt werden kann, genau zu definieren. So wurde auch die oben genannte Composition eines ProjectSpace beim Ausführungsbeispiel realisiert, indem diesem genau ein Kalender, genau ein Organigramm und beliebig vielen WorkSpaces zugeordnet wur- den. Die Verbindungsobjekte des Ausführungsbeispiel sind damit ganz anders, als Verbindungsbeziehungen in bekannten Datenstrukturen von beispielsweise objektorientierten Datenbanken. Sie haben alleine wegen der Tatsache, dass sie genau wie Informationsobjekte auf Basisobjekten beruhen, je nach Bedarf ver- schiedenste Fähigkeiten, die wie folgt nutzbringend eingesetzt werden können:

Die Verbindungsobjekte haben Eigenschaften (Properties), wie z.B. einen eindeutigen Namen, um so genannte Permalinks zu ermöglichen. Verbindungsobjekte können eine Zusatzinformation (Content) in Form beispielsweise eines Textes aufweisen, der Erläuterung für den Grund der Verbindung oder detaillierte Informationen über den Zusammenhang zwischen den beiden verbundenen Objekten beschreibt. Auf die Verbindungsobjekte können alle bereits genannten verfügbaren Ordnungsmöglichkeiten angewendet werden (Connecting, Tagging, Classify- ing). Verbindungsobjekte können auch selbst zur Nachvollziehbarkeit erfasst wer- den (Version Control, Histroy, Audit Trail, Logging). Verbindungsobjekte können durch die Vergabe von Berechtigungen für den Lese- oder Schreibzugriff administriert werden, sodass bestimmte Verbindungsobjekte (und damit auch die dahinter liegenden Objekte) für bestimmte Benutzer oder Benutzergruppen nicht sichtbar oder editierbar sind (Access Rights, Signing, Encrypting). Die Sichtbarkeit von Verbindungsobjekten kann auch über die Zeit gesteuert werden (Visibility). Verbindungsobjekte können von Benutzern bewertet und damit einen Mehrwert erhalten (Rating, Voting). Verbindungsobjekte können aktiv vom Benutzer oder passiv vom System gewichtet werden (beispielsweise durch die Häufigkeit der Nutzung) (Weighting). Die Aktualität von Erfindungsobjekten kann für die Naviga- tion in hierarchischen Strukturen genutzt werden (Aktualität, Outdating, Expiring). Das Setzen von Überwachungen (Watches) auf Verbindungsobjekte kann einen Benutzer über etwaige Veränderungen der Verbindung auf den laufenden halten (Watching). Ferner kann der Lebenszyklus eines Verbindungsobjektes einem Arbeitslauf unterliegen (Workflowable), wie beispielsweise ein Prozess zur Freigabe von Verbindung zwischen sensiblen Daten. Indem vorteilhaft ferner bei dem Ausführungsbeispiel computerimplementiert die derart gebildeten Informationsobjekte als Knoten und die Verbindungsobjekte als Kanten eines Graphen identifiziert werden, können basierend auf der Graphentheorie und den darin zur Verfügung stehenden Algorithmen Maßzahlen festgelegt werden. Diese Maßzahlen geben dann innerhalb der Datenstruktur des Ausführungsbeispiels Auskunft über die Beziehung der Informationsobjekte untereinander.

Wichtige Maßzahlen sind dabei: - die Anzahl der Verbindungen an einem Objekt,

- der minimale Abstand zwischen zwei Objekten (welcher beispielsweise mittels dem Algorithmus von Dijkstra berechnet werden kann),

- die Anzahl der möglichen Wege mit einer maximalen Länge zwischen zwei Objekten, - das Gewicht und/oder die Aktualität eines Verbindungsobjektes bzw. einer Kante,

- das Gewichts und/oder die Aktualität aller Verbindungsobjekte bzw. Kanten eines Informationsobjektes bzw. Knotens,

- die Anzahl der auf ein Objekt gerichteten Verbindungsobjekte sowie - die Anzahl an Schritten, die benötigt wird, um bei durch gerichtete Verbindungsobjekte verbundenen Informationsobjekten (ParentChildConnections) das gemeinsame Ausgangsobjekt (Elternobjekt bzw. ParentObject) zu ermitteln.

Mit Hilfe der Maßzahlen können beim Ausführungsbeispiel sehr leicht jene Infor- mationsobjekte gefunden werden, die stark miteinander vernetzt sind und entsprechend innerhalb der Datenstruktur eine hohe Bedeutung haben. Ferner können auf der Basis der Maßzahlen selbst große Mengen an Informationen besonders einfach strukturiert werden, wie nachfolgend zum so genannten prinzipiellen Merkmal Swarm noch näher erläutert werden wird. Die Verbindungsobjekte können ferner in einer dem Ausführungsbeispiel zugeordneten Anzeigeeinheit, beispielsweise in Gestalt eines Bildschirms, graphisch auf vielfältigste Weise, beispielsweise in unterschiedlichen Farben, visualisiert werden. Durch Layoutalgorithmen können miteinander verwandte Informationsob- jekte nahe beieinander liegend dargestellt werden. Optional kann vom Benutzer des computerimplementierten Systems die Tiefe der gewünschten Visualisierung ausgehend von einem Informationsobjekt angegeben werden. Durch Anwählen eines Informationsobjektes kann dieses zum neuen aktuellen Informationsobjekt werden, um so eine Bewegung durch die Datenstruktur real abbilden zu können. Diese Art der "Navigation" durch die Datenstruktur bringt einem Benutzer einen viel rascheren Überblick über ein Themengebiet und die nicht offensichtlichen Verbindungen zu anderen Themengebieten, als durch eine übliche Baumstruktur, wie sie beispielsweise in heutigen Dateisystemen angeboten wird.

Mindestens eines der genannten Basisobjekte ist ferner dazu eingerichtet, dass es während des Betriebs des computerimplementierten Systems einem vordefinierten Ablauf unterliegt. Der vordefinierte Ablauf wird vorliegend auch als Lifecyc- Ie oder Workflow bezeichnet. Der derartige „Lebenszyklus" beginnt mit der „Geburt" des modifizierten Basisobjekts im computerimplementierten System des Ausführungsbeispiels und endet mit dessen „Tod". Während eines dazwischen liegenden „Lebens" erfährt das modifizierte Basisobjekt die unterschiedlichsten Modifikationen, die sich insbesondere aufgrund seiner dabei angenommen und abgelegten Fähigkeiten ergeben. Es kann sich beispielsweise aufgrund seiner Fähigkeiten mit anderen Objekten verbinden und von anderen Benutzern genutzt werden. Der Tod des Objektes tritt schließlich dadurch ein, dass dieses endgültig aus dem System gelöscht wird.

Einen derartigen, allgemeinen Lebenszyklus muss jedes Objekt durchleben. Meistens ist ein derartiger, allgemeiner Lebenszyklus für viele Anwendungsfälle bereits ausreichend. Es gibt jedoch eine Vielzahl Situationen, in denen der Zeitraum des Lebens zwischen Geburt und Tod nach einem klar vordefinierten Ablauf zu erfolgen hat. Dieser vordefinierte Ablauf (welchen wir auch als Workflow bezeichnen) ist durch eine Menge von Stati beschrieben, die das Objekt während seiner Lebenszeit anneh- men kann oder muss, und durch eine Vielzahl Übergänge, die den Wechsel von einem Status in einen anderen Status festlegen.

Ein exemplarischer, vordefinierter Ablauf ist bei dem dargestellten Ausführungsbeispiel, ein Objekt, welches die Urlaubsgenehmigung des Urlaubs für einen Mit- arbeiter verwaltet. Der Lebenszyklus für dieses Objekt ist in drei Schritte eingeteilt: 1.) Geburt - vom Benutzer wird das neue Objekt Urlaub angelegt, 2.) Leben - das Objekt durchläuft verschiedene Stati, die durch einen vordefinierten Ablauf vorgegeben sind, 3.) Tod - das Objekt Urlaub wird nicht mehr benötigt und aus Speicherplatzgründen oder wegen Verfalls wieder gelöscht.

Der Zeitraum nach der Geburt und vor dem Tod wird dabei durch einen Workflow beschrieben, der mehrere Stati und Übergänge besitzt. Ein Übergang ist das Eingeben des Anfangs- und Enddatums des Urlaubs durch den betroffenen Mitarbeiter, nachdem dieser das Objekt Urlaub erstellt hat. Danach leitet der Mitarbeiter das Objekt in den nächsten Status, nämlich an seinen Vorgesetzten weiter. Dieser erzeugt einen neuen Übergang, indem er den Vorschlag akzeptiert oder ablehnt.

Bei Ablehnung wird das Objekt in einen Status überführt, bei dem der Mitarbeiter einen neuen Terminvorschlag machen kann. Bei Annahme wird ein Status für das Objekt belegt, bei dem dieses beispielsweise von der Personalabteilung gelesen werden kann.

Der Ablauf ist ferner bevorzugt noch effizienter gestaltet, indem die Stati im Workflow mit einem Zeitlimit versehen sind, bis zu dem ein Wechsel in einen an- deren Status (also eine Weiterverarbeitung) zu erfolgen hat. Nach Ablauf des Zeitlimits wird die Aufgabe dann automatisch z.B. an einen Stellvertreter oder ei- nen Vorgesetzten weitergeleitet. Nach jedem Statuswechsel werden relevante beteiligte Personen über diesen Wechsel informiert.

Bevor ein Statuswechsel durchgeführt wird, werden vordefinierte Überprüfungen auf Konsistenz der Eigenschaften des Objektes durchgeführt. Fehler und Inkon- sistenzen in den Daten können so vermieden werden.

Während ein Objekt von einem Status zu einem anderen Status einen Workflow durchwandert, muss es von dem im jeweiligen Status berechtigten Benutzern) bearbeitet werden. Die Bearbeitung betrifft das Modifizieren der Eigenschaften und gegebenenfalls der Fähigkeiten des Objektes. Der letzte Schritt der Bearbeitung ist das Weiterleiten in den nächsten Status. Dieser Schritt kann manuell oder automatisiert anhand vorgegebener Kriterien erfolgen.

Aus der Sicht des beteiligten Objektes wird dieses von Status zu Status weitergereicht, bis es einen Endpunkt im Workflow erreicht hat. Aus der Sicht der Benutzer hingegen, die in einem bestimmten Status die Verantwortung für das Objekt übernehmen, stellt es sich so dar, dass sie eine Aufgabenliste zu bearbeiten haben, in der immer wieder neue Objekte mit einem für sie zugeteilten Status erscheinen, welche sie dann „abarbeiten" bzw. deren Status sie ändern müssen.

Ein Objekt, welches einem Workflow unterliegt, unterscheidet sich von einem Objekt ohne Workflow folgendermaßen:

- das Objekt ist über ein Verbindungsobjekt mit einem Workflow verbunden, der selbst aus Informationsobjekten und Verbindungsobjekten aufgebaut ist;

- das Objekt hat in dem Workflow dadurch einen Status, der angibt, in welchem Schritt des Workflows es sich befindet;

- zu jedem Status ist über den Workflow definiert, welcher Benutzer das Objekt in welchem Umfang ändern und in einen anderen Status überführen darf; - für jeden Benutzer ist dadurch umgekehrt definiert, wie seine Zugriffsrechte sind, z.B. welche Objekte er bei der Bearbeitung sehen darf bzw. sieht; Etwas allgemeiner formuliert, bedeutet dies, dass jedes Objekt, welches einem Workflow unterliegt, immer einen Status besitzt und bezüglich seiner Änderbarkeit nach bestimmten Vorgaben eingeschränkt ist.

Der Workflow gibt hingegen als Kette aus Informationsobjekten und Verbindungsobjekten die Möglichkeiten und Wege vor, entlang denen sich zugeordnete Objekte bewegen können. Der Workflow als vordefinierter Ablauf kann daher auch Abzweigungen enthalten, die entsprechend den im Objekt hinterlegten Daten aus- gewählt werden.

Es wird also die Funktionalität von der Lösung getrennt. Beide werden aber mit der gleichen Datenstruktur abgebildet. Es wird eine Kette aus Stati und Übergängen als Workflow aufgebaut, an die dann die Objekte angehängt werden. Die LJ- bergänge definieren, welche Veränderungen an einem Objekt möglich sind und legen fest, ob ein Objekt in den nächsten Status überführt werden kann. Wenn alle Anforderungen erfüllt sind, wird das geänderte Objekt vom System gegebenenfalls automatisch an den nächsten passenden Status gehängt.

Die Funktionalität wird in Eingabemasken bzw. User Interfaces abgebildet, die dem Benutzer vorgeben, welche Veränderungen möglich sind. Die Eingabemasken sind dabei stark vom zugehörigen Status im vordefinierten Ablauf abhängig. Besonders vorteilhaft ist die zugehörige Eingabemaske selbst als ein Objekt bzw. eine Objektklasse gestaltet, welche an den jeweiligen Status im Workflow ange- hängt ist. Die Eingabemaske kann dann auch die Definition der Zugriffsrechte enthalten. Dadurch werden weitere Funktionen realisiert, ohne die vollständig objektorientierte, in Informationsobjekte und Verbindungsobjekte aufgeteilte durchgängige Datenstruktur zu verlassen.

Auf diese Weise ist sowohl der vordefinierte Ablauf, als auch dessen Eingabe bzw. Abarbeitung selbst in Form von modifizierten Basisobjekten gestaltet, welche den oben genannten prinzipiellen Merkmalen unterliegen. Es kann also z.B. ein Workflow zum Erstellen eines Workflows generiert werden.

Mit den derart anwendbaren prinzipiellen Merkmalen ergeben sich weitere Vorteile bei der Nutzung:

Prinzipielles Merkmal Capabilities: Der vordefinierte Ablauf besitzt selbst alle erforderlichen Fähigkeiten, wie z.B. eine Versionskontrolle oder Zugriffsberechtigungen; Prinzipielles Merkmal Evolution: Aus vordefinierten Abläufen können durch Varia- tion und Selektion besser für eine Aufgabenstellung angepasste Abläufe entstehen;

Prinzipielles Merkmal Composition: Einfache vordefinierte Abläufe können durch Zusammenstellen zu komplexen Abläufen verbunden werden; Prinzipielles Merkmal Connection: Es können mehrere einzelne Abläufe durch Verbindungsobjekte zu komplexen Abläufen verbunden werden;

Prinzipielles Merkmal Passive Usage: Die Daten, die sich aus der Nutzung von vordefinierten Abläufen ergeben, können z.B. für statistische Auswertungen genutzt werden; insbesondere Bearbeitungszeiten können dabei erfasst und ausgewertet werden; Prinzipielles Merkmal Active Usage: Durch Bewertungen, Tags und dem Hinzufügen von Notizen kann jedem vordefinierten Ablauf ein Mehrwert hinzugefügt werden;

Prinzipielles Merkmal Lifecycle: Auch ein vordefinierter Ablauf unterliegt selbst voll einem Lebenszyklus und kann daher selbst jederzeit durch einen vordefinierten Ablauf hindurchgeleitet werden; dies könnte z.B. ein Freigabeprozess sein, bei dem der vordefinierte Ablauf vor seinem eigentlichen Einsatz nochmals geprüft und endgültig freigegeben wird;

Jeder Status ist beim Ausführungsbeispiel eine Instanz einer speziellen Klasse von Objekten, die sich aus den prinzipiellen Merkmalen Capabilities und Evolution ergibt. Für jeden Status ist genau definiert, welche Benutzer welche Daten sehen und editieren dürfen und welche Funktionen und Statusübergänge sie ausführen dürfen.

Jeder Statusübergang ist ein spezielles Verbindungsobjekt, das zwei oder mehr Status-Objekte miteinander verbindet und alle Eigenschaften, Regeln und Einschränkungen als Fähigkeiten beinhaltet. Weiters kann jeder Statusübergang eine Menge an Bedingungen enthalten, die erfüllt sein müssen, damit der Statusübergang erfolgen kann.

Jeder Workflow, der sich aus Stati und Statusübergängen zusammensetzt, befindet sich in einem speziellen Container, dem so genannten WorkflowContainer. Dieser enthält genau einen Workflow, der sich aus den Informationsobjekten für die einzelnen Stati und Verbindungsobjekten für die Statusübergänge zusammensetzt.

Da die derartigen Workflows damit insgesamt ausgehend von den oben erläuterten Basisobjekten gestaltet sind, können auf die einzelnen Objekte sämtliche hier erläuterten prinzipiellen Merkmale angewendet werden. Das gleiche gilt für den Workflow im Ganzen. Die einzelnen Objekte von Workflows sind kopierbar und bilden als solche eigene Klassen von modifizierten Basisobjekten. Änderungen an einem Status oder Statusübergang können so für andere Workflows, die diesen Status bzw. Statusübergang ebenfalls benutzen, sehr einfach übernommen werden.

Die durchgängig objektorientierte Struktur der Workflows und der damit verarbeiteten Daten erleichtert ferner die graphische Darstellbarkeit und liefert somit eine bessere Übersicht sowie ein schnelleres Verständnis für alle Beteiligten. Insbesondere werden dem Benutzer der aktuelle Status im Ablauf, alle möglichen nächsten Stati, die noch verbleibende Zeit für die Bearbeitung und die bereits er- ledigten Stati, deren Bearbeiter und das Erledigungsdatum angezeigt. Der das Leben beschreibende, vordefinierte Ablauf ist also mittels mindestens zweier Stati und einem Statusübergang definiert, von denen die Stati ausgehend von Basisobjekten gestaltet sind, die Informationen tragen, und der Statusübergang ausgehend von einem Basisobjekt gestaltet ist, das als Verbindungsobjekt zwei oder mehr Basisobjekte verbindet. Auf diese Weise kann eine ganze Kette von Stati gebildet werden, wobei der Wechsel von einem Status zu einem anderen Status jeweils in Form eines zugehörigen, den Übergang beschreibenden Verbindungsobjektes gestaltet ist.

Vorteilhaft ist bei dieser Vorgehensweise, dass die für den Lebenszyklus bzw. Ablauf verwendete Datenstruktur gleich ist wie die im Ablauf verarbeiteten Daten selbst. Dadurch können sämtliche auf die Daten angewandten, oben beschriebenen und auch nachfolgend noch genannten prinzipiellen Merkmale auch auf die Ablaufbeschreibung angewendet werden.

Das prinzipielle Merkmal Lifecycle ist also eine zunächst allgemeine Sichtweise auf die beteiligten Objekte, die einen klaren Anfangs- und Endpunkt für jedes Objekt definiert. Zwischen diesen beiden Punkten findet das eigentliche Leben des Objektes statt, das entweder frei von jeden Zwängen durchlaufen werden kann, oder eingeschränkt durch einen Workflow einen vorbestimmten Ablauf hat.

Das computerimplementierte System und Verfahren des Ausführungsbeispiels sind ferner vorteilhaft dazu eingerichtet, dass bei ihnen das mindestens eine Basisobjekt während des Betriebs des computerimplementierten Systems seine Nut- zung protokolliert. Das dabei zugrunde liegende prinzipielle Merkmal des Ausführungsbeispiels wird hier als Usage bezeichnet und basiert auf der Erkenntnis, dass jedes Verhalten von Benutzern in einem computerimplementierten System Spuren hinterlässt, die zu den im System gespeicherten Informationen einen wichtigen Mehrwert bilden können. Die Spuren können vorteilhaft verfolgt bzw. ge- sammelt und die so weiter entstandenen Informationen auf unterschiedlichste Art genutzt werden. Beim Ausführungsbeispiel wird dabei unterschieden zwischen der so genannte Passive Usage, bei der Informationen rein durch die Benutzung des Systems entstehen, und der so genannten Active Usage, welche all jene Informationen umfasst, die von einem Benutzer aktiv dem System hinzugefügt werden.

Im Hinblick auf Passive Usage werden bei dem computerimplementierten System und Verfahren Veränderungen, die ein Benutzer an einem Objekt vornimmt, mit den relevanten Änderungsinformationen erfasst (wie beispielsweise Datum und Uhrzeit, Benutzername und durchgeführte Aktion) und insbesondere in einer Nutzungstabelle, wie sie in Fig. 9 dargestellt ist, abgelegt.

Die Nutzungstabelle umfasst dabei:

- eine Spalte 64, in der Datum und Uhrzeit (DateTime) der vorgenommenen Änderung aufgeführt sind,

- eine Spalte 66, in der die IP-Adresse (IP Address) des die Änderung durchfüh- renden Rechners aufgeführt ist,

- eine Spalte 68, in der eine Benutzeridentifikation (UserlD) aufgeführt ist,

- eine Spalte 70, in der die durchgeführte Aktion (Action, wie z.B. Betrachten (view), Editieren (edit.attributes), Erstellen (create), Löschen (delete), Taggen (tag) oder Klassifizieren (classify)) aufgeführt ist, und - eine Spalte 74, in der die Zeitdauer (Duration) der durchgeführten Aktion aufgeführt ist.

Die derart gestaltete Nutzungstabelle wird innerhalb der Datenstruktur in Form eines Information tragenden Basisobjektes abgebildet. Dieses Basisobjekt ist nach dem prinzipiellen Merkmal Composition aus Verbindungsobjekten zusammengesetzt. Jedes Verbindungsobjekt bildet eine Zeile der Nutzungstabelle ab. Es ist als so genannte UsageConnection modifiziert. Die UsageConnection ist dabei die Verbindung, die den Benutzer (welcher ja ebenfalls als modifiziertes Basisobjekt repräsentiert ist) und das benutzte Objekt verbindet. Als Eigenschaften der UsageConnection sind z.B. die durchgeführte Aktion (Action) und die Dauer der Aktion (Duration) und der Zeitpunkt der Durchführung (DateTime) gespeichert. Auf diese Weise sind die gemäß dem Stand der Technik bisher in textuellen Log- Dateien befindlichen Nutzungsdaten zu einer speziellen Art von Verbindungsobjekten weiterentwickelt, wodurch die folgenden Vorteile entstehen: Die Nutzungs- daten sind selbst auf der Grundlage von Basisobjekten abgebildet, auf welche sämtliche genannten prinzipiellen Merkmale anwendbar sind. Da jede Aktion als ein Verbindungsobjekt zwischen einem Benutzer und einem benutzten Objekt abgebildet ist, entwickelt sich ein Graph zwischen dem Benutzer und dem benutzten Objekt, auf dem insbesondere die genannten graphentheoretischen Algorithmen für Auswertungen und Analysen angewendet werden können. Neben der eigentlichen Datenstruktur bildet sich eine Nutzungsstruktur, wobei diese beiden Strukturen gemeinsam ausgewertet werden können.

Die Sichtweise, die Nutzungsdaten nicht mehr als einfache Tabelle, sondern als Graphen zu betrachten, schafft neue Möglichkeiten der Visualisierung und Auswertung. Fig. 10 zeigt einen derartigen Graphen, der Nutzungsdaten in Form von UsageConnections 76 zwischen Benutzern 78 und Informationsobjekten 80 abbildet.

Die derart aufgeschlüsselten Nutzungsdaten können auf vielfältige Art und Weise im System des Ausführungsbeispiels ausgewertet werden. Sie sind insbesondere hilfreich für die Nachvollziehbarkeit von Aktionen und Unterstützen auch das Bilden eines so genannten Audit Trails (wie er beispielsweise für kritische Daten durch den Sarbanes-Oxley Act vorgeschrieben ist). Ferner können Zugriffsberech- tigungen einfach überwacht werden, der zeitliche Verlauf von Arbeiten an einem Objekt kann leicht visualisiert werden, Ereignis-Protokolle können einfach erstellt und weitergeleitet werden und persönliche Journale können für einen Benutzer bei Bedarf abgerufen werden.

In vielen Systemen des Standes der Technik werden die Metadaten des Objektes und auch die Daten von dessen Editoren sowie das Erstellungs- und Änderungs- datum direkt als Eigenschaften des Objektes gespeichert. Gemäß dem Ausführungsbeispiel sind hingegen die benutzerbezogenen Daten von den objektbezogenen Daten getrennt strukturiert, sodass diese auch entsprechend getrennt oder aber in Verbindung mit den Objekten ausgewertet werden können.

So können bei dem System des Ausführungsbeispiels beispielsweise die Bearbeitungskosten für ein Objekt (insbesondere innerhalb eines Projektes) leicht ermittelt werden. Für die Lizenzierung der Nutzung eines Objektes können die Lizenzkosten unmittelbar an der erfolgten Nutzung berechnet werden. Ferner kann, wie oben bereits erwähnt, die Aktualität eines Objektes an dessen Nutzung orientiert mathematisch berechnet werden. Da auch Objektkassen wie ein Programmskript und ein Anwendungsprogramm als eigene Objekte abbildbar sind, kann auch deren Nutzung an einem Server durch einen Benutzer mittels der erfindungsgemäßen UsageConnections abgebildet und ausgewertet werden. Ein Benutzer kann jederzeit über seine zuletzt bearbeiteten Objekte und die darauf durchgeführten Aktionen informiert werden. Ferner können wiederkehrende Muster von Aktionen identifiziert werden. Diese Muster können dann automatisch und/oder in Abstimmung mit einem Benutzer in eine Reihe von Aktionen zusammengefasst werden, die als Skript-Objekt verfügbar gemacht werden. Mehrere Skripts können mit Con- nections aneinander gereiht werden.

Die Nutzungsdaten beinhalten auch Angaben darüber, welcher Benutzer welches Objekt angesehen hat. Damit kann aus den erfindungsgemäß erfassten Nutzungsdaten eine gesicherte Informationsverteilung (Assured Information Delivery) bereitgestellt werden, bei der z.B. mittels eines Fragebogens erfasst werden kann, ob eine Information tatsächlich verstanden worden ist. Es kann auch erfasst werden, ob eine Reihe von Aktionen nur langsam nacheinander ausgeführt worden ist, und so auf Unsicherheiten in der Benutzung geschlossen werden. Ferner kann erfasst werden, ob neue Funktionen von den Benutzern angenommen werden oder nicht. Fehler in der Bedienung bzw. Benutzung eines computerimplementierten Systems gemäß dem Ausführungsbeispiel können ebenfalls besser erfasst und nachvollzogen werden. Die Nutzung bzw. Auslastung des gesamten computerimplementierten Systems kann ebenfalls vergleichsweise leicht erfasst und für einen Systemadministrator aufbereitet dargestellt werden. Diese Auswertung ist noch dazu in Echtzeit möglich. Da ferner auf die erfassten Nutzungsdaten auch entsprechend begrenzte Zugriffsrechte verteilt werden können, ist es sogar leicht möglich diese Benutzung zu "anonymisieren".

In der Active Usage werden all jene Möglichkeiten zusammenfasst, die es einem Benutzer erlauben aktiv weitere Informationen direkt einem Objekt hinzuzufügen, an einem Objekt ein Objekt mit Hilfe eines Verbindungsobjektes anzuhängen, o- der Objekte über Verbindungsobjekte miteinander zu verknüpfen.

Das so genante Tagging umfasst dabei das Hinzufügen von einzelnen Wörtern oder Begriffen, so genannte Schlag- oder Schlüsselwörter, zu einem Objekt. Jedes Tag wird in einem eigenen Eingabefeld eingegeben, wodurch eine Trennung zwischen den einzelnen Tags einfacher wird. Ferner können dadurch dem einzelnen Tag selbst Eigenschaften mitgegeben werden. So zeigt Fig. 11 eine Einga- bemaske 82 für ein Tag 84, dem eine Einordnung hinsichtlich seiner Sichtbarkeit Visibility 86 nämlich öffentlich (public) oder privat (private) zugeordnet ist. Im oberen Bereich der Eingabemaske 82 ist ferner eine Anzeige von öffentlichen Tags anderer Benutzer dargestellt, bei der der Benutzer der Eingabemaske 82 ferner die Möglichkeit erhält, diese öffentlichen Tags zu werten (My Rating).

Im Gegensatz zu Tags, wo beliebige Wörter genutzt werden können, ist bei Klassifikationen der Wortschatz genau vorgegeben und der Benutzer kann nur aus diesem fixen Wortschatz einen oder mehrere Begriffe auswählen. Ähnlich wie die Tags werden auch die Klassifikationen jeweils als eigenes Objekt modelliert. Fig. 12 zeigt ein solches Modell von zwei Informationsobjekten 90 und 92, die über eine ParentChildConnection als Verbindungsobjekt 94 verbunden sind. Den In- formationsobjekten 90 und 92 sind ferner über TagConnections als Verbindungsobjekte 96 und Tags 98 in Form von Informationsobjekten zugeordnet. Drei der Tags 98 sind über TagBundleConnections zu einem so genannten TagBundle 102 in Form eines Informationsobjektes gebündelt.

Auch das Anhängen bzw. Einbinden von Informationsobjekten in die Datenstruktur ist eine aktive Nutzung, wobei insbesondere Notizen in aügemeiner Form angehängt werden können. Eine Notiz ist ein Objekt, das aus einem Text, einem Titel und einer beliebigen Menge an Anhängen bestehen kann. Eine Notiz kann dabei einen vielfältigen Mehrwert bieten und insbesondere eine Bewertung des zugehörigen Informationsobjektes beinhalten. Eine besondere Art einer derartigen Bewertung ist eine Rückmeldung eines Benutzers bei Durchsicht eines ihm zur Verfügung gestellten Suchergebnisses. Der Benutzer kann bei dem System des Ausführungsbeispiels dabei mit einem einzigen Mausklick die Relevanz des einzelnen Eintrags des Suchergebnisses bewerten.

Eine weitere aktive Nutzung innerhalb des computerimplementierten Systems bzw. Verfahrens ist das Verbinden bzw. Koppeln bestehender Objekte mittels Verbindungsobjekten gemäß dem oben bereits erläuterten prinzipiellen Merkmal Connection.

Bei einer weiteren vorteilhaften Ausgestaltung des computerimplementierten Systems und Verfahrens gemäß dem Ausführungsbeispiel sind bei diesem mehrere Basisobjekte dazu eingerichtet, dass sie gemäß ihrer angenommenen Fähigkeit, ihrer Art der Zusammenstellung aus mehreren Objekten, ihrer Art der Zusammenstellung mehrerer allgemeiner Eigenschaften, ihrem vordefinierten Ablauf und/oder ihrer protokollierten Nutzung geordnet werden können. Die dabei erstellte Ordnungsstruktur basiert insbesondere auf den oben genannten prinzipiellen Merkmalen, gemäß denen die für das Ordnen erforderlichen Informationen erfasst und innerhalb der Datenstruktur des Ausführungsbeispiels in gleicher Weise gespeichert werden, wie die eigentlichen Informationen. Dabei wird zunächst von einer so genannten Objectsoup (einer „Objektsuppe") ausgegangen, die einen Behälter darstellt, in dem sich alle Objekte gleichwertig und ungeordnet befinden. Insbesondere durch die Nutzung der Objekte entstehen dann explizite und implizite Ordnungen die erkannt, berechnet, visualisiert und für verschiedenste Anwendungsmöglichkeiten genutzt werden können. Dabei werden insbesondere so genannte relevante Objekte erkannt, die besondere Eigenschaften und Merkmale aufweisen. Ferner werden so genannte Alpha-Objekte ermittelt, denen viele andere Objekte „folgen".

Das derart entwickelte prinzipielle Merkmal wird als Swarm bezeichnet. Wichtig ist bei dieser Vorgehensweise, dass innerhalb der Objectsoup das einzelne Objekt nicht nur in Verbindung mit anderen Objekten gesehen werden kann, sondern auch als eine alleinstehende Einheit, die zu den anderen Einheiten ungeordnet und gleichwertig ist. Die alleinstehende Einheit kann programmtechnisch nämlich erheblich einfacher verarbeitet und angesprochen werden, als wenn sie sich stets in einer Kopplungen mit anderen Einheiten befindet, wie dies bei bekannten Systemen der Fall ist.

Die „Unabhängigkeit" des einzelnen Objektes wird erreicht, indem jedes Basisobjekt drei Grundfähigkeiten aufweist, nämlich eine eindeutige Kennung zugewiesen zu haben, computerimplementiert gespeichert werden zu können und auf eine computerimplementierte Anfrage hin antworten zu können. Diese besonders einfache Grundstruktur der Basisobjekte, welche allen sich innerhalb der Objectsoup befindlichen Objekten gemeinsam ist, ermöglicht während des eigentlichen Betriebs des computerimplementierten Systems und Verfahrens eine Abfrage bzw. einen Zugriff auf sämtliche ( gegebenenfalls bereits modifiziert) vorliegenden Basisobjekte.

Da wie oben erläutert auch sämtliche weiteren Strukturdaten und Nutzungsarten des computerimplementierten Systems und Verfahrens in Form solcher Basisob- jekte innerhalb der Objectsoup abgelegt werden, können aus diesen modifizierten Basisobjekten nach nahezu beliebigen Kriterien die oben genannten „Zusammenschlüsse" von miteinander in Beziehung stehenden Objekten gebildet werden. Innerhalb der Zusammenschlüsse können relevante Objekte, insbesondere rele- vante Benutzer, relevante Tags oder Klassifikationen, relevante Verbindungen, relevante Workflows oder relevante Suchmuster leicht ermittelt werden.

Bei dem Ausführungsbeispiel ist mit dieser Vorgehensweise die Funktion realisiert, dass beim Ändern oder Löschen von relevanten Objekten in einer Ordnung das System den Benutzer fragt, ob er andere relevante Objekte in diesem Bereich auch ändern oder löschen möchte. Ferner kann dem Benutzer des Systems gemäß dem Ausführungsbeispiel stets ein Überblick über die Ordnungsstruktur eines bearbeiteten Objektes gegeben werden oder es können ihm die innerhalb der Ordnung tätigen anderen relevanten Benutzer als Experten genannt werden.

Die Möglichkeiten, Ordnungen zu ermitteln und zu erkennen sind dabei besonders vielfältig. So können Ordnungen innerhalb verschiedenerer Fähigkeiten (Capabili- ties) innerhalb der Entwicklung von Objekttypen (Evolution), innerhalb von gleichen oder ähnlichen Composition-Objekten, innerhalb von durch Verbindungsob- jekte (Connections) hergestellten Strukturen, Hierarchien und Gruppen, innerhalb von Nutzungsstrukturen (Usage) aufgebaut und für eine spätere Auswertung nutzbar gemacht werden. Bei dem Ausführungsbeispiel können insbesondere die „Trampelpfade", also oft genutzte Verbindungen zwischen Objekten visualisiert und daraus eine Empfehlung für einen vordefinierten Ablauf abgeleitet werden.

Fig. 13 zeigt eine solche Visualisierung von Verbindungsobjekten 104 zwischen Informationsobjekten 106, bei der die Nutzungshäufigkeit der Verbindungsobjekte 104 durch die Strichstärke von Kanten zwischen den als Knoten dargestellte Informationsobjekten 106 veranschaulicht ist. An der Darstellung kann ein Benutzer ferner anhand der Farbe der dargestellten Kante eine (oft genutzte) Verbindung mit sehr hoher Aktualität 104a von einer (oft genutzten) Verbindung mit geringer Aktualität 104b unterscheiden. Eine selten genutzte Verbindung mit geringer Aktualität 104c erkennt der Benutzer bereits an der geringen Strichstärke der dargestellten Kante.

Die Strukturierung auf Grundlage von ausschließlich modifizierten Basisobjekten ermöglicht es ferner, Kosten für bestimmte Strukturbereiche zu ermitteln und daraus Kostenschätzungen für ähnliche Strukturen aufzustellen. Dabei können insbesondere die anhand der Usage entstandenen Bearbeitungskosten berücksichtigt werden.

Ferner können bei dem System und Verfahren gemäß dem Ausführungsbeispiel Benutzer oder Autoren gruppiert werden, die an gleichen Themen bzw. Objekten arbeiten. Fig. 14 zeigt eine solche Darstellung, bei der die einzelnen Autoren 106 in ihren Themengebieten als Punkte veranschaulicht sind. Die Größe des Punktes eines Autors veranschaulicht innerhalb der Darstellung dessen Publikationshäufigkeit. Autoren, die an den gleichen Themen arbeiten, können sich auf diese Weise zu Autorenteams zusammenfinden. Femer können isolierte Autoren als „Einzelgänger" und auch Themenketten bildende Autoren als „Autorenkette" erkannt werden.

Es können vorteilhaft auch Korrelationen zwischen Tags, Klassifikationen, dem Inhalt, Ratings, Revies und der Passive Usage ausgewertet werden. Mit Hilfe der Maßzahlen aus der Graphentheorie lassen sich, wie oben bereits erwähnt, die Entfernungen zwischen den einzelnen relevanten Objekten berechnen. Bereiche mit eng zusammenhängenden Objekten werden als so genannte relevante Cluster bezeichnet und sind innerhalb eines Swarm von besonderer Bedeutung.

So können die relevanten Cluster einem Benutzer beispielsweise dazu angezeigt werden, damit dieser gezielt in einem der Cluster eine Suchanfrage starten kann. Gemäß einer weiteren vorteilhaften Ausgestaltung des Ausführungsbeispiels ist eine Auswertung im Hinblick auf die sich ergebenden Ordnungen insbesondere dahingehend möglich, welche Ordnung sich zwischen Basisobjekten ergibt, welche Benutzer darstellen. Wir nennen dieses prinzipielle Merkmal Socializing.

Die Auswertung beruht dabei auf den Ergebnissen, die die erfindungsgemäße Lösung durch die prinzipiellen Merkmale Usage und Swarm liefert. Sie basiert auf der Erkenntnis, dass hinter jedem Objekt innerhalb einer Datenstruktur, insbesondere einer objektorientierten Datenbank, ein oder mehrere Benutzer dieses Objek- tes „stehen", die mit diesem Objekt arbeiten oder sich mit diesem Objekt beschäftigt haben. Da sich nun innerhalb des Systems und Verfahrens des Ausführungsbeispiels die Objekte besonders leicht ordnen lassen, ergibt sich mit geringem Aufwand auch eine Ordnung jener Benutzer, die diesen Objekten zugeordnet sind. Die auf diese Weise ermittelte Ordnung von Benutzern wird gewinnbringend eingesetzt, indem diese Benutzer z.B. über Chat oder e-Mail miteinander in Kontakt gebracht werden. Geographische Grenzen können dabei leicht überwunden und es können auch Benutzer miteinander in Kontakt gebracht werden, die in einem weltweit verteilt arbeitenden Unternehmen tätig sind.

Das computerimplementierte System und Verfahren können dazu dem einzelnen Benutzer in Listenform oder in Gestalt eines graphisch aufbereiteten Charts jene Benutzer zur Kenntnis geben, die sich mit ähnlichen Probleme, Themen, Bereichen oder Tätigkeiten beschäftigen. Diese Benutzer können dann unter Auswahl eines vordefinierten Kommunikationskanals (z.B. e-Mail, Voice-over-IP, Chat) kon- taktiert werden.

Die zum Kontaktieren interessanten Benutzer bzw. Kollegen können dabei insbesondere folgende Eigenschaften haben:

- Sie arbeiten in der gleichen Ordnung (Bereich, Thema, Teilbaum, Gruppierung) oder haben gleiche Zugriffsberechtigungen;

- sie arbeiten oft zur gleichen Zeit im System; und/oder - sie haben eine ähnlich aktive oder passive Usage, sie nutzen also beispielsweise Anwendungsprogramme in ähnlicher Weise.

Die gefundenen interessanten Benutzer werden bei diesem Vorgehen insbeson- dere in Abhängigkeit der übereinstimmenden Ähnlichkeiten der geographischen Nähe, der Anzahl indirekter Bekanntschaften oder der Anzahl gemeinsam genutzter Ordnungen in einer Reihung dargestellt.

Da jeder der interessanten Benutzer selbst ein auf einem Basisobjekt beruhendes Objekt ist, kann er von dem interessierten Benutzer als solches sofort in seine

Datenstruktur aufgenommen und beispielsweise in einem Adressbuch gespeichert und verwaltet werden.

Die Tatsache, dass der interessante Benutzer, ein modifiziertes Basisobjekt ist, kann im computerimplementierten System und Verfahren ferner dazu genutzt werden auf einheitlichen Wegen Kommunikationskanäle bereitzustellen.

Zugleich stehen dem Benutzer des computerimplementierten Systems und Verfahrens gemäß dem Ausführungsbeispiel sämtliche Ordnungsmöglichkeiten zur Verfügung, wie sie bereits oben beschrieben wurden. So können insbesondere jene Benutzer, mit denen öfter Kontakt besteht, in einen so genannten Collea- guesContainer zusammengefasst werden oder die Relevanz von Verbindungen zu anderen Benutzern kann vom System automatisch basierend auf der Relevanz des interessanten Benutzers sowie die Aktualität, Intensität und Dauer der Zu- sammenarbeit, der Ähnlichkeit der Tätigkeiten und Ähnlichem gewichtet werden.

Das System „weiß" ferner, wann interessante Benutzer ansprechbar sind, nämlich insbesondere dann, wenn sie selbst das System benutzen.

Die interessanten Benutzer können ferner vorteilhaft in einer Landkarte dem interessierten Benutzer mit ihrer Örtlichkeit angezeigt werden. Da wie oben erläutert innerhalb des Ausführungsbeispiels auch ganze Skripte und Applikationen von Programmprodukten als modifiziertes Basisobjekt abgebildet werden können und entsprechend auch ihre Benutzung überwacht werden kann, stehen für das erfindungsgemäße prinzipielle Merkmal Socializing auch Daten zur Verfügung, die Aussagen erlauben, welche Benutzer welche Skripte und Applikationen oft benutzen. Auf diese Weise können z.B. relevante Experten für die Applikationen gefunden werden.

Das erläuterte Vorgehen ermöglicht es auch, von interessanten Benutzern die weiter interessanten Kollegen zu ermitteln. Ferner können vorteilhafte Themenlandschaften, Wissensnetze und deren Experten auf Suchanfragen hin generiert werden. Fig. 15 zeigt dazu einen so genannten Expertenraum, welcher erfindungsgemäß für einen Benutzer 108 in dessen aktueller Situation interessante Experten 110 geordnet visualisiert. Der Benutzer 108 steht dabei im Zentrum einer flächigen Darstellung, in der die Experten 110 als Punkte bzw. Kreise dargestellt sind. Die Größe der Punkte bzw. Kreise ist proportional zur Relevanz als Experte für die dargestellte Ordnung. Die Größe des Punktes bzw. Kreises des Benutzers 108 steht ebenfalls im Verhältnis zu der Größe der Punkte bzw. Kreise den anderen Experten 110. Der Abstand zu den Experten 110 ist proportional zu bisherigen Gemeinsamkeiten zueinander. Diese Gemeinsamkeiten ergeben sich z.B. aus der Dauer der Zusammenarbeit, der Anzahl gleicher benutzter Objekte und dergleichen. Die Kreise sind ferner mittels einer Farbe und/oder einer Schraffur dahingehend zu unterscheiden, ob die dargestellten Experten 110 bereits Kollegen sind oder nicht. Farbe und/oder Schraffur geben auch an, ob der gefundene Experte 110 gerade das System benutzt. Aus der Darstellung gemäß Fig. 15 kann der Benutzer 108 ferner das Verhältnis der Experten 110 untereinander erkennen. Experten 110, die nahe beieinander angeordnet sind, bilden so genannte Cluster von Experten, die auf ähnlichem Gebiet tätig sind. Es ergeben sich also völlig neue Möglichkeiten für einen Benutzer des computerimplementierten Systems und Verfahrens gemäß dem Ausführungsbeispiel einen Überblick über die Themensituation in einem Unternehmen, über mögliche Wissenslücken, über Experten und „AHrounder" sowie über verwandte Themengebie- te zu erhalten.

Besonders vorteilhaft wird innerhalb eines computerimnlementierten Systems und Verfahrens gemäß dem Ausführungsbeispiel ausgehend von den Basisobjekten auch eine Kommunikation zwischen Benutzern des Systems dargestellt. Dieses prinzipielle Merkmal nennen wir Communication.

Es werden dabei zunächst verschiedene Kommunikationsmöglichkeiten unterschieden. Eine erste Kommunikationsmöglichkeit ist die asynchrone Kommunikation, bei der die Benutzer zeitversetzt Beiträge zu der Kommunikation leisten. Dies kann beispielsweise in einem Diskussionsforum durch Fragen, Antworten, Hinweise, Zustimmungen, Ablehnungen und dergleichen geschehen.

Interessant ist dabei, dass gemäß der oben erläuterten Vorgehensweise zwischen einem Notizenbaum und einer Diskussion im Grunde genommen nicht unter- schieden werden muss. Es kann vielmehr jede Kommunikation dadurch abgebildet werden, dass jeder einzelne Kommunikationsbeitrag als ein Basisobjekt datentechnisch abgebildet bzw. dargestellt wird. Eine Kommunikation zwischen zwei Benutzern wird auf diese Weise in eine Reihe von Verbindungsobjekten aufgelöst, die jeweils einzeln einen Kommunikationsbeitrag umfassen. Die Verbindungsob- jekte können in einem Container zusammengefasst im System gehandhabt und nur bei Bedarf einzeln aufgeschlüsselt werden.

Der Übergang in eine synchrone Kommunikation erfolgt oft schleichend, indem die Kommunikationsbeiträge nur knapp nacheinander erstellt werden. Eine klassische synchrone Kommunikation ergibt sich beispielsweise bei einem Telefongespräch. Auch diese Form von Kommunikation kann mit der oben genannten Systematik innerhalb des Ausführungsbeispiels leicht gehandhabt werden, indem die einzelnen Kommunikationsbeiträge in Form von gerichteten Verbindungsobjekten abgebildet werden. Die Richtung gibt dann an, welcher Teilnehmer den (gegebenenfalls zeitgleichen) Kommunikationsbeitrag abgegeben hat. Dem derartigen Ver- bindungsobjekt kann der Inhalt einer Audiodatei zugeordnet werden, die den Kommunikationsbeitrag wiedergibt. Zusätzlich können die Verbindungsobjekte mit Tags versehen werden, welche beispielsweise auch automatisiert aus der Audiodatei generiert werden können.

So können insbesondere auch „geschlossene Kommunikationssysteme" aufgebaut werden, innerhalb denen das derzeit bestehende Problem von Zugriffsberechtigungen oder Spam vermieden werden kann, da alle Benutzer des Systems zumindest als modifiziertes Basisobjekt bekannt sein müssen.

Auch eine themenbezogene Zuordnung und Ablage von Kommunikationsvorgängen wie beispielsweise e-Mails ist mit diesem Vorgehen erheblich einfacher und weitgehend automatisiert möglich.

Mit dem System des Ausführungsbeispiels ist auf die oben genannte Weise ins- besondere ein so genanntes Shared-white-board realisiert, bei dem sich mehrere Benutzer eine Darstellungsoberfläche teilen, und ein so genanntes Application- sharing oder Desktop-sharing, bei dem mehrere Benutzer gleichzeitig an einer Computeranwendung arbeiten.

Die Vorteile sind insbesondere, dass die Kommunikation insgesamt nachvollziehbar archiviert werden kann, dass durch die Passive Usage in Kombination mit der Active Usage ein zusätzlicher Mehrwert an Informationen entsteht, dass schneller ein Überblick über Strukturen und Gruppierungen erhalten werden kann und dass Information zwischen den Benutzern selbst auf verschiedensten Informationska- nälen einfach befördert kann. Das derart entwickelte System ist vorteilhaft ferner weiter dahingehend ausgestaltet, dass ausgehend von Basisobjekten mindestens ein Werkzeug für eine Zusammenarbeit zwischen Benutzern des Systems datentechnisch abgebildet bzw. dargestellt ist. Das zugehörige prinzipielle Merkmal nennen wir Collaboration.

Es ermöglicht es den Benutzern des computerimplementierten Systems und Verfahrens besonders einfach gemeinsam an Aufgaben im Team zu arbeiten. Dabei werden für die Teamarbeit bekannte Werkzeuge wie eine Notizfunktion, eine gemeinsame Dateiablage, eine Aufgabenliste, ein Diskussionsforum, ein Organi- gramm, eine Liste häufiger Fragen (FAQ) und/oder ein Kalender ausschließlich basierend auf modifizierten Basisobjekten abgebildet werden. Die Modifikation erfolgt dazu wie oben erläutert durch das Zuordnen von Fähigkeiten.

Wichtig ist bei dieser Vorgehensweise, dass sämtliche Werkzeuge innerhalb des Systems mittels Objekten abgebildet werden, die alle die Möglichkeiten der genannten Basisobjekte bieten. Erst durch diese streng gleichartige Strukturierung des Systems und Verfahren können die genannten prinzipiellen Merkmale auf alle Objekte in der dargestellten Weise angewendet werden.

So wird mit dem System gemäß dem Ausführungsbeispiel z.B. ein Programmprodukt gestaltet, bei dem ein Wartungsmitarbeiter sämtliche Wartungsaufträge mit der dabei zu Grunde liegenden Fehlermeldung eines Kunden (beispielsweise als Audiodatei einer telefonischen Störungsmeldung) zur Verfügung hat und dabei zugleich auch auf den bisherigen Betriebsablauf der zu wartenden Anlage, deren Bedienungsanleitungen, deren Betriebsparameterverlauf und sogar auf andere

Wartungsexperten zugreifen kann. Der Wartungstechniker kann ferner seine Wartungsarbeiten innerhalb des derartigen Programmprodukts auf einfache Weise dokumentieren und zur Abrechnung bringen.

Ein Unternehmen bzw. ein Team innerhalb eines Unternehmens können so komplett virtuell abgebildet und unterstützt werden, indem das System und Verfahren gemäß dem Ausführungsbeispiel als ein intelligenter Wissensspeicher für alle projektbezogenen Informationen und dem sich dabei ergebenden Informationsaustausch genutzt wird.

Bezugszeichenliste

10 Zeitstrahl

12 Zeitpunkt

14 Zeitintervall (Objekt sichtbar)

16 Zeitpunkt

18 Zeitintervall (Objekt nicht sichtbar)

20 Zeitachse

22 Bewertungsachse

24 Linie

26 Pool an Fähigkeiten

28 Folder

30 Tasklist

32 Task

34 Anlage

36 Notiz

38 Bewertung

40 Frage

42 Diskussion

44 Ordner

46 DateProperty

48 TimeProperty

50 DateTimeProperty

52 LocationProperty

54 DateTimeLocationProperty

56 Verbindungsobjekt

58 I nformationsobjekt

60 Steckdose

62 Stecker 64 Spalte

66 Spalte

68 Spalte

70 Spalte

72 Spalte

74 Spalte

76 UsageConnection

78 Benutzer

80 Informationsobjekt

82 Eingabemaske

84 Tag

86 Visibility

88 Anzeige

90 Informationsobjekt

92 Informationsobjekt

94 Verbindungsobjekt

96 TagConnection

98 Tag

100 TagBundleConnection

102 TagBundle

104 Verbindungsobjekt

104a Verbindungsobjekt

104b Verbindungsobjekt

104c Verbindungsobjekt

106 Autor

108 Benutzer

110 Experte

Claims

Ansprüche

1. Computerimplementiertes System zum strukturierten Speichern von Daten mindestens eines vordefinierten Ablaufs, um diese weiterverarbeiten zu können, bei dem der vordefinierte Ablauf mittels zweier Stati und einem Statusübergang definiert ist, von denen die Stati je als ein Informationsobjekt (58) und der Statusübergang als ein Verbindungsobjekt (56) abgebildet ist, das die beiden Informati- onsobjekte (58) verbindet.

2. Computerimplementiertes System nach Anspruch 1 , bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) während des Betriebs des computerimplementierten Systems mindestens eine Fähigkeit (Capability) annehmen und diese Fähigkeit auch wieder ablegen kann.

3. Computerimplementiertes System nach Anspruch 2, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbin- dungsobjekt (56) die Fähigkeit annehmen und ablegen kann, gerichtet zu werden, abgesichert zu werden, bewertet zu werden, gewichtet zu werden, eine Information zu tragen, seine Änderung nachzuvollziehen, auf seine Änderung überwacht zu werden und/oder einem Ablauf zu unterliegen.

4. Computerimplementiertes System nach Anspruch 2 oder 3, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) durch Annehmen und Ablegen von Fähigkeiten während des Betriebs des computerimplementierten Systems für seine Aufgabe angepasster gestaltet worden ist (Evolution), insbesondere zu einem andere Objekte enthal- tenden Objekt.

5. Computerimplementiertes System nach einem der Ansprüche 1 bis 4, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) eine Eigenschaft und/oder Fähigkeit tragen kann, welche eine Anpassung einer allgemeineren Eigenschaft bzw. Fähigkeit darstellt.

6. Computerimplementiertes System nach einem der Ansprüche 1 bis 5, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) eine Eigenschaft und/oder eine Fähigkeit tragen kann, welche eine Zusammenstellung mehrerer allgemeinerer Eigenschaften bzw. Fähigkeiten darstellt.

7. Computerimplementiertes System nach einem der Ansprüche 1 bis 6, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) dazu eingerichtet ist, dass es während des Betriebs des compu- terimplementierten Systems seine Nutzung protokolliert (Usage).

8. Computerimplementiertes System nach einem der Ansprüche 1 bis 7, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) dazu eingerichtet ist, dass es gemäß seinem vordefinierten Ab- lauf, der angenommenen Fähigkeit, der Art seiner Zusammenstellung aus mehreren Objekten, der Art der Zusammenstellung mehrerer allgemeiner Eigenschaften und/oder seiner protokollierten Nutzung geordnet werden kann (Swarm).

9. Computerimplementiertes Verfahren zum strukturierten Speichern von Da- ten mindestens eines vordefinierten Ablaufs, um diese weiterverarbeiten zu können, bei dem der vordefinierte Ablauf mittels zweier Stati und einem Stausübergang definiert ist, von denen die Stati je als ein Informationsobjekt (58) und der Statusübergang als ein Verbindungsobjekt (56) strukturiert gespeichert wird.

10. Computerimplementiertes Verfahren nach Anspruch 9, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) während des Betriebs des computerimplementierten Systems mindestens eine Fähigkeit (Capability) annimmt und diese Fähigkeit auch wieder ablegen kann.

11. Computerimplementiertes Verfahren nach Anspruch 10, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) die Fähigkeit annimmt und ablegen kann, gerichtet zu werden, abgesichert zu werden, bewertet zu werden, gewichtet zu werden, eine Informati- on zu tragen, seine Änderung nachzuvollziehen, auf seine Änderung überwacht zu werden und/oder einem Ablauf zu unterliegen.

12. Computerimplementiertes Verfahren nach Anspruch 10 oder 11 , bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbin- dungsobjekt (56) durch Annehmen und Ablegen von Fähigkeiten während des Betriebs des computerimplementierten Systems für seine Aufgabe angepasster gestaltet wird (Evolution), insbesondere zu einem andere Objekte enthaltenden Objekt.

13. Computerimplementiertes Verfahren nach einem der Ansprüche 9 bis 12, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) eine Fähigkeit und/oder eine Eigenschaft trägt, welche eine Anpassung einer allgemeineren Eigenschaft bzw. Fähigkeit darstellt.

14. Computerimplementiertes Verfahren nach einem der Ansprüche 9 bis 13, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) eine Fähigkeit und/oder eine Eigenschaft trägt, welche eine Zusammenstellung mehrerer allgemeinerer Eigenschaften bzw. Fähigkeiten darstellt.

15. Computerimplementiertes Verfahren nach einem der Ansprüche 9 bis 14, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbindungsobjekt (56) während des Betriebs des computerimplementierten Systems seine Nutzung protokolliert (Usage).

16. Computerimplementiertes Verfahren nach einem der Ansprüche 9 bis 15, bei dem das einzelne Informationsobjekt (58) und/oder das einzelne Verbin- dungsobjekt (56) gemäß seinem vordefinierten Ablauf, der angenommenen Fähigkeit, der Art seiner Zusammenstellung aus mehreren Objekten, der Art der Zusammenstellung mehrerer allgemeiner Eigenschaften und/oder seiner protokollier- ten Nutzung geordnet wird (Swarm).