DE69625884T2

DE69625884T2 - Informationswiederauffindungssystem

Info

Publication number: DE69625884T2
Application number: DE69625884T
Authority: DE
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1995-11-17
Filing date: 1996-11-15
Publication date: 2003-08-28
Anticipated expiration: 2016-11-16
Also published as: EP1251437A3; JPH09325968A; EP0774722A2; EP0774722B1; EP1251438A2; EP1251437A2; EP1251438A3; DE69625884D1; EP0774722A3; US5907837A

Description

Die vorliegende Erfindung betrifft Informationswiederauffindungssysteme und insbesondere ein System und ein Verfahren zum Indexieren, Abfragen und Wiederauffinden von Informationen in einem Online-Netzwerk.
Microsoft Network, das Internet, Compuserve, Prodigy und America Online sind Beispiele von Online-Netzwerken. Endbenutzer greifen typischerweise unter Verwendung eines mit einem Modem ausgerüsteten Mikrocomputers auf diese Netzwerke zu. Während einer Online-Sitzung kann ein Benutzer eine Vielfalt von informationsbezogenen Diensten und Kommunikationsdiensten einschließlich Nachrichtendiensten, Wetterdiensten, Anschlagbrettdiensten, E-Mail und dergleichen, verwenden.
Wenngleich Online-Dienste immer beliebter werden, befinden sich gegenwärtige Online-Anwendungen immer noch im Anfangsstadium. Tatsächlich hindern erhebliche Probleme unabhängige Inhaltsanbieter oder Verleger nach wie vor daran, fortgeschrittene und verlockende Dienste einzusetzen, die zum Bereitstellen eines tragfähigen Online-Geschäfts erforderlich sind. Gleichzeitig arbeiten Anbieter existierender Online- Dienste daran, das richtige technische Geschäftsmodell und Gebrauchslösungen zu finden, die die Akzeptanz über die Kreise früher Anhänger hinaus fördern.
In jeder großen Stadt ist es für eine Einzelperson unmöglich, mit den in der Gemeinschaft stattfindenden Aktivitäten und Ereignissen auf dem Laufenden zu sein. Daher wenden sich die Menschen an Schriftsteller, Reporter, Redakteure, Kritiker u.a., um Hilfe beim Verstehen und Strukturieren der verfügbaren Informationen zu erhalten. Eine verwandte Tendenz besteht darin, daß Rundfunk- und Fernsehmedien immer weniger in der Lage sind, die Bedürfnisse verschiedener einfacher Bevölkerungsteile zu befriedigen. Daher werden auf den meisten Märkten gezielte Medien (Medien, die ihren Inhalt auf kleinere, gut definierte Kreise zugeschnitten und verteilt haben) immer beliebter und einträglicher. In der Online-Gemeinschaft wird diese Tendenz entsprechend wichtiger werden.
Ein Problem, auf das Inhaltsanbieter beim Erzeugen von Anwendungen für den Massenmarkt stoßen, besteht im vielschichtigen Auditorium. Beispielsweise sind einige Kunden an Spielen, einige an Wirtschaft, einige an der Computertechnologie und einige am Kino interessiert. Welche Informationen sollten Inhaltsanbieter bereitstellen, damit ihre Kunden zufrieden bleiben? Es ist ein System erforderlich, das es einem Inhaltsanbieter ermöglicht, Anwendungen zu erzeugen, die die redaktionelle Sprache des Inhaltsanbieters mit individueller kundenspezifischer Anpassung verbinden. Beispielsweise könnte ein Kunde aus einer bestimmten Anwendung heraus ein Interesse am Computergeschäft und/oder an klassischer Musik angeben und in der Lage sein, auf diese Bereiche konzentrierte zusätzliche Informationen zu gewinnen. In ähnlicher Weise könnte eine Online-Veröffentlichung den Inhalt auf der Grundlage verschiedener Verbraucherpräferenzen automatisch erzeugen und mit Prioritäten versehen.
Gegenwärtige Veröffentlichungssysteme umfassen Software zum elektronischen Veröffentlichen von Beiträgen über Online- Netzwerke, wie CompuServe, America On-Line oder das Internet. Durch die meisten dieser Systeme werden Beiträge erzeugt und angezeigt, die in verallgemeinerter Standard-Markierungssprache (SGML) oder in Hypertext-Markierungssprache (HTML) formatiert sind. HTML und SGML sind Standards für das Markieren von Text in Dokumenten, die in einem Online- Netzwerk anzuzeigen sind. In HTML oder SGML formatierte Dokumente können durch mehrere weitverbreitete Browser, wie Mosaic und Netscape für das Internet, betrachtet werden. Diese Browser-Programme lesen mit SGML- und HTML-Tags markierte Dokumente und stellen sie mit der richtigen Formatierung dar. Die Formatierungsinformationen sind jedoch am Browser gespeichert und werden vom Verleger nicht verteilt.
Computerbenutzer suchen in plattenbasierten Computersystemen und in Online-Umgebungen nach Informationen. In einer Personalcomputerumgebung sind die meisten Computerbenutzer an ein Stöberungsmodell (Browsing Model) des Navigierens durch den Inhalt gewohnt. Die Festplatten auf Personalcomputern waren bisher ziemlich groß, sie hatten aber einen handhabbaren Umfang. Benutzer stellen den Inhalt auf ihren Platten selbst zusammen, so daß dies eine begrenzte Struktur ist, die Benutzer recht bequem durchsuchen können. Der Festplatteninhalt hat einen bekannten Kontext, weil die Elemente Seite an Seite angeordnet sind. Hierdurch wird eine gute Organisation des Materials erzielt und auch ein ungezwungenes Suchen gestattet. Benutzer brauchen kein bestimmtes Ziel im Sinne zu haben, können aber in zufälliger Weise nach Informationen stöbern und diese finden. Das Problem besteht hierbei jedoch darin, daß dies auf große Informationsmengen nicht gut übertragbar ist.
Bei der Online-Arbeit wird es alleine schon durch den Umfang des Inhalts unvernünftig, auf diese Weise zu stöbern. Daher ist eine Suchstrategie erforderlich, die es Personen ermöglicht, weitere Kriterien oder Spezifikationen für eine Einrichtung oder Agentur zu spezifizieren, die diese tatsächlich aufnimmt und die Übereinstimmungsprüfung für sie ausführt. Wenn die Suchergebnisse oder Treffer vom Benutzer empfangen werden, sind sie in einer angemessenen Menge vorhanden, die ein Benutzer tatsächlich durchsuchen kann. Einige der bei dieser Vorgehensweise auftretenden Probleme bestehen darin, daß diese Ergebnisse häufig aus dem Kontext herausgerissen werden und der Benutzer keine Vorstellung vom benachbarten Material hat, so daß der Benutzer dabei sehr zielgerichtet sein muß.
Einige Online-Systeme, wie Microsoft Network (MSN), Prodigy, Compuserve und America Online, haben einen Typ einer Abteilungsstruktur. Bei dieser Struktur gibt es eine Oberebenen-Kategorisierung von Geschäfts- und Finanzinteressen oder bestimmten speziellen Interessen, die eine redaktionelle Betrachtung einer Inhaltsaufteilung als eine Art, Informationen zum Durchsuchen durch Personen zu organisieren, vorsieht. Das bei dieser Vorgehensweise auftretende Problem besteht natürlich darin, daß die Vorstellungen von Personen darüber, wo sich ein bestimmtes Thema befindet, verschiedenen sein können. Beispielsweise kann eine Person in einem Bereich nach Informationen über das Sporttauchen suchen, während eine andere Person unter einer ganz anderen Kategorisierung suchen kann. Weil Personen verschiedene Vorstellungen darüber haben, wo Themen gespeichert sind, tritt beim Suchen nach Informationen häufig eine Nichtübereinstimmung auf, wenn eine Person entsprechend der Klassifikation und Kategorisierung einer anderen stöbert.
Ein weiteres Online-System ist das Internet World Wide Web (WWW). Das WWW bietet durch die Art, in der Verknüpfungen zwischen verwandten Informationen hergestellt sind, ein reiches Medium. Unter Verwendung von Verknüpfungen und Verweisen können viele verschiedene Redakteure unterschiedliche Inhaltsbetrachtungsweisen verbreiten. Daher ist das WWW nicht durch eine, sondern durch viele Strukturen gegeben. Ein Benutzer identifiziert sich häufig mit einem bestimmten Verzeichnisdienst, der der Art entspricht, in der er Informationen begreift, wodurch das Durchsuchen erleichtert wird. Das Problem besteht schon alleine wegen der Größe des Webs darin, daß es nicht erschöpfend durchsucht werden kann. Der Benutzer behält immer das Gefühl, daß es noch etwas anderes im Web gibt. Ein Benutzer bekommt beim eigentlichen Suchen kein sehr gutes Gefühl eines Abschlusses.
Einige der Techniken zum tatsächlichen Durchsuchen des Internets sind auf Crawlern beruhende Volltextindizes. Dieser Typ eines Indexierers durchläuft tatsächlich die verschiedenen Internetseiten und baut dabei einen Index auf, so daß Personen auf einer bestimmten Aktualisierungsbasis suchen und sehen können, welcher neue Inhalt auf dem Web erscheint. Wiederum bleibt bei Benutzern oft das Gefühl zurück, daß sie nicht wissen, wie vollständig eine Suche ist. Verschiedene Indizes haben möglicherweise Zugang zu Seiten, zu denen andere keinen Zugang haben. Es gibt keine wirklich klare Art des Auffindens des gesamten gewünschten Inhalts. WAIS stellt einen Internetserver bereit, der Textzeichenketten über mehrere Datenbanken indexiert und abruft. Dieser Server beruht auf dem sich entwickelnden 239.50-Suchprotokoll, das bei WAIS- und Gopher-Seiten verwendet wird.
Ein Beispiel eines auf einem WWW-Crawler beruhenden Indexierers ist der Web Crawler. Eine andere WWW-Indexiermaschine ist als Lycos bekannt. Die Lycos-Maschine nimmt eine gewichtete zufällige Auswahl von Verknüpfungen vor, denen in einem Dokument zu folgen ist, wobei der Schwerpunkt auf Dokumente gelegt wird, die mehrere auf sie verweisende Verknüpfungen (was Beliebtheit andeutet) und Verknüpfungen mit kürzeren Pfadnamen (URLs) aufweisen, wobei dies auf der Theorie beruht, daß kurze Pfadnamen gewöhnlich flachere Web- Verknüpfungen und daher eine größere Breite bedeuten. Lycos versucht, eine Zusammenfassung eines Dokuments zu erstellen, um seinen Inhalt zu bewahren, während die Unwirksamkeit der Katalogisierung des gesamten Dokuments vermindert wird. Die Lycos-Suchsprache unterstützt keine Booleschen Abfragen (UND, ODER usw.) bzw. Nachbarschaftssuchen.
Ein weiterer sich in Entwicklung befindender WWW- Indexierer ist das Harvest-Projekt. Harvest bietet ein Mittel zum Sammeln und Verteilen von Indexinformationen, unterstützt den Aufbau verschiedener Typen von Indexen für jede Informationssammlung und bietet eine Cache-Speicherungs- und Replikationsunterstützung.
Ein weiteres bei den gegenwärtigen Indexierern auftretendes Problem besteht darin, daß die Versuche, die Server auf dem Web zu durchlaufen, viel Zeit in Anspruch nehmen. Wenn neuer Inhalt zu einem Server hinzugefügt wird, auf den ein aktueller Indexierer gerade zugegriffen hat, kann eine lange Zeit verstreichen, bevor der Indexierer zurückkehrt und den Server wieder indexiert. Alternativ kann der Inhalt aus einem Server entfernt werden, der Indexierer hat jedoch keine Möglichkeit, dies zu erfahren, bevor der Server wieder besucht wird. Diese Indexierer sind auch für einen "Roboterausschluß" anfällig, wodurch das Indexieren eines Webservers verhindert wird. Eine "Keine-Roboter"-Norm wird auf einigen Webservern verwendet, wodurch verhindert wird, daß irgendein Teil des auf dem Server vorhandenen Inhalts in den Index aufgenommen wird. Es ist eine Indexier- und Suchkomponente eines Informationswiederauffindungsdienstes gewünscht, die immer aktuell ist und den gesamten Inhalt des Systems oder des Online-Dienstes indexieren kann.
Das Gewinnen von Inhalt für einen Online-Dienst ist kein größeres Problem, sobald aber dieser ganze Inhalt zu einer enormen Größe anschwillt, besteht das Problem in der Fähigkeit des Benutzers, den ganzen Inhalt zu durchdringen und spezifische gewünschte Informationen aufzufinden. Es ist für die Online-Industrie erforderlich, daß Inhaltsanbieter ihre Informationen mit Tags markieren können und ihre Kunden direkt ansprechen können, um diese Verbindung von beiden Seiten herzustellen und die Inhaltsübergabe erfolgreich zu machen. Um dieses Problem durch die herkömmlichen Online- Dienste zu veranschaulichen, kann ein Administrator daher das Verfahren verwenden, einen neuen Dienst bereitzustellen, der in den Online-Modus geschaltet wird und sich in mehreren Orten befindet. Ein häufig auftretendes Problem besteht darin, daß ein Benutzer möglicherweise denkt, daß sich der Dienst irgendwo anders befindet und daher keine Verbindung hergestellt wird. Daher ist ein Verfahren zu einer Volltextsuche über einen gesamten Online-Dienst erforderlich.
Dieses Durchsuchen sollte das Suchen von Text, wie der Eigenschaften (beispielsweise Bilder, Beiträge, Ton-Clips) und Titel verschiedener verfügbarer Dienste, sowie das Suchen in den Titeln, beispielsweise einem Artikel oder einem Beitrag, ermöglichen. Somit wäre ein Benutzer beispielsweise in der Lage, Dienste anhand einer Beschreibung von Eigenschaften zu durchsuchen.
Ein Verleger könnte ein Suchobjekt definieren, um den gewünschten Kriterien entsprechenden Inhalt abzurufen. Der Verleger könnte auch spezifizieren, wo gesucht werden muß. Demgemäß wäre ein System und ein Verfahren zum Indexieren strukturierter Titel und Suchobjekte in der Industrie ein Fortschritt.
Die vorstehend angegebenen Nachteile werden durch die vorliegende Erfindung überwunden.
Die Erfindung wird durch die Merkmale der Ansprüche spezifiziert.
Ein Informationswiederauffindungsserver (IR-Server) indexiert und durchsucht Beiträge und andere Inhaltsobjekte, wie Bilder und Ton-Clips, in Titeln in einem Online-Netzwerk. Das Indexieren findet statt, wenn ein Titel durch einen Arbeitsplatzrechner des Verlegers in das Netzwerk freigegeben wird. Falls ein Inhaltsobjekt aus dem Netzwerkserver gelöscht wird, wird der IR-Server benachrichtigt. Demgemäß hat der IR-Server einen aktuellen Index des gesamten Inhalts auf dem Netzwerk, sobald der Inhalt veröffentlicht oder gelöscht wird.
Der IR-Server bringt einen Titel, einen Abschnitt und Beitragsobjekte anhand ihrer global eindeutigen Kennungen in Beziehung zueinander und erzeugt eine Leitwegtabelle, die zum Auffinden von Objekten über mehrere Datenbankpartitionen verwendet wird. Eine Partition ist für die Quelle und den Datumsbereich spezifisch. Ein IR-Suchdienst wird von der Titelbetrachtungseinrichtung am Kundenarbeitsplatzrechner auf zwei verschiedene Arten angefordert. Erstens wird eine Suche nach jedem dynamischen Steuerelement oder Anzeigebereich in einem Titel angefordert. Ein dynamisches Steuerelement ist Beiträgen zugeordnet, die auf der Grundlage einer vom Verleger definierten Suchabfrage aufgefunden wurden. Zweitens kann eine Suche von einem Kunden eingeleitet werden, der einen Suchdialog verwendet, um alle Beiträge in einem Titel sowohl dynamisch als auch statisch zu suchen. Die IR-Funktion wird durch Zerlegen eines Titels in Inhalts- und Entwurfsobjekte ermöglicht, und sie erfüllt den Bedarf an einer schnellen und wirksamen Suche über einen Kommunikationsweg mit geringer Bandbreite, beispielsweise 9600 Baud.
Eine Erscheinungsform der vorliegenden Erfindung ist ein Verfahren zum computergestützten Suchen, welches die Schritte des Speicherns mehrerer Inhaltsstücke in einem Veröffentlichungsspeicher, des Veröffentlichens eines Titels am Veröffentlichungsspeicher, wobei der Inhalt und das Layout im Titel getrennt sind, wobei das Layout eine einem Steuerelement zugeordnete Suchabfrage aufweist und wobei das Steuerelement einen Bereich zur Anzeige von Ergebnissen der Suchabfrage definiert, des Abrufens des die Abfrage erfüllenden Inhalts aus dem Veröffentlichungsspeicher und des Anzeigens des abgerufenen Inhalts im Steuerelement aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung ist ein computergestütztes Informationswiederauffindungssystem, welches einen Veröffentlichungsspeicher, der einen Inhaltsspeicher, einen Indexierer zum Indexieren des Inhalts und eine Sucheinrichtung bzw. ein Suchprogramm zum Erfüllen von Abfragen für die Indizes aufweist, eine Entwurfseinrichtung bzw. ein Entwurfsprogramm, das einen Titel mit einem oder mehreren Suchobjekten versieht, wobei jedes Suchobjekt eine Abfrage definiert, und eine Betrachtungseinrichtung bzw. ein Betrachtungsprogramm, das auf den Titel zugreift und die Suchobjekte den anzuzeigenden Inhalt auffinden läßt, aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung in einem Computernetzwerk ist ein Indexiersystem für einen Titel, der ein Titellayout und einen Inhalt aufweist, wobei das Titellayout Suchobjekte aufweist, wobei das Titellayout, der Inhalt und die Suchobjekte jeweils eine zugeordnete Objektkennung aufweisen und der Inhalt Sucheigenschaften aufweist, wobei das System einen den Titel empfangenden Indexserver, eine Katalogdatenbank mit Tabellen, die anderen Informationen einschließlich Sucheigenschaften Objektkennungen zuordnen, einen Indexdienst, der auf dem Indexserver ausgeführt wird und auf die Katalogdatenbank zugreift, und einen Datenbankserver, der Indexzuordnungen zwischen den Sucheigenschaften und den vom Indexdienst bereitgestellten Objektkennungen speichert, aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung ist ein durch Computer implementiertes Verfahren zum Durchsuchen eines Titels, welches die Schritte des Speicherns des Inhalts in einem Veröffentlichungsspeicher, des Veröffentlichens eines Titels, dessen Inhalt und Layout getrennt sind, am Veröffentlichungsspeicher und des Abrufens des eine Benutzerabfrage erfüllenden Inhalts aus dem Veröffentlichungsspeicher aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung ist ein Verfahren zum computergestützten Suchen, welches die Schritte des Veröffentlichens eines Titels an einem den Inhalt aufweisenden Veröffentlichungsspeicher, wobei der Inhalt und das Layout des Titels getrennt sind und wobei das Layout eine Suchabfrage aufweist, des Abrufens des die Benutzerabfrage erfüllenden Inhalts aus dem Veröffentlichungsspeicher und des Anzeigens des abgerufenen Inhalts aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung ist ein computergestütztes Verfahren zum elektronischen Veröffentlichen, welches die Schritte des Erzeugens eines eine Suchabfrage enthaltenden Titels, des Speicherns des Titels in einem Veröffentlichungsspeicher und des Anzeigens des Titels, wobei die Suchabfrage Inhalt aus dem Veröffentlichungsspeicher abruft, aufweist.
In einem Computernetzwerk ist ein Suchsystem vorgesehen, welches einen Suchobjektserver zum Speichern des Orts von Suchobjekten in einem Titel und den Suchobjekten zugeordneten Suchabfragen, einen Suchserver zum Zerlegen der Suchabfragen in mehrere Teilabfragen und einen Datenbankserver zum Empfangen von Teilabfragen vom Suchserver und zum Bereitstellen von Objektkennungen in Reaktion auf jede Teilabfrage aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung ist ein computergestütztes Verfahren zum Durchsuchen eines Titels unter Verwendung einer Suchabfrage, welches die Schritte des Speicherns von Inhalt in einem Veröffentlichungsspeicher, des Prüfens eines Such-Cache-Speichers auf die Suchabfrage und die Inhaltsidentifikation darstellende Ergebnisse, des Abrufens der Ergebnisse der Suchabfrage aus dem Such-Cache-Speicher, falls die Suchabfrage im Such-Cache- Speicher vorhanden ist, des Erzeugens einer oder mehrerer Teilabfragen auf der Grundlage der Suchabfrage, des Prüfens des Such-Cache-Speichers auf das Vorhandensein einer der Teilabfragen und eines Ergebnisses der Teilabfrage, falls die Suchabfrage nicht im Such-Cache-Speicher vorhanden ist, des Abrufens der Ergebnisse der Teilabfrage aus dem Such-Cache- Speicher, falls die Teilabfrage im Such-Cache-Speicher vorhanden ist, des Anwendens der Teilabfrage für einen Datenbankserver, des Abrufens der Ergebnisse der Teilabfrage aus dem Datenbankserver, falls die Teilabfrage nicht im Such- Cache-Speicher vorhanden ist, und des Abrufens des Inhalts aus dem Veröffentlichungsspeicher entsprechend den abgerufenen Ergebnissen aufweist.
Eine weitere Erscheinungsform der vorliegenden Erfindung in einem Computernetzwerk ist ein Informationswiederauffindungssystem, welches einen Veröffentlichungsspeicher, der einen Beitragsspeicher, einen Indexierer zum Indexieren der gespeicherten Beiträge und ein Suchprogramm zum Erfüllen von Abfragen für die Indizes aufweist, ein Entwurfsprogramm, das einen Titel mit einem oder mehreren Suchobjekten versieht, wobei jedes Suchobjekt eine Abfrage definiert, und ein Betrachtungsprogramm, das auf den Titel zugreift und die Suchobjekte anzuzeigende Beiträge auffinden läßt, aufweist.
Fig. 1 ist ein Blockdiagramm der Basissystemkonfiguration eines Multimedia-Veröffentlichungssystems (MPS), die die gegenwärtig bevorzugte zugrundeliegende Architektur für die vorliegende Erfindung ist.
Fig. 2 ist ein Diagramm der Hauptsystemkomponenten des in Fig. 1 dargestellten MPS unter Einschluß eines Betrachtungsprogramms und eines Entwurfsprogramms.
Fig. 3 ist ein Diagramm eines als Beispiel dienenden Online-Systems zum Speichern und Verteilen einer Veröffentlichung.
Fig. 4 ist ein Blockdiagramm der Wechselwirkung von Seitenlayouts, Steuerelementen, einer Stilvorlage und Inhaltsobjekten beim Betrachtungsprogramm aus Fig. 2.
Fig. 5 ist ein Blockdiagramm zur Darstellung der Wechselbeziehung zwischen dem Informationswiederauffindungssystem (IR-System) und dem MPS.
Fig. 6 ist ein Blockdiagramm der wichtigsten Softwarekomponenten des in den Fig. 1, 2 und 5 dargestellten Systems.
Fig. 7 ist ein Diagramm, in dem ein als Beispiel dienender MPS-Beitrag mit einer Wurzel, Sucheigenschaften, Text und eingebetteten Objekten dargestellt ist.
Fig. 8 ist ein Diagramm eines als Beispiel dienenden Titelbaums, der bei der in Fig. 2 dargestellten Betrachtungsprogrammkomponente erzeugt ist.
Fig. 9 ist ein Oberebenen-Flußdiagramm des Betrachtungsprogrammprozesses für die in Fig. 2 dargestellte Betrachtungsprogrammkomponente.
Fig. 10 ist ein Diagramm zur Darstellung einer Abfrage, die vom Kunden unter Verwendung eines Suchdialogs beim in den Fig. 1 und 5 dargestellten System ausgeführt wird.
Fig. 11 ist ein Flußdiagramm der Wechselwirkung des Betrachtungsprogramms mit dem in den Fig. 5 und 10 dargestellten IR-System.
Fig. 12 ist ein Diagramm der Suchobjekten zugeordneten Datenstrukturen und Server des IR-Systems.
Fig. 13 ist ein Flußdiagramm eines Titelveröffentlichungsprozesses beim IR-System aus Fig. 5.
Fig. 14 ist ein Flußdiagramm des in Fig. 13 dargestellten IR-Indexierprozesses.
Fig. 15 ist ein Flußdiagramm der in Fig. 14 dargestellten Titelverarbeitungsfunktion.
Fig. 16 ist ein Flußdiagramm der in Fig. 15 dargestellten Inhaltsverarbeitungsfunktion.
Fig. 17 ist ein Flußdiagramm des in Fig. 11 dargestellten Suchobjekt-Auflösungsprozesses.
Fig. 18 ist ein Flußdiagramm der in Fig. 17 dargestellten Suchanforderungs-Auflösungsfunktion.
Fig. 19 ist ein Flußdiagramm der in Fig. 18 dargestellten Anforderungsverarbeitungsfunktion.
Fig. 20 ist ein Diagramm der Komponenten und Strukturen des in den Fig. 3 und 5 dargestellten IR-Systems.
Fig. 21 ist ein Diagramm der einer Kundenabfrage zugeordneten Datenstrukturen und Server des IR-Systems.
Fig. 22 ist ein Diagramm einer als Beispiel dienenden Suchdialog-Bildschirmanzeige, die vom in Fig. 2 dargestellten Betrachtungsprogramm angezeigt wird.
Fig. 23 ist ein Diagramm einer als Beispiel dienenden Sucheigenschafts-Bildschirmanzeige, die vom in Fig. 2 dargestellten Verleger angezeigt wird.
Fig. 24 ist ein Diagramm einer als Beispiel dienenden Dokumenteditoreigenschafts-Bildschirmanzeige, die vom in Fig. 2 dargestellten Verleger angezeigt wird.
Es wird nun auf die Zeichnung Bezug genommen, in der gleiche Bezugszahlen überall gleiche Teile bezeichnen. Aus Zweckmäßigkeitsgründen ist die nachfolgende Beschreibung in die folgenden Hauptabschnitte eingeteilt: Abkürzungen, Vorteile des Informationswiederauffindungssystems, Übersicht über das Multimedia-Veröffentlichungssystem, Übersicht über die Informationswiederauffindung (IR), IR-Indexierung, Suchobjektauflösung, Kundenabfragenauflösung und Schlußbemerkung.

I. ABKÜRZUNGEN

Die folgende Abkürzungsliste ist als eine Bezugsquelle beim Lesen der restlichen Abschnitte vorgesehen.
BBS - Anschlagbrettsystem ("Bulletin Board System")
MPML - Multimedia-Veröffentlichungs-Markierungssprache
COS - Caching-Objekt-Speicher
DBM - Datenbank-Verwaltungssystem
DLL - Bibliothek für dynamische Verknüpfungen
GUID - Global eindeutige Kennung
HTML - Hypertext-Markierungssprache
ICP - Unabhängiger Inhaltsanbieter
IM - Informationsmagnet
IP - Informationsanbieter
IR - Informationswiederauffindung
LAN - Lokales Netzwerk
MP - Multimedia-Veröffentlichung
MPC - Prozeduraufruf in Microsoft Network
MPS - Multimedia-Veröffentlichungssystem
MFC - Microsoft Foundation Class
MSN - Microsoft Network
OCX - OLE-Steuerung
OLE - Objektverknüpfung und -einbettung
PDA - Persönlicher digitaler Assistent
SGML - Verallgemeinerte Standard-Markierungssprache
WAN - Weiträumiges Netzwerk
WWW - World-Wide Web

II. VORTEILE DES INFORMATIONSWIEDERAUFFINDUNGSSYSTEMS

