EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852024-03-25T14:40:09ZEDIT Project Management
Redmine feature request #10486 (New): Allow area tree as parameter in advanced search areasInUse requesthttps://dev.e-taxonomy.eu/redmine/issues/104862024-03-25T14:40:09ZAndreas Müller
<p>To be implemented webservice side and dataportal side.</p>
feature request #10479 (New): [Discuss] Format hybrids with space between × and name parthttps://dev.e-taxonomy.eu/redmine/issues/104792024-03-13T16:33:25ZAndreas Müller
<p>WGB:</p>
<p>Bisher formatieren wir Nothotaxa mit dem Hybrid-marker direkt vor dem Namensteil. Ich hatte folgenden Kommentar zu diesem Problem von IPNI bekommen (von Rafael Govaerts), nachdem ich mich dummerweise über das dort verwendete Leerzeichen beschwert hatte. <br>
Ich plädiere dafür, in der Platform hier IPNI und den Argumenten von Rafael zu folgen, wie das wohl auch WFO macht.</p>
feature request #10478 (New): (How to) handle pro sp. and https://dev.e-taxonomy.eu/redmine/issues/104782024-03-13T11:08:00ZAndreas Müller
<p>MM:</p>
<p>May you please inform me how to mention "Pro. sp." status of a name in TaxEditor?<br>
"Pro. sp." indicates that the name is originally published as a good species but after publication it is defined as a hybrid. </p>
<p>ERS:</p>
<p>this is a good question. I also need this feature from time to time. Norbert and Nadja, how do you handle this?</p>
<p>It could be an “appended phrase” (but then it goes also in the title of the taxon name, which we don’t want),<br>
or an editorial annotation (which is sometimes not shown).</p>
<p>Is there a better way?</p>
<p>AM:</p>
<p>should we add this as a nomenclatural Status to the list of the nom. status types? Is it somehow covered by the code? How should it be formatted? Like other nom. status?<br>
Can you give an example of a fully formatted name including the status (and reference and maybe original spelling)?</p>
<p>ERS:</p>
<p>this is mentioned (together with the inverse situation, when a good species was originally described as a hybrid) in Art. 50.1 of the Code:</p>
<p><a href="https://www.iapt-taxon.org/nomen/pages/main/art_50.html">https://www.iapt-taxon.org/nomen/pages/main/art_50.html</a></p>
<p>I briefly discussed it with Norbert and we agree that it should not be a nomenclatural status, which it isn’t, but it is quite well covered when entered as an “appended phrase”:</p>
<p>Hieracium nuriense Mateo & al. (pro hybr.) in Fl. Montiber. 85: 35. 2023</p>
<p>or</p>
<p>Hieracium nuriense Mateo & al. in Fl. Montiber. 85: 35. 2023 (pro hybr.)</p>
<p>So currently the appended phrase is inserted directly behind the name and authorship, not behind the entire publication.<br>
Both ways are correct, I believe.</p>
<p>NaK:</p>
<p>thanks for clarifying!</p>
<p>ERS:</p>
<p>I forgot to mention</p>
<p><a href="https://europlusmed.org/cdm_dataportal/taxon/5d63a1f0-3474-4828-97b6-dabe440426e3">https://europlusmed.org/cdm_dataportal/taxon/5d63a1f0-3474-4828-97b6-dabe440426e3</a></p>
<p>that the Cache for the Page title currently includes the appended phrase. I don’t believe this is needed. The appended phrase should not be included, similar to the original spelling which should also be omitted there (mentioned a few weeks ago).</p>
<p>The title of the taxon page should only include the name and nothing else, I think.</p>
<p>AM:</p>
<p>To be honest, I am not sure if “appended (name) phrase” is necessarily the best place to put this. The field as far as I understand it, should be used for name parts which do not fit into the ordinary trinomial name structure. Mostly for exceptions etc.<br>
Therefore it is part of the name, not additional information.</p>
<p>But pro hybr. and pro sp. from my point of view are not parts of the name but additional information retrieved from the original publication. Maybe there is also some similarity to “pro syn.” which we also handle as “nom. status”, though I know that pro syn. induces the name to be invalid and therefore it is more a nom. status in the strict sense then pro hybr. and pro sp. </p>
<p><img src="https://dev.e-taxonomy.eu/redmine/attachments/download/2439/clipboard-202403131402-aerig.png" alt="" /></p>
<p>However, from the data perspective it is always better to handle data structured instead of handling it in a freetext which is also used for completely different information.<br>
Doing so enables one e.g. to format information consistently throughout a publication. Also it makes it easier to parse names and to find names having such an information.<br>
Therefore I personally prefer to use nom. status (sensu lato) for this rather than appended (name) phrase. But maybe there is an even better solution.</p>
feature request #10474 (New): Improve occurrence loading for taxon pagehttps://dev.e-taxonomy.eu/redmine/issues/104742024-02-16T08:56:20ZAndreas Müller
<p>This is strongly related to <a class="issue tracker-5 status-2 priority-10 priority-lowest" title="feature request: Use DTOs for portal taxon page (cont.) (In Progress)" href="https://dev.e-taxonomy.eu/redmine/issues/10322">#10322</a>. There we already split SpecimenOrObservationBaseDTO and subtype DTOs into relatively pure DTOs and loader classes. But there are still a couple of issues left.</p>
<ul>
<li><del>sort order for derivatives</del> => implemented for sort on the short label </li>
<li>loading of the instances still partly takes place in the service classes, therefore some of the computing steps (computing summary label, boolean hasXXX values and updating the data after adding a derivative, ...) still takes place in the DTO but should be triggered by the loader class</li>
<li>for map computation there is still a separate call to separate remote method taxonOccurrencesFor which internally does the call to the loader again. <del>We need some similar structure as distributionInfoFor</del> which combines DTO base values as well as map parameters => wrapping occurrenceInfoDto implemented, but not yet including map parameters</li>
<li>do load not via model objects</li>
<li>adapt DTOs so that they work with jackson (see <a href="#note-5">#note-5</a>, see also <a class="issue tracker-6 status-1 priority-12 priority-high14 parent" title="task: Refactor and modernize REST web service API (New)" href="https://dev.e-taxonomy.eu/redmine/issues/6992">#6992</a>)</li>
<li>remove all model classes from DTOs (...) => this is mostly done, are there stillopen issues?</li>
<li>implement paging (exists for model objects in OccurrenceService.pageRootUnitsByAssociatedTaxon() maybe used in old derivate path view in dataportal and (without paging) in TaxEditor</li>
<li>create <strong>tests</strong> for DTO loading</li>
</ul>
feature request #10467 (New): Distribution status filter for exportshttps://dev.e-taxonomy.eu/redmine/issues/104672024-02-01T09:51:11ZAndreas Müller
<p>Copied from <a class="issue tracker-5 status-4 priority-12 priority-high14" title="feature request: Allow removing certain distribution status from distribution publication (Feedback)" href="https://dev.e-taxonomy.eu/redmine/issues/9500">#9500</a></p>
<p>This needs to be implemented in the configurators, export routines and the TaxEditor assistent.</p>
<p>E.g. CdmLight, DwC-A, WfoContent, ColDP or also CsvNameExport and WordClassificationExport</p>
feature request #10464 (New): Spring boot and modern Spring compositionhttps://dev.e-taxonomy.eu/redmine/issues/104642024-01-28T19:20:49ZAndreas Müller
<p>Part of new architecture <a class="issue tracker-8 status-5 priority-11 priority-default closed" title="discussion: [Master] Upgrade architecture (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/10445">#10445</a></p>
<ul>
<li><a href="https://start.spring.io/">https://start.spring.io/</a></li>
<li><a href="https://spring.io/guides/gs/spring-boot/">https://spring.io/guides/gs/spring-boot/</a></li>
<li>embedded server
<ul>
<li><a href="https://docs.spring.io/spring-boot/docs/2.0.6.RELEASE/reference/html/howto-embedded-web-servers.html">https://docs.spring.io/spring-boot/docs/2.0.6.RELEASE/reference/html/howto-embedded-web-servers.html</a></li>
<li><a href="https://howtodoinjava.com/spring-boot/configure-jetty-server/">https://howtodoinjava.com/spring-boot/configure-jetty-server/</a></li>
</ul></li>
<li><a href="https://dzone.com/articles/why-springboot">https://dzone.com/articles/why-springboot</a></li>
<li>Graph QL: <a href="https://www.heise.de/hintergrund/Spring-for-GraphQL-in-der-Praxis-Eine-GraphQL-API-fuer-die-Tierklinik-7061176.html">https://www.heise.de/hintergrund/Spring-for-GraphQL-in-der-Praxis-Eine-GraphQL-API-fuer-die-Tierklinik-7061176.html</a></li>
</ul>
feature request #10462 (New): Allow adding ORCID for authors in Phycobankhttps://dev.e-taxonomy.eu/redmine/issues/104622024-01-24T10:56:23ZAndreas Müller
<p>... here: not for users but ordinary Person records.</p>
<p>Uses are handled at: <a class="issue tracker-6 status-1 priority-11 priority-default" title="task: Quick person entry via identifier (ORCID, IPNI, ...) for phycobank (New)" href="https://dev.e-taxonomy.eu/redmine/issues/9106">#9106</a></p>
feature request #10460 (New): Selfregistration widget follow uphttps://dev.e-taxonomy.eu/redmine/issues/104602024-01-24T09:52:18ZWolf-Henning Kusber
<p>Include as optional<br>
Field "Organisation"</p>
feature request #10452 (New): Editorial workflow supporthttps://dev.e-taxonomy.eu/redmine/issues/104522024-01-15T13:26:05ZAndreas Müller
<p>WGB:</p>
<p>Hier geht es im Sinne der CDM-Modellierungsphilosophie darum, möglichst generelle Funktionalitäten zu schaffen, die im ganzen Spektrum der Platform genutzt werden können, also </p>
<ul>
<li>sowohl von in Einzel- als auch in Teamarbeit bearbeiteten Treatments</li>
<li>bei Teamarbeit mit oder ohne klare Abgrenzung der personellen Teilbaumverantwortlichkeit</li>
<li>inhaltlich von einfachen Checklisten hin zu Floren-Treatments bis zu quasi-monographischen Sachen (Doktorarbeiten)</li>
<li>nur-online oder mit Print- oder PDF-Veröffentlichung als Haupt- oder Beiprodukt</li>
<li>mit oder ohne noch zu veröffentlichenden nomenklatorischen „acts“</li>
</ul>
<p>Die Frage, wie man eigentlich die Rollen Autor, Editor, Compiler definiert, muss m.A.n. projektspezifisch entschieden werden. Aber eine Diskussion zur Eingrenzung und Kategorisierung der verschiedenen Möglichkeiten ist hier sinnvoll, so dass das auch bei Ausgaben allgemein und nicht nur projektspezifisch gehandhabt werden kann. Diese Fragestellung geht in die Behandlung der sec.-Referenzen über und weiter auch in die Nutzung und das Handling von Quellreferenzen allgemein. </p>
<p>Weiterhin braucht man Möglichkeiten, den Bearbeitungsstand bzw. die Qualität von bestimmten Informationen zu kennzeichnen. <br>
Als Voraussetzung für die Diskussion bräuchte man hierzu erstmal eine zusammenfassende Darstellung, welche Möglichkeiten es z.Zt. schon in der Platform gibt (auch die, die bisher nicht ausgegeben werden). Möglichkeiten sehe ich angefangen bei Faktenkategorien („last taxonomic scruteny“ mit Quelle wie in CoL; „Taxonomic status“ in eFloraMex a la Iresine Borsch & al.), aber vor allem auch in Markern, Annotations, Extensions (?) und spezifischen Strukturen wie z.B. das geforderte Häkchen im Navigator Baum oder den schon implementierten Kategorien für den Ausschluss von Namen und Taxa.</p>
feature request #10429 (New): Distinguish nomen alternativum and alternative name betterhttps://dev.e-taxonomy.eu/redmine/issues/104292023-11-21T20:33:34ZAndreas Müller
<p>ERS to NT:</p>
<p>I wonder why the definitions for those terms in the glossary of the Shenzhen Code seem to differ, as follows:</p>
<ul>
<li>alternative names. Two or more different names based on the same type accepted simultaneously for the same taxon by the same author and accepted as alternatives by that author in the same publication (Art. 36.3) (see also nomen alternativum).</li>
<li>nomen alternativum (nom. alt.). One of eight family names, each regularly formed from a generic name in accordance with Art. 18.1, allowed as an alternative (Art. 18.6) to one of the family names of long usage treated as validly published under Art. 18.5. In addition, one subfamily name of long usage, Papilionoideae, may be used as an alternative to Faboideae (Art. 19.8) (see also alternative names).</li>
</ul>
<p>For similar terms, the English and Latin expressions including their abbreviations have the same meaning, as nom. cons. = conserved name, nom. nov. = replacement name, etc. For alternative names however, the meaning is different according to this glossary.</p>
<p>I am asking because I am not sure if I can use the abbreviation “nom. alt.” for an alternative name in the sense of Art. 36.3, or if that abbreviation is reserved for a nomen alternativum in the sense of Art. 18.1. The current wording of the Shenzhen Code seems to imply the latter, but I don’t know if this was intended or not. If not, the Ed. Committee might consider clarification in the glossary… also because the status “nom. alt.” is very helpful for older names.</p>
<p>NT:</p>
<p>Yes, the use of nomen alternativum = nom. alt. is reserved in the Code for the sense of (sub)family names under Art. 18.6 and 19.8. It is also used in Appendix IIB where these names are used.</p>
<p>Yes, I realize that the term “alternative names”, in the sense of Art. 36.3, could be confusing because the general linguistic meaning is the same.</p>
<p>One would have to propose an amendment to the Code to change this, though.</p>
<p>ERS:</p>
<p>thanks a lot for this clarification. I should think that some users of the Code are not aware of this distinction and in fact use “nom. alt.” for names which fall under Art. 36.3.</p>
<p>Andreas, Walter, is this correctly modelled in the CDM? Do we have “nomen alternativum (nom. alt.)” as a status which is different from the status “alternative name”?</p>
<p>WGB:</p>
<p>soweit ich sehe, haben wir das nicht als Status sondern als name relationship – „is alternative name for“ und „has alternative name“. <br>
Frage: Ist die „nom. alt.“ Relation für die 8 Familien in Benutzung? Ich glaube, sie werden weder in Caryophyllales noch in den Cuba oder Salvador Floren benutzt.<br>
Ich nehme an, dass diese Relation in der Regel nur im Sinne von Art. 36.3 benutzt wurde. Wichtig ist, dass dafür dann nicht irgendwo „nom. alt.“ eingefügt wird. Außerdem könnte man der Relationsbezeichnung den Artikel und das Code-Kurzzitat hinzufügen, um das eindeutig zu machen.</p>
<p>NoK:</p>
<p>Im TaxEditor ist "nom. altern." sehr wohl auch als Nomenclatural Status verfügbar und im Cichorieen-Portal ist er auch so (fälschlich im Sinne von Art. 36.3) verwendet worden.</p>
<p>WGB:</p>
<p>stimmt, das ist bei Caryophyllales abgeschaltet – unter Serversided Preferences – Names – Nomenclatural status.<br>
Das sollte man vielleicht default-mäßig so handhaben.</p>
<p>ERS:</p>
<p>in Euro+Med benutzen wir den Status „nom. alt.“ für die 8 Familien tatsächlich. Bin mir gerade nicht sicher, ob nur als status oder auch als name relationship. Vermutlich haben wir den Status aber wie Norbert auch fälschlicherweise im Sinne von Art. 36.3 für alternative names verwendet.</p>
<p>AM:</p>
<p>ja, es stimmt, der Stand im CDM ist bislang, dass wir einen Status nom. alt. und eine Namensbeziehung „is alternative name for“ haben. Bei beiden ist die Semantik lediglich im Programmcode definiert als sog. java-doc. Die wurde mal von Marc Geoffroy geschrieben und evtl. vom Berlin Model übernommen.<br>
Interessant ist, dass in beiden Fällen auf Artikel 18 verwiesen wird, d.h. Art. 36.3 war Marc damals gar nicht bewusst und es heißt auch, dass hier nom. altern. doppelt implementiert ist, einmal als Status (unäre Relation) und einmal als (binäre) Relation (Namensbeziehung).<br>
Wobei ein erster Test auf einigen DBs gerade gezeigt hat, dass sowohl der Status als auch die Relation v.a. für Art. 36.3 verwendet wird. Auch nicht verwunderlich, da es für Art. 18 ja nur 8 Fälle gibt.<br>
Die Unterscheidung zwischen unären und binären Relationen macht laut <a class="issue tracker-5 status-1 priority-11 priority-default" title="feature request: [DISCUSS] Unify Nomenclatural status and name relationships (New)" href="https://dev.e-taxonomy.eu/redmine/issues/9273">#9273</a> eigentlich auch keinen Sinn, da es zwar rein unäre Relationen (Status) gibt, in vielen anderen Fällen aber grundsätzlich eine binäre Relation vorliegt, für die der zweite Name aber nicht immer bekannt bzw. angegeben wird. Besser wäre gerade im vorliegenden Fall, den zweiten Namen optional hinzufügen zu können, wenn bekannt. Zumindest scheint mir das so. Das würde auch einiges vereinfachen im Model und im User Interface.<br>
Gerade im vorliegenden Fall wäre es eigentlich sinnvoll, auf diese Modelländerung zu warten, da sonst 4 Fälle unterschiedenen werden müssen, 2 für Art. 18 und 2 für Art. 36.3.</p>
<p>Wie auch immer, müssten dann noch die Label Frage geklärt werden. Natürlich könnte wie Walter vorschlägt, „Artikel und das Code-Kurzzitat“ dem Label hinzufügen. Wobei die Frage ist, ob das nur bei der Auswahl im Editor der Fall sein soll, oder auch bei der Anzeige im Portal. Wenn unterschiedlich, müsste man sehen, wie das modellseitig gehandhabt werden kann. Nicht ganz trivial. Und wie müsste das abgekürzte Label für alternative names (36.3) lauten bei der unären Angabe, also wenn nicht der „Hauptname“ mit angegeben ist. „nom. alt.“ geht dann ja nicht mehr.</p>
<p>Anm.: Walter, du hattest dieses Thema schon mal für das „Manual-EDIT-Platform-Nomenclatural-status-and-name-relationships.docx“ angesprochen in 2020. Aber da war es nur Nebenthema.</p>
feature request #10422 (New): Allow different base layers for distribution and occurrence mapshttps://dev.e-taxonomy.eu/redmine/issues/104222023-10-25T09:27:33ZAndreas Müller
<p>This is overlapping with <a class="issue tracker-5 status-1 priority-11 priority-default" title="feature request: Full implementation for showing IUCN "distribution" data separately (New)" href="https://dev.e-taxonomy.eu/redmine/issues/10343">#10343</a> (having separate maps for speparate features).</p>
<p>We could e.g. define a list of map settings instead of having only the 1 map setting as it is now. These setting will each have a name then and for each feature or each place where to show a map one may select 1 settings from the list of settings. This way the complex UI for setting the map settings can still be outsourced to a separate administration page as it is now and for the feature only 1 parameter needs to be selected.</p>
feature request #10421 (New): Make it impossible to store objects with obligatory fields not set ...https://dev.e-taxonomy.eu/redmine/issues/104212023-10-24T09:53:56ZAndreas Müller
<p>As an example we found StatisticalMeasumentValue without type set, but there are many others.</p>
<p>We need to</p>
<ul>
<li>set up a list of all such fields</li>
<li>define a strategy how to handle this</li>
</ul>
<p>Maybe we can use the validation framework for it, but then we need a generic way how to indicate to the user that there is an obligatory field missing. Only using not null/not empty constraint is not enough as then the exception is thrown after pushing the save button which is not convenient and intuitive. </p>
feature request #10406 (New): Feedback button for taxon pageshttps://dev.e-taxonomy.eu/redmine/issues/104062023-09-27T08:09:42ZAndreas Müller
<p>ERS:</p>
<p>Wir haben die User gefragt, weshalb wir extrem wenig Feedback bekommen, und die Antwort war ziemlich eindeutig:</p>
<p>Die Feedback-Möglichkeit ist viel zu kompliziert, man muss wirklich auf unseren Seiten danach suchen, und das machen die Leute nicht.</p>
<p>Man bräuchte also auf jeder Taxon-Seite, gut sichtbar, einen ganz einfachen Feedback-Button, der beim Klicken direkt das e-mail-Programm mit der richtigen Adresse und dem richtigen Betreff (z.B. Taxonname, ID‘s) öffnet. Vorbild ist hier IPNI (z.B. <a href="https://beta.ipni.org/n/77213147-1">https://beta.ipni.org/n/77213147-1</a><br>
, rechts oben findet man „Contact us“); ich schicke euch gleich mal eine Mustermail, wie so etwas dann aussieht....</p>
<p>Gut wäre dann auch, eine eigene Mail-Adresse für E+M Plantbase zu haben.</p>
<p>RL:</p>
<p>das finde ich eine sehr gute Idee! Man müsste dann sehen, ob das über eine EDIT-Funktionsemail läuft oder für jede Datenbank gleich über die inhaltlich verantwortliche Person.</p>
<p>NaK:</p>
<p>ich finde das auch eine gute Idee, den IPNI Feedback-Mechanismus kenne ich natürlich und nutze ich sehr segelmäßig.<br>
Gut wäre, für eine Datenbank eine Funktionsadresse zu haben, auf die mehrere Leute Zugriff haben. Für Caryophyllales gibt es eine Funktionsadresse, das könnte dann darüber laufen.</p>
<p>Note: this more or less duplicates <a class="issue tracker-6 status-1 priority-10 priority-lowest" title="task: Provide feedback mechanism for dataportals (New)" href="https://dev.e-taxonomy.eu/redmine/issues/9233">#9233</a> / #5078</p>
feature request #10405 (New): Allow synchronizing termshttps://dev.e-taxonomy.eu/redmine/issues/104052023-09-25T13:48:57ZAndreas Müller
<p>see also <a class="issue tracker-5 status-5 priority-13 priority-high13 closed" title="feature request: Implement Cdm2Cdm for vocabularies (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/9771">#9771</a>.</p>
<p>In the above ticket synchronization was only implemented by allowing to add terms. In a next step we want to allow synchronizing labels etc.</p>
feature request #10404 (New): Allow synchronizing term trees in TaxEditorhttps://dev.e-taxonomy.eu/redmine/issues/104042023-09-25T13:45:33ZAndreas Müller
<p>see <a class="issue tracker-5 status-5 priority-13 priority-high13 closed" title="feature request: Implement Cdm2Cdm for vocabularies (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/9771">#9771</a> </p>
<p>For now we only allow synchronizing term trees as this is what is needed for additivity.</p>
<p>The update will currently only add new terms if available. In future also terms will be updated (e.g. label, description, ...), terms will be deleted/moved, etc.</p>
<p>Note: CdmServerInfo.getDevServerRemoteSource() might be relevant.</p>