DE69030833T2

DE69030833T2 - Datenbasissystem

Info

Publication number: DE69030833T2
Application number: DE69030833T
Authority: DE
Inventors: Alan J Demers; Steven B Putz; Lawrence A Spitz; Mark D Weiser
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 1989-03-03
Filing date: 1990-03-01
Publication date: 1997-12-04
Anticipated expiration: 2010-03-02
Also published as: EP0388050A3; EP0388050A2; DE69030833D1; EP0388050B1; JPH02297229A

Description

Diese Erfindung betrifft Dokument-Datenbanken für verteilte Computersysteme und insbesondere Verfahren und Einrichtungen, um Benutzern von Personalcomputern und professionellen Arbeitsplatzrechnern (allgemein hier als "Arbeitsplatzrechner" bezeichnet) gemeinsam genutzten Zugriff bereitzustellen trotz Unterschiede bei den Hardwareausgestaltungen und den Softwarebetriebsumgebungen ihrer Arbeitsplatzrechner, den Kodierformaten und ihren elektronischen Dokumenten und der Dateiübertragung und den Kommunikationsprotokollen ihrer Netzwerkumgebungen.
Es sind verschiedene Editoren für Text und synthetische Bilder zum Erzeugen und Ausgeben von Dokumenten auf Computern mit unterschiedlichen Hardwareausgestaltungen und unterschiedlichen Softwarebetriebsumgebungen entwickelt worden. Unglücklicherweise verwenden viele dieser Editoren unterschiedliche Dokumentbeschreibungssprachen (DDL) zum Kodieren der Struktur und des Inhalts solcher Dokumente in Formate, die ihnen ermöglichen, von gewissen Computersystemen, aber nicht von anderen, verarbeitet und bildmäßig aufbereitet zu werden. Beispielsweise liegen WYSIWYG ("What You See is What You Get") Texteditoren allgemein Dokumentbeschreibungssprachen zugrunde, die systemspezifische Kodierformate aufweisen.
Als ein Ergebnis dieser verschiedenen Dokumentkodierformate gibt es ein "Dokumentaustauschproblem", das das gemeinsame Verwenden elektronischer Dokumente von Benutzern stört, die verschiedene Computerhardwareausgestaltungen und/oder unterschiedliche Softwarebetriebsumgebungen verwenden. Benutzer können manchmal dieses Problem umgehen, indem sie eine schlichte Textkodierung, wie eine übliche ASCII Kodierung, für die Dokumente verwenden, die sie gemeinsam benutzen wollen, oder indem sie die Dokumente, die ein fremdes Kodierungsformat aufweisen, durch einen Formatumsetzer laufen lassen. Jedoch opfert das schlichte Textkodieren viel an Formatierungsinformationen, die verlangt werden, um einem elektronischen Dokument die Erscheinung zu geben, das von seinem Autor beabsichtigt ist. Formatumwandlungsprogramme sind andererseits nicht nur durch das Betriebssystem des Hostcomputers beschränkt, in dem sie resident sind, sondern verlangen üblicherweise auch, daß der Host wesentliche Rechenbetriebsmittel verfügbar hat, um sie laufen zu lassen. Des weiteren verlangen bekannte Formatumwandler im allgemeinen eine Vorauskenntnis des ursprünglichen und des erwünschten Formats des Dokuments, so daß sie nur eine Teillösung für dieses Problem sind. Bilddatenbanken, wie ein Dateinetz (Filenet), kombinieren einige der Elemente der Dokumenterscheinungen und der Dokumentbeschreibungen. Diese Datenbanken sind zum Speichern und Wiedergewinnen von Bildern ausgelegt, wobei aber die gespeicherten Bilder oder "die Erscheinung" in nur einem vorbestimmten Format wiedergewinnbar sind. Aus diesem Grund benötigen Requester häufig Kundenanzeigeeinrichtungen und/oder umfangreiche Kundensoftware um die Bilder aufzubereiten, die sie von einer solchen Datenbank wiedergewinnen. Diese Datenbanken enthalten typischerweise getrennt abfragbare Informationen über jedes der gespeicherten Bilder, wobei aber diese beschreibenden Informationen herkömmlicherweise auf einige wenige, vorbestimmte Felder begrenzt sind, statt daß sie eine ausbaufähige Bildbeschreibung liefern, die ergänzt werden kann, um sie auf die Anforderungen des Benutzers nach Maß zu schneidern. Des weiteren ist es die übliche Praxis, alle Bildbeschreibungen auf dem gleichen Niveau einer solchen Datenbank zu speichern, so daß eine Beschreibung nicht zu einer anderen zeigen kann.
Erweiterte Fernprozedurrufoperationen (RPC) werden verwendet, diese Erfindung auszuführen. Demgemäß versteht es sich, daß es bekannte erweiterte Fernprozedurrufoperationen gibt, um Rückrufe des Server zu dem Requester zu liefern, wenn eine von dem Requester aufgerufene Prozedur ihren Abschluss erreicht, sowie erweiterte Fernprozedurrufoperationen, die periodische Rückrufe von dem Requester verlangen (das heißt, Abrufen des Server durch den Requester), während die aufgerufene Routine ausgeführt wird. Jedoch geben die Rückrufe des Server dieser bekannter Fernprozedurrufoperationen dem Requester keine Teilergebnisse. Des weiteren berücksichtigen die bekannten Abruftechniken des Requesters keine Änderungen bei dem Status des Server, nachdem die aufgerufene Routine begonnen worden ist.
IEEE Software Bd. 4, Nr. 2, März 1987, S. 4-14 offenbart ein Multimediadateiorganisationssystem, das eine Dokumentwiedergewinnung erlaubt und eine verteilte Architektur aufweist. Das System zerfällt in drei Teile: eine Gruppe von Dokument- Servern, die die Grunddateiorganisation und Anfrageoperationen über Dokumente unterstützen; eine Gruppe von Requestern, die Benutzeroperationen in Anfragen an den Dokument-Server umsetzen; und ein Namen-Server, der zwei Arten Informationen beibehält - die Netzwerkadresse des Dokument-Server und die Verteilung der Dokumentarten.
Die vorliegende Erfindung schafft ein Dateisystem, das schnittstellenmäßig mit Requester-Anwendungen verbunden ist, die auf Computern laufen, das eine Einrichtung zum Speichern elektronischer Dokumente auf Anforderung von irgendeiner der Requester-Anwendungen und eine Einrichtung einschließt, die mit der Speichereinrichtung gekoppelt ist, um auf irgendeines der elektronischen Dokumente, die darin gespeichert sind, bei Anforderung von irgendeiner der Requester-Anwendungen zuzugreifen, dadurch gekennzeichnet, daß die Computer unterschiedliche Hardwareausgestaltungen und unterschiedliche Softwarearbeitungsumgebungen haben, wobei verschiedene der Computer mehrere unterschiedliche Codierformate zum Lesen und Schreiben vollständig formatierter, elektronischer Dokumente verwenden; daß die Speichereinrichtung eine Erscheinungs-Datenbank zum Speichern von elektronischen Dokumenten umfaßt, die mit irgendeinem der Codierformate als Quellendokumente geschrieben sind, und daß das System umfaßt eine Bildaufbereitungseinrichtung, die mit der Datenbank gekoppelt ist und die genannte Zugriffseinrichtung einschließt, wobei die Bildaufbereitungseinrichtung eine Einrichtung zum Umwandeln der Codierformate von wenigstens einigen der Dokumente, die in der Datenbank gespeichert sind, in andere Codierformate für Requester-Anwendungen einschließt, die auf Computern laufen, die die anderen Codierformate verwenden, wodurch Bildaufbereitungen solcher Dokumente bereitgestellt werden, die im wesentlichen die physikalische Erscheinung für den Benutzer der Quellendokumente zur Wiedergewinnung durch die Computer kopieren, die die anderen Codierformate verwenden.
Gemäß der vorliegenden Erfindung wird ein Dateisystem geschaffen, um visuell getreue Bildaufbereitungen von vollständig formatierten, elektronischen Dokumenten unter Computern auszutauschen, die unterschiedliche Hardwareausgestaltungen und unterschiedliche Softwarebetriebsumgebungen zur Darstellung solcher Dokumente durch unterschiedliche Kodierformate aufweisen, und um solche Dokumente zu übertragen, wobei unterschiedliche Dokumentübertragungsprotokolle verwendet werden. Alle Formatumwandlungen und andere Aktivitäten, die beim Übertragen solchen Dokumente zwischen solchen Computern enthalten sind, sind für ihre Benutzer im wesentlichen durchschaubar und verlangen keine Vorauskenntnis auf Seiten der Benutzer in bezug auf die Rechen- und/oder Netzwerkumgebungen von irgendeinem der anderen Benutzer.
Bei Betrachtung eines mehr ins Einzelne gehenden Merkmals dieser Erfindung werden alle Datenbankoperationen mittels eines Fernprozedurrufprotokolls iniziiert und ihr Fortschritt wird durch dieses überprüft, was Requesteranwendungen ermöglicht, um Teilergebnisse von ihnen relativ schnell zu erhalten, ohne warten zu müssen, bis solche Operationen ihre Arbeit abgeschlossen haben. Diese Datenbankoperationen sind als "abgeleitete Vorgänge" durch ein Hauptdatenbank-Server verzweigt, so daß die Funktionalität des Dateisystems ohne weiteres erweitert werden kann, indem ihm weitere Dateisystemoperationsprogramme hinzugefügt werden.
Die Erfindung wird nun in beispielhafter Weise unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen:
Fig. 1 ein funktionales Blockdiagramm ist, das das Speichern von Dokumenten nach Erscheinungen und Beschreibungen gemäß einem Gesichtspunkt dieser Erfindung zeigt, wobei der Dokument- und Beschreibungsdatenfluß mit durchgezogenen Linien gezeigt ist, der Argumentenfluß der Operation durch unterbrochene Linien gezeigt ist, die durch rechte Pfeile beendet sind, und der Ergebnisdatenfluß mit gestrichelten Linien gezeigt ist, die mit linken Pfeilen beendet sind;
Fig. 2 ein Funktionsblockdiagramm ist, das die gleichen Linienarten wie Fig. 1 verwendet, um eine Datenbank nach einer Beschreibung darzustellen, wobei ein anderer Gesichtspunkt dieser Erfindung betrachtet wird;
Fig. 3 ein Funktionsblockdiagramm ist, das wiederum die gleichen Linienarten wie Fig. 1 verwendet, um die Bildaufbereitung der Erscheinung eines Dokuments darzustellen, wobei ein noch anderer Gesichtspunkt dieser Erfindung betrachtet wird;
Fig. 4 ein Blockdiagramm ist, das eine bestimmte Ausführung der vorliegenden Erfindung darstellt;
Fig. 5 ein Flußdiagramm ist, das ein Hauptserverprogramm für die in Fig. 4 gezeigte Ausführung darstellt, wobei der Steuerablauf des Programms mit durchgezogenen Linien gezeigt ist, der Ergebnisdatenfluß mit gestrichelten Linien gezeigt ist und der Auftragstabellenzugriff mit gepunkteten Linien gezeigt ist;
Fig. 6 ein Flußdiagramm ist, das ein typisches Requesteranwendungsprogramm für die in Fig. 4 gezeigte Ausführung darstellt, wobei der Programmsteuerablauf mit durchgezogenen Linien und der Datenfluß mit gestrichelten Linien gezeigt ist;
Fig. 7 ein Flußdiagramm ist, das ein neues NewDocDesc Operationsprogramm zum Hinzufügen neuer Dokumente und/oder Beschreibungen zu den Datenbanken der in Fig. 4 gezeigten Ausführung darstellt, wobei der Programmablauf mit durchgezogenen Linien gezeigt ist, der Ergebnisdatenfluß mit gepunkteten Linien gezeigt ist und der Dokumentdatenfluß mit gestrichelten Linien gezeigt ist;
Fig. 8A ist ein Ablaufdiagramm, das ein Operationsprogramm für eine Beschreibungssuche für die in Fig. 4 gezeigte Ausführungsform darstellt, wobei der Programmablauf mit durchgezogenen Linien gezeigt ist, und der Datenfluß mit gepunkteten und gestrichelten Linien für die Fälle von Einzel- bzw. Mehrsuchmustern gezeigt ist,
Fig. 8B ein Ablaufdiagramm ist, das ein rekursives Suchfilterprogramm darstellt, das durch das in Fig. 8A gezeigte Beschreibungs-Suchprogramm zum Filtern mit zweiter oder höherer Ordnung der Suchergebnisse aufgerufen wird, wobei der Programmablauf mit durchgezogenen Linien gezeigt ist und der Datenfluß zum Filtern mit zweiter Ordnung und höherer Ordnung mit gepunkteten bzw. gestrichelten Linien gezeigt ist;
Fig. 9 ein Flußdiagramm ist, das ein Bildaufbereitungs- Operationsprogramm für die in Fig. 4 gezeigte Ausführung darstellt, wobei der Programmsteuerfluß mit ausgezogenen Linien und der Ergebnis- und Dokumentdatenfluß mit gepunkteten bzw. gestrichelten Linien gezeigt ist;
Fig. 10 ein Benutzerschnittstellenwerkzeug zum Abtasten von Dokumenten, zum Erkennen ihres Textes, zum Eingeben desselben und zum Eingeben ihrer Beschreibung in eine Datenbank gemäß dieser Erfindung darstellt;
Fig. 11 ein Benutzerschnittstellenwerkzeug zum Suchen von Dokumentbeschreibungen und zum Anzeigen und Durchstöbern solcher Beschreibungen und ihrer entsprechenden Erscheinungen gemäß dieser Erfindung darstellt, und
Fig. 12 stellt ein anderes Benutzerschnittstellenwerkzeug zum Suchen, Anzeigen und Durchstöbern der Beschreibungen von Dokumentbeschreibungen und zum Anzeigen und Durchstöbern von Dokumenterscheinungen mit unterschiedlichen Vergrößerungen und Auflösungen dar.
Während die Erfindung mehr im einzelnen hier unten unter besonderer Bezugnahme auf eine dargestellte Ausführungsform beschrieben wird, versteht es sich, daß es nicht die Absicht ist, sie auf diese Ausführungsform zu beschränken.

