Project

General

Profile

Actions

Mappings für Rote Liste-Projekt

This page summarizes the RL->CDM mappings


Mapping: Rote Liste-DB -> CDM

Die Rote Liste Datenbank beinhaltet insbesondere taxonomische Daten sowie deskriptive Daten im Sinne des CDM bzw. Eigenschaften im Sinne der Roten Liste.

Zudem sind Daten zur Ausgabesteuerung für die einzelnen Ausgabekanäle sowie allgemeine Daten z.B. die Nutzerverwaltung sowie die Projektverwaltung enthalten.

Die meisten Daten sollten ohne größere Probleme ins CDM überführbar sein. Offene Fragen gibt es insbesondere im Bereich Projektverwaltung sowie Publikationsaufbereitung, da das CDM eine Projektverwaltung derzeit nicht vorsieht (Workarounds aber möglich sind) und die Steuerung von Pulikationen im CDM tlw. durch externe Tools geschieht, also die hierfür benötigten Daten nicht implizit im CDM gespeichert werden sondern in hierfür verwendeten templates oder themes.

|Tabelle RLDB|Attribut|CDM|Klären|

Teilprojekt Alle Classification Bezug Projekt, Teilprojekt, Haupttabelle genaue definieren
Haupttabelle - Reference
Kurzbez: Nom.Ref.Title
Name Title
Raum_ID: Modifier auf Reference (evtl. auch auf DescriptionBase) genaue Verwendung
Quelle ?? Bedeutung
Bearbeiter Autor
Zeitbezug !PublicationDate
!WissenschaftlicheNamen !TaxonNameBase
Def_Raenge Rank
Def_Reich so nicht vorhanden
Taxonyme - Taxon
!AppendedPhrase appended phrase in TaxonBase
Excode nicht vorhanden, ggf. Extension, UUID Bedeutung und Verwendung klären
Epi2/4 Bedeutung klären ggüber Ep3/5 in wissNamen
!HauptTabGueltigeNamen Sequenz nicht vorhanden, workaround hängend an Taxon über Extension oder über Descriptions (Feature: Reihenfolge und TextData oder QuantitativeData(?) ). Evtl. auch über OriginalSource, als ID oder Annotation). Warum befindet sich die Sequenz nicht in der Taxonyme Tabelle?
REL_SynonymeZuTaxonymen - Synonym, SynonymRelationship(type), TaxonRelationship(type)
Zusätze appended phrase in TaxonBase
Epi2/4 Bedeutung klären ggüber Ep3/5 in wissNamen
!WissNamenFormatiert nicht in DB
SORT_XXX notwendig in DB (?)
Def_Konzeptsynstat !TaxonRelationshipType + Representations
Def_Synstat !NameRelationshipType, SynonymRelationshipType Mehrfachnennungen, Mischung aus Synonymie und Namensabeziehung
!DeutscheNamen - !CommonTaxonName
!TrivialName !CommonTaxonName.Name
Gruppe nicht vorhanden Verwendung
Spezifischer_Teil nicht vorhanden Verwendung
REL_DeutscheNamenZuTaxonym !CommonTaxonName
Sequenz nicht vorhanden
BfN_Eigenschaften Marker oder FeatureTree Warum Trennung von Tabelle Eigenschaften
Def_Eigenschaft_Bewumf ?? Bedeutung und Verwendung
Def_EigenschaftStr !FeatureTree
Def_Eigenschafttyp Unterklassen von DescriptionElementBase; Feature warum soviele Typen für Festkommazahlen; warum Kommentar als eigenständigen Typ
Eigenschaften - !TermVocabulary + Representation Zuordnung zu STRG_ID unklar
Listenwerte - !DefinedTerms; Vocabularies
Informationen - Description; DescriptionElement
RaumId: !GeoScope bzw. Modifier auf Description oder DescriptionElement
TaxonymeXXX Taxon
!EigenschaftenId, ListenwertId !DescriptionElement; Features; Vocabularies
Text, TextFormatiert !TextData und TextData.format
Festkommazahl !QuantitativeData
Zeit nur workaround als Annotation, Referenz einer OriginalSource oder als QuantitativeData
REL_Wertelisten_Eigenschaft - !DefinedTerms; Vocabularies Warum wird zwischen Eigenschaften und Wertelisten unterschieden, wenn die Beziehung 1:1 ist und warum gibt es eine Zwischentabelle?
Wertelisten s. REL_Wertelisten_Eigenschaften
Def_Raumbezug !NamedArea als GeoScope
REL_Haupteigenschaft - !FeatureTree
Def_Auswertungsgruppen !DefinedTerms; Vocabularies
!TaxonymeInAuswertungsGruppen !CategoricalData;!TaxonDescription
Def_AusgabeGruppen Feature in FeatureTree
Def_Ausgabekanal !FeatureTree
Def_Gruppensequenz Feature in FeatureTree
DTEntityManagement Alle nicht in DB, tlw. Über Representationen sinnvoll in DB? Auch als Konfig.file für Ausgaben möglich
Bearbeiter Alle User; Person

