-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung,
um einen Index für
eine semistrukturierte Datenbank zu erzeugen, die eine Anzahl von
Elementen beinhaltet, wobei jedes Element einen Satz von Daten aufweist,
die in einem semistrukturierten Format gespeichert sind, wobei jeder
Satz von Daten eine Anzahl von zugehörigen Einträgen beinhaltet.
-
Früher gab
es zwei Hauptansätze,
um auf Daten zuzugreifen, die in elektronischem Format gespeichert
sind. Der erste Prozess ist bekannt als Informationsabfrage und
arbeitet mit einem strengen Zeichenfolgesuchansatz. Wenn dementsprechend ein
Benutzer dabei ist, eine Abfrage in Form eines Schlüsselwortes
einzugeben, wobei die Informationsabfragetechnik benutzt wird, wird
die gesamte Datenbank nach einer Zeichenfolge, welche zu dem Schlüsselwort
passt, durchsucht. Offensichtlich leidet ein solches System an dem
Nachteil, dass es leicht relevante Einträge verpassen könnte, sollte
die Form des Wortes in der Datenbank geringfügig von der Form des Schlüsselwortes
abweichen. Dieses Problem kann überwunden
werden, indem eine Abstammungstechnik benutzt wird, in der das Schlüsselwort abgeschnitten
und eine globale Wortendung hinzugefügt wird. Dies hat jedoch wieder
den Nachteil, dass dann zahlreiche irrelevante Datensätze gefunden
werden können,
die ähnliche
Schlüsselworte
beinhalten.
-
Im
zweiten Ansatz, bekannt als Wissensdarstellung, muss die ganze Information
der Datenbank vorcodiert werden, indem eine spezielle Wissensdarstellungssprache
benutzt wird, um eine neue Datenbank zu bilden. Dies erfordert es,
dass ein Benutzer die Daten durchsucht und analysiert und relevante
Informationen in verschie denen Wissensdarstellungsfeldern platziert.
Wenn dies abgeschlossen ist, erlaubt dies Benutzern, auf die Information
zuzugreifen, indem Abfragen in einer Wissensdarstellungssprache
eingegeben werden. Diese benutzt logische und Theorem-Beweise und
ist deshalb für
Benutzer ohne Spezialwissen nicht unmittelbar zugänglich.
Zudem leiden Wissensdarstellungsansätze an dem Nachteil, dass die
Datenbanken anfangs schwierig zu erzeugen sind, und wenn sie erzeugt
sind, noch schwieriger zu ändern
sind.
-
Beide
der oben erwähnten
Techniken sind sowieso ungeeignet für Benutzung mit Daten, die
im semistrukturierten Format gespeichert sind. Eine semistrukturierte
Datenbank ist eine Datenbank, in der einige Daten innerhalb der
Datenbank in spezifischen Feldern gespeichert werden, welche den
Typ der Daten kennzeichnen, wobei der Rest der Daten einfach unter
einem allgemeinen Feld gespeichert wird, wie z.B. ein Freitextfeld.
-
Datenbanken
dieser Form werden im Allgemeinen entweder durch Durchsuchen von
Datensätzen
in Hardcopy, die ein vorbestimmtes Format haben, oder indem man
einen Benutzer Daten manuell eingeben lässt, erzeugt. Jedoch können wegen
der Vielseitigkeit der Freitextfelder die eingegebenen Daten in
Inhalt und Stil variieren. Während
dies die Beschränkungen
auf die Daten, die eingegeben werden können, verringert, wodurch die
Datenbank leichter zu erzeugen ist, bedeutet dies, dass die verschiedenen
Typen von gespeicherten Daten nicht bestimmt werden können durch
Identifizierung der Felder, in denen die Daten gespeichert sind.
Beispiele von Fällen,
wo Daten in solch einem semistrukturierten Format gespeichert werden,
beinhalten das Yellow Pages®-Verzeichnis, Exchange
and Mart, Loot, und The British National Formulary.
-
So
werden zum Beispiel im Yellow Pages®-Verzeichnis
die Titel von verschiedenen Abschnitten gespeichert, und zwar in
einem Datensatz, der als ein Titelfeld vorgesehen ist. Jede individuelle Anzeige
(nachstehend bezeichnet als ein Element) enthält ein Namensfeld und ein Freitextfeld.
Ein Namenseintrag wird im Namensfeld gespeichert, wogegen ein Freitexteintrag,
wie z.B. eine Beschreibung von Produkten oder Dienstleistungen der
Firmen, ein Adresseintrag und ein Telefonnummerneintrag alle im
selben Freitextfeld gespeichert werden.
-
Wenn
dementsprechend eine Informationsabfrage auf das Yellow Pages®-Verzeichnis
angewendet würde,
würden
in einer Schlüsselwortsuche alle
Titel, Firmennamen und der Freitext durchsucht. Da der Datentyp
nicht ausgewiesen ist, kann ein Titel als ein relevantes Ergebnis
gefunden werden, wenn tatsächlich
die Elemente verbunden mit jenem Titel die gesuchten Ergebnisse
sind. Andererseits würde ein
Wissensdarstellungsverfahren zum Durchsuchen der Datenbank erfordern,
dass die Datenbank in eine separate Wissendarstellungsdatenbank übersetzt wird,
die dann unter Verwendung von Wissensdarstellungsverfahren durchsucht
werden könnte.
Die ursprünglichen
Yellow Pages®-Daten
würden
dann redundant sein, obwohl, wenn sie aktualisiert würden, eine
neue Wissensdarstellungsdatenbank erforderlich wäre.
-
Huffman
et al. beschreiben in einer Veröffentlichung
mit dem Titel "Notes
Explorer: entity based retrieval in shared, semistructured information space" in "Proceedings of the
1996 ACM CIKM International conference on information and knowledge management", 12.–16. November
1996, Seiten 99–106,
ein System, das einen Index für
ungleiche Datenbankdatensätze
von semistrukturiertem Format erzeugt. Huffman befasst sich damit,
ein System vorzusehen, das auf Informationen, die in vielen Datenbanken
gespeichert sind, die zu verschiedenen Zeiten durch verschiedene
Nutzer und an verschiedenen Orten erzeugt wurden, zugreifen kann.
-
Die
Datensätze
sind eine heterogene Mischung aus Informationen und Formaten. Huffman versucht,
alle Datenbankdatensätze
zu rationalisieren, indem er die Felder eines jeden Datensatzes analysiert
und den Datensatz gemäß einem
einzigen Indizierungsschema indiziert. Dies umfasst die Identifizierung
von Feldtypen, indem Feldnamen und Feldwerte mit einem domainabhängigen Wörterbuch bestehend
aus Schlüsselwörtern und "typischen Werten" verglichen wird.
-
Im
Allgemeinen sind die Felder sogenannte Kurz-Textfelder, wo ein Feld
eine Einheit beschreibt. Huffman beschreibt auch die Möglichkeit,
dass ein Feld ein semistrukturiertes Dokument ist, wobei Einheiten
wie Ort, Produktname und Fachausdrücke daraus abgefragt werden
könnten.
Die Abfrageverfahren, die aufgeführt
sind, beinhalten Textverarbeitungswerkzeuge und Fachausdruckextraktoren.
-
Frank
Shou-Cheng Tseng et al. beschreiben in einer Veröffentlichung mit dem Titel "Extending the E-R
concepts to capture natural language semantics for database access" veröffentlicht
durch die IEEE in "15th Proceedings for Computer software and
applications conference 1991",
einige Probleme im Zusammenhang mit dem Abfragen von Informationen aus
Datenbanken. Es ist gut bekannt, dass Sprachen, die benutzt werden,
um Datenbanken abzufragen, oft zu komplex für nicht-technische Benutzer sind.
Zwischensprachen, die eine Eingabe in natürlicher Sprache aufnehmen und
diese Eingabe in ein Format übersetzen,
das geeignet ist für
Datenbankabfragen, sind entwickelt worden, aber, wie angegeben bei
Tseng et al., haben diese den Nachteil, dass es extrem schwierig
ist, eine Abbildung zwischen natürlicher
Sprache und Datenbankabfrage zu entwickeln, welche durchgehend funktioniert.
Tseng et al. präsentieren
ein Verfahren, bei dem die natürliche Sprache
geparst und über
ein Einheitsbeziehungsschema in eine relationale Algebra abgebildet
wird. Mit diesem Ansatz werden das Verb und die Semantik einer Abfrage
in eine logische Form abgebildet und in relationale Algebra übersetzt
und zwar entsprechend welcher Datenbank auch immer, die abgefragt
werden muss. Dieses Verfahren ist relativ komplex.
-
Gemäß einem
ersten Aspekt der Erfindung ist eine Vorrichtung vorgesehen, um
auf eine semistrukturierte Datenbank zuzugreifen, in Übereinstimmung
mit einer Eingabeaufforderung für
Informationen, wobei die semistrukturierte Datenbank mehrere Elemente
aufweist, wobei jedes Element ein oder mehrere Felder aufweist,
die mehrere Zeichen enthalten, und wenigstens eines dieser Felder
ein Freitextfeld ist, wobei die Vorrichtung aufweist
einen
Datenspeicher mit mehreren Indexeinträgen, die eine Übereinstimmung
zwischen einem Eintrag in ein Feld eines Elements und einem Element
darstellen;
eine Eingabeeinrichtung zur Aufnahme einer Informationsanforderung,
wobei die Anforderung einen Satz in natürlicher Sprache aufweist, gekennzeichnet durch
einen
Parser zum Parsen der Anforderung, um Komponenten der Anforderung
zu bestimmen;
einen Schlitzfüller, der dazu ausgelegt ist,
eine oder mehrere Objektkomponenten, die ein Objekt der Anforderung
von der geparsten Anforderung darstellen, zu identifizieren, wobei
jeder Schlitz einer Gruppe von Indexeinträgen entspricht und wobei der
Schlitzfüller
dazu ausgelegt ist, wenigstens eine Komponente einem entsprechenden
Schlitz einer Schlitz- und Füllanforderung
mit mehreren Schlitzen zuzuweisen; und
einen Abfrageerzeuger,
für den
Zugriff auf den Datenspeicher, wobei der Abfrageerzeuger dazu ausgelegt
ist, eine zugewiese ne Komponente mit Indexeinträgen zu vergleichen, innerhalb
welcher Gruppe von Indexeintragung auch immer dies dem Schlitz der
zugewiesenen Komponente entspricht, um einen entsprechenden Indexeintrag
zu identifizieren, und um den identifizierten Indexeintrag zu benutzen,
um ein Element in der semistrukturierten Datenbank zu identifizieren.
-
Daher
weist die Abfrageeinrichtung der Erfindung tatsächlich einen Schlitz einem
Indexeintrag oder einer Gruppe von Indexeinträgen zu, und sobald die Abfrage
geparst und einem Schlitz zugewiesen wurde, wird der Indexeintrag,
der dem entspricht, identifiziert. Dies ist wesentlich weniger komplex
als die bekannten Verfahren, so wie oben bei Tseng et al. beschrieben.
-
Ein
Beispiel einer Vorrichtung gemäß der vorliegenden
Erfindung wird nun bezugnehmend auf die begleitenden Zeichnungen
beschrieben, in der
-
1 in
schematischer Form eine Vorrichtung zum Erzeugen eines Indexes in
einer semistrukturierten Datenbank zeigt;
-
2a ein
typisches Element eines Yellow Pages®-Verzeichnisses zeigt;
-
2b eine
Darstellung des Formates der Daten des Elements aus 2a ist;
-
3 einen
typischen Titel, "See"-Referenz- und "See-Also"-Referenz-Einträge aus dem
Yellow Pages®-Verzeichnis
zeigt; und
-
4 in
einer schematischen Form eine Vorrichtung für die Anforderung eines Elements
aus einer semistrukturierten Datenbank zeigt.
-
Eine
Vorrichtung zum Erzeugen eines Indexes für eine semistrukturierte Datenbank
wird nun bezugnehmend auf 1 beschrieben.
Die Vorrichtung weist einen Datenbankspeicher 1 auf, der
die Daten, die die semistrukturierte zu indizierende Datenbank bilden,
speichert, und einen Indexspeicher 2, der den erzeugten
Index speichert. Der Indexspeicher 2 und der Datenbankspeicher 1 sind,
um den Index zu erzeugen, an die Vorrichtung 3 gekoppelt,
die im Allgemeinen aus einem Computer, wie z.B. einer SUN SPARCS-175-Station, oder Ähnlichem,
besteht. Dieser beinhaltet einen Prozessor 4, der an einen
Speicher 5 gekoppelt ist, welcher eine Anzahl von bestimmten
Auswahlkriterien speichert. Der Prozessor 4 ist auch über einen
Bus 7 an den Indexgenerator 6 gekoppelt.
-
Die
Funktion der Vorrichtung aus 1 wird nun
beschrieben. Die in 1 gezeigte semistrukturierte
Datenbank enthält
im Allgemeinen eine Anzahl von Elementen, wobei jedes Element als
eine Anzahl von Datensätzen
gespeichert wird. In dem Fall des Yellow Pages®-Verzeichnisses
zum Beispiel weist jedes Element 40 im Allgemeinen eine
individuelle Anzeige auf, wie z.B. die in 2a gezeigte
Anzeige. Dies beinhaltet typischerweise ein Namensfeld 41 mit
einem Namenseintrag 42 und ein Freitextfeld 43 mit
einem Freitexteintrag 44, einen Adresseintrag 45 und
einen Telefonnummerneintrag 46.
-
Jedes
Element in dem Datenbankspeicher 1 wird als eine Anzahl
von Datensätzen 51, 52, 53, 54 gespeichert,
wobei jeder Datensatz einer separaten Linie in dem Element entspricht.
Jeder Datensatz bezeichnet in einem ersten Bereich 51A, 52A, 53A, 54A das
Element, auf das sich der Datensatz bezieht. Ein zweiter Bereich 51B, 52B, 53B, 54B gibt
den Typ eines Datenfeldes an. Daher zeigt in dem vorliegenden Beispiel
der zweite Bereich 52B, 53B, 54B der
letzten drei Datensätze
an, dass die Daten in dem Freitextfeld 43 vorgesehen sind,
und dass diese deshalb identisch sind, wobei der zweite Bereich
des ersten Datensatzes 51B anzeigt, dass die Daten in dem
Namensfeld 41 vorgesehen sind. Der letzte Bereich 51C, 52C, 53C, 54C der
Datensätze
enthält
die aktuellen Daten, wie z.B. den Namenseintrag 42, den Freitexteintrag 44,
den Adresseintrag 45 und den Telefoneintrag 46.
-
Im
Betrieb greift der Prozessor 4 auf den Datenbankspeicher 1 zu,
um die Datensätze 51, 52, 53, 54,
die sich auf ein einzelnes Element 40 beziehen, zu erhalten.
Der Prozessor greift dann auf den Speicher 5 zu, um eines
aus einer Anzahl von Auswahlkriterien zu erhalten. Dieses Auswahlkriterium
wird mit den Datensätzen 51, 52, 53, 54 verglichen,
um einen entsprechenden individuellen Eintrag innerhalb des Elements 40,
das den jeweiligen Auswahlkriterien genügt, zu lokalisieren.
-
Sobald
der Eintrag, der den entsprechenden Auswahlkriterien entspricht,
bestimmt ist, werden die Daten, die jenem Eintrag entsprechen, aus
dem relevanten Datensatz 51, 52, 53, 54 extrahiert
und zusammen mit einer Angabe des Elements, mit dem der Eintrag
verknüpft
ist, an den Indexgenerator 6 übertragen. Der Indexerzeuger 6 erzeugt
dann einen Index, der den Eintrag, der bestimmt wurde, und das Element,
auf das sich der Eintrag bezieht, angibt. Dieser wird dann über den
Bus 7 an den Indexspeicher 2 übertragen. Der Prozessor 4 greift
dann auf den Speicher 5 zu, um das nächste Auswahlkriterium zu erhalten.
-
Sobald
jeder Eintrag in dem Element indiziert ist, greift der Prozessor 4 auf
den Datenbankspeicher 1 zu, um das nächste Element in der Datenbank
zu erhalten. Der Vorgang wird dann wiederholt, bis alle Elemente
indiziert worden sind.
-
Es
ist auch festzustellen, dass in dem Yellow Pages®-Verzeichnis die Elemente 40 in
Abschnitte von zugehörigen
Elementen angeordnet werden. Wie in 3 gezeigt,
beinhaltet jeder Abschnitt 60 einen Titeleintrag 62,
der in einem Titelfeld 61 enthalten ist. Der Titeleintrag
gibt die Art der entsprechenden Einträge an und wird mit einem eigenen
Datensatz versehen.
-
Darüber hinaus
gibt es auch zusätzliche "See"-Referenz-Einträge 63 und "See-Also"-Referenz-Einträge 64,
die auch innerhalb des Titelfeldes 61 in den jeweiligen
Datensätzen
enthalten sein können.
-
"See-Also"-Referenz-Einträge 64 sind
Verbindungen zu Titeleinträgen 62 von
alternativen Abschnitten 60, welche auch relevante Elemente
enthalten können. "See"-Referenz-Einträge 63 sind
wiederum Verbindungen zu Titeleinträgen von alternativen Abschnitten 60,
welche relevante Elemente 40 beinhalten können, jedoch
werden die "See"-Referenz-Einträge, im Gegensatz
zu den "See-Also"-Referenz-Einträgen, dann
benutzt, wenn der Abschnitt 60, der den "See"-Referenz-Eintrag
enthält,
nicht tatsächlich
irgendwelche Elemente enthält.
Dementsprechend werden der Titeleintrag, der "See-Also"-Referenz-Eintrag und der "See"-Referenz-Eintrag
auch an den Prozessor 4 zur Indizierung übermittelt.
-
Im
Gegensatz zu der Indizierung von Elementen beinhaltet jeder Titel,
jeder "See"-Referenz- und "See-Also"-Referenz-Eintrag 62, 63, 64 nicht selbst
ein spezifisches Element. Dementsprechend, sobald der Prozessor 4 einen
Titeleintrag gefunden hat, muss er wieder auf die Daten, die in
dem Datenbankspeicher 1 gespeichert sind, zugreifen, um
zu bestimmten, welche von den Elementen in dem jeweiligen Abschnitt
lokalisiert sind. Details dieser Elemente werden dann an den Indexgenerator 6 übertragen,
der einen Index für
den jeweiligen Titeleintrag erzeugt, wobei der Index eine Liste
von relevanten Elementen in dem jeweiligen Abschnitt beinhaltet. Diese
Liste enthält
auch eine Verbindung zu dem Titeleintrag von alternativen Abschnitten,
wenn dort "See-Also"-Referenzen oder "See"-Referenzen vorhanden sind.
-
Die
Auswahlkriterien selbst müssen
definiert werden, indem ein detailliertes Wissen der Datenbank und
des Formats, in welchem die Daten eingegeben werden, benutzt wird.
-
Zum
Beispiel ist es im Fall von dem in 2a gezeigten
Element 40 notwendig, das Vorliegen des Namenseintrags 42,
des Freitexteintrags 44, des Adresseintrags 45 und
des Telefonnummerneintrags 46 sowie der Titeleinträge zu bestimmen.
Das Verfahren, um dies zu erreichen, wird nun separat für jeden
Eintrag diskutiert.
-
Namenseintrag 42
-
Dieser
Eintrag ist leicht zu identifizieren, da er in einem spezifischen
Namensfeld lokalisiert ist und deshalb identifiziert werden kann
durch Prüfen des
Datensatzes, der für
den Datenbankspeicher 1 heruntergeladen wurde.
-
Telefonnummerneintrag 46
-
Die
Lokalisierung der Telefonnummerneinträge 46 kann erreicht
werden, indem das Freitextfeld 43 durchsucht wird, um eine
Folge von Ziffern zu lokalisieren, die ein vorbestimmtes Format
haben. So ist zum Beispiel in dem in 2a gezeigten
Element der Telefonnummerneintrag 46 "Colchester 822990". Dementsprechend wird das Auswahlkriterium
zur Lokalisierung des Telefonnummerneintrags 46 so ausgelegt,
dass nach einem Stadtnamen gefolgt von einer Zahl mit sechs Ziffern
gesucht wird.
-
Alternativ
jedoch wird das jeweilige Suchkriterium auch gebraucht, um nach
einer vierstelligen Vorwahlnummer gefolgt von einer sechs- oder
siebenstelligen Zahl, zu suchen. Es ist auch notwendig zu berücksichtigen,
dass es verschiedene Abstände zwischen
den Stellen in der Telefonnummer geben kann, in Abhängigkeit
von dem Format, das für
den Eintrag der Telefonnummer benutzt wird. Dementsprechend beinhaltet
das Suchkriterium, welches benutzt wird, um Telefonnummern zu lokalisieren,
vorzugsweise alle möglichen
Telefonnummernformate, was es erlaubt, jeden beliebigen Telefonnummereintrag
zu lokalisieren.
-
Adresseintrag 45
-
Ferner
ist es notwendig, den Adresseintrag zu lokalisieren, indem der Freitexteintrag
mit einer Anzahl von wahrscheinlichen Formaten für eine Adresse verglichen wird.
So könnte
in dem Beispiel von 2a der Adresseintrag 45 lokalisiert
werden, indem nach einer drei- oder vierstelligen Zahl gefolgt von
einem Wort und dann dem Begriff "street" gesucht wird. Die
Analyse von Adressen zeigt, dass viele tatsächlich Begriffe wie road, street,
avenue... etc. enthalten, und entsprechend können all diese Begriffe in
dem Auswahlkriterium enthalten sein, welches zur Bestimmung von
Adresseinträgen
benutzt wird.
-
Zusätzlich zum
Vergleichen des Freitextfeldes für
einen Begriff dieser Form und einer Adressennummer ist es auch möglich, nach
Ortsnamen, wie Colchester, zu suchen. In diesem Fall könnte eine
solche Suche nicht erfolgreich sein, da Colchester schon als ein
Teil des Telefonnummernfeldes 46 identifiziert sein kann.
Jedoch ist es nicht das Ziel, eine einzelne Regel zu erzeugen, welche
für alle
Begriffe funktioniert, sondern einen Satz von Regeln zu erzeugen
von denen jede in dem entsprechenden Auswahlkriterium dargestellt
wird, sodass, wenn das Auswahlkriterium auf die Daten angewendet
wird, der relevante Eintrag bestimmt wird.
-
Freitexteintrag 44
-
Soweit
der Freitexteintrag 44 betroffen ist, umfasst dieser in
dem vorliegenden Beispiel die Formulierung "suppliers of all top brand golf equipment". Da dieser Eintrag
selbst sehr schwierig zu lokalisieren ist, stellt der Prozessor 4 das
Vorliegen eines Texteintrages 44 fest, indem er erst alle
anderen Einträge
in dem Freitextfeld 43 identifiziert und diese dann ignoriert.
-
Da
das Format des Yellow Pages®-Verzeichnisses derart
ist, dass das Freitextfeld 43 nur immer einen Texteintrag 44,
einen Adresseintrag 45 und einen Telefoneintrag 46 enthält, müssen, sobald
diese Einträge
bestimmt sind, die verbleibenden alphanumerischen Zeichen, die im
Freitextfeld 43 übrig
sind, einen Freitexteintrag 44 aufweisen.
-
Im
Falle des Freitexteintrags 44 beinhaltet dieser eine Anzahl
von Wörtern.
Die Extraktion all dieser Wörter
wäre nicht
besonders nützlich
für Suchzwecke.
Demgemäß ist es
vorzuziehen, selektiver bei der Auswahl der Wörter zu sein, welche benutzt
werden, um einen Index zu bilden.
-
Ein
möglicher
Ansatz ist es, eine begrenzte Anzahl von Wörtern aus dem Texteintrag auszuwählen, um
eine Liste von Schlüsselwörtern zu
bilden. Dann kann ein Index für
jedes Schlüsselwort
gebildet werden. So ist im vorliegenden Beispiel der Freitexteintrag 44 "suppliers of all
top brand golf equipment". In
diesem Fall sind Wörter
wie "of" und "all" an sich nicht sehr
nützlich
und würden
deshalb weggelassen werden. Im Gegensatz dazu bilden die Wörter "supplier" oder "golf" sehr gute Schlüsselwörter.
-
Jedoch
wird das Problem der Auswahl von Schlüsselwörtern vergrößert durch die Tatsache, dass
es keine Satzstruktur in dem Freitexteintrag gibt und dass die Unterscheidungen
von Groß- und Kleinbuchstaben,
welche von vielen lexikalischen Analysepro grammen benutzt werden,
in diesen Elementen eher bedeutungslos sind. Eine Lösung hierfür ist es, eine
vorbestimmte Liste von Schlüsselwörtern zu
haben, welche ausgewählt
werden müssen.
Dies ist jedoch etwas einschränkend
und es wird deshalb bevorzugt, Wörter
auf der Basis von bestimmten Eigenschaften auszuwählen.
-
Im
vorliegenden Beispiel wird dies erreicht, indem alle Wörter, die
nicht Nomen, Verben oder Adjektive sind, gestrichen werden. Diese
Wörter
können leicht
identifiziert werden, indem ein System wie das "Brill-Tagger" benutzt wird, welches Zeilen von Wörtern als
Eingabe nimmt und die Wörter
mit einer "Part-of-Speech"-Markierung markiert,
welche die Art der Wörter
angibt.
-
Ein
Index wird dann erzeugt für:
- i) jedes einzelne Wort, das als Nomen markiert
ist;
- ii) jede Zusammensetzung bestehend aus zwei oder drei aufeinanderfolgenden
Wörtern
(d.h. wo kein Zwischenwort gestrichen worden ist);
- iii) Nomenzusammensetzungen, die aus zwei oder mehr Wörtern bestehen
(diese werden indiziert auf der Basis von jedem einzelnen Wort in der
Zusammensetzung in Kombination mit dem ersten Wort).
-
Die
Benutzung von solchen zusammengesetzten Schlüsselwörtern ist dadurch begrenzt,
dass viele zu spezifisch sind und sich nur auf ein Element beziehen
könnten.
Dieses Problem wird gelöst,
indem alle Zusammensetzungen gestrichen werden, die nur mit einem
einzelnen Element assoziiert sind.
-
Soweit
die verbleibenden Schlüsselwörter und
Zusammensetzungen betroffen sind, ist es notwendig, sich daran zu
erinnern, dass es verschiedene Abwandlungen desselben Wortes so
wie Golf, golfen, Golfer gibt. Da ein direkter Vergleich der Zeichenfolge
von Golf und golfen keine Übereinstimmung
produziert, ist es deutlich vorzuziehen, das Schlüsselwort
oder die Zusammensetzung zu modifizieren, bevor der Index gebildet
wird.
-
Dementsprechend
greift der Pozessor 4 auf ein Lexikon wie z.B. "WordNet" zu. Dieses wird
benutzt, um jedes Wort, das in dem Freitexteintrag lokalisiert ist,
in seine Grundform zu konvertieren, sodass golfen als Golf erfasst
werden würde.
Es ist auch möglich,
Stammformen von Wörtern
zu benutzen, wie zum Beispiel "Lawnmow". Dies würde es dann erlauben,
Wörter
wie "lawnmowers" oder "lawnmowing" zu erkennen.
-
Eine
weitere Alternative, die betrachtet werden muss, wenn man sich mit
Freitexteinträgen
befasst, ist die Benutzung von Synonymen und Hyperonymen. Diese
können
benutzt werden, um Wörter zu
finden, die verschieden sind, die aber ähnliche Bedeutungen haben.
So kann zum Beispiel eine Suche nach Elementen, die sich auf "Teelöffel" beziehen, nicht
sehr viele Datensätze
lokalisieren. Wenn jedoch eine Suche bezüglich des Begriffs "Besteck" ausgeführt werden
würde,
dann würden
mehr Datensätze lokalisiert
werden. Demzufolge ist es möglich,
dass der Index erzeugt wird, indem allgemeinere Synonyme oder Hyperonyme
von Wörtern
benutzt werden, um die Zahl von relevanten Datensätzen, die
lokalisiert werden, zu erhöhen.
-
In
einigen Fällen
ist es vorzuziehen ein zyklisches Verfahren zur Bestimmung des Freitexteintrages
zu benutzen. Bei diesem Vorgang werden aus dem Freitextfeld schrittweise
Textmengen gestrichen, bis die Zahl und die Form der Zusammensetzungen
und Schlüsselwörter, die
bestimmt werden, akzeptabel sind.
-
Titeleintrag 62
-
Wie
oben erwähnt
wird der Titeleintrag 62 identifiziert aufgrund dessen,
dass er im Titelfeld 61 lokalisiert ist. Sobald er jedoch identifiziert
ist, ist es notwendig, ein oder mehrere Schlüsselworte aus dem Titel auszuwählen. Dies
wird ausgeführt
in einer Art und Weise, die ähnlich
ist zu der, die für
den Freitexteintrag auf der Basis von "Brill-Tagger", WordNet und einer Stammroutine, benutzt
wird. Es ist auch notwendig zu gewährleisten, dass jede Abkürzung in dem
Titel identifiziert wird und in ein Schlüsselwort modifiziert wird.
Dies kann erreicht werden, indem die Abkürzungen im Vorhinein identifiziert
werden und indem gewährleistet
wird, dass das Lexikon die Basisform des jeweiligen Wortes aus der
Abkürzung
identifizieren kann.
-
Sobald
die Einträge
bestimmt worden sind, wird die Information in die jeweiligen Indices
eingetragen. Diese Indices werden in Abhängigkeit von der speziellen
Datenbank, die benutzt wird, und von der Art und Weise, in welcher
auf die Datenbank zugegriffen werden muss, bestimmt.
-
So
könnten
zum Beispiel, wenn die Datenbankzugriffstechnik die Benutzung eines
einzigen Schlüsselwortes
mit einbezieht, die Suche auf die gewünschten Indices begrenzt werden,
wie z.B. die Liste von Nameneintragsindices, wenn der Name einer Firma
bekannt ist.
-
Das
vorliegende Beispiel benutzt eine Erweiterung davon, in welcher
wenigstens einige der Indices in vorteilhafter Art und Weise bestimmt
werden, um den jeweiligen Schlitzen in einer Schlitz- und Füllanforderung
zu entsprechen, deren Bildung unten genauer erklärt wird. Dies bedeutet, dass
der Suchbegriff, der in einen gegebenen Schlitz eingegeben wird,
nur mit dem entsprechenden Satz von Indices verglichen zu werden
braucht, welche mit jenem Schlitz assoziiert sind, wobei der Umfang
des erforderlichen Suchens redu ziert wird, während es ermöglicht wird,
genaue Suchvorgänge
durchzuführen.
-
In
dem vorliegenden Beispiel beinhaltet die Schlitz- und Füllanforderung
Transaktions-, Waren-, Orts-, Bezahlungs-, Öffnungszeiten- und Straßenschlitze.
-
Ort-
und Straßen-Indices
sind von dem Adresseintrag abgeleitet. Dementsprechend werden, sobald
der Adresseintrag bestimmt und analysiert worden ist, alle Details,
die einen allgemeinen Ort betreffen, wie der Ortsname "Colchester", in dem Ortindex
gespeichert, während
detaillierte Straßennamen in
dem Straßenindex
gespeichert werden.
-
Die
Bezahlungs-, Öffnungszeiten-
und Warenindices werden von dem Freitextfeld abgeleitet. So würde in dem
oben genannten Beispiel das Wort "Golf" bestimmt
und in dem Warenschlitz platziert werden. Ähnlich würden Wörter wie "Visa", "Cash" oder "Credit Card", die sich auf Bezahlungsmethoden beziehen,
in dem Bezahlungsschlitz gespeichert werden, während Öffnungszeiten in dem Öffnungszeitenschlitz
gespeichert werden.
-
Alle
Einträge,
die keinen assoziierten spezifischen Index haben, werden dann in
einen Index eingegeben, der mit dem Feld, von welchem sie abgeleitet
werden, assoziiert ist. In dem oben genannten Beispiel sind deshalb
auch ein Namensindex, ein Telefonnummernindex und ein kompletter
Adressindex vorgesehen. Ähnlich
werden alle anderen Einträge
in dem Freitextfeld in einem Freitextindex platziert.
-
Während des
Abfrageprozesses werden alle Suchbegriffe, die in dem Transaktionsfeld
lokalisiert sind, welches keinen assoziierten Index hat, dann in all
den Freitextindices gesucht. Aufgrund der Art und Weise, in welcher
der Warensuchbegriff abgeleitet wird, kann es auch vorteilhaft sein,
den Warenschlitzsuchbegriff mit den Freitextindices zu vergleichen. Da
dies jedoch weniger relevante Datensätze lokalisieren könnte, kann
das System konfiguriert werden, diese Suche nur dann auszuführen, wenn
anfangs unzureichende Datensätze
gefunden werden.
-
Soweit
ein Namensindex, ein Telefonnummernindex und ein kompletter Adressindex
betroffen sind, werden diese während
der Abfrage von Elementen benutzt, um zu ermöglichen, dass die Information,
die in dem Element enthalten ist, aus der Datenbank abgefragt wird.
Optional können
diese auch gesucht werden.
-
Sobald
die Indices definiert worden sind, ist es vorzuziehen weiter einen
Satz von Rangfolgewerten zu definieren, welche angeben wie relevant
ein Element für
einen speziellen Index ist. Dies wird erreicht, indem die Anzahl
von Elementen bestimmt wird, welche lokalisiert werden würden, wenn
ein spezifischer Index benutzt würde.
Im Allgemeinen hat im Falle einer Vielzahl von Indices, wenn eine Vielzahl
an Elementen erhalten würde,
jedes Element einen relativ niedrigen Rangfolgewert, der eine relativ
niedrige Relevanz anzeigt. Im Gegensatz dazu haben diese, wenn nur
eine kleine Anzahl von Elementen für einen bestimmten Index erhalten
wird, einen hohen Rangfolgewert, der anzeigt, dass sie sehr relevante
Elemente sind.
-
Die
Situation wird weiter verkompliziert durch Titeleinträge, da jeder
Titeleintrag sich auf eine Anzahl von zugehörigen Elementen bezieht, wobei
alle davon relevant sind. Dementsprechend wird Indices für Titeleinträge ein höherer Rangfolgewert
gegeben, als jenen für
die Texteinträge.
-
Im
Falle der "See"-Referenz-Einträge wird der
Titeleintrag auf den sie sich beziehen, betrachtet, als ob sich
die ursprüngliche
Anforderung direkt auf jenen Titeleintrag bezöge. "See-Also"-Referenz-Einträge werden
jedoch ignoriert, da die Titeleinträge, auf die sie sich beziehen,
gewöhnlich
viel allgemeiner sind, als die Titeleinträge, unter welchen die "See-Also"-Referenz auftritt.
Zudem gibt es oft vielfache Titel-"See-Also"-Referenzen für jeden gegebenen Titeleintrag.
-
Es
ist jedoch festzustellen, dass die Berechnung von Rangfolgewerten
sehr situationsabhängig ist,
und das verwendete Verfahren variiert deshalb für verschiedene semistrukturierte
Datenbanken.
-
Eine
Vorrichtung für
den Zugriff auf die semistrukturierte Datenbank unter Benutzung
der erzeugten Indices wird nun mit Bezug auf 4 beschrieben,
welche schematisch eine Systemarchitektur für den Zugriff auf Elemente
einer semistrukturierten Datenbank zeigt. Das System, das allgemein
aus einer Computeranordnung gebildet wird, beinhaltet einen Prozessor 100,
der an eine Eingabe/Ausgabe-Vorrichtung 101 gekoppelt ist.
Die Eingabe/Ausgabe-Vorrichtung 101 kann
jede Art von Eingabe/Ausgabe-Vorrichtung sein, wie z.B. eine graphische
Benutzerschnittstelle (GUI) und eine Tastatur, oder ein Mikrofon
und ein Lautsprecher gekoppelt an einen Spracherkennungs-/Synthesizer-Schaltkreis oder
einer Kombination von beiden.
-
Der
Prozessor 100 ist auch an ein Datenbankzugriffssystem 102 gekoppelt.
Das Datenbankzugriffssystem 102 beinhaltet einen Dialogmanager 103,
der an den Prozessor 100 gekoppelt ist. Der Dialogmanager 103 ist
auch gekoppelt an einen Parser 104, einen Abfrageerzeuger 105 und
einen Schlitzfüller 108.
Der Schlitzfüller 108 und
der Abfrageerzeuger 105 sind beide an ein Weltmodell 106 gekoppelt. Der
Abfrageerzeuger 105 ist auch an ein Backend 107 gekoppelt,
das im vorliegenden Beispiel aus der Vorrichtung gemäß 1 gebildet
wird und deshalb den semistrukturierten Datenbankspeicher 1 und
den Indexspeicher 2 beinhaltet.
-
Im
Betrieb wird eine Informationsanforderung durch einen Benutzer eingegeben,
der die Eingabe/Ausgabe-Vorrichtung 101 benutzt. In dem
vorliegenden Beispiel des Yellow Pages®-Verzeichnisses
hat die Anforderung die Form eines natürlichen Satzes wie:
"I want a plumber
for my boiler, who takes visa, in Ipswich".
-
Die
Anforderung wird über
den Prozessor 100 an den Dialogmanager 103 übertragen,
welcher das gegenwärtige
Stadium der Anfrageverarbeitung beobachtet sowie die Arbeit des
Parsers 104 und des Abfrageerzeugers 105 steuert.
-
Von
dem Dialogmanager wird die Anforderung an den Parser 104 weitergeleitet,
der die Anforderung parst, um die Anforderung in ihre Bestandteile zu
zerlegen. Die Bestandteile werden dann grammatikalisch beschrieben,
bevor sie an den Schlitzfüller 108 weitergeleitet
werden. Der Schlitzfüller 108 weist die
Bestandteile verschiedenen Schlitzen in einer so genannten Schlitz-
und Füllanforderung
zu, was unten genauer beschrieben wird. Diese Schlitz- und Füllanforderung
wird dann an den Abfrageerzeuger 105 über den Dialogmanager 103 übertragen.
-
Der
Abfrageerzeuger wandelt die Anforderung in eine Datenbankabfrage
um, indem er, falls nötig,
das Weltmodell 106 benutzt. Der Abfrageerzeuger greift
dann auf den Indexspeicher 2 in dem Backend 107 zu,
um den Ort der relevanten Elemente innerhalb des Datenbankspeichers 1 zu
erhalten. Sobald die relevanten Elemente lokalisiert sind, werden
diese an den Dialogmanager 103 zurückübertragen, welcher feststellt,
ob die abgerufenen Elemente akzeptabel sind. Akzeptable Elemente
werden an den Prozessor 100 weitergeleitet, welcher eine
Ausgabe erzeugt stellvertretend für die entsprechenden Elemente,
die dem Benutzer unter Verwendung der Eingabe/Ausgabe-Vorrichtung 101 gezeigt
wird.
-
Falls
zu viele oder zu wenige Datensätze
lokalisiert werden oder die lokalisierten Datensätze ungeeignet sind, modifiziert
der Dialogmanager 103 die Schlitz- und Füllanforderung,
die von dem Schlitzfüller 108 erhalten
wird. Diese Modifikation kann entweder auf einer grammatikalischen
Modifikation basieren oder alternativ auf Modifikationen, die durch
den Dialog zwischen dem Benutzer und dem Dialogmanager 103 angegeben
sind.
-
Sobald
die Schlitz- und Füllanforderung
modifiziert ist, wird die Datenbankabfrage so wie oben dargelegt
durch den Abfrageerzeuger 105 wiederholt.
-
Die
Arbeit des Datenbankzugriffssystems 102 wird nun genauer
beschrieben.
-
Wie
oben erwähnt,
wird eine von einem Benutzer eingegebene Anforderung an den Dialogmanager 103 weitergeleitet,
der die Anforderung analysiert, um zu bestimmen, ob es eine Anforderung
für Daten
oder eine alternative Betriebsanforderung ist, wie z.B. das Verlassen
oder Neustarten des Systems, eine Hilfeanforderung vom Betriebssystem oder
die Korrektur einer zuvor eingegebenen Anforderung.
-
Im
Fall der Korrektur einer zuvor eingegebenen Anforderung modifiziert
der Dialogmanager 103 die Anforderung, was unten genauer
beschrieben wird. Für
andere Betriebsanforderungen weist der Dialogmanager den Prozessor 100 an,
eine geeignete Operation, wie das Bereitstellen von Hilfeinformation, Verlassen
oder Neustart des Systems, auszuführen.
-
In
dem Fall, in dem die Anforderung eine Anforderung von Informationen
aus der Datenbank ist, überträgt der Dialogmanager 103 die
Anforderung an den Parser 104.
-
Parser 104
-
Wie
oben erwähnt,
werden in diesem Beispiel Anforderungen in das System in Form eines Standardsatzes
eingegeben. Daher gibt es nicht notwendigerweise eine Standardstruktur
für die
Anfrage und es ist deshalb notwendig, den beabsichtigten Umfang
der Anforderung zu bestimmen, indem diese in eine Form gebracht
wird, welche der Abfrageerzeuger 105 handhaben kann.
-
Die
erste Stufe ist es, den Satz zu parsen, um den Satz in seine einzelnen
Bestandteile zu zerlegen. Während
eine Anzahl von verschiedenen Parsingverfahren benutzt werden kann,
ist es bei der genau bestimmten Semantik und Syntax des Satzes im vorliegenden
Beispiel für
den Syntaxbaum nicht notwendig, linguistisch korrekt zu sein. Statt
dessen muss der Parser nur eine Struktur bestimmen, die es erlaubt,
die Suche auszuführen.
Dementsprechend ist der Parser so konfiguriert, dass er als ein
schwacher Parser arbeitet, was bedeutet, dass es für den Parser
nicht notwendig ist, die exakte Wortklasse von allen Wörtern in
der Anforderung zu identifizieren, solange irgendeine Form des Syntaxbaumes
gefunden werden kann, um den Satz darzustellen.
-
Wenn
das Ergebnis des Parsingprozesses ungeeignet ist, hat dies den Effekt,
dass keine relevanten Datensätze
gefunden werden. In dieser Situation stellt der Dialogmanager 103 fest,
dass die Anforderung ungeeignet war, und wird deshalb eine Rückmeldung
beim Benutzer vorsehen, um die Anforderung klären zu lassen, wie es unten
genauer erklärt
wird.
-
Angesichts
dessen benutzt der Parser eine einfache DCG-ähnliche
Grammatik und wird als einfacher Bottom-up-Chart-Parser in der Art
wie unten beschrieben implementiert.
-
Zuerst
durchsucht der Parser 104 den Satz um alle harten Wörter zu
bestimmen. Harte Wörter sind
Wörter
einer in sich ge schlossenen Gattung, die nur in eine einzige grammatikalische
Gattung fallen können
und deshalb Wörter
beinhalten, die nur als ein Verb oder nur als ein Nomen oder nur
als ein Adjektiv oder nur als eine Präposition dienen können. Diese
harten Wörter
sind in einer Liste vorgesehen, die in Form eines Lexikons in einem
Speicher (nicht gezeigt) gespeichert ist. Alle anderen Wörter, die nicht
als harte Wörter
aufgelistet sind, werden automatisch als weiche Wörter identifiziert,
was bedeutet, dass sie in irgendeine einer Anzahl von grammatikalischen
Gattungen fallen können,
in Abhängigkeit
von dem Kontext, in welchem die Wörter benutzt werden. Ein Beispiel
dafür ist
das Wort "schwimmen", das als Nomen oder
als Verb benutzt werden kann. In diesem Beispiel wird, um die Informationsmenge,
die aus dem Satz erhalten wird, zu maximieren, jedes Wort, das als
ein weiches Wort klassifiziert ist, automatisch wenigstens als ein
Nomen identifiziert.
-
Der
Parser 104 durchsucht dann den Satz, um alle Präpositionen
und alle Verben zu bestimmen.
-
Dies
hat den Vorteil, dass es dem Lexikon, das im Speicher (nicht gezeigt)
gespeichert ist, erlaubt, auf einer Liste von Präpositionen, harten Wörtern und
allen von der zugehörigen
Datenbank benutzten Verben zu basieren. Dies kann den Inhalt des Lexikons
auf nur 400 Elemente beschränken,
wodurch es dem Parser 104 ermöglicht wird, die Anforderung
sehr schnell zu durchsuchen.
-
Sobald
der Satz zerlegt worden ist und die relevanten Komponenten identifiziert
sind, wird es an den Schlitzfüller 108 in
Form eines Syntaxbaumes weitergeleitet. Dies zeigt für jede Satzkomponente an,
wie sie durch die Grammatik analysiert wird.
-
Ein
Beispiel eines solchen Syntaxbaumes ist unten gegeben, in welchem
der Satz "I want
a plumber for my boiler, who takes visa, in Ipswich" zerlegt wird.
[s,
[np, [pron, i], [vp, [v, want], [np, [det, a], [np, [n, plumber],
[pp, [prep, for], [np, [det, my],
[np, [n, boiler], [relc,
[rel, who], [np, [n, takes], [np, [n, visa],
[pp, [prep, in],
[np, [n, Ipswich]]]]]]]]]]]]]
wo:
- (NP) =
- ein Nomenausdruck
- (VP) =
- ein Verbausdruck
- (PP) =
- ein Präpositionalausdruck
- (RELC) =
- ein Relativsatz
- (PRON) =
- ein Pronomen
- (V) =
- ein Verb
- (N) =
- ein Nomen
- (PREP) =
- eine Präposition
- (REL) =
- ein Relativpronomen
- (DET) =
- ein Bestimmungswort
-
Schlitzfüller 108
-
Der
Schlitzfüller
analysiert dann den geparsten Satz, um die Satzstruktur festzustellen.
In diesem Fall wird angenommen, dass die Satzstruktur im Wesentlichen
Subjekt, Verb, Objekt und (optional) Modifikatoren sind.
-
Dementsprechend
ist für
den Schlitzfüller 108 der
erste Schritt, das erste Verb oder die erste Verbgruppe in dem Satz
zu identifizieren. Verbgruppen werden identifiziert, indem der Satz
analysiert wird, um zu bestimmen, ob es mehrere Verben gibt. Wenn
nicht, dann gibt es keine Verbgruppe. Wenn es jedoch mehrere Verben
gibt, werden die Verben mit einer Liste von bekannten Verbgruppen,
die in dem Speicher (nicht gezeigt) gespeichert sind, verglichen.
-
Sobald
das Verb oder die Verbgruppe identifiziert ist, wird alles in dem
Satz, was vor dem Verb steht, als Subjekt der Anforderung bestimmt
und alles nachher wird als Objekt und zugeordnete Modifikatoren
bestimmt. Alles in dem Objekt, das als ein Präpositionalausdruck identifiziert
wird, wird als ein Modifikator für
das Objekt betrachtet.
-
Wenn
man diese Methode benutzt, wird die Struktur des oben erwähnten Satzes "I want a plumber
for my boiler, who takes visa, in Ipswhich" wie folgt identifiziert:
| Subjekt | I |
| Verb | want |
| Objekt | a
plumber |
| Modifikatoren | for
my boiler, who takes visa, in Ipswich. |
-
Wenn
eine missgebildete Eingabe wie ein einzelner Nomenausdruck (zum
Beispiel "parachuting
centre") eingegeben
wird, würde
vermutet, dass dies ein Objekt mit allen zugeordneten Modifikatoren ist.
Solche Eingaben werden durch das Fehlen jeglichen Verbs innerhalb
des Satzes identifiziert.
-
Die
oben erwähnte
Analyse ist weitgehend bereichsunabhängig. Dies kommt daher, dass
die Analyse in der gleichen Art und Weise ausgeführt werden kann, unabhängig von
der Datenbank, mit der das System benutzt wird, obwohl einige kleinere Änderungen
des Lexikons erforderlich sein könnten, wenn
das System in Verbindung mit einer alternativen Datenbank, die im
Wesentlichen verschiedene Verben benutzt, verwendet wird.
-
Die
gegliederte Anforderung durchläuft
dann eine bereichsabhängige
Analyse. Diese Analyse wird dazu benutzt, Teile der Satzstruktur
in verschiedene Schlitze zum Durchsuchen der Datenbank abzubilden.
Dementsprechend hängt
diese Analyse von der durchsuchten Datenbank und den zugehörigen erzeugten
Indices ab. Somit wird in diesem Beispiel die Abbildung in verschiedene
Schlitze so ausgeführt, dass
die Schlitze für
das Durchsuchen des Yellow Pages®-Verzeichnisses
geeignet sind.
-
In
diesem besonderen Beispiel ist es gewöhnlich nicht notwendig, Details
des Satzsubjektes zu kennen, weshalb diese Information verworfen wird.
Weiter gibt es eine Anzahl von Wörtern und/oder
Sätzen,
die typischerweise keine Information in den Yellow Pages® mitteilen,
so wie "der", "und", "Adresse", oder "Telefonnummer", und die Suche mit diesen
Wörtern
und/oder Sätzen
würde nicht
helfen, relevante Datensätze
zu lokalisieren. Diese Wörter und/oder
Sätze werden
als Stoppworte bezeichnet und ein Datensatz davon wird auch in dem
Lexikon im Speicher (nicht gezeigt) gespeichert. Der zerlegte Satz
wird deshalb durchsucht und alle Stoppworte werden entfernt.
-
Die
nächste
Stufe ist es, einzelne Wörter oder
Sätze in
die Schlitze der Schlitz- und Füllanforderung
zu setzen. In dem vorliegenden Beispiel des Yellow Pages®-Verzeichnisses
sind die bevorzugt benutzten Schlitze Transaktion, Waren, Bezahlung, Öffnungszeit,
Straße
und Ort.
-
Die
Verbinformation bildet direkt in den Transaktionsschlitz ab und
die Objektinformation bildet in den Warenschlitz ab. Weiter kann
der Ortschlitz leicht gefüllt
werden durch eine einfache Suche nach bekannten Orten, die in der
Datenbank beinhaltet sind. So ergibt dies im vorliegenden Beispiel
anfangs die folgenden Schlitz- und Füllanforderungen:
| Transaktion | <leer> |
| Waren | Plumber |
| Ort | Ipswich |
-
Der
Transaktionsschlitz bleibt leer, da das Verb "want" keine
nützliche
Information mitteilt und deshalb als ein Stoppwort entfernt würde. Wenn
jedoch der Satz das Verb "hire" zum Beispiel in "I want to hire a
car" beinhaltet
hätte,
dann würde
der Transaktionsschlitz das Wort "hire" beinhalten.
Die Suche würde
dann beschränkt
werden auf Mietwagenfirmen.
-
Soweit
die Bezahlungs-, Öffnungszeiten- und
Straßenschlitze
betroffen sind, wird diese Information fast ausschließlich innerhalb
der Objektmodifikatoren gefunden. Demgemäß beinhaltet jeder Schlitz
eine zugeordnete Reihe von Prädikaten,
deren Funktion es ist, das Modifikatorfragment der Anforderung zu
durchsuchen, wobei nach Begriffen, welche mit spezifischen Schlitzen
identifiziert sind, gesucht wird.
-
Die
Prädikate
sind eine Reihe von Regeln, welche definieren, ob ein Begriff in
den jeweiligen Schlitz aufgenommen werden sollte. Demgemäß sucht
in diesem Beispiel das Prädikat,
das mit dem Bezahlungsschlitz verknüpft ist, nach Wörtern wie
Visa, Delta, "switch" Credit Card "access" "cash" etc.
In ähnlicher
Weise sucht das Straßenschlitzprädikat nach
Straßennamen,
welche auf der Basis ihrer Struktur erkannt werden. So nehmen Straßennamen oft
die Form "X Crescent" oder "X Road" an, wobei X ein
Name ist. Zusätzlich
könnte
die Identifikation von Straßennamen
unterstützt
werden, indem Inhalte in die Datenbank aufgenommen werden, zum Beispiel durch
Aufnehmen des bekannten Straßennamens "X", sodass die Straßen direkt auf der Basis des
Namens identifiziert werden können.
-
Die
Prädikate
sind in diesem Beispiel in der Prolog-Programmiersprache implementiert, obwohl jedes
geeignete Verfahren der Implementierung benutzt werden könnte.
-
Sobald
dies abgeschlossen ist, wird jede zusätzliche modifizierte Information
in dem Warenschlitz platziert. In dem vorliegenden Beispiel führt dies
zu der folgenden Schlitz- und Füllanforderung:
| Transaktion | <leer> |
| Waren | Plumber & Boiler |
| Ort | Ipswich |
| Bezahlung | Visa |
| Öffnungszeit | <leer> |
| Straße | <leer> |
-
Man
erkennt, dass die Prädikate
abhängig von
dem Schlitz, der gefüllt
werden muss, und den Inhalten der zugehörigen Datenbank angepasst werden
können.
-
Die
Schlitz- und Füllanforderung
wird dann über
den Dialogmanager 103 zu dem Abfrageerzeuger 105 übertragen.
-
Damit
die Suche erfolgreich ist, beinhaltet die Schlitz- und Füllanforderung
gewöhnlicherweise
wenigstens einen Schlitz, der gefüllt werden muss. In dem vorliegenden
Beispiel ist es unmöglich,
relevante Datensätze
zu lokalisieren, falls kein Suchbegriff in dem Warenschlitz vorhanden
ist. Demgemäß, wenn der
Schlitzfüller 108 feststellt,
dass der Warenschlitz leer ist, dann gibt er die Anforderung an
den Dialogmanager 103 zurück. Der Dialogmanager fordert dann
eine Korrektur des Suchbegriffes vom Benutzer, sodass ein Warenschlitzeintrag
bestimmt werden kann.
-
Dies
kann erreicht werden, indem man den Benutzer darauf hinweist, dass
mehr Informationen erforderlich sind bezüglich welche Waren oder Dienste
benötigt
werden. Die Antwort, falls sie in einer Einwortform vorliegt, kann
dann einfach zu dem Warenschlitz hinzugefügt werden. Alternativ könnte die Anforderung
in der üblicher
Art und Weise neu verarbeitet werden.
-
Abfrageerzeuger 105
-
Der
Abfrageerzeuger 105 benutzt die Schlitz- und Füllanforderung,
um auf das Backend 107 zuzugreifen und um eine Anzahl von
Elementen, die relevant für
die Schlitz- und Füllanforderung
zu sein scheinen, zu bestimmen. Somit greift der Abfrageerzeuger 105 auf
Indices zu, die die Schlüsselwörter enthalten,
die in die entsprechenden Felder der Schlitz- und Füllanforderung
eingetragen wurden.
-
In
dem vorliegenden oben beschriebenen Beispiel würde der Abfrageerzeuger 105 auf
die geeigneten Indices in dem Indexspeicher 2 zugreifen, die
die Schlüsselwörter "plumber", "boiler", "Ipswich" und "Visa" beinhalten.
-
Eine
Liste von beliebigen relevanten Elementen und deren jeweilige Orte
innerhalb des Datenbankspeichers 1 wird dann an den Abfrageerzeuger 105 zurückgegeben
und an den Dialogmanager 103 weitergeleitet, der bestimmt,
ob die Zahl von abgefragten Elementen akzeptabel ist oder ob es
unzureichende oder zu viele Übereinstimmungen
gibt.
-
Wenn
es unzureichende Übereinstimmungen
gibt, erweitert der Abfrageerzeuger 105 den Bereich der
Anforderung. Dies wird erreicht, indem von dem Weltmodell 106 erhaltenes
Wissen verwendet wird, das generell ein Lexikon (zum Beispiel "WordNet") mit verschiedenen
Synonymen, Hyperonymen, Stammversionen von Wörtern und jedem anderen vom
Benutzer erworbenen Wissen beinhaltet.
-
Wenn
daher die Suche zu wenig Übereinstimmungen
ergibt, greift der Abfrageerzeuger 105 auf das Weltmodell 106 zu
und bestimmt ein neues Schlüsselwort,
das auf einem Synonym, Hyperonym oder einer Stammversion des ursprünglichen
Schlüsselworts
basiert. Die Suche kann dann wiederholt werden, indem das neue allgemeinere
Schlüsselwort benutzt
wird, um mehr Ergebnisse zu erhalten.
-
Als
ein Beispiel dürfte
eine Suche nach dem Wort "Teelöffel" nicht sehr viele
Elemente zum Ergebnis haben. Demgemäß wird der Abfrageerzeuger 105 auf
das Weltmodell 106 zugreifen und feststellen, dass ein äquivalentes
Wort, das benutzt werden könnte, "Besteck" ist. Dann wird eine
Suche nach dem Wort "Besteck" mit dem Backend 107 durchgeführt, was
mehr Elemente zum Ergebnis haben wird.
-
Alternativ
könnte
ein Schlitzeintrag "golfing" beschränkt werden
auf "to golf". Jedoch kann eine
zu starke Beschränkung
auf die Stammform zu der fehlerhaften Abfrage von irrelevanten Datensätzen führen, zum
Beispiel wenn "hospitality" beschränkt wird auf "hospital". Demgemäß ist es
vorzuziehen, eine zu geringe Beschränkung zu benutzen, um zu verhindern,
dass irrelevante Datensätze
lokalisiert werden, obwohl, wenn keine Datensätze lokalisiert werden sollten,
die Menge an Beschränkung
erhöht
werden könnte.
-
Jedoch
gibt es in dem vorliegenden Beispiel keine leicht ersichtlichen
Alternativen, die benutzt werden können. Demgemäß modifiziert
der Dialogmanager 103 die Schlitzeinträge, um die Suche zu erweitern.
Dies kann erreicht werden, indem man Informationen entweder über die
Syntax oder die Semantik des Schlitzes benutzt.
-
So
kann es zum Beispiel der Abfrageerzeuger vorziehen, alle Einträge in dem
Warenschlitz zu ignorieren, welche nur als Teil eines Präpositionalausdrucks
lokalisiert sind. In diesem Fall würde dies involvieren, den Begriff "boiler" aus dem Warenschlitz zu
entfernen.
-
Alternativer
könnte
es der Dialogmanager 103 vorziehen, die Suche zu lockern,
indem einige bestimmte Schlitze ignoriert werden. Wenn daher zum
Beispiel ein Eintrag sowohl im Straßenschlitz als auch im Ortschlitz
vorläge,
würde der
Dialogmanager den Inhalt des Straßenschlitzes ignorieren, um
die Suche auf einen breiteren Bereich zu erweitern.
-
Für den Fall,
dass dem Dialogmanager eine Anzahl von verschiedenen Optionen zur
Verfügung steht,
wird der Dialogmanager Angaben der verschiedenen zur Verfügung stehenden
Optionen erzeugen. Diese werden dann dem Benutzer mittels der Eingabe/Ausgabe-Vorrichtung 101 als
eine Anzahl von Fragen präsentiert.
Dies erlaubt es dem Benutzer zu steuern, wie die Suche angepasst
wird.
-
Falls
zum Beispiel die Abfrage eine Anforderung für einen Küchenschrankspezialisten in
Ipswich beinhaltet, könnte
der Dialogmanager Fragen stellen, analog zu:
- 1.
Wollen Sie Übereinstimmungen
in einem größeren Bereich
sehen?
- 2. Soll ich nach Küchenspezialisten
suchen?
- 3. Soll ich nach Schrankspezialisten suchen?
-
Sobald
die Ergebnisse dieser Fragen eingegeben worden sind, modifiziert
der Dialogmanager 103 den Schlitz in der Schlitz- und Füllanforderung entsprechend,
und zwar durch Modifizierung oder Entfernen von Begriffen innerhalb
des Schlitzes. Die modifizierten Schlitze werden dann an den Abfrageerzeuger 105 zurückgesandt,
der die aktualisierte Suche ausführt.
-
Gleichermaßen wird
der Dialogmanager 103, wenn die Anforderung zu viele Datensätze lokalisiert,
den Bereich der Suche verkleinern. Dies kann erreicht werden, indem
man spezifischere Begriffe in den Schlitzen benutzt, die von dem
Weltmodell 106 abgeleitet wurden oder indem weitere Begriffe
abgefragt werden, die zu der Suche hinzugefügt werden.
-
Alternativ
kann es innerhalb der Suche einige Inkonsistenzen oder unbekannte
Konzepte geben, in welchem Falle die Anforderung an den Dialogmanager 103 für eine weitere Überprüfung zurückgeleitet
wird.
-
Sobald
eine geeignete Anzahl von Elementen lokalisiert worden ist, wird
eine Liste von Elementen an den Prozessor 100 übertragen.
Der Benutzer kann dann die Ranglistenwerte der jeweiligen Begriffe
benutzen, um die Relevanz des lokalisierten Begriffes festzustellen.
Der Benutzer wählt
eine Anzahl von Elementen, die betrachtet werden sollen, und diese
werden dann von der Datenbank heruntergeladen und mittels der Eingabe/Ausgabe-Vorrichtung 101 ausgegeben.