Die vorliegende Erfindung kann vielleicht den größten Nutzen bieten, wenn ein Online-Netzwerk verwendet wird. Daher bieten dieser und die nachfolgenden Abschnitte Hintergrundinformationen zu einem bevorzugten Online-Veröffentlichungssystem, das die Grundlage bildet, auf der die vorliegende Erfindung aufbaut.
Ein wichtiger Vorteil des MP-Systems besteht in der Fähigkeit zum dynamischen Auffinden und Anzeigen des Inhalts während der Laufzeit. Unter Verwendung dieser Technik kann ein Verleger einen Titel laufend ändern, indem er lediglich den Inhalt aktualisiert, der in verschiedenen Ordnern oder Containern innerhalb des Haupttitels untergebracht wurde. Wenn eine Seite angezeigt wird, zeigt sie den aktualisierten Inhalt. Dies ist eine dynamische Titelsynthese, die das fortlaufende Aktualisieren des Inhalts ermöglicht, ohne daß ein Modifizieren und Aktualisieren des Titelentwurfs erforderlich wäre, der aus den einzelnen Seiten, Steuerelementen und dem von Hand angeordneten Inhalt besteht und zur Anzeige des Inhalts verwendet wird. Wenn Verleger die dynamische Synthese verwenden, erstellen sie Titel, die Platzhalter enthalten, welche durch den sich ändernden Inhalt ausgefüllt werden. Die dynamische Synthese wird durch das Erzeugen und Auflösen von Suchobjekten erleichtert, die den gewünschten Inhalt in den Containern des MP-Systems auffinden. Suchobjekte können verwendet werden, um es Inhaltsanbietern oder Verlegern zu ermöglichen, den Inhalt aufweisende Ordner unter mehreren Titeln gemeinsam zu benutzen.
Als ein Beispiel der Verwendung von Suchobjekten beim Entwickeln von Anwendungen sei das Beispiel einer Online- Zeitung betrachtet. Es sei angenommen, daß die Zeitung aus Abschnitten einschließlich eines Wirtschaftsteils besteht. Die die Zeitung entwerfenden Personen fügen während des Entwurfs ein Suchobjekt in den Wirtschaftsteil der Zeitung ein. Dieses Suchobjekt definiert die Inhaltsordner, denen der Inhalt zu entnehmen ist. Beispielsweise kann das Suchobjekt (durch Festlegen seiner Eigenschaften) so programmiert werden, daß es innerhalb des Wirtschaftsteils alle Beiträge im Inhaltsordner für Wirtschaft und alle Berichte im Inhaltsordner für Börsenberichte enthält. Ein Suchdialog erlaubt es Kunden, den Wirtschaftsteil im wesentlichen zu personalisieren, indem beispielsweise ein Abfragekriterium bereitgestellt wird, das den Umfang angezeigter Wirtschaftsbeiträge auf eine bestimmte Industrie beschränkt. Alternativ kann der Produzent der Online-Veröffentlichung einzelnen Benutzern gezielte, kundenangepaßte Versionen der Veröffentlichung anbieten, indem er die Suchobjekteigenschaften auf der Grundlage von Kundenprofilen oder ausgedrückten Interessen programmatisch modifiziert.
Das MP-System beinhaltet weiterhin einen Indexierprozeß, um die Eigenschaften und den Text des gesamten veröffentlichten Inhalts zu indexieren. Der Suchdialog ermöglicht es einem Kunden, den indexierten Inhalt aufzufinden, der mit einer Benutzersuchabfrage übereinstimmt. Weitere Vorteile und Nutzeffekte des MP-Systems werden nachfolgend in Einzelheiten erörtert.
Um weitere Einzelheiten zu den Vorteilen des MP-Systems bereitzustellen, bietet der folgende Abschnitt eine Übersicht über das Multimedia-Veröffentlichungssystem.

III. ÜBERSICHT ÜBER DAS MULTIMEDIA-VERÖFFENTLICHUNGSSYSTEM

Dieser Abschnitt gibt eine Übersicht über die Konfiguration und die Hauptkomponenten des bevorzugten Multimedia-Veröffentlichungssystems. Dieser Abschnitt beginnt mit einer Beschreibung des wichtigen Konzepts der Trennung des Entwurfs (oder des Titellayouts) und des Inhalts und setzt sich mit einer Erörterung der Hauptkomponenten und der Konfiguration des MP-Systems fort.
Die vom MP-System verwendeten Objekte umfassen ein Projekt, einen Titel, einen Inhaltsordner und wahlweise einen Inhaltsunterordner, einen Abschnitt und wahlweise einen Unterabschnitt, ein Fenster, eine Seite, ein Steuerelement, eine Stilvorlage und verschiedene Inhaltsobjekte (wie Beiträge, Bilder, Audioinformationen usw.). Diese Objekte werden nachfolgend mit Bezug auf Fig. 4 in näheren Einzelheiten erklärt. Es ist wichtig zu verstehen, daß diese Objekte in einem nichtflüchtigen Computerspeicher in der Art eines Festplattenlaufwerks gespeichert werden müssen.
Die natürliche Art zum Speichern verwandter und geordneter Objekte ist das Speichern in einer Datenstruktur in der Art eines azyklischen Graphen. Die gegenwärtig bevorzugte Art zum Speichern der Objekte eines MP-Systems wird als Caching-Objekt-Speicher (COS) bezeichnet. Beim gegenwärtig bevorzugten MPS entspricht jeder Titel einem COS. Es gibt mindestens einen COS am Arbeitsplatzrechner des Verlegers und auf jedem MPS-Server im Veröffentlichungs- Speicher- und -Verteilungszentrum (Fig. 2). Jeder Kundenarbeitsplatzrechner verfügt auch über einen COS, so daß der Kunde beim Zusammensetzen des Inhalts zu Steuerelementen auf Seiten Objekte des MP-Systems speichern und auffinden kann.
Ein Titel kann breit so definiert werden, daß er eine Veröffentlichung (beispielsweise eine Zeitung), eine Dienstleistung (beispielsweise Börsennotierungen) oder eine Anwendung (beispielsweise eine Multimedia-Enzyklopädie) umfaßt. Wenn ein Titel betrachtet wird, öffnet das Betrachtungsprogramm eine den Titel darstellende Titeldatei. Diese Titeldatei ist eine COS-Datei. Beim Online-Szenario ist dies typischerweise ein Skelettitel. Ein Skelettitel befindet sich in einer COS-Datei, die nur einen Wurzelbeinamen und keine wirklichen Objekte enthält. Ein Beiname ist ein Objekt, das bei der Implementierung des COS verwendet wird und Identifikations- und Statusinformationen über COS-Objekte enthält.
Ein SuperCOS ist eine COS-Datei, die mehr als einen untergeordneten COS, der als ein SubCOS bekannt ist, enthält. Beispielsweise wird ein SuperCOS am Kundenarbeitsplatzrechner verwendet, um Objekte im Cache-Speicher zu speichern, die ferngesteuert aus dem Host-Datenzentrum abgerufen wurden, Solange diese im Cache-Speicher gespeicherten Objekte nicht veraltet sind oder gelöscht wurden, ist das Betrachtungsprogramm in der Lage, dieses Objekt bei der nächsten Anforderung des Objekts schnell bereitzustellen, statt es erneut aus dem Datenzentrum abzurufen. Hierdurch erzielt das MP-System einen enormen Geschwindigkeitsvorteil gegenüber anderen Online-Systemen.
Ein Beispiel des Bildaufbereitungsprozesses und einer Abfrage, die zur Anzeige des Titels für einen Kunden verwendet werden, wird in Zusammenhang mit Fig. 4 gegeben.

A. Trennung des Entwurfs und des Inhalts beim Multimedia- Veröffentlichungssystem

Wie vorstehend erörtert wurde, behält die MPS-Architektur eine klare Trennung zwischen Entwurfsinformationen und dem Inhalt, auf den dieser Entwurf angewendet wird, bei. Eine Sammlung von Seitenlayouts des Verlegers liegt in Form eines oder mehrerer Titel vor. Ein Titel ist eine Sammlung von Seitenlayouts in einer bestimmten Abfolge, die der Reihenfolge entspricht, in der Seiten betrachtet werden. Die Seitenlayouts beschreiben, wie der Kundenbereich eines Fensters erscheint, wenn eine Seite aufbereitet wird. Aufbereiten bezeichnet das Erzeugen einer Bitabbildung eines Anzeigebildschirms im Speicher vor der Anzeige des Bildschirms. Ein vollständiges Seitenlayout wird durch Anordnen von Steuerelementen auf einem leeren Seitenlayout erzeugt, wobei jedes Steuerelement einen Bereich umschreibt, in dem ein Inhaltsbestandteil angezeigt werden sollte. Die Einstellungen an jedem Steuerelement bestimmen den richtigen Ort, an dem nach dem in diesem Steuerelement anzuzeigenden Inhalt gesucht werden muß.
Der Inhalt nimmt die Form diskreter Objekte an, die jeweils eine Informationseinheit, beispielsweise einen Beitrag oder ein Bild, ausmachen. Diese Inhaltsobjekte weisen wohlbekannte und allgemein zugängliche Datenformate auf und können unter Verwendung eines beliebigen Werkzeugs erzeugt werden, das diese Datenformate unterstützt. In Inhaltsobjekten sind gewöhnlich keine Formatierungsinformationen codiert.
Wenn der Verleger den Titel (mit seinen Seitenlayouts) und die Inhaltsobjekte erstellt hat, werden der Titel und der Inhalt zusammen am öffentlichen Verteilungspunkt veröffentlicht. Verbraucher laden den Titel und die Inhaltsobjekte auf ihre Personalcomputer herunter, wo die MPS-Betrachtungssoftware die im Titel enthaltenen Seitenlayouts dazu verwendet, den Inhalt in der vom Verleger entworfenen visuell reichen Form zusammenzusetzen.

B. Systemkonfiguration

Mit Bezug auf Fig. 1 wird nun die Basissystemkonfiguration des Multimedia-Veröffentlichungssystems (MPS) 100 beschrieben, das eine bevorzugte Ausführungsform des Systems 100 ist. Nach Konvention wird der Begriff "Titel" zum Beschreiben des Gesamtplans oder der Vorschriften zum Zusammensetzen der vollständigen Online-MPS-Anwendung auf dem Computer eines Kunden verwendet.
Ein großer Teil der Leistungsfähigkeit des MP-Systems 100 liegt in seiner Fähigkeit, den Entwurf und den Inhalt vollkommen zu trennen, was es von bestehenden Online- und Multimedia-Veröffentlichungswerkzeugen unterscheidet, die einen Verleger oder Inhaltsanbieter, wie einen ersten Verleger 102, einen zweiten Verleger 104 oder einen Verleger M 106, zum Integrieren des Entwurfs und des Inhalts benötigen. Beim MP-System können Titel in der Art eines Titels A 140, eines Titels B 142 oder eines Titels P 144 in zwei Teile aufgeteilt werden, und zwar den Inhalt (148, 152, 156), also die Informationen in der Art von Bitabbildungen, Videoclips, Audioinformationen, Animationen oder Beiträgen, die einen Titel ausmachen, und das Titellayout, das auch als der Entwurf (146, 150, 154) bezeichnet wird, also die allgemeine Erscheinung und den allgemeinen Eindruck eines Titels. Um den Inhalt und den Entwurf unter Verwendung des MPS zu trennen, statt den Inhalt direkt auf einer Seite anzuordnen, kann ein Verleger den Inhalt, wie einen Satz von Inhaltsobjekten 112, 114 oder 118, in einem oder mehreren Containern eines Titels unterbringen und dann Abschnitte oder Unterabschnitte erzeugen, die Seiten mit speziellen Steuerelementen, wie einem Satz von Titellayoutobjekten 110 oder 116, welche den Inhalt während der Laufzeit dynamisch auffinden und anzeigen, enthalten.
Unter Verwendung dieser Technik kann ein Verleger einen Titel laufend ändern, indem er lediglich den Inhalt 112, 114, 116 aktualisiert, der in verschiedene Ordner oder Container innerhalb des Haupttitels gegeben wurde. Wenn eine Seite angezeigt wird, zeigt sie den aktualisierten Inhalt. Dies wird dynamische Titelsynthese oder dynamische Synthese genannt, und der Inhalt kann dadurch fortlaufend aktualisiert werden, ohne daß ein Modifizieren und Aktualisieren des Titelentwurfs erforderlich wäre, der aus den einzelnen Seiten, Steuerelementen und dem von Hand angeordneten Inhalt besteht und zur Anzeige des Inhalts verwendet wird.
Wenn Verleger die dynamische Synthese verwenden, erstellen sie Titel, die Platzhalter enthalten, welche durch den sich ändernden Inhalt ausgefüllt werden. Wenn die dynamische Synthese benutzt wird, wird ein Titel als eine Vorlage verwendet, und ein Abdruck ist der angezeigte ausgefüllte Titel. Jedesmal dann, wenn der Verleger den Inhalt in einem Titel aktualisiert und ihn für Kunden (die auch als Endbenutzer oder Client-Endbenutzer bekannt sind), wie einen ersten Kunden 160, einen zweiten Kunden 162 oder einen Kunden N 164, verfügbar macht, erstellt der Verleger eine neue Ausgabe dieses Titels. Wenn der Kunde mit dem Betrachten dieser Ausgabe beginnt, wird ein "Abdruck" vorgenommen, der einen Teil des Inhalts oder den gesamten Inhalt in der Ausgabe enthält.
Der Hauptvorteil dieser Methode besteht in ihrer Flexibilität. Einige Teile eines Titels können durch direktes manuelles Anordnen des Inhalts auf einer Seite erzeugt werden, und andere Teile können unter Verwendung der dynamischen Synthese erzeugt werden. Es sei jedoch bemerkt, daß der manuell auf Seiten angeordnete Inhalt statisch ist, er ändert sich also nur, wenn die den Titel erstellenden Personen die Seiten aktualisieren.
Zum Erstellen von Titellayouts und des Inhalts durch den Verleger zurückkehrend sei bemerkt, daß nach der Erstellung die Titellayouts 110, 116 und der Inhalt 112, 114, 118 freigegeben und in einem Veröffentlichungsspeicher 120 gespeichert werden. Der Speicher 120 kann in vielen Formen, wie beispielsweise einem Netzwerk 122, einem CD-ROM 124 und anderen Speichermitteln in der Art von Anschlagbrettern, magnetischen Medien, Kabelfernsehen und so weiter, implementiert werden.
Das gegenwärtig bevorzugte Netzwerk 122 ist das Microsoft Network (MSN), auf das beispielsweise durch Microsoft Windows 95 zugegriffen werden kann. Natürlich ist das MPS so ausgelegt, daß es übertragbar ist, so daß es auf jedem beliebigen Online-Netzwerk unter Einschluß von Internet, America On-Line, Compuserve und Prodigy, verwendet werden kann, jedoch nicht auf diese beschränkt ist.
Bei der gegenwärtig bevorzugten Ausführungsform des Speichers 122, wie dem MSN, verwenden viele Kunden ein MSN- Explorer-Werkzeug zum Erwerben und Aktivieren von MPS- Anwendungen.
Der MSN Internet Explorer ist das integrierte Navigationswerkzeug innerhalb von Windows 95, das zum Durchsuchen der MSN-Hierarchie und des Internets verwendet werden kann. Anspruchsvolle Kunden können andere, fortgeschrittenere MPS-Funktionen, wie das Suchen, das Planen und das automatische Zusenden, benutzen, falls diese Merkmale vom Verleger aktiviert wurden. Außer dem Durchsuchen mit dem Explorer oder der Planung einer automatischen Zusendung nach Haus können Kunden MPS-Anwendungen auf mehrere weitere Arten erhalten. Beispielsweise kann eine einzelne Anwendung über eine Diskette oder einen CD-ROM 124 verteilt werden, sie kann über E-Mail oder Anschlagbretter verteilt werden, oder die Anwendung kann direkt über eine Verknüpfung in anderen Anwendungen (wie beispielsweise dem System der gelben Seiten für das Microsoft Network) zugänglich sein. In jeder dieser Situationen erwirbt das MP-System 100 eine Anwendung für den Kunden.

C. Systemkomponenten

Mit Bezug auf Fig. 2 werden nun die bevorzugten Basiskomponenten des MP-Systems 100 beschrieben. Das System 100 beinhaltet einen Satz von Werkzeugen zum Entwerfen, Entwickeln und Betrachten von Multimedia-Online-Anwendungen. Ein Verleger in der Art des Verlegers 102 verwendet einen Verleger-Arbeitsplatzrechner (auch als Computer oder Maschine bekannt) 180 und eine Entwurfssoftwareumgebung 194 zum Erzeugen und Veröffentlichen der Titellayouts 110 und des Inhalts 112. Im System 100 könnte ein Verleger möglicherweise einfach einen Inhalt erzeugen und die Titellayouts eines anderen Verlegers verwenden. Die Titellayouts und/oder der Inhalt werden vorzugsweise in einem Netzwerk 122 gespeichert, das einen Hochleistungsserver zum Unterbringen von Online- Anwendungen aufweist. Das bevorzugte Netzwerk 122 wird in Zusammenhang mit Fig. 3 näher beschrieben. Ein Kunde, wie ein Kunde 162, verwendet einen Kundenarbeitsplatzrechner 182 und eine Laufzeit-Betrachtungssoftwarekomponente 202, um auf dem Netzwerk 122 gespeicherte MPS-Titel auf einer Sichtanzeige am Arbeitsplatzrechner 182 aufzufinden und zu aktivieren.
Das Entwurfsprogramm 194 ist eine erweiterbare Entwurfs- und Entwicklungsumgebung, die mehrere bevorzugte Softwarekomponenten aufweist. Diese umfassen einen Projekteditor 184 zum Verwalten von Titeln, Containern und Objekten, einen Seiteneditor 186 zum Erzeugen und Zusammensetzen von Seiten, einen Stilvorlageneditor 187 zum Editieren von Stilvorlagen, einen Suchobjekteditor 189 zum Erzeugen von Suchobjekten, ein Textverarbeitungsprogramm, wie einen MPS-Dokumenteditor 188, zum Erzeugen eines für das MP-System 100 optimierten Inhalts und optionale Werkzeuge von Drittentwicklern, wie einen Toneditor 190, einen Bildeditor 192 und einen Objekteditor 193 für andere Medien zum Erzeugen und Modifizieren von Tönen, Bildern, Videoinformationen, Animationen und anderen Inhaltsobjekten. Der bevorzugte Dokumenteditor zum Zuordnen des Textinhalts zu einem Autor ist eine erweiterte Version des Textverarbeitungsprogramms Microsoft Word 6.0 zum Erzeugen mit Tags markierter Hypertext-Dokumente. Diese Programme bilden zusammen die Entwurfsprogrammkomponente 194.
Der Projekteditor 184 wird zum Aufrufen eines Stilvorlageneditors 187 verwendet, der zum Erzeugen und Editieren von Stilvorlagen verwendet wird. Der Stilvorlageneditor 187 und Teile des Projekteditors 184 und des Seiteneditors 186 werden in nachfolgenden Abschnitten dieser Erörterung in Einzelheiten beschrieben.
Das MPS-Entwurfsprogramm 194 ist ein Microsoft Visual Basic ähnelndes seiten- oder formularbasiertes Entwicklungssystem. Die Entwicklungsumgebung ist graphisch und einfach in der Benutzung. Steuerelemente, die die auf dem Bildschirm erscheinenden Komponenten einer MPS-Anwendung darstellen, werden innerhalb von MPS-Seiten angeordnet. MPS-Seiten und Steuerelemente basieren vorzugsweise auf der Objektverknüpfung und -einbettung 198 (in Fig. 2), die eine Komponenten- Softwaretechnologie von Microsoft ist. Die OLE, die gegenwärtig in der Version 2 vorliegt, wird in Inside OLE 2 und OLE 2, Programmer's Reference, Bände 1 und 2, näher beschrieben, die alle von Microsoft Press veröffentlicht wurden. Zusätzlich enthält das Kapitel "Systemübersicht" von Class Library User's Guide for the MFC Class Library, Microsoft Corp., 1993, nähere relevante Informationen. Es können jedoch auch andere Architekturen zusammengesetzter Dokumente, wie OpenDoc, verwendet werden.
Ein Hauptmerkmal der OLE besteht in ihrer Fähigkeit zur Wechselwirkung, welche die Grundlage für eine Integration zwischen Anwendungen bildet. Diese Integration macht es erforderlich, mehrere Anwendungen Informationen in dieselbe Datei im zugrundeliegenden Dateisystem schreiben zu lassen. OLE definiert ein Modell mit der Bezeichnung "strukturierte OLE-Speicherung" zum Behandeln einer einzelnen Dateisystemeinheit als eine strukturierte Sammlung von Objekten zweier Typen, nämlich Speicher und Ströme. Diese Objekte wirken wie Verzeichnisse bzw. Dateien.
Das Modell der strukturierten OLE-Speicherung implementiert allgemein diese Objekte, und Anwendungen brauchen sie selten oder nicht zu implementieren. Wie alle anderen Objekte in der OLE implementieren diese Objekte Schnittstellen, und zwar IStream für Stromobjekte und IStorage für Speicherobjekte.
Ein Stromobjekt ist konzeptuell einer einzelnen Plattendatei gleichwertig. Ströme sind die grundlegenden Dateisystemkomponenten, in denen Daten untergebracht sind, wobei jeder Strom Zugriffsrechte und einen einzigen Suchzeiger aufweist. Durch seine IStream-Schnittstelle kann ein Strom aufgefordert werden, seine zugrundeliegenden Daten zu lesen, zu schreiben, zu durchsuchen und einige andere Operationen daran auszuführen. Ströme werden unter Verwendung einer Textzeichenkette benannt, und sie können jede beliebige innere Struktur aufweisen, weil sie einfach flache Byteströme sind. Überdies entsprechen die Funktionen in der IStream- Schnittstelle nahezu eineindeutig standardmäßigen auf der Dateihandhabung basierenden Funktionen, wie denjenigen in der ANSI-C/C++-Laufzeitbibliothek.
Ein Speicherobjekt ist konzeptuell einem Verzeichnis gleichwertig. Jeder Speicher kann ähnlich wie ein Verzeichnis jede beliebige Anzahl von Unterspeichern (Unterverzeichnissen) und jede beliebige Anzahl von Strömen (Dateien) enthalten. Weiterhin hat jeder Speicher seine eigenen Zugriffsrechte. Die IStorage-Schnittstelle umschreibt die Fähigkeiten eines Speicherobjekts, wie das Aufzählen von Elementen (dir), Verschieben, Kopieren, Umbenennen, Erzeugen und Löschen. Ein Speicherobjekt selbst, kann in der Anwendung definierte Daten nicht speichern, wobei es jedoch die Namen der darin enthaltenen Elemente (Speicher und Ströme) implizit speichert.
Die Technologie der strukturierten OLE-Speicherung löst mit vorherigen flachen Dateisystemen verbundene Probleme durch das erhöhte Niveau an Indirektheit eines Dateisystems innerhalb einer Datei. Bei der OLE kann eine bestimmte Anwendung eine strukturierte Hierarchie erzeugen, wobei die Wurzeldatei selbst viele Unterspeicher hat. Jeder Unterspeicher kann wiederum Unterspeicher enthalten usw.
Durch diese Struktur wird das Problem der Informationserweiterung in einem der Objekte gelöst, wobei das Objekt selbst die Ströme in seinem Steuerelement erweitert und die Implementierung des Speichers bestimmt, wo alle Informationen im Strom zu speichern sind.
Das MP-System 100 umfaßt eine Anzahl vorab paketierter Steuerelemente, wie Navigationssteuerelemente, Steuerelemente für formatierten Text, Multimedia-Steuerelemente und anderer spezieller Steuerelemente, die speziell zum Unterstützen der Erzeugung von MPS-Anwendungen ausgelegt sind. Weil das MPS auf der OLE beruht, können Drittentwickler auch ihre eigenen Steuerelemente zur Verwendung innerhalb des MPS entwerfen (unter Verwendung von Microsoft OLE Control Development Kit, der Microsoft Visual C++ 2.0 hinzugefügt ist). Auf diese Weise ist die MPS-Entwicklungsumgebung voll erweiterbar, so daß Kunden ihren MPS-Anwendungen neue Fähigkeiten hinzufügen können, indem sie zusätzliche Steuerelemente von Drittentwicklern kaufen oder ihre eigenen Steuerelemente erzeugen. Die MPS-Entwicklungsumgebung beinhaltet auch ein Scripterstellungs- und Fehlerbeseitigungssystem Visual Basic for Applications (VBA).
Während der Inhalt innerhalb der Steuerelemente angezeigt wird, die auf MPS-Seiten im MPS-Entwurfsprogramm 194 angeordnet wurden, kann der Inhalt mit einer beliebigen Anzahl existierender Werkzeuge von Microsoft und Drittentwicklern einem Autor zugeordnet werden. Ein solches Werkzeug zum Zuordnen von Hypertext zu einem Autor ist der MPS-Dokumenteditor 188, der spezielle MPS-Merkmale zum Erzeugen eines MPS-Texts und zum Markieren von diesem mit Tags unterstützt. Andere existierende Werkzeuge zum Erzeugen von Pixelmustern, komplexen Zeichnungen und anderer Multimedia-Inhalte können verwendet werden, um den innerhalb eines bestimmten OLE-Steuerelements angezeigten Inhalt zu erzeugen. Überdies arbeiten die meisten bestehenden OLE-Steuerelemente (ausführbare .ocx-Programme) in der MPS-Umgebung, wenngleich sie möglicherweise nicht für Online-Anwendungen optimiert sind. Beispielsweise könnte ein standardmäßiges OLE-Steuerelement zur fortgeschrittenen Video-Bilderzeugung (advanced video imaging - AVI) in einer MPS-Anwendung angeordnet werden.
Die Steuerelemente, die Teil des MP-Systems 100 sind, sind für eine Online-Datenübertragung bei geringer Bandbreite optimiert. Die Verwendung einer Datenübertragung bei großer Bandbreite liegt jedoch auch innerhalb des Schutzumfangs der vorliegenden Erfindung. Das MPS 100 ist für die Arbeit mit Informationen ausgelegt, die sich minütlich, täglich oder monatlich ändern können. Wenngleich also das MPS zum Erzeugen statischer Titel verwendet werden kann, die von Hand erstellt wurden und nicht leicht laufend aktualisiert werden können, besteht das Hauptziel des MP-Systems 100 darin, einen wirksamen, kostengünstigen Mechanismus zum Steuern der Erstellung und Verwaltung dynamischer, sich immer wieder ändernder Online-Anwendungen bereitzustellen. Weil dies zugleich eine offene Entwicklungsumgebung ist, können viele der Werkzeuge, die allgemein zum Erzeugen statischen Multimedia-Inhalts verwendet werden, leicht in das MP-System 100 aufgenommen werden.
Bei der Aktivierung durch den Kunden untersucht das Betrachtungsprogramm 202 die Komponenten eines gewählten Titels, um zu bestimmen, ob irgendwelche der zur Anzeige des abgedruckten Titels erforderlichen Informationen gewonnen werden müssen. Es gewinnt dann diese Informationen aus dem Veröffentlichungsspeicher 120 oder einem lokalen Speicher am Kundenarbeitsplatzrechner 182 und organisiert diese so, daß sie für den Kunden 162 angezeigt werden können. Demgemäß erfaßt ein abgedruckter Titel den Satz von Informationen, die dem Kunden zu einem gegebenen Zeitpunkt angezeigt werden. Mit anderen Worten können einige Titel jeden Tag oder häufiger einen neuen Abdruck erzeugen, wenn sich der Inhalt ändert. Andererseits können andere Titel statisch sein. Wenn ein statischer Titel aktiviert wird, muß kein anderer Abdruck vorgenommen werden, weil sich der Inhalt nicht geändert hat.
Wenngleich das Abdrucken eines statischen Titels unnötig erscheinen mag, können beim Prozeß des Organisierens und Anzeigens des Abdrucks Kundenpräferenzen und Anzeigegeräteeigenschaften berücksichtigt werden. Es sei beispielsweise angenommen, daß ein Kunde einen statischen Titel auf einem Laptop bei Verwendung des Laptop-Bildschirms aktiviert und später denselben Titel aktiviert, wenn der Computer an ein größeres Bildschirmgerät angeschlossen ist. Die zweite Aktivierung führt zu einem anderen Abdruck, um den viel größeren Bildschirmbereich zu berücksichtigen, falls der Verleger eine solche Option ermöglicht hat. Wenn der Titel aktiviert wird, bestimmt das MPS-Betrachtungsprogramm 202, ob der Titel veraltet ist, gewinnt alle nötigen Informationen und erzeugt dann bei Bedarf den Abdruck und personalisiert ihn möglicherweise.
Das MPS-Betrachtungsprogramm 202 erlaubt es Kunden, die folgenden Aktionen innerhalb der von Inhaltsanbietern definierten Grenzen auszuführen, nämlich die von einem Titel gewonnenen Informationen auszuwählen und zu personalisieren, die gesamten Struktureigenschaften von Titeln zu modifizieren, die Erscheinung und den Eindruck von Titeln zu personalisieren, den von Kunden gewonnenen Inhalt zu verwalten und zu archivieren und Gebühren- und Preisinformationen zu betrachten.
Die Anforderung an den bevorzugten Arbeitsplatzrechner 180 des Verlegers ist ein unter Windows 95 betriebener Arbeitsplatzrechner mit der minimalen Hardwarekonfiguration, die zum Betreiben der MSN-Systemoperator-Werkzeuge und zum Speichern und Anzeigen der momentan entwickelten Titel erforderlich ist. Der bevorzugte unter Windows 95 betriebene Arbeitsplatzrechner hat mindestens einen bei 33 MHz oder mehr arbeitenden Intel-486-Prozessor und einen Speicher von acht Megabytes. Ein mit 9600 Baud oder schneller arbeitendes Modem ist erforderlich, um die MSN-Systemoperator-Werkzeuge laufen zu lassen. Für Multimedia-Titel schließt dies einen MPC2- kompatiblen (für Multimedia konfigurierten) Arbeitsplatzrechner ein.
Das MPS-Betrachtungsprogramm 202 sollte am Kundenarbeitsplatzrechner 182 installiert werden, bevor ein MPS-Titel aktiviert wird. Der gegenwärtig bevorzugte Kundenarbeitsplatzrechner ist in der Lage, unter Windows 95 zu arbeiten. Zum Vereinfachen dieser Installation wird das Betrachtungsprogramm 202 automatisch auf dem Kundenarbeitsplatzrechner 182 installiert, wenn sich der Kunde zum ersten Mal mit MSN verbindet und das MP-System 100 aktiviert wird. MPS- Titel können Betriebsmittel, wie Schriftarten, Bibliotheken für dynamische Verknüpfungen (DLLs) und OLE-Steuerelemente, enthalten, die im Betriebsmittelcontainer oder im Ordner für MPS-Titel angeordnet werden. Bevor Kunden diese Titel betrachten können, werden diese Betriebsmittel auf ihrem Arbeitsplatzrechner 182 installiert.

