[Entwurf Martin] Datentabelle

[Martin Lemke]

Letzter Vorschlag:

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

Arno wand ein, dass es sinnvoller ist, die mögliche Antwort zu gewichten. Daher nun:

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
Eigenschaft: string
Eigenschaftsgewicht: int // Hier können Genitalmerkmale auf eine höhere Ebene gestellt werden als Habitatinfotos, bzw. sehr sichere Sondermerkmale wie z. B. die peitschenförmige Kopfform von Walck. acuminata in ihrer Wirkung verstärkt werden
Hinweis: text NULL
Geschlecht: char(1) // * = beide Geschlechter; ansonsten wie üblich m, f, j
Geltung: String // hier kann der Gültigkeitsraum eingeschränkt werden; z. B. 'Gattung:Xysticus' oder 'Ordnung:Opiliones'

Die Möglichkeit, den Geltungsraum einschränken zu können, ist sehr wichtig. Warum sollte man schließlich bei Weberknechten nach der Prosomalänge fragen? – Ob dieses Datenfeld nun eine gute Lösung ist oder die gesamte Datenstruktur nochmal auf den Prüfstand muss, muss ich mir noch überlegen.

Bei Michas Entwurf wurde das ja von vorn herein so assoziiert. Dies hat aber den Preis, dass man mitunter bei jeder Gattung die immer selben Merkmale neu einpflegen muss, wenn ich das richtig verstanden habe.

Tabelle Arteneigenschaften BS_ml_Arten
id_Eigenschaft int // Verweist auf den Index der Tabelle Eigenschaften
id_art: int // Verweis auf Artentabelle

[Arno Grabolle]

Bei Michas Entwurf wurde das ja von vorn herein so assoziiert. Dies hat aber den Preis, dass man mitunter bei jeder Gattung die immer selben Merkmale neu einpflegen muss, wenn ich das richtig verstanden habe.

Wenn man alle Probleme auf ein mal lösen will kann man sich aber auch verzetteln.

Ich denke, man könnte die Beschreibungen für bestimmte Merkmale (z.B. KL: wird gemessen von Vorderkante Prosoma bis Hinterkante Opisthosoma ...) aus einer schon bestehenden Tabelle ohne großen Aufwand kopieren.

Viele Fälle in denen Merkmale für mehrere Gattungen gelten, gibt es wahrscheinlich gar nicht. Wenn ich mir immer noch ein Bildchen zu den Merkmalen vorstelle, dann sehe ich da selten Schnittmengen.

Arno

[Martin Lemke]

Wenn man alle Probleme auf ein mal lösen will kann man sich aber auch verzetteln.

Die objektorientierte Vererbung ist in der Programmierung heute Standard. Warum sollte man solche vernünftigen Ideen nicht aufgreifen? Es trägt zur Vereinheitlichung des Fragenkataloges bei und reduziert den Wartungsaufwand auf ein Minimum, bzw. hilft Mehrarbeit zu vermeiden. In einem Projekt, das auf freiwillige ehrenamtliche Mitarbeit einiger weniger angewiesen ist, halte ich dies für sehr wichtig.

Ich denke, man könnte die Beschreibungen für bestimmte Merkmale (z.B. KL: wird gemessen von Vorderkante Prosoma bis Hinterkante Opisthosoma ...) aus einer schon bestehenden Tabelle ohne großen Aufwand kopieren.

Was aber schon an Merkmalen für alle anderen Webspinnen hoch geladen werden könnte, sind Fragen wir Prosomalänge u.s.w. Die jeweilige Eigenschaft (Antwort) für z. B. eine Art, muss natürlich im Einzelfall eingetragen werden. Aber man muss dann nicht für Ozyptila wieder die Frage 'Prosomalänge' hoch laden.

Viele Fälle in denen Merkmale für mehrere Gattungen gelten, gibt es wahrscheinlich gar nicht. Wenn ich mir immer noch ein Bildchen zu den Merkmalen vorstelle, dann sehe ich da selten Schnittmengen.

