% Studienarbeit von Ulrike Steffens
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Anbindung des Systems INQUERY an das Programmiersystem Tycoon
% 16.4.96

\chapter{Anbindung des Systems INQUERY an die Programmiersprache Tycoon}
\label{Anbindung}
Die Schnittstelle f"ur Anwendungsprogrammierung des Systems INQUERY ist in 
einer Reihe von C-Dateien implementiert (vgl. Abschnitt \ref{API}), die 
zusammen eine Bibliothek bilden. Diese wird statisch "uber die virtuelle 
Tycoon Maschine (vgl. Abschnitt \ref{tvm}) an das Tycoon System gebunden. 

Ein Teil der in der INQUERY Schnittstelle
enthaltenen Funktionen wurde zun"achst eins zu eins in die 
Programmiersprache TL (vgl. Abschnitt \ref{tl}) "ubernommen.
Nach der Erstellung eines groben Datenmodells
wurden diese Funktionen unter 
Ber"ucksichtigung spezieller Eigenschaften von TL, wie z.B. der Typisierung und
der Fehlerbehandlung, "uberarbeitet.

Die Struktur des Tycoon Systems f"uhrte bei der
Anbindung zu besonderen Anforderungen hinsichtlich der "Ubergabe und Nutzung von C-Funktionen.
 Die strenge Typisierung der Programmiersprache TL wurde genutzt, um den korrekten Ablauf von
INQUERY Operationen
zu gew"ahrleisten. Durch die Persistenz und die Interoperabilit"at des Tycoon 
Systems wurde der Nutzungsbereich des INQUERY Systems erweitert.

 
\section{Angebundene Funktionsgruppen}
\label{functions}
Das Hauptinteresse bei der Anbindung gilt jenen Funktionsgruppen der 
C-Schnittstelle, die die Grundfunktionalit"at
des INQUERY Systems enthalten. Die Gruppen, in denen
\begin{itemize}
\item der Zugang zu INQUERY Datenbanken,
\item das Parsing von Anfragen,
\item die Auswertung von Anfragen und 
\item der Zugang zu Dokumenten und Informationen "uber die Textsammlung
\end{itemize}
implementiert sind, werden im Tycoon System zug"anglich gemacht. Hierdurch 
k"onnen in TL Anfragen an im INQUERY System
enthaltene Testdatenbanken gestellt sowie die entsprechenden Ergebnisse 
verarbeitet werden. In TL wird die Gruppierung nach Funktionalit"at
beibehalten, indem Funktionen verschiedener Gruppen in verschiedenen
Schnittstellen und Modulen (vgl. Abschnitt \ref{modules}) zusammengefa"st 
werden. Hierdurch entsteht eine TL-Bibliothek, die folgende Dateien umfa"st:
\begin{itemize}
\item die Schnittstelle {\em Dbinfo.ti}
(vgl. Anhang \ref{dbinfo}) und das dazugeh"orige Modul {\em dbinfo.tm} f"ur den Zugang zu INQUERY Datenbanken 
\item die Schnittstelle {\em Query.ti} 
(vgl. Anhang \ref{query}) und das dazugeh"orige Modul {\em query.tm} f"ur das Parsing und die Auswertung von Anfragen  
\item die Schnittstelle {\em Docs.ti} 
(vgl. Anhang \ref{docs}) und das dazugeh"orige Modul {\em docs.tm} f"ur den Zugang zu Dokumenten und Informationen "uber die Textsammlung
\end{itemize}

\section{Datenmodell des Systems INQUERY}
\label{omt}
Um einen "Uberblick "uber die verschiedenen Daten des INQUERY Systems zu 
gewinnen, wird unter Benutzung der {\em Object Modelling Technique OMT} 
\cite{rum91} ein Datenmodell erstellt (vgl. Abbildung \ref{omtmod}).

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=9cm \epsfysize=10cm
\epsffile{/usr/users/stud/steffens/Studienarbeit/Latex/Bilder/omt.epsf}
\end{center}
\caption{Das System INQUERY im OMT-Datenmodell}
\label{omtmod}
\end{figure}

