3.4 Die Implementierung: Das Upload-Tool
3.4.5 Anwendungsf¨ alle
3.4 Die Implementierung: Das Upload-Tool 99 wird. Durch die direkte Alinierung der Daten im Upload-File mit Eintr¨agen in der Ressour-ce ¨uber diese Identifikationsnummer erfolgt eine Art modularer Zugriff auf Eintr¨age, der daf¨ur genutzt werden kann, nachtr¨agliche ¨Anderungen zu beobachten, Eintr¨age zu l¨oschen, in ihrer Attributrepr¨asentation zu erweitern, usw..
Erzeugung von Differenzdateien: Eine andere Verwendung der Exportfunktion be-steht darin, bestimmte Zeilen (Formate “Tabelle” und “typisierte Felder”) bzw. Variablen-belegungen (Format “XML”) auszuw¨ahlen und in ein separates Upload-File auszulagern.
Dabei besteht die Option, das aktuelle Schema mit zu ¨ubernehmen1. Eine solche Differenz-datei zu erzeugen kann in verschiedenen F¨allen von Nutzen sein; so k¨onnen f¨ur Konflikte, die sich nicht innerhalb der Sitzung leicht l¨osen lassen, die entsprechenden Datens¨atze exportiert werden, um sie separat h¨andisch zu bearbeiten. Dar¨uber hinaus k¨onnen Varia-blenbelegungen in einer Differenzdatei zu einer Klasse zusammengefasst werden, wenn bei der Betrachtung von Alinierungsergebnissen auff¨allt, dass bestimmte logische Konflikte sy-stematisch vorkommen und sich die entsprechenden Datens¨atze besser mit einem anderen Template behandeln lassen.
3.4 Die Implementierung: Das Upload-Tool 100 det, mit der eine unterschiedliche Kodierung einer Person erzeugt wird, je nachdem, ob f¨ur die Spalte yearein Wert vorhanden ist. Es zeigt ebenfalls eine noch nicht vorgestellte syn-taktische Variante der variablen Summe, die wie ¨ublich durch&* repr¨asentiert wird, in der jedoch die eingebettete Query-Komponente keine Multivariable enth¨alt. Die Auflistung von Spaltenvariablen, die durch den Balken |getrennt werden, stellt eine einfache M¨oglichkeit dar, bei Tabellen auf eine unterschiedliche Anzahl von belegten Spalten zuzugreifen. Ist in einer Zeile kein Wert sowohl f¨urnation als auch f¨urrolledefiniert, so schl¨agt das Schema f¨ur diese Zeile fehl.
\begin{upload} \begin{program} \begin{entries}
if #year != ’’ then
(_{Person}e(&*[#nation|#rolle]&[Geboren #year]).n) else
(_{Person}e&*[#nation|#rolle].n) endif
\begin{names}
Person.name = "#name"
\end{names}
\end{entries}
\end{program}
\begin{data}{#name|#nation|#rolle|#year}
Otto Ubbelohde & Deutschland & Maler & \\
Horst-Rudolf ¨Ubelacker & & Publizist & \\
Paolo Uccello & Italien & Maler & 1397 \\
Hermann Uber & Deutschland & Komponisten & \\
Wendelin ¨Uberzwerch & Deutschland & Schriftsteller & \\
Jorge Ubico Casta~neda & Guatemala & Pr¨asident & \\
Heinrich ¨Ubleis & ¨Osterreich & Juristen &Evaluate 1993 \\
...
Abbildung 3.18: Upload-File zur Population der Ontologie mit Personen
Eine im Deutschen interessante Klasse von facettierten Eintr¨agen bilden Komposita.
Abb. 3.19 stellt ein Upload-File dar, mit dem auf dem Stamm-tee aufbauende Komposita kodiert und in die Ontologie integriert werden k¨onnen. Im Beispiel wird auch die Bedeu-tung des Eintragsschemas zur effizienten Erzeugung graphischer und Flektionsvarianten sichtbar. Die systematische Aufbereitung von Komposita-Upload-Files setzt den Einsatz von Programmen zur Extraktion und Segmentierung von Komposita in ihre Bestandteile in der Wissensakquisitionsphase voraus.
3.4 Die Implementierung: Das Upload-Tool 101
\begin{upload} \begin{program} \begin{entries}
(_{NeuerEintrag}F([#AusWas]&[Teearten]).n)
\begin{names}
NeuerEintrag.name.de.nomen = "#{Name}tee"
NeuerEintrag.variante.de.nomen = "#{Name}tees"
NeuerEintrag.variante.de.nomen = "#{Name}-Tee"
NeuerEintrag.variante.de.nomen = "#{Name}-Tees"
NeuerEintrag.variante.de.nomen =? "#{Synonym}tee"
NeuerEintrag.variante.de.nomen =? "#{Synonym}tees"
NeuerEintrag.variante.de.nomen =? "#{Synonym}-Tee"
NeuerEintrag.variante.de.nomen =? "#{Synonym}-Tees"
\end{names}
\end{entries}
\end{program}
\begin{data}{#AusWas|#Name|#Synonym}
Kamille & Kamillen & \\
Pfefferminze & Pefferminz & \\
Fenchel & Fenchel & \\
Salbei & Salbei & \\
...
Abbildung 3.19: Upload-File zur Population der Ontologie mit Komposita Ausbau des EFGT-Netzes mit Hierarchien
Bei der Integration einer Hierarchie, die im Format typisierte Felder kodiert wurde, ist der Ablauf der Sitzung weniger flexibel als bei der Population mit voneinander unabh¨angigen Eintr¨agen. Ein Unterschied zu diesem Anwendungsfall ergibt sich schon vor Beginn der Sitzung bei der Aufbereitung des Upload-Files: Es muss ¨uberpr¨uft werden, ob das Upload-File tats¨achlich eine Hierarchie kodiert und die Anforderungen an die Wohlgeformtheit der Datei erf¨ullt sind, die in Abschnitt Kodierung von Hierarchien mittels typisierter Felder, S. 79 ff beschrieben wurden. Diese Pr¨ufung erfolgt mit Hilfe des im selben Abschnitt angesprochenen, externen Programms, das u.a. die Zeilen im Datenteil des Upload-Files korrekt sortiert. Ebenfalls m¨ussen eventuell fehlende vorausgesetzte Eintr¨age, an die die Hierarchie im EFGT-Netz ankn¨upft, vorab eingearbeitet werden.
Da die Eintr¨age der Hierarchie aufeinander aufbauen, m¨ussen dann innerhalb der Sit-zung auftretende Konflikte in der Reihenfolge behandelt werden, die der Sortierung der Zeilen entspricht. In der Regel deckt das Schema alle Eintr¨age der Hierarchie und braucht nicht w¨ahrend der Sitzung editiert zu werden. Ein Beispiel ist in Abb. 3.20 dargestellt.
3.4 Die Implementierung: Das Upload-Tool 102
\begin{upload} \begin{program} \begin{entries}
(_{Krankheit}F&*[#*kat].n)
\begin{names}
Krankheit.name.de.nomen = "#mainDE"
\end{names}
\end{entries}
\end{program}
\begin{data}{mainDE|kat|de|en|lt}
mainDE:Infektionskrankheiten;kat:Mikrobioloige;kat:Krankheiten nach Typ; \\
mainDE:Parasit¨are Infektion;de:Parasiteninfektion;
en:parasitic infections;kat:Parasitologie;kat:Infektionskrankheiten;\\
mainDE:Wurminfektionen;kat:Parasit¨are Krankheiten; \\
mainDE:Milbeninfektionen;kat:Parasit¨are Krankheiten; \\
mainDE:Protozoeninfektion;kat:Parasit¨are Krankheiten; \\
mainDE:Giardiasis;kat:Protozoeninfektion; \\
...
Abbildung 3.20: Upload-File zum Ausbau der Ontologie mit einer Taxonomie von Krank-heiten
Erweiterung der linguistischen Repr¨asentation
Eine Anwendung des Upload-Files ist die Erweiterung der linguistischen Repr¨asentation vorhandener Eintr¨age. Dies ist besonders n¨utzlich, wenn die Eintr¨age semiautomatisch er-zeugt worden sind, erg¨anzende Daten f¨ur die Attributrepr¨asentation aber erst nachtr¨aglich verf¨ugbar werden, etwa weil sie zwischenzeitlich ¨ubersetzt oder aus anderen Quellen ge-wonnen wurden. Damit wird die Multilingualit¨at der Ressource stark unterst¨utzt und die Zusammenf¨uhrung unterschiedlicher Phasen der Wissensakquisition (der Modellierungsda-ten, der linguistischen Repr¨asentation, usw.) erm¨oglicht.
Abb. 3.21 zeigt eine Beispieldatei, mit der die linguistische Repr¨asentation der Eintr¨age der Krankheitstaxonomie (vgl. Abb. 3.20) um zus¨atzliche Varianten in verschiedenen Spra-chen erg¨anzt werden kann. Die Daten sind als typisierte Felder kodiert, wobei der Schl¨ussel durch das Feld mainDE und die zus¨atzlichen Varianten auf Englisch und Latein in Feldern von Typ en bzw. lt definiert werden. Auf diese Felder wird mit Hilfe von Multivariablen zugegriffen, die zur Definition von optionalen, erg¨anzenden Attributen benutzt werden.
Der Zugriff auf die Eintr¨age erfolgt ¨uber eine Query-Komponente, die ¨uber den Schl¨ussel mainDE l¨auft und der Vereinbarkeit mit der Grammatik in Abb. 3.2 halber mit der Kom-ponente [Topnode] zu einer Summe erg¨anzt wurde. Der Identifikator des Topnodes f¨allt bei der Normalisierung weg, sodass letzten Endes der Abgleich ¨uber den ID-String des Krankheitseintrags erfolgt. Der erweiterte ID-String ist hier nicht kodierend und dient nur
3.4 Die Implementierung: Das Upload-Tool 103 als Abfragemechanismus. In der endg¨ultigen Syntax kann auf die Komponente[Topnode]
verzichtet werden.
In dieser Art von Sitzung spielen Konfliktbehandlung und Datenexport eine unterge-ordnete Rolle.
\begin{upload} \begin{program} \begin{entries}
(_{Krankheit}[#mainDE]&[Topnode])
\begin{names}
Krankheit.name.de.nomen = "#mainDE"
Krankheit.variante.de.nomen =? "#*de"
Krankheit.variante.en.nomen =? "#*en"
Krankheit.variante.lt.nomen =? "#*lt"
\end{names}
\end{entries}
\end{program}
\begin{data}{mainDE|en|de|lt}
mainDE:Infektionskrankheiten;en:infectious disease;en:infections;\\
mainDE:Parasit¨are Infektion;de:Parasiteninfektion;en:parasitic infections;\\
mainDE:Wurminfektionen;en:worm infections;en:worm infestations;\\
mainDE:Milbeninfektionen;en:mite infections;\\
mainDE:Protozoeninfektion;de:Infektionen durch Protozoen;en:protozoan infections;\\
mainDE:Giardiasis;lt:Lambliasis;en:giardiasis;en:lambliasis;\\
...
Abbildung 3.21: Template zur Erweiterung der linguistischen Repr¨asentation
Herausnehmen bestehender Eintr¨age und Adaption des Netzes
In manchen Situationen kann das L¨oschen der mit Hilfe eines Upload-Files erzeugten Ein-tr¨age sinnvoll sein. Das tritt insbesondere ein, wenn die Ressource zur Erschließung einer Textsammlung eingesetzt wird, die eine geschlossene Wissensdom¨ane darstellt (vgl. Ab-schnittPflege und Maintenance bzw. Adaptionin Kap. 2, S. 54 ff). Wird eine Kopie des f¨ur die Textsammlung relevanten Teils der Ressource in eine separate Datenbank ausgelagert, um diese anschließend anzupassen und weiter zu entwickeln (sog. Adaption) und tr¨agt ein Upload-File nicht zur Abdeckung der anvisierten Textsammlung bei, so empfiehlt sich, zur Vermeidung von Ambiguit¨aten die entsprechenden Eintr¨age wieder heraus zu nehmen.
Beispielsweise stellen die Namen einer Reihe deutscher Gemeinden Homonyme anderer Entit¨aten aus unterschiedlichen Wissensbereichen dar, wie etwa Hornbach (eine Firma) oder Nußbaum (eine Baumart). Ist der Wissensbereich Geographie Deutschlands bei der