D. Netzwerkspeicherung

Mit Bezug auf Fig. 3 wird ein als Beispiel dienendes Netzwerkspeicheruntersystem 122 beschrieben. Fig. 3 ist ein Diagramm der hohen Ebene, in dem die Grundkomponenten eines Online-Netzwerks 122 gemäß einer Ausführungsform der Erfindung dargestellt sind. Mehrere Verlegern 102, 104, 106 und Kunden 160, 164 zugeordnete Arbeitsplatzrechner sind durch ein weiträumiges Netzwerk (WAN) 240 mit einem Host- Datenzentrum 242 verbunden. Die Arbeitsplatzrechner der Verleger haben vorzugsweise schnelle Verbindungen mit dem WAN 240. Das weiträumige Netzwerk 240 umfaßt WAN-Leitungen 244, die von einem oder mehreren Telekommunikationsanbietern bereitgestellt werden und die es Endbenutzern (d.h. Verlegern und Kunden) in einem großen geographischen Bereich erlauben, auf das Host-Datenzentrum 242 über Modem zuzugreifen. Die WAN-Leitungen weisen vorzugsweise sowohl X.25- als auch ISDN- (Integrated Service Digital Network - integriertes digitales Fernmeldenetz)-Leitungen auf.
Das Host-Datenzentrum 242 weist mehrere Anwendungsserver 246 auf, die an ein schnelles lokales Netzwerk (LAN) 248 (das mehrere LANs umfassen kann) angeschlossen sind. Jeder Anwendungsserver 246 hat eine eindeutige Serverkennung. Wie in Fig. 3 dargestellt ist, sind drei der Server 246 MP- Systemserver (246a, 246b und 246c). An das LAN 248 sind auch mehrere Gateway-Computer 250, die auch als Gateways bezeichnet werden, angeschlossen, die eingehende Anrufe von Endbenutzern mit den Anwendungsservern 246 verbinden.
Es sei angenommen, daß das Host-Datenzentrum 242 vorteilhafterweise etwa einhundert Gateways 250 und zwischen mehreren Hundert und mehreren Tausend Anwendungsserver 246 aufweist. Ein Host-Datenzentrum dieses Typs ist in der Lage, Zehntausende gleichzeitige Benutzer-Anmeldungssitzungen zu handhaben.
Wie nachfolgend beschrieben wird, wird die Serverseite jedes Online-Dienstes vorzugsweise unter Verwendung (1) eines einzigen Anwendungsservers 246, (2) eines Satzes "replizierter" Anwendungsserver (also Anwendungsserver, die dieselbe n) Dienstanwendung(en) laufen lassen), die Zugriff auf replizierte (und lokal gespeicherte) Kopien von Dienst- "Inhalts"-Daten (also dem Endbenutzer des Dienstes bereitgestellte Daten) bereitstellen, oder (3) eines Satzes replizierter Anwendungsserver, die Zugriff auf serverspezifische (nicht replizierte) Dienstinhaltsdaten bereitstellen, implementiert.
Das Host-Datenzentrum 104 weist auch mehrere Zuteilercomputer 252 auf, die bestimmte Typen von Transaktionen überwachen, aufzeichnen und verarbeiten, um die Konsistenz zwischen replizierten Anwendungsservern zu gewährleisten. Das Host-Datenzentrum 104 umfaßt auch einen oder mehrere Kunden- Gateway-Computer 254, die das Host-Datenzentrum 104 mit einem oder mehreren externen Dienstanbietern 256, wie einem Kreditkartendienst, der die Gültigkeit von Kreditkartentransaktionen bestätigt und diese ausführt, verbindet.
Das Host-Datenzentrum 104 weist weiterhin eine Anzahl von Verwaltungsservern 258 auf. Die Verwaltungsserver 258 führen Verwaltungsfunktionen, wie die Rechnungsstellung, die Gebührenberechnung, die Netzwerkverwaltung, die Sicherung, die Gewährleistung der Systemsicherheit, die Leistungsfähigkeitsanalyse und die Zuordnung von Servern zu Diensten, aus.
Um Benutzer-Dienstanforderungen an die geeigneten Server 246 weiterzuleiten, müssen die Gateways 250 in irgendeiner Weise die eindeutigen Kennungen der Server bestimmen, die momentan die angeforderten Dienste handhaben. Dies wird mit Hilfe einer Dienstleistungskarte (nicht dargestellt) erreicht, die Informationen über jede Dienstleistung und jeden Server 246 im Host-Datenzentrum 242 enthält.
Die Dienstleistungskarte wird vorzugsweise durch einen Dienstleistungskarten-Dispatcher 260 erstellt, der auf einem einzelnen Computer implementiert sein kann.
Zusätzlich zur Erstellung einer Dienstleistungskarte unterhält der Dienstleistungskarten-Dispatcher 260 eine zentrale Informationsquelle, die als "globales Register" 262 bezeichnet wird. Das globale Register 262 enthält verschiedene Informationen über die gegenwärtige Konfiguration des Host-Datenzentrums 242. Beispielsweise gibt das globale Register 262 für jede Dienstgruppe die Kennungen der Server 246 einer Dienstgruppe und die Identität des der Dienstgruppe zugewiesen Zuteilercomputers 252 (falls vorhanden) an.
Es sind ein oder mehrere Informationswiederauffindungsdienste (IR-Dienste) in der Art eines IR-Dienstes 270 mit dem LAN 248 verbunden. Die IR-Dienste sind auch mit jedem anderen IR-Dienst (falls vorhanden) verbunden. Die IR-Dienste führen logisch eine IR-Gateway-Funktion für den Rest des IR- Untersystems aus. Der IR-Dienst 270 ist weiterhin logisch mit mehreren IR-Servern 1 bis N, wie einem IR-Server 272a, der ein Indexserver sein könnte, und einem IR-Server 272b, der ein Suchserver sein könnte, verbunden. Jeder IR-Server, wie die Server 272a und 272b, sind weiterhin mit mehreren Datenbankservern (DB-Servern) 1 bis N (wobei die Anzahl der IR-Server nicht unbedingt der Anzahl der DB-Server gleicht) wie einem DB-Server 276a, der beispielsweise ein SQL-Server sein könnte, und einem DB-Server 276b, der beispielsweise ein Fulcrum-Server sein könnte, verbunden. Beim gegenwärtig bevorzugten IR-Untersystem sind die IR-Server, die DB-Server und ein Abfrage-Cache-Speicher (nicht dargestellt) physikalisch mit einem MPS-LAN (nicht dargestellt) verbunden. Das MPS-LAN ist mit dem COS und dem IR-Gateway verbunden. Die IR- Server sind auch physikalisch mit dem LAN 248 verbunden.
Die weitere Offenbarung des bevorzugten Netzwerks 122 ist in einer anhängigen Anmeldung enthalten, die ebenfalls auf den Erwerber der vorliegenden Anmeldung, Microsoft Corporation, übertragen ist und am 7. Juni 1995 unter dem Titel "Architecture for Scalable On-Line Services Network", laufende Nr. 08/472 807, eingereicht wurde.

E. Beispiel eines Bildaufbereitungsprozesses

Mit Bezug auf Fig. 4 wird nun die Wechselwirkung Steuerelemente aufweisender Seitenlayouts mit Objekten beim Betrachtungsprogramm 202 (Fig. 2) am Kundenarbeitsplatzrechner 182 zur Bildaufbereitung von Seiten beschrieben. Das Betrachtungsprogramm 202 unterstützt das Anzeigen von Informationen durch Fenster. Das Anordnen, Organisieren und Festlegen der Anzahl der Fenster wird vom Verleger 102 gesteuert. Die Fenster des Betrachtungsprogramms sind Rahmenfenster von Windows 95. Diese Fenster werden vollkommen vom Entwurfsprogramm gesteuert. Das Entwurfsprogramm steuert das Betrachtungsprogramm 202 durch Erzeugen eines Titels. Der Titel legt die Größe und die Standardelemente (Titelbalken, Min/Max-Tasten, Überschrift, Umrandung, Menübalken) der verschiedenen vom Betrachtungsprogramm 202 angezeigten Fenster fest.
Der gesamte Kundenbereich eines Fensters des Betrachtungsprogramms wird zur Anzeige einer Reihe von Seiten verwendet. Jede Seite enthält einen Satz von Steuerelementen, die zur Anzeige des Inhalts, zur Navigation durch den Titel und zum Sammeln von Informationen vom Kunden verwendet werden. Ansprechend auf Kundenaktionen oder andere Ereignisse kann sich die angezeigte Seite während der Ausführung des Titels ändern. Dieses Verhalten wird vom Verleger 102 bestimmt. Ein Titel kann mehr als ein Fenster aufweisen, das zu jedem gegebenen Zeitpunkt sichtbar ist, und Popup-Fenster können modal oder nicht modal sein. Es kann nur ein Titel zu einem gegebenen Zeitpunkt in einem Fenster des Betrachtungsprogramms angezeigt werden.
In Fig. 4 ist ein Diagramm eines Titelseitenabschnitts 330 und eines Wirtschaftsteils 332 für einen Titel in der Art einer Zeitung dargestellt.

1. Titelseitenabschnitt

Der Titelseitenabschnitt 330 enthält eine Seite 334, die ein Bildsteuerelement 336 und einen Satz von statischen Beitragssteuerelementen, nämlich ein erstes Beitragssteuerelement 338, ein zweites Beitragssteuerelement 340 und ein drittes Beitragssteuerelement 342, aufweist. Jedes statische Beitragssteuerelement oder Bildsteuerelement ist während der Veröffentlichung mit nur einem Objekt verknüpft. Jedes der Steuerelemente auf der Seite 334 verweist auf eine Stilvorlage 343, um Formatierungsvorschriften bereitzustellen, nach denen der Inhalt anzuzeigen ist.
Wie in der gegenwärtigen Softwaretechnologie bekannt ist, kann eine global eindeutige Kennung (GUID) in objektorientierten OLE-Umgebungen verwendet werden, um ein Objekt mit einer eindeutigen Zeichenkette zu identifizieren. Normalerweise werden eindeutige GUIDs durch Verketten der Zeit, des Datums und der Seriennummer der Netzwerkkarte des Computers zur Zeit der Erstellung des Objekts erzeugt. Unter Verwendung dieses Verfahrens ist es praktisch unmöglich, daß zwei Objekte die gleiche GUID empfangen. Demgemäß kann jedes Objekt im System unter Verwendung der Objekt-GUID identifiziert, zugeordnet und aufgefunden werden usw.
Wie in Fig. 4 dargestellt ist, wird ein Bildobjekt 360 mit dem Bildsteuerelement 336 verknüpft, so daß nach der Bildaufbereitung das Bildobjekt 360 auf der Seite 334 an einer vom Steuerelement 336 bestimmten Position angezeigt wird. In ähnlicher Weise wird ein Beitragsobjekt 362 mit dem statischen Beitragssteuerelement 338 verknüpft, aufbereitet und in die Position des Steuerelements 338 auf der Seite 334 versetzt.
Es sei bemerkt, daß jeder Bereich, der nicht vom Beitragsobjekt 362 in dem vom Steuerelement identifizierten Bereich verwendet wird, leer ist, weil das Steuerelement 338 ein statisches Beitragssteuerelement ist. Wie dargestellt, wird ein Beitragsobjekt 364 mit dem Beitragssteuerelement 340 verknüpft, so daß es in dem vom statischen Beitragssteuerelement 340 auf der Seite 334 identifizierten Bereich aufbereitet wird. In diesem Beispiel wird wegen der Größe des Steuerelements 340 (die vom Entwurfsprogramm gewählt wird) beispielsweise nur der erste Absatz des Beitragsobjekts 364 auf der Seite 334 aufbereitet. Auf diese Weise kann das Entwurfsprogramm durch derartige Einstellung oder Größenbestimmung des Steuerelements, daß es nur einen Absatz oder einen anderen gewünschten Teil des Beitragsinhalts einnimmt, wählen, daß nur ein Teil eines verknüpften Beitrags innerhalb eines statischen Beitragssteuerelements angezeigt wird. Normalerweise ermöglicht ein statisches Beitragssteuerelement das Scrollen eines Beitrags, so daß schließlich der gesamte Beitrag angezeigt wird.
Schließlich wird ein Beitragsobjekt 366 mit dem Beitragssteuerelement 342 verknüpft, so daß es in dem vom statischen Beitragssteuerelement 342 auf der Seite 334 identifizierten Bereich aufbereitet wird. In diesem Beispiel wird das gesamte Beitragsobjekt 366 aufbereitet und auf die Seite 334 verschoben.
Es ist wichtig zu bemerken, daß jedes dieser Beitragsobjekte Bezug auf die Stilvorlage 343 nimmt, bevor es auf der Seite 334 aufbereitet wird. Wenn Beitragsobjekte einem Autor zugeordnet werden, werden sie mit Formatierungstags markiert, die spezifische Stile darstellen. Wenn die Beitragsobjekte aufbereitet werden, nehmen sie Bezug auf die mit dem geeigneten Steuerelement verknüpfte Stilvorlage, um Formatierungsinformationen abzurufen. Diese Formatierungsinformationen enthalten Eigenschaften der Absätze, Schriftarten und eingebettete Objekte in dem Beitrag, wodurch der Inhalt so formatiert wird wie er ursprünglich entworfen wurde. Infolge der Trennung des Entwurfs und des Inhalts im MP-System weisen die Beitragsobjekte selbst nur Formatierungstags auf, sie enthalten jedoch keine Beschreibung des bestimmten Formats, das jedem Tag entspricht. Die Beschreibungen dieser Tags befinden sich in der Stilvorlage, die mit dem Steuerelement verknüpft ist, zu dem das Beitragsobjekt aufbereitet wird.

2. Der Wirtschaftsteil

Wie auch in Fig. 4 dargestellt ist, enthält der Wirtschaftsteil 332 eine erste Seite 344 und eine zweite Seite 346. Die Seite 344 weist ein einziges statisches Beitragssteuerelement 348, ein einziges Bildsteuerelement 350 und ein erstes dynamisches Beitragssteuerelement 352 auf. Die zweite Seite 346 weist zwei dynamische Beitragssteuerelemente 354 und 356 auf. Zusätzlich wird von den verschiedenen Steuerelementen auf den Seiten 344 und 346 auf eine Stilvorlage · 357 und eine Stilvorlage Y 359 Bezug genommen. Die Seiten im Wirtschaftsteil 332 unterscheiden sich von der Seite 334 im Titelseitenabschnitt 330, weil sie sich auf ein Suchobjekt 368 stützen, um bestimmte Beiträge aufzufinden. Auf der Seite 334 wurden die statischen Steuerelemente jeweils mit einem bestimmten Beitrag verknüpft, der dann nach einer Bildaufbereitung angezeigt wurde. Das Suchobjekt 368 ist mit den dynamischen Beitragssteuerelementen im Abschnitt 332 verbunden.
Wie in diesem Beispiel dargestellt ist, nehmen das statische Beitragssteuerelement 348 und das Bildsteuerelement 350 auf der Seite 344 auf das Beitragsobjekt 364 und das Bildobjekt 360 Bezug oder werden mit diesen verknüpft, und sie zeigen diese Objekte an, wie auf der aufbereiteten Seite 344 dargestellt ist. Das Beitragsobjekt 364 wird somit von verschiedenen Abschnitten, Seiten und Steuerelementen im Titel gemeinsam verwendet. Das gesamte Beitragsobjekt 364 wird auf der Seite 344 angezeigt, während auf der Seite 334 nur der erste Absatz angezeigt wurde. Unter Verwendung eines ähnlichen Prozesses kann ein Entwerfer wählen, daß auf der ersten Seite eines Titels nur der erste Absatz eines Beitrags angezeigt wird, jedoch auf der anderen Seite innerhalb desselben Titels der gesamte Beitrag aufgenommen wird. Wie in Fig. 4 dargestellt ist, wird das Bildobjekt 360 ebenfalls vom Steuerelement 336 und vom Steuerelement 350 gemeinsam verwendet. Diese gemeinsame Verwendung des Inhalts durch separate Abschnitte und Seiten ist ein wichtiges Merkmal des MP-Systems 100.

3. Dynamische Beitragssteuerelemente

Das dynamische Beitragssteuerelement 352 verwendet die Ergebnisse einer Abfrage, die vom Titel vorgenommen wurde, um Beiträge aufzufinden, die den vom Verleger festgelegten Suchkriterien (die durch das Suchobjekt 368 definiert sind) entsprechen. Das Suchobjekt 368 lokalisiert Beitragsobjekte, die bestimmte Eigenschaften oder einen bestimmten Text aufweisen. Im Beispiel aus Fig. 4 gab das Suchobjekt 368 viele Beitragsobjekte 370, 372 und 374 zurück, die jeweils Beitragsobjekten 1 bis N entsprachen (wobei in diesem Beispiel N = 4 ist). Alle aufgefundenen Beitragsobjekte werden von den dynamischen Steuerelementen miteinander verkettet und in die geeigneten Bereiche auf den Seiten gegeben. Die Reihenfolge, in der die Beiträge aufbereitet und in die Steuerbereiche gegeben werden, beginnt mit dem ersten dynamischen Beitragssteuerelement auf der Seite im Abschnitt und setzt sich mit anderen im Abschnitt enthaltenen dynamischen Beitragssteuerelementen fort.
Falls im Abschnitt nicht genug Seiten definiert sind, um alle gefundenen Beiträge anzuzeigen, wird die letzte verwendete Seite wiederholt, bis alle Beiträge aufbereitet sind. Demgemäß wird der erste gefundene Beitrag 370 in den vom dynamischen Beitragssteuerelement 352 definierten Bereich gegeben. Weil er nicht vollständig in diesen Bereich paßt, setzt sich der gefundene Beitrag 370 über die Seitengrenze hinaus auf die Seite 346 in den vom dynamischen Beitragssteuerelement 354 definierten Bereich fort. Das gefundene Beitragsobjekt 372 beginnt dann, nachdem das gefundene Beitragsobjekt 370 endet. Das nächste gefundene Beitragsobjekt (das gefundene Beitragsobjekt 3) beginnt, nachdem das Beitragsobjekt 372 endet, und es setzt sich bis in das nächste Steuerelement 356 auf der Seite 346 fort, wie in diesem Beispiel dargestellt ist. Das letzte vom Suchobjekt 368 in diesem Beispiel aufgefundene Beitragsobjekt 374 wird dann zum dynamischen Beitragssteuerelement 356 innerhalb der Seite 346 aufbereitet.
Wie vorstehend erklärt wurde, verwenden die dynamischen Beitragssteuerelemente im Abschnitt 332 das Suchobjekt 368, um die Ergebnisse für spezifische Informationen vorgenommener Abfragen anzuzeigen. Beispielsweise kann das Suchobjekt 368 einen Inhalt zurückgeben, der das Wort "Microsoft" enthält. Alle vom Suchobjekt 368 gefundenen Beiträge werden in den von den dynamischen Beitragssteuerelementen definierten Bereichen in dem durch die Stilvorlage 357 oder die Stilvorlage 359 festgelegten Format angezeigt.
Falls das dynamische Beitragssteuerelement 354 beispielsweise mit der Stilvorlage 357 verknüpft ist, erscheinen alle vom dynamischen Beitragssteuerelement 354 angezeigten Beiträge in dem durch die Stilvorlage 357 festgelegten Format. Die vom dynamischen Beitragssteuerelement 356 aufbereiteten Beiträge würden jedoch anders als die entsprechend dem dynamischen Beitragssteuerelement 354 formatierte Anzeige erscheinen, wenn dieses Beitragssteuerelement mit einer anderen Stilvorlage (beispielsweise der Stilvorlage 359) verknüpft wäre. Falls die Steuerelemente 354 und 356 verschiedene Stilvorlagen verwenden, wird in diesem Beispiel der gefundene Beitrag 3 unter Verwendung zweier Formate angezeigt, wenn der Übergang von dem vom Steuerelement 354 definierten Bereich zum Steuerelement 356 erfolgt ist.
Stilvorlagen und die von diesen gesammelten Stilobjekte werden vom Entwerfer (also der Person an dem in Fig. 2 dargestellten Arbeitsplatzrechner 180 des Verlegers) unter Verwendung des Projekteditors und des Stilvorlageneditors erzeugt. Sobald die Stilvorlage erzeugt wurde, wird sie zusammen mit den anderen im Projekt vorhandenen Objekten im Caching-Objekt-Speicher (COS) gespeichert, wie vorstehend mit Bezug auf Fig. 2 beschrieben wurde. Die Stilvorlagenobjekte unterstützen die OLE-Serialisierung und basieren daher auf der CObject-Klasse der Microsoft Foundation Class (MFC). Diese Klassendefinitionen sind beim Erwerber allgemein zugänglich.

IV. ÜBERSICHT ÜBER DIE INFORMATIONSWIEDERAUFFINDUNG

Dieser Abschnitt gibt eine Übersicht über die Konfiguration und die Hauptkomponenten des bevorzugten Informationswiederauffindungssystems (IR-Systems). Einer Beschreibung der Hauptkomponenten, der Konfiguration und der Wechselbeziehungen des MP- und des IR-Systems folgt eine Erörterung der Softwarekomponenten. Danach wird die Struktur eines Beitrags und eines Titels beschrieben, worauf eine Übersicht über die Prozesse des Betrachtungsprogramms und eine Kundenabfrage folgt. Dieser Abschnitt endet mit einer Erörterung des Steuerablaufs für Suchobjekte und den Suchdialog sowie mit einer Erörterung der vom Suchobjektfluß verwendeten Strukturen.

A. Oberste Ebene der Informationswiederauffindung

Mit Bezug auf Fig. 5 und auch die Fig. 1-3 wird die Beziehung zwischen dem Informationswiederauffindungssystem (IR-System) und dem MPS beschrieben. Ein unabhängiger Inhaltsanbieter (ICP) oder Verleger 102 verwendet einen MPS- Dokumenteditor 188 zum Erzeugen von einem oder mehreren Inhaltsobjekten 390. Es können auch andere Editoren, wie ein Toneditor 190 und ein Bildeditor 192, zum Erzeugen des Inhalts 390 verwendet werden. Der Verleger 102 verwendet den Projekteditor, um einem Titellayout 110 alle oder gewählte Teile des Inhalts 390 zuzuordnen. Das Titellayout kann ein oder mehrere Suchobjekte aufweisen. Ein Inhalt 112, dessen Zuordnung zum Titellayout 110 gewählt wurde, kann in einen Wurzelinhaltsordner gegeben werden. Wenn der Verleger den Titel fertigstellt, werden das Titellayout und der Inhalt auf einem MPS-Caching-Objekt-Speicher-(COS)-Server in der Art eines MPS-Servers 246 veröffentlicht. Ein Verleger kann alternativ nur einen Inhaltsordner mit einem oder mehreren Inhaltsobjekten auf dem COS-Server 246 veröffentlichen. Der Verleger kann neue Inhaltsobjekte veröffentlichen oder später bestehende Inhaltsobjekte löschen.
Inhaltsobjekte können in einem Titel-COS auf dem Server 246 gespeichert werden, oder sie können im Wurzelinhaltsordner auf dem Server 246 gespeichert werden. Der COS- Server 246 kopiert den veröffentlichten Inhalt 394 und das Titellayout 396 auf das IR-System 398, das die IR-Dienste 270, die IR-Server 272-274 und die DB-Server 276-278 aufweist. Das IR-System 398 beinhaltet eine IRSV-DLL, eine IRUTS-DLL und eine IRIX-DLL. Wie nachfolgend beschrieben wird, erstellt das IR-System 398 Indizes, die die GUIDs und die Eigenschaften der Objekte enthalten.
Wenn eine Suchobjektabfrage oder eine Benutzerabfrage im Betrachtungsprogramm 202 eingeleitet wird, werden die Attribute der Abfrage (hier als Indizes zu Abfragen 404 dargestellt), wie eine Titel-GUID, eine Abschnitts-GUID, ein Datumsbereich, Schlüsselwörter usw., zum IR-System 398 gesendet. Das IR-System 398 durchsucht seine Datenbanken, um den Suchkriterien entsprechende Objekte zu finden. Das IR- System 398 gibt eine Liste der GUIDs und der Eigenschaften, wie das Datum und die Quelle, jedes Inhaltsobjekts, das an das Betrachtungsprogramm 202 zurückgegeben wurde, zurück. Das Betrachtungsprogramm 202 sendet dann GUID-Anforderungen 408 für die tatsächlichen vom IR-System 398 identifizierten Inhaltsobjekte zu einem lokalen COS (des Betrachtungsprogramms) 402. Falls das angeforderte Inhaltsobjekt im lokalen COS 402 vorhanden ist, wird das Inhaltsobjekt 410 an das Betrachtungsprogramm 202 zurückgegeben. Falls die durch die GUID-Anforderungen identifizierten Objekte nicht im lokalen COS 402 vorliegen, wird eine Abrufanforderung 412 an den COS-Server übergeben. Inhaltsobjekte 414, die nicht im lokalen CCS 402 vorhanden sind, werden dann vom COS-Server 246 zum lokalen COS 402 übertragen und an das Betrachtungsprogramm 202 weitergegeben.

B. API/DLL-Ansicht des Systems

