Trilobiten.de

[Pavel]

Hi Jens,

besten Dank für Deine Anmerkungen

und wieder paar Unklarheiten:
1) -Systematik-Status - als Kategorien behandelt - aus Deiner Anmerkung gehe ich davon aus, dass es mehrere Systematik-Status-Kategorien gibt (valid, invalid, noch etwas) ? Andere Frage ist: wird ein Taxon immer nur einer Kategorie zugeordnet oder auch mehreren gleichzeitig?

2) nomen nudum, oblitum,und andere
Da bin ich mir sicher, dass ein "Nomen" vergessen und auch gleichzeitig
nackt sein kann. In diesem Fall würde ich alle Möglichkeiten zusammenfassen und für jede eine "ja/nein" Option in der Taxontabelle einbauen - Platz sparend (so ein Wert besitzt 1, höchstens 8 Bits). Mann könnte es auch mit einem Feld (einer Spalte) machen: 1-"nudum", 2- "oblitum", 4-"etwas anderes" - Wert also die (für diese Kombination eindeutige) Summe 7. Ich weiß aber noch nicht, ob sich es dann einfach verwalten, abfragen und anzeigen lässt.

3) die Erstbeschreibung (nur das Jahr und "Autor") wird also getrennt von dem Literaturverzeichnis gespeichert.Na ja, es ist ja doch logisch, sonst hätte man
alle Infos gleich bei der Taxon-Eingabe ermitteln müssen. Außerdem, es kommt vor, dass z.B. ein Taxon so aussieht:
Trilobites novus SAMMLER in PROFI, 2004 (habe ich irgendwo gesehen)
Im Titel von PROFI aus dem Jahr 2004 steht aber nichts über SAMMLER. Ist meine Vermutung richtig?

4) Synonymie
Alles klar, was Deine Anmerkungen betrifft. Dies ist aber das größte Datenbank-Problem.
(Auf jeden viel größer, als Datenbasis für die graphische Darstellung der Verbreitung).
Da muss ich noch grübeln, wie man die Datenbank gestallten kann, damit die Tür für solche Daten offen bleibt, auch wenn die Synonyme nicht sofort erfasst werden.

------------------------

Die Datenbank (offline) in einer absehbaren Zeit zu gestallten ist bestimmt machbar. Genauer, entweder schaffe ich es nicht oder schon und dann brauche ich sicher weniger als Monate. Aber das hat schon Heiko gesagt, dass die Datenbank nicht das größte Problem ist....
Am Wochenende werde ich damit ein Bisschen spielen.

Grüsse, Pavel

[Mike]

Ich versteh (fast) nur Bahnhof! <g>

Mike

[Pavel]

Servus Heiko,

Zu der Hierarchie:
Die Struktur müssen wir noch ergänzen (betrifft die Klasse "Trilobita"): Klasse -> Ordnung -> Unterordnung -> Superfamilie -> Familie -> Unterfamilie -> Gattung -> Untergattung -> Art -> Unterart

Rein teoretisch, für andere Tierarten habe ich so was gefunden:
Regnum->Phylum->Subphylum->Superclasis->Classis->Subclassis->Infraclassis->
Cohors->Superordo->Ordo->Subordo->Infraordo->
Superfamilia->Familia->Subfamilia->
Tribus->Subtribus->Genus->Subgenus->Species->Subspecies

Also wir bleiben vorerst bei Trilos.

-------------------------------------
Zu Name, der Autor
Ok, gesondert speichern - wäre nicht schlecht (selektiver Suchanfrage). kleines Problem: ich such alles von AUTOR1, aber es gibt folgende Varianten: AUTOR1 AUTOR1 et AUTOR2 AUTOR3 et AUTOR1 et AUTOR2, Usw.