1. Funktionsüberblick

A. Elektronische Dokumente als Erscheinungen plus Beschreibungen

Gemäß der vorliegenden Erfindung werden elektronische Dokumente in zwei Teile unterteilt; eine "Erscheinung" und eine "Beschreibung", die getrennt gespeichert, bearbeitet und wiedergewonnen werden. Eine Dokumentbeschreibung enthält alle symbolischen Informationen über das Dokument, zu dem sie gehören. Somit sind solche Beschreibungen die primäre Informationsquelle für angegebene Suchvorgänge, wobei übliche Datenbankanfragen verwendet werden (ausschließlich holistischer Musterübereinstimmung bei Erscheinungsinhalten). Eine Dokumenterscheinung enthält andererseits alle psychophysikalisch bedeutenden Informationen, die für die Wahrnehmung des menschlichen Betrachters des Dokuments wesentlich sind, zu dem sie gehören. Weder eine Erscheinung noch eine Beschreibung ist ausreichend, irgendein gegebenes, elektronisches Dokument zu bestimmen, sondern sie werden kombiniert, um es vollständig zu bestimmen. Erscheinungen und Beschreibungen sind miteinander verbunden, weil jede Beschreibung stets die eindeutige Kennung oder den "Griff" der Erscheinung enthält, zu der sie gehört. Jedoch können einige Beschreibungen mehrere Erscheinungen betreffen, wie Seiten eines Dokuments oder Kapitel eines Buches, so daß sie mehrere Griffe enthalten können. Beschreibungen können sich auch auf Beschreibungen (entgegengesetzt zu Erscheinungen) beziehen, in welchem Fall sie die Griffe der Beschreibungen enthalten würden, auf die sie sich beziehen.

B. Speichern und Wiedergewinnen von Dokumenten

Alle Erscheinungen sind festgelegt, aber ihre Darstellungen oder "Bildaufbereitungen" sind veränderbar und können für die persönlichen Bedürfnisse der einzelnen Betrachter maßgeschneidert werden. Somit können Dokumenterscheinungen in das Datenbankystem der vorliegenden Erfindung von irgendeinem Arbeitsplatzrechner eines "Requesters" oder Eingabeservers, wie einem Server von einem Eingabeabtaster, eingegeben werden, ohne ihre Kodierformate zu ndern. Ebenso kann irgendein Anzeigeschirm eines Requestercomputers oder eines elektronischen Druckerservers auf irgendwelche gespeicherten Erscheinungen zugreifen, um diese Erscheinung in einem requesterbestimmten Format bildmäßig aufzubereiten.
Beispielsweise kann, wie es in Fig. 1 gezeigt ist, ein mehr oder weniger herkömmlicher Eingangsabtaster 21 zum Umwandeln eines Papierdokuments 22 in eine entsprechende elektronische Einzelbitdarstellung umgewandelt werden, die gemäß eines nichtverdichteten oder eines verdichteten Datenfeldes eines Intensitätsabtastungsformats kodiert ist. Diese Einzelbitdarstellung wird als eine Erscheinung in einer oder mehreren Erscheinungsdatenbanken 24 gespeichert. Zusätzlich wird sie unter Verwendung üblicher Zeichenerkennungstechniken, wie bei 25, verarbeitet, um eine Beschreibung einschließlich einer ASCII Textkodierung des eindeutigen Namens oder Griffes zu erzeugen, der der gespeicherten Erscheinung zugeordnet ist, wie es vollständiger hier unten beschrieben wird. Wie man sieht, wird eine solche Dokumentbeschreibung typischerweise durch zusätzliche Informationen vergrößert, die ihm entweder automatisch durch die Datenbank und/oder unter der Steuerung des Requesters hinzugefügt werden. Die Beschreibung wiederum wird in einer oder mehreren Beschreibungsdatenbamken 26 gespeichert. Ein ähnliches, jedoch direkteres Verfahren wird zum Eingeben der Erscheinungen und Beschreibungen der elektronischen Dokumente, die in einem Arbeitsplatzrechner 28 eines Requesters erzeugt werden, in die Erscheinungs- und Beschreibungsdatenbanken 24 bzw. 26 eingegeben.
Bezugnehmend auf Fig. 2 sieht man, daß ein Benutzer des Arbeitsplatzrechners 28 eines Requesters problemlos ein Datenbankanfragewerkzeug laufen lassen kann, um eine oder mehrere Beschreibungsdatenbanken 26 nach Übereinstimmungen mit datenbankspezifischen Anfragen zu durchsuchen, wie bei 32. Geeignete Führungstechniken können verwendet werden, wie bei 33, um diese Anfragen zu ausgewählten Beschreibungsdatenbanken 26 zu lenken. Beschreibungen, die zu den Anfragen 32 passen, werden an den Requester 28 zurückgegeben, um dem Benutzer mit einer Liste von Beschreibungen mit Anfrageübereinstimmung zu liefern.
Es wird sich nun der Fig. 3 zugewandt, wo der Benutzer des Arbeitsplatzrechners 28 des Requesters auf eine Erscheinung zugreift, indem ihr Griff einer oder mehreren Erscheinungsdatenbanken 24 geliefert wird und eine Bildaufbereitungsspezifizierung zugeführt wird, die die Einrichtung festlegt, bei der die Erscheinung bildmäßig aufbereitetn werden soll, und das Datenkodierformat, mit dem die Erscheinung der Bildaufbereitungseinrichtung geliefert werden soll. Der Griff für die ausgewählte Erscheinung kann von einer zu einer Suchanfrage passenden Beschreibung erhalten werden, wie es oben beschrieben worden ist, oder es kann ein Griff sein, den der Benutzer gesichert oder erlangt hat, ohne auf eine solche Suche zurückgreifen zu müssen. Typischerweise legt die Bildaufbereitungsspezifizierung die Einrichtung, bei der die Erscheinung bildmäßig aufbereitet werden soll, in Größen ihrer Auflösung, der Breite und Höhe der erwünschten Bildaufbereitung und der Grauwert- und Farbeigenschaften der Aufbereitungseinrichtung fest. Sie kann auch andere Informationen über die Umgebungsbedingungen einschließen, die die Wahrnehmung der Erscheinung mit dem menschlichen Auge beeinflussen kann, wie die Umgebungsbeleuchtungsbedingungen in dem Fall einer Erscheinung, die auf einem Computerbildschirm bildmäßig aufbereitet werden soll. Als allgemeine Regel ruft eine solche Bildaufbereitungsspezifizierung ein Datenkodierformat ab, das mit den Anwendungsprogrammen kompatible ist, die bei dem Arbeitsplatzrechner 28 des Requesters vorhanden sind. Beispielsweise mag ein Macintosh Requester ein Mac Paint Format spezifizieren, ein PC Requester mag ein TIFF Format spezifizieren und ein Viewpoint Requester magein RES Format spezifizieren.
Alle Bildaufbereitungen einer gegebenen Erscheinung werden durch den gleichen Griff identifiziert. Deshalb können der Erscheinungs-Griff und die Bildaufbereitungsspezifizierung, die von dem Benutzer geliefert werden, verwendet werden, um zu bestimmen, ob eine erwünschte Bildaufbereitung einer bestimmten Erscheinung in irgendeiner der Erscheinungs-Datenbanken 24 verfügbar ist oder nicht. Vorteilhafterweise werden alle Bildaufbereitungen, die erzeugt werden, durch die Datenbanken 24, wie bei 41, während irgendeiner vorbestimmten Zeitdauer, wie während 24 Stunden, in einem schnellen Zwischenspeicher gepuffert, so daß häufig verlangte Bildaufbereitungen den Requestern, die sie unmittelbar verlangen, ohne irgendeine dazwischenliegende Formatumwandlung oder anderes Verarbeiten dieser Bildaufbereitungen zur Verfügung gestellt werden können. Wenn jedoch eine benutzerspezifizierte Bildaufbereitung einer Erscheinung nicht zur Verfügung steht, wird das Format oder die Formate, mit denen die ausgewählte Erscheinung in der Erscheinungs-Datenbank 24 vorhanden ist, mit dem durch den Benutzer spezifizierten Bildaufbereitungsformat oder -formaten verglichen, um ein geeignetes Formatumwandlungsprogramm 42 aufzurufen. Typischerweise wird eine als Matrix organisierte Tabelle von Formatumwandlungen 43 verwendet, um das Formatumwandlungsprogramm 42 auszuwählen. In einem Zwischenspeicher gespeicherte und formatumgewandelte Bildaufbereitungen können durch den Requestern, der sie über den Datenbank-Dateiserver 44 verlangt, durch die Verwendung eines requesterspezifischen Dateiübertragungsprotokolls wiedergewonnen werden.

