Private Kontexte

In Zusammenhang mit der Vergabe von Zugriffsrechten (s. Abschnitt 2.1) ist die Unter-scheidung von allgemein zugänglichen, globalen und für den Nutzer reservierten lokalen Kontexten, wie sie im System CONCORDE [Hofmann et al. 90] vorgesehen sind, mit eingeschlossen. KHS stellt allerdings keinen Zusammenhang zwischen Speicherort und Zugänglichkeit eines Objekts her.

3.2.2 Pfade

Eine Möglichkeit, den Leser von Desorientierungsproblemen zu entlasten, ist, ihm eine Empfehlung hinsichtlich einer sinnvollen Leseabfolge von Hypertext-Knoten vorzugeben.

Derartige Strukturen sind als Trails schon in die Konzeption des Memex eingegangen [Bush 91] und als Pfade oder Guided Tours [Trigg 88] in einigen Hypertextsystemen zum Einsatz gekommen. Gemeinsamer Kern der Pfadmechanismen ist, daß eine Sequenz von Knoten vom Leser durch eine einfache Operation (nexf) verfolgt werden kann und daß für den Autor adäquate Operationen zur Modifikation von Pfaden zur Verfügung stehen.

Diese einfache Auffassung von Pfaden wird von [Zellweger 89] ausgeweitet und präzisiert, wobei folgende Typen von Pfaden unterschieden werden:

• Sequentielle Pfade bestehen als einfachste Form von Pfaden nur aus einer Reihung von Knoten.

• Verzweigende Pfade enthalten Verzweigungspunkte, an denen der Leser entscheiden muß, welchem der alternativen Teilpfade er folgen will.

• Bedingte Pfade legen die endgültig zu durchlaufende Textsequenz erst zur Naviga-tionszeit aufgrund pfadspezifischer Bedingungen fest.

• Prozedurale Pfade können Pfade als Teile enthalten.

• Programmierbare Pfade sind bedingte Pfade, bei deren Traversierung pfadspezifische Variablen modifiziert werden. Der Inhalt dieser Variablen ist dann Grundlage für die Auswahl von Verzweigungen bei der weiteren Navigation (z.B. indem eine Schleife abgebrochen wird).

• Variable Pfade enthalten variable Verknüpfungen, deren Ziel erst zur Traversie-rungszeit durch Suche im Hypertext oder andere verknüpfungsspezifische Berech-nungsprozesse ermittelt wird.

• Parallele Pfade können simultan verfolgt werden.

Die Spezifikationsmethode für Pfade unterscheidet sich zwischen den verschiedenen Hypertextsystemen zum Teil erheblich. Es ist jedoch festzustellen, daß Systeme, deren Pfadmechanismus über die einfachen Knotenlisten von Textnet hinausgehen, Pfade zumeist anhand einer Skript-Sprache definieren. Exponent dieses Ansatzes ist das Scripted Documents System, das ausschließlich Pfade, die in der Skript-Sprache Cedar definiert sind, für die Verknüpfung von Hypertextobjekten nutzt. Dieser prozedurale Ansatz spiegelt sich auch in der oben angeführten Pfad-Klassifikation wider, indem Konstrukte der Programmierumgebung (z.B. Variable, Schleifen) in die Pfadtypologie Eingang fanden.

Abbildung 6 Spezifikation von Pfaden durch Strukturknoten: zwei Strukturknoten, l und 2, enthalten je eine Sequenz von Teilknoten, die sich zu einem sequentiellen Pfad reihen. Da diese Sequenzen sich überlappen, entsteht ein verzweigter Pfad, der dem Nutzer an den Positionen 9 und 8 die Gelegenheit zum Pfadwechsel gibt.

Da der Strukturknoten 2 in den Strukturknoten l eingebettet ist, entsteht hier ein prozeduraler Pfad.

Im Modell des KHS werden Pfade auf elementarere Aggregierungskonstrukte, insbe-sondere auf Strukturknoten abgebildet (s.a. Abb. 6). Strukturknoten geben die Art der Ordnung ihrer Teilknoten vor, dabei sind typspezifische Sortierkriterien vorzusehen, wie