Dann muss ich entweder alle Auswahlkriterien markieren, wo AUTOR1 vorkommt (und der muss nicht unbedingt der erste sein (AUTOR3 et AUTOR1 et AUTOR2) und daher kann ich die "Auswahlzeile" in einer sortierten Liste übersehen. Oder ich kann alle Datensätze aus der Autor-Tabelle mit AUTOR1 kriegen, und zwar mit Hilfe des LIKE-Operators. Das kann ich aber auch machen, wenn, die Autors direkt bei einem Taxon hinterlegt sind. (Für eine Auswahlliste könnte man dann eine Gruppierungsabfrage mit GROUP BY verwenden). Wenn Du aber daran denkst,
das die Autor-Sondertabelle mit einem Literaturverzeichnis verknüpft werden sollte, wäre diese Tabelle nicht schlecht. Da würde ich mich danach richten, was einfacher
zu programmieren ist.

Taxons-Konnzept C: eine Tabelle und Taxon-Namen in einem DB-Feld
-------------------------------------------------------------------
Von dem Datenbakenetwurfsregeln her nicht gerade sauber Implementiert die Beziehungen zwischen Parent- und Child-Taxon in Taxon-Namen

Taxon_Name='Trilobita Agnostida', Taxon-Klasse = <Order>
Taxon_Name='Trilobita Agnostida Agnostus', Taxon-Klasse = <Gattung>
Taxon_Name='Trilobita Agnostida Agnostus pissiformis',Taxon-Klasse = <Art> Taxon_Name='Trilobita Agnostida Agnostus pissiformis',Taxon-Klasse = <Art>
Taxon_Name='Trilobita Seltsamertrilobitus', Taxon-Klasse = <Gattung>

1. Abfragen
wären ziemlich einfach zu erstellen (LIKE-operator für Namen and bei Bedarf Taxon-Klasse testen) - universall für alle Taxons beim Abfragen von verknüpften Tabellen (Literatur, Verbreitung, usw.)
Beispiel:
Kriterium für Order Agnostida (Order Agnostida im Recordset inkludiert) ((Taxon_Name LIKE 'Trilobita Agnostida %') OR (Taxon_Name = 'Trilobita Agnostida')) Bitte beachten, in Kriterien sind "wild characters" % nicht am Anfang der Zeichenfolge => ich glaube, da könnte immer noch beim Durchsuchen ein Index ins Spiel kommen

2. Baumstruktur
Untergeordnete Taxons immer mit Kriterium:
(Taxon_Name LIKE 'Trilobita %') AND (NOT (Taxon_Name LIKE 'Trilobita % %'))=> alles, was direkt auf nächster Ebene unter Trilobita steht => Order 'Agnostida' und Gattung 'Seltsamertrilobitus'

3. Größe
sehr anspruchsvoll
Aufgrund der Länge von Taxon-Namen muss man damit rechnen, dass so ein zusammengefasster Name 255 Zeichen überschreitet - über 255 Zeichen kann man die DB-Felder nicht indexieren => Da würden die Auswahlkriterien und Eindeutigkeitsregeln scheitern



Taxons-Konnzept D eine Tabelle - minimierte "Parent-Child"-Beziehung mit einem Text-Code
-------------------------------------------------------------------------------------------
Wir habe Taxon-ID (Nummer) und Taxon-Name
Ein Taxon-Text-Code in Form 'Trilobita Agnostida Agnostus' kann zu groß sein (Konnzept C) So ein Code hätte den Vorteil, dass er die Hierarchie abspiegelt und gleichzeitig keine mehrfachen Abfragen benötigt werden, um an die gewünschten Daten zu kommen - im Gegenteil zu Konnzepten A (ID, ParentID - rekursives Abfragen bis zur Art/Unterart-Ebene) und B (Abfragen mit unterschiedlich vielen Verknüpfungen).

Alternative:
Sagen wir, wir ordnen jedem Taxon einen Textcode zu, der aus z.B. 4,8,16,...usw. Ziffern besteht (0-9). Wieviele und welche Ziffern, wird erklärt. Ein Beispiel notwendig (im Taxon_Code mache ich immer nach 4 Ziffern ein Leerzeichen, damit es lesbar ist)

Taxon_Name Taxon_Klasse Taxon_Code (Taxon-Hierarchie)
Trilobita Klasse 0000 Trilobita
Agnostida Order 0000 0000 Trilobita->Agnostida
Agnostus Gattung 0000 0000 0000 Trilobita->Agnostida->Agnostus
pissiformis Art 0000 0000 0000 0000 Trilobita->Agnostida->Agnostus->pissif.
Peronopis Gattung 0000 0000 0001 Trilobita->Agnostida->Peronopsis
Trilobitus Gattung 0000 0001 Trilobita->Trilobitus (taxon. Loch)

!!! Ziffernanzahl (oder Anzahl von 4-stelligen Gruppen) in Code entspricht nicht !!! der Taxon-Klasse (Siehe Trilobitus und Agnostus)

Abfragen (Beispiele für "Agnostida"):
-Alles, was unter Agnostida liegt, mit dieser Maske (Taxon_Code LIKE '00000000_%')
-Alles aus direkt untergeordneten Ebenen (für Baumstruktur)
(Taxon_Code LIKE '00000000____')
-Übergeordneter Taxon (Taxon_Code = '0000')
-alles auf der gleichen Ebene (Taxon_Code = '0000____')
Die Kriterien lassen sich einfach automatisch ermitteln, weil man den aktuellen Code weiß und die Anzahl von Ziffern (4) kennt, die jede Ebene darstellen.

Mit Diesen Kriterien in "WHERE" kann man dann auch beliebige Tabellen verknüpfen (Lieratur, Verbreitung, ....), und zwar mit einer einzigen Abfrage und ohne weiteren Verknüpfungen
(JOIN) zwischen selbständigen Tabellen für Order, Familien, usw.. In diesem Bereich also ein geringer Programmierungsaufwand, denke ich.

INSERT:
-------
Ist schon koplizierter - Einen neuen eindeutigen Code generieren Von neuem Taxon ist der übergeordnete Taxon (Code) bekannt, oder es gibt keinen. Abfrage mit (Taxon_Code LIKE '<Parent_Taxon_Code>____') absteigend sortiert und wenn von MySQL unterstützt, nur mit einem Record im Recordset. Falls kein Record gefunden => Taxon_Code= <Parent_Taxon_Code>0000", wenn ja, letzte 4 Ziffern auf Nummer umwandeln, inkrementieren und auf String zurück (auf 4 Ziffern mit Nulls von links wieder füllen). Taxon_Code = <Parent_Taxon_Code><neue 4 Ziffern>"

UPDATE - betrifft nur die Neuzuordnung
--------------------------------------
Die Codes von dem neuen und alten übergeordneten Taxon sind bekannt. Ähnlich wie bei INSERT (Taxon_Code LIKE '<Parent_Taxon_Code_Neu>____') und genauso wie bei INSERT einen neuen Code (4 Ziffern) ermitteln. Dann Abfrage mit (Taxon_Code LIKE '<Parent_Taxon_Code_Alt>%') => der zu ändernde Taxon und alles, was unter ihm liegt. (aufsteigend sortiert). Den Recordset durchgehen und für jeden Record folgendes
machen: <Parent_Taxon_Code_Alt> von links abschneiden und dann noch 4 Ziffern von links weg.
Dann Taxon_Code = <Parent_Taxon_Code_Neu><Neue 4 Ziffern><abgeschnittener Rest>

Das wäre meiner Meinung nach alles, was mun tun muss, um die taxonomische Hierarchie warten zu können. Glaubt Ihr, dass es programmatisch machbar ist? Hoffentlich habe ich keinen Fehler gemacht.

Kapazität:
----------
Mit Zeichen '0' bis '9' und mit 4 Stellen lässt sich 10000 Variationen für jede hierarchsche Ebene erstellen, bei 5 Ziffern 100000. Das sollte reichen. Fals Taxon_Code's Länge 128 ist, kann man in diesem Feld 32 taxonomische Ebenen zusammenfassen. Also mehr, als man für Trilobiten benötigt und vielleich auch mehr, als es sie gibt. Eindeutiges Index ist garantiert.

Weitere Vorteile:
-----------------
Taxonomische "Löcher" eliminiert (wenn z.B. eine Unterfamilie fehlt und die Gattung gleich folgt - wäre bei mehreren Tabellen nur mit "Aushilfe-Werten" zu lösen. Baumstrukur lässt sich einfach aufbauen - immer die nächsten Taxons mit gleicher Maske und genau um 4 Ziffern länger. Anzhal von Taxon-Klassen (Order, Familie,...) muss nicht bekannt sein. Man kann später In Datenbank andere Taxon-Klassen einbauen (Phylum,Subphylum,Superclasis,...) ohne dass man etwas programmieren müsste.

Ich glaube, das reicht schon
Wie ist Deine Meinung dazu?
Falls es dir "D" nicht gefällt (eine Tabelle), wäre ich für "B" - mehrere Tabellen

Grüsse, Pavel

[Gast]

Hi Leute,

bin gerade in Göttingen, hier steht glücklicherweise nen Rechner, opfer gerade mein Kleingeld.
Ich denke den einzelnen Kategorien einen Nummernkode zuzuteilen ist hilfreich, so erkennt die Datenbank den Gattungsstatus auch wenn die betreffende Gattung in einer Unterfamilie versteckt ist.

Wie man das programmiert, davon habe ich leider keine Ahnung.

Übrigens wäre noch ne Idee, ein Feld Links bei den Arten mit einzuführen, so könnte man auf Internetressourcen verweisen.

Grüsse,

Jens

[Pavel]

Hie Jens, Hi Heiko

In privaten Messageboxes etwas über die geographische Verbreitung
Grüsse Pavel

[Jens]

Hallo,

habe heute auf der Tagung schon existierende Online-Datenbanken kennengelernt.

Schaut euch mal diesen Linke an.

Böhme, M. & Ilg, A. 2003: fosFarbase

http://www.wahre-staerke.com/

Eine weitere ist Böhme, M. & Ilg, A. 2003: Osteo

http://www.wahre-staerke.com/osteo/

und die Literaturdatenbank von Herrn Ilg

http://www.wahre-staerke.com/biblio/


Hier finden wir viele der von uns besprochenen Sachen und ich habe hier auch einen der Macher kennengelernt, der uns beim Aufbau einer eigenen nach unseren Wünschen angepaßten Datenbank helfen wird.

Grüsse,

Jens

[Gast]

Hallo,

Auf www.wahre-staerke.com gibt es ein Link:

http://paleodb.org/cgi-bin/bridge.pl?user=Guest&action=displayHomePage
und dann
http://paleodb.org/public/tips/taxonomy_tips.html

Interessante Infos

Grüsse Pavel

[Jens]

Hi Leute,

ich war so frei und habe ein erstes Konzept der Datenbank zu Herrn Ilg geschickt und bin mal gespannt, ob er Lust hat, dies umzusetzen.

Ich poste die Sache hier noch mal.


Was soll die Datenbank können

Es soll in erster Linie eine taxonomische Datenbank werden, aber gleichzeitig für den Laien halbwegs verständlich bleiben. Daher sollen automatisch generierte Übersichten der höheren Taxonomie das Verständnis der Verwandtschaft gewährleisten und auch die Navigation erleichtern. Ich stelle mir die Übersichten als verlinkte Namen in einem Pop-up-Fenster vor. Wenn man z.B. in einer Ordnung eine Gattung sucht, kann man sich halt durch die Systematik durchklicken, bis man das gewünschte Hierarchielevel erreicht. Im Prinzip schwebt mir eine Kopie der Windowsfester vor, wenn sich das denn verwirklichen läßt.
Das gleiche Ergebnis (Hierarchielevel) kann man auch über die Suchfunktion oder der alphabetische Gattungsindex erreichen. Aber ich denke, daß Systematikübersichten ebenfalls wichtig sind. Mir schwebt auch eine Show-Funktion vor, wenn man sich durch die Hierarchien klickt, kann man sich immer je nach Wunsch etwas anzeigen lassen. Zum Beispiel die Gattungen einer Familie oder Arten einer Gattung. Auf jeder dieser Fenster sollte dann auch die add- oder create-Funktion integriert sein, so daß man als eingeloggter Bearbeiter gleich etwas ändern oder hinzufügen kann.

Name der Datenbank Trilobite Biodiversity Database-Project

die 9 Ordnungen der Trilobiten auf der Startseite, durch anklicken öffnet sich Extra-Fenster mit Übersicht über die Unterordnungen, Familien und Unterfamilien.

Agnostida Redlichiida Corynexochida Lichida Phacopida Proetida Asaphida Ptychopariida Harpetida

Alphabetischer Index, einstellbar für Arten, Gattungen, Familien usw.Systematic overview (Link zu Extrafenster mit allen höheren Taxa bis Subfamilienlevel)

Search-Funktion für alle Einträge (auch kombinierte Suche, z.B. grabende Taxa im Mitteldevon von Oklahoma)

Add new data (in rot, Bearbeiter-Bereich) führt zu Formularen für Upload von Literatur- und ArtenlistenTutorial für die Nutzung der Datenbank, mehrsprachig

Registrierung, Log in und Erstanmeldung (freier Leserzugriff als guest)

News (Bearbeiter können hier sagen, was neu in der Datenbank ist)

History, Änderungen in der Datenbank, (verstellbar nach die letzten 10, 20 oder alle)

who is online (Forumfunktion von MySQL)Memberlist (mit Kontaktfunktion, private Message, Zählung der Dateneingaben, wie bei ebay)

Memberkategorien: Guest (nur lesen), Enthusiast (kann Arten und Gattungen ändern), Professional (darf fast alles), Admin (darf alles)

Link zum bereits existierenden Forum, falls Diskussionsbedarf besteht

Erläuterung zur Taxonomische Übersicht (systematic overview)

alle Ordnungen, Unterordnungen, Überfamilien, Familien, Unterfamilien in einem großen Fenster in tabellarischer Übersichtdurch Anklicken der einzelnen Rubriken öffnen sich Fenster mit näheren Informationen:

Order Diagnosis Distribution Occurence
Suborder Diagnosis Distribution Occurence
Superfamily Diagnosis Distribution Occurence
Family Diagnosis Synonyms Distribution Occurence show all taxa
Subfamily Diagnosis Synonyms Distribution Occurence show all taxa
Genus Diagnosis Genotypus Synonyms Distribution Occurence show all taxa
Subgenus Diagnosis Typusart Synonyms Distribution Occurence show all taxa
Species siehe Angaben für Species und Subspecies
Subspecies

Angabe der Anzahl valider Arten, Gattungen und Familien (irgendwann weiß man dann auf einen Blick wieviel Arten und Gattungen es gibt.Modul mit Create- und Edit-Funktion sowie dem Log in für Bearbeiter

Angaben für Species & Subspecies-Level:
Author
Locus typicus
Stratum typicum
Occurence in time
localities (Palaeogeography, with map feature?, Eingabe von Ländern, Regionen und Lokalitäten in Extra-Maske?, Verknüpfung mit Verbreitung von Gattungen, Familien et cet.)
Diagnosis (kurze Artdiagnose)Picture (upload feature) and Thumbnail, mit Beschreibungsfeld, Bild muß austauschbar sein, falls Fehler gemacht wurde oder besseres zur Verfügung steht
Palaeoecology
Remarks (z.B. wo liegt der Holotypus, Sammlungsnummern)
Synonomy
nomenclatoric status (valid, synonym, nomen oblitum et cet.)
References (literature database, extra Modul mit spezieller Eingabemaske)
Anzeige des Bearbeitungsstatus des Datensatzes, bei kompletter Ausfüllung grünes Feld, rot bei geringer Datendichte
Edit-Funktion Es muß auch ein Hinzufügen oder Änderung einer Untergattung problemlos möglich sein, da in der zur Verfügung stehenden taxonomischen Gattungsliste nicht zwischen Gattung und Untergattung unterschieden worden ist.

Denke erstmal, daß es reichen sollte. Wenn wir alles Umsetzen können, dann wird es ne fette Datenbank, die aber viele Möglichkeiten bietet.

Grüsse,

Jens

[Pavel]

Hallo Jens, hallo Leute

Gut, dass es jemand übernehmen will, der das schon gemacht hat.
Ich denke, Dein Konzept ist wirklich gut. Ich möchte gerne noch paar Anmerkungen dazufügen. Vielleicht findest Du etwas davon interessant.

1. Das Aussehen, Navigation, Suchfunktionen, usw.

Da habe ich gleiche Vorstellungen wie Du. Die Analogie zu einem Windows-Fenster (Windows-Explorer) wäre aus meiner Sicht die beste Navigation. Auch eine ähnlich Suchfunktion wäre nicht schlecht - einen Text eingeben und alle Taxa finden, die diesen Text in ihren Namen beinhalten. Navigation wie bei www.trilobites.com würde mir persönlich gefallen (statt Regionen Taxa).


2. Remarks

Mehrere Einträge pro Art/Unterart sollten möglich sein => eine selbstständige Datenbanktabelle

3. Geographische Verbreitung + locus typicus

Wie ich schon mal geschrieben habe, die Verbreitung von Arten ergibt die Verbreitung von Gattungen, Unterfamilien, usw. Da würde ich solche Eingaben nur für Arten/Unterarten zulassen. Sonst müssen wir bei einer neuen (nicht erfassten) Art immer überprüfen, ob die Verbreitung von Untergattung, Gattung, Unterfamilie, usw. mit Verbreitungen von allen untergeordneten Arten übereinstimmt.

Für die geographische Verbreitung sollten auch mehrere Einträge pro Art möglich sein - eine Art kann doch in Deutschland, Frankreich, Böhmen und vielleicht auch in Marokko vorkommen. Also wieder eine selbständige Tabelle, die eine Verknüpfung zu der Art (Taxon-Tabelle) und der Fundstelle beinhaltet. Diese Tabelle könnte dann ein Optionsfeld "Locus typicus On/Off" beinhalten.

4. Occurence in Time + stratum typicum

Da bin ich mir nicht sicher, wie weit wir gehen wollen. Wollen wir nach chronostratigrafischen (oder wie das Ding heißt) Einheiten recherchieren? Wenn ja, nach welchen? Silurian? Lower Silurian? Wenlockian? Oder gar die Schichten, die allerdings auf unterschiedlichen Gebieten anders heißen? Wenn z.B. bei einer Art nur "Wenlockian" steht und ich nach allen
aus "Silurian" suche, finde ich diese Art nicht. Wenn so eine Recherche möglich sein sollte, müssen wir uns eine Lösung einfallen lassen. Vielleicht ähnlich wie bei der geographischen Verbreitung (großer Zeitraum - Silurian, Stage - Wenlockian, dann vielleicht die Schichten - bei jeder Ebene noch lower, middle, upper (?)).

5. References

Nur nicht vergessen - mehrere References pro Art => eine Link-Tabelle, in der die Arten (Gattungen,...) mit dem "Buch"
verknüpft sind.

Ein Idee noch: Vielleicht sollte man auch bei dem Buch (Artikel) eine Übersetzung des Titels auf Englisch erfassen können - es wurde viel auf Deutsch, Französisch, Russisch, Schwedisch, usw. geschrieben. Ich kann persönlich bei manchen References nur ahnen, worum es geht.

6. Bilder

Falls nur zum Demozweck, ist 1 Bild OK. Falls auch für die Bestimmung, auch mehrere Bilder notwendig, denke ich.

----------

Ich freue mich schon auf neue positive Nachrichten.
Grüße Pavel

PS:
Jens, was ist mit deinen Jura-Muscheln, die willst Du drinnen nicht haben?

[Jens]

Hi Pavel,

danke fürs Feedback,

im Prinzip sprichst Du vieles an, was ich ähnlich angedacht habe.




1. Das Aussehen, Navigation, Suchfunktionen, usw.

Da habe ich gleiche Vorstellungen wie Du. Die Analogie zu einem Windows-Fenster (Windows-Explorer) wäre aus meiner Sicht die beste Navigation. Auch eine ähnlich Suchfunktion wäre nicht schlecht - einen Text eingeben und alle Taxa finden, die diesen Text in ihren Namen beinhalten. Navigation wie bei www.trilobites.com würde mir persönlich gefallen (statt Regionen Taxa).

Übers Aussehen und Navigation können wir noch reden, vielleicht sollten wir auch graphische Entwürfe machen.
Mal sehen was Herr Ilg zum Konzept meint, schaut man auf seine Datenbanken, kommt es aufs Aussehen für Wissenschaftler nicht so an. Aber ich meine, wir wollen Funktionalität auch mit Aussehen verknüpfen, so daß viele Leute mitmachen wollen.


2. Remarks

Mehrere Einträge pro Art/Unterart sollten möglich sein => eine selbstständige Datenbanktabelle

genau. Ein Bearbeiter sagt, daß ist doch ein Synonym von ..., der andere ne ist eigenständig. Daher vielleicht remarks in Form von Posts mit dem Bearbeiter-Namen.


3. Geographische Verbreitung + locus typicus

Wie ich schon mal geschrieben habe, die Verbreitung von Arten ergibt die Verbreitung von Gattungen, Unterfamilien, usw. Da würde ich solche Eingaben nur für Arten/Unterarten zulassen. Sonst müssen wir bei einer neuen (nicht erfassten) Art immer überprüfen, ob die Verbreitung von Untergattung, Gattung, Unterfamilie, usw. mit Verbreitungen von allen untergeordneten Arten übereinstimmt.



Ich meinte das so, daß die Geographische Verbreitung durch eine logische Verknüpfung zum Artniveau generiert wird, sich also aus der Verbreitung der Arten ergibt. Keine weiteren Angaben nötig. Auch stimmt, daß eine Art manchmal weltweit vorkommt.


Für die geographische Verbreitung sollten auch mehrere Einträge pro Art möglich sein - eine Art kann doch in Deutschland, Frankreich, Böhmen und vielleicht auch in Marokko vorkommen. Also wieder eine selbständige Tabelle, die eine Verknüpfung zu der Art (Taxon-Tabelle) und der Fundstelle beinhaltet.

Diese Tabelle könnte dann ein Optionsfeld "Locus typicus On/Off" beinhalten. watt heißt das? (es gibt immer nur einen Locus typicus.)

4. Occurence in Time + stratum typicum

Vielleicht geben wir schon Alter vor, die gültige internationale Stratigraphie, wo man dann nur noch ein Alter raussucht, aber mehrere Angaben wären auch nicht schlecht. Zum Beispiel Trilobitenzonen, oder Tentaculiten oder Graptolithen-Zonen. Kann sehr nützlich sein.

5. References

Nur nicht vergessen - mehrere References pro Art => eine Link-Tabelle, in der die Arten (Gattungen,...) mit dem "Buch"
verknüpft sind. genau, wenn man hat

Ein Idee noch: Vielleicht sollte man auch bei dem Buch (Artikel) eine Übersetzung des Titels auf Englisch erfassen können - es wurde viel auf Deutsch, Französisch, Russisch, Schwedisch, usw. geschrieben. Ich kann persönlich bei manchen References nur ahnen, worum es geht.

kann nicht schaden, macht aber Arbeit

6. Bilder

Falls nur zum Demozweck, ist 1 Bild OK. Falls auch für die Bestimmung, auch mehrere Bilder notwendig, denke ich.

äh, nur 1 Bild, am Besten der Holotyp

PS:
Jens, was ist mit deinen Jura-Muscheln, die willst Du drinnen nicht haben?

die sollten ne eigene Datenbank kriegen, wenn ich Zeit habe (hab i aber nich)

Grüsse,

Jens

[/quote]

[Pavel]

Hi Jens,

Hier zusätzliche Info zu meinen Anmerkungen:

1. "Locus typicus On/Off"
Die Arten sind in der Taxon-Tabelle gespeichert, die Fundstellen in der Tabelle "Localities". Jede Art wird dann mit einer oder mehreren Fundstellen in der dritten Tabelle verknüpft. So können wir gewährleisten, dass eine Fundstelle nur einmal erfasst wird und diese dann mit mehreren Arten verknüpft werden kann, die auf dieser Fundstelle vorkommen. Wenn wir dann den Fundstellenamen korrigieren müssen, wird es nur einmal in der Tabelle "Localities" gemacht, ohne dass man diese Korrektur bei jeder betroffenen Art machen müsste. Dadurch ist Datenintegrität gewährleistet und beim Recherchieren nach einer Fundstelle ist garantiert, dass alles gefunden wird und die Tippfehler vermieden werden. Also deswegen die dritte Verknüpfungstabelle. Jeder Eintrag in dieser Tabelle besteht prinzipiell aus der Kombination "TaxonID-FundstelleID". Man könnte jedoch bei solchen Verknüpfungskombinationen" zusätzliche Daten speichern, die nur für diese Kombinationen spezifisch sind. Dies ist der Fall eines "locus typicus". Fundstelle "Steinbruch" ist ein locus typicus für "ArtA" => bei der Kombination "ArtA-Steinbruch" könnte also eine Option "locus typicus" auf "Ja" gesetzt werden. Für andere Kombination "ArtA-Flussbett" auf "Nein", weil diese Fundstelle kein "locus typicus" von der "ArtA" ist. Aber, bei der Kombination (Verknüpfung) "ArtB-Flussbett" kann die Option "locus typicus" wieder "Ja" sein, weil das "Flussbett" ein "locus typicus" von der "ArtB" ist (aber kein von der "ArtA"). Also, Eine Fundstelle ist ein "locus typicus" für eine Art und für die andere wieder nicht. Sonst ist es klar, dass pro Art nur eine Fundstelle das "locus typicus" sein darf. Oh je, ich glaub, es ist nicht besonders verständlich, oder doch?

2. Occurence in Time + stratum typicum
Es freut mich zu hören, dass es wirklich eine gültige internationale Stratigraphie gibt. Auch bei Amis? Ich würde mich gerne irren, aber es kommt mir vor, dass die Amis nur eigene amerikanische stratigraphische Einheiten anerkennen. Wenn man die amerikanischen Formationen mit von uns anerkannten stratigraphischen Einheiten korrelieren kann, wäre alles wirklich viel einfacher, als ich gedacht habe. Ich habe keine Ahnung, wie ist das wirklich?

3. Übersetzung bei References
War nur eine Idee, so was dürfte nur optional sein, sprich, wenn jemand Lust hat, die Übersetzung zu machen. Ist aber überhaupt nicht wichtig

4. mehrere Bilder
Und wenn ein Holotyp ein unvollständiges Cranidium ist? Ich habe es eher als Frage geiment. Für uns Laien (bzw. für mich) ist 1 repräsentatives Bild ausreichend, die Wissenschaftler können sich na Diagnosis und Literatur richten.

Grüsse, Pavel

[Jens]

Hi Pavel,

die Geschichte mit den Localities wird man wohl so machen müssen, wie du vorschlägst.

Zum Thema Stratigraphie. Schwierige Geschichte. In Europa ist es halbwegs standartisiert, die Amis fallen wie üblich aus dem Rahmen, Russen und Chinesen machen ebenfalls ihre eigenen lokalen Sachen. Aber alles läßt sich irgendwie korrelieren.

Wenn Du wissen willst, schaue einfach nach.

http://www.stratigraphy.org/geowhen/timelinestages.html

Grüsse,

Jens

[Gast]

Danke Jens,

Ich war gerade auf der "stratigraphischen" Homepage!! Gottes Willen!!

Da muss sich einer wirklich etwas einfallen lassen. Am besten wäre es, wenn wir eigenes stratigraphsiches System für die Trilo-Datenbank erfinden

Grüsse Pavel

[Pavel]

Hi Jens,

Ich habe mich entschieden, Dich wieder mit meinen Konzept-Arbeiten zu belästigen

Meine Vorstelllungen bezüglich "Occurence in Time"
------------------------------------------------------------

Ich würde eine Liste von allen stratigraphischen Einheiten erstellen. Jede Einheit kann noch eine Kategorie kriegen (Epoch, Stage,...) und wird einem stratigraphischen System zugeordnet (Amis, Russen, ….)
Dazu sollte auch bei jeder stratigraphischen Einheit Alter von-bis gespeichert werden (in Millionen Jahren).

Wenn wir solche Liste haben, kann man bei der Taxon-Eingabe immer aus der Liste die stratigraphische Einheit wählen (für Ami-Trilos amerikanische, für unsere europäische, usw..). Falls eine Art in mehreren stratigraphischen Einheiten vorkommt (z.B. in Amerika und Russland(?)), sollten auch mehrere Einträge pro Art möglich sein. Da glaube ich aber, es wäre auf der Art-Ebene eher eine Ausnahme, oder?

Bei diesem Konzept könnte dann die Abfrage nach "occurence of the family in time" so funktionieren, dass Alter aller Arten aus der Familie abgefragt wird und Minimum und Maxim aus Datenfeldern "alter von" und "alter bis" ermittelt werden. Dann hast Du ein Zeitintervall. Zu diesem Intervall kann man schon Namen von stratigraphischen Einheiten finden, die sich mit diesem Zeitintervall, bzw. mit den Intervall-Grenzen, überschneiden. Diese könnte man noch weiter filtern - Ami-Units, EU-Units, China-Units, usw.

Andere Lösung ist, einfach in einem Datenbankfeld so etwas einzugeben: "Early Silurian, Wenlock". Dann kann man aber keine Tippfehler vermeiden und wie die Abfrage nach der stratigraphischen Verbreitung einer Familie oder Gattung funktionieren sollte, weiß ich nicht. Es sei denn, Du gibst die stratigraphische Verbreitung auch bei Gattungen, Familien, usw. ein (für Europa, Russland, Amerika...) => wenn sich etwas auf der Art-Ebene ändert, muss man dann auch alle übergeordnete Taxa händisch aktualisieren. Dies wäre aber viel einfacher zu programmieren.

------

Es würde mich interessieren, wie Du es dir mit Formationen + Facies vorstellst. Die Formationen könnten noch den chronostratiographischen Einheiten angehören, aber die Facien? Theoretisch könnte man auch die
Facien als chronostratigraphische Einheiten interpretieren (mit gleicher "occurence in time").
------
Biozonen: In Form eines Vermerks bei der Art stehend??
Gibt es wirklich globale Biozonen (vermutlich Graptholiten, Conodonten und Tentaculiten), die sich über Länder und Kontinenten erstrecken?

Ich freue mich auf Deine Meinung, wenn Du wieder mal Zeit hast

Grüsse Pavel

P.S.:
Gibt es bezüglich Herrn Ilg etwas neues?

[Jens]

Hi Pavel,

möchte mich mal wieder melden.

Die Sache mit der Eingabe des Alters ist eine schwierige Sache, wie Du ja gezeigt hast. Habe dieselben Schwierigkeiten gesehen.
Soll man nun eine vereinfachte Stratigraphie zum Auswählen in die Datenbank intergrieren (die dann auch noch regional auftrennen, mmh) oder soll man die Leute alles selbst eintippen lassen, auf die Gefahr von Schreibfehlern. mmh. Nich so ohne. Ein absolutes Alter (in Mio. Jahre) ist denke ich mal unnötig, daß können die Leute ja nachschlagen, außerdem ändert sich gelegentlich eine oder mehrere Einstufungen (obwohl heutzutage schon recht ausgereift) aufgrund neuer Isotopendatierungen.

Es gibt auch Arten, die eine längere stratigraphische Reichweite haben, aber selten über 2 Trilobiten-Zonen. Die kleinen Biester waren allesamt ziemlich Evolutionsfreudig und haben es selten lange in der selben Form ausgehalten.


Formationen und Fazies. Ne Formation ist eigenlich nur ein stratigraphischer Begriff, der regional eine bestimmte lithologische Abfolge zusammenfasst. Muß nicht unbedingt sein, diese Angabe. Die Fazies kann für paläoökologische Betrachtungen sehr wichtig sein, so bildet sich ein Sandstein (eher flach und bewegtes Wasser) unter anderen Bedingungen als ein Tonstein (eher tieferes, ruhiges Wasser). Da Trilobiten gerne eine gewisse Faziesabhängigkeit zeigen, kann eine solche Angabe schon interessant sein.


Es gibt tatsächlich überregional Biozonen, besonders von den angesprochenen Tiergruppen. Graptolithen trieben in den Ozeanen, wen wundert da die weite Verbreitung. Conodontentiere waren Schwimmer und auch gut unterwegs. Es gibt selbst überregionale Trilobiten-Zonen, google mal Glyptagnostus reticulatus durch. Oder schau gleich http://norges.uio.no/timescale/Fig10.2_Cambr-colA.pdf


Grüsse,

Jens