Inhaltsverzeichnis / Illustra und das PLS Text DataBlade / OpenText Livelink Intranet

Fulcrum SearchServer 3.5

1 Überblick

Die Produkte der Fulcrum SearchServer-Familie werden als Werkzeuge zur effizienten Entwicklung von Applikationen mit Text-Retrieval-Funktionalität vorgestellt. Neben dem SearchServer Administrator, dem SearchBuilder (graphische Entwicklungstools für MS Windows), SearchBuilder for Java und dem SearchServer SDK (C/C++-Entwicklungswerkzeuge auch für nicht-Windows Plattformen) ist der Fulcrum SearchServer, eine Indexierungs- und Retrievalmaschine, das zentrale Element dieser Tools. Prinzipiell wird davon ausgegangen, daß die zu indexierenden und durchsuchenden Dokumente nicht extra vom SearchServer abgespeichert werden. Der Zugriff auf den Dokumententext geschieht dynamisch durch sogenannte Text Reader.
Die hier vorgestellte Version des SearchServers ist eine Weiterentwicklung des Fulcrum SearchServers 2.0, der für das MeDoc-Projekt evaluiert wurde [MTP2].

2 Datenmodell

Der SearchServer verwendet ähnlich relationalen Datenbanken Tabellen, in denen Informationen über Dokumente gespeichert werden (base tables). Neben den vom System verwendeten Tabellenspalten, können auch benutzerdefinierte Spalten (Attribute) mit anderen Informationen über das Dokument angelegt werden. Die Texte selbst werden offensichtlich nicht in den Tabellen gespeichert, sondern verbleiben in ihrem ursprünglichen Format in der jeweiligen Verzeichnisstruktur, relationalen Datenbank usw. (Ob Dokumente evtl. auch physikalisch in Tabellenspalten von Fulcrum geladen werden können, ist unklar da die genauen Spezifikationen für die Datentypen unklar sind.)
In den Handbüchern wird beschrieben, daß drei verschiedene Klassen von Datentypen (text, date und numeric) existieren, die folgende Daten repräsentieren können:

externe Dokumente (external text columns),
Attribute, die vom Nutzer/Programmierer selbst bestimmt werden können,
intern benutzte Attribute (reserved columns - z.B. Statusinformationen über das Dokument).

Zusätzlich können über den Textspalten zones definiert werden. Zonen (zone) unterteilen die Spalten nochmals in "virtuelle" Spalten, die einen Datentyp besitzen, indexierbar sind und in Abfragen verwendet werden können. Zonen werden anhand von Kontrollsequenzen identifiziert, die von Text Readern während des Indexierens oder z.B. von Hand in das Originaldokument eingefügt werden. Eine Zone kann z.B. einen speziellen Teil eines Dokumentes (Kapitelname, Titel, Artikeltext) bezeichnen.
Weiterhin besteht die Möglichkeit eigene Datentypen (domain) zu definieren.
Beispiel für das Erzeugen eines Schemas mit einer Tabelle [F2]:

CREATE SCHEMA SUPPORT

-- Zones

CREATE ZONE DATE_AND_TIME (201,202)

CREATE ZONE OPERATOR (211)

CREATE ZONE CONTACT (212)

CREATE ZONE ENTRY_HEADING (201, 202, 211, 212)

CREATE ZONE DESCRIPTION (32)

-- Domains

CREATE DOMAIN LOG_DMN ( DATE_AND_TIME, OPERATOR, CONTACT, DESCRIPTION, ENTRY_HEADING ) AS APVARCHAR

CREATE DOMAIN PRIORITY_DMN VALUE AS INTEGER

CREATE DOMAIN PHONE_DMN NONE AS VARCHAR (15)

CREATE DOMAIN TLF_DMN AS VARCHAR (260)

CREATE DOMAIN VERSION_DMN LITERAL AS VARCHAR (10)

CREATE TABLE SUPPORT (

--------------------------------------

-- Reserved Columns

--------------------------------------

TEXT_LOG_FILE TLF_DMN 3,

TEXT_LOG LOG_DMN 32,

LAST_MODIFIED DATE 31,

LAST_MODIFIER VARCHAR (20) 97,

DATE_CLOSED DATE 30,

--------------------------------------

-- Application Columns

--------------------------------------

SOURCE VARCHAR (30),

COMPANY VARCHAR (30),

ADDRESS VARCHAR (80),

PHONE_NUMBER VARCHAR (15),

PLATFORM VARCHAR (20),

PRODUCT_VERSION VARCHAR (8),

SUBJECT VARCHAR (80),

COMPANY_ID VARCHAR (10),

)

;

) -- End of column definitions

-- Table Parameters

STOPFILE 'support.stp'

BASEPATH '../supdocs'

-- End of schema;

Neben den Dateien, die die Daten der Base Tables enthalten, existieren noch sog. table support files (Thesaurus-Datei, Stoppwort-Datei, character variant rules file), Index-Dateien und weitere Dateien, die zur Verwaltung notwendig sind.

3 Text Reader