• alphabetisch nach Titel,

• nach Erzeugungsdatum und anderen Zeitangaben.

Die Sequenz der Teilknoten kann nun als Pfad interpretiert werden. Prozedurale Pfade entstehen durch die Schachtelung von Strukturknoten. Ist ein Teilknoten in mehreren Strukturknoten enthalten, kann dieser als ein Verzweigungspunkt des Pfades interpretiert werden. Die Entscheidung, welcher Pfad weiter verfolgt werden soll, kann aufgrund einer Nutzerentscheidung oder vom System anhand von Kontextbedingungen (s. Kapitel 4) getroffen werden. Damit sind die strukturellen Eigenschaften von Pfaden, wie sie von [Zellweger 89] beschrieben wurden, auf ein in annähernd allen Hypertextmodellen verfügbares Aggregierungskonstrukt abgebildet. Die Skript-Sprache von Scripted Documents erlaubt aber zusätzlich noch die pfadspezifische Zuordnung von Aktionen zu einzelnen Knoten. Dies wird im KHS erreicht, indem spezielle kontextabhängige Verknüpfungen mit Aktionen versehen und den im Pfad befindlichen Knoten zugeordnet werden. Parallele Pfade unterscheiden sich von anderen nur dadurch, daß sie gleich viele Elemente haben. Auf ihnen können dann navigationsynchrone Kontexte (s. Abschnitt 4.3.4) eröffnet werden.

Das Verfolgen von Pfaden kann im KHS auch von Nutzeraktionen unabhängig gemacht werden, indem Pfade nach einem festgelegten zeitlichen Schema automatisch abgespielt werden. Derartige Präsentationen können vom Leser jederzeit unterbrochen und wieder aufgenommen werden.

3.2.3 Versionierung

Die Verwaltung unterschiedlicher Versionen von Hypertexten ist eine wichtige Aufgabe von Hyperbasesystemen. Die existierenden Ansätze für Hypermediasysteme wurden von Ansätzen für Version-Control-Systeme aus dem Software-Engineering inspiriert. Eine ausführlichere Erläuterung wird hier z.B. von [Hicks et al. 91] gegeben. Wichtig ist insbesondere der Unterschied zwischen Versionierungsverfahren, die auf der Repräsentation von Objektzuständen beruhen, und solchen, die nur die Änderungen (Deltas) speichern.

Zustandsbasierte Versionierung von Hypertexten beruht zumeist auf zusammengesetzten Objekten, sogenannten Kontexten, welche die verschiedenen Versionen eines Objekts enthalten, wie es z.B. in Neptune [Delisle & Schwartz 87] der Fall ist. Im Modell des KHS werden Kontexte als spezifische Ausprägungen von Strukturknoten aufgefaßt. Ein Knoten kann in mehrere Kontexte eingefügt, und dann in individuelle Versionen aufgespalten werden, die jeweils modifiziert werden können. Der Umstand, daß alle diese Knoten modifizierte Fassungen eines Ursprungsknotens sind, wird vom KHS durch einen besonderen Verknüpfungstyp repräsentiert (Revision-Of), durch den ein Versionsgraph analog der Derivation History von CoVer aufgebaut wird, so daß nicht nur Revisionen, sondern auch Varianten eines Objekts angelegt werden können. Dieser Ansatz erweist sich als befriedigend, wenn Versionen eines Dokuments in neue inhaltliche Zusammenhänge eingebracht werden sollen, oder wenn mehrere Personen in jeweils individueller Arbeitsumgebung an Varianten eines Dokuments arbeiten, die dann später wieder zusammengeführt werden sollen.

Eine andere Anwendung von Versionen ist aber dann gegeben, wenn Varianten eines Dokuments vom selben Autor in derselben Anwendungssituation erstellt werden, z.B.

Varianten einer Programmkomponente, die in der gleichen Softwareumgebung gegeneinander getestet werden sollen. In diesem Fall ist es sinnvoll, wenn die Versionen eines Knotens nicht über verschiedene Kontexte verteilt werden müssen. KHS orientiert sich hier an dem zustandsorientierten Versionenkonzept von CoVer [Haake 94], indem alle Versionen eines Objekts in ihrem Versionsknoten, einem speziellen Strukturknoten zusammengefaßt werden, der den Multiple State Objects (mobs) von CoVer oder den VersionGroups von HyperPro [0sterbye 92] vergleichbar ist. Allerdings ist eine explizite Versionierung von Verknüpfungen