Mapping: FFH-DB -> CDM

Die FFH-Datenbank besteht nur aus einer Tabelle. Diese beinhaltet Datensätze zu Taxa und Synonymen. Synonyme sind zu den akzeptierten Taxa in Beziehung gesetzt.

Akzeptierte Taxa sind nicht innerhalb einer Hierarchie in Beziehung gesetzt sondern lediglich über den ersten Teil des Schlüssels 21 Hauptgruppen zugeordnet.

Eine automatische Zuordnung von Arten und Unterarten zu Genus bzw. Arten wäre ggf. möglich, beinhaltet aber das Problem, dass Zuordnungen zu Zwischenrängen wie Subgenus oder Sectio nicht automatisiert möglich ist.

Tabelle RLDB Attribut CDM Anmerkung Klären
Ref_art_N2000
Nr_RefTaxTyp !OriginalSourceId Doppelter Schlüssel, erster Teil mit 21 Ausprägungen
NR_REFART !OriginalSourceId Doppelter Schlüssel, zweiter Teil, eindeutig je Art innerhalb einer Gruppe des ersten Schlüssels
CODE_EU Extension meist leer Bedeutung
GUELTIG !SynonymRelationship; Rank
SYN Synonymie und Rang Ausprägungen: NULL, ?, <, =, a, g,p,s;
SYN.? Bedeutung
SYN.< oft für Subgenus, aber nicht immer Bedeutung
SYN.= Synonym Synonym: "Gueltig" enthält das aktzeptierte Taxon
SYN.a Rang aggr.
SYN.g Rang genus
SYN.p Artengruppen
SYN.s Rang unterhalb Art
NAME !TaxonNameBase enthält auch manchmal Zusatzinfos wie "[[pp Omphalina alpina]]" oder s.l., s.str.
NAME_D !CommonTaxonName Deutscher Name
Autor !TaxonNameBase.authorshipCache enthält manchmal zusätzliche Information wie "nomen dubium", Inreferenz, sensu auct.,
FFH2 !DefinedTems; Vocabularies FFH-Eigenschaft
FFH4 !DefinedTems; Vocabularies FFH-Eigenschaft
FFH5 !DefinedTems; Vocabularies FFH-Eigenschaft
FFH_V !DefinedTems; Vocabularies FFH-Eigenschaft
BRUT !DefinedTems; Vocabularies FFH-Eigenschaft
GAST !DefinedTems; Vocabularies FFH-Eigenschaft
DUZUG !DefinedTems; Vocabularies FFH-Eigenschaft
VR_1 !DefinedTems; Vocabularies FFH-Eigenschaft
VR_1 !DefinedTems; Vocabularies FFH-Eigenschaft
ZUG !DefinedTems; Vocabularies FFH-Eigenschaft
RL_DE !DefinedTems; Vocabularies FFH-Eigenschaft

Verteilung:

SYN n
43628
? 173
< 644
= 22855
a 178
g 9702
p 12
s 2270

Mapping WISIA -> CDM

Die WISIA Datenbank beinhaltet diverse Daten zum Schutzstatus, der Verbreitung und zur Taxonomie und zu Referenzwerken.

Hier untersucht werden nur die Daten die relevant sind für die Taxonomie.

Die WISIA Datenbank ist weitgehend nicht dokumentiert, so dass die folgenden Erkenntnisse sich lediglich aus der Datenbanksturktur ableiten.

Die Taxonomie besteht aus den beiden Haupttabellen zum Speichern von Namen (VTaxName) und von Bäumen bzw. Konzepten (VTaxTree). Zusätzlich gibt es Tabellen zur Erfassung von Rängen, Sprachen, und Reichen, die weitgehend selbserklärend sind, wobei die Abhängigkeit eines Rangs von einer Sprache abzuklären ist. Die Bedeutung von Tabellen zu diversen Gruppen (insbesondere TaxGroup aber auch Workgroup und PraxGroup konnte bislang nicht geklärt werden).

Unklar ist das Handling von Synonymen. Wie wird ein Name als Synonym deklariert (Sysflag ?). Unklar auch, ob Namen doppelt vorkommen können, wenn sie in mehreren Quellen genannt sind.

TaxTree beinhaltet sowohl Konzeptinformationen als auch informationen zur Klassifikation. Einige Felder sind hier noch unklar: Syspart_ID, Indet, A_Taxkey, A_Taxcon. Die Verbindung zu Namen erfolgt über das Attribut "Ebene".

Quellen: ER_DIAGRAMM 20120119, Doku_Taxonomie_wisia.doc, WISIA99_ER_TeilNamen

Updated by Andreas Müller about 2 years ago · 29 revisions