C. Die Bedeutung der gerade rechtzeitigen (just-in-time) und wirksamsten Bildaufbereitung.

Die Verwendung der obenbeschriebenen, abstrakten Bildaufbereitungsspezifizierungen bedeutet, daß eine Bildaufbereitung (das heißt, eine psychophysikalisch äquivalente Darstellung einer gespeicherten Erscheinung) hergestellt werden kann, gerade bevor sie auf einer Ausgabeeinrichtung erscheinen soll, wie dem Anzeigebildschirm des Arbeitsplatzrechners 28 oder einem Drukker 46. Als ein Ergebnis können umgebungsmäßige und benutzerspezifische Variable, die die menschliche Wahrnehmung der Bildaufbereitung beeinflussen, berücksichtigt werden, während sie hergestellt wird, einschließlich Variabler, wie die Lichtbedingungen, unter denen die Bildaufbereitung betrachtet werden soll, des Kontrastes und des Farbtonumfangs der Ausgangseinrichtung, und der Kontrast- und Farbempfindlichkeit des Benutzers. Diese Bildaufbereitungsspezifizierungen und die gerade rechtzeitige Bildaufbereitung, die ausgeführt wird, ermöglichen verschiedenen Requestern, unterschiedliche Bildaufbereitungen derselben Erscheinung zu erhalten. Sie ermöglichen auch irgendeinem gegebenen Requester, unterschiedliche Bildaufbereitungen einer einzigen Erscheinung zu unterschiedlichen Zeiten zu erhalten. Mit anderen Worten können Requester die Bildaufbereitungen kundenspezifisch maßschneidern, um ihre individuellen Anforderungen zu befriedigen.
Demgemäß ist es offensichtlich, daß die requesterzentrierte Bildaufbereitung, die durch diese Erfindung in Betracht gezogen wird, erlaubt, viele verschiedene Transformationen bei einer Erscheinung von dem Zeitpunkt vorzunehmen zu können, zu dem sie in einer oder mehrere Erscheinungs-Datenbanken 24 mit einem bestimmten Format eingegeben worden ist, bis zu dem Zeitpunkt, zu dem sie in diesem oder einem verschiedenen Format durch einen Requester wiedergewonnen wird, um die Erscheinung bildmäßig auf eine Anzeige oder einen Drucker aufzubereiten. Jedoch beziehen sich alle diese Transformationen wegen ihrer Treue zu den visuellen Informationenen aufeinander, die der Autor eines Dokuments zu befördern beabsichtigte, unabhängig von dem Kodierformat, das anfangs verwendet wird, um diese visuellen Informationen oder "Erscheinung" festzulegen alle aufeinander. Jene Bildaufbereitung ist tatsächlich ein Versuch mit "größter Leistung", um eine psychophysikalisch äquivalente Darstellung einer gespeicherten Erscheinung zu erzeugen. Eine psychophysikalisch äquivalente Bildaufbereitung verlangt jedoch nicht keine bitweise Entsprechung zwischen einer gespeicherten Erscheinung und ihrer Bildaufbereitung. Sie verlangt vielmehr nur, daß die Bildaufbereitung eng mit dem Original oder der gespeicherten Erscheinung auf einem menschlichen Wahrnehmungsniveau übereinstimmt. Dies bedeutet, daß beispielsweise Erscheinungen als analoge Bilder auf sagen wir einem Mikrofilm zum Wiedergewinnen durch Abtasten gespeichert werden können. Dies bedeutet auch, daß Sichtwinkeltransformationen auf Bildelementmuster angewendet werden können, die geometrische Formen darstellen, um die Sichtwinkelverzerrungen ihrer Formen auszugleichen. Beispielsweise kann eine solche Transformation verwendet werden, ein nichtquadratisches Bildelementmuster zum Darstellen eines Quadrats zu erzeugen, so daß das Bildelementmuster dem menschlichen Auge als ein Quadrat erscheint, wenn es unter einem schiefen Winkel betrachtet wird.

D. Verwaltung von Anfragen und Bildaufbereitungen

Gemäß einem wichtigen Merkmal dieser Erfindung werden alle Datenbankenoperationen für irgendeinen Requester durch Fernprozedurrufe (RPC) aufgerufen, die zwei verschiedene Teile umfassen; einen Teil (hier nachfolgend als "Locate" Fernprozedurruf bezeichnet), um die erwünschte Datenbankoperation zu initiieren, und einen anderen Teil (unten als ein "LocateMore" Fernprozedurrufe bezeichnet), um dessen Fortschritt zu überprüfen. Beide diese Rufe bewirken, daß der Datenbankserver dem Requester die gleichen Informationen zurückgibt; beispielsweise eine Dateispeicherstelle, wo irgendwelche verfügbaren Ergebnisse von der gerufenen Operation gefunden werden können, eine Angabe über den Fortschritt, der in Richtung zum Abschließen der Operation gemacht worden ist, eine Abschätzung, wann von der Operation erwartet wird, daß sie abgeschlossen ist, und ein "Fortschrittsherzschlag", der sich nur ändert, wenn die gerufene Operation zusätzliche Arbeit ausgeführt hat. Diese Informationen werden durch eine "Ablauf- Server-Abschätzung" geliefert, die aus vier Feldern gebildet ist, die ganzzahlige Werte enthalten, um zu geben (1) die Speicherstelle der Ergebnisdatei (geeigneterweise wird ein Wert -1 in dieses Feld eingebracht, wenn die Dateispeicherstelle unbekannt ist), (2) eine Abschätzung der noch anhängigen Arbeit (typischerweise ein Wert 0, der angibt, daß alle Arbeit gemacht worden ist, und ein Wert -1, der angibt, daß keine Abschätzung vorliegt), (3) die abgeschätzte Zeit in Sekunden bis zur Beendigung (wiederum kann -1 angeben, daß sie unbekannt ist) und (4) die abgeschätzte Zeit in Sekunden, bis mehr Ergebnisse verfügbar sind (wiederum -1, wenn unbekannt).
Die sogenannten Ablauf-Server-Abschätzungen haben drei wichtige Verwendungen. Erstens geben sie dem Requester Zugriff auf Teilergebnisse, was besonders vorteilhaft ist, während eine Bildaufbereitung erzeugt wird, weil dies ein langer Vorgang sein kann. Zweitens liefern sie eine Rückmeldung an den Requester in bezug auf den Fortschritt, der gemacht wird. Des weiteren erleichtern sie ein optimiertes Abfragen durch den Requester nach Serverergebnissen auf der Grundlage eines requestergewählten Optimierungskriterium. Beispielsweise kann ein Requester, der ein minimale Verwicklung mit einer Datenbankoperation wünscht, den Datenbankserver nach Ergebnissen zu der vorausgesagten Beendigungszeit aufrufen. Dann kann, wenn die Operation nicht abgeschlossen worden ist, wenn ein solcher Requester nach Ergebnissen aufruft, der Requester die aktualisierte Beendigungsabschätzung verwenden, die in Reaktion auf diesen Ruf zurückgegeben wird, um eine geeignete Rückrufzeit zu bestimmen. Im Gegensatz kann ein Requester, der enger dem Fortschritt zu folgen wünscht, der bei einer Datenbankoperation gemacht wird, den Server häufiger aufrufen, wobei aber kopierte Ablauf-Server-Abschätzungen diesem Requester zurückgegeben werden, wenn solche Aufrufe so häufig gemacht werden, daß von einem Aufruf zu dem nächsten kein Fortschritt zu berichten ist (d. h., wenn der Fortschrittsherzschlag unverändert ist).

E. Dokument-Griffe Document handle)

Wie es vorhergehend angegeben worden ist, wird ein eindeutiger Dokument-Griff für jede neue Erscheinung erzeugt, die in irgendeine der Erscheinungs-Datenbanken 24 eingegeben wird. Ein einziger Griff bezieht sich insgesamt auf alle möglichen Bildaufbereitungen fur irgendeine gegebene Erscheinung. Diese Griffe sind dauerhaft und können von dem Requester während unbegrenzt langer Perioden zur späteren Verwendung beim Wiedergewinnen von Erscheinungen gesichert werden. Des weiteren erzeugen verteilte Dateisysteme unabhängig global eindeutige Dokumenten-Griffe für die verschiedenen Erscheinungen, die in sie eingegeben werden, ohne eine zentrale Registratur oder Datenbank für die Griffe zu verwenden.
Jeder Dokumenten-Griff hat zwei Kodierungen; eine binäre Kodierung, die beispielsweise aus einer Folge von zweiunddreißig Bytes von 8 Bit gebildet ist, und eine Textkodierung, die beispielsweise aus zwei hexadezimalen Großbuchstabenziffern gebildet ist, um jedes der binär kodierten Bytes darzustellen (um Platz zu sparen, können irgendwelche Null-Bytes am Ende der binären Kodierung von der Textkodierung fortgelassen werden). Wie es vollständiger hier unten beschrieben wird, werden die binären Kodierungen der Dokumenten-Griffe in einer Schnittstelle für einen Fernprozedurruf für den Datenbankserver oder die Server verwendet, während ihre Textkodierungen verwendet werden, sich auf die Dokumenterscheinungen in ihren entsprechenden Beschreibungen (Dokumentbeschreibungen können nur Text zur Benutzungserleichterung durch den Requester und die Serversoftware enthalten) zu bezeichnen.
Die Dokumenten-Griffe liefern einen hierarchischen Kennzeichnungsraum. Hierfür sind sie in eine veränderbare Anzahl von Feldern unterteilt, und die Interpretation von jedem dieser Felder kann von dem Zusammenhang abhängen, der durch das unmittelbar vorhergehende Feld festgelegt worden ist. Die Requester verwenden diese Griffe als einfache Kennungen, so daß sie deren Inhalte nicht interpretieren müssen. Die Datenbankserver jedoch interpretieren die Griffinhalte, um kodierte Informationen über die in Beziehung stehende Erscheinung zu gewinnen, wie ihre Speicherstelle. Insbesondere hält ein Server für ein einfaches System, das eine einzige Erscheinungs-Datenbank aufweist, typischerweise einfach einen Index aller örtlich bekannter Dokumenten-Griffe aufrecht, wobei aber ein Server für ein komplizierteres Datenbanksystem einen Dokumenten-Griff verwenden könnte, um zu bestimmen, ob die entsprechende Erscheinung in einer von mehreren örtlichen Datenbanken gespeichert ist, oder ob ein anderer Server angesprochen werden muß, um die Erscheinung zu erhalten.
Ein geeignetes, internes Format für einen Hauptdokumenten- Griff ist wie folgt (die binären Feldlängen in Bits sind angegeben, wenn sie nicht veränderlich sind):
< Dokumenten-Griff 256> = < Griff-Typ 8> < Feld> ...< Feld>
wo :
< Feld> = < Feldtyp 16> < Feld-Bytes> ;
< Feldtyp 16> = < Eindeutigkeitsregel 11> < Feldlänge 5>
< Feldlänge> ist die Anzahl von Bytes in < Feld-Bytes> , und < Griff-Typ> = 1
Wie man erkennt kann mehr als ein Griff-Typ für kompliziertere Systeme benötigt werden, so in dem Fall, daß < Griff Typ> nicht gleich 1 ist. Geeigneterweise wird ein < Feldtyp> , der nur Nullen enthält, reserviert, um anzugeben, daß es in einem gegebenen Griff keine weiteren Felder gibt.
Ein typischer Satz von Eindeutigkeitsregeln für diese Dokumenten-Griffe ist unten zusammen mit ihren binären Feldformaten aufgelistet, aber es versteht sich, daß zusätzliche Feldtypen verlangt würden, um zu ermöglichen, daß die Dokumenten-Griffe Hinweise über Datenbank- und Dokumentspeicherstellen kodieren, die von Servern für kompliziertere Datenbanksysteme benötigt werden mögen:
Regel 1:
< registrierter Host id 16> < Datum- und Uhrzeitzuschreibung 32> [< Zuteiler> ]
Regel 2:
Sun Host id 32> [< Zuteiler> ]
Regel 3:
< IP Host id 32> < Datum- und Uhrzeitzuschreibung 32> [< Zuteiler> ]
Regel 4:
-[< Zuteiler> ]
Regel 5:
< relative id> (eindeutig relativ zu vorhergehendem Feld)
Regel 6:
< Datenversetzung 32> [< relative id> ]
Regel 7:
< Datenversetzung 32> < Datenlänge 32> [< relative id> ]
Regel 8:
-[< Zuteiler> ]
Regel 9:
< Griff Untertyp 8> [< relative id> ]
Die Griff-Untertypen (Eindeutigkeitsregel 9), die bisher definiert worden sind, sind:
0x01: Dokument ist unveränderlich
0x02: Dokument ist eine Beschreibung
Wie es vorhergehend angegeben worden ist, haben Dokumenten- Griffe auch einer Textkodierung, wobei eine Großbuchstaben- Hexadezimal-Textkodierung eines repräsentativen Beispiels unten angegeben ist zusammen mit einer Erläuterung ihrer Felder:
Griff: 010121030107592222864BE25C
wo:
01 bedeutet Grifftyp 1;
0121 bedeutet Eindeutigkeitsregel oder Feldtyp 9, Länge 1;
03 bedeutet Griffuntertyp 0x03 (unveränderliche Beschreibung);
0107 bedeutet Eindeutigkeitsregel oder Feldtyp 8, Länge 7;
5922 bedeutet PUP Adresse: 131 # 42 #;
22864BE2 ist eine Datum- und Uhrzeitzuschreibung für Montag, 09. Mai, 1988 17:16:34 gemäß der Konvention von Unix;
5C ist der ganzzahlige Wert eines Zuteilers, für das Zuteilen des Datums und der Uhrzeit eine zusätzliche Auflösung zu liefern; und
(00...00) werden fortgelassen (d. h, 13 Bytes verwendet, 19 unbenutzt).

