Unbenanntes Dokument

Taxonschnittstelle (word-Dokument)

Vorschläge von Thorsten Ludwig: taxonomy_v_TL.doc, tax_lit_v_TL.doc und synonymy_v_TL.doc

Felder	Datentyp / Restrictionen	Beschreibung	Bemerkung
Angaben für alle Daten eines Teilprojektes
dataDelivererID	String (not null)	ID zur Unterscheidung der einzelnen Teilprojekte
Angaben zum Datensatz:
dataInputDate	String	Datum an dem der Datensatz in der Datenbank des Datenlieferanten erstellt wurde (Datentyp: Datum)
dataInputEditor	String	Person die den Datensatz angelegt hat	AK 18.02.03: In Systax benötigt die Person ein Login
dataLastChangeDate	String	Letztes Änderungsdatum in der Datenbank des Datenlieferanten (Datentyp: Datum)
dataLastChangeEditor	String	Person die den Datensatz das letzte Mal änderte
Angaben zum Taxon
taxonID	String	Diese ID definiert den Datensatz eindeutig und über diese ID ist der Bezug zur ursprünglichen Datenbank immer wieder herstellbar. Für die Eindeutigkeit der ID ist der Datenlieferant verantwortlich.	AK 18.02.03: Diese ID muß angegeben werden und wenn sie fehlt wird DS nicht importiert!
externID_description	String	Die Description gibt den Namen des Codes an und das Feld externID_code nimmt die eigentliche ID auf.	AK 18.02.03: Systax verlangt standardisierte Werte, wobei es meines Erachtens ein freies Textfeld sein sollte und der Datenlieferant ist dafür verantwortlich, dass das Feld eindeutig benannt ist. TL 26.02.03: Für jeden hier vorkommenden Wert ist eine „Erklärung“ sinnvoll, die z.B. den Namen, Bemerkungen, URLs etc. zu dieser externen Quelle enthält – diese „Erklärung“ kann auch getrennt (z.B. per email) geliefert werden.
externID_code	String	Externe IDs beziehen sich auf andere Datenbanken, wie z.B. der OSF species-code bei DOrSa. Diese IDs müssen nicht bei jedem Datensatz vorhanden sein und es können auch mehrere unterschiedliche Codes angegeben werden.
valSpeciesID	Stringmuss einen Wert aus Spalte 'taxonID' enthalten, der schon importiert wurde (nicht notwendigerweise im selben Import-File)	Verweis auf die taxonID des validen Taxons. Die Vorsilbe ‚val’ soll an dieser Stelle eine Abgrenzung zum Basionym (dort mit Vorsilbe ‚cit’) sein. An dieser Stelle werden sowohl valide Taxa im Sinne der Projekte eingetragen, als auch Synonyme im Sinne der Projekte. Die Synonyme erhalten allerdings einen Verweis auf die valide Art indem die taxonID der validen Art im Feld ‚valSpeciesID’ eingetragen wird. Zusätzlich kann im Feld ‚validity’ Angaben zur Synonymie gemacht werden	AK 18.02.03: Feld gelöscht. Durch die Abtrennung des Basionyms nicht mehr benötigt. JSP 26.02.03: Leider nicht ganz richtig: das Feld wird durch "synonymID" ersetzt. Mir erscheint der Name "valTaxonID" aber logischer, weil de facto auf ein gültiges Taxon verwiesen wird. TL 26.02.03: Zustimmung. GBIF-Vert: Bitte wir bauchen eine Definition von „Basionym“ = Identisch mit Originalbeschreibung???? Aber auch sonst: wo und wie ist der Unterschied zum letzten synonymID?? Bitte Erklärung liefern wo und wie die Verknüpfung „beschriebenes Taxon – valides Taxon „erfolgt! TL 25.03.: Anmerkung siehe unten
validity	String	Eintrag ob valides Taxon oder Synonym	AK 18.02.03: Systax verlangt standardisierte Werte. Sinnvoll oder doch freies Textfeld?
class	String		Auftrennung nach dem 1. Leerzeichen. Vor dem 1. Leerzeichen: Taxonname; danach: Taxonautor JSP 26.02.03: so lange wir diesen Rattenschwanz von Taxa beibehalten handeln wir uns weiter beständig Ärger ein. Wir sollten nur noch 2 Felder zulassen: "Vorgänger" und "Stufe", sowie logischerweise "Taxonname" und "Autor". Alles andere läuft über ID Verweise. Sonst würde unter Umständen SYSTAX wieder jede Menge Datensätze höherer Kategorie doppelt generieren TL 26.02.03: korrekt – wäre ich auch dafür. Das Problem ist aber, dass diese Struktur anscheinend der Struktur vieler Datenbanken ähnelt und diese gar keine Möglichkeit haben, hierarchische IDs zu generieren
order	String		Systax 18.02.03: Leerzeichenfunktionalität wie bei valClass
suborder	String		Systax 18.02.03: Leerzeichenfunktionalität wie bei valClass
superfamily	String		Systax 18.02.03: Leerzeichenfunktionalität wie bei valClass
family	String
familyAuthor	String
subfamily	String		Systax 18.02.03: Leerzeichenfunktionalität wie bei valClass
tribe	String		Systax 18.02.03: Leerzeichenfunktionalität wie bei valClass
genusID	String	Eindeutige ID die die Gattung repräsentiert (Angabe optional)	AK 18.02.03: über diese ID können Angaben zum Typus der Gattung verknüpft werden TL 26.02.03: wenn Felder ab species und darunter leer sind, müsste dieser Wert identisch mit taxonID sein...
genus	String (not null, falls valSpecies not null)
genusAuthor	String	Autor für die Gattung, z. B. Serville, 1839
subgenus	String
subgenusAuthor	String
species	String (not null, falls valInfraspec not null)	Erstes Epitheton, z. B. apollo
speciesAuthor	String	Autor der Art
infraspec1	String	Infraspezifischer Namensbestandteil, z. B. bohemicus	JSP 26.02.03: da subspecies "name bearer" sind, würde ich die Felder "subspecies" und "subspeciesAutor" gegebenenfalls als eigene Felder bestehen lassen. Vgl. aber hierzu die oben vorgeschlagene Datenstraffung. GBIF-Vert: Wo ist der Unterschied zwischen infraspec 1 und 2? Ist nicht selbstbeschreibend. Wertigkeit ist ja in rank gegeben. TL 25.03.: wurde ebenfalls schon von Herrn Spelda kritisiert. Meiner Meinung nach müsste dieses Feld umbenannt werden nach subspec und ein weiteres Feld subspecAutor eingefügt werden
infraspec2	String	Infraspezifischer Namensbestandteil, z. B. bohemicus	AK 18.02.03: Wird ein 2. Feld für einen infraspezifischen Namensbestandteil benötigt? TL 26.02.03: falls ja, wird auch ein rank2 und ein infraspecautor2 benötigt. JSP 26.02.03: Ich würde für alle infraspezifischen Taxa einen Precursor vorschlagen: ohne = subspecies, var. = Varietät, f. = Form etc., sonst handeln wir uns bei tiefen Hierarchien wieder Probleme ein. Allerdings muss dann jeder subspezifischer Name stets VOLL ausgeschrieben werden (Bsp. Craspedosoma rawlinsii alemannicum var. bavaricum subvar. walhallae) TL 26.02.03: verstehe ich jetzt nicht ganz... TL 25.03.: infrasubspecifischer Namensbestandteil
rank	String (not null, falls valInfraspec not null)	Entsprechender Rang des infraspezifischen Namensbestandteils, z. B. subspecies	Systax 18.02.03: hier sollten nur die Einträge 'subspecies', 'sp', 'ssp' 'variance', 'var', 'forma', oder 'f' vorkommen TL 25.03.: hier dürfte dann nur infrasubspezifische Ränge rein
infraspecAuthor	String	Autor des infraspezifischen Namensbestandteils
speciesNotes	String	Bemerkungen zum Taxon
Angaben zum Basionym
baseID	String	Verweis auf eine gültige taxonID	AK 18.02.03: Ist eine baseID eingetragen so ist das angegebene Taxon das Basionym zu dem Taxon auf das die baseID verweist. Also das Taxon das diese baseID als taxonID besitzt JSP 26.02.03: da nur für Arten nötig: die Doppelbelegung mit der Typusart bei Gattungen wäre gar nicht dumm (und auch logisch, weil der Artname auf dem Basionym basiert und ebenso der Gattungsname auf der Typusart. Gleiches gilt meines Wissens aucg für die Namen der "familyGroup"-Kategorie, ud ist dort für die korrekte Autorenschaft wichtig. Wenn schon Taxon-Informationssystem, dann auch richtig! TL 26.02.03: sorry, aber ich bin eindeutig gegen eine Doppelbelegung (damit meine ich ein Feld, dessen Interpretation abhängig ist vom Inhalt eines anderen Feldes)was aber genau jetzt hier gemeint ist, weiss ich leider nicht. GBIF-Vert: Wo ist der Unterschied zu unten???? TL 25.03.: hier fehlt meiner Meinung nach eine Angabe zur Literatur
Angaben zu Synonymen
synonymID	String	Verweis auf eine gültige taxonID	AK 18.02.03: Ist eine synonymID eingetragen so ist das angegebene Taxon das Synonym zu dem Taxon auf das die synonymID verweist. Also das Taxon das diese synonymID als taxonID besitzt JSP 26.02.03: siehe bei "valSpeciedID" GBIF-Vert: Validtaxon???? S. oben. TL 25.03.: hier fehlt ebenfalls eine Angabe zur LiteraturIst dies aufwärts oder abwärtsgerichtet? d.h. steht hier die TaxonId des validen Taxons oder die TaxonIds aller Synonyme zu diesem Taxon? AK 28.03.: Hier sollte die TaxonID des validen Taxons stehen
Literaturverknüpfung
literatureID	String	ID die auf das entsprechende Literaturzitat in der Literaturschnittstelle verweist.

JSP 26.02.03: Die Langnamen sollen (auch) beim Verknüpfen denjenigen Mitarbeitern, die in Datenbankstrukturen nicht so fit sind eine (logische) Strukturierung Ihrer Daten ermöglichen. Es ist schlichtweg einfacher für "Papilio machaon Linnaeus, 1758" bei Vorgänger "Papilio", "genus" zu schreiben, als mühevoll die ID herauszusuchen. Die hierfür nötige Verlinkung kann dann problemlos die EDV-Koordination übernehmen (wenn alles logisch korrekt angegeben ist).
Alexander hat dies in der Schnittstelle "type_genus" bereits realisiert. In gleicher Weise können wir natürlich auch mit den Basionym- und Synonymieverknüpfungen verfahren, notfalls auch mit der Hierarchisierung. Dies würde die Taxonschnitstelle entkomplizieren, vor allem, wenn wie in GBIF nur eine (stabile) Artenliste gefordert wird.
Ich würde mich auch lieber nur auf IDs beschränken, aber ich denke mit den Langnamen ist ein vernünftiger Kompromiss zu dem Rattenschwanz an Feldern gegeben.

TL 26.02.03: Es darf aber nicht vergessen werden, dass der Gattungsautor beim Langnamen einer Art weggelassen wird, für die Identifizierung einer Gattung aber eine entscheidende Rolle spielt!
Das selbe gilt für „Infra-Taxa“ (z.B. wird bei Unterarten der Artautor weggelassen...)

TL 26.02.03: Durch Angabe verschiedener literatureID ist es möglich, für ein und denselben Namen alternative Taxonomien in dieser Schnittstelle anzugeben.

TL 25.03.:Basionym ist, so wurde es mir anscheinend das Taxon so wie es in der Erstbeschreibung genannt wird und muss an dieser Stelle getrennt von der üblichen Synonymie verwaltet werden.
Wäre es nicht sinnvoll, die Basionymverknüpfung in einer anderen Schnittstelle zu realisieren?
Auf jeden Fall fehlt hier noch eine Angabe zur Literatur der Synonymieverknüpfung und eine Literatur zur Basionymverknüpfung.
siehe hierzu auch die Mail, in der diese Datei als Attachment angefügt wurde.

AK 28.03.03: Für das Basionym braucht man m. E. keine eigene LiteraturID, da das Basionym einen eigenen Datensatz in dieser Schnittstelle besitzt und damit dort die entsprechende LiteraturID eingetragen werden kann.