Mit Bezug auf Fig. 6 werden nun die Hauptsoftwarekomponenten oder -module beschrieben, die von der gegenwärtig bevorzugten Implementierung des MP-Systems 100 verwendet werden. Die Module befinden sich am Verlegerort 102 (auch in den Fig. 1 und 2 dargestellt), am Netzwerkspeicherort 122 und am Kundenort 160.
Die Module am Verlegerort 102 umfassen ein ausführbares Verlegerprogramm 430, einen Satz von Verleger-DLLs 432, einen Satz spezifischer Verleger-OLE-Steuerelemente 434, einen Satz von IR-Client-Dienst-DLLs 435, einen Verleger-COS 444 mit einem Client-Objektvermittlungsdienst und einer Client- Verlegerschnittstelle 446, der OLE 198 und der MFC 462.
Die Module am Kundenort 160 umfassen ein ausführbares Betrachtungsprogramm 438, den Satz allgemeiner Verleger-DLLs 432, den Satz allgemeiner spezifischer Verleger-OLE- Steuerelemente 434, den Satz von IR-Client-Dienst-DLLs 435, den (lokalen) Betrachtungsprogramm-COS 402 mit einem Client- Objektvermittlungsdienst 450, der OLE 198 und der MFC 462.
Die Module am Speicherort 122 umfassen ein ausführbares Serverprogramm 436 und den Server-COS 440 (der auch als SuperCOS bekannt ist) mit einem Server-Objektvermittlungsdienst und einer Server-Verlegerschnittstelle 442. Eine bidirektionale Schnittstelle vom ausführbaren Serverprogramm 436 und vom Server-COS 440 wird mit der zugeordneten Suchschnittstelle 454 eines Informationswiederauffindungsdienstes 452 verbunden.
Das ausführbare Verlegerprogramm 430 (auch als BBDESIGN.EXE bekannt) ist eine Anwendung, die einen Mechanismus zum Erzeugen einer Ansicht eines Projekts während des Entwurfs bereitstellt. Es wird beim Erzeugen von Objekten innerhalb eines Projekts und zum Herstellen der Beziehungen zwischen den Objekten eines Projekts verwendet.
Der Satz von Verleger-DLLs 432 enthält eine Formular-DLL (FORMS3.DLL), die die Implementierung der OLE-Steuercontainerklasse gewährleistet und die Daten für das Seitenobjekt in einem Projekt liefert. Es ist dort auch eine Ansichts-DLL (VIEWDLL.DLL) enthalten, die einen Satz von MPS- Objektdefinitionen und die Betrachtungsmaschine zum Erzeugen der Laufzeitansicht eines Titels bereitstellt. Die MPS- Objekte umfassen CProject, CTitle, CSection, CFolder, CContentFolder, CRootContentFolder, CProxyTable, CContent, CFrame, CBForm, CVForm, CStyleSheet und CMagnet.
Der Satz spezifischer Verleger-OLE-Steuerelemente 434 (auch als BBCTL.OCX bekannt) ist eine DLL, die den Code zum Implementieren von Beispielen der spezifischen OLE-Steuerelemente bereitstellt, die für das MP-System 100 standardmäßig sind.
Das ausführbare Betrachtungsprogramm 438 (auch als BBVIEW.EXE bekannt) ist eine Anwendung, die einen Mechanismus zum Einleiten der Laufzeitbetrachtung eines Titels bereitstellt. Dabei werden die spezifischen Verleger-OLE-Steuerelemente 434 und die Verleger-DLLs 432, insbesondere die Betrachtungsmaschine zum Erzeugen der Laufzeitansicht eines Titels, verwendet.
Der Verlegerort 102, der Kundenort 160 und der Netzwerkspeicherort 122 haben jeweils einen COS, der unter Verwendung einer DLL (COS.DLL) implementiert ist. Die COS-DLL stellt einen beständigen Speichermechanismus für vom MP- System 100 verwendete Objekte bereit. Die COS-DLL verwendet die OLE-Speicherungstechnologie zum Speichern der Sätze von Objekten als ein Dateisystem innerhalb einer Datei. Jedem in einen COS gegebenen Objekt wird eine eindeutige Identität verliehen, die als GUID bezeichnet wird. Jedes durch eine GUID identifizierte Objekt kann unabhängig von einem Pfadnamen in einem Dateisystem gefunden werden. Das ausführbare Serverprogramm 436 (auch als MSNSERVER.EXE bekannt) ist eine Anwendung, die einen Mechanismus zum Verwalten des den COS aufweisenden Netzwerkservers bereitstellt. Zusätzlich zur COS-DLL hat der Server eine DLL für den COS-Zugang und die Objektverknüpfung (OBSV.DLL), für den MPS-Serverdienst (BBOBSVC.DLL) und für den Speicherverwaltungsdienst (DFARBSV.DLL).
Der Verlegerort 102, der Kundenort 160 und der Netzwerkspeicherort 122 weisen jeweils eine Objektvermittlungsdienst-DLL (OBJBRK.DLL) auf. Der Objektvermittlungsdienst versucht, ein Objekt anhand seiner eindeutigen Identität (GUID) zu finden. Der Objektvermittler sucht zuerst in seinem lokalen Objektspeicher (als SuperCOS bezeichnet), der durch den Verleger-COS 444 (am Verlegerort 102), den Server-COS 440 (am Netzwerkspeicherort 122) oder den Betrachtungsprogramm-COS 402 (am Betrachtungsprogrammort 160) gegeben ist. Falls das Objekt nicht im COS, in dem die Anforderung vorgenommen wurde, gefunden wird und falls sich der Objektvermittler auf einer Client-Maschine (entweder am Verleger- oder am Kundenarbeitsplatzrechner) befindet, versucht er, das Objekt ferngesteuert aus dem Server-COS 440 am MSN-Datenzentrum 242 (Fig. 3) abzurufen. Gemäß einer anderen Ausführungsform können andere Objektspeicher für einen gegebenen Objektvermittler als eine Objektquelle registriert werden, die vom Objektvermittler zwischen dem lokalen und dem fernen Auffindungsversuch durchsucht wird. Dem beim Verleger befindlichen Objektvermittler 446 ist die Client-Seite der Verlegerschnittstelle zugeordnet, und dem am Netzwerkserver befindlichen Objektvermittler 442 ist die Serverseite der Verlegerschnittstelle zugeordnet. Die Verlegerschnittstelle wird zum Verwalten neuer, gelöschter und modifizierter Objekte verwendet.
Die Fähigkeiten des Objektvermittlers erlauben es einem Verleger, Layouts oder Inhalt zu prüfen, die mit einem anderen Verleger gemeinsam verwendet werden. Beispielsweise hat ein Verleger A ein Titellayout A und ein Verleger B einen Inhalt, den der Verleger B nach einer Vereinbarung mit dem Verleger A gemeinsam verwendet. Zum Prüfen des Titellayouts A zusammen mit dem Inhalt kann der Verleger A unter Verwendung des Objektvermittlungsdienstes den vom Verleger B bereitgestellten Inhalt abrufen, der im COS 440 gespeichert ist.
Eine MPC-Wrapper-DLL (MWRAP.DLL) verwendet das Microsoft- Network-Prozeduraufruf-(MPC)-Protokoll, um mit dem Netzwerkspeicher 122, also dem MSN-Datenzentrum 242 gemäß der gegenwärtig bevorzugten Ausführungsform, und den MPS-Diensten, wie dem Objektvermittler und dem COS, zu kommunizieren. Dieser Wrapper isoliert insbesondere das COS/Objektvermittler- Untersystem vom spezifischen MPC-Protokoll, so daß das MP- System 100 leicht übertragen werden kann, damit es andere Protokolle in anderen Umgebungen verwenden kann.

C. Entwurfsumgebung

In diesem Abschnitt der detaillierten Beschreibung wird die Entwurfsumgebung am Verlegerort beschrieben. Dieser Abschnitt beginnt mit einer Erörterung des gegenwärtig bevorzugten Autorzuordnungsuntersystems, das vom MP-System 100 verwendet wird. Daraufhin wird eine Titelentwurfsuntersystem-Komponente, und zwar der beim Erstellen des Titellayouts verwendete Suchobjekteditor, beschrieben. Schließlich wird eine im Betrachtungsprogramm 202 entwickelte Titelbaumstruktur beschrieben.

1. Autorzuordnungsuntersystem

Der Inhalt ist im MP-System 100 vom Entwurf getrennt. Im Betrachtungsprogramm 202 (Fig. 2) werden der Inhalt und der Entwurf durch Steuerelemente zusammengebracht, um einen vom Entwerfer spezifizierten Titel anzuzeigen. Daher müssen diese Steuerelemente verschiedene Elemente in der Struktur des Inhalts identifizieren, damit sie ihn richtig formatieren können. Dies wird durch Erzeugen eines strukturierten Inhalts erreicht. Die MPS-Autorzuordnungsumgebung bietet Autoren ein Verfahren zum Erstellen strukturierter Dokumente.
Die MPS-Autorzuordnungsumgebung weist den MPS-Dokumenteditor 188 auf, der das Erzeugen strukturierter Dokumente, das Einfügen von Verknüpfungen und das Anwenden von Eigenschaften auf diese Dokumenten zur Inhaltsauffindung unterstützt. Das MP-System 100 verwendet SGML (verallgemeinerte Standard-Markierungssprache), um das Schema zum Erstellen strukturierter Dokumente zu definieren. SGML ist eine Norm zum Definieren einer Markierungssprache, nämlich eines Satzes von Tags und Attributen, die zum Identifizieren der Struktur eines als DTD (Dokumenttypdeskriptor) bezeichneten Dokuments verwendet werden. Der MPS-Dokumenteditor 188 unterstützt das Speichern von Dokumenten in einem Format, das mit dem MPS DTD (MPML - Multimedia Publishing Markup Language - Multimedia-Veröffentlichungs-Markierungssprache) übereinstimmt. Dieser DTD wird zur Verwendung mit anderen SGML- Autorzuordnungssystemen veröffentlicht. Als Teil dieser Umgebung stellt das MPS ein Paar von Dokumenteditorumwandlern zum Lesen/Schreiben von MPML-Dateien, eine Stile und Makros definierende Vorlage, die zum Erzeugen von MPML-Dateien verwendet wird, sowie einige OLE-Steuerelemente, die zum Einfügen von Verknüpfungen und zum Anwenden von Eigenschaften auf diese Dateien verwendet werden, bereit.
Zur Erzeugen des Inhalts für das MP-System 100 im MPS- Dokumenteditor 188 erstellt ein Autor ein Dokument auf der Grundlage der MPS-Vorlage. Diese Vorlage stellt einen Satz vordefinierter Stile zusammen mit unterstützenden Makros bereit. Der Autor wendet diese Stile auf den Text an, um die verschiedenen Elemente des Dokuments (Kopfzeile, Kurzzusammenfassung, Haupttext usw.) zu identifizieren. Es sollten nur die vordefinierten Stile verwendet werden. Wenn das Dokument im MPML-Format gespeichert wird, werden diese Stile durch den MPML-Ausgabeumwandler in SGML-Tags umgewandelt. Es ergibt sich ein mit Tags markiertes Dokument, das später vom Betrachtungsprogramm 202 syntaktisch analysiert werden kann.
Die MPML-Umwandler für den Dokumenteditor 188 unterstützen die Umwandlung auf den Text angewendeter Stile in MPML-Tags. Zusätzlich unterstützen sie Graphik, die mit dem Befehl "Bild einfügen" im Dokumenteditor 188 eingefügt wurde. Hierdurch wird sowohl verknüpfte als auch eingebettete Graphik unterstützt und in geeigneter Weise mit Tags markiert. Die Umwandler gewährleisten auch die Unterstützung für die MPS-OLE-Steuerelemente zum Einfügen von Verknüpfungen und zum Anwenden von Eigenschaften auf die Dokumente.
Eine wichtige Eigenschaft der Autorzuordnungsumgebung besteht darin, daß sie nur zum Erzeugen mit Tags markierten Inhalts zu verwenden ist. Der Autor sollte nicht erwarten, daß die im Dokumenteditor 188 vorgenommenen Stildefinitionen oder angewendeten Formatierungen auf das Betrachtungsprogramm 202 übertragen werden, wenn das Dokument angezeigt wird.
Als Teil der Autorzuordnungsumgebung werden mehrere OLE- Steuerelemente bereitgestellt, die mit der MPS-Umgebung wechselwirken, um den Autor beim Einfügen von Verknüpfungen und beim Anwenden von Eigenschaften auf Dokumente zu unterstützen. Diese Steuerelemente sind normale OLE-Objekte, die erweitert sind, um das Aufbereiten ihrer Daten zum MPML- Format zu unterstützen. Die MPML-Umwandler sind in der Lage, im Dokument des Dokumenteditors eingebettete OLE-Steuerelemente zu erkennen und unter Verwendung einer gut definierten Schnittstelle ihre MPML-Darstellungen anzufordern. Wenn die Umwandler auf ein OLE-Objekt stoßen, versuchen sie, unter Verwendung dieser Schnittstelle aus ihm eine MPML-Darstellung zu gewinnen und diese in den MPML-Ausgangsstrom einzufügen. OLE-Steuerelemente, die diese Schnittstelle nicht unterstützen, werden ignoriert. Durch die Verwendung der Schnittstelle kann die Autorzuordnungsumgebung nach Bedarf mit neuen OLE-Steuerelementen erweitert werden.

a. Beitragseditor

Ein MPS-Beitragseditor, der Teil des MPS-Dokumenteditors 188 ist, ist das Hauptwerkzeug, das Entwerfer und Autoren zum Erzeugen von MPS-Beitragsobjekten verwenden. Ein MPS- Beitragsobjekt besteht aus einem Strom von Text mit eingebetteten Objekten in der Art von Verknüpfungen oder Bildern. MPS-Beiträge können auch mit Sucheigenschaften markiert werden, so daß das MPS-Suchsystem Beiträge leicht und genau finden kann.
Die Hauptaufgaben beim Erzeugen und Zusenden eines Beitrags sind die folgenden: den Beitrag verfassen, strukturelle Eigenschaften für den Beitrag festlegen, wahlweise Bilder in den Beitrag einfügen, wahlweise Verknüpfungen mit anderen Beiträgen erzeugen und Zusammenfassungseigenschaften (einschließlich der Suche-Übereinstimmungskriterien) für den Beitrag festlegen.
Zusätzlich zur Verwendung des MPS-Dokumenteditors 188 zum Erzeugen von Beiträgen können Verleger MPS-Beiträge mit anderen Werkzeugen oder mit einem automatisierten Prozeß erzeugen. Beispielsweise werden Börsenticker-Beiträge wahrscheinlich automatisch erzeugt.
MPS-Beiträge sind strukturiert, was bedeutet, daß die den Beitrag ausmachenden Elemente logisch identifiziert sind. Dies ist nützlich, weil das MP-System 100 diese logische Beschreibung dazu ausnutzen kann, die Darbietung der Informationen für Benutzer zu unterstützen. Dies wird durch den Dokumenteditor 188 erleichtert, wobei Autoren lediglich die Dokumenteditorstile anwenden müssen. Dieser Prozeß kann auch unter Verwendung einer von Microsoft oder Drittentwicklern gelieferten Filterungssoftware automatisch ausgeführt werden.
Das MP-System 100 unterstützt drei Hauptdateiformate, nämlich (1) das MPS-Datendateiformat, (2) MPML und (3) die Hypertext-Markierungssprache oder HTML. Die MPS-Datendateiformat ist das spezifische MPS-Beitragsformat. Dies ist eine standardmäßige OLE-Dokumentdatei mit getrennten Strömen für Text und die verschiedenen im Textstrom enthaltenen Objekte. Das MPML-Format ist verfügbar, um das Importieren und Exportieren von MPS-Beiträgen zu erleichtern. Eine MPML-Datei ist eine gewöhnliche Textdatei, die SGML entspricht. Weil dieses Dateiformat eine einfache Textdatei ist, ist es für Verleger einfach, den Prozeß des Erzeugens von MPML-Dateien zu automatisieren. Die meisten Verleger brauchen MPML nicht zu verwenden, weil die MPS-Werkzeuge den Prozeß automatisieren. Das MPML-Dateiformat ist nur wichtig, weil es leicht in andere Formate konvertiert werden kann, was einen leichten Migrationsweg für Verleger gewährleistet.
Das MP-System 100 kann auch HTML-Textdateien importieren und exportieren. Weil HTML jedoch ziemlich beschränkt ist, können viele fortgeschrittene MPS-Merkmale nicht in HTML dargestellt werden.
Die HTML- und die MPML-Konverter sind als ein getrenntes Programm aufgebaut, das es Verlegern ermöglicht, Stapelübersetzungen von Dateien vorzunehmen.
Beiträge werden gewöhnlich mit anderem geeigneten Inhalt verknüpft, und es werden dem Beitrag MPS-Sucheigenschaften hinzugefügt, so daß der Beitrag vom Abfrageuntersystem aufgefunden werden kann. Diese Schritte können unter Verwendung des MPS oder von Autorzuordnungswerkzeugen von Drittentwicklern ausgeführt werden. Falls ein Verleger Werkzeuge von Drittentwicklern zum Erzeugen von Inhalt verwendet, müssen die Ergebnisse mit den MPS-Dateiformaten übereinstimmen, um sicherzustellen, daß das Betrachtungsprogramm 202 den Inhalt interpretieren kann.

b. Sucheigenschaften

Um Kunden beim Finden möglicherweise interessanter Beiträge zu helfen, unterstützt das MPS durch die Dateieigenschaftsoption die Spezifikation der Schlüsselwort- oder Schlüsselausdruck-Übereinstimmungskriterien. Ein Datei/Eigenschaften-Dialog des MPS-Dokumenteditors 188 wird zum Markieren eines Beitrags mit beim Suchen zu findenden Auffindungsattributen verwendet. Jedes Feld kann vom Sucheditor individuell durchsucht werden. Der Suchdialog kann das Titelfeld einzeln durchsuchen, die restlichen Felder werden jedoch als Ganzes durchsucht, wenn der "Schlüsselwörter"-Kasten im Dialog gewählt ist.
Gemäß einer bevorzugten Ausführungsform umfassen die Beitragseigenschaften, die in den Eigenschaftsdialog eingegeben werden können, die folgenden:
- Titel - der Titel des Beitrags
- Thema - eine Liste der Themen, von denen der Beitrag handelt
- Ort - geographischer Ort (geographische Orte), der (die) im Beitrag erwähnt wird (werden)
- Person - Name(n) der Person(en), um die es sich im Beitrag handelt
- Autor - der Verfasser des Beitrags
- Organisation - Name(n) der Organisation(en), um die es sich im Beitrag handelt
- Datum des Ereignisses - das Datum des im Beitrag beschriebenen Geschehens
- Priorität - die Wichtigkeit des Beitrags in bezug darauf, wie und wo er in einem Titel veröffentlicht ist

c. Erzeugen einer Multimedia-Dokmuentdatei

Die nachfolgende Erörterung ist eine Übersicht über den Prozeß des Erzeugens einer Multimedia-Dokumentdatei (MDF) und des Veröffentlichens von dieser auf einem Server. Multimedia- Dateien werden dann zum Bereitstellen des Inhalts für angezeigte Online-Titel verwendet. Ein Verleger 102 erzeugt den Inhalt für einen Titel unter Verwendung des Dokumenteditors 188 (Fig. 2). Der Verleger 102 erzeugt dann eine MDF-Datei und speichert den erzeugten Inhalt in einem Speicher. Sobald der Inhalt in einer Datei gespeichert wurde, wählt der Verleger 102 den gespeicherten Inhalt zum Verknüpfen mit einem bestimmten Titel. Es sei bemerkt, daß der Verleger 102 mehr als eine Person vertreten kann. Beispielsweise könnte ein Autor ein MDF-Dokument erzeugen und den Inhalt in einer Datei speichern, während ein Entwerfer den Inhalt zur Verknüpfung mit dem Titel wählt. Es ist verständlich, daß jede beliebige Anzahl von dem Verleger 102 zugeordneten Personen für das Erzeugen von Inhalt und dessen Freigabe für Kunden verantwortlich sein kann.
Sobald der Inhalt gewählt und mit einem bestimmten Titel verknüpft wurde, wird ein Prozeß der syntaktischen Analyse eingeleitet. Der eigentliche Prozeß der syntaktischen Analyse des Inhalts wird nachfolgend mit Bezug auf Fig. 7 in näheren Einzelheiten erörtert. Durch den ausgeführten Prozeß der syntaktischen Analyse wird jedoch die MDF-Datei in einen syntaktisch analysierten Inhaltsbaum, der eine einzige Wurzel mit mehreren Knoten und Abzweigungen aufweist, konvertiert. Die syntaktisch analysierte Struktur erhöht die Wirksamkeit der Übertragung des Inhalts über Leitungen mit geringer Bandbreite.
Sobald der Inhalt syntaktisch analysiert worden ist, wird er im lokalen Caching-Objekt-Speicher (COS) des Verlegers gespeichert, in dem er nach Wunsch mit vielen Titeln verknüpft werden kann. Nachdem der syntaktisch analysierte Inhalt mit einem Titel verknüpft und im lokalen COS gespeichert wurde, können der Inhalt und das Titellayout auf einem Server veröffentlicht werden.
Die Ergebnisse der syntaktischen Analyse einer MDF-Datei sind in Fig. 7 dargestellt. Der Baum der syntaktischen Analyse ist eine das Dokument darstellende Datenstruktur, die vom Entwerfer erzeugt wird, wenn der Inhalt mit einem Titel verknüpft wird. Dies wird in Zusammenhang mit einem Parser niedriger Ebene und einem Dokumenttypdeskriptor-(DTD)-Manager hoher Ebene durchgeführt. Der Parser niedriger Ebene ist im wesentlichen eine Zustandsmaschine. Sie betrachtet jedes Zeichen im eingegebenen Text und modifiziert seinen aktuellen Zustand abhängig von der Identität des nächsten Zeichens. Wenn sich Zustände ändern, werden "Ereignisse" zum DTD- Manager zurückgegeben, der das Ereignis interpretiert und darauf einwirkt. Beispiele von Ereignissen sind Anfangstag gefunden, Endetag gefunden oder Attribut gefunden.
Für jedes mit Tags markierte Element in der syntaktisch analysierten MDF-Datei gibt es einen Knoten, der den Tag und die Attribute identifiziert, deren Daten das mit Tags markierte Element sind. Im Format der Multimedia-Veröffentlichungs-Markierungssprache (MPML) können Tags ineinander verschachtelt werden. Dadurch kann ein Knoten im Baum auf andere die verschachtelten Tags darstellende Knoten oder auf einen den tatsächlichen mit Tags markierten Text enthaltenden Knoten verweisen. Dies bedeutet, daß nur die "Blattknoten" des Baums der syntaktischen Analyse tatsächlich auf den mit Tags markierten Text verweisen.

d. Der syntaktisch analysierte Inhalt

Wie in Fig. 7 dargestellt ist, weist eine Wurzel 570 eines syntaktisch analysierten Dokuments einen Sucheigenschaftsspeicher 572 (ein IStorage-Objekt) auf, der einen Strom von Daten 574 enthält, die Sucheigenschaftsdaten entsprechen. Der Sucheigenschaftsstrom 574 enthält Daten, wie den Autor, die Schlüsselwörter, den Titel, die erzeugten Daten und andere Informationen, so daß ein Suchobjekt im Multimedia-Veröffentlichungssystem dieses bestimmte Dokument auffinden kann.
Der Sucheigenschaftsstrom 574 weist vorzugsweise die folgenden Eigenschaften und Formatierungen auf. Es sei bemerkt, daß die eckigen Klammern und die Schrägstriche nur der Lesbarkeit dienen und nicht zum tatsächlichen Strom gehören (siehe nachfolgende Beispiele).
Titel = < Titel> < Leerschritt> < Mit Null endende Zeichenkette>
Gegenstand = < Gegenstand> < Leerschritt> < Mit Null endende Zeichenkette >
Autor(en) = < Autor> < Leerschritt> < Mit Strichpunkten getrennte Namenliste als eine mit Null endende Zeichenkette>
Schlüsselwörter = < Schlüsselwörter> < Leerschritt> < Mit Strichpunkten getrennte Schlüsselausdruckliste als eine mit Null endende Zeichenkette>
Kommentare = < Kommentare> < Leerschritt> < Mit Null endende Zeichenkette>
Erstellungszeit = < Erstellungszeit> < Leerschritt> < Mit Null endende Zeichenkette im Format yyyy/mm/dd hh:mm::ss>
Modifikationszeit = < Modifikationszeit> < Leerschritt> < Mit Null endende Zeichenkette im Format yyyy/mm/dd hh:mm::ss>
Priorität = < Priorität> < Leerschritt> < Mit Null endende Zeichenkette einschließlich eines numerischen Werts zwischen 1 und 5>
Andere Sucheigenschaften umfassen Dokumentkennung, Quellenkennung, Textkörper, Kurzzusammenfassung, Zusammenfassung, Veröffentlichungszeit und -datum, Ereignis-Anfangszeit und - datum, Ereignis-Beendigungszeit und -datum, Kopfzeile, Ort des Ereignisses, Person, Organisation, Thema und Kennung des unabhängigen Inhaltsanbieters (ICPID).

Ein Beispiel des Sucheigenschaftsstroms:

Titel Das ist der Titel< Nullbyte> Gegenstand Dies ist der Gegenstand< Nullbyte> Autor George Washington< Nullbyte> - Schlüsselwörter Autorzuordnung, Word, Multimedia- < Nullbyte> Priorität 5< Nullbyte> < Nullbyte>
Die Sucheigenschaften werden in einem IR-Index im IR- System 398 (Fig. 5) gespeichert. Unter Verwendung der Sucheigenschaften kann ein Kunde eine Liste aller Dateien, die sich beispielsweise auf George Washington beziehen, sehen, er muß jedoch nicht warten, bis all diese Dateien vollständig über das Online-System heruntergeladen wurden. Es sei bemerkt, daß die Liste der Dateinamen für den Benutzer angezeigt wird, ohne daß er notwendigerweise eine der Dateien herunterlädt.
Im Wurzelobjekt 570 ist auch der mit Tags markierte Text 580 enthalten, der zu einem Baum der syntaktischen Analyse syntaktisch analysiert wurde. Wie dargestellt weist der mit Tags markierte Text 580 einen Speicher 582 auf, der den "Kopfdaten" entspricht, die im Strom 584 aufgefunden werden können. Der Datenstrom 864 enthält Daten, die dem Inhaltsverzeichnis (TOC), der Kurzzusammenfassung und anderen Teilen des mit Tags markierten MPML-Texts, die nicht Teil des Hauptkörpers des Dokuments sind, entsprechen.
Unter dem Speicher 580 für den mit Tags markierten Text ist auch ein Körperspeicher 586 ersichtlich, der der obere Knoten eines Baums der syntaktischen Analyse ist, welcher den syntaktisch analysierten, mit Tags markierten Text des Körpers des MPML-Dokuments enthält. Wie dargestellt, weist der Körperspeicher 586 einen < H1> -Knoten 588 auf. Unter dem Knoten 588 befindet sich ein < B> -Knoten 590, der einen Textstrom 592 aufweist, der mit den Stilen der Knoten 590 und 588 markiert wurde. In ähnlicher Weise hat der Körperspeicher 586 einen Knoten 594, der einen < P> -Tag enthält. Unter diesem Knoten im Baum befindet sich ein Knoten 596, der einen < U> - Tag enthält, der angibt, daß der nachfolgende Text unterstrichen werden muß. Unter dem Knoten 596 im Baum befinde t sich ein Textstrom 598, der vom Knoten 596 und vom Knoten 594 so formatiert ist, daß er mit Tags markiert ist.
Unter dem Knoten 594 befindet sich auch ein Knoten 600 mit einem Tag < WA> , der einen Einfassungs-Werbungsstil für ein eingebettetes Objekt angibt. Wie dargestellt, ist ein Objekt 602 in einem Blattknoten unter dem Knoten 600 angeordnet. Das Objekt 602 enthält Objektdaten 604 und eine Objektbitabbildung 606, wie es beim strukturierten OLE- Speicherungssystem standardmäßig ist. Unter dem Knoten 594 befindet sich auch ein Textstrom 608, der einen im < P> -Stil formatierten Text enthält. Somit ist in Fig. 7 die Struktur eines syntaktisch analysierten Dokuments dargestellt, nachdem es vom Verleger mit einem Titel verknüpft worden ist.
Nachdem ein Inhaltsobjekt am Datenzentrum 242 veröffentlicht wurde (Fig. 3), wird es im COS-Server (beispielsweise 246a) gespeichert und in dem in Fig. 7 beispielhaft dargestellten Format der syntaktisch analysierten Dokumentstruktur auf das IR-System übertragen. Es sei jedoch bemerkt, daß die Sucheigenschaften im IR-System 398, jedoch nicht im COS-Server 246 gespeichert werden.