II Eine detaillierte Ausführungsform

A. Einleitung

Bezugnehmend auf Fig. 4 ist das Datenbanksystem 51 der vorliegenden Erfindung bequemerweise ausgeführt, indem ein Unix Datenbank-Server auf einem Sun Arbeitsplatzrechner (nicht gezeigt) läuft, der eine übliche Sun Schnittstelle für Fernprozedurrufe zum Kommunizieren mit fernen Requesteranwendungsprogrammen 52-54 aufweist. Die Requesteranwendungen 52-54 können verschiedene Formen annehmen, einschließlich von Dokumentspeicherungs- und Wiedergewinnungsanwendungen, Datenbanksuchanwendungen, Eingangsabtaster-Serverprogramme und Druck- Serverprogramme. Die Serverprogramme für das Datenbanksystem 51 sind in rpcgen, C und C-Benutzeroberfläche Programmiersprachen geschrieben, und die Dokumentbeschreibungen und Erscheinungen werden durch die Datenbank gespeichert, wobei eine Hierarchie von Unix-Dateiverzeichnissen verwendet wird.
Wie es gezeigt ist, enthält das Datenbanksystem 51 ein Hauptserverprogramm 55 zum Kommunizieren mit fernen Requesteranwendungen 52-54 über die Sun-Schnittstelle für Fernprocedurerufe (RPC). Dieses Hauptserverprogramm 55 führt nur ein grundlegendes Datenbankprotokoll aus, wobei drei Fernprozeduren verwendet werden: Locate, LocateMore und ReleaseOp. Besondere Datenbankoperationen wie ein NewDocDesc Operationsprogramm 56, ein Bildaufbereitungs-Operationsprogramm 57 und ein Beschreibungs-Suchoperationsprogramm 58 werden durch die einzelnen Programme, die von dem Hauptserverprogramm 55 abgezweigt sind, als getrennte Unix-Verfahren verarbeitet. Diese Operationsprogramme 56-58 teilen ihrerseits ihre Ergebnisse zurück zu dem Serverprogramm 55 über ihre Standardausgänge mit. Demgemäß ist es offensichtlich, daß die Funktionalität des Datenbanksystems 51 ohne weiteres erweitert werden kann, indem ihm weitere Datenbank-Operationsprogramme hinzugefügt werden, wie für anwenderspezifische Such- und Umwandlungsoperationen. Wie es vorhergehend angegeben worden ist, werden Dateien zwischen den Requesteranwendungen 52-54 und den Datenbanken 59 des Datenbanksystems über einen oder mehrere Netzwerk-Dateiserver 44 durch die Verwendung von requesterspezifischen Dateiübertragungsprotokollen hin- und her übertragen. Das Hauptserverprogramm 55 andererseits hat einen direkten Zugriff, wie bei 60, auf die temporären und dauerhaften Dateien in den Erscheinungs- und Beschreibungsdatenbanken 59.

A. Das Hauptserverprogramm

Sich der Fig. 5 zuwendend sieht man, daß das Hauptserverprogramm 55 Fernprozedurrufe von den Requesteranwendungen 52-54 erhält, geeignete Datenbank-Operationsprogramme zum Ausführen von verlangten Datenbankoperationen für die Requester aufruft, den Fortschritt der requesterverlangten Datenbankoperationen verfolgt und die Ergebnisse dieser Operationen den Requestern zurückgibt, die sie verlangen. Geeigneterweise wird das Hauptserverprogramm 55 unter Verwendung von rpcgen- und C-Programmiersprachen ausgeführt.
Wie man sich erinnert, legt das Fernprozedurrufprotokoll, das verwendet wird, diese Erfindung auszuführen, drei Fernprozeduren fest: Locate, LocateMore, ReleaseOp. Die Locate- und Locatemore-Prozedur ermöglicht den Requestern, Teilergebnisse schnell von den Datenbankoperationen zu erhalten, die sie verlangen. Insbesondere stellen diese Prozeduren häufig Teilergebnisse zur Verfügung, während die verlangte Datenbankoperation ausgeführt wird, statt von dem Requester zu verlangen, auf Ergebnisse zu warten, bis die Operation abgeschlossen worden ist. Hierfür wird ein "id" (Kennung) oder Griff für die Operation dem Requester mit jedem Ergebnis einer verlangten Datenbankoperation zurückgegeben, und dieser Griff wird bei dem nächsten Ruf des Requesters nach der gleichen Operation verwendet, um zusätzliche Ergebnisse und aktualisierte Statusinformationen zu erhalten, die den Fortschritt der verlangten Operation betreffen. Jeder dieser Operations-Griffe belegt einfach eine Position in dem Ergebnisstrom, der zu dem Requester zurückgegeben wird, so daß irgendeiner von ihnen wiederverwendet werden kann, selbst nachdem später erzeugte Ergebnisse zurückgegeben worden sind. Beispielsweise kann ein Operations-Griff wiederverwendet werden, um eine erneute Übertragung von Ergebnissen zu verlangen. Auch kann ein solcher Griff wiederverwendet werden, um die Ergebnisse unterschiedlich zu filtern, indem ein unterschiedlicher "Ergebnistyp" spezifiziert wird, wie es vollständiger hier unten beschrieben ist.
Das Hauptserverprogramm 55 verwendet die folgenden Unix-Umfeldvariablen, um die Datenbankspeicherstellen und andere Werte festzulegen (typische Vorgabewerte für ein Datenbanksystem, das als "System 33" bekannt ist, das ein Sun NFS Dateiübertragungsprotokoll mit dem Namen "N" auf einem Server mit dem Namen "ansel.parc.xerox.com" in dem Arpa Host Namenraum abarbeitet, sind in Klammern angegeben):
S33SERVER - Protokoll- und Servername (Nansel)
S33DBDIR - Datenbankverzeichnis (/ansel04/System33)
S33BINDIR - Programmverzeichnis (/ansel04/System33/bin/3,5)
S33DEBUG - ganzzahliges Kodieren von Testmerkern (0x5F)
S33GROUP - ID der Unix-Gruppe, die erlaubten Zugriff zu beschränkten Operationen (33) hat
S33CTIME - Sekunden bis Kundenzeitende (600)
S33STIME - Sekunden für Zeitablauf (300) des anhängigen Operationsprogramms
Die Datenbank-Operationsprogramme 56-58 (Fig. 4) haben ebenfalls Zugriff zu diesen Umgebungsvariablen.

1. Die Locate-Prozedur