Text Reader stellen die Schnittstelle des SearchServers zu den Dokumenten dar. Sie werden beim Indexieren und Anzeigen für den Zugriff auf die externen Dokumente benutzt, indem sie die in anderen Formaten existierenden Dokumente dynamisch in Fulcrums Ful/Text Document Format Streams (FTDF Streams) konvertieren, die die Indexierungsmaschine lesen kann. Falls es notwendig ist, lassen sich die Text Reader auch kaskadieren. Der wichtigste Text Reader ist der ftmf (Fulcrum Technologies Multi-Format Text Reader), der die meisten Formate unterstützen soll. Mit den Text Reader existieren Schnittstellen für die wichtigsten Dokumentenformate, wie z.B. Textverarbeitungen und Tabellenkalkulationen, sowie auch database text readers für Sybase, Oracle und MS SQL-Server. Bei Bedarf können allerdings auch eigene Text Reader entwickelt werden (mit Hilfe der text reader API). Mit Hilfe von Text Reader können auch Dokumente, die keine Textinformationen (Bitmaps, Vektorgraphiken, ausführbare Dateien, uuencoded) beinhalten, eingelesen und in Fulcrum-Tabellen mit Attributen verknüpft, jedoch nicht durchsucht werden.

Abbildung 5-1: Der SearchServer und Text Reader

Text Reader sollen auch Struktur- und Dokumenteninformationen (z.B. bei PDF: Titel, Thema, Verfasser, Stichwörter) extrahieren/verarbeiten können, um sie in Tabellenspalten zu sammeln oder um Dokumente in Zonen zu unterteilen. Über die genaue Funktionsweise und die Fähigkeiten ist jedoch nichts bekannt.

4 Indexierung

Der SearchServer unterscheidet zwei Updatemodi für die Indexierung:

unmittelbar (immediate) als default,
periodisch (periodic).

Dabei bedeutet unmittelbar, daß die Indexierung erfolgt beim Einfügen oder verändern der Daten. Dabei wird ein differentieller Index erzeugt, d.h. der Index wird aus Performancegründen nur aktualisiert und kann später reorganisiert/optimiert werden. Periodisch bedeutet, daß das Indexieren explizit bestimmt wird und vollständig über die zu indexierenden Tabellen erfolgt. Ob eine Tabelle das unmittelbare Indexieren unterstützt wird bei der Erstellung der Tabelle festgelegt.
Díe möglichen Indexierungsmodi werden von der jeweiligen Klasse des Datentyps bestimmt. Der SearchServer unterscheidet folgende Indexierungsmodi:

NORMAL (alle Terme, die als Wörter identifiziert werden),
VALUE (alle Zahlen),
LITERAL (alle Terme - auch nicht-Wörter),
NONE (Nichts).

Über den Aufbau der Indexfiles wird in den Handbüchern angegeben, daß jedes Auftreten eines suchbaren Terms in den Index-Files aufgezeichnet wird und damit auch Suchen mit phrase und proximity searching sowie relevance ranking möglich wird.
Die Größe des Index wird bei Tabellen mit immediate indexing mit 20 bis 200% des Textumfangs angegeben (Grund: evtl. Fragmentierungen), bei Tabellen mit anderer Indexierung mit 20 bis 40%.

5 Retrieval

Der SearchServer unterstützt das Boolesche Retrieval, hat aber auch zwei weitere interessante Suchstrategien:

"Fuzzy Boolean",
"Intuitive Searching".

Fuzzy Boolean wird als zwischen dem strikten Booleschen Retrieval und Retrieval nach dem vector space model stehend beschrieben. Dabei werden AND und NOT in ihrer Restriktivität abgeschwächt, d.h. die Operatoren werden eher wie OR behandelt, wobei die Relevanz eines Dokumentes bei Nichterfüllung der Bedingungen abgewertet wird.
Intuitive Searching ermöglicht es, "natürlichsprachliche" Anfragen zu stellen und somit Dokumentenvergleiche durchzuführen. Zuerst wird ein sog. "Textvektor" aus der Eingabe erzeugt, um dann später mit diesem die Anfrage an das System zu stellen: "Aus den Termen des Anfragetextes wird eine Menge von Suchtermen generiert. Die Auswahl der Suchterme wird von der Frequenz, mit welcher die Terme im Abfragetext und in den zu durchsuchenden Tabellen vorkommen, beeinflußt, sowie von verschiedenen Gewichtungsfaktoren." [F4]. Ein Beispiel für das Stellen einer "Intuitive-Searching"-Anfrage:

CREATE TEXT_VECTOR VECTOR1 'Why do alphanumeric queries produce extra hits?';

Leider waren weitere Informationen zu der genaueren Funktionsweise nicht erhältlich.
Der Fulcrum SearchServer unterstützt die folgenden verschiedenen Rankingverfahren:

Auftretenshäufigkeit eines Suchbegriffes in einem Dokument,
Anzahl des Auftretens verschiedener Suchbegriffe,
statistisch (seltene terms erhalten eine höhere Gewichtung).

Inhaltsverzeichnis / Illustra und das PLS Text DataBlade / OpenText Livelink Intranet