2. Titelentwurfs-Untersystem

Dieser Abschnitt beschreibt einen Teil der MPS- Titelentwurfsumgebung, wobei die Betonung auf das Suchobjekteditor-Werkzeug 189 (Fig. 2) gelegt ist.

a. Suchobjekteditor (Magneteditor)

Der Suchobjekteditor 189 (Fig. 2) ist eine modifizierte Version des Kunden-Suchdialogs 690 (der in Fig. 10 dargestellt ist und im nachfolgenden Abschnitt "Kundenabfragenauflösung" näher beschrieben wird). Weil der Suchobjekteditor 189 von Entwerfern zur Titelerstellung zu verwenden ist, gibt es einige Unterschiede:
Der Suchobjekteditor 189 ist ein modaler Dialog, der sich als das Eigenschaftsblatt eines Suchobjekts im Titelentwerfer verhält. Gemäß der gegenwärtig bevorzugten Ausführungsform gestattet es der Suchobjekteditor dem Entwerfer, die "Jetzt suchen"-Funktion auszuführen und die Abfrage zu prüfen. Nach der Eingabe der Kriterien wird der Dialog entweder mit "OK" bestätigt oder mit "Abbrechen" aufgehoben.
Die "In:"-Wahlkästchen geben dem Entwerfer beim Auffindungsprozeß eine genauere Steuerung als dem Kunden.
Im Vergleich zum "Suche in:"-Feld, das im Suchdialog erscheint und festlegt, welcher fertige Titel (welche fertigen Titel) zu durchsuchen ist (sind), spezifiziert das "Quelle:"-Feld die Sammlung (den Wurzelinhaltsordner) von Beiträgen, die nach Beiträgen zu durchsuchen ist, welche in den Titel eingefügt werden müssen. Auf diese Quellen wird über die "Mehr..."-Option an der Unterseite des Drop-Down- Menüs zugegriffen, die eine Baumansicht aller Inhaltsquellen auf dem MSN 122 startet. Diese Quellen sind nur für Titelentwerfer sichtbar und erscheinen nicht für die allgemeinen MSN-Benutzer.
Die Suche kann auf das Auffinden von nicht mehr als einer bestimmten Anzahl von Beiträgen beschränkt werden, um zu verhindern, daß ein Abschnitt zu lange läuft. Der Entwerfer spezifiziert einfach eine maximale Anzahl in einem vorgesehenen Zählerfeld-Steuerelement.

b. Titelstruktur

Mit Bezug auf Fig. 8 wird nun ein als Beispiel dienender Titelbaum 620 beschrieben. Ein Titelbaum ist eine speicherinterne Darstellung von Objekten eines Titels im MP-System 100, wobei die Objekte Ströme und Speicher in einem COS sind. Der Titelbaum wird von der Betrachtungsprogrammkomponente 202 verwendet, um die Betrachtung eines Titels durch den Kunden zu erleichtern. Der Titelbaum 620 umfaßt einen Wurzelknoten und eine Reihe von Knoten, die unter der Wurzel in einem Baumformat angeordnet sind, um eine Informationshierarchie darzustellen. Ein Baum ist eine wohlbekannte Software- Datenstruktur. Der Titel, die Abschnitte, die Unterabschnitte (falls vorhanden), die Suchobjekte und die Wurzeln der Beiträge sind alle die OLE-Speicher, die vorstehend beschrieben wurden. Jedem dieser Speicher ist eine GUID zugewiesen. Unterhalb einer Beitragswurzel befindet sich die syntaktisch analysierte Baumdarstellung des Inhalts, der in einem COS gespeichert wurde, also der MPML-Baum der syntaktischen Analyse, der in Zusammenhang mit Fig. 7 beschrieben wurde.
An der Basis des MPML-Baums der syntaktischen Analyse befinden sich als Blattknoten bekannte Knoten, die die Ströme sind, welche die Daten in der Art von Text oder eingebetteten Objekten speichern. Andere Blattknoten sind Suchobjekte, die in Fig. 8 dargestellt sind. Oberhalb der Blattknoten befindliche Knoten sind die Speicherknoten.
Der Titelbaum beginnt mit einer Titelwurzel 622. Der Titelwurzel 622 ist eine GUIDa zugeordnet, die den Titel eindeutig identifiziert. Unterhalb der Wurzel, in der nächsten Ebene des Titelbaums, befindet sich eine Reihe von Abschnitten. Ein Abschnitt 1 ist durch einen Knoten 624 dargestellt, und es ist ihm eine GUIDb zugeordnet, die den Abschnitt eindeutig identifiziert. Ein Abschnitt 2 ist durch einen Knoten 626 dargestellt, und es ist ihm eine GUIDc zugeordnet. Der Abschnitt 1 hat des weiteren einen durch einen Knoten 628 dargestellten Unterabschnitt 11, dem eine GUIDd zugeordnet ist.
Bei diesem als Beispiel dienenden Titelbaum 620 weist der Abschnitt 624 ein durch einen Knoten 630 dargestelltes Suchobjekt M1 auf. Ein Unterabschnitt 628 hat ein durch einen Knoten 632 dargestelltes Suchobjekt M2 und ein durch einen Knoten 634 dargestelltes Suchobjekt M3.
Wie in Fig. 8 dargestellt ist, sind die Beziehungen zwischen dem Titel, dem Abschnitt, den Unterabschnitten und den Suchobjekten in einer Tabelle 636 erfaßt. Die Verwendung von Tabellen im IR-System 398 (Fig. 5) wird nachfolgend erörtert. Das IR-System 398 verwendet die Titellayoutbeziehungen und die aus dem Titelbaum gewonnenen Suchobjekte 638, um die Suchobjekte aufzulösen.

c. Betrachtungsprogramm bei Entwurfsfunktionen

Der Verleger ist in der Lage, einen Titel in der Entwurfsumgebung 194 (Fig. 2) zu betrachten. Bestimmte Funktionen des Betrachtungsprogramms 202 sind in der Entwurfsumgebung 194 verfügbar, damit beispielsweise leichter zu prüfen ist, wie ein Titel für einen Endbenutzer erscheint. Der Verleger kann die Arbeitsweise der Suchobjekte in der Entwurfsumgebung 194 überprüfen. Die Entwurfsumgebung 194 umfaßt eine erweiterte Version des Suchdialogs, damit eine Benutzerabfrage (Suche) geprüft werden kann.

D. Betrachtungsprozeß der oberen Ebene

Mit Bezug auf Fig. 9 wird nun ein Oberebenenfluß 650 der Betrachtungsprozesse zum Betrachten einer Titels beschrieben. Das Betrachtungsprogramm 202 (Fig. 2) auf dem Kundencomputer beginnt in einem Zustand 652 mit dem Erzeugen eines Baums der syntaktischen Titelanalyse, wie eines Titelbaums 620 (Fig. 8). Als nächstes wird ein Satz paralleler Teilprozesse erzeugt.
Der erste Teilprozeß beginnt in Zustand 654, in dem auf den ersten ein Suchobjekt aufweisenden Abschnitt zugegriffen wird und die Suchobjekte in diesem Abschnitt aufgelöst werden. Die Suchobjektauflösung wird in Zusammenhang mit den Fig. 11, 12, 17 und 18 beschrieben. Nach Übergehen in Zustand 656 wird auf den nächsten Suchobjekte aufweisenden Abschnitt zugegriffen, und der Teilprozeß setzt sich in einer Schleife mit Zustand 654 fort, um die Suchobjekte in diesem Abschnitt aufzulösen. Der erste Teilprozeß endet, wenn alle Suchobjekte aufweisenden Abschnitte verarbeitet worden sind.
Der zweite Teilprozeß beginnt in Zustand 658, in dem auf den ersten Abschnitt, der eine gültige Seite zur Betrachtung aufweist, zugegriffen wird und die Inhaltsobjekte in diesem Abschnitt gewonnen werden. Ein Baum der syntaktischen Inhaltsanalyse wird aus dem Titel, dem lokalen COS 402 (Fig. 5) oder dem COS-Server 246 gewonnen. Nach Übergehen in Zustand 660 wird auf den nächsten Abschnitt (oder Unterabschnitt) im Titel zugegriffen, und der Teilprozeß setzt sich in einer Schleife mit Zustand 658 fort, um den Inhalt in diesem Abschnitt zu gewinnen. Der zweite Teilprozeß endet, wenn alle den Inhalt aufweisenden Abschnitte verarbeitet worden sind.
Der dritte Teilprozeß beginnt in Zustand 662, in dem auf den ersten Abschnitt, der eine gültige Seite zur Betrachtung aufweist, zugegriffen wird und die erste Seite in diesem Abschnitt angezeigt wird. Falls diese Seite Suchobjekte aufwies, werden die Ergebnisse der Auflösung der Suchobjekte und der Gewinnung des Inhalts in das dynamische Steuerelement geleitet, das diesem Suchobjekt zugeordnet ist. Nach Übergehen in Zustand 664 wartet das Betrachtungsprogramm 202, bis der Kunde eine Aktion, wie "zur nächsten Seite übergehen" oder "zum Abschnitt XYZ übergehen", wählt. Das Betrachtungsprogramm 202 verarbeitet die Aktion, bewegt sich zum durch die Benutzeraktion angegebenen Teil des Titels und bestimmt, welche Seite betrachtet werden soll. Der dritte Teilprozeß setzt sich in einer Schleife mit Zustand 662 fort, um die in Zustand 664 bestimmte neue Seite anzuzeigen. Der dritte Teilprozeß endet, wenn der Benutzer das Betrachten des laufenden Titels beendet.
Die weitere Offenbarung der bevorzugten Arbeitsweise des Betrachtungsprogramms ist in einer anhängigen Anmeldung enthalten, die ebenfalls auf den Erwerber der vorliegenden Anmeldung, Microsoft Corporation, übertragen ist und am 17. Juli 1995 unter dem Titel "MULTIMEDIA PUBLISHING SYSTEM", mit der laufenden Nummer 08/503 343, eingereicht wurde.

E. Kundenabfrage

Mit Bezug auf Fig. 10 wird ein Abfragepfad, der von einem Suchdialog über das Informationswiederauffindungssystem 398 zur Inhaltsdatenbank im Veröffentlichungsspeicher 120 verläuft, beschrieben. Die Abfragekomponenten für Verleger 102 und Endbenutzerkunden 160 sind folgendermaßen definiert: ein MPS-Dokumenteditoreigenschaften-Dialog dient dem Markieren des Inhalts mit Schlüsselwörtern, um das Auffinden zu unterstützen (siehe Fig. 24), ein Suchobjekteditor dient dem Erzeugen und Modifizieren von Suchobjekten (auch als Informationsmagnete bekannt) durch Titelentwerfer (siehe Fig. 23) und ein Suchdialog 690 dient als eine Kundenschnittstelle für momentane und gespeicherte Suchen (siehe Fig. 22).
Der Inhalt, wie die Beiträge 680, 682 und 684, wird unter Verwendung des Dokumenteditoreigenschaften-Dialogs mit Tags markiert und in der MPS-Inhaltsdatenbank im Veröffentlichungsspeicher 120 angeordnet. Der Lnhalt wird dann an das Informationswiederauffindungssystem 398 zum Indexieren weitergeleitet. Suchobjekte sammeln Beiträge, die bestimmten Kriterien (die im Suchobjekteditor definiert sind) entsprechen, und "leiten" diese in die festgelegten Abschnitte eines Titels im Betrachtungsprogramm 202 (Fig. 2). Der Suchobjekteditor ist das Abfragewerkzeug, das Entwerfer zum Definieren von Suchobjekten verwenden, die zum Auffinden relevanter Beiträge und zum Leiten von diesen in den Titel verwendet werden. Der Kunde 160 verwendet den Suchdialog 690 im MPS-Betrachtungsprogramm 202, um eine oder mehrere Benutzerabfragen 692 für alle Beiträge eines bestimmten Titels (also jene Beiträge, die der Titel unter Verwendung eines oder mehrerer Suchobjekte aufgefunden hat, oder in einem Titel angeordnete statische Beiträge) auszugeben.
Die vom Kunden 160 im Suchdialog 690 ausgegebenen Abfragen 692 werden mit den Kriterien der Titelsuchen infolge des Suchobjekts (der Suchobjekte) vereinigt, und die Gesamtmenge wird dann in der Inhaltsdatenbank im Veröffentlichungsspeicher 120 und im IR-System 398 abgefragt. Die Ergebnisse 694 einschließlich der GUIDs (die den Abfragen und Suchobjekten entsprechende Beiträge darstellen) und der Eigenschaften, werden an den Kunden zurückgesendet und erscheinen in einem Ergebnisfeld 696 des Suchdialogs 690. Durch Kombinieren der Abfrage 692 mit den Suchobjektabfragen werden die Ergebnisse so beschränkt, daß sie innerhalb der Titelstruktur liegen und nicht aus einer beliebigen Quelle in der Inhaltsdatenbank stammen. Der Suchdialog 690 erlaubt es dem Kunden, eine oder mehrere Titel auszuwählen, die von dem vom Kunden gegenwärtig betrachteten Titel verschieden sind. In dieser Situation werden die Suchobjekte für diese Titel aufgelöst und mit den Kundenabfragekriterien vereinigt.

F. Betrachtungsprogramm-Suchobjekt- und Benutzerabfragefluß

Mit Bezug auf Fig. 11 wird die gegenwärtig bevorzugte Wechselwirkung des Betrachtungsprogramms 202 mit dem IR- System 398 als ein Flußdiagramm 700 beschrieben. In Fig. 11 ist der in Fig. 9 beschriebene Arbeitsgang des Betrachtungsprogramms erweitert und zusätzlich ein Benutzerabfragefluß (Suchablauf) aufgenommen.
Beginnend mit einem Anfangszustand 702 wird die Betrachtungsprogrammkomponente 202 (Fig. 2) aufgerufen. Wie vorstehend beschrieben wurde, befindet sich das Betrachtungsprogramm 202 am Kundencomputer 182, bestimmte Betrachtungsprogrammfunktionen sind jedoch auch am Arbeitsplatzrechner des Verlegers verfügbar, damit er beispielsweise Titel innerhalb der Entwurfsumgebung betrachten kann. Fortfahrend mit Zustand 704 bestimmt das Betrachtungsprogramm 202, welche Aktion vom Kunden gewählt wurde. Der Kunde kann wahlweise einen gewählten Titel (beginnend mit Zustand 708) durchsuchen, eine Benutzerabfrage (Suchdialog 690) vornehmen oder das Betrachtungsprogramm 202 in Zustand 706 beenden. Der Suchdialog 690 für eine Benutzerabfrage kann innerhalb eines gewählten Titels aufgerufen werden, oder er kann ohne vorheriges Wählen eines Titels (wobei ein getrenntes Anwendungsprogramm verwendet wird) gestartet werden.
Falls der Benutzer den Titel durchsuchen möchte, geht das Betrachtungsprogramm 202 in Zustand 708 zum ersten Abschnitt über, der eine gültige zu betrachtende Seite aufweist. Fortfahrend mit Zustand 710 greift das Betrachtungsprogramm auf den aktuellen Abschnitt zu und ruft alle Suchobjekte im Abschnitt (falls vorhanden) ab. Beim Übergang zu einer Funktion 712 werden durch die IR-Client-Dienste 435 (Fig. 6, 12) die Suchobjekte im aktuellen Abschnitt aufgelöst. Die Arbeitsweise des IR-Clients 435 für die Funktion 712 wird nachfolgend erörtert. Der IR-System- Arbeitsvorgang zum Auflösen von Suchobjekten wird in Zusammenhang mit den Fig. 17 und 18 erörtert. Fortfahrend mit Zustand 714 sortiert der IR-Client 435 die Ergebnisse der Suchobjektauflösung für den aktuellen Abschnitt. Wenn ein Suchobjekt den Suchobjektkriterien entsprechende Inhaltsobjekte findet, gibt es eine GUID und ausgewählte Sucheigenschaften, beispielsweise die Zeitangabe der Veröffentlichung, die Priorität und die Kennung des ICP, für jedes Inhaltsobjekt zurück. Wenn alle Suchobjekte für den Abschnitt aufgelöst wurden, sortiert der IR-Client 435 vorzugsweise die ausgewählten Eigenschaften der Inhaltsobjekte nach einem vorgegebenen Satz von Eigenschaften. Gemäß der bevorzugten Ausführungsform verwendet der IR-Client 435 die Priorität und die Zeitangabeeigenschaften für die Sortierung. Nach Übergehen in Zustand 716 werden vom Betrachtungsprogramm 202 die den zurückgegebenen GUIDs entsprechenden Inhaltsobjektdaten gewonnen. Die Inhaltsobjektdaten werden dann in Zustand 718 in die dynamischen Steuerelemente für den aktuellen Abschnitt geleitet, und es wird dem Benutzer die erste Seite des Abschnitts angezeigt. Das Betrachtungsprogramm geht dann in einer Schleife in Zustand 704 über, um auf die nächste Benutzeraktion zu warten.
Im vorstehenden Text wurden in einem Abschnitt angeordnete Suchobjekte beschrieben. Gemäß einer anderen Ausführungsform kann ein MPS-Steuerelement (innerhalb einer MPS-Seite) ein mit dem Steuerelement verbundenes Suchobjekt aufweisen. Durch diese Fähigkeit können die Suchobjektergebnisse auf einer Körnungssteuerebene statt auf der vorstehend beschriebenen Abschnittsebene sortiert werden.
Nach Zurückkehren zur Funktion 712 führt der IR-Client 435 (Fig. 6, 12) Zustände 720-726 aus, um die Suchobjekte im aktuellen Abschnitt aufzulösen. In Zustand 720 erhält der IR-Client 435 vom Betrachtungsprogramm 202 die GUID des aktuellen Abschnitts, eine Sortierungsspezifikation und eine Ergebnisspezifikation. Die Sortierungsspezifikation bestimmt, wie die Suchobjektergebnisse für den aktuellen Abschnitt sortiert werden. Die Ergebnisspezifikation bestimmt die interessierenden Eigenschaften, wie beispielsweise die Inhaltsobjekt-GUID, die Kontextinformationen und das Thema des Inhaltsobjekts. Gemäß der vorliegenden Ausführungsform ist die Ergebnisspezifikation als die ICP-Kennung, die Inhaltsobjekt-GUID, die Priorität und das Inhaltsobjekt- Modifikationsdatum vorgegeben und in die Betrachtungssoftware codiert. Gemäß der vorliegenden Ausführungsform ist die Sortierungsspezifikation als die Veröffentlichungszeitangabe und die Priorität (die beide Sucheigenschaften sind) vorgegeben und in die Betrachtungssoftware codiert. Es könnten natürlich auch andere Attribute für die Sortierungsspezifikation und die Ergebnisspezifikation verwendet werden. Fortfahrend mit Zustand 722 wird eine Abfragespezifikation auf der Grundlage eines vom Verleger gewählten Satzes von Kriterien für das Suchobjekt und einer oder mehrerer Quellen (Wurzelinhaltsordner), anhand derer die Kriterien bewertet werden, erzeugt. Die Abfragespezifikation wird zu einer Baumstruktur syntaktisch analysiert. Der Parser wird nachfolgend im Abschnitt "Kundenabfragenauflösung" näher beschrieben.
Fortfahrend mit der Funktion 712 in Zustand 724 wird die Suchobjektabfrage zum IR-System 398 gesendet. Die Ergebnisse der Suchobjektabfrage werden zum IR-Client zurückgegeben und in Zustand 726 gesammelt. Die Zustände 720-726 werden für jedes Suchobjekt im aktuellen Abschnitt wiederholt. Die Ergebnisse von jedem der Suchobjekte im aktuellen Abschnitt werden dann an den Zustand 714 weitergeleitet, wie vorstehend erörtert wurde.
Falls der Benutzer eine Benutzerabfrage ausgeben möchte, ruft das Betrachtungsprogramm 202 den Suchdialog 690 auf. Der Suchdialog verwendet eine IRFind-DLL. Fortfahrend mit einem Entscheidungszustand 730 bestimmt das Betrachtungsprogramm 202, ob der Benutzer den (die) Titel auswählen möchte, die zu durchsuchen sind. Falls der Benutzer einen Titel betrachtet und die Suche auf andere oder verschiedene Titel umlenken möchte, fährt das Betrachtungsprogramm 202 mit Zustand 732 fort, bei dem dem Kunden vorzugsweise ein MSN-Inhaltsbaum (Verzeichnisdienst) dargeboten wird, der nur MPS-Dienste und -Titel enthält. Der Kunde kann den Verzeichnisdienst durchsuchen und einen oder mehrere Titel für die Suche wählen. Falls der Kunde einen Titel betrachtet und die Suche nicht umlenken möchte, falls die Suche also am aktuellen Titel auszuführen ist, oder nach Abschluß des Zustands 732 geht das Betrachtungsprogramm 202 zurückkehrend zum Entscheidungszustand 730 in Zustand 734 über.
In Zustand 734 wählt der Benutzer die Teile eines Inhaltsobjekts, wie einen Artikel, woran die Suche auszuführen ist. Gemäß der bevorzugten Ausführungsform kann der Benutzer einen oder mehrere der folgenden Teile des zu durchsuchenden Inhaltsobjekts wählen, und zwar Titel, Schlüsselwörter und Text. Fortfahrend mit Zustand 736 spezifiziert der Benutzer einen Booleschen Textsuchausdruck, beispielsweise das Veröffentlichungsdatum, als das Suchkriterium. Der Suchausdruck wird nachfolgend im Abschnitt "Kundenabfragenauflösung" näher beschrieben. Der Zustand 736 wird gegenwärtig durch eine FindView-Klasse implementiert.
Nach Übergehen in Zustand 738 werden der (die) Titel und gewählte Teile der zu durchsuchenden Inhaltsobjekte zusammen mit den Suchkriterien als die Benutzerabfrage zum IR-System 398 gesendet. Die Zustände 738 und 740 verwenden eine IRCS- DLL. Der Zustand 738 wird gegenwärtig durch CCMDQuery::Execute() implementiert, wobei das Format Class::optional NestedClass::Function ist. Wenn vom IR-System 398 Treffer für die Benutzerabfrage bestimmt wurden, werden die Ergebnisse in Zustand 740 aufsteigend zum Suchdialog 690 zurückgesendet und in Zustand 742 im Ergebnisfeld 696 (Fig. 10) des Suchdialogs angezeigt. Der Zustand 740 wird gegenwärtig durch CCMDQueryExec::HandleRcvdObj implementiert. Gemäß der bevorzugten Ausführungsform umfassen die Ergebnisse das Titelfeld des Inhaltsobjekts in der Art eines Artikels, die Quelle (den Titel) des Artikels und die Veröffentlichungszeit des Artikels. Die Suchdialog-Benutzerschnittstelle wird nachfolgend im Abschnitt "Kundenabfragenauflösung" näher beschrieben.
Wenn die Ergebnisse in Zustand 742 im Ergebnisfeld angezeigt werden, kann der Kunde beispielsweise einen der Artikel auswählen und das Betrachtungsprogramm anweisen, (in Zustand 708) zum Abschnitt des den Artikel enthaltenden aktuellen Titels überzugehen oder zum entsprechenden Titel und Abschnitt des ausgewählten Artikels überzugehen, falls der Artikel (bei Betrachtung) nicht im aktuellen Titel enthalten ist.

6. Suchobjektstrukturen

Mit Bezug auf Fig. 12 werden nun die beim Auflösen von Suchobjekten verwendeten internen Strukturen des IR-Servers 272 (Fig. 3) erörtert. Der IR-Server 272 weist zwei Hauptkomponenten, und zwar einen Suchobjektserver 760 und einen Suchserver 780, auf. Diese Komponenten werden nachfolgend beschrieben.
Eine Suchobjektabfrage kann vom Betrachtungsprogramm 202 am Kundenort 160 oder vom Entwurfsprogramm 194 am Verlegerort 102, die beide in Fig. 2 dargestellt sind, eingeleitet werden. Das Entwurfsprogramm 194 weist Funktionen des Betrachtungsprogramms auf. Der Verleger erzeugt die Suchobjekte im Entwurfsprogramm 194 und möchte gelegentlich beispielsweise die Arbeitsweise der Suchobjekte prüfen, für die die Betrachtungsprogrammfunktionen verwendet werden. Wie in Zusammenhang mit Fig. 11 erörtert wurde, müssen vom Verleger im Titel definierte Suchobjekte aufgelöst werden, wenn ein Titel betrachtet wird. Falls der Titel nicht in Abschnitte zerlegt ist, sendet das Betrachtungsprogramm 202 (oder das Entwurfsprogramm 194) eine Liste von einer oder mehreren Suchobjekt-GUIDs 752 zum IR-Client 435. Das Betrachtungsprogramm 202 (oder das Entwurfsprogramm 194) sendet auch die Sortierungsspezifikation und die Ergebnisspezifikation, die in Zusammenhang mit Fig. 11 beschrieben wurden, zum IR-Client 435. Die Sortierungsspezifikation wird vom IR-Client 435 zum Sortieren der eingehenden Ergebnisse anhand einer Ergebnisliste 764 verwendet.
Der IR-Client 435 gibt dann die Suchobjekt-GUIDs 752 an den IR-Dienst 270 weiter, der die GUIDs 752 zum Suchobjektserver (SOS) 760 sendet. Der IR-Client 435 und der IR- Dienst 270 stellen die Software zur über das Netzwerk erfolgenden Kommunikation zwischen dem Client-Computer (beispielsweise bei 160, 102) und den IR-Servern bereit. Der IR-Client befindet sich auf dem Kundencomputer.
Wenn die Suchobjekt-GUIDs 752 am SOS 760 empfangen werden, wird in einem Entscheidungszustand 762 eine Prüfung vorgenommen, um zu bestimmen, ob die Suchobjekte zuvor aufgelöst wurden und mit ihren Ergebnissen in einem Abfrage- Cache-Speicher 1004 (Fig. 20) gespeichert sind. Wenn dies der Fall ist, werden die Ergebnisse, die die GUIDs und die Eigenschaften der passenden Inhaltsobjekte umfassen, vom Abfrage-Cache-Speicher 1004 zur Ergebnisliste 764 im IR- Dienst 270 gesendet. Die Ergebnisliste 764 wird durch den IR- Client 435 zur Quelle der Suchobjektabfrage, dem Betrachtungsprogramm 202 oder dem Entwurfsprogramm 194, zurückgesendet. Durch die Verwendung des Abfrage-Cache-Speichers 1004 (Fig. 20) ergeben sich viele Leistungsvorteile. Es ist wahrscheinlich, daß sich die Suchobjektabfrage und die Abfrageergebnisse für beliebte MPS-Titel im Abfrage-Cache- Speichers 1004 befinden, wodurch der Zugriff auf den Suchserver 780, den Datenbankserver 276 und die Datenbankpartitionen 782 unnötig gemacht wird.
Falls der Titel in Abschnitte zerlegt ist, sendet das Betrachtungsprogramm 202 (oder das Entwurfsprogramm 194) alternativ eine GUID 754 für einen Suchobjekte enthaltenden Abschnitt durch den IR-Client 435 und den IR-Dienst 270 zum SOS 760, wie vorstehend beschrieben wurde. Es sei bemerkt, daß nur die GUIDs der Abschnitte, die Suchobjekte aufweisen, zum IR gesendet werden. Wenn die Abschnitts-GUID 754 am SOS 760 empfangen wird, wird in einem Entscheidungszustand 766 eine Prüfung vorgenommen, um zu bestimmen, ob die Suchobjekte im Abschnitt 754 zuvor aufgelöst wurden und mit den Suchobjektergebnissen im Abfrage-Cache-Speicher 1004 (Fig. 20) gespeichert sind. Wenn dies der Fall ist, werden die Ergebnisse, die die GUIDs und die Eigenschaften der passenden Inhaltsobjekte für die Abschnitts-GUID 754 umfassen, zu einer Ergebnisliste 764 im IR-Dienst 270 gesendet. Diese Ergebnisliste wird durch den IR-Client 435 zur entsprechenden Anforderungsquelle, zum Betrachtungsprogramm 202 oder zum Entwerfer 194 zurückgesendet.
Falls der Entscheidungszustand 766 falsch ist, also sich die Suchobjekte und die Ergebnisse der Suchobjekte für die Abschnitts-GUID 754 nicht im Abfrage-Cache-Speicher 1004 befinden, wird die Abschnitts-GUID 754 zum Zugriff auf eine Abschnitts-/Suchobjekt-Kennungstabelle 768 verwendet, die ein Teil der Containertabelle in der Katalogdatenbank 1002 (Fig. 20) ist. Die Containertabelle wird in Zusammenhang mit Fig. 14 näher beschrieben. Die Abschnitts-GUID wird zum Zugriff auf die Abschnitts-/Suchobjekt-Kennungstabelle 768 verwendet, um alle Suchobjekte in einem bestimmten Abschnitt zu finden. Jedes Suchobjekt wird dann durch eine Suchobjekttabelle 774 in die Suchobjektabfrage umgewandelt. Ein alternativer Pfad zur Suchobjekttabelle 774 geht vom Entscheidungszustand 762 aus, falls sich die Suchobjekte und die Suchobjekt-Abfrageergebnisse nicht im Abfrage-Cache- Speicher 1004 (Fig. 20) befinden. Jedes Suchobjekt beinhaltet ein Suchkriterium und eine Quellenliste, also eine Liste von einer oder mehreren Quellen (Wurzelinhaltsordnern), auf die das Suchkriterium angewendet wird.
Die Suchobjektabfrage wird dann zum Suchserver 780 gesendet, der eine oder mehr Teilabfragen an den Datenbankserver 276 übergibt. Die Abfrage wird in einer Abfrageaufteilungsfunktion 1032 (Fig. 21) auf der Grundlage der Suchkriterien und der Quellen aufgeteilt. Jede Teilabfrage wird einem Arbeits-Teilprozeß 1026 zugewiesen, wie in Fig. 21 dargestellt ist. Der Arbeits-Teilprozeß beinhaltet eine Übersetzungsfunktion zum Übersetzen eines allgemeinen Formulars der Abfrage in eine serverspezifische Abfrage. Die serverspezifische Abfrage wird durch den Arbeits-Teilprozeß dem Datenbankserver 276 zugeführt.
Der Datenbankserver 276 verwendet die Indizes der Abfrage, um auf Tabellen, wie eine Eigenschaftsschlüsselwort- Tabelle 784 und eine Dokumenteinzelheiten-Tabelle 786, die in einer Anzahl von Datenbankpartitionen 782 gespeichert sind, zuzugreifen. Die Datenbank ist der Wirksamkeit halber in Partitionen eingeteilt. Der Datenbankserver 276 greift unter Verwendung der in der Abfrage bereitgestellten Indizes auf die spezifischen Tabellen zu und gibt die Suchergebnisse in Form von Inhaltsobjekt-GUIDs und Eigenschaften an den Suchserver 780 zurück. Die Suchergebnisse werden über den IR- Dienst 270 und den IR-Client 435 vom IR-Server 780 auf den Client-Computer weitergeleitet, wie vorstehend beschrieben wurde. Informationen (Eigenschaften) über die aufgefundenen Beiträge, wie Titel und Daten, werden der Quelle der Benutzerabfrage, also dem Betrachtungsprogramm 202 oder dem Entwurfsprogramm 194, zugeführt.