Die Locate-Prozedur nimmt die folgenden Argumente von dem Requester, der sie aufruft: eine Requestererkennungsstring, Operationsprogrammargumente, die einen Operationsprogrammnamen und eine Liste von Stringargumenten einschließen, einen Dokumenten-Griff von 32 Byte, eine Liste von Dateiprotokoll- und Servernamen, eine Liste von Formatnamen, eine ganzzahlige Zeitgrenze, eine ganzzahlige Ergebnispuffergröße und ein ganzzahliger Ergebnistyp. Bei der dargestellten Ausführungsform werden die Argumente an die Datenbank-Operationsprogramme 56- 58 (Fig. 4) durch den "argv" Mechanismus von Unix gegeben.
Typischerweise enthält der Requestererkennungsstring ("Locate-Args.userName") den registrierten Namen der Person, die auf das Datenbanksystem 51 zugreift. Der erste String in den Programmargumenten ("LocateArgs.locateSpec") ist der Name des Operationsprogramms, der die Datenbankoperation bestimmt, die ausgeführt werden soll. Die Interpretationen der verbleibenden Strings in den Programmargumenten und der anderen Prozedurargumente hängen von der benannten Datenbankoperation ab, so daß einige dieser Argumente leer oder null sein können, wenn die benannte Operation sie nicht benötigt. Wie es in Fig. 5 gezeigt ist, bewirkt die Locate Prozedur, daß das Hauptserverprogramm 55 das Programmverzeichnis, wie bei 61, nach einer ausführbaren Unix Datei überprüft, die der benannten Datenbankoperation entspricht. Wenn eine solche Datei gefunden wird, verzweigt das Hauptserverprogramm 55, wie bei 62, das benannte Operationsprogramm 63 als ein "abgeleitetes Verfahren" und gibt ihm die verbleibenden Argumente des Operationsprogramms.
Die anderen Prozedurargumente kurz betrachtend die ein Requester festlegen kann, wenn die Locate Prozedur aufgerufen werden soll, versteht es sich, daß das Dokument-Griffargument ("LocateArgs.docld") für Wiedergewinnungsoperationen verwendet wird, um ein bestimmtes Dokument (das heißt, eine Beschreibung oder Erscheinung) zu identifizieren, die in der Datenbank gespeichert ist. Dieses Argument kann auch für Speicheroperationen verwendet werden, wenn es erwünscht ist, entweder eine neue Beschreibung oder eine neue Fassung einer bestehenden Erscheinung der Datenbank hinzuzufügen. Das Argumentdatenfeld ("LocateArgs.locFilters.servers") der Server/Protokollnamen ist nicht nur zweckmäßig, die Dateiübertragungsprotokolle und/oder Server zu identifizieren, die der Requester zum Wiedergewinnen von Dokumenten von der Datenbank verwenden kann, sondern ist auch zweckmäßig, um das Protokoll und den Server zu spezifizieren, durch die die Datenbank auf die Dateien des Requesters für Dokumentspeicheroperationen zugreifen kann. Ähnlich kann das Argument für die Formatnamen ("LocateArgs.locFilters.formats") verwendet werden (a) für Wiedergewinnungsoperationen, um die Dokumentkodierformate festzulegen, die der Requester bereit ist, zu akzeptieren, und (b) für Speicheroperationen, um die Kodierformate der Dateien des Requesters festzulegen. Der Wert des Arguments der Zeitbegrenzung ("LocateArgs.locFilters.timeLimit") wiederum erlaubt dem Requester, festzulegen, (a) wie lange er möchte, daß Ergebnisse von Wiedergewinnungsoperationen bei der Operation des Netzwerk-Dateiservers 44 (Fig. 4) aufrechterhalten werden, und (b) wie lange die Dateien des Requesters für Speicheroperationen gültig sind. Des weiteren ermöglicht das Argument der Ergebnispuffergröße ("LocateArgs.bufferSize") dem Requester, die maximale Anzahl von Ergebnisdatenbytes festzulegen, die er bereit ist, in einem einzigen Antwortpaket (ausschließlich vom Netzwerkpaketoverhead) zu empfangen.
Das Argument für den Ergebnistyp für die Locate Prozedur ("LocateArgs.LocateSpec") legt die Form der Ergebnisse fest, die der Requester verlangt. Verschiedene Möglichkeiten können durch dieses Argument kodiert werden, einschließlich der Rückgabe nur der Anzahl von Übereinstimmungen, die gefunden worden sind, der Rückgabe von Dokumenten-Griffen der Übereinstimmungen, der Rückgabe der Dateispeicherstellen der Übereinstimmungen, der Rückgabe nur einer Zeitabschätzung, ohne die benannte Datenbankoperation auszuführen, der Rückgabe der Speicherstellen und der Dateilängen der Übereinstimmungen, der Rückgabe nur des Dokumenten-Griffes und/oder der Dateispeicherstellen der ersten, gefundenen Übereinstimmung, und zurückgegebene Dateispeicherstellen können Dateien mit von null verschiedenen Versetzungen spezifizieren.
Sich erneut auf Fig. 5 konzentrierend erzeugt, nachdem das Hauptserverprogramm 55 ein "abhängiges Verfahren" abzweigt, um die benannte Datenbankoperation 63 zu beginnen, erzeugt seine Locate Prozedur einen Operationsgriff für die Prozedur und gibt den Operationsgriff in die Auftragstabelle 64 ein, wie es bei 67 angegeben ist. Dann sieht die Locate-Prozedur ihren Operationsgriff in der Auftragstabelle 64 nach, wie bei 68, um zu bestätigen, daß er eingegeben worden ist, wie bei 69. Wenn die Eingabe nicht gefunden werden kann, wird eine Fehlermitteilung dem Requester zurückgegeben. Wenn jedoch der Operationsgriff gefunden worden ist, bewirkt die Locate Prozedur, daß der Datenbankserver eine Ergebnisdatei 66 für die Datenbankoperation 63 an einer identifizierten Speicherstelle herstellt, wie es bei 71 angegeben ist.
Wie man sich erinnert, überträgt die Datenbankoperation 63 ihre Ergebnisse (einschließlich der Ablauf-Server-Abschätzungen des Fortschritts, den sie macht) in die Ergebnisdatei 66 für diese besondere Operation über ihren Standardausgang. Die Locate Prozedur wiederum liest die gegenwärtigen Ablauf-Server- Abschätzungen aus der Ergebnisdatei 66 zusammen mit irgendwelchen anderen Ergebnissen, die verfügbar sind, aus, wie Dokumenten-Griffe und/oder Dateispeicherstellen, wie es bei 72 angegeben ist. Danach erzeugt die Prozedur einen Operations- Griff für die nächste Prozedur, wie bei 73, und gibt dann diesen Griff und die gegenwärtigen Ablauf-Server-Abschätzungen in die Auftragstabelle 64 ein, wie es bei 74 angegeben ist. Schließlich werden, um die Locate Prozedur abzuschließen, die Ergebnisse an den Requester zurückgegeben.
Die Ergebnisse werden geeigneterweise dem Requester als ein Ergebnisstrom zurückgegeben, der typischerweise einen Fehlercode umfaßt, der einen "kein Fehler" Wert (z. B., 0) umfaßt, wenn kein Datenbank-Server-Fehler aufgetreten ist, wobei die ganzzahligen Kodierungen für die Aktualisierungswerte der oben aufgezählten Ablauf-Server-Abschätzungen, eine ganzzahlige Kodierung der Anzahl der Ergebnisse (manchmal als "Anzahl der Übereinstimmungen" bezeichnet) zurückgegeben werden, und ein Operations-Griff von 8 Byte für die nächste Prozedur (dieser Griff kennzeichnet auch die Ergebnisse, die in Reaktion auf einen bestimmten Ruf zurückgegeben werden). Zusätzlich können in Abhängigkeit von dem Ergebnistyp, der durch den Requester festgelegt worden ist, die Ergebnisse, die zurückgegeben werden, eine Liste von Dokumenten-Griffen, Server-Dateispeicherstellen und/oder Server-Dateispeicherstellen und Dateilängen entsprechend den Übereinstimmungen einschließen, die zurückgegeben werden. Der Requester interpretiert den Operations-Griff nicht, der ihm zurückgegeben worden ist. Stattdessen gibt er nur den Griff an die LocateMore Prozedur, um weitere Ergebnisse von der Datenbankoperation 63 zu erhalten, oder an die ReleaseOp Prozedur, um die Datenbankoperation 63 zu beenden, was davon abhängt, ob die Ablauf-Server-Abschätzung, die mit dem Griff zurückgegeben wird, angibt, ob die Datenbankoperation 63 beendet ist oder nicht.
2. Die LocateMore Prozedur
Wie man sich erinnert, wird diese Prozedur verwendet, zusätzliche Ergebnisse zu erhalten oder vorhergehend zurückgegebene Ergebnisse zu betrachten, wobei das gleiche oder ein verschiedenes Filter für den Ergebnistyp verwendet wird. Hierfür nimmt sie die folgenden Argumente: einen Operations-Griff ("Locate-MoreArgs.handle"), eine ganzzahlige Ergebnispuffergröße ("LocateMoreArgs.bufferSize"), ein ganzzahliger Ergebnistyp ("LocateMoreArgs.resultType"). Die LocateMore Prozedur verwendet den Operations-Griff, der ihr übergeben worden ist, um die Auftragstabelle 64 zu überprüfen, wie bei 68, um die Ergebnisdatei 66 für die Datenbankoperation 63 zu lokalisieren. Dies ermöglicht der Prozedur, neue Ergebnisse aus der Datentabelle 66 auszulesen, wie bei 72, einen weiteren Operations-Griff zu erzeugen, wie bei 73, die Auftragstabelle 64 zu aktualisieren, wie bei 74, und die Ergebnisse an den Requester im wesentlichen in der gleichen Weise wie vorhergehend in bezug auf die Locate Prozedur beschrieben, zurückzugeben.

3. Die ReleaseOp Prozedur

Diese Prozedur wird zum Beenden einer Datenbankoperation und zum Ungültigmachen ihrer zugeordneten Operations-Griffe aufgerufen, wodurch dem Datenbanksystem 51 ermöglicht wird, das Speicherbetriebsmittel freizugeben, das es der Ergebnisdatei 66 für diese besondere Operation zugeordnet hat. Sie kann aufgerufen werden, bevor oder nachdem eine Datenbankoperation abgeschlossen worden ist, so daß sie zum Abbrechen einer Operation nach Wahl des Requesters verwendet werden kann.
ReleaseOp nimmt einen Operations-Griff für eine beabsichtigte Datenbankoperation (das heißt, die Datenbankoperation, die beendet werden soll) als ein Argument, wodurch ihr ermöglicht wird, die Ergebnisdatei 65 für diese Operation zu lokalisieren, indem sie in der Auftragstabelle 64 nachsieht, wie es bei 75 und 76 angegeben ist. Wenn die gegenwärtige Ablauf-Server- Abschätzung für die beabsichtigte Datenbankoperation angibt, daß die Operation bei 77 noch abläuft, bricht die ReleaseOp Prozedur das "abgeleitete Verfahren" für diese Operation ab, wie bei 78. Des weiteren entfernt unabhängig davon, ob die beabsichtigte Datenbankoperation abgeschlossen worden ist oder nicht, die ReleaseOp Prozedur ihrer Ergebnisdatei 66, wie bei 79, und entfernt die Eingaben für die beabsichtigte Operation von der Auftragstabelle (macht deren Operations-Griffe ungültig), wie bei 80.

B. Ein typisches Requester-Anwendungsprogramm

