Forum europäischer Spinnentiere
Projekte (Projects) => Weitere Projekte (more projects) => Entwicklung: Interaktives Bestimmungssystem (Ideas of an interactive determination system) => Thema gestartet von: Arno Grabolle am 2014-09-20 11:49:15
-
Wir haben über das Thema schon mehrfach diskutiert. Ich muss es aber mal wieder ansprechen: Ich finde, wir brauchen ein interaktives Bestimmungsmodul fürs Wiki, auch auf Gattungsebene.
Am Beispiel der Gattung Xysticus wird mir immer wieder bewusst, wo die Grenzen des klassischen Bestimmungsschlüssels liegen und die Uni Bern zeigt auf ihren Seiten das gleiche Problem auf: gut bekannte mitteleuropäische Arten werden vom Schlüssel abgedeckt, Südeuropäer am Ende nur noch aufgezählt.
In den Meeralpen fand ich jetzt X. gallicus, die äußerlich (einschließlich Epigyne) aussieht wie unsere X. kochi. Erst als ich die Vulva präpariert hatte und in der Liste der Uni Bern weiter nach unten scrollte entdeckte ich zufällig eine noch viel passendere Art.
Wenn ich X. gallicus jetzt ins Wiki einpflege (war ja schon mit einigen Abbildungen drin), müsste sie auch im Schlüssel auftauchen, in den Nennungen der „ähnlichen Arten“ usw. Und wer weiß, wie viele Arten der X. cristatus-Gruppe da noch herumschwirren. Das hat irgendwann niemand mehr unter Kontrolle.
Mit so einem einfachen interaktiven Modul (z.B. hier nur für alle Xysticus-Arten eingesetzt) könnte man mit ein paar Merkmalen, die man abfragt ganz schnell und relativ sicher die Arten eingrenzen, die man sich anschauen muss. Allein das Land, in dem die Art gefunden wurde reicht ja manchmal schon aus. Und die 5 bis 8 Merkmale, die man pro Art in das Modul einpflegen müsste, könnte jeder beim Erstellen eines neuen Artartikels schnell mit angeben und sofort wäre die Art mit der Bestimmungshilfe auffindbar.
Den Schlüssel muss ein Experte für die jeweilige Gattung umständlich anpassen bzw. in Teilen neu bauen, weil bestimmte sichere Merkmale mit der Erweiterung um ein-zwei Arten evtl. wieder ganz anders bewertet werden müssen.
Arno
-
Hallo Arno,
natürlich wäre es toll einen interaktiven Schlüssel zu haben, mit dem man schnell und sicher zum richtigen Ziel kommt.
Aber wer von uns hat das im Kreuz, so einen zu erstellen?
Mit so einem einfachen interaktiven Modul.....
Einfach ist der wohl nicht, oder?
Den Schlüssel muss ein Experte für die jeweilige Gattung umständlich anpassen bzw. in Teilen neu bauen, weil bestimmte sichere Merkmale mit der Erweiterung um ein-zwei Arten evtl. wieder ganz anders bewertet werden müssen.
Du meinst damit die vorhandenen Schlüssel bei uns? Wie genau stellst Du Dir denn die einfachere Lösung vor? Und könntest Du das federführend übernehmen?
Der Stäubli-Schlüssel ist ja so ein Schlüssel, wo man Kriterien in einer Datenbank hinterlegt - aber er ist alles andere als einfach und nicht wirklich sicher.
liebe Grüße
Eveline
-
Ich arbeite mit dem Stäubli-Modul gerne und gut. Die Linyphiiden sind ja nun auch der Worst Case. Bei anderen Familien oder Gattungen ist das wesentlich weniger komplex.
Ich stelle mir eine Datenbank-Tabelle vor, in der zu jeder Art einer Gattung eine handvoll Werte existieren. Je nach Gattung muss man wahrscheinlich andere Werte definieren. Ein Standardwert könnte das Land sein, in dem die Art gefunden worden ist. Dann könnten das Maße sein oder Farben oder bestimmte Muster, Bestachelungen bis hin zu Epigynen-typusen oder ähnlichem.
Dann stelle ich mir auf der anderen Seite eine Eingabemaske vor, auf der ich die Werte eingeben kann, einige oder alle und das Ergebnis ist eine mehr oder weniger lange Liste mit Arten, die zu meinen Kriterien passen.
Damit kann man sicher nicht so genau auf die detaillierten Unterschiede bestimmter nahe verwandter Arten eingehen – nicht bei allen gattungen würd so etwas Sinn haben – aber es ist einfach schnell und effektiv herzustellen und in Zukunft immer weiter zu pflegen und auszubauen. Sind die Werte für eine Gattung erst mal definiert, kann jeder beim Neuanlegen einer Art die Werte eingeben, oder man gibt sie in einem Rutsch aus der Literatur heraus ein.
Ich denke jetzt nicht an einen interaktiven Schlüssel für alle Spinnen. Es soll nur in großen, unübersichtlichen Gattungen helfen, die Auswahl einzuschränken.
Vielleicht kann man es auch wie Anna für ganze Familien anlegen und die Gattungsebene unbeachtet lassen.
Etwas, dass jeder bedienen kann und das überhaupt „etwas“ ist. Denn sonst haben wir nie Bestimmungshilfen. Für alle Familien und Gattungen dichitome Schlüssel anzulegen, wäre noch viel aufwendiger und aus meiner Sicht unrealistisch.
Arno
-
Ein interaktiver Schlüssel ist bisher ein Traum geblieben. Alle versuchsweisen Ansätze sind bis dato gescheitert, weil es so viele Unsicherheitsfaktoren gibt. Begriffe, die klar erscheinen, erweisen sich im Einzelfall als unscharf abzugrenzen (z. B. das Merkmal "Beine geringelt"). Man müsste wahrscheinlich mit unscharfer Logik (fuzzy logic) arbeiten. Bis dato habe ich keine Idee, aber ich habe mich auch lange nicht mehr damit beschäftigt. Ich stelle mir Merkmals-Wolken vor, die mehr oder weniger gut zur einen oder anderen Vorlage passen. PHP stellt dafür Komponenten bereit.
Merkmals-Wolken
Das System soll herausfinden, welche Arten am ehesten auf die angegebenen Merkmale passen könnten. Dann läuft man nicht gleich in die Irre wie beim Stäubli-Schlüssel, wenn eine Angabe mal nicht ganz exakt ist. Verschieden Vorschläge können graduiert in % angezeigt werden.
Umsetzung
Wenn Verbreitungsdaten einbezogen werden sollen, dann bestehen zwei Probleme:
1. technisches Problem (lösbar):
Es muss auf die Verbreitungsdaten des Wikis zugegriffen werden (Datenbank), damit hier kein Pflegeaufwand aufläuft
2. Logisches Problem:
Wenn unsere Verbreitungsdaten unvollständig sind, leidet darunter der Schlüssel. A. Hänggi hat aber schon angesprochen, dass in diesem Punkt langfristig die Datenbestände des Wikis mit dem Stand der Seite der Uni Bern synchronisiert werden muss. Dies ist also wahrscheinlich auch ein lösbares Problem.
Wenn wir einen interaktiven Schlüssel konzipieren, sollte er nicht die Defizite des Linyphiidenschlüssels haben (z. B. starre ja/nein-Abgrenzung; die Notwendigket einer unscharfen Logik nannte ich ja schon). Und es sollte kein Java dafür notwendig sein, denn das ist einerseits überflüssig und birgt andererseits weitere Hürden einschließlich Sichereitslücken.
Die Idee, punktuelle Schlüssel anzubieten, ist gut. Anderes ist wahrscheinlich auch nicht umsetzbar (Stichwort persönliche Leistungsfähigkeit und Ressourcen). Man kann ja mit wenigen Schlüsseln experimentell beginnen und mal schauen, wie es läuft.
Mache doch mal einen Anfang mit Xysticus. Welche Merkmale könnte/sollte man katalogisieren und in welcher Weise. Erst mal nur auf Textbasis.
Martin
-
Ich denke jetzt nicht an einen interaktiven Schlüssel für alle Spinnen. Es soll nur in großen, unübersichtlichen Gattungen helfen, die Auswahl einzuschränken.
Aha, da hatte ich Dich schon mal missverstanden. Auf Gattungsebene klingt schon viel besser.
Ich meine wie Martin, dass etwas Kleines eher zu realisieren ist. Man könnte mit einer Gattung anfangen, die wir (ihr) gut kennen/kennt.
Das Festlegen von Kriterien ist sicher heikel, da hat Martin Recht, aber wenn es eine Tabellenlösung ist, kann man da ja auch gut korrigierend/verbessernd eingreifen.
Insgesamt bleibt es aber ein anspruchsvolles Projekt, klingt aber auch sehr spannend!
Wie könnte man denn beginnen? Hier eine Gattung wählen und dann die einzelne Punkte, wie Felder und Kriterienwerte diskutieren und in einem anderen Post die technische Lösung erarbeiten?
Wer würde denn mitmachen?
Fachlich tauge ich nicht viel, aber bei der Datenbanklösung wäre ich dabei. PHP kann ich nicht. Naja, einpflegen kann ich natürlich auch.
liebe Grüße
Eveline
-
Wer würde denn mitmachen?
Eveline, Du machst mit! ;-)
Du konzipierst das Datenbankmodul und die DB-Abfragen, damit das Hand und Fuß hat. Ich bastele alles, das mit PHP zu tun hat. Das Frotend kann, sofern es die Testphase überstanden hat, Arno gestalten.
Als Datenbasis stelle ich mir Merkmals-Paare vor; das ist beim Stäubli-Schlüssel im Prinzip nicht anders. Nur dass bei Stäubli die Wertepaare strikt verknüpft sind.
Ich kann mir vorstellen, dass es sinnvoll ist, dass als Merkmal nicht nur Text, sondern auch Grafiken verknüpft werden können. Da ist schon die DB-Expertin gefragt, wie man das am besten Umsetzt (Feld: infotyp:char(1) – t = Text, b = Bild)?
Opisthosomafarbe: baun: X. cristatus
Opisthosomafarbe: grau: X. cristatus
...
Wahrscheinlich sind weitere Daten (z. B. Erläuterung, Hinweis, ...) pro Werte-'Paar' sinnvoll. Vielleicht kann man auch den Wert eines Merkmals gewichten oder besser das Programm gewichtet es selbsttätig (wie viele relevant Arten haben dieses Merkmal auch?).
Wenn man nun alle passenden Merkmale für X. cristatus eingegeben, aber nur bei der Opisthosomafarbe 'rötlich' eingegeben hat (z. B. weil der eigene Monitor einen Farbstich hat), dann wird noch immer X. cristatus angeboten. Nur mit einer Trefferwahrscheinlichkeit von vielleicht 95 %, wärend andere Arten gar nicht oder mit noch geringerer Wahrscheinlichkeit angegeben werden.
Das alles steht und fällt allerdings mit den Daten, die zu den relvanten Daten Arten1 (!!!) vorhanden sind. Selbst den Seiten der Uni Bern fehlen viele Informationen und auch Genital-Abbildungen. Das Bestimmungssystem muss entsprechende Hinweise geben können. Für 50 % der bei der Uni Bern gelisteten Xyticus gibt es keine Genitalbilder (http://www.araneae.unibe.ch/specieskey/360/Xysticus#843).
Martin
1: nachträglich korrigiert
-
Eveline, Du machst mit! ;-)
Ups. Aber was dachtest Du denn - ist doch was mit Datenbank .... Kann doch sonst nichts, heul...
So ganz spontan dachte ich eher an soetwas (mal sehen ob ich das hier malen kann).
| Farbe Opi | Größe | Geschlecht |
| erstmal leer | erstmal leer | erstmal leer |
Darunter zeigt eine Liste alle Arten an:
.....
Xysticus cristatus
Xysticus kochi
.....
Der Anwender wählt z.B. nun am Feld Farbe aus einer fixen Liste, die wir zur Verfügung stellen, einen Wert aus. Z.B. bräunlich. Die Liste unten reagiert sofort und zeigt nur Daten die diesem Wert entsprechen. Der Anwender sieht also, wie die Liste kürzer wird. Die Auswahlliste kann natürlich auch Genitalfotos enthalten. Wie mySQL damit umgeht, weiß ich nicht, ist aber egal, weil ich der Art ein Bild über die ID zuordnen würde. Daraus folgt aber, dass bei Auswahl eines Bildes nur noch eine Art angezeigt werden kann! Wie man unscharf filtern kann, weiß ich nicht. (Da überschätzt Du meine Möglichkeiten)
In meinem Ansatz werden alle Kriterien "ernst" genommen. Wer rot sagt und braun meint, bekommt keine braune Lösung, sondern eine rote.
So, das war jetzt aber aus dem Bauch heraus und sicher noch nicht zu Ende gedacht.
liebe Grüße
Eveline
-
Richtig so! Wir fantasieren das erstmal. Danach schauen wir, ob das wirklich umsetzbar ist.
Die Merkmalstabelle sollte das Objekt der Eigenschaften nicht vorgeben. So bleibt die Summe der Merkmale unendlich erweiterbar. Bei Opiliones z. B. 'Mitostom vorhanden': ja|nein, was Xysticus gar nicht hat.
Merkmal: Eigenschaft:Art (im Prinzip)
praktisch wäre so etwas möglich:
Merkmal:Eigenschaft:Art:Hinweis:Erläuterung:ähnliche Arten ...
Die Unschärfe-Geschichte müsste PHP erledigen. Wie konkret, weiß ich noch nicht. Für die vielen Arten, zu denen uns Daten fehlen, muss im Feld 'Eigenschaft' ein '?' stehen können.
Zum Frontend eines Schlüssels muss es auch ein Backend (special pages) geben, wo die Eigenschaften editiert werden können.
Martin
-
Ich denke da mal weiter. Mein erster Ansatz war eine Tabelle, die je Art einen Datensatz hat. Dieser enthält alle Eigenschaften, die diese Art ausmachen. Es kann aber sein, dass eine andere Art ganz die gleichen Eigenschaften hat. Dann erscheinen immer beide, es sei denn wir finden eine Eigenschaft, die beide unterscheidet.
Auch so eine Tabelle ist beliebig erweiterbar, was die Eigenschaften angeht (muss dann halt nachgepflegt werden). Und erstmal wollen wir das ja nur für Gattungen machen. Für Familien verlieren wir zu schnell den Überblick.
Nun muss ich mich aber über die Doktorarbeit meiner Tochter setzen (Korrekturlesen).
Eveline
-
Da habe ich ja was losgetreten ...
Ich hätte es mir so vorgestellt, wie es Eveline beschreibt. Und so ist Annas Schlüssel ja auch konfiguriert. Sie hat den mit diesem Programm („IntKey“?) gebaut. Vielleicht können wir auch damit arbeiten, Ich weiß aber nicht, was man da am Ende herausbekommt.
Komfortabler und langfristiger wäre natürlich eine Lösung, wie sie Martin beschreibt, mit einem Backend auf einer speziellen Unterseite (des Wikis?), in dass eingearbeitet werden kann.
Ja, man würde für eine spezielle Gattung Merkmale heraussuchen (diskutieren) und diese erst mal anlegen. Schön wäre es, wenn man später trotzdem noch mal ein Merkmal hinzufügen könnte. Für eine andere Gattung würde man ganz andere Merkmale festlegen. Was das für Konsequenzen für ein evtl. zukünftiges Gesamt-Bestimmungs-System haben würde, könnte man diskutieren.
Zu Martins Unschärfe: Ich sehe dieses Problem nicht so gravierend. Ich bezweifle, dass man das wirklich braucht und dass es hilfreich wäre. Als Praxisbeispiel kann man wieder Annas Schlüssel heranziehen. Obwohl da inzwischen mehr als 1000 Linyphiiden drin sind bekommt man mit 3 bis 5 Merkmalen schnell eine Liste von ca. 20 Arten und die klickt man locker durch.
Man muss den Umgang mit so einem System etwas erlernen / üben. Man darf nicht erwarten, nach Eingabe aller Werte (Merkmale), die eine richtige Lösung zu erhalten. Ich gehe auch davon aus, dass man nicht alle Werte eingibt, sondern nur die, bei denen man sich sehr sicher ist. So wählt man als Nutzer Merkmale mit absteigender Sicherheit bis die Liste kurz genug ist. Wenn die gesuchte Art nicht in der Auswahl ist, überprüfe ich meine Eingaben noch mal (so mache ich es bei Annas Lyniphiiden-Schüssel. Dann versucht man es irgendwann mal ohne die Angabe der Opisthosoma-Farbe und erkennt, dass zwei Arten mehr in der Liste sind. Und eine der beiden ist es dann vielleicht.
In manchen Fällen müsste man als Nutzer evtl. mehrere Werte für ein Merkmal wählen können oder Bereiche eingeben können. Auf der anderen Seite müsste man die Möglichkeit haben als Admin für eine Art mehrere Werte für ein Merkmal eintragen zu können. Es gibt Arten, die haben manchmal geringelte Beine, manchmal aber nicht. Dann würde man einfach beides angeben und die Art erschiene dann in beiden Fällen in der Auswahl.
Konkrete Bilder würde ich nicht auswählen lassen. Ich kann mir aber vorstellen, dass es schematische Darstellungen von z.B. Epigynen-Formen gibt. Das wären dann aber eher sowas wie drei Typen, die man als Bildchen gezeigt bekommt und man muss ein Häkchen hinter einen machen.
Weiterhin würde man Bilder zur Erklärung bestimmter anatomischer Details benötigen. Die würden aber im Frontend eher neben dem Text stehen, um das beschriebene zu illustrieren. Das finde ich sehr wichtig, das fehlt im Linyphiiden-Schlüssel.
Ich kann das morgen mal probieren/beginnen für die Gattung Xysticus. Eine Merkmalstabelle anlegen und eine Skizze vom Frontend. Aus einer Vorstellung der Benutzung heraus lassen sich meines Erachtens leicht Kriterien für eine Umsetzung ableiten.
Arno
-
Da habe ich ja was losgetreten ...
Du hast einen schlafenden Riesen geweckt.
Programm („IntKey“?) gebaut. Vielleicht können wir auch damit arbeiten, Ich weiß aber nicht, was man da am Ende herausbekommt.
IntKey sollten wir aus mehreren Gründe nicht nehmen:
1. Es läuft unter Java (nicht zu verwechseln mit JavaScript!)
1.1 Java birgt immer wieder Sicherheitslücken, die Ausführung im Browser wird darum immer restriktiver eingeschränkt.
1.2 Man benötigt ein Plugin (mit meinem Linux-Rechner kann ich den Schlüssel beispielsweise nicht aufrufen, da ich ein entsprechendes Plugin von Hand installieren müsste)
2. Es ist funktionell eingeschränkt (primitiv)
3. Es ermöglicht nicht das Arbeiten mit Grafiken
Alles, das das Programm macht, kann man auch ohne Java lösen.
Komfortabler und langfristiger wäre natürlich eine Lösung, wie sie Martin beschreibt, mit einem Backend auf einer speziellen Unterseite (des Wikis?), in dass eingearbeitet werden kann.
Genau: Spezialseiten (special pages) (http://wiki.spinnen-forum.de/index.php?title=Spezial:Spezialseiten)
Zum Ausprobieren lassen wir das weg. Das Frotend bleibt primitiv und wird erst aufgehübscht, wenn sich heraus stellt, dass wir das im Wiki wirklich anbieten können.
Ja, man würde für eine spezielle Gattung Merkmale heraussuchen (diskutieren) und diese erst mal anlegen.
Das wird schlussendlich der größte Batzen Arbeit sein.
Zu Martins Unschärfe: Ich sehe dieses Problem nicht so gravierend. Ich bezweifle, dass man das wirklich braucht und dass es hilfreich wäre. Als Praxisbeispiel kann man wieder Annas Schlüssel heranziehen. Obwohl da inzwischen mehr als 1000 Linyphiiden drin sind bekommt man mit 3 bis 5 Merkmalen schnell eine Liste von ca. 20 Arten und die klickt man locker durch.
Ich bestimmt nicht der einzige, bei dem es in den meisten Fällen so aussieht, dass in den verbleibenden 20 Arten die Art, die ich bestimmen will nicht enthalten ist. Nach ein paar Merkmalsänderungen (z. B. ein Merkmal raus, ein anderes rein), erhält man eine ganz andere Schnittmenge möglicher Arten, bei der man aber nicht sicher sein kann, dass die gesuchte Art darunter ist. Das führt zu Frustration. Mit dem bloßen Durchblättern von Roberts Linyphenband komme ich in der Regel erheblich schneller zum Ziel.
Der Stäubli-Schlüssel ist damit nur begrenzt brauchbar. Wir müssen diese Diskussion hier aber nicht zu sehr vertiefen. In der Studienphase des Systems probieren wir einfach beide Ansätze und vielleicht weitere aus. Möglicherweise kann man auch Konzepte mischen oder variieren.
Auf der anderen Seite müsste man die Möglichkeit haben als Admin für eine Art mehrere Werte für ein Merkmal eintragen zu können. Es gibt Arten, die haben manchmal geringelte Beine, manchmal aber nicht.
Ganz zu schweigen von unterschiedlichen Mustern und Farben ...
Konkrete Bilder würde ich nicht auswählen lassen. Ich kann mir aber vorstellen, dass es schematische Darstellungen von z.B.
Es würde mir sehr helfen, mit schematisierten Epigynen- oder Pedipalpen-Formen die Suche eingrenzen zu können. Ich hatte mal vorgeschlagen, im Stäubli-Schlüssel die Möglichkeit zu haben, die Leptyphantiformen ausschließen zu können, aber das wurde abgelehnt. Damit bleibt dieser Schlüssel ein Werkzeug für Tüftler.
Epigynen-Formen gibt. Das wären dann aber eher sowas wie drei Typen, die man als Bildchen gezeigt bekommt und man muss ein Häkchen hinter einen machen.
Häkchen ist gut! So kann man mehrere wählen, wenn es einem nicht gelingt, die vorliegende Epigyne sicher zu kategorisieren. Damit wird immer noch ein Teil der potentiellen Kandidaten ausgeschlossen. Hier ist wieder Unschärfe im Spiel.
Weiterhin würde man Bilder zur Erklärung bestimmter anatomischer Details benötigen.
Und so weiter ...
Die würden aber im Frontend eher neben dem Text stehen, um das beschriebene zu illustrieren. Das finde ich sehr wichtig, das fehlt im Linyphiiden-Schlüssel.
Das meinte ich ja damit, dass einem mit Arten verknüpften Werte'paar' noch weitere Inhalte wie Erläuterungen oder Hinweise beigestellt werden sollten. Im Gegensatz zum Stäubli-Schlüssel sollen mit unserem System nicht nur Profis arbeiten können.
Ich kann das morgen mal probieren/beginnen für die Gattung Xysticus. Eine Merkmalstabelle anlegen und eine Skizze vom Frontend. Aus einer Vorstellung der Benutzung heraus lassen sich meines Erachtens leicht Kriterien für eine Umsetzung ableiten.
Das Frontend ist nicht wichtig. Darüber können wir uns Gedanken machen, wenn der Schlüssel funktioniert. Zu aller erst müssen wir anhand eines Beispiels mit Daten spielen können. Alles andere kommt später.
Wir müssen zuerst die geeigneten Datenstukturen finden, dann verschiedene Modi der Auswertung testen. Ein hübsches Frontend kommt später.
Martin
-
Mal zur Datenstruktur.
Ich würde es mit Hilfe von Zuordnungstabellen lösen, da brauch man nicht für jede Gattung (mit unterschiedlichen Merkmalen) eine extra Tabelle.
Mal sehen, ob ich das verdeutlichen kann:
Tabelle für Definition der verschiedenen Merkmale innerhalb der Gattungen:
- GattundsID (int)
- Gattung (varchar)
- Anzahl_Genutzte_Merkmale (int)
- Merkmals_DefinitionsText1 (varchar)
- Merkmals_DefinitionsTyp1 (int)
- Merkmals_DefinitionsText2 (varchar)
- Merkmals_DefinitionsTyp2 (int)
...
- Merkmals_DefinitionsTextX (varchar)
- Merkmals_DefinitionsTypX (int)
Tabelle mit den eigentlichen Eigenschaften je Art:
- Art (int)
- Gattungs_ID (int) -> Verknüpfung mit 1.Tabelle zum "Auflösen" der Merkmale
- Merkmal1 (Eingabe je nach Typ)
- Merkmal2 (Eingabe je nach Typ)
....
- MerkmalX (Eingabe je nach Typ)
Man wäre dann sehr flexibel und könnte pro Gattung beliebig viele Merkmale
definieren. Außerdem können diese dann für jede Gattung komplett anders aussehen,
ohne dabei jedesmal das Frontend oder die Abfragen ändern zu müssen. Es müssen
nur die verschiedenen Merkmalsdefinitionstypen vorher besprochen werden:
- Bild (z.B. für Genitalabbildungen oder Augenanordnungen)
- ja/nein
- Zahl (z.B. für Anzahl von Stacheln)
- Auswahl (z.B. für Farben)
- Text
Ich hoffe, das war soweit verständlich - auch für nicht Datenbank-Junkies wie Eveline.
Gruß
Micha
-
Das habe sogar ich verstanden. Klingt gut. Vielleicht ergänzend in der ersten Tabelle:
- Merkmals_DefinitionsBild1 (?) ... für erläuternde Grafiken.
Martin sprach ganz oben die Probleme mit den Verbreitungsdaten an. Zum Inhaltlichen Argument: natürlich sind die Verbreitungsdaten nie vollständig. Auch nach einer Synchronisierung aller in der Literatur und im Web verfügbarer Daten würde es noch Lücken geben. Es wäre schade wenn nicht – dann könnte man nie wieder einen Neunachweis für ein Land machen. Trotzdem hilft dieses Merkmal bei der Eingrenzung er Arten-Liste in 95 % der Fälle, v.a. bei Standardarten. Dass so ein Wert eine gewisse „Gefahr“ für mein Ergebnis birgt, sollte jedem bewusst sein, bzw. würde man einen entsprechenden Hinweis im Frontend des Schlüssels geben.
Zum technischen Argument kann ich kaum etwas sagen. Natürlich sollten diese Daten aus der DB des Wikis geholt werden. Ob und wie das geht, müsstet ihr ausprobieren.
Arno
-
Eine Anmerkung zu Martins Unschärfe: wenn sogar Experten wie Martin mit dem strikten Ansatz des Stäubli-Schlüssels Probleme haben, sollte man das bei der Konstruktion eines neuen Schlüssels schon berücksichtigen. Es gibt ja viele Gründe, warum die Auswahl des Benutzers nicht mit der Angabe im Schlüssel übereinstimmt: beschädigte Exemplare (z.B. Wiehle-Formel), Missverstehen der Merkmalsdefinition, ungewöhnliche Exemplare, Fehleingaben...
Wenn man das bereits beim Aufbau des Schlüssels berücksichtigt, dann gibt es eine ganz einfache Lösung, ohne Fuzzy-Logic, dafür mit Bayes-Statistik:
Im klassischen (Stäubli) Schlüssel wird für jedes Merkmal gefragt: stimmt die Auswahl des Benutzers mit der Beschreibung in der Datenbank überein (Wert=1) oder nicht (Wert=0). Die Werte für alle Merkmale werden dann multipliziert, und wenn eines der Merkmale nicht passt, ist das Gesamtergebnis 0, und die Art wird verworfen.
Im Bayes-Ansatz berechnet man ebenfalls so ein Produkt, aber es wird für jede Art jede Merkmalsausprägung erlaubt, jedoch mit unterschiedlicher Wahrscheinlichkeit, also mit Werten zwischen 0 und 1. Beispiele: eine Art hat eine prolaterale Borste auf Femur I. Im klassischen Ansatz wäre das kodiert als "Borste ja=1, nein=0", im Bayes-Ansatz z.B. als "Borste ja=0.99, nein=0.01"; die genauen Werte sind subjektiv und hängen davon ab, wie hoch man die Fehlerrate einschätzt, der Ansatz ist aber robust gegenüber kleinen Variationen. Für Größenangaben ließe sich das automatisieren: wenn man eine Normalverteilung der Maße um einen Mittelwert annimmt und die Varianz schätzen kann, dann lässt sich die Wahrscheinlichkeit ungewöhnlicher Maße berechnen.
Das Ergebnis der Multiplikation ist dann immer ein Wert zwischen 0 und 1, nach dem sich die Liste sortieren lässt. Es wird jedoch keine Art verworfen (der Wert wird nie gleich 0), d.h. auch wenn man sich mal vertut, rutscht eine Art nur nach hinten, verschwindet aber nicht, und wenn genügend andere charakteristische Merkmale passen, dann kann sie sich auch wieder ganz vorne in der Liste einfinden. (Natürlich kann man auch einen Filter einbauen, der Arten nicht mehr anzeigt, wenn zu viel nicht passt, der Wert also zu klein wird.)
Ein weiterer Vorteil ist, dass sich auf die gleiche Weise auch Häufigkeits-, Habitat- oder Phänologie-Angaben kodieren lassen: man könnte die Liste der Arten nach allgemeiner Häufigkeit im Fundland vorsortieren (ohne weitere Angaben ist die häufigste Art die wahrscheinlichste), und man kann den Fundzeitpunkt als Merkmal kodieren; z.B. eine winteraktive Art wäre vielleicht "Winter = 0.8, Frühjahr = 0.1, Sommer = 0.05, Herbst = 0.05". Natürlich ließe sich das beliebig verfeinern, z.B. mit den Fundzeitstatistiken des SRS nach Geschlecht und Monat...
Für einen ersten Test könnte man einfach eine allgemeine Fehlerrate annehmen, und für jedes nicht passende Merkmal den gleichen kleinen Wert (z.B. 0.001) verwenden. Langfristig wäre es aber natürlich interessanter, wenn man Expertenwissen verwendet, um zu beurteilen welche Fehler wie wahrscheinlich sind. Beispiel Wiehle-Formel: wenn eine Art 2-2-2-2 haben sollte, dann ist 2-2-2-1 schon mal möglich, 0-0-0-0 aber eher unwahrscheinlich; aber bei einer Art, wo die Stacheln besondern kurz und zart sind, und leicht übersehen werden können, wäre der Fehler trotzdem recht häufig, und das könnte bei der Wahl der Wahrscheinlichkeiten berücksichtigt werden.
Ich bin kein Experte für Datenbanken und kann nicht sicher einschätzen, wie einfach sich das umsetzen lässt, aber aus "Laiensicht" scheint mir der zusätzliche Aufwand überschaubar, und es wäre ein großer Fortschritt gegenüber klassischen Schlüsseln.
Beste Grüße,
Rainer
-
- Merkmals_DefinitionsBild1 (?) ... für erläuternde Grafiken.
Ich würde das eher für jedes mögliche Kriterium zulassen und dann einfach
in Tabelle 2 zu jeden Merkmal noch eine Bild-Spalte vorsehen. In der Definitions-
tabelle für die Kriterien ist das m.E. nicht notwendig. Dann wäre der Def.Typ
Bild sogar überflüssig.
Rainers Prozente Logik ist ja nur eine Erweiterung des Ausschlusses mittels 0 bzw.1
und klingt auf dem Papier erst einmal recht simple. Wie man so etwas allerdings
möglichst flexibel in einer DB unterbringen soll, wird sicherlich das größere Problem
darstellen. Die einzelnen Kriterien unterschiedlich zu wichten sollte m.E. aber auf
jeden Fall relativ einfach möglich sein (dann wäre fürs erste nur ne weitere Spalte
pro Merkmal in der Definitionstabelle für die einzelnen Merkmal mit der prozentualen
Wichtung als Inhalt fällig).
Gruß
Micha
-
Interessanter Ansatz Rainer,
Ich möchte aber noch mal kurz den klassischen, harten Schlüssel (Beislpie Sträubli) verteidigen. Ich habe das Gefühl, dass der Schlüssel von vielen Leuten schon nach einer oberflächlichen Betrachtung beurteilt wird und nicht nach einer längeren Nutzung in der Praxis. Meine Erfahrungen damit waren ähnlich. Meine ersten Versuche waren entweder erstaunlich präziese (drei Arten nach drei Merkmalen -> Bestimmung nach 2 Minuten) oder deprimierend unbefriedigend (lange herumprobieren, bis herauskam, dass mein Exemplar zu viel gefressen hatte und deshalb zwei zehntel mm zu groß war).
Mit der Zeit lernt man das einzuschätzen. Wenn meine Art in der Liste nicht zu finden ist, variiere ich als erstes die Prosomalänge. Diesen Tip gibt Anna auch jedem, der danach fragt. Wenn der Schlüssel noch ein paar Verbesserungsphasen durchlaufen hätte (das ist wohl nur an den Finanzen gescheitert), würde das bei der Abfrage der KL als Hinweistext stehen.
Nun frage ich mich, ob solch ein „hartes“ System nicht für den Nutzer am Ende transparenter ist, als ein weichere, wie von Rainer angedeutet. Das ist dann wie bei einer Google-Suche, in der oft Dinge auftauchen, die ich nicht brauchen kann, weil Google „mitdenkt“.
Ich fürchte auch ein wenig den Aufwand der Einschätzung der Wahrscheinlichkeiten. Allein die relevanten Merkmale für eine Gattung zu bestimmen wird eine Herausforderung.
Die Menge der Ergebnisse wird wahrscheinlich recht groß bleiben. Und zum Schluss klicke ich doch alle durch. Ich kann als Nutzer nicht einschätzen, ob ich mein Exemplar vielleicht einfach nur zufällig im falschen Lebensraum gefunden habe und die Art deshalb ganz am End der Liste gelandet ist.
Auch weiß ich nicht, wie solch ein weiches System reagiert, wenn ich nicht alle Merkmale eingebe. Auch die Merkmalseingabe mache ich als Nutzer sehr gezielt. Wenn ich eine Krabbenspinne im meiner Wohnung finde, lasse ich das Merkmal „Lebensraum“ mal lieber weg, weil ich annehme, dass sie nur eingewandert ist und nicht wirklich synanthrop. Ich kann aber auch mal einen Durchlauf mit einem prognostizierten Lebensraum machen (ich glaube, die Art schon mal auf einer Wiese gesehen zu haben). So probiere ich herum und bekomme ein Gefühl für das System.
Sicher, all das ist auch mit weicheren Werten möglich. Aber ist das noch kontrollierbar?
Bei einigen Merkmalen kann ich mir jedoch vorstellen, dass weichere Codierungen helfen können. Bei der Einschätzung von Mustern oder Farben z.B. die bei 5% der Population auch mal anders sein können.
---
Für die Nutzung in der Praxis wäre es hilfreich, wenn man Arten aus der Liste ausschließen könnte. Wenn ich im ersten Durchlauf 10 Arten angezeigt bekomme und durchklicke, kann ich die, die auf keinen Fall passen, einfach rauskicken. Die würden dann in weiteren Durchläufen nicht mehr berücksichtigt und ich hätte bei einem weiteren Durchlauf nur noch sehr wenige Arten in der Auswahl.
Arno
-
Hallo Arno,
Ich fürchte auch ein wenig den Aufwand der Einschätzung der Wahrscheinlichkeiten. Allein die relevanten Merkmale für eine Gattung zu bestimmen wird eine Herausforderung.
Ich denke, den Aufwand könnte man selbst bestimmen. Als Default könnte man einfach überall wo in der klassischen Variante eine 0 steht, einen kleinen Wert (z.B. 0.0001) eintragen; das könnte sogar automatisch geschehen. Das Ergebnis ist dann sehr ähnlich, wie beim klassischen "harten" Schlüssel, aber das System wäre flexibler (wenn sich die Datenbank-Herausforderung lösen lässt): mit der Zeit könnte man dann Erfahrungs- und Expertenwissen einbauen. Ich denke, wenn man die Merkmale entschieden hat, dann ist das ein relativ kleiner Zusatzaufwand (vor allem wenn man erstmal ein Gefühl dafür entwickelt hat, was sinnvolle Erwartungswerte sind).
Die Menge der Ergebnisse wird wahrscheinlich recht groß bleiben. Und zum Schluss klicke ich doch alle durch.
Das hängt davon ab, wie/ob man die Ergebnisse filtert. Arten, bei denen mehrere Merkmale überhaupt nicht passen, braucht man ja nicht mehr anzeigen. Je nach Einstellung kann die Liste also genauso kurz werden, wie im "harten" Schlüssel.
Ich kann als Nutzer nicht einschätzen, ob ich mein Exemplar vielleicht einfach nur zufällig im falschen Lebensraum gefunden habe und die Art deshalb ganz am Ende der Liste gelandet ist.
Das stimmt; aber wenn die Kodierung vernünftig gewählt ist, dann rechnet das System ja mit der Wahrscheinlichkeit, Tiere im "falschen" Lebensraum zu finden; d.h. wenn die übrigen Merkmale passen, dann landet so eine Art nicht ganz am Ende (während sie bei harter Kodierung sofort rausgeschmissen würden). Die Theorie hinter dem Bayes-Ansatz ist es, den "natürlichen" Vorgang der rationalen Entscheidungsfindung abzubilden; die Ergebnisse sollten also recht intuitiv sein.
Auch weiß ich nicht, wie solch ein weiches System reagiert, wenn ich nicht alle Merkmale eingebe.
Darauf sollte das System gar nicht reagieren, d.h. nicht eingegebene Merkmale haben keinen Einfluss auf die Sortierung der Arten. Das sollte eigentlich genauso sein, wie im "harten" System.
Wenn ich eine Krabbenspinne im meiner Wohnung finde, lasse ich das Merkmal „Lebensraum“ mal lieber weg, weil ich annehme, dass sie nur eingewandert ist und nicht wirklich synanthrop. Ich kann aber auch mal einen Durchlauf mit einem prognostizierten Lebensraum machen (ich glaube, die Art schon mal auf einer Wiese gesehen zu haben). So probiere ich herum und bekomme ein Gefühl für das System.
Sicher, all das ist auch mit weicheren Werten möglich. Aber ist das noch kontrollierbar?
Ich denke, das ginge schon. Und der Vorteil wäre, dass ein "weiches" System genau solche Formen von Expertenwissen (welche Arten kann man wo und wann erwarten?) einbauen kann und damit auch unerfahrenen Benutzern zugänglich macht (auch wenn die nicht gezeigt bekommen, welche Argumentation im Einzelfall dahintersteckt).
Bei einigen Merkmalen kann ich mir jedoch vorstellen, dass weichere Codierungen helfen können. Bei der Einschätzung von Mustern oder Farben z.B. die bei 5% der Population auch mal anders sein können.
Und für Maßangaben, die immer schwanken werden (durch Messungenauigkeit und natürliche Variation; damit ließen sich sicher 80% der Stäubli-Probleme beheben). Und für Merkmale, bei denen sich auch erfahrenere Nutzer regelmäßig vertun (Augen prokurv/rekurv; Fovea deutlich/fehlend...) oder die leicht beschädigt werden (Wiehle-Formel).
Beste Grüße,
Rainer
-
Ich will gleich noch ins Gelände und habe daher Eure Statements nur quer gelesen. Die Tabellenstruktur von Michael kommt mir etwas kompliziert vor (ich schau es mir später nochmal genauer an).
Vom Bayesfilter habe ich schon mal gehört. In PHP gibt es viele bereits eingebaute Funktionen; eine, die für uns interessant sein könnte, wäre die Funktion similar_text() (http://php.net/manual/de/function.similar-text.php), welche den Unterschied zweier Texte in % angibt. Ich sehe hier die Möglichkeit, Ungenauigkeiten in % anzuheben (oben wurde das Beispiel 'falscher Lebensraum' diskutiert). Ich habe gar nicht so selten Arten in 'falschen' Lebensräumen gefunden (Arctosa perita im Moor, bei benachbartem Sandhabitat u.s.w.). Der Lebensraum sollte nicht so stark bewertet werden, wie ein Genitalmerkmal. Ebenso ist Araneus diadematus meist bräunlich, aber manchmal auch knallrot...
Ich glaube eher nicht, dass ich heute noch dazu komme, eine Testkomponente zu basteln. Ich warte mal Arnos Xysticus-Datensätze ab.
Martin
-
Ich habe mal einen Anfang gemacht und Merkmale herausgesucht, die mir relevant und verifizierbar erscheinen (Gattung Xysticus). Es sind gar nicht so viele geworden. Wie weit man damit kommt, muss man eben mal ausprobieren.
Der Aufwand ist doch höher als ich dachte. Es müssen doch einige Grafiken hergestellt werden.
Beim konkreten Zusammensuchen der Merkmale hatte ich das Gefühl, dass Rainers Vorschlag doch ganz hilfreich sein könnte. Manche Merkmale lassen sich bei bestimmten Arten sehr eindeutig festlegen, bei anderen schwanken sie oder sind unklar. Dann wäre es schön, wenn man „weicher“ auswerten könnte.
Die Datenbank-Experten müssten mir dann mal sagen, wie ich die einzelnen Merkmalsausprägungen der einzelnen Arten codieren soll, in welcher Form das für eine Testdatenbank am besten zu übernehmen wäre. Dann würde ich das mal für die Arten machen, die wir schon mit Bild im Wiki haben (immerhin schon 25).
Arno
Geschlecht
- f
- m
Land
- Liste mit allen europäischen Ländern (aus Datenbank)
KL
- Wertebereich: kleinste Länge – größte Länge
Grundfarbe/Gesamtfarbe (cverschiedene Typen mit Bildern + Erläuterungen)
- insgesamt sehr dunkel ohne kontrastreiche Zeichnung
- insgesamt hell gelblich braun, abgesehen von Prosoma-Längsstreifen ohne kontrastreiche Zeichnung
Fundort/Lebensraum (verschiedene Lebensraumtypen, laienverständlich)
- Laubbäume/-büsche
- Nadelbäume
- Wiese
- Trockenrasen + ähnliche steinige Habitate, am Boden
- Sanddünen
- auf Stauden und Blüten
- feuchte, nasse Wiese, Seggen in Sümpfen etc.
Prosoma: Zeichnung (verschiedene Typen mit Bildern + Erläuterungen)
- einheitlich dunkel, Mitte meist etwas aufgehellt, Kopfdreieck undeutlich, verschmiltzt mit dunklen Seiten
- hell mit dunklen Seiten, diese können hinten etwas gegabelt sein
- hell mit zwei deutlichen dunklen Längsstreifen und meist auch dunklen Seitenstreifen
Opisthosoma: Zeichnung (verschiedene Typen mit Bildern + Erläuterungen)
- dunkel, verwaschen fleckig
- hell mit scharf abgegrenzten dunklem Folium, in diesem helles Mittelband und Querstreifen
- verwaschenes, weniger kontrastreich abgesetztes Folium, in diesem helle Zeichnung
Vorderbeine: Zeichnung (verschiedene Typen mit Bildern + Erläuterungen)
- mehr oder weniger gleichmäßig dunkel gefleckt, mehr dunkle Anteile als helle
- hell mit feiner Punktierung
- hell mit feinen Punkten und einigen größeren Flecken, mehr helle Anteile als dunkle
- hell mit feinen Punkten, einigen größeren Flecken und deutlichen dunklen Längsstreifen
- relativ dunkel, distal heller, Tibia mit drei Ringen: dunkel-hell-dunkel
Epigyne: Form (verschiedene Typen mit Bildern + Erläuterungen)
- zwei deutlich getrennte Gruben
- Trennung nur im vorderen Teil der Epigyne, bzw. scapusartiger Vorsprung der dem Hinterand entspringt
- eine Grube mit einfacher Form (rund bis dreieckig bis eckig)
- eine Grube mit Ausbuchtungen
Pedipalpus: mediane Bulbusapophyse (verschiedene Typen mit Bildern + Erläuterungen)
- keine mediale Bulbusapophysen
- zwei Apophysen, eine davon Hammerförmig
- zwei Apophysen, sichelförmig zueinander zeigend
- zwei Apophysen, gerade oder löffelförmig
-
Von der notwendigen Datenstruktur habe ich anscheinend eine viel einfachere Vorstellung als Michael:
Tabelle Eigenschaften
Index: int
Sektion: string // Um Merkmale zu gruppieren
Merkmal: string
Mermalstyp: char(1) // t=Text, b= Bild => Merkmal enthält dann Bildname
Merkmalsgewicht: int // Hier können Genitalmerkmale auf eine höhere Ebene gestellt werden als Habitatinfos
Eigenschaft: string
Hinweis: text NULL
Tabelle Arteneigenschaften
id_Eigenschaft int // Verweist auf den Index der Tabelle Eigenschaften
id_art: int // Verweis auf Artentabelle
Geschlecht: char(1) // * = beide Geschlechter; ansosten wie üblich m, f, j
Region-Infos können im Wiki über id_art ermittelt werden.
Egal, ob man nun einen Schlüssel zum Unterscheiden von Gattungen oder Arten baut, greift man im Idealfall auf immer die selben Daten zu, welche sich immer primär auf Arten beziehen. Das heißt, das System muss selbsttätig herausfinden, welche Merkmale allen z. B. Xystikus gemeinsam sind. Dies mindert ganz wesentlich den Wartungsaufwand.
Ich sehe schon, wir benötigen zur Eingabe der Daten ein Backend.
Martin
-
Ups, was macht Ihr denn hier? Auf die Schnelle kriege ich das nicht alles durchgelesen und nachvollzogen. Ich habe jetzt erstmal meiner Tochter meine freie Zeit versprochen (diese Woche). Mal sehen, ob ihr mich anschließend überhaupt noch braucht, oder ob ich schon Daten einpflegen muss, weil alles fertig ist ;).
liebe Grüße
Eveline
-
@Eveline: Dein Part kommt erst, wenn es zur Optimierung einer Lösung kommt. Das ist im Moment nicht wichtig. Wir müssen erst schauen, ob der Traum machbar ist.
Widme Dich in aller Ruhe der Dissertation Deiner Tochter.
Martin
-
Änderung in der Datenstruktur: Das Feld 'Geschlecht' wandert in die Eigenschaften-Tabelle:
Tabelle Eigenschaften BS_ml_Eigenschaften
Index: int
Sektion: string // Um Merkmale zu gruppieren
Merkmal: string
Mermalstyp: char(1) // t=Text, b= Bild => Merkmal enthält dann Bildname
Merkmalsgewicht: int // Hier können Genitalmerkmale auf eine höhere Ebene gestellt werden als Habitatinfos
Eigenschaft: string
Hinweis: text NULL
Geschlecht: char(1) // * = beide Geschlechter; ansosten wie üblich m, f, j
Tabelle Arteneigenschaften BS_ml_Arten
id_Eigenschaft int // Verweist auf den Index der Tabelle Eigenschaften
id_art: int // Verweis auf Artentabelle
Grund: Nur so können in Frontend & Backend geschlechtsspezifische Merkmale angeboten werden.
Hier ein erster Entwurf für ein Backend zur Eingabe von Merkmalen und Artenlisten:
http://media.spinnen-forum.de/merkmalseingabe.html
Hinweis zum Formular:
Die Dropdownliste 'Merkmale' ist leer. In der Praxis sollen diese aus der Datenbank eingelesen werden. Hier in der Forumlarentwicklung besteht aber keine Programmsteuerung. Es ist ein reines html-Formular, das nicht einmal einen html-Header besitzt.
Martin
-
Nun hatte ich ein wenig mehr Muße, mir das Bayes-Prinzip vor Augen zuführen. Das klingt wirklich brauchbar und auch einfach zu realisieren.
Für absolute Merkmale könnte ich mir auch 0 und 1 vorstellen. Beispielsweise beim Geschlecht. Wenn man sich nicht sicher ist, muss man ja kein Geschecht wählen.
(Natürlich kann man auch einen Filter einbauen, der Arten nicht mehr anzeigt, wenn zu viel nicht passt, der Wert also zu klein wird.)
Das sollte sinnvollerweise der Besucher einstellen können. Man kann ja eine sinnvolle Vorgabe vorschlagen, die er ändern kann. Wir konzipieren ja einen interaktiven Schlüssel. ;-)
Ein weiterer Vorteil ist, dass sich auf die gleiche Weise auch Häufigkeits-, Habitat- oder Phänologie-Angaben kodieren lassen: man könnte die Liste der Arten nach allgemeiner Häufigkeit im Fundland vorsortieren (ohne weitere Angaben ist die häufigste Art die wahrscheinlichste), und man kann den Fundzeitpunkt als Merkmal kodieren; z.B. eine winteraktive Art wäre vielleicht "Winter = 0.8, Frühjahr = 0.1, Sommer = 0.05, Herbst = 0.05". Natürlich ließe sich das beliebig verfeinern, z.B. mit den Fundzeitstatistiken des SRS nach Geschlecht und Monat...
Für die meisten Arten habe wir da keine verlässlichen Daten.
Beispiel Wiehle-Formel: wenn eine Art 2-2-2-2 haben sollte, dann ist 2-2-2-1 schon mal möglich, 0-0-0-0 aber eher unwahrscheinlich;
Ich würde sagen, weniger Stacheln ist immer möglich (Stichwort beschädigtes Material, aber man kann berücksichtigen, dass es nur ein begrenztes Repertoir an Mustern gibt; also kein 1-2-3-4 oder 2-1-2-1), eher unwahrscheinlich sind mehr Stacheln (aber auch möglich: Fehlinterpretation anatomischer Merkmale). Es gibt viele Fallstricke.
Martin
-
Warum baust du die Datenbank so herum auf (Merkmal –> Zuordnung aller Arten mit diesem Merkmal)? Mir erscheint der Ansatz von Michael mit den Zuordnungstabellen (Art –> Liste aller Merkmale in ihren artspezifischen Ausprägungen) logischer. Welche Vorteile hat dein Ansatz?
Ich habe mir das Backend angeschaut und finde es im ersten Moment verwirrend. Irgendwie definiere ich Merkmale und dann eine Liste aller betreffenden Arten. Es gibt zwar einen Wert für das Gewicht eines Merkmals, aber ich kann nicht definieren, wie (ge)wichtig oder unwichtig ein Merkmal bei einer Art ist. Fiktives Beispiel: Art 1 ist stenök –> Lebensraum bekommt starkes Gewicht, bzw. ist der richtige Lebensraum mit 0,99 und alle anderen Lebensräume mit 0,01 bewertet; Art 2 ist euryök –> Lebensraum bekommt geringes Gewicht bzw. alle Lebensräume bekommen einen Wert von 0,30.
Ich hätte erwartet, dass wir immer eine Art nehmen und zu dieser Art alle Merkmale abarbeiten (eingeben), bis jede Art (die der Schlüssel behandelt) einen Steckbrief hat, der aus den 8(...) Merkmalen besteht.
In einer anderen Tabelle hätte man die Merkmale beschrieben.
Oder verstehe ich das falsch?
Eine andere Sache, die mir noch aufgefallen ist: Es gibt (auch in Annas Linyphiiden-Schlüssel) viele Merkmale, die miteinender korrelieren. Einfachstes Beispiel: Fragen zur Epigynenform erübrigen sich, wenn als Geschlecht Männchen angegeben wurde. Weniger banales Beispiel: Wenn in der Liste der übrigen Arten keine Variabilität in einem Merkmal mehr besteht (sprich alle 10 Restarten haben geringelte Beine), muss dieses Merkmal nicht mehr abgefragt werden.
Daraus folgt zu einen der Bedarf an einer technischen Lösung (Datenbankabfrage) und zum Anderen ein Layout unseres Frontends, dass ein flexibles Zu- und Wegschalten von Merkmals-Abfragefeldern erlaubt.
In Annas Schlüssel werden die restlichen Merkmale (die in Bezug auf meine eingeschränkte Artenliste noch zur Verfügung stehen) auf Wunsch sogar nach Relevanz sortiert. D.h. vermutlich, dass solche Merkmale weiter oben in der Liste stehen, die eine größere Menge an Restarten ausschließen würden und solche weiter unten, mit denen z.B. nur eine der übrigen Arten abgetrennt werden könnte. Das ist ein schönes Gimmick, aber vielleicht nicht so wichtig für uns.
Arno
-
Warum baust du die Datenbank so herum auf (Merkmal –> Zuordnung aller Arten mit diesem Merkmal)? Mir erscheint der Ansatz von Michael mit den Zuordnungstabellen (Art –> Liste aller Merkmale in ihren artspezifischen Ausprägungen) logischer. Welche Vorteile hat dein Ansatz?
Zu aller erst den, dass ich – im Gegensatz zu Michaels – meinen Ansatz verstehe.
In welcher Weise man Daten eingibt, ist nicht eine Frage der Tabelle sondern des Backends. Man kann alternativ auch ein Backend bauen, das eine (un-) definierte Menge von Eigenschaften für eine Art definiert. Das ist eine Frage der Eingabelogik. Beide haben Vorzüge. Es erscheint mir sinnvoll, beide Möglichkeiten anzubieten.
Es gibt zwar einen Wert für das Gewicht eines Merkmals, aber ich kann nicht definieren, wie (ge)wichtig oder unwichtig ein Merkmal bei einer Art ist. Fiktives Beispiel: Art 1 ist stenök –> Lebensraum bekommt starkes Gewicht, bzw. ist der richtige Lebensraum mit 0,99 und alle anderen Lebensräume mit 0,01 bewertet; Art 2 ist euryök –> Lebensraum bekommt geringes Gewicht bzw. alle Lebensräume bekommen einen Wert von 0,30.
Du meinst, man sollte das Gewicht nicht dem Merkmal, sondern der Eigenschaft zuordnen. Interessant. Das ist durchaus eine Überlegung wert. Dein Beispiel ist da zumindest überzeugend.
Ich hätte erwartet, dass wir immer eine Art nehmen und zu dieser Art alle Merkmale abarbeiten (eingeben), bis jede Art (die der Schlüssel behandelt) einen Steckbrief hat, der aus den 8(...) Merkmalen besteht.
Wie gesagt, das ist eine Frage des Eingabelogik des Backends.
Eine andere Sache, die mir noch aufgefallen ist: Es gibt (auch in Annas Linyphiiden-Schlüssel) viele Merkmale, die miteinender korrelieren. Einfachstes Beispiel: Fragen zur Epigynenform erübrigen sich, wenn als Geschlecht Männchen angegeben wurde. Weniger banales Beispiel: Wenn in der Liste der übrigen Arten keine Variabilität in einem Merkmal mehr besteht (sprich alle 10 Restarten haben geringelte Beine), muss dieses Merkmal nicht mehr abgefragt werden.
Dieses Feature habe ich eher als störend empfunden (außer bei Geschlecht und Region). Ich kann Werte nicht mehr eingeben, weil irgend ein anderer eingegebener Wert dies verhindert (in diesem Moment ist aber nicht klar, welches dieser ermittelten Merkmale nicht wirklich passt, also vermutlich unpräzise oder falsch ist). Damit ist die mögliche Fehlleitung durch einen Fehler (Messfehler, Fehlinterpretation) davon abhängig, in welcher Reihenfolge man die Werte eingibt.
Überhaupt scheint die Auswertung bei Annas Schlüssel nicht ganz so primitiv zu sein, wie ich angenommen hatte. BTW: Leider gibt es wohl keine Möglichkeit die Daten dieses Schlüssels automatisiert auszulesen oder manuell heraus zu kopieren. Das könnte uns viel Arbeit ersparen. – Ich finde den Gedanken reizvoll, zu schauen, ob man mit der Bayes-Lösung mit den selben Daten besser zu Ziel käme.
In Annas Schlüssel werden die restlichen Merkmale (die in Bezug auf meine eingeschränkte Artenliste noch zur Verfügung stehen) auf Wunsch sogar nach Relevanz sortiert. D.h. vermutlich, dass solche Merkmale weiter oben in der Liste stehen, die eine größere Menge an Restarten ausschließen würden und solche weiter unten, mit denen z.B. nur eine der übrigen Arten abgetrennt werden könnte. Das ist ein schönes Gimmick, aber vielleicht nicht so wichtig für uns.
Das wäre gerade der Vorteil des Bayes-Filters.
Ich habe lange nicht programmiert. Es dauert ein wenig, bis ich eine ausprobierbare Lösung präsentieren kann. Man vergisst ja immer einiges, das man sich erst wieder anlesen muss.
Martin
-
Mein Entwurf sieht im Backend nun 3 verschiedenen Eingabemodi vor:
1: 1 Merkmal: viele Arten
2: viele Merkmale: 1 Art
3: nur Merkmalskatalog hochladen (im Beispielfall,, den Merkmalskatalog für die Gattung Xysticus) [ENTWURF (http://media.spinnen-forum.de/katalog.html)]
Man könnte aber auch das Merkmal 'Wiehleformel' für die Familie Linyphiidae hoch laden. Dies hilft, die Merkmalsdefinitionen einheitlich zu halten. Ebenso 'Prosomalänge' für die Ordnung: Araneae. Das ist ein bisschen wie Vererbung und reduziert den Pflegeaufwand.
Für Modus 2 läd man am besten über Modus 3 zunächst den Merkalskatalog hoch und arbeitet diesen dann Art für Art ab, wobei bei Nichteingabe von Eigenschaften ein Platzhalter für 'unbekannt' automatisch eingetragen wird. Allerdings stellt sich die Frage, wie sind fehlende Arten zu gewichten? Ich denke, gar nicht. 'Unbekannt' muss anders behandelt werden.
Merkmale, welche für eine Art die Eigenschaft 'unbekannt' haben, dürfen nicht für diese Art ausgewertet werden.
Art:Merkmal:Eigenschaft:Eigenschaftgewicht
Xysticus aaa: Lebensraum: Wald:0.20
Xysticus bbb: Lebensraum: Wiese:0.15
Xysticus ccc: Lebensraum: unbekannt:NULL
Wird nach Lebensraum 'Wald' gesucht, erhöht sich das Ranking von Xysticus aaa um 20%, wenn ich das Bayes-Prinzip richtig verstanden habe. Da nach 'Lebensraum: unbekannt' nicht gesucht werden können soll, werden unbekannte Lebensräume nie bewertet. Das Kriterium spielt einfach keine Rolle. Eine andere Lösung sehe ich da nicht.
Martin
-
Merkmale, welche für eine Art die Eigenschaft 'unbekannt' haben, dürfen nicht für diese Art ausgewertet werden.
Art:Merkmal:Eigenschaft:Eigenschaftgewicht
Xysticus aaa: Lebensraum: Wald:0.20
Xysticus bbb: Lebensraum: Wald:0.15
Xysticus ccc: Lebensraum: unbekannt:NULL
Wird nach Lebensraum 'Wald' gesucht, erhöht sich das Ranking von Xysticus aaa um 20%, wenn ich das Bayes-Prinzip richtig verstanden habe. Da nach 'Lebensraum: unbekannt' nicht gesucht werden können soll, werden unbekannte Lebensräume nie bewertet. Das Kriterium spielt einfach keine Rolle. Eine andere Lösung sehe ich da nicht.
Interessantes Beispiel (ich habe es leicht modifiziert, hoffentlich entsprechend der ursprünglichen Intention). Der Umgang mit fehlenden Werten ist ein ganzes Forschungsgebiet, das ist nicht trivial.
Im Beispiel würde die Wertung von Xysticus aaa mit 0.20 multipliziert, wenn "Lebensraum=Wald" ausgewählt wird, für Xysticus bbb mit 0.15. Wenn man dann für Xysticus ccc gar nichts macht, dann wäre das gleichbedeutend mit einer Multiplikation mit 1.0. Die Art bekäme also einen unfairen Vorteil. Wenn das Merkmal nicht bekannt ist, sollte die Art keinen Nachteil erleiden, aber auch nicht bevorzugt werden.
Eine klassische Lösung, die in anderen Anwendungen recht gut funktioniert, ist, dass man die fehlenden Werte durch den Durchschnitt der bekannten Werte ersetzt -- nach dem Prinzip: ich weiss zwar nicht, wo diese Art vorkommt, aber mein bester Tipp ist ein durchschnittliches Xysticus-Habitat. Im Beispiel also, Multiplikation mit 0.175 für X. ccc.
Beste Grüsse,
Rainer
-
Danke, Rainer. Interessant. Mit Durchschnitt meinst Du also das arithmetische Mittel: (sum1-n)/n; n=Anzahl der Antworten (einschließlich der unbekannten Antworten).
Beispiel 2:
A :wald:0.6
B :unbekannt:x
C :wiese:0.4
D :wald:0.5
E :unbekannt:x
n=5
Summe=0.6+x+0.4+0.5+x =1.5+2x
x=summe/n = (1.5+2x)/5
x=(1.5+2x)/5 |*5
5x=1.5+2x |-2x
3x=1.5
x=0.5
Korrekt?
Das wirft nun Fragen nach der Implementation auf. Am einfachsten (im Sinne von Pflegeleichtigkeit des Systems) ist es wohl, diesen Wert bei jeder Abfrage Auswertung erneut zu berechnen. Performanter wäre es, den Wert irgendwo zu speichern, dann müsste man aber protokollieren, ob der Fragenkatalog geändert wurde und immer dann neu berechnet werden. Ich denke, es ist besser, die Pflegeleichtigkeit zu priorisieren.
Die nächste Frage ist, wie implementiert man diese Formel als PHP-Funktion?
Martin
-
Hallo Martin,
n wäre nicht 5 sondern 3, da Du ja nur das Mittel der bekannten Arten bildest. Das Ausrechnen kannst Du gleich in SQL machen. Da zeigt es Dir für alle Zeilen mit Wert die Werte an und für alle mit 0 zeigt es Dir das Mittel aus diesen Werten an.
Hier mal ein bißchen Pseudo-Code dazu. Tabellen- und Spaltenname mußt Du natürlich anpassen:
SELECT CASE GROESSE WHEN 0 THEN (SELECT AVG(GROESSE)
FROM TABELLE_MERKMALE WHERE GROESSE <> 0) ELSE GROESSE END FROM TABELLE_MERKMALE
Gruß
Micha
-
n wäre nicht 5 sondern 3, da Du ja nur das Mittel der bekannten Arten bildest.
Stimmt. Da habe ich nicht aufgepasst. Das macht die Berechnung viel einfacher.
Ich habe mal verschiedene Konstellationen durchgespielt. Bei beiden Berechnungsmodi kommt das selbe heraus.
Martin
-
Beispiel 2:
A :wald:0.6
B :unbekannt:x
C :wiese:0.4
D :wald:0.5
E :unbekannt:x
Hallo, Martin,
Michael hat ja schon erwähnt, dass man den Mittelwert nur der bekannten Arten berechnet. Ich habe aber noch ein anderes Problem mit dem Beispiel (das war der Punkt, den ich in meinem Zitat von Beispiel 1 geändert hatte, aber da gibt es wohl noch Diskussionsbedarf).
Für mich sollte das Beispiel so aussehen:
Beispiel 2:
A :wald:0.6
B :wald:unbekannt
C :wald:0.4
D :wald:0.5
E :wald:unbekannt
Für die beiden Arten B und E, würde man dann den Wert (0.6+0.4+0.5)/3 = 0.5 ergänzen.
Wenn man auch die Wahrscheinlichkeiten des Lebensraums Wiese eingeben will, wäre das ein zweiter Eintrag zu jeder Art:
A :wiese:0.4
B :wiese:unbekannt
C :wiese:0.6
D :wiese:0.5
E :wiese:unbekannt
In einem strikt statistische Ansatz sollte die Summe der Wahrscheinlichkeiten 1.0 sein, wenn man alle Lebensräume aufaddiert (um die Ähnlichkeit zum klassischen Stäubli-Ansatz zu erhöhen, kann man auch der Merkmalsausprägung mit der höchsten Wahrscheinlichkeit für eine Art den Wert 1 geben, den weniger wahrscheinlichen Werte zwischen 0 und 1). Allgemein muss man also Merkmale (hier "Lebensraum") und Merkmalsausprägungen (hier "Wiese"/"Wald") unterscheiden. Für jedes gattungsrelevante Merkmal sollte jede Merkmalsausprägung erlaubt sein, wenn auch mit unterschiedlicher Wahrscheinlichkeit ("Gewichtung"); und die Summe sollte 1 sein (denn dass das vorliegende Exemplar irgendeine Merkmalsausprägung hat ist ja garantiert, solange man keine Option vergessen hat).
Ich bin nicht sicher, ob meine Erklärung deutlich ist, aber vielleicht hilft das Beispiel ja bei der Diskussion.
Beste Grüsse,
Rainer
-
Innerhalb identischer Eigenschaften eines Merkmals muss die Summe der Wahrscheinlichkeiten also 1 sein.
Merkmal 'Lebensraum': Eigenschaft: 'Wiese'.
Da sehe ich Durchführungsprobleme bei der Dateneingabe. Wir haben 94 Xysticus-Arten im Wiki. Ich schätze, für 50 % haben wir gar keine Daten (ich habe es nicht überprüft). Das sind dann die 'unbekannt'-Kandidaten. Je nach dem, wie viele Wiesen-Arten wir haben,desto geringer muss die angebbare Wahrscheinlichkeit ausfallen, sie in diesem Biotop vorzufinden. Das ist sehr ungünstig, weil dies die Relation der Auffindewahrscheinlichkeit für die jeweilige Art verändert.
Wenn ich als Experte schätze, dass Xysticus aaaa in einer Wahrscheinlichkeit zu 60 % auf einer Wiese vorkommt und zu 40% im Wald, kann ich das so nicht eintragen, weil jede Einschätzung für eine andere Art, bei der mindestens eins dieser Biotope vorkommt, die Notwendigkeit nach sich zieht, diese Werte anzupassen. Das heißt, die eigentliche Aussage wird verwässert.
Fiktives Beispiel:
A Wiese 60%, Wald 40 %
nun kommen 30 Arten hinzu, die auf Wiesen vorkommen. Es wird aus 60 % => 2 %. Das Wahrscheinlichkeitsverhältnis ist drastisch verschoben.
Eigentlich kann es nur funktionieren, wenn die Summe der Wahrscheinlichkeiten für eine Art = 1 (bzw. 100%) ist. Anders kann man das nicht eingeben. Und nur so resultieren auch die richtigen Ergebnisse.
Angenommen es sind 8 Biotope im System, aber für Art A sind nur 2 angegeben (Wiese 60 % & Wald 40 %), dann ergibt sich für die nicht angegebenen Biotope 50 % entsprechend der obigen Rechnung. Aber eben nur, wenn die Summe für die Biotope der jeweiligen Art 1 ergibt.
Martin
-
Hallo, Martin,
Da war meine Erklärung wohl missverständlich.
Innerhalb identischer Eigenschaften eines Merkmals muss die Summe der Wahrscheinlichkeiten also 1 sein.
Nein, die Addition läuft in die andere Richtung: für die verschiedenen Eigentschaften eines Merkmals innerhalb einer Art muss die Summe 1 sein. In dem Beispiel von Xysticus aaa ist das der Fall: "60 % auf einer Wiese und zu 40% im Wald" = 100% = 1. Wie Du ja schon sagst:
Eigentlich kann es nur funktionieren, wenn die Summe der Wahrscheinlichkeiten für eine Art = 1 (bzw. 100%) ist.
Die Zahl der anderen Arten (ob mit oder ohne Daten) beeinflusst die erwarteten oder einzugebenden Werte zum Glück nicht. Aber wenn mehr Arten mit bekannten Daten eingetragen werden, dann wird der Erwartungswert genauer.
Was vielleicht auch nicht ganz deutlich war: wenn der Wert für eine Art unbekannt ist, sollte er auch so in der Datenbank eingetragen sein. Die Ergänzung des Erwartungswertes (Durchschnitt dieser Eigenschaften über die bekannten Arten) wird dann erst berechnet, wenn eine Abfrage kommt. Auf diese Weise muss man die Werte nicht jedesmal in der Datenbank neu berechnen, bloss weil andere Arten aktualisiert wurden.
Beste Grüsse,
Rainer
-
Danke für die Bestätigung. Dann habe ich es nun begriffen.
Martin
-
Für mich sollte das Beispiel so aussehen:
Beispiel 2:
A :wald:0.6
B :wald:unbekannt
C :wald:0.4
D :wald:0.5
E :wald:unbekannt
Für die beiden Arten B und E, würde man dann den Wert (0.6+0.4+0.5)/3 = 0.5 ergänzen.
Wenn man auch die Wahrscheinlichkeiten des Lebensraums Wiese eingeben will, wäre das ein zweiter Eintrag zu jeder Art:
A :wiese:0.4
B :wiese:unbekannt
C :wiese:0.6
D :wiese:0.5
E :wiese:unbekannt
Logisch ergibt sich für mich ein Eingabeproblem. Man kann nicht zwischen allen Möglichkeiten gewichten, weil man die Anzahl der möglichen Merkmalsausprägungen (hier Eigenschaften genannt) nicht kennt.
Man gibt für Körperfärbung der Art A an:
bräunlich 60 %
gelblich 20 %
grau 20 %
Für Art B gibt man an:
bräunlich 50 %
gelblich 30 %
grünlich 10 %
schwarz 10 %
Für 'grünlich' und 'schwarz' wurde Art A nicht gewichten, Art B nicht für 'grau'. Die Summe der möglichen Farben ist erst bekannt, wenn die Merkmale für alle Arten eingegeben sind (müsste man das vorher ermitteln, werde das Eingeben von Eigenschaften eine sehr unübersichtliche und fehlerträchtige Aufgabe).
Die Wahrscheinlichkeiten einer Eigenschaft für eine Art muss (automatisch) korrigert werden (wieder zum Zeitpunkt der Abfrage). Aber mit welchem Wert?
Problem:
Art A:
bräunlich 60%
gelblich 20 %
grau 20%
grünlich
schwarz
Art B
bräunlich 50%
gelblich 30 %
grau
grünlich 10%
schwarz 10 %
Wie sind die fehlenden Werte aufzufüllen? Die Anpassung der bereits festgelegten gesetzten Werte erfolgt entsprechend anteilig ihrer Aufteilung.
Martin
-
Hallo Martin,
Ich sehe da zwei Möglichkeiten: 1. Man definiert eine allgemeine Fehler-und-Verwirrungs-Wahrscheinlichkeit (z.B. 1%) und gibt den fehlenden Eigenschaften diesen Wert. 2. Man ergänzt diese Werte am Ende doch manuell und fragt sich für jeden Einzelfall welcher Wert plausibel ist. Das wäre vielleicht auch eine Gelegenheit zur Qualitätskontrolle: habe ich Eigenschaften vergessen? Sind alle Eigenschaften klar verschieden - oder verwende ich die (fast) gleiche Eigenschaft unter verschiedenen Namen?
Beste Grüße,
Rainer
-
Verwirrungswahrscheinlichkeit ist vielleicht das falsche Wort. Sagen wir lieber Restunsicherheit.
Beispiel Verbreitung:
Es besteht immer auch die Möglichkeit einen Erstnachweis zu landen. Arno jüngst mit Drassodex validior für Italien (http://forum.spinnen-forum.de/index.php?topic=18150.0) oder ich 2011 mit Xysticus brevidentatus für Bosnien-Hezegovina (http://wiki.spinnen-forum.de/index.php?title=Xysticus_brevidentatus/Beobachtungen/Lemke).
Eine Notwendigkeit bei Nachtrag eines Merkmals die restlichen 93 Xysicus erneut editieren zu müssen, würde eine ziemliche Bearbeitungsbarriere aufbauen.
Dann mache ich es lieber so, dass ich für die Summe der nicht genannte Eigenschaften eine Gesamtwahrscheinlichkeit von 1% annehme. Damit ergibt sich für nicht genannte Merkmale folgendes: wahrscheinlichkeit=1%/m; m ist die Anzahl der nicht genannten Eigenschaften innerhalb dieses Merkmals über alle Arten der Gattung. Alle angegebenen Wahrscheinlichkeiten der genannten Eigenschaften: werden dann mit 0,99 multipliziert.
Martin
-
Um mal etwas spitzfindig zu ein: Die Wahrscheinichkeit Drassodex validior in Italien zu finden war nicht so klein, weil es die Art schon im Anchbarland Frankreich gibt. Die Wahrscheinlichkeit, sie in Norwegen zu finden, ist dagegen ausgesprochen gering.
Arno
-
Hallo Arno,
Gar nicht spitzfindig, sondern ein guter Punkt: im Grunde lässt sich das im Bayes-Ansatz gut einbauen. Wenn die Art in einem Land bereits gefunden wurde, ist die Nachweiswahrscheinlichkeit=1. Für die anderen Länder kann man dann nach Expertenintuition Werte zwischen 0 und 1 vergeben. D. validior wurde ja nicht nur ins Frankreich, sondern spezifisch in einem zoogeographisch dicht an Italien anschliessenden Gebiet gefunden. Da wäre ein Wert von 0.8 oder mehr wahrscheinlich sinnvoll. In Norwegen eher 0.1 oder weniger (verschleppt durch Urlauber oder Pflanzenimport für den Alpengarten?).
Beste Grüße,
Rainer
-
Das hatte ich befürchtet: Eine Sisyphosarbeit. Ich hatte mir eine clevere Formen erhofft, die die „Nähe“ eines europäischen Landes errechten.
Du hast natürlich Recht, man müsste eigentlich auch die zoogeografischen Gegebenheiten einbeziehen. Das setzt aber intensive Recherche bei jeder Art voraus.
Arno
-
Das hatte ich befürchtet: Eine Sisyphosarbeit. Ich hatte mir eine clevere Formen erhofft, die die „Nähe“ eines europäischen Landes errechten.
Da habe ich wohl leichtfertig ein etwas zu spezielles Beispiel gewählt. Aber es zeigt, wie hilfreich es ist, Ideen und Einfälle einfach so auszusprechen.
Wir könnten eine Tabelle aufbauen, aus der hervor geht, welches Land an welches andere grenzt – Nachbarländer bekommen 10%, andere 1 %/m, das Land des Vorkommens 89% (z. B. dk:no, se, gb, de; die von Rainer vorgeschlagenen 80 % für ein Nachbarland sind da nicht sinnvoll, da das eigentliche Vorkommensland so nur noch max. auf < 20% kommen könnte). An Hand dieser Tabelle könnten die entsprechenden Werte automatisch berechnet werden. Etwas ungenau wäre es an Europas Grenzen, da wir evtl. keine Verbreitungsdaten für die angrenzenden Länder haben (Algerien, Marokko ...); diese Daten müsste man künftig mit einpflegen.
Dies wäre aber nichts für unser Testsystem. Sowas kann man einbauen, sollte sich herausstellen, dass das System gut funktioniert.
Zurück zum eigentlichen Problem:
Ein neues Beispiel. Eine Art hat ein besonderes Merkmal, das die Bestimmung extrem vereinfacht; z. B. wie bei Dicymbium tibiale. Man bietet eine entsprechende Frage als Ankreuzfrage an und vergibt hierfür eine Wahrscheinlichkeit von 100%. Im Wiki haben wir drei Dicymbium-Arten. Das System würden den anderen beiden für verdickte Beine je eine Wahrscheinlichkeit von 1%/2 = 0,5% geben und Dicymbium tibiale eine von 100% x 0,99 = 99%.
Akzeptabel oder nicht? Ich würde sagen, ja. Die Wahrscheinlichkeit, dass die anderen beiden Arten verdickte Tibien haben, ist zwar in Wahrheit 0, aber eine andere Lösung sehe ich nicht. Um solche Fälle zu vermeiden, ist es sinnvoll, sich vor Eingabe der Daten einen geeigneten Fragenkatalog (für eine Gattung) zu überlegen. Arno hat das ja auch so gemacht (Fragenkatalog für Xysticus (http://forum.spinnen-forum.de/index.php?topic=18102.msg112445#msg112445)). Auf diese Weise wird vermieden, dass für eine Gattung nachträglich Fragen auftauchen, für die einigen Arten darunter Merkmal/Eigenschaft-Konstellationen fehlen.
Martin
-
So sehe ich das auch. Aber: Ich würde mir bei so einer sensiblen Sache wie einem Bestimmungssystem trotzdem die Mühe machen, bei möglichst allen Arten die Werte nachzutragen, wenn ich einen neuen Wert für die Gattung (taxonomischen Raum) ergänze. So viel Arbeit ist das wahrscheinlich nicht, v.a. wenn es Spezialmerkmale sind, die nur eine Art hat (alle anderen erhalten dann ja 0 oder so).
So oft wird das mit dem Ergänzen von Merkmalen nicht vorkommen, denke ich (außer in der Testphase). eigentlich ist das eher ein Problem von Arten bei denen wir über ein Merkmal keine Angaben haben. Z.B: Xysticus-Arten aus den „hinteren Reihen“, bei denen niemand weiß, wie sie aussehen (Prosomazeichnung, Gesamtfarbe ...)
Vielleicht ist ein späteres Backend ja so clever programmiert, dass ich eine generelle Eigenschaftenkombination für ein neues Merkmal für alle Arten erst mal vordefiniere und nur bei ein paar Arten korrigieren muss (Beisp: Harpactea hombergi ist die einzige Harpactea-Art mit geringelten Beinen).
Arno
-
So sehe ich das auch. Aber: Ich würde mir bei so einer sensiblen Sache wie einem Bestimmungssystem trotzdem die Mühe machen, bei möglichst allen Arten die Werte nachzutragen, wenn ich einen neuen Wert für die Gattung (taxonomischen Raum) ergänze.
Wir sollten eine Bearbeitungsanweisung formulieren und darin auch erklären, warum und wieso...
So viel Arbeit ist das wahrscheinlich nicht, v.a. wenn es Spezialmerkmale sind, die nur eine Art hat (alle anderen erhalten dann ja 0 oder so).
Wenn man es von Anfang an richtig macht (wie Du), hält man den Fehler minimal oder vermeidet ihn ganz.
Martin
-
Kleine Randbemerkung: die geographische Verbreitung ist ein Merkmal, wo sich die einzelnen Eigenschaftswahrscheinlichkeiten nicht zu 100% addieren müssen. Vorkommen in einem Land schliesst ja ein Vorkommen in anderen nicht aus. Alle Länder aus denen eine Art sicher gemeldet ist können also mit 100% registriert werden. Etwas anderes ist es, wenn man dann noch die Häufigkeit im Land des vorliegenden Fundes berücksichtigen will. Aber das liegt wohl noch in ferner Zukunft.
Beste Grüße,
Rainer
-
Mir ist heute beim Mikrokopieren eine Randstrategie eingefallen: Nämlich die Möglichkeit, wie in der Mathematik (es ist ja Mathematik), den Wertebereich der Lösungsmenge zu begrenzen. Bisher gingen wir implizit davon aus, dass der mögliche Wertebereich alle europäischen Arten einer Gattung umfasst, bzw. bei einem Familienschlüssel alle europ. Gattungen einer Familie. Dies würde uns beim Erstellen vor teilweise nicht lösbare Herausforderungen stellen.
Was mir seit Jahren vorschwebt, ist ein Epigynenschlüssel nach Epigynenformen (http://forum.spinnen-forum.de/index.php?topic=9619.msg69602#msg69602), der sich immer mehr verfeinert. So etwas würde mir meine Arbeit beim Mikroskopieren sehr erleichtern. Wäre ich aber gezwungen, alle europ. Linyphiiden zu typisieren, wäre der Aufwand praktisch nicht zu schaffen. Eine Eingrenzung auf häufige oder mitteleuropäische Arten wäre eine Lösung. Es müsste also die Möglichkeit bestehen, einen Werte-Pool zu definieren. Damit fielen dann die Strategien für nicht genannte Arten unter den Tisch und man kann mit absoluten Wahrscheinlichkeiten die Zielmenge möglicher Arten besser eingrenzen.
Syntaktisch: <bestimmungsschluessel gattung='Xysticus' pool='Mitteleuropa' />
[Häufigkeit in den Ländern]
Etwas anderes ist es, wenn man dann noch die Häufigkeit im Land des vorliegenden Fundes berücksichtigen will.
Ich denke, dieses Feature ist (erstmal?) zu komplex.
Im Grunde bedingt selbst die Nennung einer Art für ein Land eine grobe Vereinfachung. Hochgebirgsarten kommen an der Meeresküste nicht vor u.s.w.
Martin
-
Dein Einwurf (erster) wundert mich jetzt etwas. Ich dachte, das wäre das Ziel des interaktiven Schlüssels überhaupt. Ich kann doch über das Feld „Land“ das Zielland einstellen und dann (wenn in der Gattung/Familie angeboten) Epigynen-Typen auswählen.
Wir können das Feld „Land“ ja evtl. noch weiter aufbohren und „Ländergruppen“ anbieten (z.B: Mittel-, Nord-, Südeuropa oder Balkan, Iberische HI usw.). Das ist ja am Ende nur eine Frage der Abfrage, oder?
Arno