V. INDEXIEREN DES INHALTS

Nachdem ein Titel auf dem MPS-COS-Server 246 (Fig. 3) am Datenzentrum 242 veröffentlicht wurde, wird der Titel zum IR- System 398 (Fig. 5) übertragen. Ein Teil des IR-Systems 398 weist einen Indexdienst 1000 (Fig. 20) auf, der sich beispielsweise auf dem IR-Server 272a, einem Indexiererserver befinden kann. Dieser Abschnitt beginnt mit einer Beschreibung der Datenzentrumsansicht des Veröffentlichungsprozesses, weil sie das IR-System betrifft, worauf eine Beschreibung des Indexierprozesses folgt.

A. Titelveröffentlichung

Mit Bezug auf Fig. 13 wird nun die IR-Systemansicht des Titelveröffentlichungsprozesses 800 beschrieben. Der Prozeß 800 beginnt mit einem Anfangszustand 802 und geht in Zustand 804 über, in dem der COS-Serve 246 (Fig. 3) die vom Verleger 102 (Fig. 2) übertragene COS-Datei empfängt. Dieser Zustand verwendet die BBOBSvc-DLL. Nach Übergehen in Zustand 806 wird die empfangene COS-Datei auf den IR-Server 272 kopiert. Dieser Zustand verwendet die BBOBSvc-DLL. Gemäß einer gegenwärtig bevorzugten Ausführungsform der Erfindung wird die COS-Datei auf ein gemeinsam verwendetes Plattenlaufwerk auf dem Netzwerk kopiert, auf das der IR- Server 272 zugreift. In Zustand 808 benachrichtigt der COS- Server 246 das IR-System 398 über die empfangene COS-Datei, um mit der Verarbeitung der Datei zu beginnen. Dieser Zustand wird vom Dateisystem von Windows NT ausgeführt. Nachdem in Zustand 808 die Benachrichtigung am IR-System empfangen wurde, aktualisiert der IR-Server 272 in Prozeß 810 die Indizes in den Datenbankservern 276 und den IR-Systemtabellen mit neuen, modifizierten oder gelöschten Objekten der empfangenen COS-Datei. Dieser Prozeß ist der IR-Indexdienst und verwendet die IRIX- und IRUTS-DLLs. Nachdem in Prozeß 810 die Indizes und Tabellen aktualisiert wurden, endet der Prozeß 800 in einem Endzustand 812.

B. IR-Indexierung

Mit Bezug auf die Fig. 14-16 wird nun der IR- Indexierprozeß 810 zum Indexieren einer COS-Datei beschrieben. Der Prozeß verwendet die IRIX-DLL und die IRUTS- DLL. Der Prozeß 810 beginnt mit einem Anfangszustand 816 in Fig. 14 und geht in Zustand 818 über, um auf die veröffentlichte COS-Datei zuzugreifen. Der Zustand 818 wird gegenwärtig durch CBBXParser::UpdateIndexFromCOS implementiert. Fortfahrend mit Zustand 820 erhält der Prozeß 810 das veröffentlichte Paket, das eine Eigenschaft der veröffentlichten COS-Datei ist. Das Paket beinhaltet die Wurzelkennung (eine GUID) des Titels oder des Wurzelinhaltsordners und die Kennung des Verlegers oder des ICP. Fortfahrend mit Zustand 822 überprüft der Prozeß 810, ob die Wurzelobjektkennung in einer Objektinformationstabelle enthalten ist, die eine der Tabellen der Katalogdatenbank für das IR-System 398 ist. Die Objektinformationstabelle wird während des Indexierprozesses aktualisiert. Das Objektkennungsfeld enthält beispielsweise die Kennung eines Titels oder eines Dokuments in der Art eines Beitrags. Die Objekttypen im Objekttypfeld umfassen beispielsweise Suchobjekt, Beitrag, Titel, Abschnitt, Wurzelinhaltsordner usw. Die Felder der Objektinformationstabelle zusammen mit als Beispiel dienenden Daten sind in der nachfolgenden Tabelle 1 dargestellt: TABELLE 1 OBJEKTINFORMATIONSTABELLE Falls der Entscheidungszustand 824 bestimmt, daß die Wurzelkennung nicht in der Objektinformationstabelle enthalten ist, geht der Prozeß 810 zu einem Zustand 826 über und gewinnt das Wurzelobjekt aus der COS-Datei. Der Zustand wird gegenwärtig durch CBBXParser::IndexCOS1 implementiert. Fortfahrend mit Zustand 828 erzeugt der Prozeß 810 einen Eintrag für das Wurzelobjekt in der Containertabelle, die eine der Tabellen der Katalogdatenbank für das IR-System 398 ist. Die Felder der Containertabelle zusammen mit als Beispiel dienenden Daten sind in der nachfolgenden Tabelle 2 dargestellt: TABELLE 2 CONTAINERTABELLE
Das Beziehungsfeld wird zum Definieren der Beziehung zwischen dem Container- und dem Containee-Feld, wie beispielsweise Titel zu Abschnitt, Abschnitt zu Unterabschnitt, Abschnitt zu Suchobjekt, Titel zu Suchobjekt usw., verwendet. Gemäß der gegenwärtig bevorzugten Ausführungsform enthält das Wurzelcontainerfeld die GUID für einen Titel oder einen Wurzelinhaltsordner.
In Zustand 828 wird auch eine Quelle in einer Leitwegtabelle erzeugt. Die Felder der Leitwegtabelle zusammen mit als Beispiel dienenden Daten sind in der nachfolgenden Tabelle 3 dargestellt: TABELLE 3 LEITWEGTABELLE
Gemäß der gegenwärtig bevorzugten Ausführungsform beinhaltet das Quellenkennungsfeld in der Leitwegtabelle eine Titel-GUID oder eine Wurzelinhaltsordner-GUID. Das Datenbankpartitions- Feld kann einen Maschinennamen, einen Datenbanknamen und Teile eines Tabellennamens aufweisen. Das Verbindungsanzahlfeld definiert die Anzahl paralleler Verbindungen auf einem bestimmten Suchserver, wobei eine Verbindung ein Kommunikationskanal zwischen Maschinen ist.
Nach dem Abschluß des Zustands 828 oder beim Vorhandensein der Wurzelkennung in der Objektinformationstabelle setzt sich der Prozeß 810 mit einem Entscheidungszustand 830 fort, um zu bestimmen, ob das Wurzelobjekt ein Titel ist. Wenn dies der Fall ist, geht der Prozeß 810 zu einer Titelverarbeitungsfunktion 834 über. Die Funktion 834 wird gegenwärtig durch CBBXParser::ProcessTitle implementiert. Falls jedoch der Entscheidungszustand 830 bestimmt, daß das Wurzelobjekt ein Wurzelinhaltsordner ist, setzt sich der Prozeß 810 mit einer Wurzelinhaltsordner-Verarbeitungsfunktion 832 fort. Die Funktion 832 wird gegenwärtig durch CBBXParser::ProcessRootCF implementiert.
Mit Bezug auf Fig. 15 wird nun die in Fig. 14 definierte Titelverarbeitungsbeginn-Funktion 834 beschrieben. Die Funktion 834 verwendet die IRIX-DLL und wird gegenwärtig durch CBBXParser::ProcessTitle implementiert. Der Prozeß 810 beginnt mit einem Anfangszustand 840 und geht in einen Zustand 842 über, um alle Abschnitte im Titel zu erhalten. Der Zustand 842 wird gegenwärtig durch CBBXParser::CollectCosObjs implementiert. Fortfahrend mit Zustand 844 greift der Prozeß 810 auf den ersten Abschnitt im Titel zu. Fortfahrend mit einem Entscheidungszustand 846 bestimmt der Prozeß 810, ob der Abschnitt ein neuer oder ein gelöschter Abschnitt ist. Diese Situation tritt auf, falls der Verleger den Titel durch Hinzufügen oder Löschen eines Abschnitts des Titels modifiziert hat. Falls im Entscheidungszustand 846 bestimmt wurde, daß ein neuer oder gelöschter Abschnitt existiert, geht der Prozeß 810 in einen Zustand 848 über. Falls ein neuer Abschnitt existiert, erzeugt der Prozeß 810 einen Eintrag in der zuvor in Zusammenhang mit Fig. 14 beschriebenen Containertabelle. Beim Zustand 848 wird auch ein Eintrag in der Objektinformationstabelle erzeugt, die auch in Zusammenhang mit Fig. 14 beschrieben wurde. Schließlich wird ein Eintrag in einer Kontextinformationstabelle erzeugt, die eine der Tabellen der Katalogdatenbank für das IR-System 398 ist. Die Kontextinformationstabelle wird zum Umwandeln eines gegebenen Kontexts (ICP-Kennung, Quellenkennung, Abschnittskennung) in ein eindeutiges DWord (vier Bytes), beispielsweise während einer Benutzer(such)abfrage, verwendet. Die Felder der Kontextinformationstabelle zusammen mit als Beispiel dienenden Daten sind in der nachfolgenden Tabelle 4 dargestellt: TABELLE 4 KONTEXTINFORMATIONSTABELLE
Falls im Entscheidungszustand 846 bestimmt wird, daß ein Abschnitt gelöscht wurde, geht der Prozeß 810 in Zustand 848 über und löscht den Eintrag für diesen Abschnitt in der Containertabelle, in der Objektinformationstabelle und in der Kontextinformationstabelle. Beim Abschluß des Zustands 848 oder falls im Zustand 846 bestimmt wurde, daß ein neuer oder gelöschter Abschnitt nicht existiert, geht der Prozeß 810 in einen Zustand 850 über. Im Zustand 850 gewinnt der Prozeß 810 alle im Abschnitt vorhandenen Suchobjekte. Der Zustand 850 wird gegenwärtig durch CBBXParser::CollectCosObjs implementiert. Fortfahrend mit Zustand 852 greift der Prozeß 810 auf das erste Suchobjekt im Abschnitt zu. Fortfahrend mit einem Entscheidungszustand 854 bestimmt der Prozeß 810, ob das Suchobjekt ein neues Suchobjekt ist. Wenn dies der Fall ist, geht der Prozeß 810 in einen Zustand 856 über. Der Zustand 856 wird gegenwärtig durch CBBXParser::ProcessMagnet implementiert. In Zustand 856 erzeugt der Prozeß 810 einen Eintrag in einer Suchobjekt-/Kontexttabelle. Die Felder der Suchobjekt-/Kontextabelle sind zusammen mit als Beispiel dienenden Daten in der nachfolgenden Tabelle 5 dargestellt:

TABELLE 5

SUCHOBJEKT-/KONTEXTTABELLE

SUCHOBJEKTKENNUNG / KONTEXTKENNUNG
GUID DWORD
12875 2350
10999 2051
10999 2053
Zusätzlich wird ein Eintrag in der zuvor beschriebenen Objektinformationstabelle erzeugt und ein Eintrag in der auch zuvor beschriebenen Containertabelle erzeugt. Schließlich wird ein Eintrag in einer Suchobjekttabelle erzeugt, die eine der Tabellen der Katalogdatenbank für das IR-System 398 ist. Das Suchobjektabfragefeld enthält die Abfragedaten für das Suchobjekt, die gemäß der bevorzugten Ausführungsform Kriterien und eine oder mehrere Quellen oder Wurzelinhaltsordner enthalten, auf die die Kriterien angewendet werden. Die Felder der Suchobjekttabelle zusammen mit als Beispiel dienenden Daten sind in der nachfolgenden Tabelle 6 dargestellt:

TABELLE 6

SUCHOBJEKTTABELLE

SUCHOBJEKTKENNUNG SUCHOBJEKTABFRAGE
12875 Binärdatendarstellung (Sport und Basketball) in Quelle A
13000 Binärdatendarstellung (Schlittschuhlaufen) in Quelle B und Quelle C
Falls im Entscheidungszustand 854 bestimmt wurde, daß das Suchobjekt nicht neu ist, fährt der Prozeß 810 mit einem Entscheidungszustand 858 fort, um zu bestimmen, ob das Suchobjekt gelöscht wurde. Wenn dies der Fall ist, geht der Prozeß 810 in einen Zustand 860 über. Im Zustand 860 wird der Eintrag für das Suchobjekt in der Suchobjekt-/Kontexttabelle sowie in der Containertabelle gelöscht. Der Zustand 860 wird gegenwärtig durch CBBXParser::ProcessMagnet implementiert. Falls im Entscheidungszustand 858 bestimmt wird, daß das Suchobjekt nicht gelöscht wurde, setzt sich der Prozeß 810 mit einem Zustand 862 fort, weil das Suchobjekt modifiziert wurde, also nicht neu ist und nicht gelöscht wurde. Bei einem Zustand 862 aktualisiert der Prozeß 810 die Suchobjekttabelle, um das modifizierte Suchobjekt widerzuspiegeln.
Beim Abschluß von Zustand 856, Zustand 860 oder Zustand 862 geht der Prozeß 810 in einen Zustand 864 über, in dem Shortcuts verarbeitet werden, also das Objekt, mit dem der Shortcut verknüpft ist, konkretisiert wird. Ein Shortcut verweist auf ein Objekt im aktuellen Titel oder Inhaltsordner. Dieses Objekt kann ein Beitrag, ein Suchobjekt, ein Bild usw. sein. Durch Verarbeiten der Shortcuts in Zustand 864 kann der Prozeß 810 in geeigneter Weise den Tabellen die Informationen für ein dem Shortcut zugeordnetes Suchobjekt hinzufügen, wie in den Zuständen 856, 860 oder 862 definiert ist. Der Zustand 864 wird gegenwärtig durch CBBXParser::ResolveShortCuts implementiert.
Beim Abschluß von Zustand 864 geht der Prozeß 810 in einen Entscheidungszustand 866 über und bestimmt, ob im aktuellen Abschnitt weitere Suchobjekte vorhanden sind. Wenn dies der Fall ist, kehrt der Prozeß 810 in einer Schleife in Zustand 852 zurück und greift auf das nächste Suchobjekt im Abschnitt zu. Falls im aktuellen Abschnitt jedoch keine weiteren Suchobjekte vorhanden sind, fährt der Prozeß 810 mit einer Inhaltsverarbeitungsfunktion 868 zum Verarbeiten jeglicher Inhaltsobjekte im Abschnitt fort. Die Funktion 868 wird gegenwärtig durch CBBXParser::ProcessObject implementiert. Die Inhaltsverarbeitungsfunktion 868 wird in Zusammenhang mit Fig. 16 beschrieben. Beim Abschluß der Inhaltsverarbeitungsfunktion 868 setzt sich der Prozeß 810 mit einem Entscheidungszustand 870 fort, um zu bestimmen, ob im Titel weitere Abschnitte vorhanden sind. Falls im Titel keine weiteren Abschnitte vorhanden sind, geht der Prozeß 810 in einen Fertig-Zustand 872 über. Falls im Titel weitere Abschnitte vorhanden sind, kehrt der Prozeß 810 in einer Schleife in Zustand 844 zurück, um auf den nächsten Abschnitt im Titel zuzugreifen.
Mit Bezug auf Fig. 16 wird nun die in Fig. 15 definierte Inhaltsverarbeitungsfunktion 868 beschrieben. Der Prozeß 810 beginnt mit einem Anfangszustand 880 und geht in einen Zustand 882 über, um auf das erste Inhaltsobjekt im Abschnitt zuzugreifen. Fortfahrend mit einem Zustand 884 bestimmt der Prozeß 810, ob das Zugriffsinhaltsobjekt in der zuvor beschriebenen Objektinformationstabelle existiert. Wenn dies der Fall ist, fährt der Prozeß 810 mit Zustand 886 fort und bestimmt auf der Grundlage von Informationen aus der Leitwegtabelle die existierenden Objektpartitionen. Der Zustand 886 wird gegenwärtig durch CBBX- Indexer::XIndexer::GetIndexCopies implementiert. Sobald die Objektpartitionen bestimmt wurden, geht der Prozeß 810 in Zustand 888 über und löscht die Indexinformationen in den Datenbankservern 276 aus den identifizierten Partitionen. Der Zustand 888 wird gegenwärtig durch CBBX- Indexer::XIndexer::< Obj> Delete implementiert.
Beim Abschluß von Zustand 888 oder falls das Zugriffsinhaltsobjekt nicht in der Objektinformationstabelle existiert, wie im Entscheidungszustand 884 bestimmt wurde, geht der Prozeß 810 in einen Zustand 890 über. In Zustand 890 bestimmt der Prozeß 810 unter Verwendung der Leitwegtabelle auf der Grundlage der Quelle und des Veröffentlichungsdatums die Partitionen für das aktuelle Inhaltsobjekt. Der Zustand 890 wird gegenwärtig durch CBBXIndexer::XIndexer::Add implementiert. Fortfahrend mit Zustand 892 erzeugt der Prozeß 810 einen Eintrag in der Objektinformationstabelle für das aktuelle Inhaltsobjekt. Der Zustand 892 wird gegenwärtig durch CBBXParser::ProcessObject und CBBXIndexer::Add implementiert. Nach Übergehen in Zustand 894 erzeugt der Prozeß 810 Indexeinträge in den auf den Datenbankservern 276 befindlichen Partitionen, die in Zustand 890 identifiziert wurden. Der Zustand 894 wird gegenwärtig durch CBBXIndexer::XIndexer:Add implementiert. Fortfahrend mit einem Entscheidungszustand 896 bestimmt der Prozeß 810, ob im aktuellen Abschnitt weitere Inhaltsobjekte vorhanden sind. Wenn dies der Fall ist, geht der Prozeß 810 in einer Schleife in Zustand 882 über, um auf das nächste Inhaltsobjekt im Abschnitt zuzugreifen. Falls im aktuellen Abschnitt jedoch keine weiteren Inhaltsobjekte vorhanden sind, geht der Prozeß 810 in Zustand 898 über und kehrt zur Titelverarbeitungsfunktion 834 in Fig. 15 zurück.
Die Wurzelinhaltsordner-Verarbeitungsfunktion 832 gleicht im wesentlichen der vorstehend beschriebenen Inhaltsverarbeitungsfunktion 868. Daher ist keine weitere Beschreibung der Funktion 832 erforderlich.

VI. SUCHOBJEKTAUFLÖSUNG

In diesem Abschnitt wird der Prozeß des Auflösens von Suchobjekten am IR-System 398 (Fig. 5) beschrieben. Der Betrachtungsprogramm-Suchobjektfluß 700 wurde vorstehend in Zusammenhang mit Fig. 11 beschrieben. In diesem Abschnitt wird der Prozeß auf dem IR-Server 272 (Fig. 3) und dem DB- Server 276 beschrieben, nachdem das Betrachtungsprogramm 202 oder das Entwurfsprogramm 194 (Fig. 2) die Suchobjektabfrage gesendet hat.

A. Auflösen des Suchobjektflusses

Mit Bezug auf die Fig. 17 und 18 wird nun ein Prozeß 902 zum Auflösen von Suchobjekten am IR-System 398 (Fig. 5) beschrieben. Der Prozeß 902 verwendet die IRSV-DLL. Der Prozeß 902 beginnt mit einem Anfangszustand 904 aus Fig. 17, setzt sich mit einem Entscheidungszustand 906 fort und bestimmt, ob das Suchobjekt und die entsprechenden Suchobjektergebnisse im Abfrage-Cache-Speicher (auch als Suchobjekt-Cache-Speicher bekannt) 1004 (Fig. 20) vorhanden sind. Falls bestimmt wird, daß das Suchobjekt und die Ergebnisse im Abfrage-Cache-Speicher 1004 vorhanden sind, fährt der Prozeß 902 mit Zustand 908 fort. In Zustand 908 sendet der Prozeß 902 die Ergebnisse aus dem Abfrage-Cache- Speicher 1004 zur Ausgabewarteschlange 1018 (Fig. 20). Der Prozeß 902 endet in einem Endzustand 910. Falls die Prüfung des Abfrage-Cache-Speichers 1004 im Entscheidungszustand 906 jedoch zeigt, daß das Suchobjekt und die Ergebnisse nicht vorhanden sind oder falls die Abfrage geändert, also modifiziert wurde, geht der Prozeß 902 in einen Zustand 912 über. Im Zustand 912 lädt der Prozeß 902 das Suchobjekt aus der zuvor beschriebenen Suchobjekttabelle. Der Prozeß 902 geht dann zu einer Suchanforderungs-Auflösungsfunktion 914 über. Die Funktion 914 wird gegenwärtig durch CBBIRServer::XBBIRServer::ExecuteQuery implementiert. Die Funktion wird nachfolgend in Zusammenhang mit Fig. 18 beschrieben. Nach Abschluß der Suchanforderungs-Auflösungsfunktion 914 setzt sich der Prozeß 902 mit einem Zustand 916 fort, in dem die Suchanforderungsergebnisse in den Abfrage- Cache-Speicher 1004 (Fig. 20) geschrieben werden. Nach Übergehen in Zustand 908 werden die Suchanforderungsergebnisse aus dem Cache-Speicher zur Ausgabewarteschlange gesendet, wie vorstehend beschrieben wurde.
Mit Bezug auf Fig. 18 wird nun die in Fig. 17 definierte Suchanforderungs-Auflösungsfunktion 914 beschrieben. Der Prozeß 902 beginnt mit einem Anfangszustand 920, geht in einen Zustand 922 über und reiht die Suchanforderung in die Anforderungswarteschlange 1008 (Fig. 20) ein. Der Zustand 922 wird gegenwärtig durch CRequestManager::XRequestManager::AddRequest implementiert.
Nach Übergehen in Zustand 924 erhält der Prozeß 902 ein freies Organisationsprogramm 1014 (Fig. 20). Fortfahrend mit Zustand 926 führt der Prozeß partitionsspezifische Teilabfragen auf der Grundlage der Suchobjektkriterien und der einen oder mehreren dem Suchobjekt zugeordneten Quellen aus. Der Zustand 926 wird gegenwärtig durch CSupervisor::ProcessRequest implementiert. Fortfahrend mit einem Entscheidungszustand 928 bestimmt der Prozeß 902, ob die im Zustand 926 identifizierten partitionsspezifischen Teilabfragen (und die Teilabfrageergebnisse) im Abfrage-Cache- Speicher 1004 (Fig. 20) vorhanden sind. Falls alle Teilabfragen im Cache-Speicher vorhanden sind, wie im Entscheidungszustand 928 bestimmt wurde, geht der Prozeß 902 in Zustand 938 über, in dem jegliche Duplikate zwischen Teilabfragen beseitigt werden. Eine Situation, in der Duplikate zwischen den Teilabfragen existieren können, tritt dann auf, wenn eine Quelle in mehreren Partitionen existiert. Nach Abschluß des Zustands 938 ist die Funktion 914 abgeschlossen und kehrt in einem Rückkehrzustand 940 zum Prozeß 902 (Fig. 17) zurück.
Nach Zurückkehren zum Entscheidungszustand 928 wird der Prozeß 902 mit Zustand 930 fortgesetzt, um jegliche der partitionsspezifischen Teilabfragen (und Ergebnisse), die nicht im Abfrage-Cache-Speicher 1004 (Fig. 20) vorhanden waren, in eine Warteschlange einzureihen. Der Zustand 930 wird gegenwärtig durch CWorkUnitQueue:: XWorkUnit-Queue::QueueRequest implementiert. Jede nicht im Cache- Speicher vorhandene partitionsspezifische Teilabfrage wird in Zustand 930 nicht in die Warteschlange eingereiht, die Ergebnisse werden jedoch zur Verwendung in Zustand 938 gespeichert. Nachdem die Teilabfragen in Zustand 930 in eine Arbeitswarteschlange 1022 (Fig. 20) eingereiht wurden, wird der Prozeß 902 mit Zustand 932 fortgesetzt. In Zustand 932 gewinnt der Prozeß 902 einen verfügbaren Arbeits-Teilprozeß 1026 (Fig. 20). Nach Übergehen in Zustand 934 sendet der Arbeits-Teilprozeß 1026 die Teilabfrage zum Datenbankserver 276 (Fig. 3, 12, 20). Die Zustände 934 und 936 werden gegenwärtig durch CWorker::ProcessCriteria implementiert. Fortfahrend mit Zustand 936, erhält der Prozeß 902 die Ergebnisse vom Datenbankserver 276 und wird mit Zustand 938 fortgesetzt, um jegliche Duplikate zu beseitigen, wie zuvor beschrieben wurde. Der Zustand 938 wird gegenwärtig durch CSupervisor::ProcessResults implementiert. Alle spezifischen Teilabfragen (und Ergebnisse), für die im Entscheidungszustand 928 bestimmt wurde, daß sie im Cache-Speicher vorhanden sind, werden auch beim Beseitigen von Duplikaten in Zustand 938 verwendet.