Eine Prosomalänge ist für alle Webspinnen relevant. Du musst das Merkmal (die Frage) von der Eigenschaft (Antwort) getrennt betrachten. Es geht mir darum einerseits, den Fragenkatalog zu vereinheitlichen und andererseits den Aufwand, diesen zu ersinnen und einpflegen zu müssen zu reduzieren.

Ich implementiere mal das, was mir vorschwebt, zum Ausprobieren und Rumspielen. Dann ist das anschaulicher.

Wenn es etwas taugt, ist es ein Ansatz, den man verfolgen kann, wenn es sich als untauglich oder fehleranfällig erweist, können wir es korrigieren oder als Ansatz verwerfen um andere Lösungen zu entwickeln. Was es auf jeden Fall bringt, ist Erkenntnisgewinn.

Im Gegensatz zu früheren Konzepten, werde ich das unmittelbar ins Wiki integrieren. Damit haben wir Zugriff auf Bilder, die bereits im Wiki enthalten sind, bzw. können noch fehlende über den bekannten Upload-Dialog des Wikis hinzufügen.

Aktueller Entwurf der Datentabellen: http://media.spinnen-forum.de/datenstruktur.html

Es ist das Feld: Antworttyp hinzu gekommen, das definiert, wie die Antwort angeboten werden soll:
- Checkbox: Ein Kästchen, das man ankreuzt
- Listbox: Eine Liste, aus der man eine vorgegebene Antwort auswählt

Martin

[Martin Lemke]

Die von mir vorgeschlagene Datenstruktur ist nicht wirklich gut. De Eigenschaften müssen in eine andere Tabelle als die Merkmale, wenn man nicht alles duplizieren will.

http://media.spinnen-forum.de/datenR3.html

Martin

[Eveline Merches]

Zu den Begrifflichkeiten:
Hat das Feld Merkmal in Tabelle bs_ml_merkmal Werte wie: Größe, Habitat, Prosomalänge etc ?
Hat das Feld Eigenschaften in Tabelle bs_ml_eigenschaften die zu Merkmal gehörenden Werte, wie 1-3 mm (zu Größe), Wiese (zu Habitat) usw.?
Ausgehend von einer Art:
Eine Art hat mehrere Merkmale, aber nicht alle Arten haben die gleiche Anzahl an Merkmalen?
Ein Merkmal kann viele Eigenschaften haben, aber je Art nur eine?

Solche Dinge müssen für alle klar sein. Ich verstehe z.B. nicht, warum in Tabelle "Merkmale" id_ordnung und id_familie enthalten ist. Hätte dort id_art vermutet. Bei meinem obige Verständnisansatz, würde ich das Merkmal ganz ohne Zuordnung zu irgendwas machen, die Eigenschaften nur zu einem Merkmal (id_merkmal) und den Zusammenhang beider zu Arten erst in einer zusammenführenden Tabelle herstellen.

Aber erstmal möchte ich verstehen, was die Feldinhalte bedeuten und wie sie zusammenhängen.

liebe Grüße
Eveline

[Martin Lemke]

Ich bin mit diesen Strukturen noch unschlüssig. Das sind nur die ersten, etwas fortentwickelten Ideen.

Martin

[Martin Lemke]

Hat das Feld Merkmal in Tabelle bs_ml_merkmal Werte wie: Größe, Habitat, Prosomalänge etc?

ja.

Hat das Feld Eigenschaften in Tabelle bs_ml_eigenschaften die zu Merkmal gehörenden Werte, wie 1-3 mm (zu Größe), Wiese (zu Habitat) usw.?

ja.

Ausgehend von einer Art:
Eine Art hat mehrere Merkmale, aber nicht alle Arten haben die gleiche Anzahl an Merkmalen?
Ein Merkmal kann viele Eigenschaften haben, aber je Art nur eine?