Auf Fig. 6 bezugnehmend erinnert man sich, daß die Requesteranwendungen 52-54 (Fig. 4) die Argumente für die Fernprozedurrufe, wie bei 81, für jede Datenbankoperation liefern, wie die Operation 63 (Fig. 5), die für sie ausgeführt werden soll. Somit wird, um eine Datenbankoperation zu beginnen, die Locate Prozedur (Fig. 5) bei 82 aufgerufen, um die durch den Requester festgelegten Fernprozedurrufargumente, einschließlich des Namens (z. B., "NewDocDesc", "Beschreibungssuche", "Bildaufbereitung", usw.) der erwünschten Datenbankoperation an das Hauptserverprogramm 55 (Fig. 5) weiterzugeben. Wenn kein Fehler des Fernprozedurrufs auftritt, nimmt das Hauptserverprogramm 55 das Argument des Operationsnamens, um zu bestimmen, ob ein ausführbares Programm zum Ausführen der benannten Datenbankoperation durch das Programmverzeichnis des Datenbankservers aufgelistet ist oder nicht. Wenn eine Verzeichnisauflistung des spezifizierten Operationsprogramms gefunden wird, wird die benannte Datenbankoperation aufgerufen, wie es hier oben beschrieben worden ist. Wenn andererseits keine Auflistung gefunden wird, oder wenn die Ergebnisse, die von der Locate Prozedur zurückgegeben werden, einen Fehlercode enthalten, der angibt, daß ein Serverfehler aufgetreten ist, wie es bei 83 bestimmt wird, gibt das Programm des Requesters eine Fehlermitteilung bei 84 aus und endet.
Wenn gültige Ergebnisse durch die Locate Prozedur zurückgegeben werden, gibt das Programm des Requesters die Anzahl von Übereinstimmungen aus, die bei 85 zurückgegeben worden sind, und bereitet vor, die Liste der zurückgegebenen Ergebnisse zu verarbeiten, wie es bei 86 angegeben ist. Diese Liste, die leer ist, wenn der Requester als Ergebnistyp "nur Anzahl der Übereinstimmungen" festgelegt hat, wird bei 87 überprüft, um zu bestimmen, ob alle aufgelisteten Ergebnisse verarbeitet worden sind. Wenn nicht, wird die "id" oder Griff für das nächste Ergebnis auf der Liste bei 88 gewonnen, und dieses Ergebnis wird dann bei 89 überpüft, um zu bestimmen, ob es eine Dateispeicherstelle für das Dokument, das durch den gewonnenen Griff identifiziert worden ist, einschließt oder nicht. Wenn es so ist, wie es bei 91 angegeben ist, kann der Requester die Dateispeicherstelle zum Zugreifen auf das gegenwärtige Dokument in dem Datenbanksystem 59 über den spezifizierten Dateiserver 44 (Fig. 4) verwenden, obgleich sogar die Datenbankoperation unvollständig sein kann und das gegenwärtige Dokument nur eine Teildarstellung des endgültigen Arbeitsprodukts der Datenbankoperation sein kann. Nachdem das Programm des Requesters bei 87 bestätigt, daß alle die Ergebnisse, die von der Locate Prozedur zurückgegeben worden sind, verarbeitet worden sind, prüft es die Ablauf-Server-Abschätzung der anhängigen Arbeit, wie bei 92, und macht dann entweder einen ReleaseOp Fernprotokollruf (RPC) 96 oder einen LocateMore Fernprotokollruf (RPC) 97, in Abhängigkeit davon, ob die verlangte Datenbankoperation abgeschlossen worden ist oder nicht.
Insbesondere ruht, wenn die Datenbankoperation weitere Arbeit ausführen muss, das Programm des Requesters, wie bei 101, bevor ein LocateMore Fernprotokollruf RPC 97 gemacht wird, wodurch der Datenbankoperation einige zusätzliche Zeit gegeben wird, um weitere Ergebnisse zu erzeugen. Die Dauer der Pause 101 wird durch die Ablauf-Server-Abschätzung bestimmt, die in Reaktion auf den früheren Ruf zurückgegeben worden ist, wenn sie eine Abschätzung der Zeit enthält, bis weitere Ergebnisse verfügbar sind, wie es bei 102 bestimmt wird. Sonst wird eine vorbestimmte Pausenzeit 103 verwendet. Nach dem Pausieren während der geeigneten Dauer gewinnt das Programm des Requesters den Operations-Griff für den nächsten Aufruf aus den Ergebnissen, die in Reaktion auf den früheren Aufruf zurückgegeben worden sind, wie es bei 104 angegeben ist. Diese Griff wird dann zu der LocateMore Prozedur (Fig. 5) als ein Argument der LocateMore Fernprotokollruf RPC 97 übergeben.
Der Requester mag mehrere LocateMore RPC 97 machen müssen, um alle Ergebnisse einer verlangten Datenbankoperation zu erhalten. Somit versteht sich, daß die Teilergebnisse, die dem Requester durch jede LocateMore Prozedur zurückgegeben werden, durch das Programm des Requesters verarbeitet werden, wie es oben unter Bezugnahme auf das Verarbeiten der Teilergebnisse beschrieben worden ist, die von der Locate Prozedur zurückgegeben worden sind. Dies bedeutet, daß der Requester aus den LocateMore Ergebnissen die gleichen Arten an Informationen gewinnen kann, wie er aus den Locate Ergebnissen gewinnt. Im Normalfall endet das Programm des Requesters nachdem zuerst bei 92 bestimmt wird, daß die verlangte Datenbankoperation ihre Arbeit abgeschlossen hat, und dann ein ReleaseOp RPC 96 gemacht wird, um die Ergebnisdatei 66 für diese besondere Operation zu entfernen und die in Beziehung stehenden Eingänge von der Auftragstabelle 64 (siehe Fig. 5) zu entfernen.

C. Typische Datenbankoperationsprogramme

Wie es in Fig. 5 gezeigt ist, sind alle Datenbankoperationsprogramme 63 als abhängige Verfahren des Hauptserverprogramms 55 abgezweigt. Infolgedessen erleichtert dies, weitere Datenbankoperationsprogramme dem Datenbankserver hinzuzufügen, wie Programme, die anwenderspezifisch sind, um Datenbankoperation auszuführen, die ausgelegt sind, besondere Anforderungen von gewissen Requesteranwendungen und/oder Benutzern zu erfüllen. Tatsächlich eine nahezu grenzenlose Vielfalt von Datenbankoperationsprogrammen möglich, so daß nur einige wenige grundsätzliche Datenbankoperationsprogramme beschrieben werden, um einige repräsentative Beispiele zu liefern.
Argumente für die verschiedenen Datenbankoperationen werden bequemerweise dem Hauptserverprogramm 55 durch die Requesteranwendungen 52-54 (Fig. 5) übergeben. Die LocateMore und ReleaseOp Prozeduren haben relativ wenig Argumente, so daß die Organisation ihrer Argumente relativ problemlos ist. Jedoch verwendet die Locate Prozedur eine größere Anzahl Argumente, so daß es hilfreich sein kann, kurz eine geeignete Organisation von ihnen anzugeben. Wie man versteht enthält eines der Anfangsargumente für eine Locate Prozedur vorteilhafterweise den Programmnamen für die Datenbankoperation, die der Requester auszuführen wünscht. Es ist dann von den Programmargumenten gefolgt (das heißt, den Argumenten, die das Serverprogramm 55 zu dem benannten Datenbankoperationsprogramm weitergibt) und ihnen wiederum folgen zusätzliche Prozedurargumente, die weitere Requesteranforderungen festlegen, wie den Griff eines Datenbankdokuments, das bildmäßig für den Requester aufbereitet werden soll, annehmbare Server- und Dateiübertragungsprotokolle zum Übertragen von Dokumenten zu dem oder von dem Requester (dieses String kann leer sein, wenn irgendein verfügbarer Server und Dateiübertragungsprotokoll annehmbar sind), Dokumentkodierformate, die von dem Requester verwendet werden oder für ihn annehmbar sind (für Dokumente, die jeweils gespeichert oder bildmäßig aufbereitet werden sollen) und Ergebnistypen, die von dem Requester erlangt werden.

1. Hinzufügen von Dokumenten und Beschreibungen zu der Datenbank.

Es wird sich nun der Fig. 7 zugewandt, in der es ein NewDoc-Desc Programm 63A gibt, um Requestern zu ermöglichen, neue Dokumente und/oder neue Beschreibungen ihrer Erscheinungs- bzw. Beschreibungsdatenbank hinzuzufügen. Hierzu kopiert, wenn ein Requester den Dienst dieses Programmes verlangt, NewDocDesc, wie bei 131, die requesterspezifizierten Dokument- und/oder Beschreibungsdateien 132 in einer temporären Datenbankdatei 133. Der Server wiederum erzeugt einen eindeutigen Griff bei 134 für die temporäre Datei, und das NewDocDesc Programm 63a zeichnet dann den Griff zusammen mit irgendwelchen anderen von dem Server erzeugten Beschreibungsfeldern in der temporären Datei 133 auf. Das vermischt die von dem Server erzeugten Beschreibungsfelder mit den von dem Requester zugeführten Beschreibungsfeldern, wie es bei 136 angegeben ist. Danach werden die neuen Dokument- und/oder Beschreibungsdateien bei 137 von der temporären Datei 133 zu dauerhafteren Datenbankdateispeicherstellen 59 übertragen. Bei der dargestellten Ausführungsform ist ein "abhängiges Verfahren" von dem NewDocDesc Hauptverfahren bei 141 abgezweigt, um den Datenbankbeschreibungsindex 142 mit den Inhalten der neuen Beschreibung, wie bei 143, zu aktualisieren, und das "abhängige Verfahren" wird dann beendet. Zusätzlich zeichnet, während der Beschreibungsindex 142 aktualisiert wird, das "Hauptverfahren" die Identifikationsgriffe und Dateispeicherstellen des neu hinzugefügten Dokuments und/oder Beschreibung in der Operationsergebnisdatei 66 auf, wie es bei 145 angegeben ist, und endet dann.
Wenn ein neues Dokument zu der Datenbank hinzugefügt werden soll, ist der erste String in den Programmargumenten für das NewDocDesc Verfahren typischerweise der Dateiname, unter dem eine Kopie des Dokuments von dem Requester verfügbar ist, und der nächste String ist leer. Des weiteren werden geeigneterweise, wenn ein Dokument und eine Beschreibung der Datenbank hinzugefügt werden sollen, jene zwei Strings von entweder einem anderen leeren String oder von einem Namen einer Beschreibungsdatei gefolgt, der in die neue Beschreibung eingeschlossen werden soll. Irgendwelche benutzerspezifizierten Suchbereiche für eine bestehende Beschreibung in der Datenbank können in dem nächsten String enthalten sein, und dieser String kann von einem leeren String gefolgt werden, um anzugeben, daß alle restlichen Programmargumente Paare von requesterspezifizierten Zusatznamen und -werten sind, die in die bestehende Beschreibung eingefügt werden sollen. Um ein noch anderes Beispiel zu liefern, geben, wenn eine neue Beschreibung zu einem bereits in der Datenbank residenten Dokument hinzugefügt werden soll, die Programmargumente zusätzlich den Griff des bestehenden oder residenten Dokuments an, sind aber sonst im allgemeinen die gleichen, als wenn ein neues Dokument hinzugefügt wird.
Während die NewDocDesc Datenbankoperation ausgeführt wird, verifiziert der Datenbankserver entweder (durch nicht gezeigte Mittel) einen Dokumenten-Griff, der durch den Requester geliefert worden ist (das heißt, zum Hinzufügen einer neuen Beschreibung zu einem bestehenden Dokument) oder erzeugt ein neues Datenbankdokument von einer durch den Requester bezeichneten Datei. Des weiteren gibt, wennimmer ein neues Dokument der Datenbank hinzugefügt wird, der Server einen eindeutigen Griff und/oder eine Dateispeicherstelle für dieses Dokument an das Hauptserverprogramm 55 (Fig. 5), wobei der Ergebnistyp durch den Requester festgelegt wird, der bestimmt, ob der Griff und/oder die Speicherstelle an den Requester zurückgegeben werden sollen.
Wennimmer eine neue Dokumentbeschreibung der Datenbank hinzugefügt wird, schließt der Server die folgenden Felder der neuen Beschreibung ab: DescID, ThisDescID, DescCreateDate, DescCreator, DocID, DocFormat (nur zu einer Beschreibung für ein neues Dokument hinzugefügt). Zusätzlich hängt, während eine neue Beschreibung der Datenbank hinzugefügt wird, der Server an sie die Felder von irgendwelchen Attributen in den Programmargumenten an, sowie die Felder von irgendeiner von dem Requester benannten Beschreibungsdatei. Vorteilhafterweise werden eine veränderliche und eine unveränderliche Fassung jeder Beschreibung in der Datenbank gespeichert, so daß, nachdem eine solche Beschreibung erzeugt worden ist, der Server den Dokumenten-Griff und/oder die Dateispeicherstelle für die veränderliche (z. B., DescID) und die unveränderliche Version (z. B., ThisDescID) zurückgibt.

2. Datenbanksuchvorgänge