B. Abfragenauflösungskomponenten

Fig. 20 zeigt die internen Datenstrukturen und Teilprozesse, die vom in Fig. 12 dargestellten Suchserver 780 verwendet werden. Der COS 246 führt einem Indexdienst 1000 Titel und Inhaltsobjekte zu. Der Indexdienst 1000 erzeugt und aktualisiert eine Katalogdatenbank 1002. Die Katalogdatenbank umfaßt die folgenden Tabellen: die Containertabelle, die Objektinformationstabelle, das Globalzustandsregister, die Suchobjekttabelle, die Kontexttabelle und die Quellenkennung-in-Kurznamen-Umwandlungstabelle. Die Containertabelle, die Objektinformationstabelle, die Suchobjekttabelle und die Kontexttabelle wurden bereits vorstehend beschrieben. Die Globalzustandsregister-Tabelle gehört nicht zum erfindungsgemäßen IR-System. Die Quellenkennung-in- Kurznamen-Umwandlungstabelle wird zum Umwandeln einer 16- Byte-Quellen-GUID in eine eindeutige 4-Byte-Nummer zum Erzeugen von Partitionsnamen anhand ihrer Quellenkennung verwendet. Die Felder der Quellenkennung-in-Kurznamen- Umwandlungstabelle sind in der nachfolgenden Tabelle 7 dargestellt:

TABELLE 7

QUELLENKENNUNG-IN-KURZNAMEN-UMWANDLUNGSTABELLE

QUELLENKENNUNG DWORD
GUID DWORD
Weil der COS-Server 246 dem Indexdienst 1000 nur neue, modifizierte oder gelöschte Objekte zuführt, muß der Indexdienst 1000 einen Abschnitt des Abfrage-Cache-Speichers 1004 ungültig machen. Anfänglich erzeugt der Indexserver 1000 eine Leitwegtabelle 1006, die einen Datenbank-Partitionsbezug für eine spezifische Quellenkennung bereitstellt. Diese Informationen werden von dem auch in Fig. 12 dargestellten Datenbankserver 276 bereitgestellt, nachdem die Indexiereigenschaften des Objekts und die GUID gespeichert worden sind.
Der Datenbankserver 276 verwaltet eine Anzahl von Datenbankpartitionen 1 bis N 782, wie in Fig. 12 dargestellt wurde. Falls eine Quellenkennung bereits einer Partition zugeordnet wurde, verwendet der Indexdienst 1000 die Leitwegtabelle 1006 zum Leiten von Indizes zur Partition 782. Der Indexdienst 1000 setzt das Schreiben in den Datenbankserver 276 fort, um die Katalogdatenbank 1002 zu aktualisieren und in die Leitwegtabelle zu schreiben, wenn neuer Inhalt und neue Titel freigegeben und an den Veröffentlichungsspeicher 120 (Fig. 1) übergeben werden.
Der in Fig. 12 dargestellte IR-Dienst 270 führt einer Anforderungswarteschlange 1008 im Suchserver 780 eine Benutzerabfrage oder Suchobjektabfrage 1010 (Fig. 12) zu. Jede Abfrage in der Anforderungswarteschlange 1008 wird von einem Anforderungsmanager 1012 gelesen. Der Anforderungsmanager 1012 weist einer einzelnen Abfrage einen von einer Sammlung von Organisationsprogramm-Teilprozessen 1014 zu. Jeder Organisationsprogramm-Teilprozeß 1014 weist eine Ergebnissammelfunktion 1016 auf. Die Ergebnissammlung 1016 überprüft den Abfrage-Cache-Speicher 1004, um zu bestimmen, ob der aktuellen Abfrage entsprechende Ergebnisse existieren. Im Abfrage-Cache-Speicher 1004 enthaltene Ergebnisse werden paketiert und einer Ergebnispakete 1020 enthaltenden Ausgabewarteschlange 1018 zugeführt. Die Ergebnissammlung 1016 benachrichtigt den Anforderungsmanager 1012 über das neue Ergebnispaket, und es wird dem IR-Dienst 270 (Fig. 12) ein Ergebnisereignis zugeführt. Der IR-Dienst 270 (Fig. 12) liest dann Ergebnispakete aus der Ausgabewarteschlange 1018.
Falls der Abfrage-Cache-Speicher 1004 die Abfrage nicht enthält, teilt das Organisationsprogramm 1014 die Abfrage 1010 in eine Anzahl von Teilabfragen 1024 auf. Die Teilabfragen werden einer Sammlung von Arbeitseinheits- Warteschlangen WQ1 und WQn 1022 zugeführt. Jede Arbeitseinheits-Warteschlange 1022 ist einem physikalischen Datenbankserver zugeordnet. Tatsächlich werden nun Datenbankabfragen in eine Warteschlange eingereiht, um sie für Datenbankserver auszuführen. Eine Sammlung von Arbeits- Teilprozessen 1026 bedient die Arbeitseinheits-Warteschlangen 1022. Der Arbeits-Teilprozeß 1026 überprüft den Abfrage- Cache-Speicher 1004, um zu bestimmen, ob die Teilabfrage 1024 und ihre Ergebnisse existieren. Wenn dies der Fall ist, werden die Ergebnisse zur Ergebnissammelfunktion 1016 im Organisationsprogramm-Teilprozeß 1014 gesendet und der Ausgabewarteschlange 1018 zugeführt, wie vorstehend erörtert wurde. Alle verfügbaren Arbeits-Teilprozesse 1026 werden zum Bedienen aller verfügbaren Arbeitseinheits-Warteschlangen 1022 verwendet. Dies gewährleistet eine wirksame Verwendung von Arbeits-Teilprozessen und eine wirksame Verwendung physikalischer Datenbank-Servermaschinen. Als eine Optimierung werden, wenn möglich, den gleichen Indextyp verwendende Teilabfragen zusammengeführt und unter Bildung einer einzigen Arbeitseinheit zur gleichen physikalischen Maschine gesendet.
Gemäß einer alternativen Ausführungsform können Arbeitseinheits-Warteschlangen einer Partition des indexierten Inhalts zugeordnet werden.
Die Sammlung von Arbeits-Teilprozessen 1026 und Organisationsprogramm-Teilprozessen 1014 ermöglicht einen Belastungsausgleich sowie eine Erweiterbarkeit. Bei einem alternativen Entwurf, bei dem der Belastungsausgleich weniger wichtig ist, könnten die Organisationsprogramm-Teilprozesse und/oder Arbeits-Teilprozesse des Anforderungsmanagers zu einem einzigen Prozeß vereinigt werden. Beispielsweise kann ein bestimmter Arbeits-Teilprozeß 1026 im SQL-Eigenmodus, im Fulcrum-Eigenmodus oder in einer anderen Datenbankabfragesprache oder bei einem anderen Suchtyp ablaufen.
Der Arbeits-Teilprozeß 1026 übergibt eine Teilabfrage in einem spezifischen Eigenmodus an einen spezifischen Datenbankserver 276. Der Datenbankserver 276 greift auf eine spezifische Datenbankpartition oder auf spezifische Datenbankpartitionen zu, um die Teilabfrage zu erfüllen. Die Abfrageergebnisse werden vom Datenbankserver 276 zum Arbeits- Teilprozeß zurückgesendet, und die Abfrage und die Ergebnisse werden zusammen in den Abfrage-Cache-Speicher 1004 geschrieben. Die Ergebnisse werden auch zur Ergebnissammelfunktion 1016 des Organisationsprogramms 1014 gesendet, die die ursprüngliche Abfrage in Teilabfragen aufgeteilt hat. Die Abfrageergebnisse werden dann der Ausgabewarteschlange 1018 zugeführt, wie vorstehend erörtert wurde.
Die Teilabfragen können von jedem Organisationsprogramm 1014 seriell oder parallel zu den Arbeitswarteschlangen 1022 geleitet werden. Um eine ausgeglichene Betriebsmittelzuordnung zu gewährleisten, übergibt das Organisationsprogramm 1014 eine Teilabfrage, wartet auf die Ergebnisse und übergibt dann eine weitere Teilabfrage. Falls es jedoch die Verarbeitungsgeschwindigkeit zuläßt, weil es beispielsweise wenige Abfragen für die gegebenen Serverbetriebsmittel gibt, können mehrere Teilabfragen gleichzeitig übergeben werden. Wenn beispielsweise eine Teilabfrage 1 und eine Teilabfrage 2 gegeben sind, wird die Teilabfrage 1 in eine Arbeitswarteschlange und die Teilabfrage 2 in eine andere eingereiht.

VII. KUNDENABFRAGENAUFLÖSUNG

In diesem Abschnitt wird der Prozeß des Auflösens einer Kundenabfrage am IR-System 398 (Fig. 5) beschrieben. Der Betrachtungsprogramm-Benutzerabfragen-(Suchdialog)-Fluß 700 wurde bereits in Zusammenhang mit Fig. 11 beschrieben. In diesem Abschnitt wird der Prozeß auf dem IR-Server 272 (Fig. 3) und dem DB-Server 276 beschrieben, nachdem das Betrachtungsprogramm 202, das Entwurfsprogramm 194 (Fig. 2) oder der Suchdialog 690 (Fig. 10) die Benutzerabfrage gesendet hat.

A. Auflösen des Benutzerabfrageflusses

Mit Bezug auf Fig. 19 wird nun ein Benutzerabfrage- Auflösungsprozeß 950 beschrieben. Der Prozeß 950 verwendet die IRSV-DLL. Der Prozeß 950 beginnt mit einem Anfangszustand 952 und wird mit Zustand 954 fortgesetzt, um eine Schleife für jeden Titel oder jede Quelle, die mit der Abfrage identifiziert ist, einzuleiten, wobei eine Quelle in diesem Zusammenhang ein Wurzelinhaltsordner ist. Es sei bemerkt, daß gemäß der gegenwärtig bevorzugten Ausführungsform der Verleger 102 in der Entwurfsumgebung 194 (Fig. 2) sowohl Titel als auch Wurzelinhaltsordner spezifizieren und durchsuchen kann, daß der Kunde jedoch Wurzelinhaltsordner weder spezifizieren noch durchsuchen kann. Nach Übergehen in einen Entscheidungszustand 956 bestimmt der Prozeß 950, ob die Benutzerabfrage und die Abfrageergebnisse für den aktuellen Titel oder die aktuelle Quelle im Abfrage-Cache- Speicher 1004 (Fig. 20) vorhanden sind. Falls die Benutzerabfrage und die Ergebnisse im Abfrage-Cache-Speicher 1004 vorhanden sind, geht der Prozeß 950 in einen Entscheidungszustand 958 über, um zu bestimmen, ob es zusätzliche der aktuellen Benutzerabfrage zugeordnete Titel oder Quellen gibt. Falls es weitere der aktuellen Benutzerabfrage zugeordnete Titel oder Quellen gibt, kehrt der Prozeß 950 in einer Schleife in Zustand 954 zurück, um auf den nächsten Titel oder die nächste Quelle, der oder die der aktuellen Benutzerabfrage zugeordnet ist, zuzugreifen. Falls es jedoch keine der aktuellen Benutzerabfrage zugeordneten Titel oder Quellen gibt, geht der Prozeß 950 in Zustand 960 über. In Zustand 960 sendet der Prozeß 950 die Abfrageergebnisse aus dem Abfrage-Cache-Speicher 1004 (Fig. 20) zur Ausgabewarteschlange 1018 (Fig. 20). Nach dem Abschluß des Zustands 960 endet der Prozeß 950 mit einem Endzustand 962.
Falls bestimmt wurde, daß die aktuelle Benutzerabfrage und die Ergebnisse nicht im Abfrage-Cache-Speicher 1004 vorhanden sind, geht der Prozeß 950, zurückkehrend zum Entscheidungszustand 956, in einen Entscheidungszustand 964 über, um zu bestimmen, ob ein Titel oder ein Wurzelinhaltsordner momentan verarbeitet wird. Falls im Entscheidungszustand 964 bestimmt wird, daß ein Titel momentan verarbeitet wird, geht der Prozeß 950 in Zustand 966 über, um auf die im Titel enthaltenen Suchobjekte zu erweitern. Der Prozeß 950 greift auf die zuvor beschriebene Containertabelle zu, um die im Titel enthaltenen Suchobjekte zu erhalten. Von der Containertabelle aus greift der Prozeß 950 dann auf die Suchobjekttabelle zu, um die Suchobjektabfrage zu erhalten. Nach Übergehen in Zustand 968 wird die Suchobjektabfrage auf die darin enthaltenen Quellen erweitert. Das Suchobjekt enthält eine Liste von Quellen als eine Quellenspezifikation. Die Kriterien aus den Quellenobjekten werden (durch eine Boolesche UND-Operation) mit den vom Benutzer definierten Kriterien kombiniert und auf die relevanten Quellen in der Quellenspezifikation angewendet. Die Zustände 966 und 968 werden gegenwärtig durch CSupervisor::ProcessTitle implementiert. Beim Abschluß des Zustands 968 oder falls im Entscheidungszustand 964 bestimmt wurde, daß eine Quelle gerade verarbeitet wird, geht der Prozeß 950 in Zustand 970 über. In Zustand 970 erzeugt der Prozeß 950 quellenspezifische Teilabfragen. Nach Übergehen in Zustand 972 werden die quellenspezifischen Teilabfragen durch Erzeugen partitionsspezifischer Teilabfragen weiter präzisiert. Gemäß einer gegenwärtig bevorzugten Ausführungsform wird diese weitere Präzisierung unter Verwendung des Veröffentlichungsdatums der Quelle erzielt. Gemäß einer weiteren Ausführungsform werden andere Kriterien verwendet. Die Zustände 970 und 972 werden gegenwärtig durch CSupervisor::ProcessSources implementiert.
Beim Abschluß des Zustands 972 wird der Prozeß 950 mit einem Entscheidungszustand 974 fortgesetzt und überprüft den Abfrage-Cache-Speicher 1004 (Fig. 20), um zu bestimmen, ob die erste Teilabfrage und die entsprechenden Teilabfrageergebnisse vorhanden sind. Falls die Teilabfrage und die Ergebnisse vorhanden sind, wie im Entscheidungszustand 974 bestimmt wird, wird der Prozeß 950 mit einem Entscheidungszustand 984 fortgesetzt und bestimmt, ob im Entscheidungszustand 974 zusätzliche in den Zuständen 970 und 972 erzeugten Teilabfragen überprüft werden können, um zu bestimmen, ob sie im Abfrage-Cache-Speicher 1004 vorhanden sind.
Falls im Entscheidungszustand 974 bestimmt wird, daß die aktuelle Teilabfrage nicht im Abfrage-Cache-Speicher 1004 vorhanden ist, wird der Prozeß 950 mit einem Zustand 976 fortgesetzt, in dem die aktuelle Teilabfrage in eine Arbeitswarteschlange 1022 (Fig. 20) eingereiht wird. Der Zustand 976 wird gegenwärtig durch CWorkUnitQueue:: XWorkUnit-Queue::QueueRequest implementiert. Nach Übergehen in einen Zustand 978 erhält der Prozeß 950 einen verfügbaren Arbeits- Teilprozeß 1026 (Fig. 20). Fortfahrend mit Zustand 980 sendet der Arbeits-Teilprozeß 1026 die aktuelle Teilabfrage zum Datenbankserver 276. Nach Übergehen in Zustand 982 erhält der Arbeits-Teilprozeß 1026 die Ergebnisse vom Datenbankserver 276. Die Zustände 980 und 982 werden gegenwärtig durch CWorker::ProcessCriteria implementiert. Beim Abschluß des Zustands 982 wird der Prozeß 950 mit einem Entscheidungszustand 984 fortgesetzt, um zu bestimmen, ob für die aktuelle Benutzerabfrage weitere Teilabfragen vorliegen. Falls im Entscheidungszustand 984 bestimmt wird, daß alle Teilabfragen für diese aktuelle Abfrage aufgelöst worden sind, geht der Prozeß 950 in Zustand 986 über, in dem alle Duplikatergebnisse aus den Teilabfragen beseitigt werden. Der Zustand wird gegenwärtig durch CSupervisor::ProcessResults() implementiert. Nach Übergehen in Zustand 988 werden die Teilabfragen und die Abfrageergebnisse in den Abfrage-Cache- Speicher 1004 geschrieben. Beim Abschluß des Zustands 988 geht der Prozeß 950 in einen Entscheidungszustand 958 über, um zu bestimmen, ob es noch weitere Titel oder Quellen für die aktuelle Benutzerabfrage gibt, die noch nicht verarbeitet worden sind, wie zuvor beschrieben wurde.

B. Benutzerabfragestrukturen

Fig. 21 zeigt die Innenstruktur des Suchservers 780 in einer Informationswiederauffindungsumgebung, die zum Auflösen einer Benutzerabfrage erforderlich ist. Eine Benutzerabfrage kann vom Betrachtungsprogramm 202 oder vom Entwurfsprogramm 194 eingeleitet werden, die beide in den Fig. 2 und 12 dargestellt sind. Überdies kann die Benutzerabfrage durch eine getrennte Suchkomponente 690 erzeugt werden. Die Benutzerabfrage wird beispielsweise auf einem Kundencomputer 180 oder einem Verleger-Computer 182 (Fig. 2) erzeugt. Der IR-Client 435 und der IR-Dienst 270 funktionieren in der zuvor in Fig. 12 beschriebenen Weise, um die Software zur über das Netzwerk erfolgenden Kommunikation zwischen dem Client-Computer (beispielsweise 180, 182) und den IR-Servern bereitzustellen. Die Benutzerabfrage wird dem Suchserver 780 zugeführt, der eine oder mehrere Teilabfragen an den in Fig. 12 dargestellten Datenbankserver 276 übergibt. Der Datenbankserver 276 verwendet die Indizes der Abfrage, um auf Tabellen, wie die Eigenschaftsschlüsselwort-Tabelle 784 und die Dokumenteinzelheiten-Tabelle 786, die in einer Anzahl von Datenbankpartitionen 782 gespeichert sind, zuzugreifen.
Die Datenbank wird der Wirksamkeit halber in Partitionen eingeteilt, dies ist jedoch nicht unbedingt erforderlich.
Die Benutzerabfrage wird durch den IR-Dienst dem Suchserver 780 zugeführt, wo die Abfrage einem Organisationsprogramm 1014 in der Art des in Fig. 20 dargestellten zugeordnet wird. Falls sich die Benutzerabfrage auf einen oder mehrere Titel bezieht, wird unter Bezugnahme auf die dargestellten Tabellen auf die Katalogdatenbank 1002 (Fig. 20) zugegriffen. Die Titel-/Abschnittstabelle 1030 und die Abschnitts-/Suchobjektkennungs-Tabelle 768 gehören zur Containertabelle in der Katalogdatenbank 1002. Die Titel- /Abschnittstabelle 1030 stellt eine Liste aller Abschnitte im Titel bereit, und jeder Abschnittsname wird zum Zugriff auf die Abschnitts-/Suchobjektkennungs-Tabelle 768 verwendet, um alle Suchobjekte in einem bestimmten Abschnitt zu finden. Jedes Suchobjekt wird dann durch die Suchobjekttabelle 774 in eine Suchobjektabfrage umgewandelt. Die Benutzerabfrage wird in der Abfrageaufteilungsfunktion 1032 aufgeteilt. Jede Teilabfrage wird einem Arbeits-Teilprozeß 1026 zugewiesen, wie in Fig. 20 dargestellt ist.
Der Arbeits-Teilprozeß beinhaltet eine Übersetzungsfunktion 1036 zum Übersetzen eines allgemeinen Formulars der Abfrage in eine serverspezifische Abfrage. Falls der Datenbankserver beispielsweise die SQL-Sprache versteht, wird die Benutzerabfrage in verallgemeinerter Form in die SQL- Sprache übersetzt. Die serverspezifische Abfrage wird vom Arbeits-Teilprozeß 1026 dem Datenbankserver 276 zugeführt. Der Datenbankserver 276 greift unter Verwendung der in der Abfrage bereitgestellten Indizes auf seine spezifischen Tabellen zu und gibt Suchergebnisse in Form von Beitragskennungen und Eigenschaften zum Organisationsprogramm 1014 zurück. Durch eine Zuordnungs-/Filterungsfunktion 1038 im Organisationsprogramm 1014 werden Duplikate von Suchobjekten beseitigt. Die Suchergebnisse werden dann durch eine Paketierungsfunktion 1040 paketiert und der Ausgabewarteschlange 1018 zugeführt. Die Abfrageergebnisse werden vom IR-System über den IR-Dienst 270 und den IR-Client 435 an den Client-Computer weitergeleitet. Informationen (Eigenschaften) über die aufgefundenen Beiträge, wie der Titel und das Datum, werden an die Quelle der Benutzerabfrage, also das Betrachtungsprogramm, das Entwurfsprogramm oder Client- Komponenten, übermittelt.
Es wird verständlich sein, daß das erfindungsgemäße Informationswiederauffindungssystem zum Handhaben einer großen Anzahl von Abfragen in einem Online-Netzwerk ausgelegt ist. Die Erfindung hängt jedoch nicht von einer bestimmten Architektur von Teilprozessen, Datenbanken, Tabellen, Partitionen usw. ab. Es wurde nur eine gegenwärtig bevorzugte Ausführungsform beschrieben.

C. Benutzerabfrage-(Suchdialog)-Schnittstelle