Eine Art kann beliebig viele Merkmale haben, welche sich in der Anzahl unter den verschiedenen Arten unterscheiden können. Ein Merkmal einer Art kann beliebig viele verschiedene Eigenschaften umfassen. Bsp. Merkmal Lebensraum => Eigenschaften verschiedener Wahrscheinlichkeiten: Wald (60%), Wiese (20%), Moor (10%) und Ruderalflur (10 %).

Innerhalb eines Merkmals einer Art muss die Summe der Wahrscheinlichkeiten immer 100% ergeben.

Ich verstehe z.B. nicht, warum in Tabelle "Merkmale" id_ordnung und id_familie enthalten ist.

Ich habe es mir nochmal durch den Kopf gehen lassen und diese beiden Felder gestrichen. id_art bleibt natürlich drin.

Bei meinem obige Verständnisansatz, würde ich das Merkmal ganz ohne Zuordnung zu irgendwas machen, die Eigenschaften nur zu einem Merkmal (id_merkmal) und den Zusammenhang beider zu Arten erst in einer zusammenführenden Tabelle herstellen.

Wenn das Merkmal keinen Bezugsrahmen bekommt, wird bei der Konzeption der Bestimmung von Weberknechten die Frage nach der Prosomalänge auftauchen. Ich gehe davon aus, dass mit der Benutzung der Fragenkatalog anschwillt. Aber wir können diese Bindung auch weg lassen. Für die anfängliche Konzeption ist die Reduktion auf das unbedingt nötige vielleicht auch ganz gut.

Also: Rev. 3.2: http://media.spinnen-forum.de/datenR3.html

Martin

[Eveline Merches]

Wenn das Merkmal keinen Bezugsrahmen bekommt, wird bei der Konzeption der Bestimmung von Weberknechten die Frage nach der Prosomalänge auftauchen. Ich gehe davon aus, dass mit der Benutzung der Fragenkatalog anschwillt. Aber wir können diese Bindung auch weg lassen. Für die anfängliche Konzeption ist die Reduktion auf das unbedingt nötige vielleicht auch ganz gut.

Ich dachte eigentlich an Vermeidung von Mehrfacheingaben.
Ich käme auf vier Tabellen:
1. Die Tabelle der Arten (gibt es schon (cl_art)) - Schlüssel = id_art
2. Tabelle der Merkmale (s_merkmale - Schlüssel = id_merkmal)
3. Tabelle der Eigenschaften je Merkmal (s_eigenschaften - Schlüssel = id_eigenschaft)
              Fremdschlüssel zu s_merkmal über id_merkmal
4. Zusammenführungstabelle Arteigenschaften (schlüssel = id_arteigenschaft)
    Letztere hat:
    id_art als Fremdschlüssel auf cl_art und kann über join alle notwendigen Daten der Art holen
    id_merkmal als Fremdschlüssel zu s_merkmale, die über Join das Merkmal und seine Daten holt
    id_eigenschaft als Fremdschlüssel zu s_eigenschaften, die per join die Eigenschaft holt
    geschlecht      -- für die Differenzierung nach Geschlecht, falls für diese Art notwendig
    eigenschaftsgewicht -- die für diese Art und evtl. Geschlecht notwendige Gewichtung

Die Zusammenführungstabelle ist dann Grundlage für die Erfassung der Eigenschaften/Merkmale je Art. Derjenige, der die befüllt wählt dann je Art aus der Liste der Merkmale ein Merkmal und aus der der Eigenschaften eine passende Eigenschaft aus.
So kann man die Liste der Merkmale relativ kurz und übersichtlich halten und muss die nicht mehrfach eintragen. Bei den Eigenschaften gibt es wohl wenige Eigenschaften, die für mehrere Merkmale gültig sind und daher ein eventueller Mehrfacheintrag hinnehmbar ist.

