Mycobank erweitern

  • Hallo Wolfgang,

    Das Zusammentragen aller Trennmerkmale für alle Arten ist tatsächlich eine Mammutaufgabe, die einer allein nicht bewerkstelligen kann. Das würde nur über ein großes Team und langer Zeit funktionieren.

    Das stimmt. Deshalb sollten die Daten nur die wesentlichen Merkmale enthalten. In meiner Tabelle könnten beispielsweise die Angaben zu den Hutfarben auf eine Spalte mit Angabe von wenigen Farbräumen / -gruppen reduziert werden. Gleiches gilt für die Sporenfarben, da es auch hier viele uneinheitliche Farbbeschreibungen bzw. Farbnamen gibt.
    Die Tabelle ist entstanden, als ich ab ca. 2002 begonnen habe, mich intensiver mit den Pilzen zu beschäftigen und mir einen Überblick verschaffen wollte, weil man mit der Excel-Datenfilter-Funktion mit einigen bekannten Merkmalen recht schnell zu den in Betracht kommenden Gattungen und Arten kommt.


    Und dann eine Software, die die Merkmale nicht in Spalten sondern Zeilen verwaltet, weil man so jederzeit dynamisch weitere Merkmale aufnehmen kann. Und die online ist oder sich zumindest synchronisieren kann...

    Da Excel nur 256 Spalten zur Verfügung stellt, wird sich das so nicht realisieren lassen. Man kann zwar über "Bearbeiten / Inhalte einfügen / Transponieren" bis zu max. 256 Datensätze auch in der Form darstellen, aber eben nicht mehr.
    Man kann also bis zu 256 Spalten für die Merkmale verwenden und dynamisch jederzeit weitere Merkmale einfügen bzw. verändern.


    Beste Grüße
    Udo

  • Hallo zusammen,


    weil hier mittlerweile zwei Dinge diskutiert werden, MycoBank-Nutzung und Etablierung einer neuen DB, ein kurzer Gedanke. Ich rate davon ab, die MycoBank-Datensätze als Basis für eine offizielle DGfM-Datenbank zu verwenden. Zum einen steckt die DB dort noch immer in den Kinderschuhen. Im Moment habe ich leise Zweifel, dass die MycoBank-Infrastruktur dem neuen ICN-Passus (= gültige Veröffentlichung nur mit MB-Registrierung) standhalten kann. Zum anderen schleift man unweigerlich einen großen Haufen Ballast wie doppelte Einträge, falsche Autorenzitate oder falsche Literaturreferenzen mit. Warum nicht gründlicher und in kleineren Schritten vorangehen, z. B. in Gattungen, über die man bei Bearbeitung als Nebeneffekt auch noch einen aktuellen Überblick gewinnt? Das dauert dann natürlich länger, aber eine solide, stetig wachsende DB (auf der Mykis-Liste und einem belastbaren DB-Layout basierend) hat doch auch was.


    Zu einer nachhaltigen Lösung trage ich selbstverständlich gern mein Scherflein bei.


    Zu Jens ursprünglicher Frage: m. E. führt kein Weg daran vorbei, die MycoBank-Administration zu fragen, in welchem Ausmaß das Ganze genutzt werden darf.


    Viele Grüße,
    Eric

  • Du kannst mir aber gerne jederzeit deinen Wunsch per PM mitteilen. Ich verspreche hiermit öffentlich, diesen dann auch geheim zu halten, obwohl ich ja ansonsten eher für mehr Glasnost bin. Aber da es bei Wünschen ja ins persönliche geht....


    Hi Jens,


    um Geheimhaltung geht es mir gar nicht - ich will hier nur keinen mit meinen Wolkenschlössern langweilen. Naja, wer nicht will, muss ja nicht weiterlesen.


    Ich träume von einer Software zur Funderfassung, in der ich alle Beobachtungen, Bilder, ... zu einem Fund und dem Fundort ablegen kann, und zwar recherchierbar (z.B. zeige mir alle Fälblingsfunde aus dem Laubwald mit kopfigen Zystiden) und vergleichbar mit anderen Funden.


    Wenn ich die Gattung angebe (oder eine andere taxonomische Ebene), erzeugt mir die Software eine Checkliste der dort zu erfassenden Merkmale (bei Saftlingen z.B. Länge der Tramahyphen).


    Anders als bei Kartierungsprogrammen kann ich auch unbestimmte Funde erfassen, und vielleicht Jahre später einem beliebigen Taxon-Knoten zuordnen (vielleicht einer Art oder sogar einer Form, aber vielleicht auch nur einer Sektion).


    Wenn auch die Typus-Merkmale erfasst wurden, entsteht nebenbei auomatisch auch ein synoptischer Schlüssel, aber das ist eher das Fernziel. Für sicher bestimmte Kollektionen mit bekannter Herkunft muss die Software natürlich einen Export zu den Kartierungsprogrammen haben, aber die Beziehung "Art <-- Fund --> Geokoordinate" ist nur eine von vielen Beziehungen, die man dort abbilden kann.


    Das ganze sollte komplett mehrsprachig angelegt sein (europaweiter Einsatz möglich), und wahlweise über eine lokale Installation funktionieren (also Server-Synchronisation) oder über eine Webseite oder App. Im Hintergrund muss eine "richtige" relationale Datenbank auf dem Server laufen. Die Software sollte über Plugins erweiterbar sein, um weitere Funktionen später hinzufügen zu können.


    Ein so großes Projekt könnte man heute wohl nur in Java oder C# umsetzen, und ich hatte tatsächlich schon mal mit C# angefangen. Damals waren die Datenbank-Zugriffsklassen
    ("O-R-Mapper") für C# aber noch sehr schlecht und haben mein Datenbank-Design nicht unterstützt. Heute wäre das anders.


    Mit Pilzen hat die Software über weite Strecken gar nichts zu tun, man könnte mit anderen Klassifikationsbäumen und Merkmalslisten genauso gut Gesteinsproben oder Briefmarken verwalten. Ich hatte die Software daher auch "General Attribute Information Architecture", kurz GAIA, genannt.


    Da Excel nur 256 Spalten zur Verfügung stellt, wird sich das so nicht realisieren lassen.


    @Udo: Mit Excel stößt man tatsächlich schnell an die Grenzen. Auch mit Access kann man eine Grenze erreichen. Mit einer echten SQL-Datenbank wären ein paar Tausend Taxa mit jeweils ein paar Hundert Merkmalen ein Klacks. Das Problem ist eher das Herausarbeiten all dieser Daten. Und erstmal die Programmierung einer Software, die einem über Jahre hinweg garantiert keine technischen Grenzen auferlegt.


    Grüße,



    Wolfgang

  • Hallo Wolfgang,

    Ich träume von einer Software zur Funderfassung, in der ich alle Beobachtungen, Bilder, ... zu einem Fund und dem Fundort ablegen kann, und zwar recherchierbar (z.B. zeige mir alle Fälblingsfunde aus dem Laubwald mit kopfigen Zystiden) und vergleichbar mit anderen Funden.

    Da müssten für alle Möglichkeiten entweder Spalten einer Tabelle oder eigene Tabellen vorhanden sein, die jeweils schon alle Auswahlmöglichkeiten bereithalten. (kann man ja bei Bedarf erweitern)

    Wenn ich die Gattung angebe (oder eine andere taxonomische Ebene), erzeugt mir die Software eine Checkliste der dort zu erfassenden Merkmale (bei Saftlingen z.B. Länge der Tramahyphen).

    Ist dadurch möglich, dass man die (Gattungs-usw.)Merkmale mit z.B der Gattung, Art oder eben auch höherwertig verknüpft, z.B. in einer Tabelle Differentialmerkmale. Pilzoek hat glaube ich sehr viele Merkmale (Waldtypen) und so schon tabellarisch erfasst.

    Anders als bei Kartierungsprogrammen kann ich auch unbestimmte Funde erfassen, und vielleicht Jahre später einem beliebigen Taxon-Knoten zuordnen (vielleicht einer Art oder sogar einer Form, aber vielleicht auch nur einer Sektion).

    Ja,..... man kann nicht genug Merkmale erfassen!

    Wenn auch die Typus-Merkmale erfasst wurden, entsteht nebenbei auomatisch auch ein synoptischer Schlüssel, aber das ist eher das Fernziel. Für sicher bestimmte Kollektionen mit bekannter Herkunft muss die Software natürlich einen Export zu den Kartierungsprogrammen haben, aber die Beziehung "Art <-- Fund --> Geokoordinate" ist nur eine von vielen Beziehungen, die man dort abbilden kann.

    Der Export ist sowieso sehr wichtig. Was nützen die erfassten Daten, wenn sie einen Schneewitchenschlaf halten. Was man wie in der DB abfragt,
    ist hinterher nur eine Frage der SQL-Umsetzung und des Frontends. Für die Kartierungsprogramme ist allerdings eigentlich nur Ort und die korrekt bestimmte Art von Interesse, oder?

    Das ganze sollte komplett mehrsprachig angelegt sein (europaweiter Einsatz möglich), und wahlweise über eine lokale Installation funktionieren (also Server-Synchronisation) oder über eine Webseite oder App. Im Hintergrund muss eine "richtige" relationale Datenbank auf dem Server laufen. Die Software sollte über Plugins erweiterbar sein, um weitere Funktionen später hinzufügen zu können.

    Das ist natürlich schon ein richtig großer Ansatz, den man von Anfang an berücksichtigen sollte (Sprachdateien und so), aber meinen Zeitrahmen dürfte das Gesamtkonzept erstmal sprengen. Allerdings eine Domain mit Datenbankmöglichkeit habe ich. Was darauf läuft? Damit habe ich mich noch nicht so recht mit auseinander gesetzt? Relational würde aber bei den selbst erfassten Datensätzen nur über einen Index funktionieren

    Ein so großes Projekt könnte man heute wohl nur in Java oder C# umsetzen, und ich hatte tatsächlich schon mal mit C# angefangen. Damals waren die Datenbank-Zugriffsklassen


    ("O-R-Mapper") für C# aber noch sehr schlecht und haben mein Datenbank-Design nicht unterstützt. Heute wäre das anders.

    Ich glaube, die Sprache für das Frontend ist fast egal (PC Laptop). Wichtiger ist die Datenbank mit ihren Möglichkeiten. Z.B. läuft die DB auch auf Android wg. App.

    Mit Pilzen hat die Software über weite Strecken gar nichts zu tun, man könnte mit anderen Klassifikationsbäumen und Merkmalslisten genauso gut Gesteinsproben oder Briefmarken verwalten. Ich hatte die Software daher auch "General Attribute Information Architecture", kurz GAIA, genannt.

    Das würde für absolut neu zu beschreibende "Gebiete" wohl Sinn machen. Ich möchte aber gerne auf vorhandene Daten (Mycobank, Udos und meine Excels, IF....) zurückgreifen und bei den Pilzen bleiben. Deine angedachte Struktur ist doch theoretisch so möglich, dass eine Tabelle der DB die Alleinstellungsmerkmale aufnimmt und damit weitere Tabellen (je Merkmal) erzeugt werden, die diese Merkmale, bezogen auf den nächst darüber liegenden Rang verwalten.
    Ich denke da demnächst mal weiter drüber nach...



    N8 und LG, Jens

  • Hi Jens,


    Da müssten für alle Möglichkeiten entweder Spalten einer Tabelle oder eigene Tabellen vorhanden sein


    Nein! Wenn jedes Merkmal in einer eigenen Tabelle stehen müsste, würde ja jedes neue Merkmal eine Änderung der Datenbank-Struktur erfordern. Bei Hunderten von Merkmalen...


    Ich würde alle Merkmale, die in Zahlen ausgedrückt werden können, in derselben Tabelle abspeichern, und diese Datensätze jeweils mit einer Fremdschlüssel-Id einem Merkmal (z.B. "Breite der Cheilocystiden") und dem Fund zuordnen. Die Namen der Merkmale und die Funde/Arten (allgemein: "Knoten") werden jeweils in einer anderen Tabelle gehalten. Im Front-End würde das natürlich nicht so zu sehen sein, würde aber die Programmierung jeder Suche erleichtern. Und man braucht nur eine Spalte/Tabelle pro Datentyp (Zahl, Datum, Text, Geokoordinate etc), und könnte jederzeit ohne Software-Änderung weitere Merkmale dieses Typs hinzufügen (z.B. "Länge der Pileozystiden"). Dann kann man auch auf der Datenbank leicht mit Indizes den Zugriff optimieren.



    Ich möchte aber gerne auf vorhandene Daten (Mycobank, Udos und meine Excels, IF....) zurückgreifen und bei den Pilzen bleiben


    Ich auch. Ein Datenimport sollte ja auf jeden Fall möglich sein, egal in welcher Form die Daten heute vorliegen (Hauptsache strukturiert). Wenn aber aus meiner Idee ein Open-Source-Projekt werden sollte, hätte man viele Synergien mit anderen Nutzergruppen, wenn alles Pilzliche nur in den Daten und nicht in der Software steckt.



    Gruß,



    Wolfgang

  • Andreas Kunze

    Hat das Label Expertenthema hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!