Zu einer INQUERY Datenbank geh"ort ein Name und eine Stoppwortliste, die
beim Parsing zur Stoppwortelimitierung (vgl. Kapitel \ref{ir}) genutzt wird. Jede Datenbank
enth"alt ein oder mehrere Dokumente. 

Alle diese
Dokumente besitzen denselben Dokumententyp. Der Dokumententyp ist hierbei
eine Aggregation aus einem oder mehreren Feldtypen, die Namen, wie z.B. 
''text'' oder ''title'', tragen und in der INQUERY Schnittstelle f"ur
Anwendungsprogrammierung (vgl. Abschnitt \ref{API} durch ganzzahlige Bezeichner repr"asentiert sind. 
Ein Dokument eines Dokumententyps besteht aus den 
den Feldtypen entsprechenden Feldern,
in denen sich der Feldinhalt, wie beispielsweise der eigentliche Text oder
Titel des Dokuments, befindet. Die Anzahl der Felder (vgl. Kapitel \ref{ir}) in einem Dokument ergibt sich
genau wie die Anzahl von Feldtypen, die einen Dokumententyp bilden, durch
die Aggregation und ist ein Attribut des jeweiligen Dokuments
bzw. Dokumententyps.

Aus einer Anfrage an das INQUERY System resultiert eine Rangliste, in der sich eine
Zahl von relevant erscheinenden Dokumenten befindet. Jedem Dokument wird dabei ein Erf"ullungsgrad zugeordnet, der die Position
des Dokuments in der Rangliste bestimmt.

Nach der Suche ist es m"oglich, die
Position von zuvor bestimmten Suchtermen in den Feldern der Ergebnisdokumente
auszumachen. Die Position besteht dabei aus zwei ganzen Zahlen, die
die L"ange des Suchterms sowie seinen Anfang in der Zeichenkette des Feldes   angeben.

Dieses Datenmodell stellt eine von vielen m"oglichen Interpretationen
der mit dem INQUERY System vorliegenden Daten dar. Naturgem"a"s erfa"st es
nicht alle Zusammenh"ange des Systems. Es bietet jedoch Unterst"utzung
dabei, die Funktionen und Datentypen der Schnittstelle f"ur 
Anwendungsprogrammierung zu verstehen und in TL eine entsprechende Typisierung
vorzunehmen.

\section{Besondere Anforderungen bei der Anbindung}
\label{anbindanf}
Bei der Anbindung externer Bibliotheken an das Tycoon System m"ussen einige
systemimmanente Besonderheiten beachtet werden. So ist es nicht m"oglich,
Funktionen, die strukturierte Werte als Parameter erhalten oder zur"uckgeben, direkt an das System anzubinden. Die unterschiedlichen Speicherbereiche, auf
die interne und externe Funktionen des Tycoon Systems zugreifen, stellen
ebenfalls ein Problem dar (vgl. Abschnitt \ref{tvm}).

\subsection{Strukturierte Werte als Parameter externer Funktionen}
\label{structs}
Die TVM l"a"st die Anbindung externer Funktionen, die strukturierte Werte als
Parameter besitzen, nicht zu. Daher ist es im Rahmen der Anbindung des
Systems INQUERY an Tycoon notwendig, derartige Parameter explizit als TL-Tupel  aufzubereiten. 

Zur Verdeutlichung werden die Funktion {\em check} und ihr Pendant auf
der INQUERY Seite, {\em inq\_check\_query}, betrachtet. {\em inq\_check\_query}
erh"alt einen Zeiger auf eine Datenbankinformation und eine Zeichenkette,
die eine ungeparste Anfrage repr"asentiert, als Parameter. Ihr Ergebnis ist 
ein Zeiger auf eine Struktur vom Typ {\em query\_info\_t}:

\begin{verbatim}
query_info_t *inq_check_query (dbinfo *db, Char_t *qstring) 

typedef struct
{
  Int_t             error_code;      /* zero for no error */
  Int_t             error_offset;    /* only meaningfull if error_code != 0 */
  Char_t            *parsed_query;   /* final parsed query */
  Int_t             num_terms;       /* total number of terms in query */
  Int_t             num_stops;       /* number of stop words in query */
  Int_t             num_not_found;   /* number of non-indexed words */
  Int_t             num_xformers;    /* number of identified transformers */
} query_info_t;
\end{verbatim}
Die entsprechende TL-Funktion soll folgende Signatur besitzen:

\begin{xple}
check(db :dbinfo.T qstring :String) :Info
\end{xple}
Hierbei ist der Typ {\em Info} folgenderma"sen implementiert:

\begin{xple}
{\bf Let} Info  = {\bf Tuple}
                      errorCode :Int
                      errorOffset :Int
                      parsedQuery :T
                      numTerms :Int
                      numStops :Int
                      numNotFound :Int
                      numXFormers :Int
                 {\bf end}
\end{xple}
das
TL-Konstrukt {\em bind} (vgl. Abschnitt \ref{tlcbib}) wird verwendet, um die Funktion {\em inq\_check\_query} an Tycoon anzubinden. 

\begin{xple}
{\bf let} checkCall = 
{\bf bind}(:\k{Fun}(:word.T :String) :word.T lib "{}inq\_check\_query"{} "{}wsw"{})
\end{xple}
Ein Aufruf von {\em checkCall} liefert dem Tycoon System jedoch nur einen
Zeiger in den von C verwalteten Speicherbereich. Die C-Struktur, auf die
dieser Zeiger weist, kann in TL auf zwei Arten zug"anglich gemacht werden. 

Zum einen bietet das Tycoon System die Schnittstelle {\em WordOp.ti} zur Interpretation von Maschinenw"ortern, wie Bitmustern oder Adressen, an. Diese stellt
Funktionen zur Verf"ugung, mit denen der Inhalt des Speicherbereichs, auf den
ein C-Zeiger zeigt, bitweise interpretiert und in TL-Werte umgesetzt werden
kann. Diese maschinennahe Art des Zugriffs besitzt jedoch einen Nachteil.
Implementationen, die auf bitweisem Zugriff basieren, sind von der zugrundeliegenden Rechnerarchitektur abh"angig, so da"s sie nur eingeschr"ankt portabel sind. 

Aufgrund dieser eingeschr"ankten Portabilit"at wird f"ur die Anbindung des Systems INQUERY ein anderer Weg gew"ahlt.
Die C-Strukturen werden bereits auf C-Seite in ihre Komponenten aufgespalten, einzeln an das Tycoon System "ubergeben und dort zu einem Tupelwert zusammengesetzt.

F"ur das obige Beispiel wird also wie folgt verfahren. Zun"achst wird der
aus dem Aufruf der Funktion {\em checkCall} resultierende Zeiger in einem TL-Wert abgelegt.
\begin{xple}
{\bf let} ptr = checkCall(db "{}all about Information Retrieval"{}) 
\end{xple}
Auf C-Seite werden Funktionen definiert, die den Zugriff auf die einzelnen
Komponenten der Struktur, auf die der Zeiger weist, erlauben.

\begin{verbatim}
Int_t get_error_code(query_info_t *info)
{
 	return info->error_code;
}


Int_t get_error_offset(query_info_t *info)
{
 	return info->error_offset;
}

...
\end{verbatim}
Die beiden Funktionen {\em get\_error\_code} und {\em get\_error\_offset} dienen hier als Beispiel. Die Funktionen, die die weiteren Komponenten einer Struktur vom Typ {\em query\_info\_t} liefern, sind entsprechend aufgebaut. Die
C-Funktionen wurden wiederum an das Tycoon System gebunden.

\begin{xple}
{\bf let} checkCall2 = 
{\bf bind}(:\k{Fun}(:word.T) :Int  lib "{}get\_error\_code"{} "{}wi"{})

{\bf let} checkCall3 = 
{\bf bind}(:\k{Fun}(:word.T) :Int  lib "{}get\_error\_offset"{} "{}wi"{})

...
\end{xple}
Mit Hilfe dieser Bindungen wird die TL-Funktion {\em check} implementiert.
\newpage
\begin{xple}
{\bf let} check(db :dbinfo.T  qstring :String) :Info =
   {\bf begin}
      {\bf let} ptr = checkCall(db qstring)
      {\bf let} result = {\bf tuple}
                            checkCall2(ptr)
                            checkCall3(ptr)
                            ...
                       {\bf end}
      word.free(ptr) (* free C-pointer *) 
      result
   {\bf end}
 \end{xple}
Ein Aufruf von {\em check} liefert somit einen Tupelwert im Tycoon Speicher 
zur"uck, dessen Komponenten den Komponenten der zugrundeliegenden
C-Struktur entsprechen.

\subsection{Persistenz in unterschiedlichen Speicherbereichen}
\label{stores}
Das Tycoon System bietet die M"oglichkeit, Objekte, die in den 
systemeigenen Programmiersprachen, wie z.B. TL, 
definiert worden sind, persistent im Speicher abzulegen. 
Werte, die w"ahrend der Nutzung externer Bibliotheken entstehen, werden 
jedoch nicht im Speicherbereich des Tycoon Systems gespeichert und sind 
daher fl"uchtig.

Bestehen innerhalb von Tycoon Werte, die Zeiger auf den externen 
Speicherbereich enthalten, so werden diese bei einer Stabilisierung des
Systemzustandes ebenso persistent wie alle anderen Tycoon Werte.
Wird das Tycoon System heruntergefahren, so geht der externe Wert, der
durch den persistenten Zeiger adressiert wurde, verloren. Der Zeiger wird
in jeder weiteren Sitzung mit dem
Tycoon System einen Bereich adressieren, der nicht mehr den urspr"unglichen
Wert enth"alt.

Auch bei der Anbindung des INQUERY Systems werden Funktionen implementiert,
die Tycoon Zeiger auf den externen Speicherbereich zum Ergebnis haben.
So ist eine ge"offnete INQUERY Datenbank durch einen Zeiger repr"asentiert.
Hier gilt jedoch die Pr"amisse, da"s nur mit einer INQUERY Datenbank zur
Zeit gearbeitet werden kann. Dadurch mu"s eine Dokumentendatenbank vor dem 
Zugriff ge"offnet und anschlie"send wieder geschlossen werden. Dieses
"Offnen und Schlie"sen ist in jedem Anwendungsprogramm f"ur INQUERY
erforderlich. Hier l"a"st sich auch das Anlegen eines neuen Zeigers vor jedem
"Offnen einer Datenbank, bzw. direkt nach jedem Hochfahren des Tycoon Systems
integrieren. W"unschenswert w"are es jedoch, den Anwendungsprogrammierer
von derartigen Aufgaben der Systemverwaltung zu entlasten.

Das Tycoon System stellt einen Mechanismus bereit, der das Anlegen und L"oschen
externer Werte protokolliert und diese beim n"achsten Systemstart erneut
generiert (vgl. Abschnitt \ref{tvm}). Im Rahmen der vorliegenden 
Arbeit wird diese
M"oglichkeit nicht betrachtet. Die Verwendung des beschriebenen Mechanismus 
kann jedoch der Gegenstand zuk"unftiger praktischer Arbeiten sein, zumal er 
f"ur andere INQUERY Daten, wie 
Dokumente oder Textstellen, an denen Suchterme gefunden wurden, zum 
Einsatz kommen k"onnte.

Ein weiterer Ansatz ist es, Daten wie Dokumente nicht als Zeiger auf den 
externen Speicher abzulegen, sondern die dort enthaltenen Werte direkt als 
TL-Werte zu "ubernehmen. Dieses Vorgehen w"urde dem Datenmodell des
Systems INQUERY (vgl. Abschnitt \ref{omt}) eher gerecht werden und
den intuitiven Umgang mit dem System innerhalb von Tycoon erleichtern.

Ein Dokument beispielsweise ist momentan als Zeiger auf den externen Speicher
definiert.
\begin{xple}
{\bf Let} Doc = word.T (* pointer *)
\end{xple}
Nach dem INQUERY Datenmodell ist auch die folgende Definition
eines Dokumententyps geeignet:
\begin{xple}
{\bf Let} Doc = {\bf Tuple}
                     numberOfFields :Int
                     fields :list.T(Field)
                {\bf end}
\end{xple}
Die Tatsache, da"s ein Dokument durch eine Aggregation von Feldern entsteht, 
ist hier durch eine Liste dieser Felder dargestellt. Zus"atzlich enth"alt
das Dokument eine Angabe dar"uber, wieviele Felder es enth"alt.

Diese Art der Implementation bedeutet jedoch einen zus"atzlichen Aufwand. So m"u"sten
beispielsweise f"ur Dokumente alle Felder im voraus aus dem C-Speicherbereich
des Systems INQUERY in den persistenten Tycoon Speicher geladen werden, obwohl
zu diesem Zeitpunkt nicht klar ist, ob sie ben"otigt werden. Ob
der Verst"andnisvorteil, der durch die modellnahe Definition von Typen
entsteht, diesen Aufwand rechtfertigt, mu"s Gegenstand zuk"unftiger
Betrachtungen bleiben.

			
 

\section{TL-Typisierung in INQUERY}
\label{irtypes}
Die Typisierung der Sprache TL wird bei der Anbindung von INQUERY genutzt,
um zwischen Datentypen, die in C einheitlich repr"asentiert sind, genauer zu 
differenzieren. Dadurch wird der Definitionsbereich von Funktionen so
eingeschr"ankt, da"s eine fehlerhafte Nutzung zur "Ubersetzungszeit entdeckt werden kann. Das
Typsystem unterst"utzt somit statisch den korrekten Ablauf von Programmen.

Bei der Anbindung von INQUERY wurden beispielsweise die Anfragen an
eine Datenbank, die in der Programmierschnittstelle von INQUERY als einfache 
Zeichenketten definiert sind, so typisiert, da"s bei einer Nutzung im Tycoon
System generell zwischen geparsten und ungeparsten Anfragen unterschieden wird:
\begin{xple}
T $<$:String
(* A parsed query *)
\end{xple}
Eine ungeparste Anfrage kann eine beliebige Zeichenkette sein, und auch
der Typ {\em T} einer geparsten Anfrage ist Subtyp vom Typ {\em String}.
Durch die Subtypisierung wird jedoch erreicht, da"s Funktionen, die
einen Wert vom Typ {\em T} als Parameter erwarten, ausschlie"slich Werte 
dieses Typs oder eines Subtyps von {\em T} akzeptieren \cite{mat93}. Die "Ubergabe einer
einfachen Zeichenkette anstelle einer geparsten Anfrage w"urde somit zur
 "Ubersetzungszeit zu einem Typfehler f"uhren. So l"a"st sicherstellen,
da"s z.B. einer Funktion, die eine geparste Anfrage auswerten soll, auch nur
eine solche "ubergeben wird:
\begin{xple}
evalParsed(db :dbinfo.T  parsedQuery :T) :Results 
(* Evaluate the parsed query and return the results in a belieflist. *)
\end{xple}
Eine geparste Anfrage, also ein Wert vom Typ {\em T}, kann nur
durch den Aufruf entsprechender Funktionen generiert werden.
\begin{xple}
getParsed(db :dbinfo.T  queryString :String) :T
(* Process a parsed query string *)
\end{xple}
Durch Typisierung werden somit logische Fehler in der Anwendungsprogrammierung
unterbunden. Von der Implementation der jeweiligen Typen wird dabei
abstrahiert.

\section{M"oglichkeiten der erweiterten Nutzung von INQUERY innerhalb von
Tycoon}
\label{chances}
Das Tycoon System ist eine Systementwicklungsumgebung mit der M"oglichkeit,
nicht nur Deklarationen, sondern auch beliebige konkrete Werte persistent
abzulegen . Sowohl Schnittstellen, die in systeminternen Programmiersprachen
implementiert sind, als auch externe Bibliotheken k"onnen auf orthogonale
Weise genutzt werden und interagieren (vgl. Abschnitt \ref{tl}). Im
 Information Retrieval wird eine Vielzahl an
Informationen verwaltet. Verschiedene Benutzer haben auf ein
Softwaresystem wie INQUERY Zugriff. Der Einsatz von INQUERY innerhalb des
Tycoon Systems bietet hier erweiterte M"oglichkeiten der Anwendungsprogrammierung.

\subsection{Persistenz im Information Retrieval}
\label{irpersistence} 

Die Persistenz des Tycoon Systems ist im Information Retrieval sowohl f"ur Anfragen an das System als auch f"ur zur"uckgelieferte Ergebnisse 
sinnvoll nutzbar. Parameter und Ergebnisse eines Information Retrieval Prozesses
k"onnen zwar auch ohne Anbindung an Tycoon von INQUERY protokolliert werden.
Dieses bleibt jedoch dem Benutzer unter Verwendung des jeweiligen
Dateisystems "uberlassen. Die Verwaltung von Anfrage- und Ergebnisdaten l"a"st
sich in Tycoon so automatisieren, da"s dem Benutzer die zugrundeliegende Systemstruktur verborgen bleibt. 

Unter diesen Voraussetzungen ist es m"oglich, die Funktionalit"at des 
INQUERY Systems zu erweitern. Einmal gestellte Anfragen k"onnten bespielsweise
f"ur verschiedene Benutzer in verschiedenen Tycoon Speicherbereichen abgelegt
werden. Dieses beg"unstigt den Vorgang der Informationsfilterung \cite{bel92},
in dem regelm"a"sig von einem Benutzerprofil abh"angige Anfragen an ein
Informationssystem gestellt werden. 

Weiterhin ist ein Katalog von Standardanfragen an eine Datenbank denkbar,
der zum einen der Auswertung von Systemver"anderungen dient, aber zum
anderen auch Benutzern als Alternative zur Eingabe eigener Anfragen zur 
Verf"ugung gestellt werden kann.

Eine persistente Ablage von Ergebnissen eines Information Retrieval Prozesses
gibt Benutzern die M"oglichkeit, sich eine Art elektronische Bibliothek
mit f"ur sie relevanten Dokumenten anzulegen. Mit Hilfe von TL-Datenstrukturen
l"a"st sich diese zus"atzlich sinnvoll, beispielsweise nach Themengebieten
oder Anfragedaten, ordnen.

\subsection{Interoperabilit"at im Information Retrieval}
\label{inter}
Das System Tycoon vereinigt eine Vielzahl von Bibliotheken (vgl. Abschnitt
\ref{modules}), deren Funktionen, Typen usw. beliebig f"ur neue Implementationen
genutzt werden k"onnen. Die Verbindung eingebundener, externer Bibliotheken
untereinander wird durch die Orthogonalit"at der Sprache TL vereinfacht.

Auch f"ur das INQUERY System lassen sich viele der Tycoon Bibliotheken nutzen.
So werden verschiedene Strukturen zur Verwaltung von Massendaten, wie z.B.
Hashtabellen, B"aume oder Listen, angeboten.
 Die Implementation ergonomischer Benutzerschnittstellen mit Hilfe von in
Tycoon integrierten Fenstersystemen ist ebenso vorstellbar wie die 
Weiterverarbeitung von Dokumenten "uber einen angebundenen Texteditor.