Wie es in den Figuren 8A und 8B gezeigt ist, gibt es auch eine Beschreibungssuchoperation, um ein oder mehrere requesterspezifizierte Felder der Datenbankbeschreibungen, die sich in einem requesterspezifizierten Suchbereich (z. B., einer benannten Datenbank) befinden, nach Übereinstimmungen mit einem oder mehreren requesterspezifizierten Requestersuchmuster zu durchsuchen. "Mustertyp"-Argumente werden typischerweise verwendet, um dem Requester zu ermöglichen, Suchanforderungen zu formulieren, die verschiedene Grade von Musterübereinstimmung festlegen. Beispielsweise kann ein "gleich" Suchtypargument verwendet werden, um anzugeben, daß die exakte Übereinstimmung, verlangt wird, ein "Vorsilben"-Argument" verwendet werden, um Übereinstimmungen zu identifizieren, denen ein bestimmtes Suchmuster vorausgeht, und ein "Wildcard" Argument kann verwendet werden, um anzugeben, daß jegliches zu irgendwelchen Wildcard-Zeichen ("Stern") in dem Suchmuster paßt.
Das Anfangsprogrammargument für diese Operation ist typischerweise der Suchbereich, und die restlichen Programmargumente sind typischerweise Dreiergruppen, die den Mustertyp, den Feldnamen und das Suchmuster für einen nach dem anderen der "Suchfilter" festlegen, die in die Suchanforderung eingebaut worden sind. Wie mann erkennt, können die obenbeschriebenen Ergebnistypargumente mit besonderem Vorteil verwendet werden, während eine Datenbanksuche ausgeführt wird, weil sie den Ergebnissen, die zurückgegeben werden, ermöglichen, nach den besonderen Bedürfnissen des Requesters maßgeschneidert zu sein.
Betrachtet man Fig. 8A mehr im einzelnen, sieht man, daß das Beschreibungssuchprogramm 150 seine Argumente 151 überprüft, um zu bestimmen, ob der Requester mehr als ein Suchmuster in seiner Suchabfrage angegeben hat oder nicht. Wenn nur ein einziges Suchmuster angegeben worden ist, werden die requesterspezifizierten Felder des Beschreibungsindex 142 (Fig. 7) der Datenbank nach Übereinstimmungen bei 152 durchsucht, und die Identifizierungsgriffe und die Dateispeicherstellen der passenden Beschreibungen werden bei 153 zum Aufzeichnen in der Ergebnisdatei 66 (Fig. 5) ausgegeben. Wenn jedoch die Suchabfrage mehr als ein Suchmuster angibt (d.h, wenn ein Filtern mit zweiter oder höherer Ordnung der Ergebnisse verlangt wird), wird ein "abgeleitetes Verfahren" von dem Hauptprogramm bei 155 abgezweigt, um ein Suchfilterprogramm 161 aufzurufen (siehe Fig. 8B). Das Haupt-Beschreibungssuchprogramm 150 führt dann den Suchvorgang 152 nach Beschreibungen durch, die zu dem ersten Suchmuster passen (d.h., Filtern der ersten Ordnung), beendet aber nach Ausgeben der Griffe und der Dateispeicher stellen der passenden Beschreibungen, die es, wie bei 153 angegeben, zum zusätzlichen Filtern durch das Suchfilterprogramm 161 aufdeckt.
Um das Filtern höherer Ordnung der Suchergebnisse auszuführen, filtert, wie es in Fig. 8B gezeigt ist, das Suchfilterprogramm 161 die Teilergebnisse, die es von dem Beschreibungssuchprogramm 150 erhält, gemäß einem nach dem anderen der Suchfilter höherer Ordnung der Suchabfrage. Hierfür prüft, wenn bei 162 bestimmt wird, daß die Suchabfrage nur ein zusätzliches Suchmuster enthält (d.h., ein Suchmuster, das nicht vorhergehend zu den Ergebnissen paßte), das Suchfilterprogramm bei 163, um zu bestimmen, ob es irgendwelche Teilergebnisse gibt, die gegenüber diesem vorhergehend nichtpassenden Muster geprüft werden sollen. Wenn es keine Teilergebnisse gibt, endet das Programm. Wenn jedoch eine oder mehrere Beschreibungen das Filtern niedriger Ordnung (z.B., das Filtern erster Ordnung) erfüllt haben, werden der Griff und die Dateispeicherstelle dieser Beschreibungen einer nach dem/der anderen bei 165 eingegeben, so daß die entsprechenden Beschreibungen bei 166 geprüft werden können, um zu bestimmen, ob sie das Filter der nächsthöheren Ordnung erfüllen oder nicht. Die Griffe und die Dateispeicherstellen der Beschreibungen, die zu dem Filter höherer Ordnung passen, werden bei 167 ausgegeben, entweder zum Aufzeichnen in der Ergebnisdatei 66 oder zum weiteren Filtern durch das Suchfilterprogramm 161, wie es unten beschrieben wird, was davon abhängt, ob die Suchabfrage irgendein weiteres Filtern der Suchergebnisse verlangt oder nicht.
Mehrere Rekursionen des Suchfilterprogramms 161 können verlangt werden, um einen Suchvorgang zu seinem Abschluß zu bringen. Insbesondere durchsucht, wenn bei 162 bestimmt wird, daß die Suchabfrage das Filtern der Ergebnisse des Beschreibungssuchprogramms 150 gemäß mehr als einem Suchmuster höherer Ordnung verlangt, das Suchfilterprogramm 161 die mit erster Ordnung gefilterten Ergebnisse, wie es oben beschrieben worden ist, nach Beschreibungen, die das Suchfilter nächsthöherer Ordnung (z.B. zweiter Ordnung) erfüllen. Jedoch sind in dieser Situation die Ergebnisse, die das Suchfilterprogramm bei 167 ausgibt, weiterhin nur teilweise gefiltert, so daß das Programm ein "abgeleitetes Verfahren" bei 168 abgezweigt, um sich selbst rekursiv aufzurufen, wie es bei 169 angegeben ist. Diese Rekursion des Suchfilterprogramms verwendet die Griffe und Dateispeicherstellen einen nach dem anderen, die bei 167 durch das Haupt-Suchfilterprogramm 161 ausgegeben werden, um der Reihe nach auf ihre entsprechenden Beschreibungen zuzugreifen, um zu bestimmen, ob diese Beschreibungen das Suchfilter nächsthöherer Ordnung erfüllen oder nicht. Infolgedessen werden die Griffe und Dateispeicherstellen der Beschreibungen, die gefunden werden, dieses Filtern höherer Ordnung zu erfüllen, entweder als vollständig gefilterte Ergebnisse zum Aufzeichnen in der Ergebnisdatei 66 oder als teilweise gefilterte Ergebnisse für noch eine weitere Rekursion des Suchfilterprogramms 161 ausgegeben. Wie man erkennt, werden Suchergebnisse in der Ergebnisdatei 66 nur aufgezeichnet, nachdem bestätigt worden ist, daß die entsprechenden Beschreibungen treu auf die Suchabfrage antworten, wobei aber einige vollständig gefilterte Ergebnisse zur Rückgabe an den Requester verfügbar sein können, während andere teilweise gefilterte Ergebnisse noch überprüft werden.

3. Wiedergewinnen von Dokumenterscheinungen

Als nächstes auf Fig. 9 Bezug nehmend verwendet eine Bildaufbereitungsoperation 170 einen Dokumentengriff, um ein entsprechendes Dokument in der Datenbank zu lokalisieren, und wandelt, wenn es notwendig und möglich ist, das Dokument in eine requestenverlangte Darstellung oder "Bildaufbereitung" um. Ein Anfangsargument benennt das Operationsprogramm ("Bildaufbereitung"); die nächste Gruppe der String enthält wahlweise Programmargumente für die Bildaufbereitungsoperation (und kann leer sein, wenn der Requester wünscht, ein Standard-Bildaufbereitungsverfahren zu verwenden, wie es gezeigt ist). Typische Optionen für den Ergebnistyp für diese Operation schließen die Rückgabe der Dateidatenstelle(n) des bildaufbereiteten Dokuments, die Rückgabe einer Abschätzung der Zeit, die zum Ausführen einer spezifizierten Umwandlung verlangt wird, führt aber keine Umwandlung aus, und die Rückgabe der Dateilänge(n) mit der Dateispeicherstelle(n).
Wie es dargestellt ist, prüft, wenn das Operationsprogramm 170 für die Bildaufbereitung aufgerufen wird, es zuerst bei 171, um zu bestimmen, ob das erste Argument, das seinem Programmnamen folgt, ein spezialisiertes oder benutzerspezifiziertes Bildaufbereitungsprogramm 172 angibt. Wenn kein spezialisiertes Bildaufbereitungsprogramm 172 angegeben ist, ruft die Bildaufbereitungsoperation ein Standardverfahren auf, währenddessen es den Dokumentgriff verwendet, der von dem Requester bereitgestellt wird, um, wie bei 173, die datenbankmäßig gespeicherte(n) Bildaufbereitung oder Bildaufbereitungen des entsprechenden Dokuments zu lokalisieren (man erinnert sich, daß die Datenbank mehrere Bildaufbereitungen eines Dokuments unter demselben Griff enthalten kann, weil alle Bildaufbereitungen vorteilhafterweise während einer vorbestimmten Zeitdauer, wie vierundzwanzig Stunden, in einem Cache zwischengespeichert werden). Das Verfahren vergleicht dann, wie bei 174, die Formate der Bildaufbereitungen, die es lokalisiert hat, gegenüber dem/den Bildaufbereitungsformat(en), das von dem Requester angegeben ist. Wenn eine gespeicherte Bildaufbereitung, die ein annehmbares Format aufweist, gefunden ist, werden ihr Dateiname und ihre Speicherstelle bei 175 zum Aufzeichnen in der Verfahrenergebnisdatei 66 ausgegeben, und das Bildaufbereitungsprogramm 170 wird dann beendet. Wenn andererseits keine annehmbar formatierte Bildaufbereitung gefunden wird, überprüft das Bildaufbereitungsprogramm 170 eine Nachschlagtabelle, um zu bestimmen, wie bei 177, ob irgendeine der verfügbaren Bildaufbereitungen in ein von dem Requester verlangtes Format umgewandelt werden kann oder nicht. Wenn nicht, gibt es einen Fehler "Bildaufbereitungs nicht möglich", wie bei 178, an und beendet dann. Natürlich können zusätzliche Umwandlungen dem Bildaufbereitungsprogramm 170 hinzugefügt werden, wie es erwünscht ist, so, wenn eine Umwandlung ausreichend häufig verlangt wird, um ihren Einschluß zu rechtfertigen, kann sie bereitgestellt werden und die Nachschlagtabelle kann aktualisiert werden, um sie einzuschließen.
Um eine Bildaufbereitung eines Dokuments mit umgewandeltem Format für einen Requester herzustellen, bewirkt das dargestellte Standard-Bildaufbereitungsverfahren, daß der Datenbankserver eine temporäre Datei 180 mit einem dem Server zugeordneten Dateinamen für die umgewandelte Bildaufbereitung erzeugt. Der Name und die Speicherstelle dieser temporären Datei werden bei 181 zum Aufzeichnen in der Ergebnisdatei 66 ausgegeben. Dann wiedergewinnt das Standardverfahren das Dokument, das umgewandelt werden soll, von der Erscheinungsdatenbank 24 (Fig. 3) und beginnt, es in das erwünschte Format bei 183 umzuwandeln. Die formatumgewandelte, codierte Darstellung des Dokuments wird in die temporäre Datei 180 geschrieben, während es erzeugt wird, so daß Teilergebnisse der Umwandlung dem Requester zur Verfügung stehen, sogar bevor das Dokument vollständig umgewandelt worden ist. Bei Beendigung der Umwandlung 183 teilt das Bildaufbereitungsverfahren 170 seinen Abschluß bei 184 zum Aufzeichnen in der Ergebnisdatei 66 mit, und zwischenspeichert dann die umgewandelte Bildaufbereitung in dem Cache-Speicherabschnitt 41 der Erscheinungs-Datenbank 24 (Fig. 3), wie es bei 186 angegeben ist.
Individuelle Benutzer oder Benutzergruppen können spezialisierte Bildaufbereitungsprogramme 172 verwenden, um die Bildaufbereitungen, die sie wiedergewinnen, für ihre Anforderungen maßzuschneidern. Bildaufbereitungen können auf einer "gerade rechtzeitig" Grundlage erzeugt werden, so daß eine nahezu grenzenlose Vielfalt von Bildaufbereitungen bereitgestellt werden kann, ohne eine übermäßige Dokumentspeicherkapazität für die Erscheinungs-Datenbank 24 (Fig. 3) zu verlangen. Tatsächlich kann ein Benutzer/Requester die "gerade rechtzeitig" Bildaufbereitungsfähigkeiten des Bildaufbereitungsprogramms 170 nutzen, verschiedene, spezialisierte Bildaufbereitungsprogramme 172 zu unterschiedlichen Zeiten zum Erzeugen von Bildaufbereitungen aufrufen, die mehr oder weniger für die verschiedenen Umgebungsbedingungen oder die verschiedenen Ausgabeeinrichtungen optimiert sind, unter denen, oder auf denen der Benutzer sie zu betrachten wünscht.
Beispielsweise kann ein relativ problemfreies, spezialisiertes Bildaufbereitungsprogramm 172 zum Maßschneidern einer Einzelbit-Bildaufbereitung eines Dokuments bereitgestellt werden. Diese Bildaufbereitungsoption würde typischerweise aufgerufen, indem ihr Name (z.B. "Rasterschrumpfung") als die erste String der Programmargumente angegeben wird. Es würde neun andere ganzzahlige Argumente (als getrennte, dezimale ASCII Stringen codiert) verlangen, um den optimalen, minimalen und maximalen Bildelementinhalt einer requesterspezifizierten Einzelbit- Bildaufbereitung entlang seiner x, y und z-Abmessungen festzulegen. Die Rasterschrumpf-Bildaufbereitungsoption könnte diese Argumente in der folgenden Reihenfolge interpretieren: Weite, Höhe, Tiefe, minimale Weite, minimale Höhe, minimale Tiefe, maximale Weite, maximale Höhe und maximale Tiefe. In diesem Fall könnte von dem Bildaufbereitungsoperationsprogramm 170 verlangt werden, eine Einzelbit-Bildaufbereitung herzustellen, die einen xyz Begrenzungskasten aufweist, der zwischen (64x64x1) und (200x200x1) Bildelemente enthält, wobei eine bevorzugte Größe als (150x150x1) Bildelemente angegeben wird, indem ihm die folgenden Argumente übertragen werden: Bildaufbereitung, Rasterschrumpfung, 150, 150, 1, 64, 64, 1, 200, 200, 1.