Das Geschlecht kann als Liste hinterlegt werden. Das Eigenschaftsgewicht ist meiner Meinung nach artspezifisch und muss daher in dieser Tabelle stehen und nicht bei der Eigenschaft werden.
Dass die Summe der Gewichtung je Eigenschaft 100% ergeben muss, muss man via Prüfroutine absichern, die am Ende einer Eingabe aller (!) Eigenschaften je Art startet. Jede Gewichtung ist ja ein Datensatz!

liebe Grüße
Eveline
   

[Arno Grabolle]

Da ich das nicht alles bis zum Letzten durchschaue muss ich nachfragen: Wie ist stellt ihr euch das jetzt vor? Gibt es eine große Datenbank in der man alle Arten verwaltet (also von den Wolfspinnen bis zum Weberknecht)? Wenn ich die Gattung Xysticus bestimmen will würden auf der speziellen Bestimmungshilfe-Seite nur die Daten zu Xysticus abgerufen und angezeigt.

Kann man später auch andere „taxonomische Räume“ definieren, also z.B. mehrere nahe verwandte Gattungen zusammengefasst oder gar eine kleine Familie?

Natürlich (Martin hat es oben häufiger erwähnt) haben viele Merkmale in anderen Gattungen keinen Sinn oder vollkommen andere Eigenschaften.

Ist das Geschlecht wirklich so eine herausgehobene Eigenschaft, dass es in der Datenbankstruktur eine Sonderbehandlung erfahren muss? Hängt nicht jedes Merkmal mehr oder mit jedem anderen zusammen?

Arno

[Eveline Merches]

Gibt es eine große Datenbank in der man alle Arten verwaltet (also von den Wolfspinnen bis zum Weberknecht)? Wenn ich die Gattung Xysticus bestimmen will würden auf der speziellen Bestimmungshilfe-Seite nur die Daten zu Xysticus abgerufen und angezeigt.

Von meinem (und Martins habe ich auch so verstanden) Ansatz her ja. Die Datenbank z.B. wird erstmal für die Gattung Xysticus mit Daten gefüllt und das System an sich getestet und verbessert.

Kann man später auch andere „taxonomische Räume“ definieren, also z.B. mehrere nahe verwandte Gattungen zusammengefasst oder gar eine kleine Familie?

Anfangs werden nur Merkmale in die Merkmalstabelle gelangen, die für Xysticus relevant sind. Man kann das dann aber beliebig erweitern und ergänzen und für andere Familien oder auch Weberknechte mit Daten befüllen. Das ist ja sehr viel Arbeit und wenn wir das machen, dann sicher in kleinen übersichtlichen Portionen und nur für Gruppen für die wir genügend gute Daten haben.

Natürlich (Martin hat es oben häufiger erwähnt) haben viele Merkmale in anderen Gattungen keinen Sinn oder vollkommen andere Eigenschaften.

Da einer Art nur die Merkmale und deren Eigenschaften  zugeordnet werden, die auch passen, ist das ja kein Problem. Ich bin mir nur nicht sicher, wie man die Auswertung macht, wenn je Art 10 - 20 Datensätze auszuwerten sind. Das wird man wohl mit Funktionen machen.

Ist das Geschlecht wirklich so eine herausgehobene Eigenschaft, dass es in der Datenbankstruktur eine Sonderbehandlung erfahren muss? Hängt nicht jedes Merkmal mehr oder mit jedem anderen zusammen?

Ich hab e das aus Martins Ansatz übernommen, weil das Geschlecht mitunter entscheidend ist, ob eine Eigenschaft greift oder nicht.  Wahrscheinlich macht es auch mehr Sinn, das Geschlecht bei der Eigenschaft zu lassen, wie Martin es hat. Ursprünglich hatte ich es eigentlich als ein Merkmal angesehen.
Ich finde auch nicht, dass alle Merkmale so zusammenhängen, wie Geschlecht zu etlichen Eigenschaften. Bilder, Größe, Epiygnenform, Kopfform sind doch meistens geschlechtsspezifisch. Aber z.B. die Größe hängt nicht mit der Epigynenform und die Prosomaform nicht mit dem Habitat zusammen. Wenn es da doch welche gibt, die zusammen betrachtet werden müssen, müssen wir da drauf reagieren. Da sind wir dann aber schon bei der Festlegung von Merkmalen und deren Eigenschaften.

