Anlage zu AZA 6
Vorhabenbeschreibung AP 7
Partner
| N.Fuhr K.Groß- johann | Experte Informatik Autor/Leser |
Fachbereich Informatik Universität Dortmund | fuhr@ Kai.Grossjohann@ cs.uni-dortmund.de | 0231/ 755 -2045
-5670 |
| W. Dalitz | Experte Mathematik Autor/Leser |
ZIB Berlin | dalitz@zib.de | 030/ 84185 -201 |
| J. Plümer R.Schwänzl | Vorprojekt Autor/Leser |
Universität Osnabrück, FB.Mathematik/Informatik | roland@ mathematik.uni-osnabrueck.de | 0541/ 969 -2526 -2531 |
Viele heute praktisch eingesetzte Retrievalverfahren (insbesondere die WWW-Suchmaschinen und andere Web-basierte Suchsysteme wie z.B. Harvest) behandeln Dokumente als unstrukturierte Textblöcke. Metadaten werden von Harvest nur in HTML2.0 Kodierung erkannt. Daher sind diese Systeme für Dokumentrecherchen nur bedingt geeignet. In dem Maße, wie Metadaten und Volltexte mit reichhaltigerer Strukturierung bereitgestellt werden, wächst auch der Bedarf nach geeigneten Such- und Navigationshilfen, die unter Ausnutzung der explizit vorhandenen Struktur eine präzisere Recherche erlauben. Insbesondere sollen folgende Recherchestrategien unterstützt werden:
Inhaltsorientierte Navigation: Basierend auf einem Klassifikationsschema oder Thesaurus navigiert der Benutzer zu den ihn interessierenden Einträgen .
Freitextsuche: Der Benutzer gibt einige Begriffe ein, die sein Informationsbedürfnis beschreiben, und sucht dann nach hierzu relevanten Dokumenten, wobei die Suche selbst in der Regel auf ``Kurzfassungen'' der Dokumente stattfindet.
Volltextsuche: Bei langen Dokumenten (z.B. Büchern) möchte der Benutzer außer dem Nachweis des Gesamtdokumentes auch einen Hinweis auf den mutmaßlich relevanten Dokumentteil.
Strukturorientierte Dokumentsuche: Der Benutzer sucht nach Inhalten, die in bestimmten Dokumentteilen auftreten sollen (z.B. eingebetteter Programmcode, semantisch faßbare Dokumentteile wie Beweise, Abstracts).
Verwandtheitssuche: Z.B. Referenzen oder Zitate verfolgen ; zitierende, enthaltene oder umfassende Dokumente finden.
Herkunftsorientierte Suche: Wenn ein relevanter Autor ode r eine Institution bekannt sind, sucht der Benutzer nach Dokumenten vom selben Autor / derselben Institution.
Um solche Recherchetaktiken zu unterstützen, muß ein Retrievalsystem zur Verfügung stehen, das strukturierte Dokumente und Metadaten verarbeiten kann und geeignete Such- und Navigationsfunktionen anbietet.
Aus vielfältigen Gründen (z.B. aus rechtlichen und wirtschaftlichen) können die Dokumente selbst häufig nicht an zentraler Stelle gespeichert werden. Daher sollen nur die Metadaten und die Indexierungsdaten in einer Datenbank, die Überblicke vermitteln soll, gespeichert werden. Um auf verteilt vorliegende Metadaten und Dokumente zugreifen zu können, muß eine Sammler-(Gathering-)Komponente bereitgestellt werden. Damit das System neben XML-basierten Dokumentformaten (wie z.B. MathML und CML) auch klassische Dokumentformate wie HTML, Postscript, PDF und LaTeX verarbeiten kann, muß ferner eine Extraktor-Komponente (Extractor/Summarizer) entwickelt werden, die die für die Indexierung benötigten Daten aus diesen Formaten extrahiert.
Das integrierte Retrieval- und Hypertextsystem soll einen zentralen Index sowohl für Metadatensätze als auch für Volltextdokumente verwalten, zudem werden auch die Metadaten zentral gespeichert. Das System soll die folgenden Such- und Browsingfunktionen realisieren:
Derzeit verfügbare kommerzielle Retrieval- und Hypertextsysteme sind nicht flexibel genug, um Dokumentmengen nach unterschiedlichen Gesichtspunkten zu ordnen oder verschiedene Recherchestrategien zu unterstützen (s.a. W. Sander-Beuermann: Schatzsucher. Die Internet-Suchmaschinen der Zukunft. c't 13/98, S. 178). Retrievalsysteme bieten in der Regel nur einige Textsuchfunktionen sowie Suchmöglichkeiten für bibliographische Attribute. Fachspezifische Suchoperatoren (z.B. für technische Meßgrößen oder physikalische Reaktionsgleichungen) werden nicht angeboten und können auch nicht vom Anwender nachträglich integriert werden. Volltextsuche in strukturierten Dokumenten kann nur in der Form realisiert werden, indem entweder das vollständige Dokument als Antwort zurückgeliefert wird oder das Dokument in Teile zerlegt wird, die vom System aber als unabhängige Dokumente behandelt werden. Ferner bieten diese Systeme keine Hypertext-Funktionalität. Umgekehrt unterstützen Hypertext-Systeme zwar die Navigation in Dokumentaggregationen (und damit in Volltexten) und das Verfolgen referentieller Verknüpfungen. Leider ist hier aber die Retrievalfunktionalität unterentwickelt, und daher wird auch das Browsen in Attributwerten (z.B. Autorennamen, Klassifikationsschemata) sowie deren implizite Verknüpfung mit den zugehörigen Dokumenten nicht unterstützt.
Experimentelle Systeme bieten im Vergleich zu den kommerziellen in Teilbereichen meist bessere Lösungen an, doch konzentrieren sich solche Ansätze jeweils auf Einzelaspekte. Im Hinblick auf die Realisierung integrierter Systeme sind jedoch bislang keine Forschungsanstrengungen zu erkennen.
Literatur/Eigene Arbeiten:
(Informationsrecherche und weitere Arbeiten des Antragstellers in Anlage)
III. Ausführliche Beschreibung des Arbeitsplans
| 6 Monate | Do | Broker:
Einbau Suchmaschine WAIT in Harvest statt glimpse. Ersetzt internes Format des
Brokers (SOIF) durch wählbare XML-DTD. Anpassung der Kommunikation von Gatherer/Extraktor und Broker an das XML Format RDF. Schnittstellenbeschreibung. |
| Os | Gatherer:
Evaluation des Harvest-ng Gatherers hinsichtlich Plattformunabhängigkeit.
Extractor: SOIF -> RDF Embedding (verlustfrei) Weiternutzbarkeit der Harvest Summarizer unter WAIT. | |
| Os / ZIB | Gatherer/Extractor: RDF -> SOIF flattening (verlustbehaftet): Interoperabilität mit SOIF basieren Harvestsystemen. | |
| ZIB | Extractor: Genuiner HTML 4.0 -> RDF Summarizer. Evaluation von Harvest-ng Summarizern | |
| [Retrievalnukleus an AP 6/9 zur Speicherung von und Suche in RDF-MetaDaten] | ||
| 6 Monate | Do | Broker: Browsen in Attributwerten und Verzweigen zu den zugehörigen Dokumenten (Autorennamen, Klassifikationen); Flexible Textsuche; Suchen in MetaDaten: Suchoperatoren für unterschiedliche Datentypen. |
| Os | Gatherer: MetaDatenverfolgung: Rekursive Auflösung von Hyperlinkreferenzen in DC.Relation und DC.Identifier. RDF Schema Erkennung, Übersetzungswerkzeug für Schemes (dabei: Dumpdown und stripping). Genuiner (parsed) RDF Transport. | |
| ZIB | Extractor: TeX (speziell BiBTeX) -> RDF Summarizer. | |
| [Prototyp an AP 6/9 zur Evaluation] | ||
| 2 Monate | Do / Os / ZIB | Revision des Retrievalnucleus nach Feedback durch Test auf den unterschiedlichen Dokumententypen in AP 6 und AP 9. |
| 6 Monate | Do | Broker: Ähnlichkeitssuche; Volltext-Retrieval: Suche nach relevanten Dokumentteilen, Suche in Dokumentstrukturen; Browsen: Navigation zwischen MetaDaten und Dokumenten, Suche nach benutzerdefinierten Kriterien |
| Os | Gatherer: Join von MetaDaten und (automatischen Volltextextracten längs DC.Identifier. MetaDatenannotation bei Doubletten. Empfang von push (authentifizierter Provider-seitiger Anstoß: Push-Modul, Inkrementalität der (neuen) Funktionen, verträglich mit Channels.) | |
| ZIB | Extractor: MathML -> RDF. Einbau des non-mark up Summarizer tools von AP 11 | |
| [Erweiterter Prototyp an AP 6/9 zur Evaluation] | ||
| 2 Monate | Do | Broker: Browsen in aggregierten Dokumenten, referentiellen Verknüpfungen. Automatische Klassifikation. |
| Os | Gatherer: PushModul zur (Re)Konfiguration des Gatherers. | |
| ZIB | Extractor für OpenMath Content Dictionaries. | |
| 2 Monate | Do / Os / ZIB | Dokumentation und Bug-fixes des Retrievalsystems. |
V. Arbeitsteilung/Zusammenarbeit mit Dritten
(Organisationsform:)
Aus dem Arbeitsplan ergibt sich der folgende Förderbedarf