zur Zeit nicht vorgesehen, d.h. das im Versionierungsfall eine Modifikation von Verknüpfungen auf eine Modifikation von Knoten abgebildet werden muß [0sterbye 92].

Referenzen auf den versionierten Knoten erfolgen dann durch Referenz auf den Versi-onsknoten, sowohl hinsichtlich der Einbettung in Strukturknoten als auch bei Referenz durch Verknüpfungen. Der Versionsknoten ist durch die ihm zugeordneten Aktionen so ausgelegt, daß für Navigation und Retrieval immer die Inhalte der jeweils relevanten Version genutzt werden. Anders als in CoVer erfolgt diese Zuordnung nicht durch eine spezielle Attribuierung der Verweise, sondern über den situativen Kontext (s. a. Abschnitt 4.3.5), der eine Versionskennung oder eine Versionsspezifikation vorgibt. Damit wird ein von [0sterbye 92]

identifiziertes Manko des CoVer Ansatzes entschärft. Indem die Versionsspezifikation nicht fest mit den Verknüpfungen verbunden wird, wird der Autor von Spezifikationsaufwand entlastet und ergibt sich die Möglichkeit, eine situationsspezifische Auswahl der zu nutzenden Version vorzusehen. Standard ist der Zugriff über eine Spezifikation, welche die neueste Version bevorzugt. Soll eine Verknüpfung kontextunabhängig nur auf eine Version des versionierten Knotens Bezug nehmen, so kann sie explizit auf die Version verweisen. Damit ermöglicht das Versionenkonzept des KHS die Unterscheidung von generic version links und specific version links, wie sie auch von HyperPro vorgesehen werden (s.a. Abb. 7). Die Knoten innerhalb eines Versionsknotens sind durch Verknüpfungen zu einem Versionsgraphen verbunden (Revision-Of). Knoten, die sich nicht an den Blättern des Versionsgraphen befinden, werden automatisch eingefroren, d.h. daß Inhalt und Attribute nicht mehr modifiziert werden können. Diese Einschränkung bezieht sich allerdings nicht auf die Annotierbarkeit von Versionen.

Ein zentrales Problem der Versionierung von Hypertexten ist die Wahl einer adäquaten Strategie zur Erzeugung von Versionen. Während Neptune jede Änderung eines Hyper-textobjekts zum Anlaß nimmt, eine neue Version zu erzeugen, überlassen CoVer und in Anlehnung daran auch das KHS diese Entscheidung der konkreten Applikation, um die Erzeugung unnötiger Versionen zu vermeiden.

Im Zusammenhang mit dem Entstehen neuer Versionen ergibt sich auch das Problem, größere Hypertext-Segmente, die in ihrem aktuellen Zustand für die Funktionsfähigkeit des versionierten Objekts von Bedeutung sind, zusammen mit diesem "einzufrieren" [0sterbye 92]. Eine Lösung für dieses Problem ist im KHS noch nicht konzipiert.

Abbildung 7 Versionierung von Knoten — Der Knoten Kl liegt in sechs Versionen vor. Der Strukturknoten K2 enthält den Versionsknoten und nimmt damit Bezug auf die Version von Kl, die anhand des situativen Kontexts als relevant ausgewählt wird (z.B. die neueste Version, die von einem bestimmten Autor angelegt wurde). K3 hingegen nimmt expliziten Bezug auf die Version V6 von Kl, der Inhalt von K3 wird also von etwaigen Versionsänderungen von Kl nicht betroffen. Ähnlich bezieht sich eine von K2 ausgehende Verknüpfung auf die kontextspezifisch relevante Version von Kl und eine explizit auf die Version VI. Zusätzlich zeigt eine Verknüpfung ungeachtet der Versionen von Kl ausgehend auf K4, während eine andere nur von der Version V6 ausgeht.