Die Strukturen befinden sich ja noch im Aufbau und sind noch lange nicht perfekt. Man muss schauen, ob man alles abbilden kann, was man will und ob man dann auch noch eine Auswertung hinbekommt.

Eveline

[Martin Lemke]

Zur Datenbank:
Es existiert eine Datenbank mit allen im Wiki behandelten Arten (und einigen mehr). Mittels dieser werden die Tabellen mit den Verbreitungsangaben, die Europakarten und die Angaben zu den Roten Listen automatisch erzeugt.

Was nun zu konstruieren ist, sind Merkmals- und Eigenschaftentabellen.

Stand der Dinge:
Ich habe eine Konstruktion aus 2 Tabellen vorgestellt (die bereits vorhandene Artentabelle und die der Verbreitungsdaten habe ich nicht mit gezählt). Eveline hat nun vorgeschlagen aus meiner Tabelle Eigenschaften 2 Tabellen zu machen. Erst dachte ich, das sei unsinnig, aber es ist konsequent. Der Einfachheit halber werde ich es aber bei meinem Entwurf belassen. Sollte das System, das nun zum Testen implementiert wird, gut funktionieren, sollten wir es neu aufsetzen und dann so wie von Eveline vorgeschlagen implementieren.

Faktisch läuft es darauf hinaus, dass ein Katalog an Merkmalen festgelegt wird (der kann jeder Zeit erweitert werden). Bei der Eingabe von Eigenschaften für eine Art wird der komplette Bestand an Merkmalen angeboten, es muss aber nicht zu jedem möglichen Merkmal eine Eingabe gemacht werden. Diesen Maximalbestand an angebotenen Merkmalen wollte ich ursprünglich gattungsspezifisch begrenzen, aber das lassen wir weg, weil es ja nur eine Studie ist und da beschränken wir uns auf das rudmentär notwendige (Usability-Optimierungen bleiben außen vor). Sollte das System sich als brauchbar erweisen, kann man meine ursprüngliche Idee immer noch aufgreifen.

Anwendungsfall (Idee):
Wie bereits für die Europakarte und Artentabellen, soll es ein spezielles Tag geben, bei dem beispielsweise die Gattung als Attribut angegeben wird. Also beispielsweise so:

<bestimmungsschluessel gattung='Xysticus' /> bzw. <bestimmungsschluessel gattung='{{PAGENAME}}' />

Der angezeigte Frage/Antwortenkatalog wird in festgelegte Sektionen gegliedert: Anatomische Merkmale, Habitus und Ökologie (z. B. Lebensraum). Es werden für eine Gattung ausschließlich solche Merkmale abgefragt, für die auch Eigenschaften hinterlegt sind (Prosomafarbe würde also bei Weberknechten nicht abgefragt).

Für einen Familienschlüssel wäre es dann z. B. <bestimmungsschluessel familie='Salticidae' />

Die Anwendung ist damit ganz einfach.

Als Hilfsmittel soll es auch ein Info-Attribut geben. Vielleicht so: <bestimmungsschluessel hilfe='liste' /> o. ä. um alle vorhandenen Schlüssel aufzulisten. Das wäre dann für die Wiki-Seiten unter: Hilfe zur Benutzung und Mitarbeit.

Die Eingabe von Merkmalen und Eigenschaften von Arten erfolgt über eine Spezialseite (Backend). Ursprünglich hatte ich hier 3 Eingabemodi vorgesehen:

