 |
Biodiversitätsinformatik / Biodiversity Informatics |
|
Biodiversitätsinformatik / Biodiversity Informatics |
Festlegung einer formalen Sprache zur RegelformulierungINHALT: Die Ausgangssituation
|
Der "potential Taxon"-Graph | Benutzerabfragen
| Die AusgangssituationEine Vielzahl von Sachdaten, die sich in unabhängigen, über die Welt zerstreuten Quellen (Literatur, Datenbanken, usw.) befinden, sind an Taxonnamen gekoppelt und können über diese verknüpft werden. Erhebliche Schwierigkeiten dieses Wissen zusammenzuführen entstehen dadurch, dass oft in den verschiedenen Quellen unterschiedliche Auffassungen über die systematische Position (die den zu benutzenden Taxonname bestimmen kann) und/oder die Umschreibung des Taxons vertreten werden. Die Frage nach der Übertragbarkeit von Sachdaten, die an einem Taxonnamen aus einer Quelle gekoppelt sind, auf einen Taxonnamen aus einer anderen Quelle ist Gegenstand des Forschungsprojekts „MoreTax“. Der „potential Taxon“-GraphEine Auffassung über ein Taxon in einer bestimmten Quelle kann formal durch die Kopplung des benutzten Taxonnamens mit dem Quellenhinweis bezeichnet werden (wir nennen diese Kombination ein "Potential Taxon"). Da Taxa Klassen von Organismen sind, können wir sie als Mengen betrachten, deren Elemente einzelne Organismen sind. Die Auffassung des Taxons bestimmt dessen Umschreibung und damit die enthaltenen Elemente. Im Rahmen des Projektes beschreiben wir einen speziellen Editor (den taxonomischen Editor), der neben der Funktion der Bildung solcher potential Taxa es einem Experten(-team) ermöglicht, die Mengenbeziehungen zwischen verschiedenen potential Taxa (bzw. den diesen zugrunde liegenden Umschreibungen der Taxa) anzugeben. Folgende Grundbeziehungen aus der Mengenlehre sind für die Beschreibung der Beziehung zwischen zwei Potential Taxa PT1 und PT2 relevant:
Betrachten wir die Beziehungen zwischen mehreren Potential Taxa entsteht ein gerichteter Graph, dessen Knoten die Potential Taxa sind und dessen Kanten oder Senken von den Paaren aus Potential Taxa gebildet werden, für die Mengenbeziehungen angegeben wurden:
BenutzerabfragenVorausgesetzt es gibt einen Pool von taxonbezogenen Faktenquellen und die Beziehungen zwischen den in den Quellen genannten Taxonnamen wurden mittels des taxonomischen Editors eingegeben. Vom Standpunkt eines Benutzers sind nun zwei grundsätzlich unterschiedliche sachdatenbezogene Abfragen möglich:
Das Ergebnis soll davon unabhängig sein, an welche Potential Taxa diese Sachdaten ursprünglich gekoppelt waren. Hierfür muss ein auf dem Graph beruhendes Regelsystem aufgebaut werden. Darüber hinaus soll auch die Möglichkeit geschaffen werden, flexible Regeln zu formulieren, die das Ergebnis beeinflussen, und die z.B. von einer Einschätzung der Datenquellen oder des Autors der Beziehung abhängen können. Insgesamt muss der Benutzer über die qualitativen Eigenschaften der übertragenen Sachdaten in Relation zu dem ursprünglich in der Abfrage berührten Potential Taxon informiert werden. Die ÜbertragbarkeitAnwendbarkeit Es gibt vier Kategorien für
die Anwendbarkeit der an ein Potential Taxon geknüpften Sachdaten: Nehmen wir an, Sachdaten seien voll anwendbar für das Potential Taxon PT1. Basierend auf dem Beziehungsgraph existieren mindestens drei Optionen für die Qualität dieser Sachdaten, wenn sie auf PT2 übertragen werden:
Wie man sieht, hängt die Übertragungsqualität der Sachdaten für PT2 von der Anwendbarkeit dieser Sachdaten für PT1 und von der Art der Beziehung zwischen den beiden Potential Taxa ab. Übertragungsweg Betrachtet man den Graph, so wird ersichtlich, dass es nicht für alle Paare von Potential Taxa eine Kante gibt, obwohl es zwischen ihnen einen Weg (Aufeinanderfolge von Kanten) geben kann. Dies trifft in unserem Beispiel für PTi und PTk zu. Es muss also eine Regel geben, nach der aus zwei aufeinanderfolgenden Mengenbeziehungen eine resultierende Mengenbeziehung abgeleitet werden kann. Sind z. B. Bij und Bjk die Mengenbeziehung „Ě“, so ist es leicht zu sehen, dass die resultierende Beziehung zwischen PTi und PTk ebenfalls „Ě“ ist und dementsprechend voll anwendbare Sachdaten für PTi nur partiell anwendbar für PTk sind. Nehmen wir an, dass Bij „Ě“ bleibt aber Bjk „Ĺ“ ist. Man kann dann feststellen, dass die resultierende Beziehung zwischen PTi und PTk nicht mehr eindeutig ist sondern „Ě“ oder „Ĺ“ oder sogar „!“ sein kann. Dies erzwingt die Einführung von „zusammengesetzten“ Beziehungen und eine entsprechende Ausdehnung der Regel. Mit dieser erweiterten Regel kann dann für jeden Weg im Graph eine zugehörige zusammengesetzte Beziehung ermittelt werden. Zwischen zwei Potential Taxa kann es im Graph durchaus mehrere Wege geben. Dies trifft für PTi und PTl zu, denn es gibt einen „direkten“ Weg - nämlich die entsprechende Kante - und auch den (Um-)Weg über PTj. Zu jedem Weg gehört eine zusammengesetzte Beziehung. Zusätzliche Regel müssen also festlegen, wie zu verfahren ist, um aus zwei so entstandenen Beziehungen die resultierende zusammengesetzte Beziehung zu erhalten. Dies führt zu mindestens zwei alternativen Regeln. Bedenkt man, dass zu jeder gerichtete Beziehung zwischen zwei Potential Taxa PT1 und PT2 eine umgekehrte gerichtete Beziehung zwischen PT2 und PT1 ebenfalls durch eine entsprechende Regel definiert werden kann, so erhalten wir insgesamt mindestens vier unterschiedliche Regeln. Die formale BeschreibungDie Qualität von Sachdaten, wenn sie ursprünglich an ein PTq gekoppelt waren und an ein PTz übertragen werden, hängt also sowohl vom Potential Taxon-Graph, oder präziser, von der Menge aller Wege von PTq nach PTz und von den gerichteten Beziehungen, die den einbezogenen Kanten zugeordnet sind, als auch von der Anwendbarkeit der an PTq geknüpften Sachdaten ab. Die Ableitung der Übertragbarkeit basiert also:
Für die formale Beschreibung eines solchen Graphs sowie der Algorithmen und Regeln kann eine beliebige höhere Programmiersprache verwendet werden. Diese Regeln brauchen nicht editierbar zu sein, da sie nicht von den spezifischen Inhalten der einbezogenen Daten abhängen. Wir haben als Beispiel einen "Beziehungsdatentyp" sowie darauf basierende Regeln mit Visual Basic formuliert. Diese Regeln sind die im Punkt "Übertragungsweg" genannten, die zusammengesetzte Beziehungen betreffen, sowie die zuletzt genannte, die die Übertragung der Anwendbarkeit regelt. BeispieleDefinition eines Datentyps für "zusammengesetzte Beziehungen"-Objekte: Public Type Relationship Regel für die Umkehrung "zusammengesetzter Beziehungen": Public Function reverse(Rel1 As Relationship) As Relationship Regel für die Zusammenführung zweier "zusammengesetzten Beziehungen" (enger Konsens): Public Function cons(Rel1 As Relationship, Rel2 As Relationship) As Relationship Regel für die Zusammenführung zweier "zusammengesetzten Beziehungen" (breiter Konsens): Public Function large_cons(Rel1 As Relationship, Rel2 As Relationship) As Relationship Regel für die Verkettung zweier aufeinanderfolgenden "zusammengesetzten Beziehungen": Public Function concatenate(Rel1 As Relationship, Rel2 As Relationship) As Relationship Regel für die Interpretation "zusammengesetzter Beziehungen": Public Function evaluate(Category as
String, Rel1 As Relationship) As String Editierbares RegelsystemEs gibt Situationen in denen - in Abhängigkeit von spezifischen Merkmalen der einbezogenen Daten(-quellen) - das Einführen neuer Regeln bzw. Veränderungen schon existierender Regeln sinnvoll ist, z. B.:
Da Regeln dieser Art nicht grundsätzlich vorhersehbar sind, und sich z. B. auch direkt auf Dateninhalte und Metadaten der Quelle beziehen können, dürfen sie nicht fest im Kern der Auswertungsalgorithmen verankert sein, sondern müssen zur Laufzeit eingelesen und angewendet werden. Um die Anpassung dieser Regeln zu erleichtern, sollten sie in einer an die Aussagenlogik angelehnten formalen Sprache formuliert werden, die auch die Implementierung einer Benutzerschnittstelle zur Wartung dieser Regel erleichtert. Die Programmiersprache Prolog erfüllt diese Anforderungen und wird von uns zur weiteren Beschreibung des Systems benutzt werden. Für die Implementierung kommen aber auch andere Sprachen in Frage und es ist alternativ auch eine Entwicklung auf Basis einer komplexen Konfigurationsdatei denkbar, aus der Parameter beim Applikationsaufruf übermittelt werden. Marc Geoffroy, Anton Güntsch & Walter G.
Berendsohn __________________________________________________________________________
MoreTax
(Modellierung von regelbasierten Funktionalitäten) ist ein vom Projektleiter: Walter
Berendsohn |
||||||||||
Diese Seite wurde zuletzt am 19-06-2002 geändert
© Freie Universität
Berlin, Botanischer Garten und Botanisches Museum Berlin-Dahlem,
Seitenverantwortlicher / Page editor: M.
Geoffroy.
BGBM Impressum / Imprint