D. Benutzerschnittstellenbeispiele

Verschiedene Benutzerschnittstellen können verwendet werden, um die vorliegende Erfindung auszunutzen. Einige von ihnen können für bestimmte Verwendungen des Datenbanksystems spezialisiert werden, während andere verallgemeinerter sein können. Einige wenige Schnittstellen auf Fenstergrundlage werden hier unten beschrieben, wobei es sich aber versteht, daß diese Beispiele nur einige wenige der Schnittstellenmöglichkeiten darstellen.
Fig. 10 stellt eine Benutzerschnittstelle 201 dar, die in der Sun Unix "Sunwerkzeug" Umgebung arbeitet, um einem Benutzer eines Sun Arbeitsplatzrechners zu ermöglichen: (a) die Optionen für einen verbundenen Eingangsabtaster und die Ansicht der Einzelbit-Darstellung eines eingabeabgetasteten Bildes in einem Fenster 202 einzustellen, (b) die Optionen für ein residentes Zeichenerkennungsverfahren und die Ansicht des erkannten Textes in einem zweiten Fenster 203 einzustellen und (c) die Optionen zum Eingeben eines neuen Dokuments und/oder einer neuen Beschreibung in die Datenbank der vorliegenden Erfindung und die Ansicht der von dem Server erzeugten und dem requesterspezifizierten Felder solch einer Beschreibung in einem dritten Fenster 204 einzustellen.
Fig. 11 wiederum zeigt eine andere Benutzerschnittstelle 211, der die Sun Unix "Sunwerkzeug" Umgebung zugrundeliegt, um Benutzern eines Sun Arbeitsplatzrechners zu ermöglichen (a) Suchabfragen in das Datenbanksystem dieser Erfindung einzugeben und die Suchergebnisse in dem oberen Teil 212 eines geteilten Fensters 213 anzuzeigen, (b) die zu der Abfrage passenden Beschreibungen in dem unteren Teil 214 des Fensters 213 zu durchstöbern und (c) die entsprechenden Dokumenterscheinungen in einem anderen Fenster 215 anzuzeigen.
Fig. 12 ist Fig. 11 gleich mit der Ausnahme, daß die Benutzerschnittstelle 221 in einer Smalltalk-80 Umgebung arbeitet und das zusätzliches Merkmal aufweist, dem Benutzer eine Möglichkeit zu geben, auflösungsverringerte/größenverringerte Darstellungen von Erscheinungen, wie bei 222 als Seitenübersicht anzusehen, wie, um zu bestimmen, ob sie ausreichend interessant sind, sie mit voller Auflösung und Größe anzuzeigen (d.h., bildmäßig aufzubereiten).

Schlußfolgerung

In Anbetracht des Vorstehenden versteht es sich, daß die vorliegende Erfindung Computerbenutzern ermöglicht, elektronische Dokumente auf dem menschlichen Wahrnehmungsniveau (d.h., Erscheinungsniveau) auszutauschen und gemeinsam zu benutzen, selbst wenn die Benutzer in Computerumgebungen resident sind, die unterschiedliche Dokumentcodierformate verwenden. Alle notwendigen Formatumwandlungen werden für die Anwendungen des Benutzerrequesters ausgeführt, ohne deren örtliche Rechenbetriebsmittel zu belasten und ohne eine Vorkenntnis auf der Seite der Requesteranwendungen in bezug auf die Codierformate der Dokumente zu verlangen, die die Benutzer bildmäßig aufbereiten möchten. Des weiteren sind die Bildaufbereitungen, die bereitgestellt werden, im allgemeinen zu der ursprünglichen Erscheinung der Dokumente treu, die bildmäßig aufbereitet werden, wodurch im wesentlichen der psychophysikalisch wichtige Informationsinhalt der Originale bewahrt wird.
Man erkennt auch, daß das Fernprozedurrufprotokoll, das bereitgestellt worden ist, die vorliegende Erfindung auszuführen, Requester ermöglicht, Teilergebnisse der Fernprozeduren, die sie schnell aufrufen, zu erhalten, ohne zu verlangen, daß der Requester den Abschluß solcher Verfahren abwartet. Die Abarbeitungs-Server-Abschätzungen, die den Requestern mit den Ergebnissen ihrer Fernprozedurrufe zurückgegeben werden, ermöglichen den Requestern, ihre Teilnahme mit den Fernprozeduren, die sie aufrufen, auf der Grundlage der Teilnahmeebene zu optimieren, die am besten ihre individuellen Anforderungen erfüllt.

Claims

1. Ein Datenbanksystem, das schnittstellenmäßig mit Requester-Anwendungen verbunden ist, die auf Computern (28) laufen, das eine Einrichtung (24) zum Speichern elektronischer Dokumente auf Anforderung von irgendeiner der Requester-Anwendungen und eine Einrichtung einschließt, die mit der Speichereinrichtung gekoppelt ist, um auf irgendeines der elektronischen Dokumente, die darin gespeichert sind, bei Anforderung von irgendeiner der Requester-Anwendungen zuzugreifen,

dadurch gekennzeichnet, daß die Computer (28) unterschiedliche Hardwareausgestaltungen und unterschiedliche Softwarearbeitungsumgebungen haben, wobei verschiedene der Computer mehrere unterschiedliche Codierformate zum Lesen und Schreiben vollständig formatierter, elektronischer Dokumente verwenden;

daß die Speichereinrichtung eine Erscheinungs-Datenbank (24) zum Speichern von elektronischen Dokumenten umfaßt, die mit irgendeinem der Codierformate als Quellendokumente geschrieben sind, und daß das System umfaßt

eine Bildaufbereitungseinrichtung, die mit der Datenbank gekoppelt ist und die genannte Zugriffseinrichtung einschließt, wobei die Bildaufbereitungseinrichtung eine Einrichtung (42) zum Umwandeln der Codierformate von wenigstens einigen der Dokumente, die in der Datenbank gespeichert sind, in andere Codierformate für Requester- Anwendungen einschließt, die auf Computern laufen, die die anderen Codierformate verwenden, wodurch Bildaufbereitungen solcher Dokumente bereitgestellt werden, die im wesentlichen die physikalische Erscheinung für den Benutzer der Quellendokumente zur Wiedergewinnung durch die Computer kopieren, die die anderen Codierformate verwenden.

2. Das Datenbanksystem des Anspruchs 1, einschließend:

eine Einrichtung (67) zum Zuordnen eines eindeutigen Identifikationsgriffes und einer Dateispeicherstelle zu jedem der elektronischen Dokumente, wenn es in die Datenbank eingegeben wird,

eine Einrichtung zum Erzeugen von Textbeschreibungen für die Dokumente, wenn sie in die Datenbank eingegeben werden und nachdem sie eingegeben worden sind, wobei die Beschreibungen textorientierte Codierungen der Griffe und der Dateispeicherstellen der Dokumente einschließen, auf die sie sich beziehen, und

eine Beschreibungs-Datenbank (26) zum Speichern der Beschreibungen.

3. Das Datenbanksystem des Anspruches 2, einschließend

eine Einrichtung zum Suchen von Beschreibungen nach Übereinstimmungen mit Suchabfragen, die von den Requester-Anwendungen eingegeben werden, und

eine Einrichtung zum Zurückgeben der Anzahl von Übereinstimmungen, die für jede Suchabfrage gefunden worden sind, an die Requester-Anwendung, die die Abfrage macht, zusammen mit einem Beschreibungs-Datenbanknamen und einer Dateispeicherstelle für jede zu der Abfrage passenden Beschreibung, wenn es von der Requester-Anwendung verlangt worden ist.

4. Das Datenbanksystem nach irgendeinem vorhergehenden Anspruch, worin die Requester-Anwendungen mit dem Datenbanksystem durch eine Fernprozedurrufschnittstelle schnittstellenmäßig verbunden sind, wodurch den Requester-Anwendungen ermöglicht wird, Datenbankoperationen aufzurufen, indem Fernprozedurrufe gemäß einem vorbestimmten Fernprozedurprotokoll gemacht werden.

5. Das Datenbanksystem des Anspruches 4, worin das Fernprozedurprotokoll einen ersten Prozedurruf zum Beginnen einer spezifizierten Datenbankoperation und zum Zurückgeben von wenigstens Teilergebnissen davon an die Requester-Anwendung umfaßt, die den Ruf macht; einen zweiten Prozedurruf, der wiederholt werden kann, wenn es verlangt wird, zur Statusüberprüfung der spezifizierten Operation und zum Zurückgeben zusätzlicher Ergebnisse von ihr, wenn sie verfügbar sind, und einen dritten Prozedurruf zum Beenden der Datenbankoperation und zum Freigeben von Speicherbetriebsmitteln, die ihr zugeordnet sind.

6. Das Datenbanksystem des Anspruches 5, das ein Hauptserverprogramm einschließt, von dem alle Datenbankoperationen als abgeleitete Verfahren in Reaktion auf Argumente abgezweigt werden, die sie angeben.