1. Ein Merkmal/Eigenschaft-Paar, viele Arten
Arno hatte diese Eingabelogik kritisiert. Nach dem ich verschiedene Eingabeszenarien im Kopf durchgespielt habe, bin ich nun auch der Meinung, dass wir darauf verzichten sollten. Man arbeitet einfach so nicht, sondern gibt die Daten Art für Art ein.
2. Zu einer Art verschiedene Merkmal/Eigenschaft-Konstellationen eingeben (logischer Normalfall)
3. Einen Merkmalskatalog hoch laden
Ich habe hier die von Arno für Xysticus erarbeiteten Merkmale schon mal thematisch gegliedert und werde die hoch laden, wenn ich das entsprechende Backend teste:

- Anatomie
Geschlecht   
Körperlänge                 
Epigyne: Form
Pedipalpus: Form der medianen Bulbusapophyse
- Habitus
Beine: Färbung des ersten Beinpaars
Grundfarbe/Gesamtfarbe
Prosomazeichnung
Opisthosomazeichnung
-Ökologie
Land 
Lebensraum

Als Ergebnis werden grundsätzlich alle Ergebnisse angezeigt, allerdings nach Wahrscheinlicheit gewichtet. Der Anwender soll die Möglichkeit haben, einzustellen, ab welcher (geringen) Wahrscheinlichkeit abwärts, Ergebnisse nicht mehr angezeigt werden. Für jede angebotene Art gibt es einen Link ins Wiki und einen zu den SpiEu.

Der Anwender soll nicht gezwungen werden, alle Fragen zu beantworten. Aber er wird mit der Zeit feststellen, dass man bessere Ergebnisse erreicht, wenn man möglichst viele Fragen beantwortet.

Zum Geschlecht:
Das Geschlecht ist im Prinzip ein Wertepaar: Merkmal=>Eigenschaft. Da bei vielen Arten jedoch die Männchen ganz anders aussehen als die Weibchen, sollten Geschlechter im Bestimmungsschlüssel so behandelt werden, als seien es unterschiedliche Arten. Damit hat das Geschlecht als Eigenschaft eine gewisse Sonderstellung in der Auswertung.

Martin

[Martin Lemke]

Durch diese Störung (man konnte nicht richtig Posten, oft Time out-Fehler) bin ich von diesem Thema etwas abgekommen. Arno hat schon Recht, ich neige dazu, viele Features auf einmal zu verwirklichen. Ich muss mich zur Zurückhaltung zwingen.

Ich überlege gerade, wie das Backend funktionieren soll, wo man den Merkmalen, Eigenschaften zuordnet. Ich bin der Meinung, dass es zwar ein sehr langes Formular ergibt, letztendlich aber trotzdem am übersichtlichsten ist, wenn man zu jeder Art und Geschlecht den gesamten Merkmalskatalog auf einer Seite anbietet (wenn man später mal editiert, sollen farblich hinterlegt neu hinzugefügte Merkmale, die noch unbeantwortet sind, ganz oben angezeigt werden).

Kann man später auch andere „taxonomische Räume“ definieren, also z.B. mehrere nahe verwandte Gattungen zusammengefasst oder gar eine kleine Familie?

Das müssen wir. Im Moment bin ich etwas ratlos, wie man das am besten bewerkstelligt. Hat jemand eine Idee?

M. E. muss man in folgender Weise Räume definieren können:
- Gattung: Gattungname, evtl. auch mehrere Gattungen
- Familie: Familienname

Meine Idee hierzu:

Tabelle BS_ml_merkmalskatalog
id: int – Merkmalskatalog_id
rahmen: string – hier steht entweder 'Gattung' oder 'Familie'
name: string

Beispiel für einen gemeinsamen Schlüssel über Xysticus und Ozyptila

BS_ml_merkmalskatalog
id: 110
rahmen: 'Gattung'
name: 'Xysticus, Ozyptila'

In der Merkmalstabelle muss ein Feld id_merkmalskatalog existieren und hat für alle Merkmale, die den gemeinsamen  Schlüssel über Xysticus und Ozyptila betreffen, den Wert 110.

Martin