EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852024-03-25T15:28:00ZEDIT Project Management
Redmine feature request #10488 (In Progress): Distinguish equal short citations by adding a, b, c,... to ...https://dev.e-taxonomy.eu/redmine/issues/104882024-03-25T15:28:00ZAndreas Müller
<p>WGB:</p>
<p>In der Datenbankausgabe im Portal sind die Beziehungen zum korrekten Zitat immer gegeben, da hier die Einträge direkt referenziert werden (bzw. das bei in-Text Referenzen mal so sein soll). Im Dokument-Text-Output besteht diese Beziehung nicht. Ich habe gestern mehrere Stunden damit verbracht, für eine relativ kleine Publikation (Achyranthoid Clade) die Kurzzitat-Duplikate auszusortieren, also die, die bei gleicher Jahreszahl verschiedenen Bibliographie-Einträgen entsprechen (hier z.B. Townsend (1997) und Townsend (1997a)). Dazu muss man sich dann durch die Referencing Objects wühlen und das für jedes einzelne Kurzzitat im Text überprüfen und ggf. ändern (falls es sich um die 2. oder 3. Referenz handelt).<br>
Eine mögliche Lösung, um dies zu erleichtern wäre, im Dokument tatsächlich die Kurzzitate mit der Bibliographie zu verlinken. Hört sich nett an, würde aber die Verarbeitung in Word ziemlich komplizieren (und damit Versions-anfälliger machen). Und für die Einreichung als Artikel müsste dann immer noch manuell das Kurzzitat entsprechend verändert werden.<br><br>
Optimal wäre, wenn man dies bereits in der Platform lösen könnte. Da dies kontextabhängig ist, kann man bei einer optimalen Lösung nicht einfach mit einem Zusatz beim Datum der Referenz arbeiten (obwohl das dann ja schon sehr hilfreich wäre, weil es zumindest die Eindeutigkeit herstellen würde). Ich denke, das müsste in der Ausgabe im CDM-L gelöst werden, so dass die Zusätze nur dort benutzt werden, wo tatsächlich Duplikate entstehen. </p>
<p>AM:</p>
<p>Verstehe ich es richtig, dass beim ersten Auftreten eines Kurzzitat-Strings dieser normal ausgegeben werden soll, beim zweiten mal ein „a“ an die Jahreszahl drangehängt werden soll, danach ein „b“, etc.? Das heißt die Reihenfolge, welche Referenz jetzt kein oder „a“, „b“, oder … als Anhang bekommt ist beliebig wählbar? Alles andere wäre schwierig, da der Export bezüglich Referenz-Ausgabe völlig unsortiert verläuft und eine nachträgliche Änderung der Daten sobald ein Duplikat auftaucht, mit viel Aufwand verbunden wäre.</p>
bug #10487 (Resolved): Rename nameUseInSource to original spelling in CDM light name tablehttps://dev.e-taxonomy.eu/redmine/issues/104872024-03-25T15:12:35ZAndreas Müller
<p>WGB:</p>
<p>das erste verstehe ich immer noch nicht: Die nomenklatorische Referenz bezieht sich doch auf den Namen. Oder ist das das „Original spelling“? Dann sollten wir das Attribut auch so nennen, wenn wir die Doku updaten. <br>
Das wäre übrigens gut, wenn man das hätte, da man damit irgendwie die Indizierung von diesen Namen in Word erreichen könnte (die bisher nicht stattfindet, da der Name ja nicht ausgeschrieben wird). Dann sollten wir aber sowohl den _Fk als auch den Eintrag ausgeben.</p>
<p>Also </p>
<p>39 NameOriginalSpelling_Fk<br>
40 NameOriginalSpelling [der entsprechende Name mit Autor]<br>
41 AppendedPhrase</p>
bug #10455 (New): Improve DOI formatting for references in cdm-lighthttps://dev.e-taxonomy.eu/redmine/issues/104552024-01-17T12:42:19ZKatja Luther
<p>for details see <a class="issue tracker-5 status-5 priority-10 priority-lowest closed" title="feature request: Improve DOI formatting for references (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/10240">#10240</a></p>
<p>It needs to bediscussed if the DOI should go into the bibliographic reference formatter and how far this works together with other usages of the formatter and how far the links can be integrated there.</p>
feature request #10449 (Closed): Allow filtering out synonyms in list exportshttps://dev.e-taxonomy.eu/redmine/issues/104492024-01-12T16:09:27ZAndreas Müller
<p>Currently this should be implemented for cdm-light, coldp, wfo-classification and dwc-a export</p>
discussion #10408 (New): Workflow support for print publication referenceshttps://dev.e-taxonomy.eu/redmine/issues/104082023-09-27T15:30:43ZAndreas Müller
<p>For print publication we usually need reference lists. These maybe can be created during CDM light export. We need to discuss if this is possible and how they should be filtered and formatted.</p>
<p>Maybe formatting is too difficult in some cases so we only export the list to allow comparison with a manually created list to find missing references. </p>
bug #10357 (Resolved): CDMLight fix handling for names used as synonym and accepted taxahttps://dev.e-taxonomy.eu/redmine/issues/103572023-06-22T11:48:03ZKatja Luther
<p>mail ERS:</p>
<p>Hallo,</p>
<p>ich habe gerade versucht, für die Gattung Oncostema Raf. einen cdm-light Output aus Euro+Med Plantbase zu erstellen, da ich diesen an meine beiden Co-Autoren der Gattung schicken möchte.</p>
<p>Das Ergebnis ist anbei. Folgendes Problem tritt dabei auf:</p>
<p>Der Name Oncostema africanum (Borzi & Mattei) Speta taucht zweimal in Euro+Med Plantbase auf, einmal im bisher publizierten und auch im Portal sichtbaren Kew-Treatment als Synonym von Scilla peruviana L., und einmal als akzeptierter Name im unpublizierten, neuen Treatment von Raab-Straube & al.</p>
<p>In CDM light wollte ich mir eigentlich nur das neue Treatment anzeigen lassen (als Ausgangspunkt habe ich den Knoten Oncostema gewählt).</p>
<p>Was aber jetzt passiert, ist, dass im Word-Dokument auch die syn.sec. Kew Treatment angezeigt werden, nicht nur die syn.sec. Raab-Straube & al. (welche dagegen teilweise fehlen können, wenn es Überlappungen gibt). Mit dieser speziellen Situation kommt Euro+Med PlantBase also anscheinend nicht zurecht, da so eine datenbankstruktur nicht vorgesehen ist.</p>
<p>Um den Autoren also das eigentlich noch nicht publizierte Treatment schicken zu können, muss ich es also doch erstmal publizieren, damit ich die Mehrfachverwendung von Namen dann eliminieren kann, richtig?</p>
<hr>
<p>The problem comes from the handling of names used for more then one taxonbase.</p>
bug #10193 (New): OutOfMemory exception when exporting mexico florahttps://dev.e-taxonomy.eu/redmine/issues/101932022-11-30T23:17:25ZAndreas Müller
<p>When running CDM-l export the OOME occurred after about 85% (see logfile at about line 39.467).</p>
<p>A bit earlier (line 39.370) a deadlock appears in C3P0PooledConnectionPoolManager which might be caused by the memory issue (or is the OOME caused by the deadlock?).</p>
<p>Starting with about 75% the export becomes much slower. Before it is about 2 min per 10% then it becomes 15min per 10%.</p>
<p>After the OOME there come some JDBC exceptions like "Caused by: java.sql.SQLException: Not a navigable ResultSet." which are probably consecutive errors of the OOME.</p>
<p>Solutions:</p>
<ul>
<li>we need to further optimize memory handling during exports e.g. by trying to profile it</li>
<li>a first workaround for the efloramex could be to give some more memory to the CDM server instance</li>
</ul>
bug #10102 (Closed): Non-names formatted in italicshttps://dev.e-taxonomy.eu/redmine/issues/101022022-07-29T09:09:23ZAndreas Müller
<p>WGB:</p>
<p>mir ist eben dann auch aufgefallen, dass die „non“-Namen nicht kursiv formatiert werden:</p>
<p>− Achyranthes tenuifolia Steud., Nomencl. Bot., ed. 2, 1: 16. 1840, nom. inval. [non Achyranthes tenuifolia Willd.]</p>
<p>Das betrifft in HomotypicGroup.csv die Felder <br>
HomotypicGroupString<br>
HomotypicGroupStringWithoutAccepted</p>
bug #9987 (New): Handle areas of different vocabularies in comparatorhttps://dev.e-taxonomy.eu/redmine/issues/99872022-03-17T08:39:47ZKatja Luther
<p>Areas of different vocabularies can not be compared for example while creating the condensed distribution string in cdmLight export (portals using the condensed distribution string should have the same problem).</p>
<p>This could be fixed by using the uuid instead (only if the vocabularies are different)</p>
<p>Additionally a warning should be added to the exportResult which contains explanations how to fix the problem (see <a class="issue tracker-4 status-1 priority-11 priority-default" title="bug: Problems in cdmLight export which are caught and not critical should be warnings only (New)" href="https://dev.e-taxonomy.eu/redmine/issues/9985">#9985</a>)</p>
bug #9986 (New): Log when cdmLight export is interrupted completelyhttps://dev.e-taxonomy.eu/redmine/issues/99862022-03-17T08:27:54ZKatja Luther
<p>Actually the error log does not show whether the export was created or not if exceptions appeared. Sometimes the export is created but with missing data caused by the exceptions and in some rare cases the export is interrupted completely but this is not mentioned in the error log.</p>
bug #9985 (New): Problems in cdmLight export which are caught and not critical should be warnings...https://dev.e-taxonomy.eu/redmine/issues/99852022-03-17T08:23:43ZKatja Luther
<p>Actually every exception during the export is logged as exception, but some are catched and should only be logged as warning.</p>
<p>Example:<br>
Areas of different vocabularies could not be compared and the condensed distribution string can not be created.</p>
bug #9662 (New): CDMLight: Output should summarize all MAN with same name and err. sechttps://dev.e-taxonomy.eu/redmine/issues/96622021-06-10T07:44:48ZKatja Luther
<p>mail WB:</p>
<p>Aber hierzu noch der Wunsch, dass die MAN-sensu Referenzen zusammengefasst werden, wenn der Name und die err.sec. Referenz gleich sind.</p>
<hr>
<p>This functionality should be available for portal and CDMLight/other exports</p>
bug #9646 (Closed): CDM Light: Add name relationship to concatenated string for homotypic group https://dev.e-taxonomy.eu/redmine/issues/96462021-06-03T06:23:56ZKatja Luther
<p>mail WB:</p>
<p>Name relationships werden in der Konkatenierung der homotypischen Gruppen in CDM-Light nicht berücksichtigt? Also z.B. in Kuba:<br>
CDM-Light: Polygonum truncatum A. Rich. in Sagra, Hist. Fís. Cuba 11: 182. <br>
Portal: Polygonum truncatum A. Rich. in Sagra, Hist. Fís. Cuba 11: 182. 1850 syn. sec. Greuter & Rankin Rodríguez 2017 [non Polygonum truncatum Zoll. & Moritzi]</p>
feature request #9262 (Closed): Several open issues for cdmlight export related to Cactaceae and ...https://dev.e-taxonomy.eu/redmine/issues/92622020-10-22T10:45:11ZAndreas Müller
<p>Mail WGB 2020-10-22:</p>
<ol>
<li><p><del>Fehlerhafter Literatur-Output – zwei Autoren + et al. statt Erstautor + et al., siehe angehängtes Mail dazu<br>
Das muss unbedingt gelöst werden, sonst müsste ich das alles manuell in Word nachformatieren, und das sind etliche Referenzen, die das betrifft.</del></p></li>
<li><p><del>Fehlerhafte „fide“ Ausgabe. Siehe auch die angehängten Mails dazu. Soweit ich sehe, steht überall falsch fide, es müsste immer „deginated by“ heißen.<br>
Ich verstehe auch nicht ganz, warum das nur bei Lektotypen gelten soll, Neotypen und Epitypen werden schließlich auch designiert?<br>
WGB: ja klar, Lekto-, Neo- und Epitypen, hatte ich unten vergessen zu ergänzen. <br>
Noch mal für die Ausgabe: Das „fide“ gehört zu den Source Referenzen für Typen, das „designated by“ (das früher bei allen Referenzen stand) gehört zu den Type Status Referenzen bei Lekto-, Neo- und Epitypen.<br>
WGB (telfonisch): Designated by gehört direkt hinter die Sammlung, nicht in die eckige Klammger, diese ist nur für fide Referenzen</del><br>
Das betrifft auch den Portal output. => Portal muss noch umgestellt werden auf TypeDesignationSetManager</p></li>
<li><p>Ausgabe -title cache generation not implemented-. Das kommt, soweit ich sehe, nur bei specimens vor, und zwar bei allen, aber nicht bei Typen. Specimens gibt es nur in bestimmten Gattungen, z.b. in Lepismium, Rhipsalis, Epiphyllum, Disocactus. <br>
WGB: Ich habe das im Output ohne Specimen als factual data nicht gesehen, ist also für den jetzt anstehenden Artikel noch nicht relevant. Das kann aber an anderer Stelle (Amaranthaceae, Vanessas Artikel, hoffentlich auch noch dieses Jahr!) relevant werden. <br>
Andreas fragte, wo denn diese Specimen stehen – ich nehme an, dass das in den von Nadja genannten Gattungen specimen als factual data am Taxon sind (?). moved to new ticket <a class="issue tracker-5 status-1 priority-11 priority-default" title="feature request: Improve handling of specimen without titlecache in cdmLight (New)" href="https://dev.e-taxonomy.eu/redmine/issues/9309">#9309</a>.</p></li>
<li><p><del>Bug Klammerautoren bei Gattungstypen hatte Katja ja schon gelöst (im nächsten Release)</del>.</p></li>
<li><p><del>Einschluss von syn.-sec.-Referenzen (Kurzzitat) in der homotypischen Gruppe, in HomotypicGroup.csv (und Taxon.csv, siehe unten)<br>
Ich gebe derzeit zwei Dokumente aus, eine mit den syn.-secs aber ohne homotypische Gruppe und dann das eigentliche Format mit homotypischen Gruppen. Das verwirrt die Reviewer, von denen wir eben auch Input zu den syn.-sec.-refs. wollen, obwohl wir das normalerweise letztendlich nur auf dem Website veröffentlichen. Ich hätte also gern ein Feld, in dem nach jedem Namen die syn.-sec.-Kurzreferenz mit ausgegeben wird.<br><br>
Also ein neues Feld HomotypicGroupStringWSec in der HomotypicGroup.csv.</del></p></li>
<li><p>Homotypical Group in Taxon.csv<br>
<del>Ich stoße bei den großen Datenbanken (Euro+Med, Caryophyllales) an die Grenzen der Datenverarbeitung mit Access. Knackpunkt ist die Konkatenierung von Strings aus komplexen Strukturen. Das wirkt sich z.Zt. vor allem an zwei Stellen aus, distributions (derzeit nicht so dringend) und homotypical groups:<br>
Um den Taxonnamen incl. nom. Zitat mit der Sec.-Referenz getrennt von seinen homotypischen Synonymen ausgeben zu können, muss ich mir diese group selbst (ohne den Taxonnamen) zusammenstellen. Im verarbeiteten Output sieht das dann so aus: <br>
.<br>
Achyranthes bidentata Blume, Bijdr.: 545. 1826. Sec. WFO-Import Amara-Cheno-Polyg-Dianthus June 2018<br>
≡ Centrostachys bidentata (Blume) Standl. in J. Wash. Acad. Sci. 5(3): 75. 1915.<br>
= Achyranthes fauriei var. tomentosa Honda, Nom. Pl. Jap. ed. emend.: 373. 1957. Achyranthes bidentata var. tomentosa (Honda) H.Hara, Fl. E. Himal.: 635. 1966.<br>
.<br>
Der erste Absatz ist der akzeptierte Name mit Sec.-Ref (kein Problem)<br>
Der 2. Absatz ist die homotypische Gruppe des akzeptierten Namens OHNE den Namen selbst (hier liegt das Problem – CDM-light liefert mir HomotypicGroup.HomotypicGroupString = Achyranthes bidentata Blume; Centrostachys bidentata (Blume) Standl.<br>
Der 3. Absatz ist die homotypische Gruppe eines heterotypischen Synonyms. Das entspricht direkt der Ausgabe HomotypicGroup.HomotypicGroupString in CDM-light, also auch kein Problem.<br>
Die Lösung hier wäre also ein zusätzlicher String ohne den akzeptierten Namen – das Problem ist aber natürlich, dass der akzeptierte Namen aus einer homotypical group ja zwischen verschiedenen Klassifikationen variieren kann. Man müsste das also in die Taxon.csv stellen, als HomotypicSynonymGroupString <br>
und dann natürlich auch HomotypicSynonymGroupStringWSec.<br>
AM: Da wir ja nur <em>eine</em> Klassifikation ausgeben, würde ich davon ausgehen, dass es je homotypischer Gruppe eindeutig ist, welches Taxon das akzeptierte ist. Wir könnten das also schon auch in csv für homotypische Gruppen aufnehmen statt in Taxon.csv (deswegen heißt es ja cdm*light*).<br>
Oder übersehe ich da was oder ist es besser aufgehoben in der Taxon.csv?<br>
WGB: Ja, da habe ich wohl zu generell gedacht – wenn wir bei der Limitation bleiben, ist das korrekt. Falls es zu Publikationen mit mehreren Klassifikationen kommt, muss man die Word-Dokumente dann vor dem Indizieren zusammenführen</del></p></li>
<li><p>Excluded und Uplaced in Sort Order [Mail vom 20.10.]<br>
beim Füllen des Felds SortOrder in der Taxon.csv werden die als excluded oder als unplaced markierten Datensätze korrekt ans Ende gesetzt, aber leider werden die beiden Kategorien gemischt. Das bringt meinen Output dieser Gruppen durcheinander – können wir bitte zuerst die unplaced und dann die excluded am Ende einordnen? <br>
mail KL:<br>
Ich habe mir jetzt nur die unplaced und excluded Taxa, die direkt unter Cactaceae hängen angeschaut, aber da ist der Sortindex korrekt. Gibt es dazu ein Beispiel, wo die Sortierung gemischt ist?<br>
WGB: merkwürdig, die kamen bei mir durcheinander raus – aber erst am Ende. Ich kümmere mich darum. </p></li>
<li><p><del>Autonyme in homotypischen Gruppen<br>
wenn Autonyme in homotypischen Gruppen eingeordnet sind, wird dahinter gar kein Trennzeichen gesetzt, hier mal ein Beispiel<br>
≡ Echinocactus taltalensis Werderm. in Notizbl. Bot. Gart. Berlin-Dahlem 10(97): 763. 1929. Copiapoa taltalensis subsp. taltalensis Copiapoa humilis subsp. taltalensis (Werderm.) Doweld in Sukkulenty 4: 49. 2002. Copiapoa humilis var. taltalensis (Werderm.) A.E.Hoffm., Cact. Fl. Silvestre Chile: 118. 1989.</del><br>
=> not an issue anymore if 10. will implemented</p></li>
<li><p>Chronologische Anordnung der Synonyme in homotypischen Gruppen<br>
[wir wollen die Kakteen in Willdenowia publizieren, das ist also eilig]<br>
<del>ERS: Im jetzigen Word-Output erscheinen die Synonyme vollkommen unsortiert, und zwar sowohl innerhalb der homotypischen Gruppen (abgesehen davon, dass das Basionym immerhin an erster Stelle steht) als auch außerhalb.<br>
Man könnte nun entweder alphabetisch sortieren (so ist es in der Nepenthes-Liste umgesetzt, wobei allerdings sogar die invaliden Namen der alphabetischen Sortierung unterworfen sind, was sehr unüblich ist –normalerweise stehen diese am Ende), oder chronologisch. Ich bevorzuge eine chronologische Sortierung, soweit ich weiß, ist das auch Willdenowia-Standard. So haben wir es auch damals im Cichorieen-Portal umgesetzt, siehe z.B. <a href="http://cichorieae.e-taxonomy.net/portal/cdm_dataportal/taxon/0c17975e-14d9-432b-846a-9f290c1a88fe/synonymy">http://cichorieae.e-taxonomy.net/portal/cdm_dataportal/taxon/0c17975e-14d9-432b-846a-9f290c1a88fe/synonymy</a>. Das Schöne dabei ist, dass bei fehlenden Jahreszahlen wiederum alphabetisch sortiert wurde. Also, im Cichorieenportal ist es schon sehr ausgefeilt, das hat viel Arbeit gekostet, wie ich mich erinnere.<br>
Wenn es das schon mal im Portal gibt, ist ja die Implementierung zumindest schon mal spezifiziert – wir möchten generell Willdenowia Standard folgen. <br>
Die Anordnung der heterotypischen Synonyme („außerhalb“) erfolgt im CDM2Word Programm, mit den invaliden Namen am Ende. Ich werde versuchen, das zu einer Anordnung nach (Basionym-) Jahr mit nachgestellten invaliden Namen zu ändern.<br>
WGB: Dazu müsste ich aber den Gruppenstring jeweils immer parsen, um das älteste Jahr herauszubekommen und dabei dann noch invalide etc. designations ausschließen, das ist kompliziert. Daher also als zusätzliches CDM-light Feld:<br>
HomotypicGroupYear - Das älteste Jahr eines validen Namens in der homotypischen Gruppe.</del><br>
wurde durch sortindex gelöst</p></li>
<li><p>Homotypische Gruppen: Identitätszeichen vor jedem Synonym <br>
<del>ERS: Eine Bemerkung zum Layout: In der Willdenowia ist es Standard, dass auch innerhalb der homotpyischen Gruppen das Identitätszeichen vor jedem Synonym ein Identitätszeichen steht (siehe z. B. Willdenowia 49: 423. 2019, unter Drimia anthericoides). Ich finde, das verbessert die Übersicht. Die Namen alle ohne weitere Trennzeichen so aneinanderzureihen, wie es jetzt der Fall ist, finde ich nicht so schön, aber das mag Geschmacks- bzw. Gewöhnungssache sein. Im Caryophyllales-Paper wurde es übrigens auch nach Willdenowia-Standard umgesetzt.<br>
Dies umzusetzen müsste einfach sein – und falls für einen anderen Publikationsort das nicht gewünscht wird, ist es auf jedem Fall einfacher, das wieder herauszunehmen, als es einzufügen.<br>
-> sollte man das dann nicht in der Word Generierung machen, entweder mit Identitätszeichen oder ohne, je nachdem wie es für die entsprechende Publikation gebraucht wird. Der cdmLight Export sollte ja möglichst generisch bleiben.<br>
WGB: Ich sehe gerade, dass das in Willdenowia (im von Eckhard genannten Artikel) tatsächlich so gemacht wird. Ich würde ja nach jedem Synonymzitat einen Punkt setzt. Egal, wenn wir Willdenowia folgen, müssen die anderswo gemachten Punkte weggelassen werden, also bleibt etwas zu tun</del></p></li>
<li><p>Homotypische Gruppe: Komma<br>
<del>Vor dem nomenklatorischen Status, nach der Jahreszahl sollte ein Komma stehen, das ist wohl auch Willdenowia Standard, fand Nadja auch:<br><br>
WB: Außerdem finde ich es eigentlich nicht schön, dass der nom. status. nach einem Punkt hinter der Jahreszahl kommt – ich fände da ein Komma besser; was meinst Du? Z.B.:<br>
<img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1943/picture597-1.png" alt="" /><br>
Andererseits steht vor der Jahreszahl ja auch ein Punkt ...</del><br>
=> Verwendung des fullTitleCache </p></li>
<li><p><del>NameTypeDesignations werden nicht exportiert</del></p></li>
<li><p>NK: <del>Semikolon zwischen zwei Notes<br>
Zwei Notes werden mit einem Semikolon zwischen Ihnen ausgegeben, zum Beispiel<br>
Hariota DC. is a homonym of Hariota Adans. (1763) and was therefore replaced by the name Hatiora Britton & Rose.; Phylogenetics:<br>
Die Notes sind normalerweise in ganzen Sätzen geschrieben, deswegen ist Semikolon da überflüssig.<br>
Ich fände es auch für die Lesbarkeit besser, wenn zwischen zwei Notes ein Absatz eingefügt werden würde</del> => KL: Das Problem mit den Notes sollte wahrscheinlich eher bei der Word Generierung gelöst werden, da könnte man ja ein „.;“ durch ein „./n“ oder ähnliches ersetzt werden.</p></li>
<li><p><del>Doppelte Autoren bei nomenklatorischen Referenzen. CDM: Hatiora Britton & Rose in L.H.Bailey, Standard Cycl. Hort.: 1432. 1915<br>
Word: Hatiora Britton & Rose in L.H.Bailey, <strong>L.H.Bailey</strong>, Standard Cycl. Hort. 1432. 1915</del> => gefixt im cdmlight output</p></li>
<li><p><del>Inautoren mit Initials: CDM: Rhipsalis bambusoides F.A.C.Weber in Bois, Dict. Hort.: 1048. 1898<br>
Word: Rhipsalis bambusoides F.A.C.Weber in Bois*<em>, D.G.J.M.</em>*, Dict. Hort. 1048. 1898 => muss in Word gefixt werden, ggf. hinzufügen des TaxonName.fullTitleCaches, der dies richtig beinhaltet. Auch Punkt 11. würde mit dem fullTitleCache gelöst</del><br>
-> fulltitleCache wird verwendet</p></li>
<li><p><del>Doubtful synonyms should be displayed with "?"</del></p></li>
</ol>
<p>(issues 3 and 4 removed as 3 is related to titleCache generation for DNA-Samples and 4 is solved already)</p>
feature request #9110 (Feedback): Add additional informations to metadata table of cdmLighthttps://dev.e-taxonomy.eu/redmine/issues/91102020-06-30T11:12:01ZKatja Luther
<p>For the usage of cdmLight in GfBio we need some more information in the metaData table:</p>
<ul>
<li>creationDate</li>
<li>Base URL of dataportal</li>
<li>licence</li>
<li><p>tbc </p></li>
<li><p>add the information to the cdmLightExportConfigurator</p></li>
<li><p>and add a wizard page to the export configuration wizard for the editor </p></li>
</ul>