1. Übersicht
Es sei auf Fig. 22 Bezug genommen. Benutzer von MPS- Titeln sind in der Lage, im Titelinhalt nach Elementen zu suchen, die mit einem Textausdruck übereinstimmen. Der Suchausdruck wird dem Text gegenübergestellt, den Autoren unter Verwendung des Eigenschaftsdialogs des MPS- Dokumenteditors (siehe Fig. 24) in Eigenschaftsfelder eines Beitrags eingegeben haben. Eine MPS-Suche kann zur späteren Verwendung in einer Datei gespeichert werden. Der Textsuchausdruck wird allgemein auf alle Standardeigenschaftsfelder im vorliegenden Dokumenteditor-Eigenschaftsdialog angewendet.
Die Hauptaufgaben, die der Benutzer mit dem Suchdialog (Fig. 22) ausführen kann, umfassen:
- Aktuellen Titel finden. Eine der üblichsten Anwendungen dieses Dialogs ist die Suche nach einem Beitrag im aktuellen aktiven Titel. Durch Wählen des Suchbefehls aus dem Betrachtungsprogramm wird der Suchdialog mit den für die Titelwahl vorgegebenen Feldwerten gestartet. Das "Suche in"-Feld wird auf den Namen des aktuellen Titels gelegt.
- Mehrere Titel finden. Der Benutzer kann einen Suchdialog "umlenken", um einen anderen oder mehrere andere Titel zu durchsuchen. Artikel aus den verschiedenen Titeln werden zusammen in der Ergebnisliste angezeigt. Durch Anklicken eines Ergebnisses wird der Beitrag im entsprechenden Titel geöffnet.
- Suchen speichern/editieren. Die Suchen können in einer Datei gespeichert und später für eine erneute Suche wieder geöffnet werden.
Das Titelentwurfsprogramm steuert die mit Firmenzeichen markierte Erscheinung und Navigation. Um zu gewährleisten, daß Titelverleger die Kontrolle über ihren Inhalt und ihre Navigation behalten, erzeugt der Suchdialog eine Liste von Treffern (im wesentlichen Shortcuts) in einem Titel. Durch Anklicken eines Treffers wird der Benutzer zum Beitrag im mit Firmenzeichen markierten Kontext des Titels gebracht, woraufhin der Benutzer durch den Titel navigieren kann, wie es der Titelentwerfer beabsichtigt. Der Suchdialog bietet unabhängig davon, ob nach Dateien auf einer Festplatte, Diensten auf MSN oder Artikeln in einer Zeitung gesucht wird, ein kohärentes Sucherlebnis.
2. Dialogtasten und -felder
- Enthält. Der Benutzer gibt in dieses Feld einen Booleschen Textsuchausdruck ein. Der Benutzer kann auch ein Drop-Down-Steuerelement verwenden, um eine vorhergehende Suchzeichenkette auszuwählen (die letzten fünf werden gemäß der vorliegenden Ausführungsform beibehalten). Der Text wird dann syntaktisch analysiert und indexiert, so daß er von der Serverseite verwendet werden kann. Der Parser verhält sich folgendermaßen:
Stoppwörter werden ignoriert. Stoppwörter sind Wörter oder Zeichenketten, die vom Parser hinsichtlich des aufzufindenden Texts ignoriert werden. Es sei bemerkt, daß einige von ihnen als Operatoren oder Listentrennzeichen interpretiert werden können, so daß sie aus der Zeichenkette herausgezogen werden, bevor Stoppwörter entfernt werden. Gemäß einer bevorzugten Ausführungsform besteht die Liste von Stoppwörtern bei der Englischen Sprache aus a, an, the. Es sei bemerkt, daß diese Liste bei Fremdsprachen länger oder kürzer sein kann, so daß die Anzahl der Zeichenketten nicht fest codiert ist.
Alle Abfragen sind von der Groß-/Kleinschreibung unabhängig, selbst wenn Anführungszeichen zur buchstäblichen Auslegung verwendet werden.
Der Ausdruck wird in eine Liste einzelner Begriffe zerlegt. Spezielle Begrenzungszeichen sind das vom System definierte Listentrennzeichen (nachfolgend als "listsep" bezeichnet und in dieser Beschreibung als Komma angenommen) und die Operatoren UND und ODER. Falls keine von diesen im eingegebenen Begriff vorhanden sind, wird angenommen, daß die Liste ein aufzufindender Ausdruck ist. 'Zeichentrick Musik' im Gegenstandstextkasten gewinnt beispielsweise alle Stellen, an denen beide Wörter zusammen als der Ausdruck, jedoch nicht nur das eine oder das andere Wort auftreten. Falls Leerschritte nicht die einzigen Begrenzungszeichen im eingegebenen Begriff sind, wird die Begriffsliste auf der Grundlage der speziellen Begrenzungszeichen ausgefüllt. 'Außenpolitik' und 'Gold' würden eine aus zwei Begriffen bestehende Liste ergeben. 'Larry, Moe oder Curly Sue' würden eine aus drei Begriffen bestehende Liste ergeben.
Anführungszeichen dienen der buchstäblichen Auslegung von Begrenzungszeichen oder -wörtern. Es können auch Einzel- oder Doppelanführungszeichen verwendet werden, um ein oder mehrere Wörter speziell zu begrenzen, so daß "Außenpolitik" Gold Dasselbe wie das erste Beispiel bedeuten würde, auch wenn kein anderes Begrenzungszeichen verwendet wurde.
Falls in einem Schlüsselworteditierkasten ODER auftritt, jedoch UND niemals auftritt, wird angenommen, daß alle Begriffe durch ODER miteinander verknüpft werden, wie in:
Larry, Moe oder Curly Sue == Larry ODER Moe ODER Curly Sue
Falls weder UND noch ODER auftritt oder UND irgendwo im Editierkasten auftritt, wird angenommen, daß zwei beliebige Begriffe, die nicht speziell durch ODER verknüpft sind, durch UND verknüpft sind. Jegliche am Anfang oder Ende eines Editierkastens stehende Konjunktionen werden verworfen.
Symbole. Die Symbole & und werden als Entsprechungen für UND bzw. ODER interpretiert.
Reihenfolge von Operationen. Sobald die Boolesche Logik aufgelöst wurde, ist es belanglos, in welcher Reihenfolge diese Begriffe syntaktisch analysiert werden.
- In. Der Benutzer kann durch Anwählen beliebiger der drei Wahlkästchen, nämlich Titel, Schlüsselwörter und Text (Körper des Artikels) wählen, in welchen Teilen des Artikels nach dem Ausdruck zu suchen ist. Vorgabemäßig sind alle drei Möglichkeiten angewählt. Der entsprechende durchsuchte Teil des Eigenschaftsfelds (der Eigenschaftsfelder) des Artikels wird nachfolgend in Einzelheiten dargelegt:
für Titel -- Titelfeld,
für Schlüsselwörter -- Thema, Ort, Autor, Person, Organisation, Ereignisdatum, Priorität
und
für Text -- der gesamte Textkörper des Artikels.
- Veröffentlicht. Wenn Beiträge am MSN-Datenzentrum empfangen werden, werden sie nach der Ankunft mit der Angabe der mittleren Greenwich-Zeit (GMT) markiert. Der Verleger kann vor der Veröffentlichung das Veröffentlichungsdatum und die Veröffentlichungszeit als eine Eigenschaft für den Beitrag festlegen. Der Benutzer kann die durch den Suchdialog aufgefundenen Artikel auf diejenigen beschränken, die an einem gegebenen Tag oder innerhalb eines Zeitraums veröffentlicht wurden. Dieser durch die Suchabfrage festgelegte Zeitraum wird am Client (unter Verwendung der Computeruhr und der lokalen Zeitzone von Windows 95) zu GMT normiert, bevor er zum IR-Server gesendet wird, so daß der Zeitvergleich immer in GMT erfolgt.
Die in alphabetischer Reihenfolge angeordneten Optionen am "Veröffentlicht"-Drop-Down-Steuerelement umfassen "Nach", "Jederzeit" (Vorgabe), "Vor", "Zwischen", "Innerhalb der letzten" und "Am". Bei "Jederzeit" wird für die aufzufindenden Artikel keine Einschränkung hinsichtlich des Veröffentlichungsdatums festgelegt. Den Wahlmöglichkeiten "Am", "Nach" und "Vor" folgt jeweils ein einziges Datumsfeld rechts, das nach Vorgabe das laufende Datum anzeigt. Im Datumsfeld werden eine drei Buchstaben enthaltende Wochentagabkürzung und ein als mm/DD/YY formatiertes Datum angezeigt. Der Wochentag, mm, DD und YY sind wählbare Felder, die durch Eingabe von der Tastatur, durch die Pfeilaufwärts- /Pfeilabwärtstaste und durch die Nummernfeldtasten rechts vom Datumsfeld editiert werden können. Durch Drücken einer Buchstabentaste, wenn der Wochentag gewählt ist, wird der Tagwert zyklisch zum nächsten passenden Wert geändert (beispielsweise wird durch Drücken auf "S" der Wert zu "Son", durch erneutes Drücken zu "Sam" geändert usw. ). Der Wochentag und das mm/DD/YY-Feld verfolgen einander, wenn eines davon geändert wird. Wenn der Benutzer zwischen beliebigen der Optionen, die das Datumsfeld rechts vom Drop-Down-Optionssteuerelement beinhalten, umschaltet, ändert sich der Datumswert nicht.
Der Benutzer kann unter Verwendung der "Zwischen"- Option einen beliebigen Zeitraum festlegen. Durch diese Option werden eine neue Zeile in den Dialogkasten eingefügt, die Steuerelemente nach unten verschoben und der Dialogkasten nach Bedarf verlängert. Es gibt keine Einschränkung für die Reihenfolge der Daten, so daß jedes Feld das Anfangs- oder Enddatum sein kann. Nach Vorgabe zeigt das zweite Datum (rechts von der "Und"-Überschrift) dasselbe Datum wie die erste Zeile an.
Die "Innerhalb der letzten"-Option erzeugt ein zweistelliges numerisches Nummernfeld-Steuerelement und ein Drop-Down-Einheitssteuerelement rechts. Durch diese Option kann der Benutzer Artikel anfordern, die während der letzten Anzahl (0-99) von Stunden, Tagen, Wochen oder Jahren veröffentlicht wurden. Wenn der Benutzer "Innerhalb der letzten" wählt, sind der Vorgabewert und die Vorgabeeinheit "1 Woche(n)". Die Einheiten Tag, Woche, Monat und Jahr werden zur Berechnung durch Multiplizieren in die jeweilige Stundenanzahl umgewandelt.
- Suche in. Der Benutzer kann die MSN-Hierarchie durchsuchen und eine verteilte Einfach- oder Mehrfachauswahl von Titeln oder Ordnern vornehmen. Eine Verkettung der ausgewählten Elementnamen wird im Drop- Down-Feld bereitgestellt, wobei die Liste wenn nötig mit "..." abgekürzt wird. Das Drop-Down-Feld weist die fünf zuletzt verwendeten "Suche in"-Werte auf, denen die "Mehr..."-Option folgt, die einen MSN-Browser startet. Die Funktion des "Suche in"-Felds besteht darin, den Umfang der Suche auf einen einzigen Titel oder einen Satz von Titeln zu beschränken. Durch Suchen in einem Ausgangsordner von Titeln werden alle eingeschlossenen Titel durchsucht (wobei ein transitives Schließen angenommen wird).
- Mehr... Der vom Explorer aufbereitete MSN-Inhaltsbaum wird dem Benutzer in einem Durchsuchungsdialog dargeboten, damit der Benutzer einen oder mehrere Titel, in denen zu suchen ist, wählen kann. Es werden aus dem Baum alle anderen Dienste außer MPS-Titeln entfernt, um die Benutzerwahl einzuschränken.
Die hierarchische Steuerung gestattet eine Erweiterung und Verdichtung der Hierarchie und eine Einfachauswahl einzelner Titel oder Titelordner. Beim Schließen des Dialogs erscheint der Name der Auswahl wieder im "Suche in"-Drop-Down-Feld. Es kann ein einzelner Knoten im Baum gewählt werden, wobei die verteilte Mehrfachauswahl nicht verfügbar ist.
- Jetzt suchen. Dieser Befehl führt die tatsächliche Suche der eingegebenen Kriterien in dem im "Suche in"-Feld festgelegten Titel (in den festgelegten Titeln) aus. "Jetzt suchen" ist die Vorgabetaste nach dem Eintritt in den Dialog, so daß der Benutzer, nachdem er einen Suchausdruck eingegeben hat, die Eingabetaste drückt, um die Suche einzuleiten. Die "Jetzt suchen"-Taste wird deaktiviert, und das Vergrößerungsglas-Bildzeichen wird animiert, während die Suche ausgeführt wird.
Während der Suche werden Zwischenergebnisse dargestellt, wenn sie aufgefunden werden, wobei der Elementzählwert in der Statuszeile erhöht wird. Die Ergebnisse werden asynchron an den Client weitergeleitet, so daß sie fliegend eingetragen werden. Durch Anklicken der Unterbrechungstaste wird das Senden weiterer Ergebnisse zum Client unterbrochen, jegliche bereits erzielten Treffer bleiben jedoch im Ergebnisfeld.
Nachdem die Suche abgeschlossen wurde (oder der Benutzer die Unterbrechungstaste gedrückt hat), wird die Unterbrechungstaste gesperrt, wobei die "Jetzt suchen"- Taste wieder freigegeben und zur Vorgabetaste wird. Der Statusbalken zeigt die Anzahl der gefundenen Übereinstimmungen. Falls der Benutzer die Suche unterbrochen hat, zeigt der Statusbalken: "n Element(e) gefunden", wobei n größer als 0 oder gleich 0 ist. Falls die Suche in natürlicher Weise endet, zeigt er: "Abgeschlossen: n Elemente) gefunden".
Falls die Suche normal abgeschlossen ist (nicht unterbrochen wurde), piept das Benutzersystem mit dem standardmäßigen Piepton.
- Unterbrechungstaste. Die Unterbrechungstaste ist nur dann aktiv, wenn die Suche gerade ausgeführt wird. Diese Taste endet die Suche sofort.
- Neue Suche. Damit der Benutzer eine neue Suche einleiten kann, setzt dieser Befehl den Inhalt der "Enthält"-, "In"- und "Veröffentlicht"-Felder auf ihre Vorgabewerte zurück, bei denen der Dialog gestartet wurde. Die anderen Felder werden nicht beeinflußt.
3. "Editieren"-Menü. Einige der Befehle und Beschreibungen des "Editieren"-Menüs sind nachfolgend angegeben:
Alles auswählen -- Wählt alle Elemente in der Ergebnisliste aus,
Auswahl invertieren -- Invertiert den ausgewählten Teil der Ergebnisliste und
Aus der Liste entfernen -- Entfernt ein ausgewähltes Element (ausgewählte Elemente) aus der Ergebnisliste.
4. "Ansicht"-Menü. Einige der Befehle und Beschreibungen des "Ansicht"-Menüs sind nachfolgend angegeben:
Bildzeichen anordnen -- nach Namen, nach Quelle, nach Datum (sortiert das Ergebnis nach gewählter Eigenschaft) Nur nicht geöffnete Elemente -- Beim Anwählen zeigt die Ergebnisliste nur nicht geöffnete Elemente an
5. Ergebnisfeld-Arbeitsgänge -- einige der Aktionen sind nachfolgend angegeben:
- Sortieren. In der Einzelheiten-Ansicht sind die Spaltenkopfteile Tasten, die wie in einem Explorer-Fenster gedrückt werden können. Durch einmaliges Drücken auf einen Spaltenkopfteil wird diese Spalte in aufsteigender Reihenfolge umsortiert. Durch Anklicken einer bereits in aufsteigender Reihenfolge sortierten Spalte wird sie in absteigender Reihenfolge sortiert. Auf diese Weise kann der Benutzer ihre Sortierungsreihenfolge einfach mit gewöhnlichen Mausklicks ändern. Es gibt in der Benutzerschnittstelle keine Rückkopplung außer der sortierten Elemente selbst. Die Spaltenkopfteile sind die folgenden:
kleines Bildzeichen - verkleinerte Version des Kundenbildzeichens des Quelltitels
Titel - Name des Elements (d. h. des Artikels)
Quelle - Name des das Element enthaltenden MPS-Titels
Veröffentlicht - Datum und Tageszeit der Veröffentlichung des Elements.
- Kontextmenüs. Durch Anklicken einer Auswahl mit der rechten Maustaste wird das folgende Kontextmenü aufgerufen. Die Befehle in diesem Menü gelten für die gesamte Auswahl. Die Befehle führen genau die gleiche Operation wie ihre Entsprechungen in den Drop-Down-Menüs aus.
Öffnen - Öffnet das ausgewählte Element in seinem jeweiligen Titel (nur Einfachauswahl).
Shortcut erstellen - Erstellt einen Shortcut für den Titel der ausgewählten Beiträge auf dem Arbeitsplatzrechner.
Drucken - Druckt das ausgewählte Ergebniselement (die ausgewählten Ergebniselemente).
- Öffnen. Dieser Befehl ist nur verfügbar, wenn ein einziges Ergebnis ausgewählt ist, und er startet den Titel, der das ausgewählte Element enthält, und plaziert ihn in den das Element enthaltenden Abschnitt. Die folgende Strategie wird zum Starten des Titels verwendet.
1) Falls sich der Treffer im aktuellen Titel (also dem Titel, der den Suchdialog gestartet hat) befindet, geht der aktuelle Titel zum den Treffer aufweisenden Abschnitt über.
2) Falls der Treffer in einem Titel enthalten ist, der nicht der aktuelle Titel ist, gilt Folgendes:
a) Falls der Titel momentan in einem bestehenden Betrachtungsprogramm geöffnet ist, geht dieses Betrachtungsprogramm zum Treffer über.
b) Falls der Titel nicht geöffnet ist, wird ein neues MPS-Betrachtungsprogramm gestartet, das zum Treffer übergeht.
6. Spezielle Benutzerbenachrichtigungen
Eine spezielle Benachrichtigung erfolgt, falls der Suchdialog keine Übereinstimmungen zurückgab. Während er im Hintergrund bleibt, falls er sich bereits dort befindet, gibt der Suchdialog die folgende Warnmeldung aus, damit der Benutzer weiß, was geschehen ist: "Es konnten nach Ihrer Beschreibung keine Artikel gefunden werden. Sie können versuchen, weitere Artikel zu finden, indem Sie einige der Werte im Such-Fenster löschen und dann die "Jetzt suchen"- Taste erneut drücken.".
Die "Neue Suche"-Taste setzt alle Steuerelemente im Dialog in ihren ursprünglichen Zustand zurück, der vorhanden war, als der Dialog geöffnet wurde. Dies können die Vorgabewerte oder die von der Anwendung, die das Suchfenster geöffnet hat, eingegebenen Werte sein. Um der Absicht des Benutzers sicher zu sein, werden sie gemeldet, bevor ihre Suchdefinitionen gelöscht wird.
Es gibt für jede Abfrage eine maximale Trefferanzahl und eine maximal zulässige Zeit. Diese Maximalwerte werden in einem Registerschlüssel auf der Serverseite festgelegt. Weil diese Anzahl die Leistungsfähigkeit direkt beeinflußt, wird sie so festgelegt, daß sie die maximale erwartete Belastung nicht übersteigt. Der anfängliche Maximalwert liegt bei 500 Treffern. Wenn die Benutzerabfrage einen dieser Grenzwerte übertrifft, wird das Ergebnisfeld mit den ersten gefundenen Treffern (die möglicherweise die relevantesten sind) ausgefüllt, und der Benutzer wird gewarnt, daß einige Ergebnisse fehlen könnten, wobei die Warnmeldung in der Art der folgenden ausgegeben wird: "Es gab zu viele Übereinstimmungen, um sie alle anzuzeigen. Sie können versuchen, die Anzahl der Übereinstimmungen zu verringern, indem Sie im Editierkästchen weitere spezifische Werte hinzufügen und dann die "Jetzt suchen"-Taste erneut drücken.".
7. Speichern von Suchabfragen
Das einmalige Ausführen einer Suche ist sicher eine bequeme Art, den Inhalt und die Dienste, die vom MP-System bereitgestellt werden, zu durchsuchen. Durch Speichern von Suchen und ihrer Ergebnisse auf der Festplatte des Benutzers wird die Leistung der Integration mit dem Arbeitsplatzrechner erhöht. Im Ergebnis können Benutzer Ordner erstellen, die nur den Inhalt aufweisen, an dem Benutzer interessiert sind. Benutzer können diese Abfragen speichern und über die Oberfläche von Windows 95 in Namen wie "Aktuelle Ereignisse in Bosnien" umbenennen.
Wenn ein Benutzer den Befehl "Suche als Datei speichern" anwählt, wird die von ihm definierte Abfrage in einer Datei gespeichert, die auf seinem Arbeitsplatzrechner erstellt wird. Ein einmaliger Benachrichtigungsdialog informiert den Benutzer, wo das Bildzeichen erstellt wurde.
Die gespeicherte Datei hat die Erweiterung BBF und wird nach der folgenden Vorlage benannt: MSN Suche #n < Titelbalkenbeschreibung> . Im gespeicherten Namen ist n die größte ganze Zahl (mindestens Eins), die erforderlich ist, damit der Name eindeutig ist. < Titelbalkenbeschreibung> ist der Text nach dem Doppelpunkt im Titelbalken. In diesem Fall ist der Benutzer praktisch immer in der Lage, einen zulässigen Dateinamen erstellen zu lassen. Das erfolglose Speichern würde dann nur in Fällen auftreten, wenn beispielsweise die Festplatte voll ist. Falls ein Problem beim Speichern der BBF-Datei auftritt, wird die folgende Warnmeldung angezeigt: "Ihre Suche konnte nicht auf dem Arbeitsplatzrechner gespeichert werden. Stellen Sie sicher, daß Ihre Festplatte nicht voll ist und daß nichts Sie daran hindert, eine Datei auf dem Arbeitstisch zu erstellen.".
Wenn die BBF-Datei wieder geöffnet wird, wird der vorherige Zustand des Dialogs (einschließlich der Ergebnisse, falls während der Speicherung die "Ergebnisse speichern"- Option im "Optionen"-Menü angewählt wurde) unter Einschluß der Größe und Position genau wiederhergestellt. Die Abfrage wird nicht automatisch erneut gestartet, weil der Benutzer möglicherweise einfach die alte Ergebnisliste weiterlesen möchte. Durch Drücken der "Jetzt suchen"-Taste wird die Abfrage mit den zu dieser Zeit neuesten Informationen ablaufen gelassen und die Ergebnisliste umgebaut.
Wenn der Benutzer ein Ergebnis anklickt, wird das MPS- Betrachtungsprogramm mit dem das Ergebnis enthaltenden Titel gestartet. Falls der Titel nicht mehr auf das Element zugreifen kann (falls das Element also nicht mehr in der Inhaltsdatenbank vorhanden ist), gibt das Betrachtungsprogramm eine entsprechende Meldung aus.

VIII. SCHLUSSBEMERKUNG

In diesem Abschnitt werden von der vorliegenden Erfindung bereitgestellte Nutzeffekte zusammengefaßt. Durch Trennen des Inhalts und des Entwurfs im MP-System können mit einem Stil versehene Publikationen hoher Qualität über Kommunikationsverbindungen niedriger Geschwindigkeit gesendet oder verteilt werden. Ein Informationswiederauffindungsserver (IR-Server) indexiert und durchsucht Beiträge in Titeln. Das Indexieren erfolgt, wenn ein Titel durch einen Arbeitsplatzrechner eines Verlegers auf dem Netzwerk freigegeben wird. Es werden ein Indexieren von Titeleigenschaften sowie ein Volltextindexieren des Titelinhalts ausgeführt. Der IR-Suchdienst kann vom Titelbetrachtungsprogramm am Kundenarbeitsplatzrechner auf zwei verschiedene Weisen angefordert werden. Erstens wird eine Suche für jedes dynamische Steuerelement in einem Titel angefordert. Sie wird Beiträgen zugeordnet, die auf der Grundlage einer vom Verleger unter Verwendung des Suchobjekteditors definierten Suchabfrage aufgefunden wurden. Zweitens kann eine Suche von einem Kunden eingeleitet werden, der den Suchdialog zum Durchsuchen aller Beiträge in einem Titel verwendet, wobei dies sowohl dynamisch als auch statisch erfolgen kann. Der Suchdialog kann auch zum Umlenken der Suche auf einen anderen einzelnen Titel, auf mehrere Titel oder auf Titelordner verwendet werden.

Claims

1. Computergestütztes Informationswiederauffindungssystem (100), aufweisend:

einen Veröffentlichungsspeicher (120),

dadurch gekennzeichnet, daß der Veröffentlichungsspeicher aufweist:

einen Inhaltsspeicher,

einen Indexierer (272a) zum Indexieren des Inhalts und

eine Sucheinrichtung (272b) zum Erfüllen von Abfragen (692) für die Indizes,

weiter gekennzeichnet durch eine Entwurfseinrichtung (194), die einen Titel mit einem oder mehreren Suchobjekten (368) bereitstellt, wobei jedes Suchobjekt eine Abfrage definiert, und

eine Betrachtungseinrichtung (202), die auf den Titel zugreift und die Suchobjekte den anzuzeigenden Inhalt auffinden läßt.

2. System nach Anspruch 1, wobei die Suchobjektabfragen durch eine Benutzersuchabfrage modifiziert werden.

3. System nach Anspruch 2, wobei die Suchabfrageergebnisse vom Betrachtungseinrichtung aufsteigend empfangen werden.

4. System nach Anspruch 2, wobei die Suchabfrageergebnisse einem Kunden (160) angezeigt werden, wodurch die weitere Navigation erleichtert wird.

5. System nach Anspruch 2, 3 oder 4, wobei der Inhalt Beiträge aufweist und wobei jeder Beitrag Eigenschaften aufweist.

6. System nach Anspruch 5, wobei Beitragseigenschaften angezeigt werden.

7. System nach einem der Ansprüche 1 bis 6, wobei die Betrachtungseinrichtung auf einem Kundencomputer (182) ausgeführt wird.

8. System nach einem der Ansprüche 1 bis 7, das zusätzlich einen Abfrage-Cache-Speicher (1004) aufweist, wobei die Suchobjekte und der aufgefundene Inhalt im Abfrage- Cache-Speicher gespeichert werden.

9. System nach Anspruch 8, wobei die Sucheinrichtung zuerst den Abfrage-Cache-Speicher überprüft, um zu bestimmen, ob zuvor die gleiche Abfrage vorgenommen wurde.

10. System nach einem der Ansprüche 1 bis 9, wobei jedes Suchobjekten Kriterium und mindestens eine Quelle aufweist.

11. System nach Anspruch 10, wobei jede Suchobjektabfrage in Teilabfragen unterteilt ist.

12. System nach Anspruch 11, wobei eine der Teilabfragen die Kriterien und eine ausgewählte Quelle aufweist.

13. System nach Anspruch 11, wobei der Indexierer Datenbankindizes erzeugt, die nach Quellen und dem Veröffentlichungsdatum in Partitionen aufgeteilt sind.

14. System nach Anspruch 13, wobei jede der Teilabfragen für eine Datenbankpartition (782) spezifisch ist.

15. System nach Anspruch 14, das zusätzlich mehrere Arbeitseinrichtung (1026) aufweist, wobei jede Arbeitseinrichtung für eine Datenbankpartition spezifische Teilabfragen empfängt.

16. System nach Anspruch 15, wobei die Teilabfragen den Arbeitseinrichtungen seriell zugewiesen werden.

17. System nach Anspruch 15, wobei die Teilabfragen den Arbeitseinrichtungen parallel zugewiesen werden.

18. System nach Anspruch 13, das zusätzlich mehrere Arbeitseinrichtung (1026) aufweist, wobei jeder Arbeits- Teilprozeß für einen Datenbankserver (276) spezifische Teilabfragen empfängt.

19. Computergestütztes Informationswiederauffindungssystem nach Anspruch 1, wobei der Inhalt mindestens einen Beitrag aufweist.

20. Computerimplementiertes Verfahren zum Suchen eines Titels, welches die folgenden Schritte aufweist:

Speichern des Inhalts in einem Veröffentlichungsspeicher (120),

gekennzeichnet durch die weiteren Schritte des Veröffentlichens eines Titels, dessen Inhalt (112) und Layout (110) getrennt sind, in das Veröffentlichungsspeicher und des Abrufens des eine Benutzerabfrage (692) erfüllenden Inhalts aus dem Veröffentlichungsspeicher.

21. Verfahren nach Anspruch 20, welches zusätzlich den Schritt des Anzeigens von Abfrageergebnissen für den Benutzer (160) aufweist.

22. Verfahren nach Anspruch 21, wobei die Abfrageergebnisse in einem Ergebnisfeld (696) auf einer Sichtanzeige (182) angezeigt werden.

23. Verfahren nach Anspruch 20, 21 oder 22, welches zusätzlich den Schritt des Indizierens des Inhalts aufweist.

24. Verfahren nach Anspruch 23, wobei der Indexierschritt das Bestimmen von Partitionen (782) auf der Grundlage einer Quelle und eines Veröffentlichungsdatums aufweist.

25. Verfahren nach einem der Ansprüche 20 bis 24, wobei die Benutzerabfrage eine Quelle aufweist.

26. Verfahren nach einem der Ansprüche 20 bis 24, wobei die Benutzerabfrage Kriterien aufweist.

27. Verfahren nach einem der Ansprüche 20 bis 26, wobei der Auffindungsschritt das Wählen eines Teils des Inhalts, an dem die Abfrage auszuführen ist, aufweist.

28. Verfahren nach Anspruch 27, wobei der Inhaltsteil durch den Titel, Schlüsselwörter und Text oder mehrere von diesen definiert wird.

29. Verfahren nach Anspruch 20, wobei das Layout die Abfrage aufweist und die Abfrage eine Suchabfrage ist, wobei das Verfahren weiter den Schritt des Anzeigens des aufgefundenen Inhalts aufweist.

30. Verfahren nach Anspruch 29, wobei die Suchabfrage durch eine Benutzersuchabfrage modifiziert wird.

31. Verfahren nach Anspruch 29 oder 30, wobei der Titel mehrere Abschnitte (330, 332) aufweist und wobei jeder Abschnitt mindestens ein Steuerelement (342, 352) aufweist.

32. Verfahren nach Anspruch 29 oder 30, wobei der Titel eine Veröffentlichung aufweist.

33. Verfahren nach Anspruch 29 oder 30, wobei der Titel einen Dienst aufweist.

34. Verfahren nach Anspruch 29 oder 30, wobei der Titel eine Anwendung aufweist.

35. Verfahren nach Anspruch 20 oder 29 bis 34, wobei der Veröffentlichungsspeicher einen Netzwerkserver aufweist.

36. Verfahren nach Anspruch 20 oder 29 bis 34, wobei der Veröffentlichungsspeicher einen Teil des Internets aufweist.

37. Verfahren nach einem der Ansprüche 29 bis 36, wobei der Auffindungsschritt erfolgt, während der Titel angezeigt wird.

38. Verfahren nach Anspruch 20, wobei das Layout die Abfrage aufweist, die Abfrage eine einem Steuerelement (352) zugeordnete Suchabfrage ist und das Steuerelement einen Bereich zur Anzeige von Ergebnissen (370, 694) der Suchabfrage definiert, wobei das Verfahren weiter den Schritt des Anzeigens des aufgefundenen Inhalts im Steuerelement aufweist.

39. Verfahren nach Anspruch 38, wobei der aufgefundene Inhalt mehrere Beiträge (370, 372, 374) aufweist und wobei das Steuerelement die Beiträge verkettet und in den Bereich leitet.

40. Verfahren nach Anspruch 39, wobei die geleiteten Beiträge einem Kunden (160) angezeigt werden.

41. Verfahren nach Anspruch 39, wobei das Titellayout ein anderes Steuerelement (354) aufweist, wobei Beiträge, die nicht in den Steuerbereich passen, in einen vom anderen Steuerelement definierten Bereich geleitet werden.

42. Verfahren nach Anspruch 41, wobei das andere Steuerelement dann, wenn Beiträge nicht in den anderen Steuerbereich passen, so viele Male dupliziert wird, wie erforderlich ist, um die restlichen Beiträge anzuzeigen.

43. Verfahren nach Anspruch 38, wobei der Titel mehrere Abschnitte (330, 332) aufweist.

44. Verfahren nach Anspruch 43, welches zusätzlich den Schritt 708 des Navigierens zu einem gewählten Abschnitt des Titels aufweist.

45. Verfahren nach Anspruch 44, wobei die Suchabfrage dem gewählten Abschnitt zugeordnet wird.

46. Verfahren nach Anspruch 43, welches zusätzlich den Schritt des Navigierens zu einem gewählten Beitrag innerhalb eines Abschnitts des Titels aufweist.

47. Computergestütztes Verfahren zum elektronischen Veröffentlichen, welches durch die folgenden Schritte gekennzeichnet ist:

Erzeugen eines eine Suchabfrage (692) enthaltenden Titels,

Speichern des Titels in einem Veröffentlichungsspeicher (120) und

Anzeigen des Titels, wobei die Suchabfrage Inhalt aus dem Veröffentlichungsspeicher abruft.

48. Verfahren nach Anspruch 47, wobei der abgerufene Inhalt mit dem Titel angezeigt wird.

49. Verfahren nach Anspruch 47 oder 48, welches zusätzlich den Schritt des Speicherns des Inhalts im Veröffentlichungsspeicher aufweist.

50. Verfahren nach Anspruch 49, wobei die Inhaltsspeicherung vor der Titelspeicherung erfolgt.

51. Verfahren nach Anspruch 49, wobei die Titelspeicherung vor der Inhaltsspeicherung erfolgt.

52. Verfahren nach einem der Ansprüche 47 bis 51, wobei die Suchabfrage während des Anzeigeschritts modifiziert wird.

53. Verfahren nach Anspruch 52, wobei die Suchabfrage durch ein oder mehrere mit Tags markierte Felder beschränkt wird.

54. Verfahren nach einem der Ansprüche 47 bis 51, wobei die Suchabfrage Suchkriterien und mindestens eine Quelle aufweist.